Re: [Python-Dev] PEP 428: stat caching undesirable?

2013-05-02 Thread Charles-François Natali
Yes, definitely. This is exactly what my os.walk() replacement, Betterwalk, does: https://github.com/benhoyt/betterwalk#readme On Windows you get *all* stat information from iterating the directory entries (FindFirstFile etc). And on Linux most of the time you get enough for os.walk() not

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

2013-05-02 Thread Barry Warsaw
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 #

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

2013-05-02 Thread Barry Warsaw
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

Re: [Python-Dev] Enum: subclassing?

2013-05-02 Thread Barry Warsaw
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

Re: [Python-Dev] Enum: subclassing?

2013-05-02 Thread Barry Warsaw
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' ...

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

2013-05-02 Thread Ethan Furman
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 #

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

2013-05-02 Thread Guido van Rossum
On Thu, May 2, 2013 at 7:58 AM, Barry Warsaw ba...@python.org 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

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

2013-05-02 Thread Barry Warsaw
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

Re: [Python-Dev] Enum: subclassing?

2013-05-02 Thread Eli Bendersky
On Thu, May 2, 2013 at 8:54 AM, Barry Warsaw ba...@python.org 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

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

2013-05-02 Thread Eli Bendersky
On Thu, May 2, 2013 at 8:57 AM, Barry Warsaw ba...@python.org 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.

Re: [Python-Dev] PEP 428: stat caching undesirable?

2013-05-02 Thread Pieter Nagel
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

[Python-Dev] PyPy, Jython, IronPython: Enum convenience function and pickleablity

2013-05-02 Thread 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? -- ~Ethan~ ___

Re: [Python-Dev] PyPy, Jython, IronPython: Enum convenience function and pickleablity

2013-05-02 Thread Benjamin Peterson
2013/5/2 Ethan Furman et...@stoneleaf.us: 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,

Re: [Python-Dev] PyPy, Jython, IronPython: Enum convenience function and pickleablity

2013-05-02 Thread Antoine Pitrou
On Thu, 2 May 2013 15:48:14 -0400 Benjamin Peterson benja...@python.org wrote: 2013/5/2 Ethan Furman et...@stoneleaf.us: In order for the Enum convenience function to be pickleable, we have this line of code in the metaclass: enum_class.__module__ =

Re: [Python-Dev] PyPy, Jython, IronPython: Enum convenience function and pickleablity

2013-05-02 Thread Eli Bendersky
On Thu, May 2, 2013 at 1:10 PM, Antoine Pitrou solip...@pitrou.net wrote: On Thu, 2 May 2013 15:48:14 -0400 Benjamin Peterson benja...@python.org wrote: 2013/5/2 Ethan Furman et...@stoneleaf.us: In order for the Enum convenience function to be pickleable, we have this line of code in

Re: [Python-Dev] PyPy, Jython, IronPython: Enum convenience function and pickleablity

2013-05-02 Thread Georg Brandl
Am 02.05.2013 22:10, schrieb Antoine Pitrou: On Thu, 2 May 2013 15:48:14 -0400 Benjamin Peterson benja...@python.org wrote: 2013/5/2 Ethan Furman et...@stoneleaf.us: In order for the Enum convenience function to be pickleable, we have this line of code in the metaclass:

Re: [Python-Dev] PyPy, Jython, IronPython: Enum convenience function and pickleablity

2013-05-02 Thread Antoine Pitrou
On Thu, 2 May 2013 13:15:00 -0700 Eli Bendersky eli...@gmail.com 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 :-)

Re: [Python-Dev] PyPy, Jython, IronPython: Enum convenience function and pickleablity

2013-05-02 Thread fwierzbi...@gmail.com
On Thu, May 2, 2013 at 12:07 PM, Ethan Furman et...@stoneleaf.us 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

Re: [Python-Dev] PyPy, Jython, IronPython: Enum convenience function and pickleablity

2013-05-02 Thread Eli Bendersky
On Thu, May 2, 2013 at 1:22 PM, Antoine Pitrou solip...@pitrou.net wrote: On Thu, 2 May 2013 13:15:00 -0700 Eli Bendersky eli...@gmail.com wrote: Two things that were suggested in private: 1) ask users to pass the module name to the convenience function explicitly (i.e. pass

Re: [Python-Dev] PyPy, Jython, IronPython: Enum convenience function and pickleablity

2013-05-02 Thread Barry Warsaw
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

Re: [Python-Dev] PyPy, Jython, IronPython: Enum convenience function and pickleablity

2013-05-02 Thread Guido van Rossum
On Thu, May 2, 2013 at 1:18 PM, fwierzbi...@gmail.com fwierzbi...@gmail.com wrote: On Thu, May 2, 2013 at 12:07 PM, Ethan Furman et...@stoneleaf.us wrote: In order for the Enum convenience function to be pickleable, we have this line of code in the metaclass: enum_class.__module__ =

Re: [Python-Dev] PyPy, Jython, IronPython: Enum convenience function and pickleablity

2013-05-02 Thread Antoine Pitrou
On Thu, 2 May 2013 13:33:21 -0700 Eli Bendersky eli...@gmail.com wrote: On Thu, May 2, 2013 at 1:22 PM, Antoine Pitrou solip...@pitrou.net wrote: On Thu, 2 May 2013 13:15:00 -0700 Eli Bendersky eli...@gmail.com wrote: Two things that were suggested in private: 1) ask users to

Re: [Python-Dev] PyPy, Jython, IronPython: Enum convenience function and pickleablity

2013-05-02 Thread Maciej Fijalkowski
On Thu, May 2, 2013 at 9:07 PM, Ethan Furman et...@stoneleaf.us 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

Re: [Python-Dev] PyPy, Jython, IronPython: Enum convenience function and pickleablity

2013-05-02 Thread Eli Bendersky
On Thu, May 2, 2013 at 1:39 PM, Barry Warsaw ba...@python.org 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

Re: [Python-Dev] PEP 428: stat caching undesirable?

2013-05-02 Thread Ben Hoyt
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

Re: [Python-Dev] PyPy, Jython, IronPython: Enum convenience function and pickleablity

2013-05-02 Thread Eli Bendersky
On Thu, May 2, 2013 at 1:39 PM, Guido van Rossum gu...@python.org wrote: On Thu, May 2, 2013 at 1:18 PM, fwierzbi...@gmail.com fwierzbi...@gmail.com wrote: On Thu, May 2, 2013 at 12:07 PM, Ethan Furman et...@stoneleaf.us wrote: In order for the Enum convenience function to be pickleable,

Re: [Python-Dev] PyPy, Jython, IronPython: Enum convenience function and pickleablity

2013-05-02 Thread Antoine Pitrou
On Thu, 2 May 2013 13:48:24 -0700 Eli Bendersky eli...@gmail.com wrote: On Thu, May 2, 2013 at 1:39 PM, Barry Warsaw ba...@python.org 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

Re: [Python-Dev] PyPy, Jython, IronPython: Enum convenience function and pickleablity

2013-05-02 Thread Eli Bendersky
On Thu, 2 May 2013 13:15:00 -0700 Eli Bendersky eli...@gmail.com 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

Re: [Python-Dev] PyPy, Jython, IronPython: Enum convenience function and pickleablity

2013-05-02 Thread Ethan Furman
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

Re: [Python-Dev] PyPy, Jython, IronPython: Enum convenience function and pickleablity

2013-05-02 Thread Antoine Pitrou
On Thu, 2 May 2013 13:52:29 -0700 Eli Bendersky eli...@gmail.com 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

Re: [Python-Dev] PyPy, Jython, IronPython: Enum convenience function and pickleablity

2013-05-02 Thread Eli Bendersky
On Thu, May 2, 2013 at 2:05 PM, Ethan Furman et...@stoneleaf.us 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

Re: [Python-Dev] PyPy, Jython, IronPython: Enum convenience function and pickleablity

2013-05-02 Thread Eli Bendersky
On Thu, May 2, 2013 at 2:10 PM, Antoine Pitrou solip...@pitrou.net wrote: On Thu, 2 May 2013 13:52:29 -0700 Eli Bendersky eli...@gmail.com 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()

Re: [Python-Dev] PyPy, Jython, IronPython: Enum convenience function and pickleablity

2013-05-02 Thread Barry Warsaw
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

Re: [Python-Dev] PyPy, Jython, IronPython: Enum convenience function and pickleablity

2013-05-02 Thread Benjamin Peterson
2013/5/2 Eli Bendersky eli...@gmail.com: On Thu, May 2, 2013 at 1:10 PM, Antoine Pitrou solip...@pitrou.net wrote: On Thu, 2 May 2013 15:48:14 -0400 Benjamin Peterson benja...@python.org wrote: 2013/5/2 Ethan Furman et...@stoneleaf.us: In order for the Enum convenience function to be

Re: [Python-Dev] PyPy, Jython, IronPython: Enum convenience function and pickleablity

2013-05-02 Thread Antoine Pitrou
On Thu, 2 May 2013 14:16:34 -0700 Barry Warsaw ba...@python.org 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

Re: [Python-Dev] PyPy, Jython, IronPython: Enum convenience function and pickleablity

2013-05-02 Thread Antoine Pitrou
On Thu, 2 May 2013 14:15:40 -0700 Eli Bendersky eli...@gmail.com 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

Re: [Python-Dev] PyPy, Jython, IronPython: Enum convenience function and pickleablity

2013-05-02 Thread Amaury Forgeot d'Arc
2013/5/2 Guido van Rossum gu...@python.org On Thu, May 2, 2013 at 1:18 PM, fwierzbi...@gmail.com fwierzbi...@gmail.com wrote: On Thu, May 2, 2013 at 12:07 PM, Ethan Furman et...@stoneleaf.us wrote: In order for the Enum convenience function to be pickleable, we have this line of code in

Re: [Python-Dev] PyPy, Jython, IronPython: Enum convenience function and pickleablity

2013-05-02 Thread 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;

Re: [Python-Dev] [Python-checkins] peps: Add time(), call_at(). Remove call_repeatedly(). Get rid of add_*_handler()

2013-05-02 Thread Nick Coghlan
On 3 May 2013 08:34, guido.van.rossum python-check...@python.org wrote: http://hg.python.org/peps/rev/26947623fc5d changeset: 4870:26947623fc5d user:Guido van Rossum gu...@python.org date:Thu May 02 14:11:08 2013 -0700 summary: Add time(), call_at(). Remove

Re: [Python-Dev] PyPy, Jython, IronPython: Enum convenience function and pickleablity

2013-05-02 Thread Jeff Hardy
On Thu, May 2, 2013 at 1:18 PM, fwierzbi...@gmail.com fwierzbi...@gmail.com wrote: On Thu, May 2, 2013 at 12:07 PM, Ethan Furman et...@stoneleaf.us wrote: In order for the Enum convenience function to be pickleable, we have this line of code in the metaclass: enum_class.__module__ =

Re: [Python-Dev] PyPy, Jython, IronPython: Enum convenience function and pickleablity

2013-05-02 Thread Nick Coghlan
On 3 May 2013 08:00, Eli Bendersky eli...@gmail.com 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

Re: [Python-Dev] PyPy, Jython, IronPython: Enum convenience function and pickleablity

2013-05-02 Thread Guido van Rossum
On Thu, May 2, 2013 at 4:14 PM, Nick Coghlan ncogh...@gmail.com 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

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

2013-05-02 Thread Greg Ewing
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 ___

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

2013-05-02 Thread Greg Ewing
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

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

2013-05-02 Thread Ethan Furman
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~

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

2013-05-02 Thread Eli Bendersky
On Thu, May 2, 2013 at 4:50 PM, Ethan Furman et...@stoneleaf.us 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

Re: [Python-Dev] PyPy, Jython, IronPython: Enum convenience function and pickleablity

2013-05-02 Thread Barry Warsaw
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

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

2013-05-02 Thread Ethan Furman
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

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

2013-05-02 Thread Nick Coghlan
On Fri, May 3, 2013 at 9:57 AM, Ethan Furman et...@stoneleaf.us 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

Re: [Python-Dev] PEP-435 reference implementation

2013-05-02 Thread Nick Coghlan
On Thu, May 2, 2013 at 11:37 AM, Steven D'Aprano st...@pearwood.info 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

[Python-Dev] Tightening up the specification for locals()

2013-05-02 Thread 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

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

2013-05-02 Thread Barry Warsaw
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

Re: [Python-Dev] Tightening up the specification for locals()

2013-05-02 Thread Benjamin Peterson
2013/5/2 Nick Coghlan ncogh...@gmail.com: 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

Re: [Python-Dev] Tightening up the specification for locals()

2013-05-02 Thread Steven D'Aprano
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

Re: [Python-Dev] Tightening up the specification for locals()

2013-05-02 Thread Terry Jan Reedy
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

Re: [Python-Dev] PyPy, Jython, IronPython: Enum convenience function and pickleablity

2013-05-02 Thread Georg Brandl
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