Re: [Python-Dev] enum discussion: can someone please summarize open issues?
On May 01, 2013, at 11:54 AM, Larry Hastings wrote: >On 04/30/2013 11:29 PM, Ethan Furman wrote: >> On 04/30/2013 11:18 PM, Barry Warsaw wrote: >>> On Apr 28, 2013, at 11:50 PM, Ethan Furman wrote: >>> But as soon as: type(Color.red) is Color # True type(MoreColor.red) is MoreColor # True then: Color.red is MoreColor.red # must be False, no? If that last statement can still be True, I'd love it if someone >>> showed me how. >>> >>> class Foo: >>> a = object() >>> b = object() >>> >>> class Bar(Foo): >>> c = object() >>> >> Foo.a is Bar.a >>> True >> >> Wow. I think I'm blushing from embarrassment. >> >> Thank you for answering my question, Barry. > >Wait, what? I don't see how Barry's code answers your question. In his >example, type(a) == type(b) == type(c) == object. You were asking "how can >Color.red and MoreColor.red be the same object if they are of different >types?" > >p.s. They can't. Sure, why not? In "normal" Python, Bar inherits a from Foo, it doesn't define it so it's exactly the same object. Thus if you access that object through the superclass, you get the same object as when you access it through the subclass. So Foo.a plays the role of Color.red and Bar.a plays the role of MoreColor.red. Same object, thus `Foo.a is Bar.a` is equivalent to `Color.red is MoreColor.red`. -Barry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
On May 02, 2013, at 11:44 AM, Greg Ewing wrote: >Barry Warsaw wrote: >> Why isn't getattr() for lookup by name >> good enough? > >Because it will find things that are not enum items, >e.g. '__str__'. Why does that matter? -Barry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enum: subclassing?
On May 01, 2013, at 11:04 AM, Eli Bendersky wrote: >Actually, in flufl.enum, IntEnum had to define a magic __value_factory__ >attribute, but in the current ref435 implementation this isn't needed, so >IntEnum is just: > >class IntEnum(int, Enum): >''' >Class where every instance is a subclass of int. >''' > >So why don't we just drop IntEnum from the API and tell users they should >do the above explicitly, i.e.: +1 -Barry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enum: subclassing?
On May 01, 2013, at 08:47 PM, Georg Brandl wrote: >Wait a moment... it might not be immediately useful for IntEnums (however, >that's because base Enum currently defines __int__ which I find questionable), And broken. And unnecessary. :) >>> class Foo(Enum): ... a = 'a' ... b = 'b' ... >>> int(Foo.a) Traceback (most recent call last): File "", line 1, in TypeError: __int__ returned non-int (type str) ...remove Enum.__int__()... >>> class Bar(int, Enum): ... a = 1 ... b = 2 ... >>> int(Bar.a) 1 So yes, Enum.__int__() should be removed. -Barry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
On 05/02/2013 07:57 AM, Barry Warsaw wrote: On May 01, 2013, at 11:54 AM, Larry Hastings wrote: On 04/30/2013 11:29 PM, Ethan Furman wrote: On 04/30/2013 11:18 PM, Barry Warsaw wrote: On Apr 28, 2013, at 11:50 PM, Ethan Furman wrote: But as soon as: type(Color.red) is Color # True type(MoreColor.red) is MoreColor # True then: Color.red is MoreColor.red # must be False, no? If that last statement can still be True, I'd love it if someone >>> showed me how. class Foo: a = object() b = object() class Bar(Foo): c = object() Foo.a is Bar.a True Wow. I think I'm blushing from embarrassment. Thank you for answering my question, Barry. Wait, what? I don't see how Barry's code answers your question. In his example, type(a) == type(b) == type(c) == object. You were asking "how can Color.red and MoreColor.red be the same object if they are of different types?" p.s. They can't. Sure, why not? In "normal" Python, Bar inherits a from Foo, it doesn't define it so it's exactly the same object. Thus if you access that object through the superclass, you get the same object as when you access it through the subclass. So Foo.a plays the role of Color.red and Bar.a plays the role of MoreColor.red. Same object, thus `Foo.a is Bar.a` is equivalent to `Color.red is MoreColor.red`. Same object, true, but my question was if `type(Bar.a) is Bar`, and in your reply `type(Bar.a) is object`. -- ~Ethan~ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
On 05/02/2013 07:57 AM, Barry Warsaw wrote: On May 01, 2013, at 11:54 AM, Larry Hastings wrote: On 04/30/2013 11:29 PM, Ethan Furman wrote: On 04/30/2013 11:18 PM, Barry Warsaw wrote: On Apr 28, 2013, at 11:50 PM, Ethan Furman wrote: But as soon as: type(Color.red) is Color # True type(MoreColor.red) is MoreColor # True then: Color.red is MoreColor.red # must be False, no? If that last statement can still be True, I'd love it if someone >>> showed me how. class Foo: a = object() b = object() class Bar(Foo): c = object() Foo.a is Bar.a True Wow. I think I'm blushing from embarrassment. Thank you for answering my question, Barry. Wait, what? I don't see how Barry's code answers your question. In his example, type(a) == type(b) == type(c) == object. You were asking "how can Color.red and MoreColor.red be the same object if they are of different types?" p.s. They can't. Sure, why not? In "normal" Python, Bar inherits a from Foo, it doesn't define it so it's exactly the same object. Thus if you access that object through the superclass, you get the same object as when you access it through the subclass. So Foo.a plays the role of Color.red and Bar.a plays the role of MoreColor.red. Same object, thus `Foo.a is Bar.a` is equivalent to `Color.red is MoreColor.red`. So you're saying Color.red and MoreColor.red are the same object. Which means they have the same type. But in Ethan's original example above, type(Color.red) == Color, and type(MoreColor.red) == MoreColor. Those are different types. So, for the second time: How can Color.red and MoreColor.red be the same object when they are of different types? p.s. They can't. //arry/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
On Thu, May 2, 2013 at 7:58 AM, Barry Warsaw wrote: > On May 02, 2013, at 11:44 AM, Greg Ewing wrote: > >>Barry Warsaw wrote: >>> Why isn't getattr() for lookup by name >>> good enough? >> >>Because it will find things that are not enum items, >>e.g. '__str__'. > > Why does that matter? I claim it doesn't. The name lookup is only relevant if you already know that you have a valid name of an enum in the class, e.g. if you know that a Color name was written earlier. If you don't, you should do some other check, e.g. "if x in Color:". (Note that from this you cannot derive that Color[x] should work.) -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enum: subclassing?
On May 01, 2013, at 03:11 PM, Ethan Furman wrote: >The reason __int__ is there is because pure Enums should be using plain ints >as their value 95% or more of the time, and being able to easily convert to a >real int for either database storage, wire transmission, or C functions is a >Good Thing. But then, Foo.a.value is good enough. -Barry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
On May 02, 2013, at 08:42 AM, Larry Hastings wrote: >So, for the second time: How can Color.red and MoreColor.red be the same >object when they are of different types? It's a moot point now given Guido's pronouncement. -Barry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Enum: subclassing?
On Thu, May 2, 2013 at 8:54 AM, Barry Warsaw wrote: > On May 01, 2013, at 03:11 PM, Ethan Furman wrote: > > >The reason __int__ is there is because pure Enums should be using plain > ints > >as their value 95% or more of the time, and being able to easily convert > to a > >real int for either database storage, wire transmission, or C functions > is a > >Good Thing. > > But then, Foo.a.value is good enough. > __int__ is out of Enum, Barry. You're preaching to the choir now ;-) Eli ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
On Thu, May 2, 2013 at 8:57 AM, Barry Warsaw wrote: > On May 02, 2013, at 08:42 AM, Larry Hastings wrote: > > >So, for the second time: How can Color.red and MoreColor.red be the same > >object when they are of different types? > > It's a moot point now given Guido's pronouncement. > Correct. There's no Color.red and MoreColor.red. Subclassing is allowed only of enums that define no members. So this is forbidden: >>> class MoreColor(Color): ... pink = 17 ... TypeError: Cannot subclass enumerations But this is allowed: >>> class Foo(Enum): ... def some_behavior(self): ... pass ... >>> class Bar(Foo): ... happy = 1 ... sad = 2 ... Eli ___ Python-Dev mailing list [email protected] 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 428: stat caching undesirable?
On Wed, 2013-05-01 at 23:54 +1000, Nick Coghlan wrote: > > However, I like the idea of a rich "stat" object, with "path.stat()" > and "path.cached_stat()" accessors on the path objects. > Since it seems there is some support for my proposal, I just posted to python-ideas to get an idea how much support there would be for such a PEP. -- Pieter Nagel ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity
In order for the Enum convenience function to be pickleable, we have this line of code in the metaclass: enum_class.__module__ = sys._getframe(1).f_globals['__name__'] This works fine for Cpython, but what about the others? -- ~Ethan~ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity
2013/5/2 Ethan Furman : > In order for the Enum convenience function to be pickleable, we have this > line of code in the metaclass: > > enum_class.__module__ = sys._getframe(1).f_globals['__name__'] > > This works fine for Cpython, but what about the others? Regardless of that, perhaps we should come up with better ways to do this. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity
On Thu, 2 May 2013 15:48:14 -0400 Benjamin Peterson wrote: > 2013/5/2 Ethan Furman : > > In order for the Enum convenience function to be pickleable, we have this > > line of code in the metaclass: > > > > enum_class.__module__ = sys._getframe(1).f_globals['__name__'] > > > > This works fine for Cpython, but what about the others? > > Regardless of that, perhaps we should come up with better ways to do this. Two things that were suggested in private: 1) ask users to pass the module name to the convenience function explicitly (i.e. pass "seasonmodule.Season" instead of "Season" as the class "name"). Guido doesn't like it :-) 2) dicth the "convenience function" and replace it with a regular class-based syntax. Ethan doesn't like it :-) Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity
On Thu, May 2, 2013 at 1:10 PM, Antoine Pitrou wrote: > On Thu, 2 May 2013 15:48:14 -0400 > Benjamin Peterson wrote: > > 2013/5/2 Ethan Furman : > > > In order for the Enum convenience function to be pickleable, we have > this > > > line of code in the metaclass: > > > > > > enum_class.__module__ = sys._getframe(1).f_globals['__name__'] > > > > > > This works fine for Cpython, but what about the others? > > > > Regardless of that, perhaps we should come up with better ways to do > this. > > Two things that were suggested in private: > > 1) ask users to pass the module name to the convenience function > explicitly (i.e. pass "seasonmodule.Season" instead of "Season" as the > class "name"). Guido doesn't like it :-) > > 2) dicth the "convenience function" and replace it with a regular > class-based syntax. Ethan doesn't like it :-) > Re (2), we already have the hack in stdlib in namedtuple, so not allowing it for an enum is a step backwards. If sys._getframe(1).f_globals['__name__'] feels hackish, maybe it can be shortened to a convenience function the stdlib provides? Are there conditions where it doesn't produce what we expect from it? The point at which the enumeration is defined resides in *some* module, no? Eli ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity
Am 02.05.2013 22:10, schrieb Antoine Pitrou: > On Thu, 2 May 2013 15:48:14 -0400 > Benjamin Peterson wrote: >> 2013/5/2 Ethan Furman : >> > In order for the Enum convenience function to be pickleable, we have this >> > line of code in the metaclass: >> > >> > enum_class.__module__ = sys._getframe(1).f_globals['__name__'] >> > >> > This works fine for Cpython, but what about the others? >> >> Regardless of that, perhaps we should come up with better ways to do this. > > Two things that were suggested in private: > > 1) ask users to pass the module name to the convenience function > explicitly (i.e. pass "seasonmodule.Season" instead of "Season" as the > class "name"). Guido doesn't like it :-) > > 2) dicth the "convenience function" and replace it with a regular > class-based syntax. Ethan doesn't like it :-) 5) accept that convenience-created enums have restrictions such as no picklability and point them out in the docs? Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity
On Thu, 2 May 2013 13:15:00 -0700 Eli Bendersky wrote: > > Two things that were suggested in private: > > > > 1) ask users to pass the module name to the convenience function > > explicitly (i.e. pass "seasonmodule.Season" instead of "Season" as the > > class "name"). Guido doesn't like it :-) > > > > 2) dicth the "convenience function" and replace it with a regular > > class-based syntax. Ethan doesn't like it :-) > > > > Re (2), we already have the hack in stdlib in namedtuple, so not allowing > it for an enum is a step backwards. That's a fallacy. There is no step backwards if you adopt a class-based syntax, which is just as convenient as the proposed "convenience function". I have a hard time understanding that calling a function to declare a class is suddenly considered "convenient". > If > sys._getframe(1).f_globals['__name__'] feels hackish, maybe it can be > shortened to a convenience function the stdlib provides? It's not the notation which is hackish, it's the fact that you are inspecting the frame stack in the hope of getting the right information. What if someone wants to write another convenience function that wraps your convenience function? What if your code is executing from some kind of step-by-step debugger which inserts an additional frame in the call stack? What if someone wants the enum to be nested inside another class (rather than reside at the module top-level)? Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity
On Thu, May 2, 2013 at 12:07 PM, Ethan Furman wrote: > In order for the Enum convenience function to be pickleable, we have this > line of code in the metaclass: > > enum_class.__module__ = sys._getframe(1).f_globals['__name__'] > > This works fine for Cpython, but what about the others? This should work for Jython, but I can't say I like it. I believe IronPython has a sort of speedup mode that disallows the use of _getframe, and I'd like to add this to Jython someday. -Frank ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity
On Thu, May 2, 2013 at 1:22 PM, Antoine Pitrou wrote: > On Thu, 2 May 2013 13:15:00 -0700 > Eli Bendersky wrote: > > > Two things that were suggested in private: > > > > > > 1) ask users to pass the module name to the convenience function > > > explicitly (i.e. pass "seasonmodule.Season" instead of "Season" as the > > > class "name"). Guido doesn't like it :-) > > > > > > 2) dicth the "convenience function" and replace it with a regular > > > class-based syntax. Ethan doesn't like it :-) > > > > > > > Re (2), we already have the hack in stdlib in namedtuple, so not allowing > > it for an enum is a step backwards. > > That's a fallacy. There is no step backwards if you adopt a class-based > syntax, which is just as convenient as the proposed "convenience > function". I have a hard time understanding that calling a function to > declare a class is suddenly considered "convenient". > > > If > > sys._getframe(1).f_globals['__name__'] feels hackish, maybe it can be > > shortened to a convenience function the stdlib provides? > > It's not the notation which is hackish, it's the fact that you are > inspecting the frame stack in the hope of getting the right information. > > What if someone wants to write another convenience function that wraps > your convenience function? What if your code is executing from some > kind of step-by-step debugger which inserts an additional frame in the > call stack? What if someone wants the enum to be nested inside another > class (rather than reside at the module top-level)? > Would nesting the non-convenience Enum in a function or a class allow one to pickle it? I think programmers who want their libraries to be pickle-able already have to be aware of some restrictions about what can and cannot be pickled. Eli ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity
On May 02, 2013, at 10:18 PM, Georg Brandl wrote: >5) accept that convenience-created enums have restrictions such as no >picklability and point them out in the docs? That would work fine for me, but ultimately I'm with Guido. I just don't want to have to pass the module name in. -Barry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity
On Thu, May 2, 2013 at 1:18 PM, [email protected] wrote: > On Thu, May 2, 2013 at 12:07 PM, Ethan Furman wrote: >> In order for the Enum convenience function to be pickleable, we have this >> line of code in the metaclass: >> >> enum_class.__module__ = sys._getframe(1).f_globals['__name__'] >> >> This works fine for Cpython, but what about the others? > This should work for Jython, but I can't say I like it. I believe > IronPython has a sort of speedup mode that disallows the use of > _getframe, and I'd like to add this to Jython someday. This particular function is typically only called at module load time, so speeding it up isn't worth it. FWIW, as Eli pointed out, namedtuple() does the same thing (since Python 2.6), so we'll just copy that code (refactoring it doesn't have to hold up the PEP). The only other alternative I find acceptable is not to have the convenience API at all. That's Eli's call. [Eli] > Would nesting the non-convenience Enum in a function or a class allow one to > pickle it? I think programmers who want their libraries to be pickle-able > already have to be aware of some restrictions about what can and cannot be > pickled. Apparently it hasn't been a problem for namedtuple. Calling namedtuple() or Enum() in another function is similar to a class statement inside a function -- the resulting class isn't picklable. (But from this, don't conclude that it's not important for namedtuple() or Enum() to return a picklable class. It is important. It is just not important to try to make it work when they are called through some other wrapper -- there's just not much use for such a pattern.) -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity
On Thu, 2 May 2013 13:33:21 -0700 Eli Bendersky wrote: > On Thu, May 2, 2013 at 1:22 PM, Antoine Pitrou wrote: > > > On Thu, 2 May 2013 13:15:00 -0700 > > Eli Bendersky wrote: > > > > Two things that were suggested in private: > > > > > > > > 1) ask users to pass the module name to the convenience function > > > > explicitly (i.e. pass "seasonmodule.Season" instead of "Season" as the > > > > class "name"). Guido doesn't like it :-) > > > > > > > > 2) dicth the "convenience function" and replace it with a regular > > > > class-based syntax. Ethan doesn't like it :-) > > > > > > > > > > Re (2), we already have the hack in stdlib in namedtuple, so not allowing > > > it for an enum is a step backwards. > > > > That's a fallacy. There is no step backwards if you adopt a class-based > > syntax, which is just as convenient as the proposed "convenience > > function". I have a hard time understanding that calling a function to > > declare a class is suddenly considered "convenient". > > > > > If > > > sys._getframe(1).f_globals['__name__'] feels hackish, maybe it can be > > > shortened to a convenience function the stdlib provides? > > > > It's not the notation which is hackish, it's the fact that you are > > inspecting the frame stack in the hope of getting the right information. > > > > What if someone wants to write another convenience function that wraps > > your convenience function? What if your code is executing from some > > kind of step-by-step debugger which inserts an additional frame in the > > call stack? What if someone wants the enum to be nested inside another > > class (rather than reside at the module top-level)? > > > > Would nesting the non-convenience Enum in a function or a class allow one > to pickle it? Once PEP 3154 is implemented (Alexandre is on it :-)), nested classes should be picklable. As for classes inside functions, it sounds quite impossible (how do you instantiate the function namespace without calling the function?). Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity
On Thu, May 2, 2013 at 9:07 PM, Ethan Furman wrote: > In order for the Enum convenience function to be pickleable, we have this > line of code in the metaclass: > > enum_class.__module__ = sys._getframe(1).f_globals['__name__'] > > This works fine for Cpython, but what about the others? It's ugly as hell, but it's not a performance problem for PyPy, since this is executed at module load time (you probably won't jit that code anyway) Cheers, fijal ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity
On Thu, May 2, 2013 at 1:39 PM, Barry Warsaw wrote: > On May 02, 2013, at 10:18 PM, Georg Brandl wrote: > > >5) accept that convenience-created enums have restrictions such as no > >picklability and point them out in the docs? > > That would work fine for me, but ultimately I'm with Guido. I just don't > want > to have to pass the module name in. > The problem with (5) is this: you use some library that exports an enumeration, and you want to use pickling. Now you depend on the way the library implemented - if it used the convenience API, you can't pickle. If it used the class API, you can. Eli ___ Python-Dev mailing list [email protected] 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 428: stat caching undesirable?
> Actually, there's Gregory's scandir() implementation (returning a > generator to be able to cope with large directories) on it's way: > > http://bugs.python.org/issue11406 > > It's already been suggested to make it return a tuple (with d_type). > I'm sure a review of the code (especially the Windows implementation) > will be welcome. > Ah, thanks for the pointer, I hadn't seen that. Definitely looks like I should "merge" Betterwalk with it. I'll see if I can spend some time on it again soon. I'd love to see scandir/iterdir go into Python 3.4, and I'd be very chuffed if iterdir_stat got in, because that's the one that can really start speeding up operations like os.walk(). -Ben ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity
On Thu, May 2, 2013 at 1:39 PM, Guido van Rossum wrote: > On Thu, May 2, 2013 at 1:18 PM, [email protected] > wrote: > > On Thu, May 2, 2013 at 12:07 PM, Ethan Furman > wrote: > >> In order for the Enum convenience function to be pickleable, we have > this > >> line of code in the metaclass: > >> > >> enum_class.__module__ = sys._getframe(1).f_globals['__name__'] > >> > >> This works fine for Cpython, but what about the others? > > This should work for Jython, but I can't say I like it. I believe > > IronPython has a sort of speedup mode that disallows the use of > > _getframe, and I'd like to add this to Jython someday. > > This particular function is typically only called at module load time, > so speeding it up isn't worth it. > > FWIW, as Eli pointed out, namedtuple() does the same thing (since > Python 2.6), so we'll just copy that code (refactoring it doesn't have > to hold up the PEP). The only other alternative I find acceptable is > not to have the convenience API at all. That's Eli's call. > I really prefer having the convenience API and acknowledging that it has some limitations (i.e. picking enums that were created with the convenience API and are nested in classes). > > [Eli] > > Would nesting the non-convenience Enum in a function or a class allow > one to > > pickle it? I think programmers who want their libraries to be pickle-able > > already have to be aware of some restrictions about what can and cannot > be > > pickled. > > Apparently it hasn't been a problem for namedtuple. Calling > namedtuple() or Enum() in another function is similar to a class > statement inside a function -- the resulting class isn't picklable. > > (But from this, don't conclude that it's not important for > namedtuple() or Enum() to return a picklable class. It is important. > It is just not important to try to make it work when they are called > through some other wrapper -- there's just not much use for such a > pattern.) > I agree. Eli ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity
On Thu, 2 May 2013 13:48:24 -0700 Eli Bendersky wrote: > On Thu, May 2, 2013 at 1:39 PM, Barry Warsaw wrote: > > > On May 02, 2013, at 10:18 PM, Georg Brandl wrote: > > > > >5) accept that convenience-created enums have restrictions such as no > > >picklability and point them out in the docs? > > > > That would work fine for me, but ultimately I'm with Guido. I just don't > > want > > to have to pass the module name in. > > > > The problem with (5) is this: you use some library that exports an > enumeration, and you want to use pickling. Now you depend on the way the > library implemented - if it used the convenience API, you can't pickle. If > it used the class API, you can. A good reason to ditch the function-based syntax. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity
> > > On Thu, 2 May 2013 13:15:00 -0700 > > > Eli Bendersky wrote: > > > > > Two things that were suggested in private: > > > > > > > > > > 1) ask users to pass the module name to the convenience function > > > > > explicitly (i.e. pass "seasonmodule.Season" instead of "Season" as > the > > > > > class "name"). Guido doesn't like it :-) > > > > > > > > > > 2) dicth the "convenience function" and replace it with a regular > > > > > class-based syntax. Ethan doesn't like it :-) > > > > > > > > > > > > > Re (2), we already have the hack in stdlib in namedtuple, so not > allowing > > > > it for an enum is a step backwards. > > > > > > That's a fallacy. There is no step backwards if you adopt a class-based > > > syntax, which is just as convenient as the proposed "convenience > > > function". I have a hard time understanding that calling a function to > > > declare a class is suddenly considered "convenient". > > > > > > > If > > > > sys._getframe(1).f_globals['__name__'] feels hackish, maybe it can be > > > > shortened to a convenience function the stdlib provides? > > > > > > It's not the notation which is hackish, it's the fact that you are > > > inspecting the frame stack in the hope of getting the right > information. > > > > > > What if someone wants to write another convenience function that wraps > > > your convenience function? What if your code is executing from some > > > kind of step-by-step debugger which inserts an additional frame in the > > > call stack? What if someone wants the enum to be nested inside another > > > class (rather than reside at the module top-level)? > > > > > > > Would nesting the non-convenience Enum in a function or a class allow one > > to pickle it? > > Once PEP 3154 is implemented (Alexandre is on it :-)), nested classes > should be picklable. Interesting, I did not know that. > As for classes inside functions, it sounds quite > impossible (how do you instantiate the function namespace without > calling the function?). > True. Back to my question from before, though - do we have a real technical limitation of having something like inspect.what_module_am_i_now_in() that's supposed to work for all Python code? Eli ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity
On 05/02/2013 01:52 PM, Eli Bendersky wrote: Back to my question from before, though - do we have a real technical limitation of having something like inspect.what_module_am_i_now_in() that's supposed to work for all Python code? By which you really mean inspect.what_module_was_I_called_from() ? -- ~Ethan~ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity
On Thu, 2 May 2013 13:52:29 -0700 Eli Bendersky wrote: > > Back to my question from before, though - do we have a real technical > limitation of having something like inspect.what_module_am_i_now_in() > that's supposed to work for all Python code? I already gave an answer (e.g. the debugger case), but you are free to consider it not reasonable :) In any case, I just find the argument for a function-based syntax non-existent compared to a similarly compact class-based syntax. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity
On Thu, May 2, 2013 at 2:05 PM, Ethan Furman wrote:
> On 05/02/2013 01:52 PM, Eli Bendersky wrote:
>
>>
>> Back to my question from before, though - do we have a real technical
>> limitation of having something like
>> inspect.what_module_am_i_now_**in() that's supposed to work for all
>> Python code?
>>
>
> By which you really mean inspect.what_module_was_I_called_from() ?
>
>
Yes, I guess this is what I meant by "now_in" part. Let's be precise:
Animal = Enum('Animal', '...')
The call to Enum is the interesting here. In happens in some library and
Animal members can then be passed around. But we really want the module
where Enum() was invoked to create Animal in the first place.
Eli
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity
On Thu, May 2, 2013 at 2:10 PM, Antoine Pitrou wrote: > On Thu, 2 May 2013 13:52:29 -0700 > Eli Bendersky wrote: > > > > Back to my question from before, though - do we have a real technical > > limitation of having something like inspect.what_module_am_i_now_in() > > that's supposed to work for all Python code? > > I already gave an answer (e.g. the debugger case), but you are free to > consider it not reasonable :) Sorry, but I do find the argument "let's not have a convenience syntax because enums created with such syntax won't pickle properly from within a debugger" not convincing enough :-) It may be just me though, and I'm open to other opinions. Eli ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity
On May 02, 2013, at 10:57 PM, Antoine Pitrou wrote: >On Thu, 2 May 2013 13:48:24 -0700 >> The problem with (5) is this: you use some library that exports an >> enumeration, and you want to use pickling. Now you depend on the way the >> library implemented - if it used the convenience API, you can't pickle. If >> it used the class API, you can. > >A good reason to ditch the function-based syntax. Why? Not everything is picklable. Oh well. -Barry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity
2013/5/2 Eli Bendersky : > > > > On Thu, May 2, 2013 at 1:10 PM, Antoine Pitrou wrote: >> >> On Thu, 2 May 2013 15:48:14 -0400 >> Benjamin Peterson wrote: >> > 2013/5/2 Ethan Furman : >> > > In order for the Enum convenience function to be pickleable, we have >> > > this >> > > line of code in the metaclass: >> > > >> > > enum_class.__module__ = sys._getframe(1).f_globals['__name__'] >> > > >> > > This works fine for Cpython, but what about the others? >> > >> > Regardless of that, perhaps we should come up with better ways to do >> > this. >> >> Two things that were suggested in private: >> >> 1) ask users to pass the module name to the convenience function >> explicitly (i.e. pass "seasonmodule.Season" instead of "Season" as the >> class "name"). Guido doesn't like it :-) >> >> 2) dicth the "convenience function" and replace it with a regular >> class-based syntax. Ethan doesn't like it :-) > > > Re (2), we already have the hack in stdlib in namedtuple, so not allowing it > for an enum is a step backwards. If sys._getframe(1).f_globals['__name__'] > feels hackish, maybe it can be shortened to a convenience function the > stdlib provides? Are there conditions where it doesn't produce what we > expect from it? The point at which the enumeration is defined resides in > *some* module, no? I disagree that not allowing code smell to spread is a step backwards. Rather we should realize that this is a common problem and find a proper solution rather than further propogating this hack. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity
On Thu, 2 May 2013 14:16:34 -0700 Barry Warsaw wrote: > On May 02, 2013, at 10:57 PM, Antoine Pitrou wrote: > > >On Thu, 2 May 2013 13:48:24 -0700 > >> The problem with (5) is this: you use some library that exports an > >> enumeration, and you want to use pickling. Now you depend on the way the > >> library implemented - if it used the convenience API, you can't pickle. If > >> it used the class API, you can. > > > >A good reason to ditch the function-based syntax. > > Why? Not everything is picklable. Oh well. Then why insist on the _getframe hack? You are losing me: are you bothered by picklability or not? ;-) If you are not, then fine, let's just make the function-based version *documentedly* unpicklable, and move along. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity
On Thu, 2 May 2013 14:15:40 -0700 Eli Bendersky wrote: > > Sorry, but I do find the argument "let's not have a convenience syntax > because enums created with such syntax won't pickle properly from within a > debugger" not convincing enough :-) Eli, it would be nice if you stopped with this claim. I'm not advocating "not having a convenience syntax", I'm advocating having a convenience syntax which is *class-based* rather than function-based. Debuggers are beside the point: there are two kinds of "convenience syntax" on the table; one allows pickling by construction, one requires an ugly hack which may not solve all cases (and which may apparently make Jython / IronPython mildly unhappy). Why you insist on ignoring the former and imposing the latter is beyond me. Regards you Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity
2013/5/2 Guido van Rossum > On Thu, May 2, 2013 at 1:18 PM, [email protected] > wrote: > > On Thu, May 2, 2013 at 12:07 PM, Ethan Furman > wrote: > >> In order for the Enum convenience function to be pickleable, we have > this > >> line of code in the metaclass: > >> > >> enum_class.__module__ = sys._getframe(1).f_globals['__name__'] > >> > >> This works fine for Cpython, but what about the others? > > This should work for Jython, but I can't say I like it. I believe > > IronPython has a sort of speedup mode that disallows the use of > > _getframe, and I'd like to add this to Jython someday. > > This particular function is typically only called at module load time, > so speeding it up isn't worth it. It works fine on PyPy as well. It probably also kills any JIT optimization, but it's not an issue since classes are not usually created in tight loops. -- Amaury Forgeot d'Arc ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity
> Eli, it would be nice if you stopped with this claim.
>
> I'm not advocating "not having a convenience syntax", I'm advocating
> having a convenience syntax which is *class-based* rather than
> function-based.
>
> Debuggers are beside the point: there are two kinds of "convenience
> syntax" on the table; one allows pickling by construction, one
> requires an ugly hack which may not solve all cases (and which may
> apparently make Jython / IronPython mildly unhappy). Why you insist
> on ignoring the former and imposing the latter is beyond me.
>
I'm not trying to belittle our class-based suggestion. I just think there
are two separate issues here, and I was focusing on just one of them for
now. The one I've been focusing on is how to make the function-based
convenience syntax work with pickling in the vast majority of interesting
cases. This appears to be possible by using the same pattern used by
namedtuple, and even better by encapsulating this pattern formally in
stdlib so it stops being a hack (and may actually be useful for other code
too).
The other issue is your proposal to have a class-based convenience syntax
akin to (correct me if I got this wrong):
class Animal(Enum):
__values__ = 'cat dog'
This is obviously a matter of preference (and hence bikeshedding), but this
still looks better to me:
Animal = Enum('Animal', 'cat dog')
It has two advantages:
1. Shorter
2. Parallels namedtuple, which is by now a well known and widely used
construct
On the other hand, your proposal has the advantage that it allows pickles
without hacks in the implementation.
Did I sum up the issues fairly?
I don't know what to decide here. There's no clear technical merit to
decide on one against the other (IMHO!), it's a matter of preference.
Hopefully Guido will step in and save us from our misery ;-)
Eli
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] peps: Add time(), call_at(). Remove call_repeatedly(). Get rid of add_*_handler()
On 3 May 2013 08:34, "guido.van.rossum" wrote: > > http://hg.python.org/peps/rev/26947623fc5d > changeset: 4870:26947623fc5d > user:Guido van Rossum > date:Thu May 02 14:11:08 2013 -0700 > summary: > Add time(), call_at(). Remove call_repeatedly(). Get rid of add_*_handler() return value. > > files: > pep-3156.txt | 80 +-- > 1 files changed, 43 insertions(+), 37 deletions(-) > > > diff --git a/pep-3156.txt b/pep-3156.txt > --- a/pep-3156.txt > +++ b/pep-3156.txt > @@ -252,13 +252,12 @@ > implementation may choose not to implement the internet/socket > methods, and still conform to the other methods.) > > -- Resource management: ``close()``. > +- Miscellaneous: ``close()``, ``time()``. > > - Starting and stopping: ``run_forever()``, ``run_until_complete()``, >``stop()``, ``is_running()``. > > -- Basic callbacks: ``call_soon()``, ``call_later()``, > - ``call_repeatedly()``. > +- Basic callbacks: ``call_soon()``, ``call_later()``, ``call_at()``. > > - Thread interaction: ``call_soon_threadsafe()``, >``wrap_future()``, ``run_in_executor()``, > @@ -303,8 +302,8 @@ > Required Event Loop Methods > --- > > -Resource Management > -''' > +Miscellaneous > +' > > - ``close()``. Closes the event loop, releasing any resources it may >hold, such as the file descriptor used by ``epoll()`` or > @@ -313,6 +312,12 @@ >again. It may be called multiple times; subsequent calls are >no-ops. > > +- ``time()``. Returns the current time according to the event loop's > + clock. This may be ``time.time()`` or ``time.monotonic()`` or some > + other system-specific clock, but it must return a float expressing > + the time in units of approximately one second since some epoch. > + (No clock is perfect -- see PEP 418.) Should the PEP allow event loops that use decimal.Decimal? > + > Starting and Stopping > ' > > @@ -362,17 +367,27 @@ >``callback(*args)`` to be called approximately ``delay`` seconds in >the future, once, unless cancelled. Returns a Handle representing >the callback, whose ``cancel()`` method can be used to cancel the > - callback. If ``delay`` is <= 0, this acts like ``call_soon()`` > - instead. Otherwise, callbacks scheduled for exactly the same time > - will be called in an undefined order. > + callback. Callbacks scheduled in the past or at exactly the same > + time will be called in an undefined order. > > -- ``call_repeatedly(interval, callback, **args)``. Like > - ``call_later()`` but calls the callback repeatedly, every (approximately) > - ``interval`` seconds, until the Handle returned is cancelled or > - the callback raises an exception. The first call is in > - approximately ``interval`` seconds. If for whatever reason the > - callback happens later than scheduled, subsequent callbacks will be > - delayed for (at least) the same amount. The ``interval`` must be > 0. > +- ``call_at(when, callback, *args)``. This is like ``call_later()``, > + but the time is expressed as an absolute time. There is a simple > + equivalency: ``loop.call_later(delay, callback, *args)`` is the same > + as ``loop.call_at(loop.time() + delay, callback, *args)``. It may be worth explicitly noting the time scales where floating point's dynamic range starts to significantly limit granularity. Cheers, Nick. > + > +Note: A previous version of this PEP defined a method named > +``call_repeatedly()``, which promised to call a callback at regular > +intervals. This has been withdrawn because the design of such a > +function is overspecified. On the one hand, a simple timer loop can > +easily be emulated using a callback that reschedules itself using > +``call_later()``; it is also easy to write coroutine containing a loop > +and a ``sleep()`` call (a toplevel function in the module, see below). > +On the other hand, due to the complexities of accurate timekeeping > +there are many traps and pitfalls here for the unaware (see PEP 418), > +and different use cases require different behavior in edge cases. It > +is impossible to offer an API for this purpose that is bullet-proof in > +all cases, so it is deemed better to let application designers decide > +for themselves what kind of timer loop to implement. > > Thread interaction > '' > @@ -656,12 +671,9 @@ > > - ``add_reader(fd, callback, *args)``. Arrange for >``callback(*args)`` to be called whenever file descriptor ``fd`` is > - deemed ready for reading. Returns a Handle object which can be used > - to cancel the callback. (However, it is strongly preferred to use > - ``remove_reader()`` instead.) Calling ``add_reader()`` again for > - the same file descriptor implies a call to ``remove_reader()`` for > - the same file descriptor. (TBD: Since cancelling the Handle is not > - recommended, perhaps we should return None instead?) > + deemed ready fo
Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity
On Thu, May 2, 2013 at 1:18 PM, [email protected] wrote: > On Thu, May 2, 2013 at 12:07 PM, Ethan Furman wrote: >> In order for the Enum convenience function to be pickleable, we have this >> line of code in the metaclass: >> >> enum_class.__module__ = sys._getframe(1).f_globals['__name__'] >> >> This works fine for Cpython, but what about the others? > This should work for Jython, but I can't say I like it. I believe > IronPython has a sort of speedup mode that disallows the use of > _getframe, and I'd like to add this to Jython someday. It's not just a "speedup mode", it's the default. IronPython requires frames to explicitly enabled because tracking them is about a 10% performance hit (or so Dino told me once upon a time). If you must use it, please copy the code block from namedtuple that ignores it on IronPython. - Jeff ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity
On 3 May 2013 08:00, "Eli Bendersky" wrote:
>
> > Eli, it would be nice if you stopped with this claim.
>>
>>
>> I'm not advocating "not having a convenience syntax", I'm advocating
>> having a convenience syntax which is *class-based* rather than
>> function-based.
>>
>> Debuggers are beside the point: there are two kinds of "convenience
>> syntax" on the table; one allows pickling by construction, one
>> requires an ugly hack which may not solve all cases (and which may
>> apparently make Jython / IronPython mildly unhappy). Why you insist
>> on ignoring the former and imposing the latter is beyond me.
>
>
> I'm not trying to belittle our class-based suggestion. I just think there
are two separate issues here, and I was focusing on just one of them for
now. The one I've been focusing on is how to make the function-based
convenience syntax work with pickling in the vast majority of interesting
cases. This appears to be possible by using the same pattern used by
namedtuple, and even better by encapsulating this pattern formally in
stdlib so it stops being a hack (and may actually be useful for other code
too).
>
> The other issue is your proposal to have a class-based convenience syntax
akin to (correct me if I got this wrong):
>
> class Animal(Enum):
> __values__ = 'cat dog'
I would suggest moving the field names into the class header for a class
based convenience API:
class Animal(Enum, members='cat dog'): pass
Cheers,
Nick.
>
> This is obviously a matter of preference (and hence bikeshedding), but
this still looks better to me:
>
> Animal = Enum('Animal', 'cat dog')
>
> It has two advantages:
>
> 1. Shorter
> 2. Parallels namedtuple, which is by now a well known and widely used
construct
>
> On the other hand, your proposal has the advantage that it allows pickles
without hacks in the implementation.
>
> Did I sum up the issues fairly?
>
> I don't know what to decide here. There's no clear technical merit to
decide on one against the other (IMHO!), it's a matter of preference.
Hopefully Guido will step in and save us from our misery ;-)
>
> Eli
>
>
>
>
>
>
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity
On Thu, May 2, 2013 at 4:14 PM, Nick Coghlan wrote: > I would suggest moving the field names into the class header for a class > based convenience API: > > class Animal(Enum, members='cat dog'): pass Would you propose the same for namedtuple? -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
Guido van Rossum wrote: you should do some other check, e.g. "if x in Color:". So you don't think it's important to have an easy way to take user input that's supposed to be a Color name and either return a Color or raise a ValueError? -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
Eli Bendersky wrote: TypeError: Cannot subclass enumerations This message might be better phrased as "cannot extend enumerations", since we're still allowing subclassing prior to defining members. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
On 05/02/2013 04:45 PM, Greg Ewing wrote: Eli Bendersky wrote: TypeError: Cannot subclass enumerations This message might be better phrased as "cannot extend enumerations", since we're still allowing subclassing prior to defining members. I like it, thanks! -- ~Ethan~ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
On Thu, May 2, 2013 at 4:50 PM, Ethan Furman wrote: > On 05/02/2013 04:45 PM, Greg Ewing wrote: > >> Eli Bendersky wrote: >> >> TypeError: Cannot subclass enumerations >>> >> >> This message might be better phrased as "cannot extend >> enumerations", since we're still allowing subclassing >> prior to defining members. >> > > I like it, thanks! > +1 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity
On May 03, 2013, at 09:14 AM, Nick Coghlan wrote: >> The other issue is your proposal to have a class-based convenience syntax >akin to (correct me if I got this wrong): >> >> class Animal(Enum): >> __values__ = 'cat dog' > >I would suggest moving the field names into the class header for a class >based convenience API: > >class Animal(Enum, members='cat dog'): pass Wait, what is this trying to solve? "Convenience API" is really a shorthand for "functional API". Two very different use cases that the above suggestion doesn't address. IMHO, it's not worth giving up the functional API for picklability if the technical problems cannot be resolved, especially given we already have the same problem for namedtuples. -Barry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
On 05/02/2013 04:43 PM, Greg Ewing wrote: Guido van Rossum wrote: you should do some other check, e.g. "if x in Color:". So you don't think it's important to have an easy way to take user input that's supposed to be a Color name and either return a Color or raise a ValueError? I don't believe that's what he said: The name lookup is only relevant if you already know that you have a valid name of an enum in the class [...] User input should qualify, and using getattr(EnumClass, user_input) will get you an AttributeError instead of a ValueError if user_input is not valid, but surely you don't mind that small difference. ;) -- ~Ethan~ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
On Fri, May 3, 2013 at 9:57 AM, Ethan Furman wrote: > On 05/02/2013 04:43 PM, Greg Ewing wrote: >> >> Guido van Rossum wrote: >>> >>> you should do some other check, >>> e.g. "if x in Color:". >> >> >> So you don't think it's important to have an easy >> way to take user input that's supposed to be a >> Color name and either return a Color or raise >> a ValueError? > > > I don't believe that's what he said: > >> The name lookup is only relevant if you already know that you have a >> valid name of an enum in the class [...] > > > User input should qualify, and using getattr(EnumClass, user_input) will get > you an AttributeError instead of a ValueError if user_input is not valid, > but surely you don't mind that small difference. ;) >>> int(getattr(C(), "__str__")) Traceback (most recent call last): File "", line 1, in TypeError: int() argument must be a string or a number, not 'method-wrapper' That's the problem Greg is complaining about: when you use getattr to do the name->enum member conversion, you have to do your own checking to exclude method names. This is part of why I think enums should offer an "as_dict()" method that returns an ordered dictionary. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] 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 reference implementation
On Thu, May 2, 2013 at 11:37 AM, Steven D'Aprano wrote: > On 02/05/13 08:54, Nick Coghlan wrote: > >> If enums had an "as_dict" method that returned an ordered dictionary, you >> could do: >> >> class MoreColors(Enum): >> locals().update(Colors.as_dict()) > > > > Surely that is an implementation-specific piece of code? Writing to locals() > is not guaranteed to work, and the documentation warns against it. > > http://docs.python.org/3/library/functions.html#locals I've long thought we should stop being wishy-washy about modification of locals(), and make the current CPython behaviour part of the language spec: - at module scope, locals() must return the same thing as globals(), which must be the actual module namespace - at class scope, it must return the namespace returned by __prepare__() - at function scope, it returns a snapshot of the current locals and free variables, and thus does not support modifications (and may not see subsequent changes) I'll start a separate thread about that. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Tightening up the specification for locals()
An exchange in one of the enum threads prompted me to write down something I've occasionally thought about regarding locals(): it is currently severely underspecified, and I'd like to make the current CPython behaviour part of the language/library specification. (We recently found a bug in the interaction between the __prepare__ method and lexical closures that was indirectly related to this underspecification) Specifically, rather than the current vague "post-modification of locals may not work", I would like to explicitly document the expected behaviour at module, class and function scope (as well as clearly documenting the connection between modules, classes and the single- and dual-namespace variants of exec() and eval()): * at module scope, as well as when using exec() or eval() with a single namespace, locals() must return the same thing as globals(), which must be the actual execution namespace. Subsequent execution may change the contents of the returned mapping, and changes to the returned mapping must change the execution environment. * at class scope, as well as when using exec() or eval() with separate global and local namespaces, locals() must return the specified local namespace (which may be supplied by the metaclass __prepare__ method in the case of classes). Subsequent execution may change the contents of the returned mapping, and changes to the returned mapping must change the execution environment. For classes, this mapping will not be used as the actual class namespace underlying the defined class (the class creation process will copy the contents to a fresh dictionary that is only accessible by going through the class machinery). * at function scope, locals() must return a *snapshot* of the current locals and free variables. Subsequent execution must not change the contents of the returned mapping and changes to the returned mapping must not change the execution environment. Rather than adding this low level detail to the library reference docs, I would suggest adding it to the data model section of the language reference, with a link to the appropriate section from the docs for the locals() builtin. The warning in the locals() docs would be softened to indicate that modifications won't work at function scope, but are supported at module and class scope. Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] enum discussion: can someone please summarize open issues?
On May 03, 2013, at 11:06 AM, Nick Coghlan wrote: >> User input should qualify, and using getattr(EnumClass, user_input) will get >> you an AttributeError instead of a ValueError if user_input is not valid, >> but surely you don't mind that small difference. ;) > int(getattr(C(), "__str__")) >Traceback (most recent call last): > File "", line 1, in >TypeError: int() argument must be a string or a number, not 'method-wrapper' > >That's the problem Greg is complaining about: when you use getattr to >do the name->enum member conversion, you have to do your own checking >to exclude method names. > >This is part of why I think enums should offer an "as_dict()" method >that returns an ordered dictionary. Should this be allowed then? class Transformations(Enum): as_int = 1 as_dict = 2 as_tuple = 3 ? I still don't get it why this is an issue though, or at least why this is different than any other getattr on any other class, or even Enums. I mean, you could do a getattr on any other class or instance with any random user input and there's no guarantee you could pass it straight to int() or any other conversion type. So you pretty much have to be prepared to capture exceptions anyway. -Barry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tightening up the specification for locals()
2013/5/2 Nick Coghlan : > An exchange in one of the enum threads prompted me to write down > something I've occasionally thought about regarding locals(): it is > currently severely underspecified, and I'd like to make the current > CPython behaviour part of the language/library specification. (We > recently found a bug in the interaction between the __prepare__ method > and lexical closures that was indirectly related to this > underspecification) > > Specifically, rather than the current vague "post-modification of > locals may not work", I would like to explicitly document the expected > behaviour at module, class and function scope (as well as clearly > documenting the connection between modules, classes and the single- > and dual-namespace variants of exec() and eval()): > > * at module scope, as well as when using exec() or eval() with a > single namespace, locals() must return the same thing as globals(), > which must be the actual execution namespace. Subsequent execution may > change the contents of the returned mapping, and changes to the > returned mapping must change the execution environment. > * at class scope, as well as when using exec() or eval() with separate > global and local namespaces, locals() must return the specified local > namespace (which may be supplied by the metaclass __prepare__ method > in the case of classes). Subsequent execution may change the contents > of the returned mapping, and changes to the returned mapping must > change the execution environment. For classes, this mapping will not > be used as the actual class namespace underlying the defined class > (the class creation process will copy the contents to a fresh > dictionary that is only accessible by going through the class > machinery). > * at function scope, locals() must return a *snapshot* of the current > locals and free variables. Subsequent execution must not change the > contents of the returned mapping and changes to the returned mapping > must not change the execution environment. > > Rather than adding this low level detail to the library reference > docs, I would suggest adding it to the data model section of the > language reference, with a link to the appropriate section from the > docs for the locals() builtin. The warning in the locals() docs would > be softened to indicate that modifications won't work at function > scope, but are supported at module and class scope. This sounds good to me. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tightening up the specification for locals()
On 03/05/13 11:29, Nick Coghlan wrote: An exchange in one of the enum threads prompted me to write down something I've occasionally thought about regarding locals(): it is currently severely underspecified, and I'd like to make the current CPython behaviour part of the language/library specification. (We recently found a bug in the interaction between the __prepare__ method and lexical closures that was indirectly related to this underspecification) Fixing the underspecification is good. Enshrining a limitation as the one correct way, not so good. * at function scope, locals() must return a *snapshot* of the current locals and free variables. Subsequent execution must not change the contents of the returned mapping and changes to the returned mapping must not change the execution environment. If we were designing the language from scratch, with no concern for optimizing function execution, would we want this as a language feature? I don't believe that there is anyone who would say: "I really want locals() to behave differently inside functions from how it behaves inside classes and the global scope, as a feature in and of itself." Obviously CPython introduces that limitation for good reason, and I don't wish to suggest that this is the wrong thing to do, but it is a trade-off, and some implementations may wish to make other trade-offs, or even find a way to avoid it altogether. E.g. IronPython and Jython both allow this: def func(): ... x = 1; del x ... locals()['x'] = 2 ... print x ... func() 2 And why not? In and of itself, writing to locals() inside a function is no worse a thing to do than writing to locals() inside a class or global scope. It's not something actively harmful that must be prohibited, so why prohibit it? I think that conforming Python implementations should be allowed a choice between two fully-specified behaviours, the choice between them being a "quality of implementation" issue: - locals() may return a read-only or frozen mapping containing a snapshot of the current locals and free variable, in which case subsequent execution must not change the contents of the returned mapping, and changing the returned mapping is not possible; - locals() may return an ordinary dict, in which case it must be the actual execution namespace, or a proxy to it. Subsequent execution will change the contents of the returned mapping, and changes to the mapping must change the execution environment. Code can determine at runtime which capability is provided by inspecting the type of the returned mapping: if isinstance(locals(), dict) then you have support for modifying the executable environment, if not, you don't. Obviously if you wish to write platform-agnostic code, you have to target the least behaviour, which would be read-only locals. But there's lots of code that runs only under Jython or IronPython, and if somebody really needs to write to locals(), they can target an implementation that provides that feature. -- Steven ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tightening up the specification for locals()
On 5/2/2013 9:29 PM, Nick Coghlan wrote: An exchange in one of the enum threads prompted me to write down something I've occasionally thought about regarding locals(): it is currently severely underspecified, and I'd like to make the current CPython behaviour part of the language/library specification. (We recently found a bug in the interaction between the __prepare__ method and lexical closures that was indirectly related to this underspecification) Specifically, rather than the current vague "post-modification of locals may not work", I would like to explicitly document the expected behaviour at module, class and function scope (as well as clearly documenting the connection between modules, classes and the single- and dual-namespace variants of exec() and eval()): * at module scope, as well as when using exec() or eval() with a single namespace, locals() must return the same thing as globals(), which must be the actual execution namespace. Subsequent execution may change the contents of the returned mapping, and changes to the returned mapping must change the execution environment. * at class scope, as well as when using exec() or eval() with separate global and local namespaces, locals() must return the specified local namespace (which may be supplied by the metaclass __prepare__ method in the case of classes). Subsequent execution may change the contents of the returned mapping, and changes to the returned mapping must change the execution environment. For classes, this mapping will not be used as the actual class namespace underlying the defined class (the class creation process will copy the contents to a fresh dictionary that is only accessible by going through the class machinery). * at function scope, locals() must return a *snapshot* of the current locals and free variables. Subsequent execution must not change the contents of the returned mapping and changes to the returned mapping must not change the execution environment. Except that, apparently, subsequent execution *does* change the returned mapping when tracing in on. Some of the loose specification is intentional. http://bugs.python.org/issue7083 locals() behaviour differs when tracing is in effect -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy, Jython, & IronPython: Enum convenience function and pickleablity
Am 02.05.2013 23:57, schrieb Eli Bendersky:
>> Eli, it would be nice if you stopped with this claim.
>
>
> I'm not advocating "not having a convenience syntax", I'm advocating
> having a convenience syntax which is *class-based* rather than
> function-based.
>
> Debuggers are beside the point: there are two kinds of "convenience
> syntax" on the table; one allows pickling by construction, one
> requires an ugly hack which may not solve all cases (and which may
> apparently make Jython / IronPython mildly unhappy). Why you insist
> on ignoring the former and imposing the latter is beyond me.
>
>
> I'm not trying to belittle our class-based suggestion. I just think there are
> two separate issues here, and I was focusing on just one of them for now. The
> one I've been focusing on is how to make the function-based convenience syntax
> work with pickling in the vast majority of interesting cases. This appears to
> be
> possible by using the same pattern used by namedtuple, and even better by
> encapsulating this pattern formally in stdlib so it stops being a hack (and
> may
> actually be useful for other code too).
>
> The other issue is your proposal to have a class-based convenience syntax akin
> to (correct me if I got this wrong):
>
> class Animal(Enum):
> __values__ = 'cat dog'
>
> This is obviously a matter of preference (and hence bikeshedding), but this
> still looks better to me:
>
> Animal = Enum('Animal', 'cat dog')
>
> It has two advantages:
>
> 1. Shorter
> 2. Parallels namedtuple, which is by now a well known and widely used
> construct
Not to forget 3. Has to specify the class name twice for good measure ;)
Georg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
