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

> 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

Re: [Python-Dev] Enum: subclassing?

On 02/05/13 13:47, Steven D'Aprano wrote: The most obvious use-case for subclassing enums is to extend them: class Directions(Enum): north = 1 east = 2 west = 3 south = 4 class Directions3D(Directions): up = 5 down = 6 It doesn't necessarily follow that subclassing is the right mechanism for

Re: [Python-Dev] noob contributions to unit tests

On Thu, Mar 28, 2013 at 11:36 AM, Walter Dörwald wrote: > > Am 27.03.2013 um 03:24 schrieb R. David Murray : > >> On Tue, 26 Mar 2013 16:59:06 -0700, Maciej Fijalkowski >> wrote: >>> On Tue, Mar 26, 2013 at 4:49 PM, Sean Felipe Wolfe >>> wrote: Hey everybody how are you all :) I

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

On 02/05/13 02:43, Guido van Rossum wrote: Here's how I would implement "extending" an enum if subclassing were not allowed: class Color(Enum): red = 1 white = 2 blue = 3 class ExtraColor(Enum): orange = 4 yellow = 5 green = 6 flag_colors = set(Color) | set(ExtraColor) Now

Re: [Python-Dev] Enum: subclassing?

On 02/05/13 06:45, Antoine Pitrou wrote: I was talking in the context where subclassing is allowed. I don't think there's a use-case for subclassing of non-empty enums. On the other hand, empty enums should probably allow subclassing (they are "abstract base enums", in a way). If you google fo

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

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, an

Re: [Python-Dev] Enum: subclassing?

Yes. On Wed, May 1, 2013 at 3:51 PM, Ethan Furman wrote: > On 05/01/2013 02:07 PM, Guido van Rossum wrote: >> >> On Wed, May 1, 2013 at 2:04 PM, Eli Bendersky wrote: >>> >>> >>> class BehaviorMixin: >>># bla bla >>> >>> class MyBehavingIntEnum(int, BehaviorMixin, Enum): >>>foo = 1 >>>

Re: [Python-Dev] Enum: subclassing?

On 05/01/2013 02:07 PM, Guido van Rossum wrote: On Wed, May 1, 2013 at 2:04 PM, Eli Bendersky wrote: class BehaviorMixin: # bla bla class MyBehavingIntEnum(int, BehaviorMixin, Enum): foo = 1 bar = 2 It's a common pattern to do this with a base class rather than a mixin, though, and

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

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__'. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev

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

On 2 May 2013 02:46, "Guido van Rossum" wrote: > > On Wed, May 1, 2013 at 9:18 AM, Tres Seaver wrote: > > I'd be glad to drop both of those in favor of subclassing: I think the > > emphasis on "class-ness" makes no sense, given the driving usecases for > > adopting enums into the stdlib in the f

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

On 05/01/2013 02:36 PM, Tim Delaney wrote: On 2 May 2013 02:18, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/01/2013 12:14 PM, Guido van Rossum wrote: > But we'd probably have to give up something else, e.g. adding methods > to enums, or any hope th

Re: [Python-Dev] Enum: subclassing?

> >> Good point. I think this may be just an artifact of the implementation - >> PEP 435 prohibits implicit conversion to >> integers for non-IntEnum enums. Since IntEnum came into existence, >> there's no real need for int-opearbility of other >> enums, and their values can be arbitrary anyway. >>

Re: [Python-Dev] Enum: subclassing?

On Wed, May 1, 2013 at 3: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 T

Re: [Python-Dev] Enum: subclassing?

On 05/01/2013 02:48 PM, Eli Bendersky wrote: > Am 01.05.2013 20:04, schrieb Eli Bendersky: > > > Actually, in flufl.enum, IntEnum had to define a magic __value_factory__ > > attribute, but in the current ref435 implementation this isn't needed, so > > IntEnu

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

On 2 May 2013 02:22, "Christian Heimes" wrote: > > Am 01.05.2013 16:39, schrieb Guido van Rossum: > > I've not got the full context, but I would like to make it *very* > > clear in the API (e.g. through naming of the methods) when you are > > getting a possibly cached result from stat(), and I wou

Re: [Python-Dev] Enum: subclassing?

On Wed, May 1, 2013 at 2:52 PM, Georg Brandl wrote: > Am 01.05.2013 23:48, schrieb Eli Bendersky: > > > Well, my point is that you currently don't have to inherit from int > (or IntEnum) > > to get an __int__ method on your Enum, which is what I find > questionable. IMO > > conversio

Re: [Python-Dev] Enum: subclassing?

Am 01.05.2013 23:44, schrieb Georg Brandl: > Traceback (most recent call last): > File "/home/gbr/devel/ref435/ref435.py", line 84, in __new__ > enum_item = obj_type.__new__(result, value) > TypeError: object.__new__(SIPStatusCode) is not safe, use int.__new__() > > During handling of the a

Re: [Python-Dev] Enum: subclassing?

Am 01.05.2013 23:48, schrieb Eli Bendersky: > Well, my point is that you currently don't have to inherit from int (or > IntEnum) > to get an __int__ method on your Enum, which is what I find questionable. > IMO > conversion to integers should only be defined for IntEnums. (But I >

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

We can get a greater speed up for walkdir() without resorting to > caching, too. Some operating systems and file system report the file > type in the dirent struct that is returned by readdir(). This reduces > the number of stat calls to zero. > Yes, definitely. This is exactly what my os.walk()

Re: [Python-Dev] Enum: subclassing?

> > Am 01.05.2013 20:04, schrieb Eli Bendersky: > > > > > 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):

Re: [Python-Dev] Enum: subclassing?

Am 01.05.2013 23:19, schrieb Eli Bendersky: > It's a common pattern to do this with a base class rather than a > mixin, though, and I think the rule "only allow subclassing empty > enums" makes a lot of sense. > > > I see your point (and Antoine's example in the next email is good),

Re: [Python-Dev] Enum: subclassing?

Am 01.05.2013 22:09, schrieb Eli Bendersky: > > > > On Wed, May 1, 2013 at 11:47 AM, Georg Brandl > wrote: > > Am 01.05.2013 20:04, schrieb Eli Bendersky: > > > Actually, in flufl.enum, IntEnum had to define a magic __value_factory__ > > attribute, but in

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

On 2 May 2013 02:18, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 05/01/2013 12:14 PM, Guido van Rossum wrote: > > But we'd probably have to give up something else, e.g. adding methods > > to enums, or any hope that the instance/class/subclass relationships > > make

Re: [Python-Dev] Enum: subclassing?

Am 01.05.2013 22:05, schrieb Eli Bendersky: > > > > On Wed, May 1, 2013 at 11:59 AM, Georg Brandl > wrote: > > Am 01.05.2013 20:44, schrieb Antoine Pitrou: > > On Wed, 01 May 2013 10:21:30 -0700 > > Ethan Furman mailto:et...@stoneleaf.us>> wrote: > >> W

Re: [Python-Dev] Enum: subclassing?

On Wed, May 1, 2013 at 2:07 PM, Guido van Rossum wrote: > On Wed, May 1, 2013 at 2:04 PM, Eli Bendersky wrote: > > > > > > > > On Wed, May 1, 2013 at 2:00 PM, Antoine Pitrou > wrote: > >> > >> On Wed, 1 May 2013 13:57:11 -0700 > >> Eli Bendersky wrote: > >> > > >> > I still don't understand wh

Re: [Python-Dev] Enum: subclassing?

On Wed, May 1, 2013 at 2:04 PM, Eli Bendersky wrote: > > > > On Wed, May 1, 2013 at 2:00 PM, Antoine Pitrou wrote: >> >> On Wed, 1 May 2013 13:57:11 -0700 >> Eli Bendersky wrote: >> > >> > I still don't understand what you mean, sorry. Like, this: >> > >> > class MyEmptyEnum(Enum): >> > pass >

Re: [Python-Dev] Enum: subclassing?

On Wed, 1 May 2013 14:04:11 -0700 Eli Bendersky wrote: > > You mean this? > > class BehaviorMixin: > # bla bla > > class MyBehavingIntEnum(int, BehaviorMixin, Enum): > foo = 1 > bar = 2 Yes, but without the need for multiple inheritance and separate mixins ;-) Especially if the behaviour

Re: [Python-Dev] Enum: subclassing?

On Wed, May 1, 2013 at 2:00 PM, Antoine Pitrou wrote: > On Wed, 1 May 2013 13:57:11 -0700 > Eli Bendersky wrote: > > > > I still don't understand what you mean, sorry. Like, this: > > > > class MyEmptyEnum(Enum): > > pass > > > > Why would you want to subclass MyEmptyEnum ? > > > > Or do you m

Re: [Python-Dev] Enum: subclassing?

On Wed, 1 May 2013 13:57:11 -0700 Eli Bendersky wrote: > > I still don't understand what you mean, sorry. Like, this: > > class MyEmptyEnum(Enum): > pass > > Why would you want to subclass MyEmptyEnum ? > > Or do you mean this: > > class IntEnum(int, Enum): > pass > > Now I can have: >

Re: [Python-Dev] Enum: subclassing?

On Wed, May 1, 2013 at 1:45 PM, Antoine Pitrou wrote: > On Wed, 1 May 2013 13:43:22 -0700 > Eli Bendersky wrote: > > > On Wed, May 1, 2013 at 1:33 PM, Antoine Pitrou > wrote: > > > > > On Wed, 1 May 2013 13:05:53 -0700 > > > Eli Bendersky wrote: > > > > On Wed, May 1, 2013 at 11:59 AM, Georg B

Re: [Python-Dev] Enum: subclassing?

On Wed, 1 May 2013 13:43:22 -0700 Eli Bendersky wrote: > On Wed, May 1, 2013 at 1:33 PM, Antoine Pitrou wrote: > > > On Wed, 1 May 2013 13:05:53 -0700 > > Eli Bendersky wrote: > > > On Wed, May 1, 2013 at 11:59 AM, Georg Brandl wrote: > > > > > > > Am 01.05.2013 20:44, schrieb Antoine Pitrou:

Re: [Python-Dev] Enum: subclassing?

On Wed, May 1, 2013 at 1:33 PM, Antoine Pitrou wrote: > On Wed, 1 May 2013 13:05:53 -0700 > Eli Bendersky wrote: > > On Wed, May 1, 2013 at 11:59 AM, Georg Brandl wrote: > > > > > Am 01.05.2013 20:44, schrieb Antoine Pitrou: > > > > On Wed, 01 May 2013 10:21:30 -0700 > > > > Ethan Furman wrote

Re: [Python-Dev] Enum: subclassing?

On Wed, 1 May 2013 13:05:53 -0700 Eli Bendersky wrote: > On Wed, May 1, 2013 at 11:59 AM, Georg Brandl wrote: > > > Am 01.05.2013 20:44, schrieb Antoine Pitrou: > > > On Wed, 01 May 2013 10:21:30 -0700 > > > Ethan Furman wrote: > > >> We may not want to /completely/ disallow subclassing. Consi

Re: [Python-Dev] Enum: subclassing?

On Wed, May 1, 2013 at 11:47 AM, Georg Brandl wrote: > Am 01.05.2013 20:04, schrieb Eli Bendersky: > > > 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 IntEnu

Re: [Python-Dev] Enum: subclassing?

On Wed, May 1, 2013 at 11:59 AM, Georg Brandl wrote: > Am 01.05.2013 20:44, schrieb Antoine Pitrou: > > On Wed, 01 May 2013 10:21:30 -0700 > > Ethan Furman wrote: > >> We may not want to /completely/ disallow subclassing. Consider: > >> > >> --> class StrEnum(str, Enum): > >> ...'''string e

Re: [Python-Dev] Enum: subclassing?

Am 01.05.2013 20:44, schrieb Antoine Pitrou: > On Wed, 01 May 2013 10:21:30 -0700 > Ethan Furman wrote: >> We may not want to /completely/ disallow subclassing. Consider: >> >> --> class StrEnum(str, Enum): >> ...'''string enums for Business Basic variable names''' >> ... >> --> class Vendor

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

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 F

Re: [Python-Dev] Enum: subclassing?

Am 01.05.2013 20:04, schrieb Eli Bendersky: > 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 subcl

Re: [Python-Dev] Enum: subclassing?

On Wed, 01 May 2013 10:21:30 -0700 Ethan Furman wrote: > We may not want to /completely/ disallow subclassing. Consider: > > --> class StrEnum(str, Enum): > ...'''string enums for Business Basic variable names''' > ... > --> class Vendors(StrEnum): > EnumError: subclassing not allowed I don

Re: [Python-Dev] Enum: subclassing?

On Wed, May 1, 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 i

Re: [Python-Dev] Enum: subclassing?

On Wed, May 1, 2013 at 10:48 AM, Guido van Rossum wrote: > On Wed, May 1, 2013 at 10:21 AM, Ethan Furman wrote: > > We may not want to /completely/ disallow subclassing. Consider: > > > > --> class StrEnum(str, Enum): > > ...'''string enums for Business Basic variable names''' > > ... > > -

Re: [Python-Dev] Enum: subclassing?

On Wed, May 1, 2013 at 10:21 AM, Ethan Furman wrote: > We may not want to /completely/ disallow subclassing. Consider: > > --> class StrEnum(str, Enum): > ...'''string enums for Business Basic variable names''' > ... > --> class Vendors(StrEnum): > EnumError: subclassing not allowed > > > My

[Python-Dev] Enum: subclassing?

We may not want to /completely/ disallow subclassing. Consider: --> class StrEnum(str, Enum): ...'''string enums for Business Basic variable names''' ... --> class Vendors(StrEnum): EnumError: subclassing not allowed My point is that IntEnum, StrEnum, ListEnum, FloatEnum are all "subclasse

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

On Wed, May 1, 2013 at 9:18 AM, Tres Seaver wrote: > I'd be glad to drop both of those in favor of subclassing: I think the > emphasis on "class-ness" makes no sense, given the driving usecases for > adopting enums into the stdlib in the first place. IOW, I would vote > that real-world usecases

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

Am 01.05.2013 17:09, schrieb Ethan Furman: > New repo to avoid confusion: > > https://bitbucket.org/stoneleaf/ref435 > > which has the latest updates from the feedback. > > Subclassing is again disabled. Let's get the rest of it done, then we can > come back to that issue if necessary. Thanks.

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/01/2013 12:14 PM, Guido van Rossum wrote: > But we'd probably have to give up something else, e.g. adding methods > to enums, or any hope that the instance/class/subclass relationships > make any sense. I'd be glad to drop both of those in favor

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

Am 01.05.2013 16:39, schrieb Guido van Rossum: > I've not got the full context, but I would like to make it *very* > clear in the API (e.g. through naming of the methods) when you are > getting a possibly cached result from stat(), and I would be very > concerned if existing APIs were going to get

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

Am 01.05.2013 17:35, schrieb Steven D'Aprano: > On 02/05/13 01:09, Ethan Furman wrote: >> New repo to avoid confusion: >> >> https://bitbucket.org/stoneleaf/ref435 > > Apparently I have to log in before I can even see the repo. > > Not going to happen. I'm sure he made the repo private by accide

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

Personally I would probably compare enums using ==, but I agree that 'is' should also work -- since the instances are predefined there's no reason to ever have multiple equivalent instances, so we might as well guarantee it. I'm sorry that my requirements for the relationship between the enum clas

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

On May 01, 2013, at 12:19 AM, Glenn Linderman wrote: >Can Things('foo') lookup by name and Things['foo'] lookup by value? Or does >that confuse things too? I think it confuses things too much. Why isn't getattr() for lookup by name good enough? It is for regular classes. -Barry ___

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

On Apr 30, 2013, at 10:50 PM, Ethan Furman wrote: >The way I had subclassing working originally was for the subclass to create >it's own versions of the superclass' enum items -- they weren't the same >object, but they were equal: > >--> class Color(Enum): >... red = 1 >... green = 2 >...

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

On 05/01/2013 08:35 AM, Steven D'Aprano wrote: On 02/05/13 01:09, Ethan Furman wrote: New repo to avoid confusion: https://bitbucket.org/stoneleaf/ref435 Apparently I have to log in before I can even see the repo. Not going to happen. Sorry, just made it public. Try again? -- ~Ethan~ ___

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

I can see it just fine without logging in, even in an Incognito Chrome window. On Wed, May 1, 2013 at 8:35 AM, Steven D'Aprano wrote: > On 02/05/13 01:09, Ethan Furman wrote: >> >> New repo to avoid confusion: >> >> https://bitbucket.org/stoneleaf/ref435 > > > Apparently I have to log in before I

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

On 02/05/13 01:09, Ethan Furman wrote: New repo to avoid confusion: https://bitbucket.org/stoneleaf/ref435 Apparently I have to log in before I can even see the repo. Not going to happen. -- Steven ___ Python-Dev mailing list Python-Dev@python.or

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

New repo to avoid confusion: https://bitbucket.org/stoneleaf/ref435 which has the latest updates from the feedback. Subclassing is again disabled. Let's get the rest of it done, then we can come back to that issue if necessary. -- ~Ethan~ ___ Pytho

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

I've not got the full context, but I would like to make it *very* clear in the API (e.g. through naming of the methods) when you are getting a possibly cached result from stat(), and I would be very concerned if existing APIs were going to get caching behavior. For every use cases that benefits fro

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

On 1 May 2013 22:58, "Charles-François Natali" wrote: > > > 3) Leave it up to performance critical code, such as the import > > machinery, or walkdirs that Nick mentioned, to do their own caching, and > > simplify the filepath API for the simple case. > > > > But one can still make life easier for

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

On 05/01/2013 12:05 AM, Steven D'Aprano wrote: On Tue, Apr 30, 2013 at 09:19:49PM -0700, Ethan Furman wrote: Latest code available at https://bitbucket.org/stoneleaf/aenum. Ethan, you seem to be writing a completely new PEP in opposition to Barry's PEP 435. But your implementation doesn't seem

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

> 3) Leave it up to performance critical code, such as the import > machinery, or walkdirs that Nick mentioned, to do their own caching, and > simplify the filepath API for the simple case. > > But one can still make life easier for code like that, by adding > is_file() and friends on the stat resu

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

Antoine and Nick have convinced me that stat() calls can be a performance issue. I am still concerned about the best way to balance that against the need to keep the API simple, though. I'm still worried about the current behaviour that some path can answer True to is_file() in a long-running pro

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

Hi, On Wed, 01 May 2013 09:32:28 +0200 Pieter Nagel wrote: > Hi all, > > I write as a python lover for over 13 years who's always wanted > something like PEP 428 in Python. > > I am concerned about the caching of stat() results as currently defined > in the PEP. This means that all behaviour

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

On Wed, May 1, 2013 at 5:32 PM, Pieter Nagel wrote: > Isn't the whole notion that stat() need to be cached for performance > issues somewhat of a historical relic of older OS's and filesystem > performance? AFAIK linux already has stat() caching as a side-effect of > the filesystem layer's metadat

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

Hi all, I write as a python lover for over 13 years who's always wanted something like PEP 428 in Python. I am concerned about the caching of stat() results as currently defined in the PEP. This means that all behaviour built on top of stat(), such as p.is_dir(), p.is_file(), p.st_size and the l

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

On 4/30/2013 11:08 PM, Barry Warsaw wrote: On Apr 28, 2013, at 07:46 PM, Ethan Furman wrote: and similarly, Enum behavior /should be/ (in my opinion ;) Season.AUTUMN is Season('AUTUMN') is Season(3) I think you'll have a problem with this. flufl.enum did this, but it has an inherent conflict

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

On 4/30/2013 9:19 PM, Ethan Furman wrote: Latest code available at https://bitbucket.org/stoneleaf/aenum. --> class Color(Enum): ... red = 1 ... green = 2 ... blue = 3 Enum items are virtual attributes looked by EnumType's __getattr__. The win here is that --> Color.red.green.bl

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

On Tue, Apr 30, 2013 at 09:19:49PM -0700, Ethan Furman wrote: > Latest code available at https://bitbucket.org/stoneleaf/aenum. > > --> class Color(Enum): > ... red = 1 > ... green = 2 > ... blue = 3 Ethan, you seem to be writing a completely new PEP in opposition to Barry's PEP 435.

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

On 04/30/2013 10:41 PM, Barry Warsaw wrote: What does it break if you remove the `if base._enum` check? I mean, can we be consenting adults here or not? I removed the error and added a couple lines to EnumType.__getattr_, and now subclassing works as I think you are used to it working. Ver