This file is indexed.

/usr/share/pyshared/zope.schema-3.7.1.egg-info/PKG-INFO is in python-zope.schema 3.7.1-2.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
Metadata-Version: 1.0
Name: zope.schema
Version: 3.7.1
Summary: zope.interface extension for defining data schemas
Home-page: http://pypi.python.org/pypi/zope.schema
Author: Zope Foundation and Contributors
Author-email: zope-dev@zope.org
License: ZPL 2.1
Description: ==============
        Zope 3 Schemas
        ==============
        
        Introduction
        ------------
        
        *This package is intended to be independently reusable in any Python
        project. It is maintained by the* `Zope Toolkit project <http://docs.zope.org/zopetoolkit/>`_.
        
        Schemas extend the notion of interfaces to detailed descriptions of Attributes
        (but not methods). Every schema is an interface and specifies the public
        fields of an object. A *field* roughly corresponds to an attribute of a
        python object. But a Field provides space for at least a title and a
        description. It can also constrain its value and provide a validation method.
        Besides you can optionally specify characteristics such as its value being
        read-only or not required.
        
        Zope 3 schemas were born when Jim Fulton and Martijn Faassen thought
        about Formulator for Zope 3 and ``PropertySets`` while at the `Zope 3
        sprint`_ at the Zope BBQ in Berlin. They realized that if you strip
        all view logic from forms then you have something similar to interfaces. And
        thus schemas were born.
        
        .. _Zope 3 sprint: http://dev.zope.org/Zope3/ZopeBBQ2002Sprint
        
        .. contents::
        
        Simple Usage
        ------------
        
        Let's have a look at a simple example. First we write an interface as usual,
        but instead of describing the attributes of the interface with ``Attribute``
        instances, we now use schema fields:
        
          >>> import zope.interface
          >>> import zope.schema
        
          >>> class IBookmark(zope.interface.Interface):
          ...     title = zope.schema.TextLine(
          ...         title=u'Title',
          ...         description=u'The title of the bookmark',
          ...         required=True)
          ...
          ...     url = zope.schema.URI(
          ...         title=u'Bookmark URL',
          ...         description=u'URL of the Bookmark',
          ...         required=True)
          ...
        
        Now we create a class that implements this interface and create an instance of
        it:
        
          >>> class Bookmark(object):
          ...     zope.interface.implements(IBookmark)
          ...
          ...     title = None
          ...     url = None
        
          >>> bm = Bookmark()
        
        We would now like to only add validated values to the class. This can be done
        by first validating and then setting the value on the object. The first step
        is to define some data:
        
          >>> title = u'Zope 3 Website'
          >>> url = 'http://dev.zope.org/Zope3'
        
        Now we, get the fields from the interface:
        
          >>> title_field = IBookmark.get('title')
          >>> url_field = IBookmark.get('url')
        
        Next we have to bind these fields to the context, so that instance-specific
        information can be used for validation:
        
          >>> title_bound = title_field.bind(bm)
          >>> url_bound = url_field.bind(bm)
        
        Now that the fields are bound, we can finally validate the data:
        
          >>> title_bound.validate(title)
          >>> url_bound.validate(url)
        
        If the validation is successful, ``None`` is returned. If a validation error
        occurs a ``ValidationError`` will be raised; for example:
        
          >>> url_bound.validate(u'http://zope.org/foo')
          Traceback (most recent call last):
          ...
          WrongType: (u'http://zope.org/foo', <type 'str'>, 'url')
        
          >>> url_bound.validate('foo.bar')
          Traceback (most recent call last):
          ...
          InvalidURI: foo.bar
        
        Now that the data has been successfully validated, we can set it on the
        object:
        
          >>> title_bound.set(bm, title)
          >>> url_bound.set(bm, url)
        
        That's it. You still might think this is a lot of work to validate and set a
        value for an object. Note, however, that it is very easy to write helper
        functions that automate these tasks. If correctly designed, you will never
        have to worry explicitly about validation again, since the system takes care
        of it automatically.
        
        
        What is a schema, how does it compare to an interface?
        ------------------------------------------------------
        
        A schema is an extended interface which defines fields.  You can validate that
        the attributes of an object conform to their fields defined on the schema.
        With plain interfaces you can only validate that methods conform to their
        interface specification.
        
        So interfaces and schemas refer to different aspects of an object
        (respectively its code and state).
        
        A schema starts out like an interface but defines certain fields to
        which an object's attributes must conform.  Let's look at a stripped
        down example from the programmer's tutorial:
        
            >>> import re
        
            >>> class IContact(zope.interface.Interface):
            ...     """Provides access to basic contact information."""
            ...
            ...     first = zope.schema.TextLine(title=u"First name")
            ...
            ...     last = zope.schema.TextLine(title=u"Last name")
            ...
            ...     email = zope.schema.TextLine(title=u"Electronic mail address")
            ...
            ...     address = zope.schema.Text(title=u"Postal address")
            ...
            ...     postalCode = zope.schema.TextLine(
            ...         title=u"Postal code",
            ...         constraint=re.compile("\d{5,5}(-\d{4,4})?$").match)
        
        ``TextLine`` is a field and expresses that an attribute is a single line
        of Unicode text.  ``Text`` expresses an arbitrary Unicode ("text")
        object.  The most interesting part is the last attribute
        specification.  It constrains the ``postalCode`` attribute to only have
        values that are US postal codes.
        
        Now we want a class that adheres to the ``IContact`` schema:
        
            >>> class Contact(object):
            ...     zope.interface.implements(IContact)
            ...
            ...     def __init__(self, first, last, email, address, pc):
            ...         self.first = first
            ...         self.last = last
            ...         self.email = email
            ...         self.address = address
            ...         self.postalCode = pc
        
        Now you can see if an instance of ``Contact`` actually implements the
        schema:
        
            >>> someone = Contact(u'Tim', u'Roberts', u'tim@roberts', u'',
            ...                   u'12032-3492')
        
            >>> for field in zope.schema.getFields(IContact).values():
            ...     bound = field.bind(someone)
            ...     bound.validate(bound.get(someone))
        
        
        Data Modeling Concepts
        -----------------------
        
        The ``zope.schema`` package provides a core set of field types,
        including single- and multi-line text fields, binary data fields,
        integers, floating-point numbers, and date/time values.
        
        Selection issues; field type can specify:
        
        - "Raw" data value
        
          Simple values not constrained by a selection list.
        
        - Value from enumeration (options provided by schema)
        
          This models a single selection from a list of possible values
          specified by the schema.  The selection list is expected to be the
          same for all values of the type.  Changes to the list are driven by
          schema evolution.
        
          This is done by mixing-in the ``IEnumerated`` interface into the field
          type, and the Enumerated mix-in for the implementation (or emulating
          it in a concrete class).
        
        - Value from selection list (options provided by an object)
        
          This models a single selection from a list of possible values
          specified by a source outside the schema.  The selection list
          depends entirely on the source of the list, and may vary over time
          and from object to object.  Changes to the list are not related to
          the schema, but changing how the list is determined is based on
          schema evolution.
        
          There is not currently a spelling of this, but it could be
          facilitated using alternate mix-ins similar to IEnumerated and
          Enumerated.
        
        - Whether or not the field is read-only
        
          If a field value is read-only, it cannot be changed once the object is
          created.
        
        - Whether or not the field is required
        
          If a field is designated as required, assigned field values must always
          be non-missing. See the next section for a description of missing values.
        
        - A value designated as ``missing``
        
          Missing values, when assigned to an object, indicate that there is 'no
          data' for that field. Missing values are analogous to null values in
          relational databases. For example, a boolean value can be True, False, or
          missing, in which case its value is unknown.
        
          While Python's None is the most likely value to signify 'missing', some
          fields may use different values. For example, it is common for text fields
          to use the empty string ('') to signify that a value is missing. Numeric
          fields may use 0 or -1 instead of None as their missing value.
        
          A field that is 'required' signifies that missing values are invalid and
          should not be assigned.
        
        - A default value
        
          Default field values are assigned to objects when they are first created.
        
        
        Fields and Widgets
        ------------------
        
        Widgets are components that display field values and, in the case of
        writable fields, allow the user to edit those values.
        
        Widgets:
        
        - Display current field values, either in a read-only format, or in a
          format that lets the user change the field value.
        
        - Update their corresponding field values based on values provided by users.
        
        - Manage the relationships between their representation of a field value
          and the object's field value. For example, a widget responsible for
          editing a number will likely represent that number internally as a string.
          For this reason, widgets must be able to convert between the two value
          formats. In the case of the number-editing widget, string values typed
          by the user need to be converted to numbers such as int or float.
        
        - Support the ability to assign a missing value to a field. For example,
          a widget may present a ``None`` option for selection that, when selected,
          indicates that the object should be updated with the field's ``missing``
          value.
        
        
        
        References
        ----------
        
        - Use case list, http://dev.zope.org/Zope3/Zope3SchemasUseCases
        
        - Documented interfaces, zope/schema/interfaces.py
        
        - Jim Fulton's Programmers Tutorial; in CVS:
          Docs/ZopeComponentArchitecture/PythonProgrammerTutorial/Chapter2
        
        
        ======
        Fields
        ======
        
        This document highlights unusual and subtle aspects of various fields and
        field classes, and is not intended to be a general introduction to schema
        fields.  Please see README.txt for a more general introduction.
        
        While many field types, such as Int, TextLine, Text, and Bool are relatively
        straightforward, a few have some subtlety.  We will explore the general
        class of collections and discuss how to create a custom creation field; discuss
        Choice fields, vocabularies, and their use with collections; and close with a
        look at the standard zope.app approach to using these fields to find views
        ("widgets").
        
        Collections
        -----------
        
        Normal fields typically describe the API of the attribute -- does it behave as a
        Python Int, or a Float, or a Bool -- and various constraints to the model, such
        as a maximum or minimum value.  Collection fields have additional requirements
        because they contain other types, which may also be described and constrained.
        
        For instance, imagine a list that contains non-negative floats and enforces
        uniqueness. In a schema, this might be written as follows:
        
          >>> from zope.interface import Interface
          >>> from zope.schema import List, Float
          >>> class IInventoryItem(Interface):
          ...     pricePoints = List(
          ...         title=u"Price Points",
          ...         unique=True,
          ...         value_type=Float(title=u"Price", min=0.0)
          ...     )
        
        This indicates several things.
        
        - pricePoints is an attribute of objects that implement IInventoryItem.
        - The contents of pricePoints can be accessed and manipulated via a Python list
          API.
        - Each member of pricePoints must be a non-negative float.
        - Members cannot be duplicated within pricePoints: each must be must be unique.
        - The attribute and its contents have descriptive titles.  Typically these
          would be message ids.
        
        This declaration creates a field that implements a number of interfaces, among
        them these:
        
          >>> from zope.schema.interfaces import IList, ISequence, ICollection
          >>> IList.providedBy(IInventoryItem['pricePoints'])
          True
          >>> ISequence.providedBy(IInventoryItem['pricePoints'])
          True
          >>> ICollection.providedBy(IInventoryItem['pricePoints'])
          True
        
        Creating a custom collection field
        ----------------------------------
        
        Ideally, custom collection fields have interfaces that inherit appropriately
        from either zope.schema.interfaces.ISequence or
        zope.schema.interfaces.IUnorderedCollection.  Most collection fields should be
        able to subclass zope.schema._field.AbstractCollection to get the necessary
        behavior.  Notice the behavior of the Set field in zope.schema._field: this
        would also be necessary to implement a Bag.
        
        Choices and Vocabularies
        ------------------------
        
        Choice fields are the schema way of spelling enumerated fields and more.  By
        providing a dynamically generated vocabulary, the choices available to a
        choice field can be contextually calculated.  
        
        Simple choices do not have to explicitly use vocabularies:
        
          >>> from zope.schema import Choice
          >>> f = Choice((640, 1028, 1600))
          >>> f.validate(640)
          >>> f.validate(960)
          Traceback (most recent call last):
          ...
          ConstraintNotSatisfied: 960
          >>> f.validate('bing')
          Traceback (most recent call last):
          ...
          ConstraintNotSatisfied: bing
        
        More complex choices will want to use registered vocabularies.  Vocabularies
        have a simple interface, as defined in
        zope.schema.interfaces.IBaseVocabulary.  A vocabulary must minimally be able
        to determine whether it contains a value, to create a term object for a value,
        and to return a query interface (or None) to find items in itself.  Term
        objects are an abstraction that wraps a vocabulary value.  
        
        The Zope application server typically needs a fuller interface that provides
        "tokens" on its terms: ASCII values that have a one-to-one relationship to the
        values when the vocabulary is asked to "getTermByToken".  If a vocabulary is
        small, it can also support the IIterableVocabulary interface.
        
        If a vocabulary has been registered, then the choice merely needs to pass the
        vocabulary identifier to the "vocabulary" argument of the choice during
        instantiation.
        
        A start to a vocabulary implementation that may do all you need for many simple
        tasks may be found in zope.schema.vocabulary.SimpleVocabulary.  Because
        registered vocabularies are simply callables passed a context, many
        registered vocabularies can simply be functions that rely on SimpleVocabulary:
        
          >>> from zope.schema.vocabulary import SimpleVocabulary
          >>> def myDynamicVocabulary(context):
          ...     v = dynamic_context_calculation_that_returns_an_iterable(context)
          ...     return SimpleVocabulary.fromValues(v)
          ... 
        
        The vocabulary interface is simple enough that writing a custom vocabulary is
        not too difficult itself.
        
        Choices and Collections
        -----------------------
        
        Choices are a field type and can be used as a value_type for collections.  Just
        as a collection of an "Int" value_type constrains members to integers, so a
        choice-based value type constrains members to choices within the Choice's
        vocabulary.  Typically in the Zope application server widgets are found not
        only for the collection and the choice field but also for the vocabulary on
        which the choice is based.
        
        Using Choice and Collection Fields within a Widget Framework
        ------------------------------------------------------------
        
        While fields support several use cases, including code documentation and data
        description and even casting, a significant use case influencing their design is
        to support form generation -- generating widgets for a field.  Choice and
        collection fields are expected to be used within widget frameworks.  The
        zope.app approach typically (but configurably) uses multiple dispatches to 
        find widgets on the basis of various aspects of the fields.
        
        Widgets for all fields are found by looking up a browser view of the field
        providing an input or display widget view.  Typically there is only a single
        "widget" registered for Choice fields.  When it is looked up, it performs
        another dispatch -- another lookup -- for a widget registered for both the field
        and the vocabulary.  This widget typically has enough information to render
        without a third dispatch.
        
        Collection fields may fire several dispatches.  The first is the usual lookup
        by field.  A single "widget" should be registered for ICollection, which does
        a second lookup by field and value_type constraint, if any, or, theoretically,
        if value_type is None, renders some absolutely generic collection widget that
        allows input of any value imaginable: a check-in of such a widget would be
        unexpected.  This second lookup may find a widget that knows how to render,
        and stop.  However, the value_type may be a choice, which will usually fire a
        third dispatch: a search for a browser widget for the collection field, the
        value_type field, and the vocabulary.  Further lookups may even be configured
        on the basis of uniqueness and other constraints.
        
        This level of indirection may be unnecessary for some applications, and can be
        disabled with simple ZCML changes within `zope.app`.
        
        
        =======
        Sources
        =======
        
        Concepts
        --------
        
        Sources are designed with three concepts:
        
        - The source itself - an iterable
        
          This can return any kind of object it wants. It doesn't have to care
          for browser representation, encoding, ...
        
        - A way to map a value from the iterable to something that can be used
          for form *values* - this is called a token. A token is commonly a
          (unique) 7bit representation of the value.
        
        - A way to map a value to something that can be displayed to the user -
          this is called a title
        
        The last two elements are dispatched using a so called `term`. The
        ITitledTokenizedTerm interface contains a triple of (value, token, title).
        
        Additionally there are some lookup functions to perform the mapping
        between values and terms and tokens and terms.
        
        Sources that require context use a special factory: a context source
        binder that is called with the context and instanciates the source when
        it is actually used.
        
        Sources in Fields
        -----------------
        
        A choice field can be constructed with a source or source name.  When a source
        is used, it will be used as the source for valid values.
        
        Create a source for all odd numbers.
        
            >>> from zope import interface
            >>> from zope.schema.interfaces import ISource, IContextSourceBinder
            >>> class MySource(object):
            ...     interface.implements(ISource)
            ...     divisor = 2
            ...     def __contains__(self, value):
            ...         return bool(value % self.divisor)
            >>> my_source = MySource()
            >>> 1 in my_source
            True
            >>> 2 in my_source
            False
        
            >>> from zope.schema import Choice
            >>> choice = Choice(__name__='number', source=my_source)
            >>> bound = choice.bind(object())
            >>> bound.vocabulary
            <...MySource...>
        
        If a IContextSourceBinder is passed as the `source` argument to Choice, it's
        `bind` method will be called with the context as its only argument.   The
        result must implement ISource and will be used as the source.
        
            >>> def my_binder(context):
            ...     print "Binder was called."
            ...     source = MySource()
            ...     source.divisor = context.divisor
            ...     return source
            >>> interface.directlyProvides(my_binder, IContextSourceBinder)
        
            >>> class Context(object):
            ...     divisor = 3
        
            >>> choice = Choice(__name__='number', source=my_binder)
            >>> bound = choice.bind(Context())
            Binder was called.
            >>> bound.vocabulary
            <...MySource...>
            >>> bound.vocabulary.divisor
            3
        
        When using IContextSourceBinder together with default value, it's
        impossible to validate it on field initialization. Let's check if
        initalization doesn't fail in that case.
        
            >>> choice = Choice(__name__='number', source=my_binder, default=2)
        
            >>> bound = choice.bind(Context())
            Binder was called.
        
            >>> bound.validate(bound.default)
            >>> bound.validate(3)
            Traceback (most recent call last):
            ...
            ConstraintNotSatisfied: 3
        
        It's developer's responsibility to provide a default value that fits the
        constraints when using context-based sources.
        
        
        =================
        Schema Validation
        =================
        
        There are two helper methods to verify schemas and interfaces:
        
        getValidationErrors
            first validates via the zope.schema field validators. If that succeeds the
            invariants are checked.
        getSchemaValidationErrors
            *only* validateds via the zope.schema field validators. The invariants are
            *not* checked.
        
        
        Create an interface to validate against:
        
          >>> import zope.interface
          >>> import zope.schema
          >>> class ITwoInts(zope.interface.Interface):
          ...     a = zope.schema.Int(max=10)
          ...     b = zope.schema.Int(min=5)
          ...
          ...     @zope.interface.invariant
          ...     def a_greater_b(obj):
          ...         print "Checking if a > b"
          ...         if obj.a <= obj.b:
          ...             raise zope.interface.Invalid("%s<=%s" % (obj.a, obj.b))
          ...     
        
        Create a silly model:
        
          >>> class TwoInts(object):
          ...     pass
        
        Create an instance of TwoInts but do not set attributes. We get two errors:
        
          >>> ti = TwoInts()
          >>> r = zope.schema.getValidationErrors(ITwoInts, ti)
          >>> r.sort()
          >>> r
          [('a', SchemaNotFullyImplemented(...AttributeError...)),
           ('b', SchemaNotFullyImplemented(...AttributeError...))]
          >>> r[0][1].args[0].args
          ("'TwoInts' object has no attribute 'a'",)
          >>> r[1][1].args[0].args
          ("'TwoInts' object has no attribute 'b'",)
        
        The `getSchemaValidationErrors` function returns the same result:
        
          >>> r = zope.schema.getSchemaValidationErrors(ITwoInts, ti)
          >>> r.sort()
          >>> r
          [('a', SchemaNotFullyImplemented(...AttributeError...)),
           ('b', SchemaNotFullyImplemented(...AttributeError...))]
          >>> r[0][1].args[0].args
          ("'TwoInts' object has no attribute 'a'",)
          >>> r[1][1].args[0].args
          ("'TwoInts' object has no attribute 'b'",)
         
        Note that see no error from the invariant because the invariants are not
        vaildated if there are other schema errors.
        
        When we set a valid value for `a` we still get the same error for `b`:
        
          >>> ti.a = 11
          >>> errors = zope.schema.getValidationErrors(ITwoInts, ti)
          >>> errors.sort()
          >>> errors
          [('a', TooBig(11, 10)),
           ('b', SchemaNotFullyImplemented(...AttributeError...))]
          >>> errors[1][1].args[0].args
          ("'TwoInts' object has no attribute 'b'",)
        
          >>> errors[0][1].doc()
          u'Value is too big'
        
        
        After setting a valid value for `a` there is only the error for the missing `b`
        left:
        
          >>> ti.a = 8
          >>> r = zope.schema.getValidationErrors(ITwoInts, ti)
          >>> r
          [('b', SchemaNotFullyImplemented(...AttributeError...))]
          >>> r[0][1].args[0].args
          ("'TwoInts' object has no attribute 'b'",)
        
        
        After setting valid value for `b` the schema is valid so the invariants are
        checked. As `b>a` the invariant fails:
        
          >>> ti.b = 10
          >>> errors = zope.schema.getValidationErrors(ITwoInts, ti)
          Checking if a > b
          >>> errors
          [(None, <zope.interface.exceptions.Invalid instance at 0x...>)]
        
        
        When using `getSchemaValidationErrors` we do not get an error any more:
        
          >>> zope.schema.getSchemaValidationErrors(ITwoInts, ti)
          []
        
        
        Set `b=5` so everything is fine:
        
          >>> ti.b = 5
          >>> zope.schema.getValidationErrors(ITwoInts, ti)
          Checking if a > b
          []
        
        
        Compare ValidationError
        -----------------------
        
        There was an issue with compare validation error with somthing else then an
        exceptions. Let's test if we can compare ValidationErrors with different things
        
          >>> from zope.schema._bootstrapinterfaces import ValidationError
          >>> v1 = ValidationError('one')
          >>> v2 = ValidationError('one')
          >>> v3 = ValidationError('another one')
        
        A ValidationError with the same arguments compares:
        
          >>> v1 == v2
          True
        
        but not with an error with different arguments:
        
          >>> v1 == v3
          False
        
        We can also compare validation erros with other things then errors. This 
        was running into an AttributeError in previous versions of zope.schema. e.g.
        AttributeError: 'NoneType' object has no attribute 'args'
        
          >>> v1 == None
          False
        
          >>> v1 == object()
          False
        
          >>> v1 == False
          False
        
          >>> v1 == True
          False
        
          >>> v1 == 0
          False
        
          >>> v1 == 1
          False
        
          >>> v1 == int
          False
        
        If we compare a ValidationError with another validation error based class,
        we will get the following result:
        
          >>> from zope.schema._bootstrapinterfaces import RequiredMissing
          >>> r1 = RequiredMissing('one')
          >>> v1 == r1
          True
        
        
        =======
        CHANGES
        =======
        
        3.7.1 (2010-12-25)
        ------------------
        
        - The validation token, used in the validation of schema with Object
          Field to avoid infinite recursion, has been renamed.
          ``__schema_being_validated`` became ``_v_schema_being_validated``,
          a volatile attribute, to avoid persistency and therefore,
          read/write conflicts.
        
        - Don't allow "[\]^`" in DottedName.
          https://bugs.launchpad.net/zope.schema/+bug/191236
        
        3.7.0 (2010-09-12)
        ------------------
        
        - Improve error messages when term tokens or values are duplicates.
        
        - Fix the buildout so the tests run.
        
        3.6.4 (2010-06-08)
        ------------------
        
        - fix validation of schema with Object Field that specify Interface schema.
        
        3.6.3 (2010-04-30)
        ------------------
        
        - Prefer the standard libraries doctest module to the one from zope.testing.
        
        3.6.2 (2010-04-30)
        ------------------
        
        - Avoid maximum recursion when validating Object field that points to cycles
        
        - Made the dependency on ``zope.i18nmessageid`` optional.
        
        3.6.1 (2010-01-05)
        ------------------
        
        - Allow "setup.py test" to run at least a subset of the tests runnable
          via ``bin/test`` (227 for ``setup.py test`` vs. 258. for
          ``bin/test``)
        
        - Make ``zope.schema._bootstrapfields.ValidatedProperty`` descriptor
          work under Jython.
        
        - Make "setup.py test" tests pass on Jython.
        
        3.6.0 (2009-12-22)
        ------------------
        
        - Prefer zope.testing.doctest over doctestunit.
        
        - Extend validation error to hold the field name.
        
        - Add FieldProperty class that uses Field.get and Field.set methods 
          instead of storing directly on the instance __dict__.
        
        3.5.4 (2009-03-25)
        ------------------
        
        - Don't fail trying to validate default value for Choice fields with
          IContextSourceBinder object given as a source. See
          https://bugs.launchpad.net/zope3/+bug/340416. 
        
        - Add an interface for ``DottedName`` field.
        
        - Add ``vocabularyName`` attribute to the ``IChoice`` interface, change
          "vocabulary" attribute description to be more sensible, making it
          ``zope.schema.Field`` instead of plain ``zope.interface.Attribute``.
        
        - Make IBool interface of Bool more important than IFromUnicode so adapters
          registered for IBool take precendence over adapters registered for
          IFromUnicode.
        
        
        3.5.3 (2009-03-10)
        ------------------
        
        - Make Choice and Bool fields implement IFromUnicode interface, because
          they do provide the ``fromUnicode`` method.
        
        - Change package's mailing list address to zope-dev at zope.org, as
          zope3-dev at zope.org is now retired.
        
        - Fix package's documentation formatting. Change package's description.
        
        - Add buildout part that builds Sphinx-generated documentation.
        
        - Remove zpkg-related file.
        
        3.5.2 (2009-02-04)
        ------------------
        
        - Made validation tests compatible with Python 2.5 again (hopefully not
          breaking Python 2.4)
        
        - Added an __all__ package attribute to expose documentation.
        
        3.5.1 (2009-01-31)
        ------------------
        
        - Stop using the old old set type.
        
        - Make tests compatible and silent with Python 2.4.
        
        - Fix __cmp__ method in ValidationError. Show some side effects based on the
          existing __cmp__ implementation. See validation.txt
        
        - Make 'repr' of the ValidationError and its subclasses more sensible. This
          may require you to adapt your doctests for the new style, but now it makes
          much more sense for debugging for developers.
        
        3.5.0a2 (2008-12-11)
        --------------------
        
        - Move zope.testing to "test" extras_require, as it is not needed
          for zope.schema itself.
        
        - Change the order of classes in SET_TYPES tuple, introduced in
          previous release to one that was in 3.4 (SetType, set), because
          third-party code could be dependent on that order. The one
          example is z3c.form's converter.
        
        3.5.0a1 (2008-10-10)
        --------------------
        
        - Added the doctests to the long description.
        
        - Removed use of deprecated 'sets' module when running under Python 2.6.
        
        - Removed spurious doctest failure when running under Python 2.6.
        
        - Added support to bootstrap on Jython.
        
        - Added helper methods for schema validation: ``getValidationErrors``
          and ``getSchemaValidationErrors``.
        
        - zope.schema now works on Python2.5
        
        3.4.0 (2007-09-28)
        ------------------
        
        Added BeforeObjectAssignedEvent that is triggered before the object
        field sets a value.
        
        3.3.0 (2007-03-15)
        ------------------
        
        Corresponds to the version of the zope.schema package shipped as part of
        the Zope 3.3.0 release.
        
        3.2.1 (2006-03-26)
        ------------------
        
        Corresponds to the version of the zope.schema package shipped as part of
        the Zope 3.2.1 release.
        
        Fixed missing import of 'VocabularyRegistryError'.  See
        http://www.zope.org/Collectors/Zope3-dev/544 .
        
        3.2.0 (2006-01-05)
        ------------------
        
        Corresponds to the version of the zope.schema package shipped as part of
        the Zope 3.2.0 release.
        
        Added "iterable" sources to replace vocabularies, which are now deprecated
        and scheduled for removal in Zope 3.3.
        
        3.1.0 (2005-10-03)
        ------------------
        
        Corresponds to the version of the zope.schema package shipped as part of
        the Zope 3.1.0 release.
        
        Allowed 'Choice' fields to take either a 'vocabulary' or a 'source'
        argument (sources are a simpler implementation).
        
        Added 'TimeDelta' and 'ASCIILine' field types.
        
        3.0.0 (2004-11-07)
        ------------------
        
        Corresponds to the version of the zope.schema package shipped as part of
        the Zope X3.0.0 release.
        
Platform: UNKNOWN