Comments (5)
I haven't given it any deep thoughts, but the current behavior seems reasonable to me.
from zope.schema.
I'll clarify that the possible motivation for this change comes from this comment, based on the old behaviour of hash(field)
that only accounted for object identity, not equality:
code that uses fields as dict keys may rely on mixing fields from different schemas that are not identical but compare as equal otherwise.
from zope.schema.
I think we should stick as close as possible to the old behaviour (pre Python 3) of zope.schema
as this will not break any code which is out there. Yes, this might hamper or even prevent other new uses, but I would value the existing code more than the one that might be written in future.
from zope.schema.
One way of looking at it is that including the interface in hashing is closer to what zope.schema used to do: hashing was identity based, so hash(IOne['one']) != hash(ITwo['two'])
(and hashing only worked on Python 2, so anyone relying on hashing could not port to Python 3). But now that hashing works on Python 3, and is consistent with equality, hash(IOne['one']) == hash(ITwo['two'])
. Previously on Python 2, a dict
could include both IOne['one']
and ITwo['two']
:
>>> d = {}
>>> d[IOne['one']] = 'one'
>>> d[ITwo['two']] = 'two'
>>> d
{<zope.schema._bootstrapfields.Int at 0x10fe64ed0>: 'one',
<zope.schema._bootstrapfields.Int at 0x10ffdb610>: 'two'}
Now it cannot:
>>> d = {}
>>> d[IOne['one']] = 'one'
>>> d[ITwo['two']] = 'two'
>>> d
{<zope.schema._bootstrapfields.Int at 0x10bc25d90>: 'two'}
Including the interface in equality and hashing would restore the ability to have both fields in a dict, while staying true to the language spec.
from zope.schema.
+1 to include the interface in the hash
computation. The current behaviour @jamadden has shown in the previous comment seems irritating to me. I'd never expect that two fields on different interfaces with different names are the same because they have the same configuration.
Fields almost always have a context (the interface) which makes them unequal because the interface becomes part of the field. They are the same as long as they are not part of an interface. At the moment a field becomes part of the interface it is no longer the same as a field on another interface or a field which is not part of an interface.
from zope.schema.
Related Issues (20)
- IFieldUpdatedEvent not correctly implemented by FieldUpdatedEvent.
- IField.required attribute is True but must not. HOT 19
- New Release HOT 2
- DeprecationWarnings with Python 3.11a1
- zope.schema.Bool violates it's interface spec
- Tests fail due to outsized integer test values
- Problem with doctests using zope.schema vocabulary HOT 2
- Required List accepts empty list HOT 3
- MessageID as description... HOT 2
- Exceptions could use some named attributes
- Checking constraints should set `field` and `value` for ValidationErrors
- When a field has no description (description=None) initialization fails HOT 1
- Make NativeString[Line] a distinct type
- `getDoc()` can produce invalid ReST when `value_type` is present
- Borked interface resolution order for boolean field HOT 6
- placeholder HOT 3
- Unicode normalization HOT 2
- IDecimal leaves min, max, default attributes with type Number
- #87 breaks persistent Text fields HOT 1
- Missing python_requires HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from zope.schema.