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

[Ethan Furman]

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.


Very unsure on this change being permanent (I have no objections to it).

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Steven D'Aprano]

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. But your implementation doesn't seem to match what your 
proto-PEP claims.

Your proto-PEP (file enum.txt) says:

``Enum` - a valueless, unordered type.  It's related integer value is merely to
allow for database storage and selection from the enumerated class. An
``Enum`` will not compare equal with its integer value, but can compare 
equal
to other enums of which it is a subclass.


but:


py> import aenum
py> class Color(aenum.Enum):
... red = 1
... 
py> Color.red == 1
True
py> type(Color.red) is int
True


So the implemented behaviour is completely different from the documented 
behaviour. What gives?

Given the vast number of words written about enum values being instances 
of the enum class, I'm surprised that your proto-PEP doesn't seem to 
mention one word about that. All it says is that enum values are 
singletons. (Unless I've missed something.)



-- 
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Glenn Linderman]

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.blue

no longer works.  ;)


Color.red.green.blue not working seems like a win.

Still seems like it should be possible to look them up from a subclass, 
though.


--> class FancyColor( Color ):
...'strikes my fancy'

--> FancyColor['red']
Color.red



Subclassing an implemented Enum class now raises an error (is there a 
better word than 'implemented'?)


--> class MoreColor(Color):
... cyan = 4
... magenta = 5
... yellow = 6

Traceback (most recent call last):
  File "", line 1, in 
  File "./ref435.py", line 83, in __new__
raise EnumError("cannot subclass an implemented Enum class")
ref435.EnumError: cannot subclass an implemented Enum class


Yes, I think raising an error is appropriate, if implementing Guido's 
"no subclass" comments, rather than treating what otherwise would look 
like enumeration settings as subclass attributes.


My suggested error wording would be "Cannot define additional 
enumeration items in a subclass".


That allows for "original enumeration items" to be defined in a 
subclass, of course.  And it isn't the subclassing that is disallowed, 
but the definition of more enumeration items that is disallowed.  At 
least, I hope that is the case.


Then, should consenting adults lift the restriction, there wouldn't be 
surprises in other code.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Glenn Linderman]

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, which is why we removed the getattr-like behavior.

class Things(Enum):
 foo = 'bar'
 bar = 'foo'

What does Things('foo') return?

Note that it doesn't matter if that's spelled Things['foo'].

Whether it's defined as lookup or instance "creation", you should only map
values to items, and not attribute names to items, and definitely not both.
Let getattr() do attribute name lookup just like normal.


I agree that it is confusing to be able to index by either the name of 
the enum or its value, in the same method.  The current implementation 
prefers the names, but will check values if the name is not found, I 
discovered by experimentation, after reading the tests.  But when there 
are conflicts (which would be confusing at best), the inability to look 
up some enumerations by value, because the one with that name is found 
first, would be even more confusing.


Can Things('foo') lookup by name and Things['foo'] lookup by value? Or 
does that confuse things too?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Pieter Nagel]

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 like can indefinitely hold
on to stale data until restat() is called, and I consider this
confusing.

Perhaps in recognition of this, p.exists() is implemented differently,
and it does restat() internally (although the PEP does not document
this).

If this behaviour is maintained, then at the very least this makes the
API more complicated to document: some calls cache as a side effect,
others update the cache as a side effect, and others, such as lstat(),
don't cache at all.

This also introduces a divergence of behaviour between os.path.isfile()
and p.is_file(), that is confusing and will also need to be documented.

I'm concerned about scenarios like users of the library polling, for
example, for some file to appear, and being confused about why the
arguably more sloppy poll for p.exists() works while a poll for
p.is_file(), which expresses intent better, never terminates.

In theory the caching mechanism could be further refined to only hold
onto cached results for a limited amount of time, but I would argue this
is unnecessary complexity, and caching should just be removed, along
with restat(). 

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 metadata caching. How does Windows and Mac OS
fare here? Are there benchmarks proving that this is serious enough to
complicate the API?

If the ability to cache stat() calls is deemed important enough, how
about a different API where is_file(), is_dir() and the like are added
as methods on the result object that stat() returns? Then one can hold
onto a stat() result as a temporary object and ask it multiple questions
without doing another OS call, and is_file() etc. on the Path object can
be documented as being forwarders to the stat() result just as p.st_size
is currently - except that I believe they should forward to a fresh,
uncached stat() call every time.


I write directly to this list instead raising it to Antoine Pitrou in
private just because I don't want to make extra work for him to first
receive my feedback and the re-raise it on this list. If this is wrong
or disrespectful, I apologize.

-- 
Pieter Nagel


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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 metadata caching. How does Windows and Mac OS
> fare here? Are there benchmarks proving that this is serious enough to
> complicate the API?

System calls typically release the GIL in threaded code (due to the
possibility the underlying filesystem may be a network mount), which
ends up being painfully expensive.

The repeated stat calls also appear to be one of the main reasons
walkdir is so much slower than performing the same operations in a
loop rather than using a generator pipeline as walkdir does (see
http://walkdir.readthedocs.org), although I admit it was a year or two
ago I made those comparisons, and it wasn't the most scientific of
benchmarking efforts.

Cheers,
Nick.

--
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Antoine Pitrou]

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 built on top of stat(), such
> as p.is_dir(), p.is_file(), p.st_size and the like can indefinitely hold
> on to stale data until restat() is called, and I consider this
> confusing.

I understand it might be confusing. On the other hand, if you call
is_dir() then is_file() (then perhaps another metadata-reading
operation), and there's a race condition where the file is modified
in-between, you could have pretty much nonsensical results, if not for
the caching.

> 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 metadata caching. How does Windows and Mac OS
> fare here? Are there benchmarks proving that this is serious enough to
> complicate the API?

Surprisingly enough, some network filesystems have rather bad stat()
performance. This has been reported for years as an issue with Python's
import machinery, until 3.3 added a caching scheme where stat() calls
are no more issued for each and every path directory and each and every
imported module.

But as written above caching is also a matter of functionality. I'll
let other people chime in.

> If the ability to cache stat() calls is deemed important enough, how
> about a different API where is_file(), is_dir() and the like are added
> as methods on the result object that stat() returns?

That's a good idea too. It isn't straightforward since os.stat() is
implemented in C.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Pieter Nagel]

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 process just because it had been a
file last week.

In my experience there are use cases where most stat() calls one makes
(including indirectly via is_file() and friends) want up-to-date data.
There is also the risk of obtaining a Path object that already had its
stat() value cached some time ago without your knowledge (i.e. if the
Path was created for you by a walkdir type function that in its turn
also called is_file() before returning the result).

And needing to precede each is_file() etc. call with a restat() call
whose return value is not even used introduces undesirable temporal
coupling between the restat() and is_file() call.

I see a few alternative solution, not mutually exclusive:

1) Change the signature of stat(), and everything that indirectly uses
stat(), to take an optional 'fresh' keyword argument (or some synonym).
Then stat(fresh=True) becomes synonymous with the current restat(), and
the latter can be removed. Queries like is_file(fresh=True) will be
implemented by forwarding fresh to the underlying stat() call they are
implemented on.

What the default for 'fresh' should be, can be debated, but I'd argue
for the sake of naive code that fresh should default to True, and then
code that is aware of stat() caching can use fresh=False as required.

2) The root of the issue is keeping the cached stat() value
indefinitely.

Therefore, limit the duration for which the cached value is valid. The
challenge is to find a way to express how long the value should be
cached, without needing to call time.monotonic() or the like that
presumable are also OS calls that will release the GIL.

One way would be to compute the number of virtual machine instructions
executed since the stat() call was cached, and set the limit there. Is
that still possible, now that sys.setcheckinterval() has been gutted?

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 result object as I suggested.

But this almost sounds like a PEP of its own, because although pahtlib
will benefit by it, it is actually an orthogonal issue.

It raises all kinds of issues: should the signature be
statresult.isfile() to match os.path, or statresult.is_file() to match
PEP 428?

-- 
Pieter Nagel


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Charles-François Natali]

> 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 result object as I suggested.

+1 from me.
PEP 428 goes in the right direction with a distinction between "pure"
path and "concrete" path. Pure path support syntactic operations,
whereas I would expect concrete paths to actually access the file
system. Having a method like restat() is a hint that something's
wrong, I'm convinced this will bite some people.

I'm also be in favor of having a wrapper class around os.stat() result
which would export utility methods such as is_file()/is_directory()
and owner/group, etc attributes.

That way, the default behavior would be correct, and this helper class
would make it easier for users like walkdir() to implement their own
caching.

As an added benefit, this would make path objects actually immutable,
which is always a good thing (simpler, and you get thread-safety for
free).
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ethan Furman]

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 to match what your
proto-PEP claims.


aenum.py was my original competitor for enums; the files you should be paying attention to are the *ref435* files, as 
stated in the original post. (The stars are for pattern matching, not bolding.)


Apologies for any confusion.

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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 code like that, by adding
> > is_file() and friends on the stat result object as I suggested.
>
> +1 from me.
> PEP 428 goes in the right direction with a distinction between "pure"
> path and "concrete" path. Pure path support syntactic operations,
> whereas I would expect concrete paths to actually access the file
> system. Having a method like restat() is a hint that something's
> wrong, I'm convinced this will bite some people.
>
> I'm also be in favor of having a wrapper class around os.stat() result
> which would export utility methods such as is_file()/is_directory()
> and owner/group, etc attributes.
>
> That way, the default behavior would be correct, and this helper class
> would make it easier for users like walkdir() to implement their own
> caching.

Walkdir is deliberately built as a decoupled pipeline modelled on os.walk -
the only way it can really benefit from caching without destroying the API
is if the caching is built into the underlying path objects that are then
passed through the pipeline stages.

However, I like the idea of a rich "stat" object, with "path.stat()" and
"path.cached_stat()" accessors on the path objects.

Up to date data by default, easy caching for use cases that need it without
needing to pass the stat data around separately.

Cheers,
Nick.

>
> As an added benefit, this would make path objects actually immutable,
> which is always a good thing (simpler, and you get thread-safety for
> free).
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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 caching behavior. For
every use cases that benefits from caching there's a complementary use
case that caching breaks. Since both use cases are important we must
offer both APIs, in a way that makes it clear to even the casual
reader of the code what's going on.


--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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.

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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.



--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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 can even see the repo.
>
> Not going to happen.
>
>
>
> --
> Steven
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ethan Furman]

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~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Barry Warsaw]

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
>... blue = 3
>
>--> class MoreColor(Color):
>... cyan = 4
>... magenta = 5
>... yellow = 6
>
>--> Color.red is MoreColor.red
>False
>
>--> Color.red == MoreColor.red
>True
>
>If you switched from `is` to `==` would this work for you?

Not really, because in practice you don't compare one enum against another
explicitly.  You have a value in a variable and you're comparing against a
literal enum.  So `is` is still the more natural spelling.

My point is, if you want enums to behave more class-like because you're using
the class syntax, then you shouldn't explicitly break this one class-like
behavior just to protect some users from themselves.  There doesn't even seem
to be an easy way to override the default behavior if you really wanted to do
it.

-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Barry Warsaw]

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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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
class and its values ends up forcing the decision not to allow
subclasses (and I really mean *no* subclasses, not just no subclasses
that add new values), but after thinking it all over I still think
this is the right way forward. Something has got to give, and I think
that disallowing subclasses is better than having the isinstance
relationships be inverted or having to test for enum-ness using
something other than isinstance.

I guess the only way to change my mind at this point would be to come
up with overwhelming evidence that subclassing enums is a very useful
feature without which enums are pretty much useless. 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.

Contravariance sucks.


On Wed, May 1, 2013 at 8:44 AM, Barry Warsaw  wrote:
> 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
>>... blue = 3
>>
>>--> class MoreColor(Color):
>>... cyan = 4
>>... magenta = 5
>>... yellow = 6
>>
>>--> Color.red is MoreColor.red
>>False
>>
>>--> Color.red == MoreColor.red
>>True
>>
>>If you switched from `is` to `==` would this work for you?
>
> Not really, because in practice you don't compare one enum against another
> explicitly.  You have a value in a variable and you're comparing against a
> literal enum.  So `is` is still the more natural spelling.
>
> My point is, if you want enums to behave more class-like because you're using
> the class syntax, then you shouldn't explicitly break this one class-like
> behavior just to protect some users from themselves.  There doesn't even seem
> to be an easy way to override the default behavior if you really wanted to do
> it.
>
> -Barry
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/guido%40python.org



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Georg Brandl]

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 accident just to keep you out.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Christian Heimes]

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 caching behavior. For
> every use cases that benefits from caching there's a complementary use
> case that caching breaks. Since both use cases are important we must
> offer both APIs, in a way that makes it clear to even the casual
> reader of the code what's going on.

I deem caching of stat calls as problematic. The correct and
contemporary result of a stat() call has security implications, too. For
example stat() is used to prevent TOCTOU race conditions such as [1].
Caching is useful but I would prefer explicit caching rather than
implicit and automatic caching of stat() results.

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.

Christian

[1]
https://www.securecoding.cert.org/confluence/display/seccode/POS01-C.+Check+for+the+existence+of+links+when+dealing+with+files

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Tres Seaver]

-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 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 trump hypothetical purity.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlGBQEMACgkQ+gerLs4ltQ6myQCZAZqKCR/6H6I8bogHtSwhTM9I
ok8AnjBKfFyuse6caMF085wBHvlrf0uA
=nJ5C
-END PGP SIGNATURE-

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Georg Brandl]

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. I'm reviewing the code and adding comments to
https://bitbucket.org/stoneleaf/ref435/commits/4d2c4b94cdd35022a8a3e50554794f4a1c956e46

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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 trump hypothetical purity.

Yeah, this is the dilemma. But what *are* the real-world use cases?
Please provide some.

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 I can test "c in flag_colors" to check whether c is a flag color.
I can also loop over flag_colors. If I want the colors in definition
order I could use a list instead:

ordered_flag_colors = list(Color) + list(ExtraColor)

But this would be less or more acceptable depending on whether it is a
common or esoteric use case.

--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Enum: subclassing?

[Ethan Furman]

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 "subclasses" of 
Enum.  To then have a subclass of
that, such as Season(StrEnum), is subclassing a subclass.

Now, if we do want to completely disallow it, we can ditch IntEnum and force 
the user to always specify the mixin
type:

--> class Season(str, Enum):
 .
 .
 .

--> class Names(str, Enum):
 .
 .
 .

But that's not very user friendly... although it's not too bad, either.

One consequence of the way it is now (IntEnum, StrEnum, etc., are allowed) is that one can put methods and other 
non-Enum item in a base class and then inherit from that for actual implemented Enum classes.


--> class StrEnum(str, Enum):
... def describe(self):
... print("Hi!  I'm a %s widget!" % self.value)
...

--> class Season(StrEnum):
... spring = 'green'
... summer = 'brown'
... autumn = 'red'
... winter = 'white'
...

--> class Planet(StrEnum):
... mars = 'red'
... earth = 'blue'
...

--> Season.summer.descripbe()
Hi!  I'm a brown widget!

--> Planet.earth.describe()
Hi!  I'm a blue widget!

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enum: subclassing?

[Guido van Rossum]

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 point is that IntEnum, StrEnum, ListEnum, FloatEnum are all "subclasses"
> of Enum.  To then have a subclass of
> that, such as Season(StrEnum), is subclassing a subclass.

True, and Enum itself also falls in this category. Maybe there could
be a special marker that you have to set in the class body (or a
keyword arg in the class statement) to flag that a class is meant as a
"category of enums" rather than a specific enum type. Such categorical
classes should not define any instances. (And maybe "defines no
instances" is enough to flag an Enum class as subclassable.)

> Now, if we do want to completely disallow it, we can ditch IntEnum and force
> the user to always specify the mixin
> type:
>
> --> class Season(str, Enum):
>  .
>  .
>  .
>
> --> class Names(str, Enum):
>  .
>  .
>  .
>
> But that's not very user friendly... although it's not too bad, either.

Indeed, given that we mostly want IntEnum as a last-resort backward
compatibility thing for os and socket, it may not be so bad.

> One consequence of the way it is now (IntEnum, StrEnum, etc., are allowed)
> is that one can put methods and other non-Enum item in a base class and then
> inherit from that for actual implemented Enum classes.
>
> --> class StrEnum(str, Enum):
> ... def describe(self):
> ... print("Hi!  I'm a %s widget!" % self.value)
> ...
>
> --> class Season(StrEnum):
> ... spring = 'green'
> ... summer = 'brown'
> ... autumn = 'red'
> ... winter = 'white'
> ...
>
> --> class Planet(StrEnum):
> ... mars = 'red'
> ... earth = 'blue'
> ...
>
> --> Season.summer.descripbe()
> Hi!  I'm a brown widget!
>
> --> Planet.earth.describe()
> Hi!  I'm a blue widget!

If the base class doesn't define any instances (and perhaps is marked
specifically for this purpose) I'm fine with that.

--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enum: subclassing?

[Eli Bendersky]

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'''
> > ...
> > --> class Vendors(StrEnum):
> > EnumError: subclassing not allowed
> >
> >
> > My point is that IntEnum, StrEnum, ListEnum, FloatEnum are all
> "subclasses"
> > of Enum.  To then have a subclass of
> > that, such as Season(StrEnum), is subclassing a subclass.
>
> True, and Enum itself also falls in this category. Maybe there could
> be a special marker that you have to set in the class body (or a
> keyword arg in the class statement) to flag that a class is meant as a
> "category of enums" rather than a specific enum type. Such categorical
> classes should not define any instances. (And maybe "defines no
> instances" is enough to flag an Enum class as subclassable.)
>
> > Now, if we do want to completely disallow it, we can ditch IntEnum and
> force
> > the user to always specify the mixin
> > type:
> >
> > --> class Season(str, Enum):
> >  .
> >  .
> >  .
> >
> > --> class Names(str, Enum):
> >  .
> >  .
> >  .
> >
> > But that's not very user friendly... although it's not too bad, either.
>
> Indeed, given that we mostly want IntEnum as a last-resort backward
> compatibility thing for os and socket, it may not be so bad.
>
>
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.:

class SocketFamily(int, Enum):
  AF_UNIX = 1
  AF_INET = 2

As opposed to having an IntEnum explicitly, this just saves 2 characters
(comma+space), but is more explicit (zen!) and helps us avoid the
special-casing the subclass restriction implementation.

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enum: subclassing?

[Guido van Rossum]

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 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.:
>
> class SocketFamily(int, Enum):
>   AF_UNIX = 1
>   AF_INET = 2
>
> As opposed to having an IntEnum explicitly, this just saves 2 characters
> (comma+space), but is more explicit (zen!) and helps us avoid the
> special-casing the subclass restriction implementation.

Sounds good to me.

--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enum: subclassing?

[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 Vendors(StrEnum):
> EnumError: subclassing not allowed

I don't see the point of disallowing subclassing. It sounds like
a pointless restriction.

However, perhaps the constructor should forbid the returning of a base
type, e.g.:

class Season(Enum):
spring = 1

class MySeason(Season):
"""I look nicer than Season"""

MySeason('spring')
...
ValueError: Season.spring is not a MySeason instance

(what this means is perhaps the subclassing of non-empty enum classes
should be forbidden)

Regards

Antoine.


> 
> 
> My point is that IntEnum, StrEnum, ListEnum, FloatEnum are all "subclasses" 
> of Enum.  To then have a subclass of
> that, such as Season(StrEnum), is subclassing a subclass.
> 
> Now, if we do want to completely disallow it, we can ditch IntEnum and force 
> the user to always specify the mixin
> type:
> 
> --> class Season(str, Enum):
>   .
>   .
>   .
> 
> --> class Names(str, Enum):
>   .
>   .
>   .
> 
> But that's not very user friendly... although it's not too bad, either.
> 
> One consequence of the way it is now (IntEnum, StrEnum, etc., are allowed) is 
> that one can put methods and other 
> non-Enum item in a base class and then inherit from that for actual 
> implemented Enum classes.
> 
> --> class StrEnum(str, Enum):
> ... def describe(self):
> ... print("Hi!  I'm a %s widget!" % self.value)
> ...
> 
> --> class Season(StrEnum):
> ... spring = 'green'
> ... summer = 'brown'
> ... autumn = 'red'
> ... winter = 'white'
> ...
> 
> --> class Planet(StrEnum):
> ... mars = 'red'
> ... earth = 'blue'
> ...
> 
> --> Season.summer.descripbe()
> Hi!  I'm a brown widget!
> 
> --> Planet.earth.describe()
> Hi!  I'm a blue widget!
> 
> --
> ~Ethan~



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enum: subclassing?

[Georg Brandl]

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 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.:
> 
> class SocketFamily(int, Enum):
>   AF_UNIX = 1
>   AF_INET = 2
> 
> As opposed to having an IntEnum explicitly, this just saves 2 characters
> (comma+space), but is more explicit (zen!) and helps us avoid the 
> special-casing
> the subclass restriction implementation.

Wait a moment... it might not be immediately useful for IntEnums (however,
that's because base Enum currently defines __int__ which I find questionable),
but with  current ref435 you *can* create your own enum base classes with your
own methods, and derive concrete enums from that.  It also lets you have a
base class for enums and use it in isinstance().

If you forbid subclassing completely that will be impossible.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Larry Hastings]

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.


//arry/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enum: subclassing?

[Georg Brandl]

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 Vendors(StrEnum):
>> EnumError: subclassing not allowed
> 
> I don't see the point of disallowing subclassing. It sounds like
> a pointless restriction.
> 
> However, perhaps the constructor should forbid the returning of a base
> type, e.g.:
> 
> class Season(Enum):
> spring = 1
> 
> class MySeason(Season):
> """I look nicer than Season"""
> 
> MySeason('spring')
> ...
> ValueError: Season.spring is not a MySeason instance
> 
> (what this means is perhaps the subclassing of non-empty enum classes
> should be forbidden)

That's exactly what's implemented in the ref435 code at the moment.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enum: subclassing?

[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  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't see the point of disallowing subclassing. It sounds like
> > a pointless restriction.
> >
> > However, perhaps the constructor should forbid the returning of a base
> > type, e.g.:
> >
> > class Season(Enum):
> > spring = 1
> >
> > class MySeason(Season):
> > """I look nicer than Season"""
> >
> > MySeason('spring')
> > ...
> > ValueError: Season.spring is not a MySeason instance
> >
> > (what this means is perhaps the subclassing of non-empty enum classes
> > should be forbidden)
>
> That's exactly what's implemented in the ref435 code at the moment.
>
>
It can't be because __call__ is by-value lookup, not by-name lookup.
By-name lookup is Season.spring or getattr(Season, 'spring')

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enum: subclassing?

[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 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.:
> >
> > class SocketFamily(int, Enum):
> >   AF_UNIX = 1
> >   AF_INET = 2
> >
> > As opposed to having an IntEnum explicitly, this just saves 2 characters
> > (comma+space), but is more explicit (zen!) and helps us avoid the
> special-casing
> > the subclass restriction implementation.
>
> Wait a moment... it might not be immediately useful for IntEnums (however,
> that's because base Enum currently defines __int__ which I find
> questionable),
> but with  current ref435 you *can* create your own enum base classes with
> your
> own methods, and derive concrete enums from that.  It also lets you have a
> base class for enums and use it in isinstance().
>
> If you forbid subclassing completely that will be impossible.
>

I'm not sure what you mean, Georg, could you clarify?
This works:

>>> from ref435 import Enum
>>> class SocketFamily(int, Enum):
...   AF_UNIX = 1
...   AF_INET = 2
...
>>> SocketFamily.AF_INET
SocketFamily.AF_INET [value=2]
>>> SocketFamily.AF_INET == 2
True
>>> type(SocketFamily.AF_INET)

>>> isinstance(SocketFamily.AF_INET, SocketFamily)
True

Now, with the way things are currently implemented, class IntEnum is just
syntactic sugar for above. Guido decided against allowing any kind of
subclassing, but as an implementation need we should keep some restricted
form to implement IntEnum. But is IntEnum really needed if the above
explicit multiple-inheritance of int and Enum is possible?

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enum: subclassing?

[Antoine Pitrou]

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.  Consider:
> > >>
> > >> --> class StrEnum(str, Enum):
> > >> ...'''string enums for Business Basic variable names'''
> > >> ...
> > >> --> class Vendors(StrEnum):
> > >> EnumError: subclassing not allowed
> > >
> > > I don't see the point of disallowing subclassing. It sounds like
> > > a pointless restriction.
> > >
> > > However, perhaps the constructor should forbid the returning of a base
> > > type, e.g.:
> > >
> > > class Season(Enum):
> > > spring = 1
> > >
> > > class MySeason(Season):
> > > """I look nicer than Season"""
> > >
> > > MySeason('spring')
> > > ...
> > > ValueError: Season.spring is not a MySeason instance
> > >
> > > (what this means is perhaps the subclassing of non-empty enum classes
> > > should be forbidden)
> >
> > That's exactly what's implemented in the ref435 code at the moment.
> >
> >
> It can't be because __call__ is by-value lookup, not by-name lookup.

Ok, I've mixed up the example. But, still, since Season(1) should
return the Season.spring singleton, I don't see any reasonable thing
for MySeason(1) to return. Hence the request to raise an exception.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enum: subclassing?

[Eli Bendersky]

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:
> > > >> 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't see the point of disallowing subclassing. It sounds like
> > > > a pointless restriction.
> > > >
> > > > However, perhaps the constructor should forbid the returning of a
> base
> > > > type, e.g.:
> > > >
> > > > class Season(Enum):
> > > > spring = 1
> > > >
> > > > class MySeason(Season):
> > > > """I look nicer than Season"""
> > > >
> > > > MySeason('spring')
> > > > ...
> > > > ValueError: Season.spring is not a MySeason instance
> > > >
> > > > (what this means is perhaps the subclassing of non-empty enum classes
> > > > should be forbidden)
> > >
> > > That's exactly what's implemented in the ref435 code at the moment.
> > >
> > >
> > It can't be because __call__ is by-value lookup, not by-name lookup.
>
> Ok, I've mixed up the example. But, still, since Season(1) should
> return the Season.spring singleton, I don't see any reasonable thing
> for MySeason(1) to return. Hence the request to raise an exception.
>

What do you need MySeason for, though? IIUC, you don't ask to allow adding
enum values in it, so it only leaves adding extra functionality (methods)?
What are the use cases?

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enum: subclassing?

[Antoine Pitrou]

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:
> > > > > 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't see the point of disallowing subclassing. It sounds like
> > > > > a pointless restriction.
> > > > >
> > > > > However, perhaps the constructor should forbid the returning of a
> > base
> > > > > type, e.g.:
> > > > >
> > > > > class Season(Enum):
> > > > > spring = 1
> > > > >
> > > > > class MySeason(Season):
> > > > > """I look nicer than Season"""
> > > > >
> > > > > MySeason('spring')
> > > > > ...
> > > > > ValueError: Season.spring is not a MySeason instance
> > > > >
> > > > > (what this means is perhaps the subclassing of non-empty enum classes
> > > > > should be forbidden)
> > > >
> > > > That's exactly what's implemented in the ref435 code at the moment.
> > > >
> > > >
> > > It can't be because __call__ is by-value lookup, not by-name lookup.
> >
> > Ok, I've mixed up the example. But, still, since Season(1) should
> > return the Season.spring singleton, I don't see any reasonable thing
> > for MySeason(1) to return. Hence the request to raise an exception.
> >
> 
> What do you need MySeason for, though? IIUC, you don't ask to allow adding
> enum values in it, so it only leaves adding extra functionality (methods)?
> What are the use cases?

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).

Regards

Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enum: subclassing?

[Eli Bendersky]

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 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 enums for Business Basic variable names'''
> > > > > >> ...
> > > > > >> --> class Vendors(StrEnum):
> > > > > >> EnumError: subclassing not allowed
> > > > > >
> > > > > > I don't see the point of disallowing subclassing. It sounds like
> > > > > > a pointless restriction.
> > > > > >
> > > > > > However, perhaps the constructor should forbid the returning of a
> > > base
> > > > > > type, e.g.:
> > > > > >
> > > > > > class Season(Enum):
> > > > > > spring = 1
> > > > > >
> > > > > > class MySeason(Season):
> > > > > > """I look nicer than Season"""
> > > > > >
> > > > > > MySeason('spring')
> > > > > > ...
> > > > > > ValueError: Season.spring is not a MySeason instance
> > > > > >
> > > > > > (what this means is perhaps the subclassing of non-empty enum
> classes
> > > > > > should be forbidden)
> > > > >
> > > > > That's exactly what's implemented in the ref435 code at the moment.
> > > > >
> > > > >
> > > > It can't be because __call__ is by-value lookup, not by-name lookup.
> > >
> > > Ok, I've mixed up the example. But, still, since Season(1) should
> > > return the Season.spring singleton, I don't see any reasonable thing
> > > for MySeason(1) to return. Hence the request to raise an exception.
> > >
> >
> > What do you need MySeason for, though? IIUC, you don't ask to allow
> adding
> > enum values in it, so it only leaves adding extra functionality
> (methods)?
> > What are the use cases?
>
> 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).
>

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:

class SocketFamily(IntEnum):
  ??

If it's the latter, then why allow subclassing explicitly just for this
reason? I think the explicit approach of:

class SocketFamily(int, Enum):

Is cleaner anyway, and absolves us of providing yet another enum class to
export from the stdlib.

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enum: subclassing?

[Antoine Pitrou]

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:
> 
> class SocketFamily(IntEnum):
>   ??
> 
> If it's the latter, then why allow subclassing explicitly just for this
> reason?

Because I may want to share methods accross all concrete subclasses of
IntEnum (or WhateverEnum).

Regards

Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enum: subclassing?

[Eli Bendersky]

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 mean this:
> >
> > class IntEnum(int, Enum):
> >   pass
> >
> > Now I can have:
> >
> > class SocketFamily(IntEnum):
> >   ??
> >
> > If it's the latter, then why allow subclassing explicitly just for this
> > reason?
>
> Because I may want to share methods accross all concrete subclasses of
> IntEnum (or WhateverEnum).
>

You mean this?

class BehaviorMixin:
  # bla bla

class MyBehavingIntEnum(int, BehaviorMixin, Enum):
  foo = 1
  bar = 2

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enum: subclassing?

[Antoine Pitrou]

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 is enum-specific, e.g.:

class IETFStatusCode(IntEnum):

@classmethod
def from_statusline(cls, line):
return cls(int(line.split()[0]))

class HTTPStatusCode(IETFStatusCode):
NOT_FOUND = 404

class SIPStatusCode(IETFStatusCode):
RINGING = 180


Regards

Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enum: subclassing?

[Guido van Rossum]

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
>> >
>> > Why would you want to subclass MyEmptyEnum ?
>> >
>> > Or do you mean this:
>> >
>> > class IntEnum(int, Enum):
>> >   pass
>> >
>> > Now I can have:
>> >
>> > class SocketFamily(IntEnum):
>> >   ??
>> >
>> > If it's the latter, then why allow subclassing explicitly just for this
>> > reason?
>>
>> Because I may want to share methods accross all concrete subclasses of
>> IntEnum (or WhateverEnum).
>
>
> You mean this?
>
> 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 I think the rule "only allow subclassing empty
enums" makes a lot of sense.


--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enum: subclassing?

[Eli Bendersky]

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 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:
> >> >
> >> > class SocketFamily(IntEnum):
> >> >   ??
> >> >
> >> > If it's the latter, then why allow subclassing explicitly just for
> this
> >> > reason?
> >>
> >> Because I may want to share methods accross all concrete subclasses of
> >> IntEnum (or WhateverEnum).
> >
> >
> > You mean this?
> >
> > 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 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), but my
concern is that this is a TIMTOWTDI thing, since the same can be achieved
with mixins. Specifically, Antoine's example
 becomes:

class IETFStatusCode:
@classmethod
def from_statusline(cls, line):
return cls(int(line.split()[0]))

class HTTPStatusCode(int, IETFStatusCode, Enum):
NOT_FOUND = 404

class SIPStatusCode(int, IETFStatusCode, Enum):
RINGING = 180

Same thing, while keeping the stdlib API cleaner and more minimal. Cleaner
because "no subclassing" is a simpler, more explicit, and easier to
understand rule than "no subclassing unless base class is devoid of
enumeration values". And because we can no longer say "Enum classes are
final", which is a relatively familiar and understood semantic.

That said, I don't feel strongly about this so if the above does not
convert you, I'm fine with allowing subclassing enum classes that don't
define any enums =)

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enum: subclassing?

[Georg Brandl]

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:
> >> 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't see the point of disallowing subclassing. It sounds like
> > a pointless restriction.
> >
> > However, perhaps the constructor should forbid the returning of a base
> > type, e.g.:
> >
> > class Season(Enum):
> > spring = 1
> >
> > class MySeason(Season):
> > """I look nicer than Season"""
> >
> > MySeason('spring')
> > ...
> > ValueError: Season.spring is not a MySeason instance
> >
> > (what this means is perhaps the subclassing of non-empty enum classes
> > should be forbidden)
> 
> That's exactly what's implemented in the ref435 code at the moment.
> 
> 
> It can't be because __call__ is by-value lookup, not by-name lookup. By-name
> lookup is Season.spring or getattr(Season, 'spring')

Right, I was just referring to the parenthetical remark.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Tim Delaney]

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 any sense.
>
> 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 trump hypothetical purity.
>

I have real-world use cases of enums (in java) that are essentially classes
and happen to use the enum portion purely to obtain a unique name without
explicitly supplying an ID.

In the particular use case I'm thinking of, the flow is basically like this:

1. An Enum where each instance describes the shape of a database query.
2. Wire protocol where the Enum instance name is passed.
3. At one end, the data for performing the DB query is populated.
4. At the other end, the data is extracted and the appropriate enum is used
to perform the query.

Why use an enum? By using the name in the wire protocol I'm guaranteed a
unique ID that won't change across versions (there is a requirement to only
add to the enum) but does not rely on people setting it manually - the
compiler will complain if there is a conflict, as opposed to setting
values. And having the behaviour be part of the class simplifies things
immensely.

Yes, I could do all of this without an enum (have class check that each
supplied ID is unique, etc) but the code is much clearer using the enum.

I am happy to give up subclassing of enums in order to have behaviour on
enum instances. I've always seen enums more as a container for their
instances. I do want to be able to find out what enum class a particular
enum belongs to (I've used this property in the past) and it's nice that
the enum instance is an instance of the defining class (although IMO not
required).

I see advantages to enums being subclassable, but also significant
disadvantages. For example, given the following:

class Color(Enum):
red = 1

class MoreColor(Color):
blue = 2

class DifferentMoreColor(Color):
green = 2

then the only reasonable way for it to work IMO is that MoreColor contains
both (red, blue) and DifferentMoreColor contains both (red, green) and that
red is not an instance of either MoreColor or DifferentMoreColor. If you
allow subclassing, at some point either something is going to be
intuitively backwards to some people (in the above that Color.red is not an
instance of MoreColor), or is going to result in a contravariance violation.

Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enum: subclassing?

[Georg Brandl]

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 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.:
> >
> > class SocketFamily(int, Enum):
> >   AF_UNIX = 1
> >   AF_INET = 2
> >
> > As opposed to having an IntEnum explicitly, this just saves 2 characters
> > (comma+space), but is more explicit (zen!) and helps us avoid the
> special-casing
> > the subclass restriction implementation.
> 
> Wait a moment... it might not be immediately useful for IntEnums (however,
> that's because base Enum currently defines __int__ which I find 
> questionable),
> but with  current ref435 you *can* create your own enum base classes with 
> your
> own methods, and derive concrete enums from that.  It also lets you have a
> base class for enums and use it in isinstance().
> 
> If you forbid subclassing completely that will be impossible.
> 
> 
> I'm not sure what you mean, Georg, could you clarify?
> This works:
> 
 from ref435 import Enum
 class SocketFamily(int, Enum):
> ...   AF_UNIX = 1
> ...   AF_INET = 2
> ...
 SocketFamily.AF_INET
> SocketFamily.AF_INET [value=2]
 SocketFamily.AF_INET == 2
> True
 type(SocketFamily.AF_INET)
> 
 isinstance(SocketFamily.AF_INET, SocketFamily)
> True
> 
> Now, with the way things are currently implemented, class IntEnum is just
> syntactic sugar for above. Guido decided against allowing any kind of
> subclassing, but as an implementation need we should keep some restricted form
> to implement IntEnum. But is IntEnum really needed if the above explicit
> multiple-inheritance of int and Enum is possible?

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 haven't
followed all of the discussion and this may already have been decided.)

If __int__ stays where it is, a separate IntEnum is not necessary, but that
doesn't mean that enum baseclasses aren't useful for other use cases (and
they aren't hard to support, as ref435 shows.)

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enum: subclassing?

[Georg Brandl]

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), but my
> concern is that this is a TIMTOWTDI thing, since the same can be achieved with
> mixins. Specifically, Antoine's example
>  becomes:
> 
> class IETFStatusCode:
> @classmethod
> def from_statusline(cls, line):
> return cls(int(line.split()[0]))
> 
> class HTTPStatusCode(int, IETFStatusCode, Enum):
> NOT_FOUND = 404
> 
> class SIPStatusCode(int, IETFStatusCode, Enum):
> RINGING = 180

Now try it like this:

class SIPStatusCode(IETFStatusCode, int, Enum):
RINGING = 180

and you'll get

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 above exception, another exception occurred:

Traceback (most recent call last):
  File "ex.py", line 11, in 
class SIPStatusCode(IETFStatusCode, int, Enum):
  File "/home/gbr/devel/ref435/ref435.py", line 86, in __new__
raise EnumError(*exc.args) from None
TypeError: exception causes must derive from BaseException


> Same thing, while keeping the stdlib API cleaner and more minimal. Cleaner
> because "no subclassing" is a simpler, more explicit, and easier to understand
> rule than "no subclassing unless base class is devoid of enumeration values".
> And because we can no longer say "Enum classes are final", which is a 
> relatively
> familiar and understood semantic.

I fear the "you can use mixins provided you put them in the right spot in the
base classes list" rule is not much simpler than the "no subclassing of enums
with values" rule.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enum: subclassing?

[Eli Bendersky]

> > 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 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.:
> > >
> > > class SocketFamily(int, Enum):
> > >   AF_UNIX = 1
> > >   AF_INET = 2
> > >
> > > As opposed to having an IntEnum explicitly, this just saves 2
> characters
> > > (comma+space), but is more explicit (zen!) and helps us avoid the
> > special-casing
> > > the subclass restriction implementation.
> >
> > Wait a moment... it might not be immediately useful for IntEnums
> (however,
> > that's because base Enum currently defines __int__ which I find
> questionable),
> > but with  current ref435 you *can* create your own enum base classes
> with your
> > own methods, and derive concrete enums from that.  It also lets you
> have a
> > base class for enums and use it in isinstance().
> >
> > If you forbid subclassing completely that will be impossible.
> >
> >
> > I'm not sure what you mean, Georg, could you clarify?
> > This works:
> >
>  from ref435 import Enum
>  class SocketFamily(int, Enum):
> > ...   AF_UNIX = 1
> > ...   AF_INET = 2
> > ...
>  SocketFamily.AF_INET
> > SocketFamily.AF_INET [value=2]
>  SocketFamily.AF_INET == 2
> > True
>  type(SocketFamily.AF_INET)
> > 
>  isinstance(SocketFamily.AF_INET, SocketFamily)
> > True
> >
> > Now, with the way things are currently implemented, class IntEnum is just
> > syntactic sugar for above. Guido decided against allowing any kind of
> > subclassing, but as an implementation need we should keep some
> restricted form
> > to implement IntEnum. But is IntEnum really needed if the above explicit
> > multiple-inheritance of int and Enum is possible?
>
> 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 haven't
> followed all of the discussion and this may already have been decided.)
>

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.

Ethan - unless I'm missing something, __int__ should probably be removed.

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ben Hoyt]

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() 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 to need an extra stat (though it does depend on the file
system).

I still hope to clean up Betterwalk and make a C version so we can use it
in the standard library. In many cases it speeds up os.walk() by several
times, even an order of magnitude in some cases. I intend for it to be a
drop-in replacement for os.walk(), just faster.

-Ben
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enum: subclassing?

[Georg Brandl]

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 
> haven't
> followed all of the discussion and this may already have been decided.)
> 
> 
> 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.

OK, I'm stupid -- I was thinking about moving the __int__ method to IntEnum
(that's why I brought it up in this part of the thread), but as a subclass of
int itself that obviously isn't needed :)

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enum: subclassing?

[Georg Brandl]

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 above exception, another exception occurred:
> 
> Traceback (most recent call last):
>   File "ex.py", line 11, in 
> class SIPStatusCode(IETFStatusCode, int, Enum):
>   File "/home/gbr/devel/ref435/ref435.py", line 86, in __new__
> raise EnumError(*exc.args) from None
> TypeError: exception causes must derive from BaseException

To be fair the secondary exception is an artifact of me trying the example
with Python 3.2, which doesn't have "from None".

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enum: subclassing?

[Eli Bendersky]

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
> > conversion to integers should only be defined for IntEnums.  (But I
> haven't
> > followed all of the discussion and this may already have been
> decided.)
> >
> >
> > 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.
>
> OK, I'm stupid -- I was thinking about moving the __int__ method to IntEnum
> (that's why I brought it up in this part of the thread), but as a subclass
> of
> int itself that obviously isn't needed :)


You did bring up a good point, though - __int__ should not be part of
vanilla Enum.

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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 would be very
> > concerned if existing APIs were going to get caching behavior. For
> > every use cases that benefits from caching there's a complementary use
> > case that caching breaks. Since both use cases are important we must
> > offer both APIs, in a way that makes it clear to even the casual
> > reader of the code what's going on.
>
> I deem caching of stat calls as problematic. The correct and
> contemporary result of a stat() call has security implications, too. For
> example stat() is used to prevent TOCTOU race conditions such as [1].
> Caching is useful but I would prefer explicit caching rather than
> implicit and automatic caching of stat() results.
>
> 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.

While I agree exposing dirent in some manner is desirable, note that I'm
not talking about os.walk itself, but the generator pipeline library I
built around it in an attempt to break up monolithic directory walking
loops into reusable components. Once you get out of the innermost
generator, the only state passed through each stage is the path information
(and the directory descriptor if using os.fwalk).

Upgrading walkdir from simple strings to path objects would be relatively
straightforward, but you can't change the API too much before it isn't
similar to os.walk any more.

The security issues only come into play in the outer loop which actually
tries to *do* something with the pipeline output. However, even that case
should involve at most two stat calls: one inside the pipeline (cached per
iteration) and then a more timely one in the outer loop (assuming using
os.fwalk as the base loop instead of os.walk doesn't already cover it).

Cheers,
Nick.

>
> Christian
>
> [1]
>
https://www.securecoding.cert.org/confluence/display/seccode/POS01-C.+Check+for+the+existence+of+links+when+dealing+with+files
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enum: subclassing?

[Ethan Furman]

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
> > 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.:
> >
> > class SocketFamily(int, Enum):
> >   AF_UNIX = 1
> >   AF_INET = 2
> >
> > As opposed to having an IntEnum explicitly, this just saves 2 
characters
> > (comma+space), but is more explicit (zen!) and helps us avoid the
> special-casing
> > the subclass restriction implementation.
>
> Wait a moment... it might not be immediately useful for IntEnums 
(however,
> that's because base Enum currently defines __int__ which I find 
questionable),
> but with  current ref435 you *can* create your own enum base classes 
with your
> own methods, and derive concrete enums from that.  It also lets you 
have a
> base class for enums and use it in isinstance().
>
> If you forbid subclassing completely that will be impossible.
>
>
> I'm not sure what you mean, Georg, could you clarify?
> This works:
>
 from ref435 import Enum
 class SocketFamily(int, Enum):
> ...   AF_UNIX = 1
> ...   AF_INET = 2
> ...
 SocketFamily.AF_INET
> SocketFamily.AF_INET [value=2]
 SocketFamily.AF_INET == 2
> True
 type(SocketFamily.AF_INET)
> 
 isinstance(SocketFamily.AF_INET, SocketFamily)
> True
>
> Now, with the way things are currently implemented, class IntEnum is just
> syntactic sugar for above. Guido decided against allowing any kind of
> subclassing, but as an implementation need we should keep some restricted 
form
> to implement IntEnum. But is IntEnum really needed if the above explicit
> multiple-inheritance of int and Enum is possible?

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 haven't
followed all of the discussion and this may already have been decided.)


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.

Ethan - unless I'm missing something, __int__ should probably be removed.


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.


IntEnum is for when the enum item *must* be a real, bonafide int in its own right, and the use case here is backwards 
compatibility with APIs that are already using real ints -- and this is really the *only* time IntEnum should be used).


The downside to IntEnum is you lose all Enum type protection; so if you don't need a real int, use a fake int, er, I 
mean, Enum, which can easily be int'ified on demand due to its handy dandy __int__ method.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enum: subclassing?

[Guido van Rossum]

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 Thing.

What would int(x) return if x is an enum whose value is not a plain int?

Why can't you use x.value for this use case?

--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enum: subclassing?

[Eli Bendersky]

>
>> 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.
>>
>> Ethan - unless I'm missing something, __int__ should probably be removed.
>>
>
> 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.
>

Yes, but the .value attribute makes it "easy enough". If you have foo which
is of type SomeEnum, all you need (if you know for sure it has int values)
is to pass foo.value instead of just foo to places that do int conversion.

Relying on __init__ is *unsafe* in the general case because enums can have
non-int values, or mixed values, or whatever. You only want "true int
conversion" in rare cases for which IntEnum exists.

Eli
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ethan Furman]

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 that the instance/class/subclass relationships
> make any sense.

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 trump hypothetical purity.


I have real-world use cases of enums (in java) that are essentially classes and 
happen to use the enum portion purely to
obtain a unique name without explicitly supplying an ID.

In the particular use case I'm thinking of, the flow is basically like this:

1. An Enum where each instance describes the shape of a database query.
2. Wire protocol where the Enum instance name is passed.
3. At one end, the data for performing the DB query is populated.
4. At the other end, the data is extracted and the appropriate enum is used to 
perform the query.

Why use an enum? By using the name in the wire protocol I'm guaranteed a unique 
ID that won't change across versions
(there is a requirement to only add to the enum) but does not rely on people 
setting it manually - the compiler will
complain if there is a conflict, as opposed to setting values. And having the 
behaviour be part of the class simplifies
things immensely.

Yes, I could do all of this without an enum (have class check that each 
supplied ID is unique, etc) but the code is much
clearer using the enum.

I am happy to give up subclassing of enums in order to have behaviour on enum 
instances. I've always seen enums more as
a container for their instances. I do want to be able to find out what enum 
class a particular enum belongs to (I've
used this property in the past) and it's nice that the enum instance is an 
instance of the defining class (although IMO
not required).

I see advantages to enums being subclassable, but also significant 
disadvantages. For example, given the following:

class Color(Enum):
 red = 1

class MoreColor(Color):
 blue = 2

class DifferentMoreColor(Color):
 green = 2

then the only reasonable way for it to work IMO is that MoreColor contains both 
(red, blue) and DifferentMoreColor
contains both (red, green) and that red is not an instance of either MoreColor 
or DifferentMoreColor. If you allow
subclassing, at some point either something is going to be intuitively 
backwards to some people (in the above that
Color.red is not an instance of MoreColor), or is going to result in a 
contravariance violation.


Nice example, thank you.

As far as subclassing goes, you can have behavior either way.  The sticky issue is are the enum items from an inherited 
enumeration available in the child enumeration, or should such an inheritance raise an error, or should all subclassing 
inheritance raise an error.


It sounds like we're leaning towards allowing subclassing as long as the enumeration being subclassed doesn't define any 
enum items itself.


--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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 first place.   IOW, I would vote
> > that real-world usecases trump hypothetical purity.
>
> Yeah, this is the dilemma. But what *are* the real-world use cases?
> Please provide some.
>
> 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 I can test "c in flag_colors" to check whether c is a flag color.
> I can also loop over flag_colors. If I want the colors in definition
> order I could use a list instead:
>
> ordered_flag_colors = list(Color) + list(ExtraColor)
>
> But this would be less or more acceptable depending on whether it is a
> common or esoteric use case.

If enums had an "as_dict" method that returned an ordered dictionary, you
could do:

class MoreColors(Enum):
locals().update(Colors.as_dict())
orange = 4
...

Using a similar API to PEP 422's class initialisation hook, you could even
simplify that to:

class MoreColors(Enum,  namespace=Colors.as_dict()):
orange = 4
...

Cheers,
Nick.

>
> --
> --Guido van Rossum (python.org/~guido)
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Greg Ewing]

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
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enum: subclassing?

[Ethan Furman]

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 I think the rule "only allow subclassing empty
enums" makes a lot of sense.


So is this a pronouncement?  I'm going to get whiplash if I change that bit of 
code many more times.  ;)

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enum: subclassing?

[Guido van Rossum]

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
>>>bar = 2
>>
>>
>> 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.
>
>
> So is this a pronouncement?  I'm going to get whiplash if I change that bit
> of code many more times.  ;)
>
> --
> ~Ethan~
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Steven D'Aprano]

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


--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enum: subclassing?

[Steven D'Aprano]

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 for "subclassing enums" you will find many people asking
how to subclass enums.

Apparently Apache's Java allows subclassing, if I'm reading this correctly:

http://commons.apache.org/proper/commons-lang/javadocs/api-2.6/org/apache/commons/lang/enums/Enum.html

So do Scala and Kotlin.

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


If you allow enums to have methods, then the most obvious use-case is to add or 
extend methods, no different to any other class.



--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Steven D'Aprano]

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 I can test "c in flag_colors" to check whether c is a flag color.


Earlier you argued that testing for enums should be done with isinstance, not 
"in". Or did I misunderstood? So I would have thought that isinstance(c, 
(Color, ExtraColor)) would be the way to check c.

I would prefer to write "c in ExtraColor", assuming c extends Color.


Lookups by value also become more complex. Instead of c = ExtraColor[value], 
this leads to two choices, both of which are equally ugly in my opinion:


c = [c for c in flag_colors if c.value == value][0]


try:
c = ExtraColor[value]
except:  # I'm not sure what exception you get here
c = Color[value]


There is a further problem if the two enum classes have duplicate values, by 
accident or design. Accident being more likely, since now you have no warning 
when ExtraColor defines a value that duplicates something in Color. flag_colors 
will now contain both duplicates, since enum values from different enums never 
compare equal, but that's probably not what you want.



--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Sean Felipe Wolfe]

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 am an intermediate-level python coder looking to get help out. I've
 been reading over the dev guide about helping increase test coverage
 -->
 http://docs.python.org/devguide/coverage.html

 And also the third-party code coverage referenced in the devguide page:
 http://coverage.livinglogic.de/

 I'm seeing that according to the coverage tool, two of my favorite
 libraries, urllib/urllib2, have no unit tests? Is that correct or am I
 reading it wrong?

 If that's correct it seems like a great place perhaps for me to cut my
 teeth and I would be excited to learn and help out here.

 And of course any thoughts or advice for an aspiring Python
 contributor would be appreciated. Of course the dev guide gives me
 plenty of good info.

 Thanks!
>>>
>>> That looks like an error in the coverage report, there are certainly
>>> urllib and urllib2 tests in test/test_urllib*
>>
>> The devguide contains instructions for running coverage yourself,
>> and if I recall correctly the 'fullcoverage' recipe does a better
>> job than what runs at coverage.livinglogic.de.
>
> The job that produces that output has been broken for some time now, and I 
> haven't found the time to look into it. If someone wants to try, here's the 
> code:
>
>https://pypi.python.org/pypi/pycoco/0.7.2
>
>> […]
>
> Servus,
>Walter
>

Hello Walter and everybody, after a bit of family time and other
stuffs, I'm getting back to this today and looking at what's involved
in fixing the livinglogic code coverage tool.

I was able to get the depencies and a few minor issues, and now the
script is running on a first attempt. I'll report back with progress
or problems.

Thanks y'all :)


-- 
A musician must make music, an artist must paint, a poet must write,
if he is to be ultimately at peace with himself.
- Abraham Maslow
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Enum: subclassing?

[Greg Ewing]

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 extending enums, though. If anything, you
really want to "superclass" them. Maybe

  class Directions3D(Enum, extends = Directions):
up = 5
down = 6

Then we could have issubclass(Directions, Directions3D)
rather than the reverse.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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 to need an extra stat (though it does depend on the file
> system).
>
> I still hope to clean up Betterwalk and make a C version so we can use it in
> the standard library. In many cases it speeds up os.walk() by several times,
> even an order of magnitude in some cases. I intend for it to be a drop-in
> replacement for os.walk(), just faster.

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.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com