Re: [Python-Dev] PEP 435: pickling enums created with the functional API
On 9 May 2013 13:48, "Eli Bendersky" wrote:
>
>
>
>
> On Tue, May 7, 2013 at 8:03 AM, Nick Coghlan wrote:
>>
>> On Tue, May 7, 2013 at 11:34 PM, Eli Bendersky wrote:
>> > One of the contended issues with PEP 435 on which Guido pronounced was
the
>> > functional API, that allows created enumerations dynamically in a
manner
>> > similar to namedtuple:
>> >
>> > Color = Enum('Color', 'red blue green')
>> >
>> > The biggest complaint reported against this API is interaction with
pickle.
>> > As promised, I want to discuss here how we're going to address this
concern.
>> >
>> > At this point, the pickle docs say that module-top-level classes can be
>> > pickled. This obviously works for the normal Enum classes, but is a
problem
>> > with the functional API because the class is created dynamically and
has no
>> > __module__.
>> >
>> > To solve this, the reference implementation is used the same approach
as
>> > namedtuple (*). In the metaclass's __new__ (this is an excerpt, the
real
>> > code has some safeguards):
>> >
>> > module_name = sys._getframe(1).f_globals['__name__']
>> > enum_class.__module__ = module_name
>> >
>> > According to an earlier discussion, this is works on CPython, PyPy and
>> > Jython, but not on IronPython. The alternative that works everywhere
is to
>> > define the Enum like this:
>> >
>> > Color = Enum('the_module.Color', 'red blue green')
>> >
>> > The reference implementation supports this as well.
>> >
>> > Some points for discussion:
>> >
>> > 1) We can say that using the functional API when pickling can happen
is not
>> > recommended, but maybe a better way would be to just explain the way
things
>> > are and let users decide?
>>
>> It's probably worth creating a section in the pickle docs and
>> explaining the vagaries of naming things and the dependency on knowing
>> the module name. The issue comes up with defining classes in __main__
>> and when implementing pseudo-modules as well (see PEP 395).
>>
>> > 2) namedtuple should also support the fully qualified name syntax. If
this
>> > is agreed upon, I can create an issue.
>>
>> Yes, I think that part should be done.
>>
>
> http://bugs.python.org/issue17941
As Eric noted on the tracker issue, a keyword only "module" argument may be
a better choice for both than allowing dotted names. A separate parameter
is easier to use with __name__ to avoid hardcoding the module name.
At the very least, the PEP should provide a rationale for the current
choice.
Cheers,
Nick.
>
> Eli
>
>
___
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
Re: [Python-Dev] PEP 435: pickling enums created with the functional API
On Thu, May 9, 2013 at 7:17 AM, Nick Coghlan wrote: > As Eric noted on the tracker issue, a keyword only "module" argument may > be a better choice for both than allowing dotted names. A separate > parameter is easier to use with __name__ to avoid hardcoding the module > name. +1. This is a good one. While adding module=__name__ is actually more typing than passing __name__ + '.Color' as the class name, the current proposal (parsing for dots) makes it very attractive to do the wrong thing and hardcode the module name. Then typing the module incorrectly is very easy, and the mistake is easily overlooked because it won't be noticed until you actually try to pickle a member. At the very least, the PEP should provide a rationale for the current > choice. > > Cheers, > Nick. > > > > > Eli > > > > > > ___ > 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/guido%40python.org > > -- --Guido van Rossum (python.org/~guido) ___ 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
Re: [Python-Dev] PEP 435: pickling enums created with the functional API
On May 09, 2013, at 09:24 AM, Guido van Rossum wrote: >+1. This is a good one. While adding module=__name__ is actually more >typing than passing __name__ + '.Color' as the class name, the current >proposal (parsing for dots) makes it very attractive to do the wrong thing >and hardcode the module name. Then typing the module incorrectly is very >easy, and the mistake is easily overlooked because it won't be noticed >until you actually try to pickle a member. Seems reasonable. The `module` argument should be keyword-only, and obviously namedtuple should support the same API. -Barry ___ 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
Re: [Python-Dev] PEP 435: pickling enums created with the functional API
On Thu, May 9, 2013 at 9:31 AM, Barry Warsaw wrote: > On May 09, 2013, at 09:24 AM, Guido van Rossum wrote: > > >+1. This is a good one. While adding module=__name__ is actually more > >typing than passing __name__ + '.Color' as the class name, the current > >proposal (parsing for dots) makes it very attractive to do the wrong thing > >and hardcode the module name. Then typing the module incorrectly is very > >easy, and the mistake is easily overlooked because it won't be noticed > >until you actually try to pickle a member. > > Seems reasonable. The `module` argument should be keyword-only, and > obviously > namedtuple should support the same API. > Yes, this was already pointed out by Eric in http://bugs.python.org/issue17941 which tracks this feature for namedtuple. Eli ___ 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
[Python-Dev] I want contribute to the project
Hi guys, I have 3 computer and want to contribute to the project, Windows 7, Interl I5 64bits Ubuntu 13.04, Interl I5 32bits Ubuntu 13.04, Interl I5 64bits How i can proceed? I'm nice in this world of free software and python best regards Diego Tolentino SENIOR DEVELOPER Skype: diegotolentino “Do not go where the path may lead, go instead where there is no path and leave a trail.” - Ralph Waldo Emerson ___ 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
Re: [Python-Dev] I want contribute to the project
On Thu, May 9, 2013 at 12:58 PM, Diego Tolentino wrote: > Hi guys, > > I have 3 computer and want to contribute to the project, > > Windows 7, Interl I5 64bits > Ubuntu 13.04, Interl I5 32bits > Ubuntu 13.04, Interl I5 64bits > > How i can proceed? I'm nice in this world of free software and python > > Hi Diego, Welcome! The best way to get started is to read this short page - http://pythonmentors.com/, subscribe to the mentorship mailing list it mentions, and then go over the (not-so-short, but very useful) developers' guide it links to. Good luck, Eli ___ 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
[Python-Dev] PEP 435 (Enums) is Accepted
I have reviewed the latest version of PEP 435 and I see that it is very good. I hereby declare PEP 435 as Accepted. Congratulations go to Barry, Eli and Ethan for pulling it through one of the most thorough reviewing and bikeshedding processes any PEP has seen. Thanks to everyone else for the many review comments. It is a better PEP because of the reviews. Barry or Eli, you can update the PEP's status. (I also expect there will be some copy-editing still.) Ethan: the stdlib implementation should probably be assigned a bug tracker issue (if there isn't one already) and start code review now. -- --Guido van Rossum (python.org/~guido) ___ 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
[Python-Dev] Help requested for issue 9285 (profile.py)
http://bugs.python.org/issue9285#msg182986 I'm stuck as I really have no clue what that error means. Any help from someone experienced with profile.py code is welcome. --- Giampaolo https://code.google.com/p/pyftpdlib/ https://code.google.com/p/psutil/ https://code.google.com/p/pysendfile/ ___ 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
Re: [Python-Dev] PEP 435 (Enums) is Accepted
On May 09, 2013, at 04:01 PM, Guido van Rossum wrote: >I have reviewed the latest version of PEP 435 and I see that it is >very good. I hereby declare PEP 435 as Accepted. Congratulations go to >Barry, Eli and Ethan for pulling it through one of the most thorough >reviewing and bikeshedding processes any PEP has seen. Thanks to >everyone else for the many review comments. It is a better PEP because >of the reviews. Let me echo Guido's thanks to everyone on python-dev and python-ideas, and especially Eli and Ethan. Our ability to come together and produce agreement on not only a contentious, but long wished for, feature shows off the best of our community. Huge thanks also to Guido for the invaluable pronouncements along the way. I can honestly say I'm happy with the results, and the experience of participating. Great work everyone. -Barry signature.asc Description: PGP signature ___ 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
Re: [Python-Dev] PEP 435 (Enums) is Accepted
On Fri, May 10, 2013 at 9:01 AM, Guido van Rossum wrote: > I have reviewed the latest version of PEP 435 and I see that it is > very good. I hereby declare PEP 435 as Accepted. Congratulations go to > Barry, Eli and Ethan for pulling it through one of the most thorough > reviewing and bikeshedding processes any PEP has seen. Thanks to > everyone else for the many review comments. It is a better PEP because > of the reviews. And there was much rejoicing, huzzah! :) As an added bonus, people trying to understand the details of metaclasses will now have a non-trivial standard library example to investigate (we may want to update the language reference at some point to highlight that). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] PEP 435 (Enums) is Accepted
On 05/09/2013 11:46 PM, Nick Coghlan wrote: As an added bonus, people trying to understand the details of metaclasses will now have a non-trivial standard library example to investigate Hmmm... __prepare__ really isn't doing very much at the moment... I could have it do more... maybe create some kind of little helper class, name it the same as the class being created, and stuff it in the class dict... ;) -- ~Ethan~ ___ 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
