On 28/11/2010 17:05, Michael Foord wrote:
[snip...]
It is sensible if flag values are only powers of 2; we could enforce
that or not... (Another one for the optional feature list.)
Another 'optional' feature I omitted was Phillip J. Eby's suggestion /
requirement that named values be pickleable. Email is clunky for
handling this, is there enough support (there is still some objection
that is sure) to revive the PEP or create a new one?
I also didn't include Nick's suggested API, which is slightly different
from the one I suggested:
silly = Namegroup.from_names("Silly", "FOO", "BAR", "BAZ")
>>> silly.FOO
Silly.FOO=0
>>> int(silly.FOO)
0
>>> silly(0)
Silly.FOO=0
x = named_value("FOO", 1)
y = named_value("BAR", "Hello World!")
z = named_value("BAZ", dict(a=1, b=2, c=3))
set_named_values(globals(), foo=x._raw(), bar=y._raw(), baz=z._raw())
Where a named value created from an integer is an int subclass, from a
dict a dict subclass and so on.
Michael
I forgot auto-enumeration (specifying names only and having values
autogenerated) from the optional feature set by the way. I think
Antoine strongly disapproves of this feature because it reminds him of
C enums.
Mark Dickinson thinks that the flags feature could be an optional
feature too. If we have ORing it makes sense to have ANDing, so I
guess they belong together. I think there is value in it though.
I realise that the optional feature list is now not small, and
implementing all of it would create the "franken-api" Nick is worried
about. The minimal feature list is nicely small though and provides
useful functionality.
All the best,
Michael
Grouped constants
----------------
* Easy to create a group of named constants, accessible as attributes
on group object
* Capability to go from name or value to corresponding constants
Optional Features
---------------
* Ability to dynamically add new named values to a group. (Suggested
by Guido)
* Ability to test if a name or value is in a group
* Ability to list all names in a group
* ANDing as well as ORing
* Constants are unique
* OR'ing with an integer will look up the name (or calculate it if
the int itself represents flags that have already been OR'd) and
return a named value (with useful repr) instead of just an integer
* Named constants be named values that can wrap *any* type and not
just immutable values. (Note that wrapping mutable types makes
providing "from_value" functionality harder *unless* we guarantee
that named values are unique. If they aren't unique named values for
a mutable type can have different values and there is no single
definition of what the named value actually is.)
Requiring that values only have one name - or alternatively that
values on a group could have multiple names (obviously incompatible
features).
* Requiring all names in a group to be of the same type
* Allow names to be set automatically in a namespace, for example in
a class namespace or on a module
* Allow subclassing and adding of new values only present in subclass
I'd rather we agree a suitable (minimal) API and feature set and go
to implementation from that.
For wrapping mutable types I'm tempted to say YAGNI. For the standard
library wrapping integers meets almost all our use-cases except for
one float. (At work we have a decimal constant as it happens.)
Perhaps we could require immutable types for groups but allow
arbitrary values for individual named values?
For the named values api:
name = NamedValue('name', value)
For the grouping (tentatively accepted as reasonable by Antoine):
Group = make_constants('Group', name1=value1, name2=value2)
name1, name2 = Group.name1, Group.name1
flag = name1 | name2
value = int(Group.name1)
name = Group('name1')
# alternatively: value = Group.from_name('name1')
name = Group.from_value(value1)
# Group(value1) could work only if values aren't strings
# perhaps: name = Group(value=value1)
Group.new_name = value3 # create new value on the group
names = Group.all_names()
# further bikeshedding on spelling of all_names required
# correspondingly 'all_values' I guess, returning the constants
themselves
Some of the optional features couldn't later be added without
backwards compatibility concerns (I think the type checking features
and requiring unique values for example). We should at least consider
these if we are to make adding them later difficult. I would be fine
with not having these features.
All the best,
Michael
Cheers,
Nick.
--
http://www.voidspace.org.uk/
READ CAREFULLY. By accepting and reading this email you agree,
on behalf of your employer, to release me from all obligations
and waivers arising from any and all NON-NEGOTIATED agreements,
licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap,
confidentiality, non-disclosure, non-compete and acceptable use
policies (”BOGUS AGREEMENTS”) that I have entered into with your
employer, its partners, licensors, agents and assigns, in
perpetuity, without prejudice to my ongoing rights and privileges.
You further represent that you have the authority to release me
from any BOGUS AGREEMENTS on behalf of your employer.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
