Re: [Python-Dev] casefolding in pathlib (PEP 428)

[Antoine Pitrou]

Le Thu, 11 Apr 2013 15:42:00 -0700,
Guido van Rossum  a écrit :
> On Thu, Apr 11, 2013 at 2:27 PM, Antoine Pitrou 
> wrote:
> > On Thu, 11 Apr 2013 14:11:21 -0700
> > Guido van Rossum  wrote:
> >> Hey Antoine,
> >>
> >> Some of my Dropbox colleagues just drew my attention to the
> >> occurrence of case folding in pathlib.py. Basically, case folding
> >> as an approach to comparing pathnames is fatally flawed. The
> >> issues include:
> >>
> >> - most OSes these days allow the mounting of both case-sensitive
> >> and case-insensitive filesystems simultaneously
> >>
> >> - the case-folding algorithm on some filesystems is burned into the
> >> disk when the disk is formatted
> >
> > The problem is that:
> > - if you always make the comparison case-sensitive, you'll get false
> >   negatives
> > - if you make the comparison case-insensitive under Windows, you'll
> > get false positives
> >
> > My assumption was that, globally, the number of false positives in
> > case (2) is much less than the number of false negatives in case
> > (1).
> >
> > On the other hand, one could argue that all comparisons should be
> > case-sensitive *and* the proper way to test for "identical" paths
> > is to access the filesystem. Which makes me think, perhaps concrete
> > paths should get a "samefile" method as in os.path.samefile().
> >
> > Hmm, I think I'm tending towards the latter right now.
> 
> Python on OSX has been using (1) for a decade now without major
> problems.
> 
> Perhaps it would be best if the code never called lower() or upper()
> (not even indirectly via os.path.normcase()). Then any case-folding
> and path-normalization bugs are the responsibility of the application,
> and we won't have to worry about how to fix the stdlib without
> breaking backwards compatibility if we ever figure out how to fix this
> (which I somehow doubt we ever will anyway :-).

Ok, I've taken a look at the code. Right now lower() is used for two
purposes:

1. comparisons (__eq__ and __ne__)
2. globbing and matching

While (1) could be dropped, for (2) I think we want glob("*.py") to find
"SETUP.PY" under Windows. Anything else will probably be surprising to
users of that platform.

> - On Linux, paths are really bytes; on Windows (at least NTFS), they
> are really (16-bit) Unicode; on Mac, they are UTF-8 in a specific
> normal form (except on some external filesystems).

pathlib is just relying on Python 3's sane handling of unicode paths
(thanks to PEP 383). Bytes paths are never used internally.

> - On Windows, short names are still supported, making the number of
> ways to spell the path for any given file even larger.

They are still supported but I doubt they are still relied on (long
filenames appeared in Windows 95!). I think in common situations we can
ignore their existence. Specialized tools like Mercurial may have to
know that they exist, in order to manage potential collisions (but
Mercurial isn't really the target audience for pathlib, and I don't
think they would be interested in such an abstraction).

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] casefolding in pathlib (PEP 428)

[Paul Moore]

On 12 April 2013 09:39, Antoine Pitrou  wrote:

> Ok, I've taken a look at the code. Right now lower() is used for two
> purposes:
>
> 1. comparisons (__eq__ and __ne__)
> 2. globbing and matching
>
> While (1) could be dropped, for (2) I think we want glob("*.py") to find
> "SETUP.PY" under Windows. Anything else will probably be surprising to
> users of that platform.


If glob("*.py") failed to find SETUP.PY on Windows, that would be a
usability disaster. Too many tools still exist that mangle filename case
for anything else to be acceptable. For an easy example, the standard
Windows ssh client, putty, is distributed as PUTTY.EXE.
shutil.which('putty') needs to find that file if it's to be of any
practical use.

For comparisons, I think naive Windows users would expect __eq__
comparisons to work case insensitively, but Windows users with any level of
understanding of cross-platform portability issues would be comfortable
with the idea that this is risky. Having said that, currently there aren't
any "pathname comparisons" as such, just string comparisons which "clearly"
need application handling.

In all honesty, I don't think that equality comparison for path *objects*
(as opposed to "pathnames" as strings) is necessarily even well defined. If
someone has two path objects and tries to compare them for equality, my
first question would be whether that's really what they want to do... (But
case-sensitive comparison, with copious warnings, is probably a reasonable
practical compromise).

Paul
___
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] casefolding in pathlib (PEP 428)

[Devin Jeanpierre]

On Fri, Apr 12, 2013 at 4:39 AM, Antoine Pitrou  wrote:
> Ok, I've taken a look at the code. Right now lower() is used for two
> purposes:
>
> 1. comparisons (__eq__ and __ne__)
> 2. globbing and matching
>
> While (1) could be dropped, for (2) I think we want glob("*.py") to find
> "SETUP.PY" under Windows. Anything else will probably be surprising to
> users of that platform.

OT, but, why is .lower() used for case folding in these use-cases
instead of .casefold()?

-- Devin
___
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] casefolding in pathlib (PEP 428)

[Antoine Pitrou]

Le Fri, 12 Apr 2013 08:06:37 -0400,
Devin Jeanpierre  a écrit :
> On Fri, Apr 12, 2013 at 4:39 AM, Antoine Pitrou 
> wrote:
> > Ok, I've taken a look at the code. Right now lower() is used for two
> > purposes:
> >
> > 1. comparisons (__eq__ and __ne__)
> > 2. globbing and matching
> >
> > While (1) could be dropped, for (2) I think we want glob("*.py") to
> > find "SETUP.PY" under Windows. Anything else will probably be
> > surprising to users of that platform.
> 
> OT, but, why is .lower() used for case folding in these use-cases
> instead of .casefold()?

Because the code was written before str.casefold() was introduced.
But, actually, if we want to approximate Windows' casefolding behaviour,
str.lower() may be better.

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] casefolding in pathlib (PEP 428)

[Ronald Oussoren]

On 12 Apr, 2013, at 10:39, Antoine Pitrou  wrote:
>> 
>> 
>> Perhaps it would be best if the code never called lower() or upper()
>> (not even indirectly via os.path.normcase()). Then any case-folding
>> and path-normalization bugs are the responsibility of the application,
>> and we won't have to worry about how to fix the stdlib without
>> breaking backwards compatibility if we ever figure out how to fix this
>> (which I somehow doubt we ever will anyway :-).
> 
> Ok, I've taken a look at the code. Right now lower() is used for two
> purposes:
> 
> 1. comparisons (__eq__ and __ne__)
> 2. globbing and matching
> 
> While (1) could be dropped, for (2) I think we want glob("*.py") to find
> "SETUP.PY" under Windows. Anything else will probably be surprising to
> users of that platform.

Globbing necessarily accesses the filesystem and could in theory do the
right thing, except for the minor detail of there not being an easy way
to determine of the names in a particular folder are compared case sensitive
or not. 

> 
>> - On Linux, paths are really bytes; on Windows (at least NTFS), they
>> are really (16-bit) Unicode; on Mac, they are UTF-8 in a specific
>> normal form (except on some external filesystems).
> 
> pathlib is just relying on Python 3's sane handling of unicode paths
> (thanks to PEP 383). Bytes paths are never used internally.

At least for OSX the kernel will normalize names for you, at least for HFS+,
and therefore two names that don't compare equal with '==' can refer to the
same file (for example the NFKD and NFKC forms of Löwe). 

Isn't unicode fun :-)

Ronald

> 
>> - On Windows, short names are still supported, making the number of
>> ways to spell the path for any given file even larger.
> 
> They are still supported but I doubt they are still relied on (long
> filenames appeared in Windows 95!). I think in common situations we can
> ignore their existence. Specialized tools like Mercurial may have to
> know that they exist, in order to manage potential collisions (but
> Mercurial isn't really the target audience for pathlib, and I don't
> think they would be interested in such an abstraction).
> 
> 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/ronaldoussoren%40mac.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

[Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

[Eli Bendersky]

Hello python-dev,

We're happy to present the revised PEP 435, collecting valuable feedback
from python-ideas discussions as well as in-person discussions and
decisions made during the latest PyCon language summit. We believe the
proposal is now better than the original one, providing both a wider set of
features and more convenient ways to use those features.

Link to the PEP: http://www.python.org/dev/peps/pep-0435/ [it's also pasted
fully below for convenience].

Reference implementation is available as the recently released flufl.enum
version 4.0 - you can get it either from PyPi or
https://launchpad.net/flufl.enum. flufl.enum 4.0 was developed in parallel
with revising PEP 435.

Comments welcome,

Barry and Eli

--

PEP: 435
Title: Adding an Enum type to the Python standard library
Version: $Revision$
Last-Modified: $Date$
Author: Barry Warsaw ,
Eli Bendersky 
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 2013-02-23
Python-Version: 3.4
Post-History: 2013-02-23


Abstract


This PEP proposes adding an enumeration type to the Python standard library.
Specifically, it proposes moving the existing ``flufl.enum`` package by
Barry
Warsaw into the standard library.  Much of this PEP is based on the "using"
[1]_ document from the documentation of ``flufl.enum``.

An enumeration is a set of symbolic names bound to unique, constant values.
Within an enumeration, the values can be compared by identity, and the
enumeration itself can be iterated over.


Decision


TODO: update decision here once pronouncement is made.


Status of discussions
=

The idea of adding an enum type to Python is not new - PEP 354 [2]_ is a
previous attempt that was rejected in 2005.  Recently a new set of
discussions
was initiated [3]_ on the ``python-ideas`` mailing list.  Many new ideas
were
proposed in several threads; after a lengthy discussion Guido proposed
adding
``flufl.enum`` to the standard library [4]_.  During the PyCon 2013 language
summit the issue was discussed further.  It became clear that many
developers
want to see an enum that subclasses ``int``, which can allow us to replace
many integer constants in the standard library by enums with friendly string
representations, without ceding backwards compatibility.  An additional
discussion among several interested core developers led to the proposal of
having ``IntEnum`` as a special case of ``Enum``.

The key dividing issue between ``Enum`` and ``IntEnum`` is whether comparing
to integers is semantically meaningful.  For most uses of enumerations, it's
a **feature** to reject comparison to integers; enums that compare to
integers
lead, through transitivity, to comparisons between enums of unrelated types,
which isn't desirable in most cases.  For some uses, however, greater
interoperatiliby with integers is desired. For instance, this is the case
for
replacing existing standard library constants (such as ``socket.AF_INET``)
with enumerations.

This PEP is an attempt to formalize this decision as well as discuss a
number
of variations that were discussed and can be considered for inclusion.


Motivation
==

*[Based partly on the Motivation stated in PEP 354]*

The properties of an enumeration are useful for defining an immutable,
related
set of constant values that have a defined sequence but no inherent semantic
meaning.  Classic examples are days of the week (Sunday through Saturday)
and
school assessment grades ('A' through 'D', and 'F').  Other examples include
error status values and states within a defined process.

It is possible to simply define a sequence of values of some other basic
type,
such as ``int`` or ``str``, to represent discrete arbitrary values.
However,
an enumeration ensures that such values are distinct from any others
including,
importantly, values within other enumerations, and that operations without
meaning ("Wednesday times two") are not defined for these values.  It also
provides a convenient printable representation of enum values without
requiring
tedious repetition while defining them (i.e. no ``GREEN = 'green'``).


Module and type name


We propose to add a module named ``enum`` to the standard library.  The main
type exposed by this module is ``Enum``.  Hence, to import the ``Enum`` type
user code will run::

>>> from enum import Enum


Proposed semantics for the new enumeration type
===

Creating an Enum


Enumerations are created using the class syntax, which makes them easy to
read
and write.  An alternative creation method is described in `Convenience
API`_.
To define an enumeration, derive from the ``Enum`` class and add attributes
with assignment to their integer values::

>>> from enum import Enum
>>> class Colors(Enum):
... red = 1
... green = 2
... blue = 3

Enumeration values have nice, human readable string 

Re: [Python-Dev] casefolding in pathlib (PEP 428)

[Christian Heimes]

Am 12.04.2013 14:43, schrieb Ronald Oussoren:
> At least for OSX the kernel will normalize names for you, at least for HFS+,
> and therefore two names that don't compare equal with '==' can refer to the
> same file (for example the NFKD and NFKC forms of Löwe). 
> 
> Isn't unicode fun :-)

Seriously, the OSX kernel normalizes unicode forms? It's a cool feature
and makes sense for the user's POV but ... WTF?

Perhaps we should use the platform's API for the job. Does OSX offer an
API function to create a case folded and canonical form of a path?
Windows has PathCchCanonicalizeEx().

Christian
___
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] casefolding in pathlib (PEP 428)

[Ronald Oussoren]

On 12 Apr, 2013, at 15:00, Christian Heimes  wrote:

> Am 12.04.2013 14:43, schrieb Ronald Oussoren:
>> At least for OSX the kernel will normalize names for you, at least for HFS+,
>> and therefore two names that don't compare equal with '==' can refer to the
>> same file (for example the NFKD and NFKC forms of Löwe). 
>> 
>> Isn't unicode fun :-)
> 
> Seriously, the OSX kernel normalizes unicode forms? It's a cool feature
> and makes sense for the user's POV but ... WTF?

IIRC only for HFS+ filesystems, it is possible to access files on an NFS share
where the filename encoding isn't UTF-8.

> 
> Perhaps we should use the platform's API for the job. Does OSX offer an
> API function to create a case folded and canonical form of a path?
> Windows has PathCchCanonicalizeEx().

This would have to be done on a per path element case, because every directory
in a file's path could be on a separate filesystem with different conventions
(HFS+, HFS+ case sensitive, NFS mounted unix filesystem).

I have found sample code that can determine if a directory is on a case 
sensitive
filesystem (attached to 
,
doesn't work in a 64-binary but I haven't check yet why is doesn't work there). 

I don'tknow if there is a function to determine the filesystem encoding, I 
guess 
assuming that the special casing is only needed for HFS+ variants could work 
but 
I'd have test that.

Ronald

___
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 -- Adding an Enum type to the Python standard library

[Dirkjan Ochtman]

On Fri, Apr 12, 2013 at 2:55 PM, Eli Bendersky  wrote:
> Ordered comparisons between enumeration values are *not* supported.  Enums
> are
> not integers (but see `IntEnum`_ below)::
>
> >>> Colors.red < Colors.blue
> Traceback (most recent call last):
> ...
> NotImplementedError
> >>> Colors.red <= Colors.blue
> Traceback (most recent call last):
> ...
> NotImplementedError
> >>> Colors.blue > Colors.green
> Traceback (most recent call last):
> ...
> NotImplementedError
> >>> Colors.blue >= Colors.green
> Traceback (most recent call last):
> ...
> NotImplementedError

I like much of this PEP, but the exception type for this case seems
odd to me. Wouldn't a TypeError be more appropriate here?

Somewhat like this:

>>> 'a' - 'b'
Traceback (most recent call last):
  File "", line 1, in 
TypeError: unsupported operand type(s) for -: 'str' and 'str'

Cheers,

Dirkjan
___
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 -- Adding an Enum type to the Python standard library

[R. David Murray]

On Fri, 12 Apr 2013 05:55:00 -0700, Eli Bendersky  wrote:
> Link to the PEP: http://www.python.org/dev/peps/pep-0435/ [it's also pasted
> fully below for convenience].

This looks great.  There's just one bit I don't understand.  I'm sure
it was discussed in the python-ideas thread, but the discussion of it
in the PEP does not provide any motivation for the decision.

> The ``Enum`` class supports iteration.  Iteration is defined as the
> sorted order of the item values::
> 
> >>> class FiveColors(Enum):
> ... pink = 4
> ... cyan = 5
> ... green = 2
> ... blue = 3
> ... red = 1
> >>> [v.name for v in FiveColors]
> ['red', 'green', 'blue', 'pink', 'cyan']

[...]

> Ordered comparisons between enumeration values are *not* supported.  Enums
> are
> not integers (but see `IntEnum`_ below)::
> 
> >>> Colors.red < Colors.blue
> Traceback (most recent call last):
> ...
> NotImplementedError
> >>> Colors.red <= Colors.blue
> Traceback (most recent call last):
> ...
> NotImplementedError
> >>> Colors.blue > Colors.green
> Traceback (most recent call last):
> ...
> NotImplementedError
> >>> Colors.blue >= Colors.green
> Traceback (most recent call last):
> ...
> NotImplementedError

This is the part that I don't understand.  Enums *clearly* have an
ordering, since the iteration order is defined and stable.  Why should
I not be allowed to compare values from the same Enum type?  There are
certainly use cases where that is very useful.

To give you a concrete use case: consider response codes from a client
server application constructed the way typical internet protocols are.
We might have:

class MyAppCode(Enum):

ok = 200
command_complete = 201
status_response = 202
help_response = 203
service_ready = 204
signoff_accepted = 205

temporary_failure = 400
service_not_available = 401
server_error = 402
out_of_resources = 403

error = 500
syntax_error = 501
command_not_implemented = 502
access_denied = 503
resource_not_found = 504


It can be quite handy to be able to say things like:

code = myapp.operation(opstring)
if MyAppCode.temporary_failure < code < MyAppCode.error:
myframework.requeue(opstring, code=code)
return False
elif code > MyAppCode.error:
raise AppError(code)


In talking to an existing internet protocol it would be natural to use
IntEnum and this issue would not arise, but I have recently worked on
an application that had *exactly* the above sort of enumeration used
internally, when it would have been totally appropriate to use Enum rather
than IntEnum.  The ap has several places where an ordered comparison
against the enum is used to check if a code is in the error range or not.

--David
___
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 -- Adding an Enum type to the Python standard library

[Michael Urman]

> You may not define two enumeration values with the same integer value::
>
> >>> class Bad(Enum):
> ... cartman = 1
> ... stan = 2
> ... kyle = 3
> ... kenny = 3 # Oops!
> ... butters = 4
> Traceback (most recent call last):
> ...
> ValueError: Conflicting enums with value '3': 'kenny' and 'kyle'
>
> You also may not duplicate values in derived enumerations::
>
> >>> class BadColors(Colors):
> ... yellow = 4
> ... chartreuse = 2 # Oops!
> Traceback (most recent call last):
> ...
> ValueError: Conflicting enums with value '2': 'green' and 'chartreuse'
>

Is there a convenient way to change this behavior, namely to indicate that
conflicts are acceptable in a given Enum? While I like the idea of catching
mistaken collisions, I've seen far too many C/C++ scenarios where multiple
names map to the same value. This does raise questions, as it's unclear
whether each name should get its own representation, or whether it's better
to let DupEnum.name1 is DupEnum.name2 be True.

(For the latter behavior, would adding DupEnum.name2 = DupEnum.name1 after
the class declaration work today?)

Michael
-- 
Michael Urman
___
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 -- Adding an Enum type to the Python standard library

[Lele Gaifax]

Eli Bendersky  writes:

> These enumeration values are not equal, nor do they and hence may exist
> in the same set, or as distinct keys in the same dictionary::

I'm not a native speaker and I found the above difficult to parse: is
there anything missing between "nor do they" and "and hence may exist"?

ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
l...@metapensiero.it  | -- Fortunato Depero, 1929.

___
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 -- Adding an Enum type to the Python standard library

[Davis Silverman]

I think the reason they are not supporting __lt__, __gt__,etc. is because
ints are optional values for enums, therefore it wouldnt be a good idea to
compare enums of different types in that way.

example:

>>>class MyEnum(Enum):
>>>   fir = 1
>>>   sec = 2
>>>   thir = "THIRD!"

and doing

>>> MyEnum.fir >= MyEnum.thir
would give unexpected results, therefore not making it a great idea


On Fri, Apr 12, 2013 at 9:58 AM, R. David Murray wrote:

> On Fri, 12 Apr 2013 05:55:00 -0700, Eli Bendersky 
> wrote:
> > Link to the PEP: http://www.python.org/dev/peps/pep-0435/ [it's also
> pasted
> > fully below for convenience].
>
> This looks great.  There's just one bit I don't understand.  I'm sure
> it was discussed in the python-ideas thread, but the discussion of it
> in the PEP does not provide any motivation for the decision.
>
> > The ``Enum`` class supports iteration.  Iteration is defined as the
> > sorted order of the item values::
> >
> > >>> class FiveColors(Enum):
> > ... pink = 4
> > ... cyan = 5
> > ... green = 2
> > ... blue = 3
> > ... red = 1
> > >>> [v.name for v in FiveColors]
> > ['red', 'green', 'blue', 'pink', 'cyan']
>
> [...]
>
> > Ordered comparisons between enumeration values are *not* supported.
>  Enums
> > are
> > not integers (but see `IntEnum`_ below)::
> >
> > >>> Colors.red < Colors.blue
> > Traceback (most recent call last):
> > ...
> > NotImplementedError
> > >>> Colors.red <= Colors.blue
> > Traceback (most recent call last):
> > ...
> > NotImplementedError
> > >>> Colors.blue > Colors.green
> > Traceback (most recent call last):
> > ...
> > NotImplementedError
> > >>> Colors.blue >= Colors.green
> > Traceback (most recent call last):
> > ...
> > NotImplementedError
>
> This is the part that I don't understand.  Enums *clearly* have an
> ordering, since the iteration order is defined and stable.  Why should
> I not be allowed to compare values from the same Enum type?  There are
> certainly use cases where that is very useful.
>
> To give you a concrete use case: consider response codes from a client
> server application constructed the way typical internet protocols are.
> We might have:
>
> class MyAppCode(Enum):
>
> ok = 200
> command_complete = 201
> status_response = 202
> help_response = 203
> service_ready = 204
> signoff_accepted = 205
>
> temporary_failure = 400
> service_not_available = 401
> server_error = 402
> out_of_resources = 403
>
> error = 500
> syntax_error = 501
> command_not_implemented = 502
> access_denied = 503
> resource_not_found = 504
>
>
> It can be quite handy to be able to say things like:
>
> code = myapp.operation(opstring)
> if MyAppCode.temporary_failure < code < MyAppCode.error:
> myframework.requeue(opstring, code=code)
> return False
> elif code > MyAppCode.error:
> raise AppError(code)
> 
>
> In talking to an existing internet protocol it would be natural to use
> IntEnum and this issue would not arise, but I have recently worked on
> an application that had *exactly* the above sort of enumeration used
> internally, when it would have been totally appropriate to use Enum rather
> than IntEnum.  The ap has several places where an ordered comparison
> against the enum is used to check if a code is in the error range or not.
>
> --David
> ___
> 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/sinistersnare%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 435 -- Adding an Enum type to the Python standard library

[R. David Murray]

On Fri, 12 Apr 2013 10:19:29 -0400, Davis Silverman  
wrote:
> I think the reason they are not supporting __lt__, __gt__,etc. is because
> ints are optional values for enums, therefore it wouldnt be a good idea to
> compare enums of different types in that way.
> 
> example:
> 
> >>>class MyEnum(Enum):
> >>>   fir = 1
> >>>   sec = 2
> >>>   thir = "THIRD!"
> 
> and doing
> 
> >>> MyEnum.fir >= MyEnum.thir
> would give unexpected results, therefore not making it a great idea

That's why I included the bit about iterating the values.  The ordering
*is* defined.  I find it much more surprising for that ordering to
be inaccessible via the comparison operators.

I think either the iteration order should be undefined (like a set
or dict), or the comparison operations should work.  I'd prefer
the latter, because of the use case I outlined.

--David
___
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 -- Adding an Enum type to the Python standard library

[Davis Silverman]

i agree with that, and good point, i guess i misunderstood.

enums could be a nice edition, i cant wait to see how this goes.

--Sinistersnare





On Fri, Apr 12, 2013 at 10:23 AM, R. David Murray wrote:

> On Fri, 12 Apr 2013 10:19:29 -0400, Davis Silverman <
> sinistersn...@gmail.com> wrote:
> > I think the reason they are not supporting __lt__, __gt__,etc. is because
> > ints are optional values for enums, therefore it wouldnt be a good idea
> to
> > compare enums of different types in that way.
> >
> > example:
> >
> > >>>class MyEnum(Enum):
> > >>>   fir = 1
> > >>>   sec = 2
> > >>>   thir = "THIRD!"
> >
> > and doing
> >
> > >>> MyEnum.fir >= MyEnum.thir
> > would give unexpected results, therefore not making it a great idea
>
> That's why I included the bit about iterating the values.  The ordering
> *is* defined.  I find it much more surprising for that ordering to
> be inaccessible via the comparison operators.
>
> I think either the iteration order should be undefined (like a set
> or dict), or the comparison operations should work.  I'd prefer
> the latter, because of the use case I outlined.
>
> --David
> ___
> 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/sinistersnare%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 435 -- Adding an Enum type to the Python standard library

[Barry Warsaw]

On Apr 12, 2013, at 03:53 PM, Lele Gaifax wrote:

>Eli Bendersky  writes:
>
>> These enumeration values are not equal, nor do they and hence may exist
>> in the same set, or as distinct keys in the same dictionary::
>
>I'm not a native speaker and I found the above difficult to parse: is
>there anything missing between "nor do they" and "and hence may exist"?

Oops, yes.  Good catch!  I changed it to:

Because ``Colors`` and ``OtherColors`` are unrelated enumerations, their
values are not equal, and thus they may exist in the same set, or as
distinct keys in the same dictionary::

-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 -- Adding an Enum type to the Python standard library

[Terry Jan Reedy]

On 4/12/2013 9:53 AM, Lele Gaifax wrote:

Eli Bendersky  writes:


These enumeration values are not equal, nor do they and hence may exist
in the same set, or as distinct keys in the same dictionary::


I'm not a native speaker and I found the above difficult to parse: is
there anything missing between "nor do they" and "and hence may exist"?


I am a native speaker and also do not understand the above quote.


___
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 -- Adding an Enum type to the Python standard library

[Barry Warsaw]

On Apr 12, 2013, at 09:03 AM, Michael Urman wrote:

>> You also may not duplicate values in derived enumerations::
>>
>> >>> class BadColors(Colors):
>> ... yellow = 4
>> ... chartreuse = 2 # Oops!
>> Traceback (most recent call last):
>> ...
>> ValueError: Conflicting enums with value '2': 'green' and 'chartreuse'
>>
>
>Is there a convenient way to change this behavior, namely to indicate that
>conflicts are acceptable in a given Enum? While I like the idea of catching
>mistaken collisions, I've seen far too many C/C++ scenarios where multiple
>names map to the same value. This does raise questions, as it's unclear
>whether each name should get its own representation, or whether it's better
>to let DupEnum.name1 is DupEnum.name2 be True.

Currently there is not.  This behavior is defined in the metaclass.

>(For the latter behavior, would adding DupEnum.name2 = DupEnum.name1 after
>the class declaration work today?)

Yes, but the repr/str of the alias will show the original value.

>>> from flufl.enum import Enum
>>> Colors = Enum('Colors', 'red green blue')
>>> Colors.black = Colors.blue
>>> Colors.black

>>> Colors.black is Colors.blue
True

-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] casefolding in pathlib (PEP 428)

[Antoine Pitrou]

Le Fri, 12 Apr 2013 14:43:42 +0200,
Ronald Oussoren  a écrit :
> 
> On 12 Apr, 2013, at 10:39, Antoine Pitrou  wrote:
> >> 
> >> 
> >> Perhaps it would be best if the code never called lower() or
> >> upper() (not even indirectly via os.path.normcase()). Then any
> >> case-folding and path-normalization bugs are the responsibility of
> >> the application, and we won't have to worry about how to fix the
> >> stdlib without breaking backwards compatibility if we ever figure
> >> out how to fix this (which I somehow doubt we ever will anyway :-).
> > 
> > Ok, I've taken a look at the code. Right now lower() is used for two
> > purposes:
> > 
> > 1. comparisons (__eq__ and __ne__)
> > 2. globbing and matching
> > 
> > While (1) could be dropped, for (2) I think we want glob("*.py") to
> > find "SETUP.PY" under Windows. Anything else will probably be
> > surprising to users of that platform.
> 
> Globbing necessarily accesses the filesystem and could in theory do
> the right thing, except for the minor detail of there not being an
> easy way to determine of the names in a particular folder are
> compared case sensitive or not. 

It's also much less efficient, since you have to stat() every potential
match. e.g. when encountering "SETUP.PY", you would have to stat() (or,
rather, lstat()) both "setup.py" and "SETUP.PY" to check if they have
the same st_ino.

> At least for OSX the kernel will normalize names for you, at least
> for HFS+, and therefore two names that don't compare equal with '=='
> can refer to the same file (for example the NFKD and NFKC forms of
> Löwe). 

I don't think differently normalized filenames are as common on OS X as
differently cased filenames are on Windows, right?

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 435 -- Adding an Enum type to the Python standard library

[Barry Warsaw]

On Apr 12, 2013, at 09:58 AM, R. David Murray wrote:

>> The ``Enum`` class supports iteration.  Iteration is defined as the
>> sorted order of the item values::
>> 
>> >>> class FiveColors(Enum):
>> ... pink = 4
>> ... cyan = 5
>> ... green = 2
>> ... blue = 3
>> ... red = 1
>> >>> [v.name for v in FiveColors]
>> ['red', 'green', 'blue', 'pink', 'cyan']
>
>[...]
>
>> Ordered comparisons between enumeration values are *not* supported.  Enums
>> are
>> not integers (but see `IntEnum`_ below)::
>> 
>> >>> Colors.red < Colors.blue
>> Traceback (most recent call last):
>> ...
>> NotImplementedError
>> >>> Colors.red <= Colors.blue
>> Traceback (most recent call last):
>> ...
>> NotImplementedError
>> >>> Colors.blue > Colors.green
>> Traceback (most recent call last):
>> ...
>> NotImplementedError
>> >>> Colors.blue >= Colors.green
>> Traceback (most recent call last):
>> ...
>> NotImplementedError
>
>This is the part that I don't understand.  Enums *clearly* have an
>ordering, since the iteration order is defined and stable.  Why should
>I not be allowed to compare values from the same Enum type?  There are
>certainly use cases where that is very useful.

Nick brought this up in private email, and my response was basically that
iteration order for Enums should not be guaranteed, even if that happens to
work in the current implementation.  The reason why it works in the current
implementation is purely to provide predictable reprs.

Of course, we could sort the values for the repr and remove the sorted() call
in EnumMetaclass.__iter__() but then we would have to add it back for
IntEnums, since we *do* want to make explicit iteration order guarantees for
IntEnums, as they also have full rich comparisons.  I'm just not sure it's
worth it from an implementation point of view.

I will update the PEP to make this more clear.

>In talking to an existing internet protocol it would be natural to use
>IntEnum and this issue would not arise, but I have recently worked on
>an application that had *exactly* the above sort of enumeration used
>internally, when it would have been totally appropriate to use Enum rather
>than IntEnum.  The ap has several places where an ordered comparison
>against the enum is used to check if a code is in the error range or not.

Why Enums and not IntEnums?  Enums will not have ordered comparisons, but
IntEnums will.

-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 -- Adding an Enum type to the Python standard library

[Barry Warsaw]

On Apr 12, 2013, at 10:23 AM, R. David Murray wrote:

>I think either the iteration order should be undefined (like a set
>or dict), or the comparison operations should work.  I'd prefer
>the latter, because of the use case I outlined.

Order (both iteration and comparison) is officially undefined for Enums but
defined for IntEnums.

-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 -- Adding an Enum type to the Python standard library

[Barry Warsaw]

On Apr 12, 2013, at 03:31 PM, Dirkjan Ochtman wrote:

>On Fri, Apr 12, 2013 at 2:55 PM, Eli Bendersky  wrote:
>> Ordered comparisons between enumeration values are *not* supported.  Enums
>> are
>> not integers (but see `IntEnum`_ below)::
>>
>> >>> Colors.red < Colors.blue
>> Traceback (most recent call last):
>> ...
>> NotImplementedError
>> >>> Colors.red <= Colors.blue
>> Traceback (most recent call last):
>> ...
>> NotImplementedError
>> >>> Colors.blue > Colors.green
>> Traceback (most recent call last):
>> ...
>> NotImplementedError
>> >>> Colors.blue >= Colors.green
>> Traceback (most recent call last):
>> ...
>> NotImplementedError
>
>I like much of this PEP, but the exception type for this case seems
>odd to me. Wouldn't a TypeError be more appropriate here?
>
>Somewhat like this:
>
 'a' - 'b'
>Traceback (most recent call last):
>  File "", line 1, in 
>TypeError: unsupported operand type(s) for -: 'str' and 'str'

Interesting.  I'm having a hard time articulating why, but NotImplementedError
just feels more right to me in this case.

-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 -- Adding an Enum type to the Python standard library

[R. David Murray]

On Fri, 12 Apr 2013 10:50:44 -0400, Barry Warsaw  wrote:
> Nick brought this up in private email, and my response was basically that
> iteration order for Enums should not be guaranteed, even if that happens to
> work in the current implementation.  The reason why it works in the current
> implementation is purely to provide predictable reprs.
> 
> Of course, we could sort the values for the repr and remove the sorted() call
> in EnumMetaclass.__iter__() but then we would have to add it back for
> IntEnums, since we *do* want to make explicit iteration order guarantees for
> IntEnums, as they also have full rich comparisons.  I'm just not sure it's
> worth it from an implementation point of view.
> 
> I will update the PEP to make this more clear.

OK.

> >In talking to an existing internet protocol it would be natural to use
> >IntEnum and this issue would not arise, but I have recently worked on
> >an application that had *exactly* the above sort of enumeration used
> >internally, when it would have been totally appropriate to use Enum rather
> >than IntEnum.  The ap has several places where an ordered comparison
> >against the enum is used to check if a code is in the error range or not.
> 
> Why Enums and not IntEnums?  Enums will not have ordered comparisons, but
> IntEnums will.

To take advantage of their incommensurability with other Enums.  It's
not a big deal, though; I'm more concerned that the API be internally
consistent.  I presume that one could always define an Enum subclass
and provide comparison methods if desired :)

--David
___
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 -- Adding an Enum type to the Python standard library

[R. David Murray]

On Fri, 12 Apr 2013 11:02:54 -0400, Barry Warsaw  wrote:
> On Apr 12, 2013, at 03:31 PM, Dirkjan Ochtman wrote:
> >On Fri, Apr 12, 2013 at 2:55 PM, Eli Bendersky  wrote:
> >> >>> Colors.blue >= Colors.green
> >> Traceback (most recent call last):
> >> ...
> >> NotImplementedError
> >
> >I like much of this PEP, but the exception type for this case seems
> >odd to me. Wouldn't a TypeError be more appropriate here?
> >
> >Somewhat like this:
> >
>  'a' - 'b'
> >Traceback (most recent call last):
> >  File "", line 1, in 
> >TypeError: unsupported operand type(s) for -: 'str' and 'str'
> 
> Interesting.  I'm having a hard time articulating why, but NotImplementedError
> just feels more right to me in this case.

I think TypeError is more consistent with the rest of Python:

>>> object() < object()
Traceback (most recent call last):
  File "", line 1, in 
TypeError: unorderable types: object() < object()

You get that automatically if you return NotImplemented from the
comparison methods.  I don't think you should be explicitly raising
NotImplemented.

--David
___
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] casefolding in pathlib (PEP 428)

[Ronald Oussoren]

On 12 Apr, 2013, at 16:59, Antoine Pitrou  wrote:

> Le Fri, 12 Apr 2013 14:43:42 +0200,
> Ronald Oussoren  a écrit :
>> 
>> On 12 Apr, 2013, at 10:39, Antoine Pitrou  wrote:
 
 
 Perhaps it would be best if the code never called lower() or
 upper() (not even indirectly via os.path.normcase()). Then any
 case-folding and path-normalization bugs are the responsibility of
 the application, and we won't have to worry about how to fix the
 stdlib without breaking backwards compatibility if we ever figure
 out how to fix this (which I somehow doubt we ever will anyway :-).
>>> 
>>> Ok, I've taken a look at the code. Right now lower() is used for two
>>> purposes:
>>> 
>>> 1. comparisons (__eq__ and __ne__)
>>> 2. globbing and matching
>>> 
>>> While (1) could be dropped, for (2) I think we want glob("*.py") to
>>> find "SETUP.PY" under Windows. Anything else will probably be
>>> surprising to users of that platform.
>> 
>> Globbing necessarily accesses the filesystem and could in theory do
>> the right thing, except for the minor detail of there not being an
>> easy way to determine of the names in a particular folder are
>> compared case sensitive or not. 
> 
> It's also much less efficient, since you have to stat() every potential
> match. e.g. when encountering "SETUP.PY", you would have to stat() (or,
> rather, lstat()) both "setup.py" and "SETUP.PY" to check if they have
> the same st_ino.

I found a way to determine if names in a directory are stored case sensitive,
at least on OSX. That way you'd only have to perform one call for the directory,
or one call per path element that contains wildcard characters for glob.glob.

That API is definitly platform specific.

> 
>> At least for OSX the kernel will normalize names for you, at least
>> for HFS+, and therefore two names that don't compare equal with '=='
>> can refer to the same file (for example the NFKD and NFKC forms of
>> Löwe). 
> 
> I don't think differently normalized filenames are as common on OS X as
> differently cased filenames are on Windows, right?

The problem is more that HFS+ stores names with decomposed characters,
which basicly means that accents are stored separate from their base
characters. In most input the accented character will be one character,
and hence a naieve comparison like this could fail to match:

.> name = input()
.> for fn in os.listdir('.'):
.>   if fn.lower() == name.lower():
.>  print("Found {} in the current directory".format(name))

Ronald

> 
> 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/ronaldoussoren%40mac.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 435 -- Adding an Enum type to the Python standard library

[Barry Warsaw]

On Apr 12, 2013, at 11:23 AM, R. David Murray wrote:

>To take advantage of their incommensurability with other Enums.  It's
>not a big deal, though; I'm more concerned that the API be internally
>consistent.  I presume that one could always define an Enum subclass
>and provide comparison methods if desired :)

Hey, no peeking! :)

-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 -- Adding an Enum type to the Python standard library

[Ethan Furman]

On 04/12/2013 07:51 AM, Barry Warsaw wrote:

On Apr 12, 2013, at 10:23 AM, R. David Murray wrote:


I think either the iteration order should be undefined (like a set
or dict), or the comparison operations should work.  I'd prefer
the latter, because of the use case I outlined.


Order (both iteration and comparison) is officially undefined for Enums but
defined for IntEnums.


Huh??

From the PEP

The ``Enum`` class supports iteration.  Iteration is defined as the
sorted order of the item values::

>>> class FiveColors(Enum):
... pink = 4
... cyan = 5
... green = 2
... blue = 3
... red = 1
>>> [v.name for v in FiveColors]
['red', 'green', 'blue', 'pink', 'cyan']

--
~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 -- Adding an Enum type to the Python standard library

[Ethan Furman]

On 04/12/2013 08:02 AM, Barry Warsaw wrote:

On Apr 12, 2013, at 03:31 PM, Dirkjan Ochtman wrote:


On Fri, Apr 12, 2013 at 2:55 PM, Eli Bendersky  wrote:

Ordered comparisons between enumeration values are *not* supported.  Enums
are
not integers (but see `IntEnum`_ below)::

 >>> Colors.red < Colors.blue
 Traceback (most recent call last):
 ...
 NotImplementedError
 >>> Colors.red <= Colors.blue
 Traceback (most recent call last):
 ...
 NotImplementedError
 >>> Colors.blue > Colors.green
 Traceback (most recent call last):
 ...
 NotImplementedError
 >>> Colors.blue >= Colors.green
 Traceback (most recent call last):
 ...
 NotImplementedError


I like much of this PEP, but the exception type for this case seems
odd to me. Wouldn't a TypeError be more appropriate here?

Somewhat like this:


'a' - 'b'

Traceback (most recent call last):
  File "", line 1, in 
TypeError: unsupported operand type(s) for -: 'str' and 'str'


Interesting.  I'm having a hard time articulating why, but NotImplementedError
just feels more right to me in this case.


NotImplemented makes it seem like we could implement it in a subclass -- is 
this true?

Also, for a more direct comparison:

--> 'a' < 1
Traceback (most recent call last):
  File "", line 1, in 
TypeError: unorderable types: str() < int()

I would think this is the more appropriate exception and text to use.

--
~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 -- Adding an Enum type to the Python standard library

[Barry Warsaw]

On Apr 12, 2013, at 11:29 AM, R. David Murray wrote:

>You get that automatically if you return NotImplemented from the
>comparison methods.  I don't think you should be explicitly raising
>NotImplemented.

Oh, that's much better.  Thanks, I'll update the implementation, docs, and
PEP.

-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 -- Adding an Enum type to the Python standard library

[Barry Warsaw]

On Apr 12, 2013, at 11:29 AM, R. David Murray wrote:

>You get that automatically if you return NotImplemented from the
>comparison methods.  I don't think you should be explicitly raising
>NotImplemented.

Oh darn, this doesn't work for Python 2.7.  You don't care for PEP 435, but
flufl.enum will have to raise the TypeError explicitly for consistency.

-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 -- Adding an Enum type to the Python standard library

[Barry Warsaw]

On Apr 12, 2013, at 08:36 AM, Ethan Furman wrote:

>Huh??

Refresh the page :).

-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 -- Adding an Enum type to the Python standard library

[Phil Elson]

1) Is there limitation that EnumValues themselves must be immutable?

2) I'm most excited by the prospect of using these Enums as function
defaults. I've not worked it through fully, but I'm guessing the following
will work?

>>> class Colors(Enum):
...red = (256, 0, 0)

>>> def fill(color=Colors.red):
...pass
...
>>> from inspect import signature
>>> print(signature(fill))
(color=)


3) Enums are generally used for defining constants - Is there a case to be
made for using capitals in the 435 as PEP8 suggests, or are enums a special
case? (http://www.python.org/dev/peps/pep-0008/#constants)

4) Is there an easy way to create custom EnumValues subclasses? In
particular it'd be nice to be able to change the __repr__ in some cases to
hide the value itself, which is often not important.


Sorry if this has already been discussed elsewhere (I've only recently
signed up to the dev mailinglist).




On 12 April 2013 16:23, R. David Murray  wrote:

> On Fri, 12 Apr 2013 10:50:44 -0400, Barry Warsaw  wrote:
> > Nick brought this up in private email, and my response was basically that
> > iteration order for Enums should not be guaranteed, even if that happens
> to
> > work in the current implementation.  The reason why it works in the
> current
> > implementation is purely to provide predictable reprs.
> >
> > Of course, we could sort the values for the repr and remove the sorted()
> call
> > in EnumMetaclass.__iter__() but then we would have to add it back for
> > IntEnums, since we *do* want to make explicit iteration order guarantees
> for
> > IntEnums, as they also have full rich comparisons.  I'm just not sure
> it's
> > worth it from an implementation point of view.
> >
> > I will update the PEP to make this more clear.
>
> OK.
>
> > >In talking to an existing internet protocol it would be natural to use
> > >IntEnum and this issue would not arise, but I have recently worked on
> > >an application that had *exactly* the above sort of enumeration used
> > >internally, when it would have been totally appropriate to use Enum
> rather
> > >than IntEnum.  The ap has several places where an ordered comparison
> > >against the enum is used to check if a code is in the error range or
> not.
> >
> > Why Enums and not IntEnums?  Enums will not have ordered comparisons, but
> > IntEnums will.
>
> To take advantage of their incommensurability with other Enums.  It's
> not a big deal, though; I'm more concerned that the API be internally
> consistent.  I presume that one could always define an Enum subclass
> and provide comparison methods if desired :)
>
> --David
> ___
> 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/pelson.pub%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

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2013-04-05 - 2013-04-12)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open3908 ( +3)
  closed 25569 (+61)
  total  29477 (+64)

Open issues with patches: 1728 


Issues opened (38)
==

#17642: IDLE add font resizing hot keys
http://bugs.python.org/issue17642  opened by rhettinger

#17643: Expose weakref callback for introspection purposes.
http://bugs.python.org/issue17643  opened by mark.dickinson

#17644: str.format() crashes
http://bugs.python.org/issue17644  opened by poldnev

#17646: traceback.py has a lot of code duplication
http://bugs.python.org/issue17646  opened by isoschiz

#17647: subprocess.communicate() should preserve colored output on Win
http://bugs.python.org/issue17647  opened by Caitlin.Potter

#17649: Python/Python-ast.c: No such file or directory
http://bugs.python.org/issue17649  opened by pfg

#17651: Errno checking replaced by concrete classes inherited from OSE
http://bugs.python.org/issue17651  opened by atykhonov

#17652: Add skip_on_windows decorator to test.support
http://bugs.python.org/issue17652  opened by berker.peksag

#17653: fix typo in socketserver.rst
http://bugs.python.org/issue17653  opened by tshepang

#17654: IDLE only customizes correctly for OS X when using framework b
http://bugs.python.org/issue17654  opened by Todd.Rovito

#17656: Python 2.7.4 breaks ZipFile extraction of zip files with unico
http://bugs.python.org/issue17656  opened by Vhati

#17658: pythonw.exe crashes on opening IDLE
http://bugs.python.org/issue17658  opened by Acebulf

#17659: First weekday
http://bugs.python.org/issue17659  opened by IzidorMatusov

#17660: mock.patch could whitelist builtins to not need create=True
http://bugs.python.org/issue17660  opened by michael.foord

#17661: documentation of '%r' links to the wrong repr
http://bugs.python.org/issue17661  opened by twouters

#17665: convert to idiomatic unittest code
http://bugs.python.org/issue17665  opened by tshepang

#17666: Extra gzip headers breaks _read_gzip_header
http://bugs.python.org/issue17666  opened by maubp

#17667: Windows: build with "build_pgo.bat -2" fails to optimize pytho
http://bugs.python.org/issue17667  opened by anselm.kruis

#17668: re.split loses characters matching ungrouped parts of a patter
http://bugs.python.org/issue17668  opened by triquetra011

#17670: expandtabs() weirdness
http://bugs.python.org/issue17670  opened by asolano

#17671: io.BufferedRWPair can use uninitialized members
http://bugs.python.org/issue17671  opened by amaury.forgeotdarc

#17673: add `copy_from` argument to temporaryfile
http://bugs.python.org/issue17673  opened by pitrou

#17676: spwd uses -1 for empty attributes
http://bugs.python.org/issue17676  opened by Alexqw

#17679: sysconfig generation uses some env variables multiple times
http://bugs.python.org/issue17679  opened by bkabrda

#17681: Work with an extra field of gzip files
http://bugs.python.org/issue17681  opened by serhiy.storchaka

#17683: socket.getsockname() inconsistent return type with AF_UNIX
http://bugs.python.org/issue17683  opened by giampaolo.rodola

#17684: Skip tests in test_socket like testFDPassSeparate on OS X
http://bugs.python.org/issue17684  opened by jramnani

#17686: Doc using/unix broken link (http://linuxmafia.com/)
http://bugs.python.org/issue17686  opened by hashimo

#17689: Fix test discovery for test_tarfile.py
http://bugs.python.org/issue17689  opened by zach.ware

#17691: Fix test discovery for test_univnewlines.py
http://bugs.python.org/issue17691  opened by zach.ware

#17694: Enhance _PyUnicodeWriter API to control minimum buffer length 
http://bugs.python.org/issue17694  opened by haypo

#17695: _sysconfigdata broken with universal builds on OSX
http://bugs.python.org/issue17695  opened by ronaldoussoren

#17697: Incorrect stacktrace from pdb
http://bugs.python.org/issue17697  opened by donaldcallen

#17700: Update Curses HOWTO for 3.4
http://bugs.python.org/issue17700  opened by akuchling

#17701: Improving strftime documentation
http://bugs.python.org/issue17701  opened by wolever

#17702: os.environ converts key type from string to bytes in KeyError 
http://bugs.python.org/issue17702  opened by Robert.Tasarz

#17703: Trash can mechanism segfault during interpreter finalization i
http://bugs.python.org/issue17703  opened by lemburg

#17704: ImportError: No module named '_curses'
http://bugs.python.org/issue17704  opened by marco.buttu



Most recent 15 issues with no replies (15)
==

#17704: ImportError: No module named '_curses'
http://bugs.python.org/issue17704

#17695: _sysconfigdata broken with universal builds on OSX
http://bugs.python.org/issue17695

#17694: Enhance _PyUnicodeWriter API to control minimum buffer length 
http://bugs.python.org/issue17694

#17691: Fix test discovery for test_univnewlines.py
http://bugs

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

[Guido van Rossum]

On Fri, Apr 12, 2013 at 8:02 AM, Barry Warsaw  wrote:
> Interesting.  I'm having a hard time articulating why, but NotImplementedError
> just feels more right to me in this case.

To me, NotImplementedError means that a subclass didn't implement
something it should have implemented. But that's not the case here, is
it? It's not a bug in the class, it's a bug in the call site. So I
agree it ought to be TypeError.

--
--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 -- Adding an Enum type to the Python standard library

[Ethan Furman]

On 04/12/2013 08:37 AM, Barry Warsaw wrote:

On Apr 12, 2013, at 11:29 AM, R. David Murray wrote:


You get that automatically if you return NotImplemented from the
comparison methods.  I don't think you should be explicitly raising
NotImplemented.


Oh darn, this doesn't work for Python 2.7.  You don't care for PEP 435, but
flufl.enum will have to raise the TypeError explicitly for consistency.


Yeah, 2.x has everything ordered; returning NotImplemented only works for the non-comparison methods (such as add, 
subtract, etc.); one of the nice things about 3.x.  :)


--
~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 -- Adding an Enum type to the Python standard library

[Guido van Rossum]

On Fri, Apr 12, 2013 at 9:34 AM, Guido van Rossum  wrote:
> To me, NotImplementedError means that a subclass didn't implement
> something it should have implemented. But that's not the case here, is
> it? It's not a bug in the class, it's a bug in the call site. So I
> agree it ought to be TypeError.

Seems I was late to this particular argument. :-)

Anyway, as far as I can tell the PEP looks great. I personally think
it would be nicer if regular Enums were ordered (as long as the
underlying values are ordered), but I don't care enough to overrule
the FLUFL.

I do wonder about this passage in the PEP:

> Let's say you wanted to encode an enumeration value in a database.  You might
> want to get the enumeration class object from an enumeration value::
>
> >>> cls = Colors.red.enum
> >>> print(cls.__name__)
> Colors

I don't understand what this has to do with storing enums in a
database. But it reminded me that for the purpose of storing enums in
a database, it would be nice to have two examples: one that stores the
names and looks them up (do you really have to use getattr() for
that?), and one that stores the values and looks them up (how do you
do that at all?).

Should the metaclass-based API used to create IntEnum be documented,
so strongly motivated people can write their own crazy variants?

--
--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] casefolding in pathlib (PEP 428)

[Guido van Rossum]

On Fri, Apr 12, 2013 at 1:39 AM, Antoine Pitrou  wrote:
> Ok, I've taken a look at the code. Right now lower() is used for two
> purposes:
>
> 1. comparisons (__eq__ and __ne__)
> 2. globbing and matching
>
> While (1) could be dropped, for (2) I think we want glob("*.py") to find
> "SETUP.PY" under Windows. Anything else will probably be surprising to
> users of that platform.

Yeah, I suppose so. But there are more crazy details. E.g. IIRC
Windows silently ignores trailing dots in filenames. Do we want
"*.py." to match SETUP.PY then?

>> - On Linux, paths are really bytes; on Windows (at least NTFS), they
>> are really (16-bit) Unicode; on Mac, they are UTF-8 in a specific
>> normal form (except on some external filesystems).
>
> pathlib is just relying on Python 3's sane handling of unicode paths
> (thanks to PEP 383). Bytes paths are never used internally.

I suppose that just leaves Unicode normalization, discussed later in the thread.

>> - On Windows, short names are still supported, making the number of
>> ways to spell the path for any given file even larger.
>
> They are still supported but I doubt they are still relied on (long
> filenames appeared in Windows 95!). I think in common situations we can
> ignore their existence. Specialized tools like Mercurial may have to
> know that they exist, in order to manage potential collisions (but
> Mercurial isn't really the target audience for pathlib, and I don't
> think they would be interested in such an abstraction).

Actually, I've heard of code that dynamically falls back on short
names when paths using long names exceed the system limit for path
length (either 256 or 1024 IIRC). But short names pretty much require
consulting the filesystem, so we can probably ignore them.

I guess the bottom line is that, no matter how hard pathlib tries,
apps cannot always rely on the predictions about filename validity or
equivalence made by pathlib -- we'll have to document that it may be
wrong, even though we have the moral obligation to make sure that it
is right as often as possible.

--
--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] casefolding in pathlib (PEP 428)

[Ralf Schmitt]

Guido van Rossum  writes:

> Actually, I've heard of code that dynamically falls back on short
> names when paths using long names exceed the system limit for path
> length (either 256 or 1024 IIRC). But short names pretty much require
> consulting the filesystem, so we can probably ignore them.

The limit is 260 characters. But longer paths can be handled by
prepending \\?\ and using the unicode APIs.

see http://msdn.microsoft.com/en-us/library/aa365247.aspx#maxpath

we have the following code to handle the above insanity:
,
| def prepend_magic_win32(path):
| assert isinstance(path, unicode), "path must be of type unicode"
| 
| if path.startswith(u""):
| if path.startswith(u"?\\"):
| return path
| else:
| return u"?\\UNC\\" + path[2:]
| else:
| return u"?\\" + path
`

-- 
Cheers
Ralf
___
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] casefolding in pathlib (PEP 428)

[Antoine Pitrou]

On Fri, 12 Apr 2013 19:42:25 +0200
Ralf Schmitt  wrote:
> Guido van Rossum  writes:
> 
> > Actually, I've heard of code that dynamically falls back on short
> > names when paths using long names exceed the system limit for path
> > length (either 256 or 1024 IIRC). But short names pretty much require
> > consulting the filesystem, so we can probably ignore them.
> 
> The limit is 260 characters. But longer paths can be handled by
> prepending \\?\ and using the unicode APIs.
> 
> see http://msdn.microsoft.com/en-us/library/aa365247.aspx#maxpath

Indeed. I thought I might use them by default in pathlib but there are
other pains: notably, extended paths (those starting with \\?\) can
only be absolute.

So pathlib supports *passing* them explicitly (kind of, there are very
few tests for them) but it doesn't constructs them implicitly.

(as Dirkjan pointed out, Mercurial also has domain-specific code to
handle Windows paths quirks; this is where I took the idea of having a
is_reserved() method for NUL, CON, etc.)

Regards

Antoine.


> 
> we have the following code to handle the above insanity:
> ,
> | def prepend_magic_win32(path):
> | assert isinstance(path, unicode), "path must be of type unicode"
> | 
> | if path.startswith(u""):
> | if path.startswith(u"?\\"):
> | return path
> | else:
> | return u"?\\UNC\\" + path[2:]
> | else:
> | return u"?\\" + path
> `
> 

___
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] Biggest Fake Conference in Computer Science

[nelsonsteves]

We are researchers from different parts of the world and conducted a study on  
the world’s biggest bogus computer science conference WORLDCOMP 
( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia 
from University of Georgia, USA.


We submitted a fake paper to WORLDCOMP 2011 and again (the 
same paper with a modified title) to WORLDCOMP 2012. This paper 
had numerous fundamental mistakes. Sample statements from 
that paper include: 

(1). Binary logic is fuzzy logic and vice versa
(2). Pascal developed fuzzy logic
(3). Object oriented languages do not exhibit any polymorphism or inheritance
(4). TCP and IP are synonyms and are part of OSI model 
(5). Distributed systems deal with only one computer
(6). Laptop is an example for a super computer
(7). Operating system is an example for computer hardware


Also, our paper did not express any conceptual meaning.  However, it 
was accepted both the times without any modifications (and without 
any reviews) and we were invited to submit the final paper and a 
payment of $500+ fee to present the paper. We decided to use the 
fee for better purposes than making Prof. Hamid Arabnia (Chairman 
of WORLDCOMP) rich. After that, we received few reminders from 
WORLDCOMP to pay the fee but we never responded. 


We MUST say that you should look at the above website if you have any thoughts 
to submit a paper to WORLDCOMP.  DBLP and other indexing agencies 
have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. 
See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one 
of the 
conferences of WORLDCOMP and notice that there is no listing after 2010. See 
http://sites.google.com/site/dumpconf for comments from well-known researchers 
about WORLDCOMP. If WORLDCOMP is not fake then why did DBLP suddenly stopped 
listing the proceedings after? 


The status of your WORLDCOMP papers can be changed from “scientific” 
to “other” (i.e., junk or non-technical) at any time. See the comments 
http://www.mail-archive.com/tccc@lists.cs.columbia.edu/msg05168.html   
of a respected researcher on this. Better not to have a paper than 
having it in WORLDCOMP and spoil the resume and peace of mind forever!


Our study revealed that WORLDCOMP is a money making business, 
using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing 
out a small chunk of that money (around 20 dollars per paper published 
in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) 
who publicizes WORLDCOMP and also defends it at various forums, using 
fake/anonymous names. The puppet uses fake names and defames other conferences
to divert traffic to WORLDCOMP. He also makes anonymous phone calls and 
threatens the critiques of WORLDCOMP (see Item 7 in Section 5 of 
http://sites.google.com/site/dumpconf ).That is, the puppet does all 
his best to get a maximum number of papers published at WORLDCOMP to 
get more money into his (and Prof. Hamid Arabnia’s) pockets. 


Monte Carlo Resort (the venue of WORLDCOMP until 2012) has refused to 
provide the venue for WORLDCOMP’13 because of the fears of their image 
being tarnished due to WORLDCOMP’s fraudulent activities. WORLDCOMP’13 
will be held at a different resort.


WORLDCOMP will not be held after 2013. 


The paper submission deadline for WORLDCOMP’13 was March 18 and it was 
extended to April 6 and now it is extended to April 20 (it may be extended 
again) but still there are no committee members, no reviewers, and there is no 
conference Chairman. The only contact details available on WORLDCOMP’s 
website is just an email address! Prof. Hamid Arabnia expends the deadline 
to get more papers (means, more registration fee into his pocket!).


Let us make a direct request to Prof. Hamid arabnia: publish all reviews for 
all the papers (after blocking identifiable details) since 2000 conference. 
Reveal the names and affiliations of all the reviewers (for each year) 
and how many papers each reviewer had reviewed on average. We also request 
him to look at the Open Challenge at https://sites.google.com/site/moneycomp1 


Sorry for posting to multiple lists. Spreading the word is the only way to stop 
this bogus conference. Please forward this message to other mailing lists and 
people. 


We are shocked with Prof. Hamid Arabnia and his puppet’s activities 
http://worldcomp-fake-bogus.blogspot.com   Search Google using the 
keyword worldcomp fake for additional links.

___
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 -- Adding an Enum type to the Python standard library

[Russell E. Owen]

In article 
,
 Guido van Rossum  wrote:

> On Fri, Apr 12, 2013 at 9:34 AM, Guido van Rossum  wrote:
> > To me, NotImplementedError means that a subclass didn't implement
> > something it should have implemented. But that's not the case here, is
> > it? It's not a bug in the class, it's a bug in the call site. So I
> > agree it ought to be TypeError.
> 
> Seems I was late to this particular argument. :-)
> 
> Anyway, as far as I can tell the PEP looks great. I personally think
> it would be nicer if regular Enums were ordered (as long as the
> underlying values are ordered), but I don't care enough to overrule
> the FLUFL.

I, too, would strongly prefer to see ordering within an enum. I use 
home-made enums heavily in my code and find ordering comparisons useful 
there.

Using intEnum is certainly doable, but that opens up the door to 
comparing values from different Enums, which is not something I'd want 
to allow.

I don't understand why order tests are seen as a bad thing, as long as 
the values have order (as they will in the common cases of string and 
int values). It seems the code must go out of its way to prohibit such 
tests.

In any case, I'm very pleased to have this library. it will get rid of 
much boilerplate in my code. It seems very well designed, and I'm really 
glad to see it supports subclassing to add values!

-- Russell

___
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 -- Adding an Enum type to the Python standard library

[Barry Warsaw]

On Apr 12, 2013, at 04:57 PM, Phil Elson wrote:

>1) Is there limitation that EnumValues themselves must be immutable?

I'm not sure it makes sense to have mutable EnumValues, but yes, they are
immutable in the sense that you cannot change their underlying value (well,
without hackery).

>2) I'm most excited by the prospect of using these Enums as function
>defaults. I've not worked it through fully, but I'm guessing the following
>will work?

Sure, why not? :)

>>> from flufl.enum import Enum
>>> X = Enum('X', 'a b c')
>>> def doit(default=X.b):
...   pass
... 
>>> from inspect import signature
>>> print(signature(doit))
(default=)

>3) Enums are generally used for defining constants - Is there a case to be
>made for using capitals in the 435 as PEP8 suggests, or are enums a special
>case? (http://www.python.org/dev/peps/pep-0008/#constants)

I dunno, I like that the PEP isn't shouting at me. :)

>4) Is there an easy way to create custom EnumValues subclasses? In
>particular it'd be nice to be able to change the __repr__ in some cases to
>hide the value itself, which is often not important.

Yes, although we aren't documenting it so we don't get locked into the API.
If you look at the flufl.enum implementation, you'll see this is how we
implement IntEnums.

-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] The end of 2.7

[Sturla Molden]

On 07.04.2013 21:50, "Martin v. Löwis" wrote:


So I believe that extension building is becoming more and more
painful on Windows for Python 2.7 as time passes (and it is already
way more painful than it is on Linux), and I see no way to do much
about that. The "stable ABI" would have been a solution, but it's
too late now for 2.7.


I think extension building for Python 2.7 on Windows for this reason is 
moving from VS2008 to GCC 4.7 (MinGW). When using VS, we are stuck with 
an old compiler (i.e. the .NET 3.5 SDK). With GCC, there is no such 
issue - we just link with whatever CRT is appropriate. Thus, providing 
link libraries for GCC/MinGW (both for the Python and the CRT DLL) 
somewhat alleviates the problem, unless using VS is mandatory.


A long-term solution might be to expose the CRT used by the Python 2.7 
DLL with DLL forwarding. That way, linking with the Python DLL's import 
library would also link the correct CRT.


Sturla



















___
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 -- Adding an Enum type to the Python standard library

[Michael Urman]

On Fri, Apr 12, 2013 at 9:30 AM, Barry Warsaw  wrote:

> On Apr 12, 2013, at 09:03 AM, Michael Urman wrote:
> >(For the latter behavior, would adding DupEnum.name2 = DupEnum.name1 after
> >the class declaration work today?)
>
> Yes, but the repr/str of the alias will show the original value.
>

That satisfies my concern. This gives an author the means to provide two
names for a single value, and a way to choose which one is canonical. It's
easy to imagine some corner cases related to persisting those values and
then retrieving them with a later enum definition that changes the
canonical name, but if you store raw values or names it should be easy
enough to work around such things.

Michael
___
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 -- Adding an Enum type to the Python standard library

[Fábio Santos]

On Fri, Apr 12, 2013 at 7:21 PM, Russell E. Owen  wrote:
> Using intEnum is certainly doable, but that opens up the door to
> comparing values from different Enums, which is not something I'd want
> to allow.

I agree. Comparing values from different Enums could cause a lot of
hard to find bugs.

On the other hand, simply checking in `__cmp__` what Enum both values
belong to (since they do have a `enum` attribute) should allow us to
avoid cross-comparing instead of just raising a TypeError. It's not
very intuitive behavior IMHO.

Just my 2 cents.

--
Fábio Santos
___
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 -- Adding an Enum type to the Python standard library

[Barry Warsaw]

On Apr 12, 2013, at 09:43 AM, Guido van Rossum wrote:

>I do wonder about this passage in the PEP:
>
>> Let's say you wanted to encode an enumeration value in a database.  You
>> might want to get the enumeration class object from an enumeration value::
>>
>> >>> cls = Colors.red.enum
>> >>> print(cls.__name__)
>> Colors
>
>I don't understand what this has to do with storing enums in a
>database.

Not much, really.  It's just hold over text from the original motivation for
exposing the enum class as an attribute on the values.  In Mailman, I store
these values in my database and they get reconstituted correctly by the ORM
layer.  Anyway, in this particular case, I think the motivation is unnecessary
for describing the API, so I'll remove that from the PEP.

>But it reminded me that for the purpose of storing enums in a database, it
>would be nice to have two examples: one that stores the names and looks them
>up (do you really have to use getattr() for that?), and one that stores the
>values and looks them up (how do you do that at all?).

It's going to be dependent on how you store and retrieve enum values.

As an example, in my database layer I store the enum values in an integer
column, with the ORM layer knowing which Enum subclass to use.  So all I need
to do to store the value is ``int(enum_value)`` and to get back the original
enum value, I just do ``self._enum[int_value]`` where self._enum is the Enum
subclass.  To me, that's probably the most common way of doing it.

If you store by name though, yes, you'd have to use
``getattr(self._enum, name)``.  At one point Enums also supported getitem
syntax for lookup by name, but consider this case:

class Fruit(Enum):
apple = 'red'
banana = 'yellow'
tangerine = 'orange'
orange = 'reddish yellow'

What should Fruit['orange'] return?  In private email Nick pointed out that
using getattr() for lookup by name works fine, and getitem for look up by
value has been in the API since the beginning, so now Fruit['orange'] is
documented to return Fruit.tangerine, i.e. lookup by value only.  (Actually,
in flufl.enum, lookup-by-name is still there but deprecated.  We can just drop
it for Python 3.4).

>Should the metaclass-based API used to create IntEnum be documented,
>so strongly motivated people can write their own crazy variants?

I think you recommended against that in python-ideas :).

-Barry


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

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

[Barry Warsaw]

On Apr 12, 2013, at 11:21 AM, Russell E. Owen wrote:

>I, too, would strongly prefer to see ordering within an enum. I use 
>home-made enums heavily in my code and find ordering comparisons useful 
>there.

This was all hashed out in gory detail on python-ideas.  I feel strongly that
base EnumValues should be unordered, especially because the underlying values
can be of any type.  What would you expect to happen in this case:

class X(Enum):
a = 1
b = 'hi'

if X.a < myvalue < X.b:
# whaa?

I think for most use cases, IntEnums will fit the bill for those who want
ordered comparisons, and it's also easy to subclass EnumValues to specialize
the behavior (in fact, this is how IntEnums are implemented).

So if you really want ordered-comparisons-with-untyped-enum-values, you can
have them. :)

-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 -- Adding an Enum type to the Python standard library

[Guido van Rossum]

On Fri, Apr 12, 2013 at 12:26 PM, Barry Warsaw  wrote:
> On Apr 12, 2013, at 09:43 AM, Guido van Rossum wrote:
>
>>I do wonder about this passage in the PEP:
>>
>>> Let's say you wanted to encode an enumeration value in a database.  You
>>> might want to get the enumeration class object from an enumeration value::
>>>
>>> >>> cls = Colors.red.enum
>>> >>> print(cls.__name__)
>>> Colors
>>
>>I don't understand what this has to do with storing enums in a
>>database.
>
> Not much, really.  It's just hold over text from the original motivation for
> exposing the enum class as an attribute on the values.  In Mailman, I store
> these values in my database and they get reconstituted correctly by the ORM
> layer.  Anyway, in this particular case, I think the motivation is unnecessary
> for describing the API, so I'll remove that from the PEP.

Yeah, it looked like an editing mistake. :-)

>>But it reminded me that for the purpose of storing enums in a database, it
>>would be nice to have two examples: one that stores the names and looks them
>>up (do you really have to use getattr() for that?), and one that stores the
>>values and looks them up (how do you do that at all?).
>
> It's going to be dependent on how you store and retrieve enum values.
>
> As an example, in my database layer I store the enum values in an integer
> column, with the ORM layer knowing which Enum subclass to use.  So all I need
> to do to store the value is ``int(enum_value)`` and to get back the original
> enum value, I just do ``self._enum[int_value]`` where self._enum is the Enum
> subclass.  To me, that's probably the most common way of doing it.

Agreed. I can't easily find that in the PEP though. It doesn't mention
__getitem__ and I can't find any examples of using [].

> If you store by name though, yes, you'd have to use
> ``getattr(self._enum, name)``.  At one point Enums also supported getitem
> syntax for lookup by name, but consider this case:
>
> class Fruit(Enum):
> apple = 'red'
> banana = 'yellow'
> tangerine = 'orange'
> orange = 'reddish yellow'
>
> What should Fruit['orange'] return?  In private email Nick pointed out that
> using getattr() for lookup by name works fine, and getitem for look up by
> value has been in the API since the beginning, so now Fruit['orange'] is
> documented to return Fruit.tangerine, i.e. lookup by value only.  (Actually,
> in flufl.enum, lookup-by-name is still there but deprecated.  We can just drop
> it for Python 3.4).

Yeah, getattr() is good enough, and it is documented in the PEP.

>>Should the metaclass-based API used to create IntEnum be documented,
>>so strongly motivated people can write their own crazy variants?
>
> I think you recommended against that in python-ideas :).

I have changed my mind; I am now at least +0 on documenting the
metaclass craziness.

--
--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 -- Adding an Enum type to the Python standard library

[Ethan Furman]

On 04/12/2013 12:37 PM, � wrote:

On Fri, Apr 12, 2013 at 7:21 PM, Russell E. Owen  wrote:

Using intEnum is certainly doable, but that opens up the door to
comparing values from different Enums, which is not something I'd want
to allow.


I agree. Comparing values from different Enums could cause a lot of
hard to find bugs.

On the other hand, simply checking in `__cmp__` what Enum both values
belong to (since they do have a `enum` attribute) should allow us to
avoid cross-comparing instead of just raising a TypeError. It's not
very intuitive behavior IMHO.


Something like this is what happens for Enums, but IntEnums are subtypes of 
int, and if we had something like:

class Fruit(IntEnum):
  apples = 1
  bananas = 2
  oranges = 3

class Flowers(IntEnum):
  roses = 1
  lillies = 2
  violets = 3

--> Fruit.apples == 1
True

--> Flowers.roses == 1
True

--> Fruit.apples == 1 == Flowers.roses
???

This way lies madness.

--
~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 -- Adding an Enum type to the Python standard library

[R. David Murray]

On Fri, 12 Apr 2013 15:33:02 -0400, Barry Warsaw  wrote:
> On Apr 12, 2013, at 11:21 AM, Russell E. Owen wrote:
> 
> >I, too, would strongly prefer to see ordering within an enum. I use 
> >home-made enums heavily in my code and find ordering comparisons useful 
> >there.
> 
> This was all hashed out in gory detail on python-ideas.  I feel strongly that
> base EnumValues should be unordered, especially because the underlying values
> can be of any type.  What would you expect to happen in this case:
> 
> class X(Enum):
> a = 1
> b = 'hi'
> 
> if X.a < myvalue < X.b:
> # whaa?
> 
> I think for most use cases, IntEnums will fit the bill for those who want
> ordered comparisons, and it's also easy to subclass EnumValues to specialize
> the behavior (in fact, this is how IntEnums are implemented).
> 
> So if you really want ordered-comparisons-with-untyped-enum-values, you can
> have them. :)

You are right, the problem of comparison of disparate types makes ordering
a non-starter.  But by the same token that means you are going to have to
be consistent and give up on having a sorted iteration and a stable repr:

>>> import enum
>>> class Foo(enum.Enum):
...aa = 1
...bb = 2
...cc = 'hi'
>>> Foo
Traceback (most recent call last):
  File "", line 1, in 
  File "./enum.py", line 103, in __repr__
for k in sorted(cls._enums)))
TypeError: unorderable types: str() < int()

--David
___
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 -- Adding an Enum type to the Python standard library

[Eli Bendersky]

On Fri, Apr 12, 2013 at 1:52 PM, R. David Murray wrote:

> On Fri, 12 Apr 2013 15:33:02 -0400, Barry Warsaw  wrote:
> > On Apr 12, 2013, at 11:21 AM, Russell E. Owen wrote:
> >
> > >I, too, would strongly prefer to see ordering within an enum. I use
> > >home-made enums heavily in my code and find ordering comparisons useful
> > >there.
> >
> > This was all hashed out in gory detail on python-ideas.  I feel strongly
> that
> > base EnumValues should be unordered, especially because the underlying
> values
> > can be of any type.  What would you expect to happen in this case:
> >
> > class X(Enum):
> > a = 1
> > b = 'hi'
> >
> > if X.a < myvalue < X.b:
> > # whaa?
> >
> > I think for most use cases, IntEnums will fit the bill for those who want
> > ordered comparisons, and it's also easy to subclass EnumValues to
> specialize
> > the behavior (in fact, this is how IntEnums are implemented).
> >
> > So if you really want ordered-comparisons-with-untyped-enum-values, you
> can
> > have them. :)
>
> You are right, the problem of comparison of disparate types makes ordering
> a non-starter.  But by the same token that means you are going to have to
> be consistent and give up on having a sorted iteration and a stable repr:
>
> >>> import enum
> >>> class Foo(enum.Enum):
> ...aa = 1
> ...bb = 2
> ...cc = 'hi'
> >>> Foo
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "./enum.py", line 103, in __repr__
> for k in sorted(cls._enums)))
> TypeError: unorderable types: str() < int()
>

I actually think that having values with different types within a single
Enum is conceptually wrong and should be disallowed at creation time. With
enums, you either care or don't care about their actual value. If you don't
care (the most common use case of an enum, IMHO), then no problem here. If
you do care, then it's probably for very specific reasons most of which are
solved by IntEnum. I can't imagine why someone would need differently typed
values in a single enum - this just seems like a completely inappropriate
use of an enum to me.

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] casefolding in pathlib (PEP 428)

[Larry Hastings]

On 04/12/2013 10:05 AM, Guido van Rossum wrote:

On Fri, Apr 12, 2013 at 1:39 AM, Antoine Pitrou  wrote:

I think we want glob("*.py") to find
"SETUP.PY" under Windows. Anything else will probably be surprising to
users of that platform.

Yeah, I suppose so. But there are more crazy details. E.g. IIRC
Windows silently ignores trailing dots in filenames. Do we want
"*.py." to match SETUP.PY then?


Someone who is fresher than I am at Windows programming should answer 
this, but AFAICT Win32 provides no API that will tell you if a 
particular filename / volume is case sensitive.  The VOLUME2 structure 
from GetVolumeInfo doesn't report anything, and FindFirstFileEx provides 
a special flag for you to tell the OS (!) whether or not you want 
case-sensitive globbing.  The closest I can get with my cursory browsing 
of MSDN is that you could infer case-sensitivity from the filesystem 
reported by GetVolumeInfo, but I doubt even that would be perfect.


My only suggestion: lob the problem back into the user's lap, perhaps 
with something like


pathlib.cs['/'] = True
pathlib.cs['/mnt/samba-share'] = False



(long filenames appeared in Windows 95!).


That wasn't their first appearance; I'm pretty sure Windows NT 3.1 
supported long filenames in 1992, and though I don't remember 
specifically it's possible NT 3.1 also supported long and short 
filenames for the same file.  Windows 95 was the first appearance of 
VFAT, the clever hack adding support for long and short filenames to FAT 
filesystems.




/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] PEP 435 -- Adding an Enum type to the Python standard library

[R. David Murray]

On Fri, 12 Apr 2013 14:06:55 -0700, Eli Bendersky  wrote:
> I actually think that having values with different types within a single
> Enum is conceptually wrong and should be disallowed at creation time. With
> enums, you either care or don't care about their actual value. If you don't
> care (the most common use case of an enum, IMHO), then no problem here. If
> you do care, then it's probably for very specific reasons most of which are
> solved by IntEnum. I can't imagine why someone would need differently typed
> values in a single enum - this just seems like a completely inappropriate
> use of an enum to me.

I'm sure someone will come up with one :)

But seriously, even if you require all values to be of the same type,
that doesn't solve the sorting problem:

>>> class Foo(enum.Enum):
...aa = object()
...bb = object()
... 
>>> Foo
Traceback (most recent call last):
  File "", line 1, in 
  File "./enum.py", line 103, in __repr__
for k in sorted(cls._enums)))
TypeError: unorderable types: object() < object()

Now, you could *further* require that the type of enum values be
sortablebut that point you really have no excuse for not allowing
enum values to be compared :)

--David
___
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 -- Adding an Enum type to the Python standard library

[Ethan Furman]

On 04/12/2013 02:06 PM, Eli Bendersky wrote:

On Fri, Apr 12, 2013 at 1:52 PM, R. David Murray wrote:
>>> import enum
>>> class Foo(enum.Enum):
...aa = 1
...bb = 2
...cc = 'hi'
>>> Foo
Traceback (most recent call last):
   File "", line 1, in 
   File "./enum.py", line 103, in __repr__
 for k in sorted(cls._enums)))
TypeError: unorderable types: str() < int()


I actually think that having values with different types within a single Enum 
is conceptually wrong and should be
disallowed at creation time. With enums, you either care or don't care about 
their actual value. If you don't care (the
most common use case of an enum, IMHO), then no problem here. If you do care, 
then it's probably for very specific
reasons most of which are solved by IntEnum. I can't imagine why someone would 
need differently typed values in a single
enum - this just seems like a completely inappropriate use of an enum to me.


+1  (on disallowing the mixed type enum, not the valueless enum being more 
common  ;)
___
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 -- Adding an Enum type to the Python standard library

[Guido van Rossum]

So, pragmatically, if e and f are values of the same enum class,
couldn't e  f (where  is any comparison operator) defer to
e.value  f.value ? Or is the problem with  being == and e
and f being different enum values with the same underlying value? But
that's already iffy, isn't it? (Barry's favorite solution for
serializing to a database wouldn't work either.) And they could still
be distinguished by using 'is' instead of '=='.

On Fri, Apr 12, 2013 at 2:17 PM, R. David Murray  wrote:
> On Fri, 12 Apr 2013 14:06:55 -0700, Eli Bendersky  wrote:
>> I actually think that having values with different types within a single
>> Enum is conceptually wrong and should be disallowed at creation time. With
>> enums, you either care or don't care about their actual value. If you don't
>> care (the most common use case of an enum, IMHO), then no problem here. If
>> you do care, then it's probably for very specific reasons most of which are
>> solved by IntEnum. I can't imagine why someone would need differently typed
>> values in a single enum - this just seems like a completely inappropriate
>> use of an enum to me.
>
> I'm sure someone will come up with one :)
>
> But seriously, even if you require all values to be of the same type,
> that doesn't solve the sorting problem:
>
 class Foo(enum.Enum):
> ...aa = object()
> ...bb = object()
> ...
 Foo
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "./enum.py", line 103, in __repr__
> for k in sorted(cls._enums)))
> TypeError: unorderable types: object() < object()
>
> Now, you could *further* require that the type of enum values be
> sortablebut that point you really have no excuse for not allowing
> enum values to be compared :)
>
> --David
> ___
> 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 -- Adding an Enum type to the Python standard library

[Eli Bendersky]

On Fri, Apr 12, 2013 at 2:17 PM, R. David Murray wrote:

> On Fri, 12 Apr 2013 14:06:55 -0700, Eli Bendersky 
> wrote:
> > I actually think that having values with different types within a single
> > Enum is conceptually wrong and should be disallowed at creation time.
> With
> > enums, you either care or don't care about their actual value. If you
> don't
> > care (the most common use case of an enum, IMHO), then no problem here.
> If
> > you do care, then it's probably for very specific reasons most of which
> are
> > solved by IntEnum. I can't imagine why someone would need differently
> typed
> > values in a single enum - this just seems like a completely inappropriate
> > use of an enum to me.
>
> I'm sure someone will come up with one :)
>
>
Which is precisely the reason to ban it :)


> But seriously, even if you require all values to be of the same type,
> that doesn't solve the sorting problem:
>
> >>> class Foo(enum.Enum):
> ...aa = object()
> ...bb = object()
> ...
> >>> Foo
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "./enum.py", line 103, in __repr__
> for k in sorted(cls._enums)))
> TypeError: unorderable types: object() < object()
>
> Now, you could *further* require that the type of enum values be
> sortablebut that point you really have no excuse for not allowing
> enum values to be compared :)
>

I'm actually not really in favor of enum values being comparable. I think
this is more a C-ism and does not cleanly settle with my concept of what an
enum is. For comparable enums and other C-derived properties, IntEnum is
out there, so call it maybe ;-)

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 -- Adding an Enum type to the Python standard library

[Barry Warsaw]

On Apr 12, 2013, at 12:56 PM, Guido van Rossum wrote:

>Agreed. I can't easily find that in the PEP though. It doesn't mention
>__getitem__ and I can't find any examples of using [].

Indeed, this looks like an omission in the PEP.  flufl.enum's usage
documentation definitely talks about this:

http://pythonhosted.org/flufl.enum/docs/using.html

specifically:

http://pythonhosted.org/flufl.enum/docs/using.html#conversions

Eli, care to add this to the PEP?

>>>Should the metaclass-based API used to create IntEnum be documented,
>>>so strongly motivated people can write their own crazy variants?
>>
>> I think you recommended against that in python-ideas :).
>
>I have changed my mind; I am now at least +0 on documenting the
>metaclass craziness.

It would be fine with me.  I left it out of the flufl.enum docs and we left it
out of the PEP after your original comments, but I'm pretty happy with the API
and can't foresee us changing it (famous last words).

FWIW, we use a special attribute called __value_factory__ on the Enum subclass
to name the class used to create enum values.  This is all there is to
IntEnum:

class IntEnum(Enum):
"""A specialized enumeration with values that are also integers."""
__value_factory__ = IntEnumValue

and even the IntEnumValue class isn't that big.  It can be even smaller in
Python 3.4 because of the workarounds in flufl.enum for Python 2
compatibility, and deprecations.

Eli, what do you think about documenting the extension API?

Cheers,
-Barry


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

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

[Barry Warsaw]

On Apr 12, 2013, at 04:52 PM, R. David Murray wrote:

>You are right, the problem of comparison of disparate types makes ordering
>a non-starter.  But by the same token that means you are going to have to
>be consistent and give up on having a sorted iteration and a stable repr:

Why do you make me cry?

-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 -- Adding an Enum type to the Python standard library

[Barry Warsaw]

On Apr 12, 2013, at 05:17 PM, R. David Murray wrote:

>Now, you could *further* require that the type of enum values be
>sortablebut that point you really have no excuse for not allowing
>enum values to be compared :)

I'd be more willing to give up on sorting for the base enum type's iteration
and repr.  It's not crucial functionality whereas I still don't want the base
enum values to support ordered comparisons.

-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 -- Adding an Enum type to the Python standard library

[Tim Delaney]

On 13 April 2013 08:32, Barry Warsaw  wrote:

> On Apr 12, 2013, at 04:52 PM, R. David Murray wrote:
>
> >You are right, the problem of comparison of disparate types makes ordering
> >a non-starter.  But by the same token that means you are going to have to
> >be consistent and give up on having a sorted iteration and a stable repr:
>
> Why do you make me cry?
>

Just using definition order as the stable iteration order would do the
trick - no need for any comparisons at all. Subclasses (e.g. IntEnum) can
then override it.

You could then easily have a subclass that implemented comparisons defined
based on iteration order. It makes sense not to have this in the base Enum
class (it would be confusing).

On a related note, I really would like to have the ordinal exposed if this
were added.

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] PEP 435 -- Adding an Enum type to the Python standard library

[Barry Warsaw]

On Apr 12, 2013, at 02:34 PM, Guido van Rossum wrote:

>So, pragmatically, if e and f are values of the same enum class,
>couldn't e  f (where  is any comparison operator) defer to
>e.value  f.value ? Or is the problem with  being == and e
>and f being different enum values with the same underlying value? But
>that's already iffy, isn't it? (Barry's favorite solution for
>serializing to a database wouldn't work either.) And they could still
>be distinguished by using 'is' instead of '=='.

If I'm parsing that correctly, yes, I think we don't want to defer to the
enum.value for the base enum type because unrelated enumeration values should
not compare equal.

E.g.

class Colors(Enum):
red = 1
blue = 2
green = 3

class Animals(Enum):
ant = 1
bee = 2
cat = 3

In this case, Animals.bee != Colors.blue.

Of course, they would be == if they derived from IntEnums.

While I personally recommend and use identity to compare enum types, it seems
to be difficult to convince other users to also do so.  We could enforce this
by not implementing __eq__ and __ne__, but it seems worse to disallow this
than to make it work.  E.g.

if shape.color is Colors.red:
# works

if shape.color == Colors.red:
# throws an exception

-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

[Python-Dev] Multiline Strings confusion it tutorial

[Christian Tismer]

I wanted to point a bling guy to the Python wiki:

http://wiki.python.org/moin/BeginnersGuide/Programmers/SimpleExamples#preview

and when reading a little bit, I found the entry on multiline strings.

I found that example pretty contorted, because this is not a multiline 
string.

Instead, there are multiple lines which define a single line string!
Actually, the construct is even syntactically nothing else than a single
line string which is handled by the parser, already.

A multiline string is IMHO a string which value covers multiple lines, 
after whatever

pre-processing was done. I don't think the given example is very helpful,
but adds confusion.

Where would I add such a complaint, usually?
Or should I simply fix it?

cheers - chris

--
Christian Tismer :^)   
Software Consulting  : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/
14482 Potsdam: PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776  fax +49 (30) 700143-0023
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.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 435 -- Adding an Enum type to the Python standard library

[Guido van Rossum]

On Fri, Apr 12, 2013 at 3:44 PM, Barry Warsaw  wrote:
> On Apr 12, 2013, at 02:34 PM, Guido van Rossum wrote:
>
>>So, pragmatically, if e and f are values of the same enum class,
>>couldn't e  f (where  is any comparison operator) defer to
>>e.value  f.value ? Or is the problem with  being == and e
>>and f being different enum values with the same underlying value? But
>>that's already iffy, isn't it? (Barry's favorite solution for
>>serializing to a database wouldn't work either.) And they could still
>>be distinguished by using 'is' instead of '=='.
>
> If I'm parsing that correctly, yes, I think we don't want to defer to the
> enum.value for the base enum type because unrelated enumeration values should
> not compare equal.
>
> E.g.
>
> class Colors(Enum):
> red = 1
> blue = 2
> green = 3
>
> class Animals(Enum):
> ant = 1
> bee = 2
> cat = 3
>
> In this case, Animals.bee != Colors.blue.

No, my proposal was only meant for if the classes are the same. If the
classes are different the comparison should always fail.

> Of course, they would be == if they derived from IntEnums.
>
> While I personally recommend and use identity to compare enum types, it seems
> to be difficult to convince other users to also do so.  We could enforce this
> by not implementing __eq__ and __ne__, but it seems worse to disallow this
> than to make it work.  E.g.
>
> if shape.color is Colors.red:
> # works
>
> if shape.color == Colors.red:
> # throws an exception

Right, I *only* meant this as a way to differentiate between bee and wasp in:

class Insect(Enum):
wasp = 1
bee = 1
ant = 2

We'd have Insect.wasp == Insect.bee < Insect.ant but Insect.wasp is
not Insect.bee.

--
--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 -- Adding an Enum type to the Python standard library

[R. David Murray]

On Fri, 12 Apr 2013 18:35:58 -0400, Barry Warsaw  wrote:
> On Apr 12, 2013, at 05:17 PM, R. David Murray wrote:
> 
> >Now, you could *further* require that the type of enum values be
> >sortablebut that point you really have no excuse for not allowing
> >enum values to be compared :)
> 
> I'd be more willing to give up on sorting for the base enum type's iteration
> and repr.  It's not crucial functionality whereas I still don't want the base
> enum values to support ordered comparisons.

That's fine with me.  I'm just requesting that it be self-consistent.

--David
___
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] Multiline Strings confusion it tutorial

[Steven D'Aprano]

On 13/04/13 08:58, Christian Tismer wrote:

I wanted to point a bling guy to the Python wiki:

http://wiki.python.org/moin/BeginnersGuide/Programmers/SimpleExamples#preview

[...]

Where would I add such a complaint, usually?
Or should I simply fix it?


It's a wiki. You can fix it yourself, next time. I've done it this time.


--
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 -- Adding an Enum type to the Python standard library

[Glenn Linderman]

On 4/12/2013 3:59 PM, Guido van Rossum wrote:

class Insect(Enum):
 wasp = 1
 bee = 1
 ant = 2

We'd have Insect.wasp == Insect.bee < Insect.ant but Insect.wasp is
not Insect.bee.


can't define two names in the same enum to have the same value, per the PEP.
___
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] Multiline Strings confusion it tutorial

[Ethan Furman]

On 04/12/2013 03:58 PM, Christian Tismer wrote:

I wanted to point a bling guy to the Python wiki:

http://wiki.python.org/moin/BeginnersGuide/Programmers/SimpleExamples#preview

and when reading a little bit, I found the entry on multiline strings.


This entry?

Defining multiline strings

string = '''This is a string with embedded newlines.
Also known as a tripled-quoted string.
Whitespace at the beginning of lines is included,
so the above line is indented but the others are not.
'''



I found that example pretty contorted, because this is not a multiline string.
Instead, there are multiple lines which define a single line string!
Actually, the construct is even syntactically nothing else than a single
line string which is handled by the parser, already.


That string has four (4) embedded '\n's -- that makes it multiline.


A multiline string is IMHO a string which value covers multiple lines, after 
whatever
pre-processing was done. I don't think the given example is very helpful,
but adds confusion.


And that string does cover multiple lines.



Where would I add such a complaint, usually?
Or should I simply fix it?


Nothing broken here, move along, nothing to see...

--
~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 -- Adding an Enum type to the Python standard library

[Guido van Rossum]

Well, even better. :-)

On Fri, Apr 12, 2013 at 5:13 PM, Glenn Linderman  wrote:
> On 4/12/2013 3:59 PM, Guido van Rossum wrote:
>
> class Insect(Enum):
> wasp = 1
> bee = 1
> ant = 2
>
> We'd have Insect.wasp == Insect.bee < Insect.ant but Insect.wasp is
> not Insect.bee.
>
>
> can't define two names in the same enum to have the same value, per the PEP.
>
> ___
> 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 -- Adding an Enum type to the Python standard library

[Steven D'Aprano]

On 13/04/13 05:33, Barry Warsaw wrote:

On Apr 12, 2013, at 11:21 AM, Russell E. Owen wrote:


I, too, would strongly prefer to see ordering within an enum. I use
home-made enums heavily in my code and find ordering comparisons useful
there.


This was all hashed out in gory detail on python-ideas.  I feel strongly that
base EnumValues should be unordered, especially because the underlying values
can be of any type.  What would you expect to happen in this case:

 class X(Enum):
 a = 1
 b = 'hi'

 if X.a < myvalue < X.b:
 # whaa?



I would expect the same behaviour from enums that I get in Python 3 from 
non-enums. That is, if enums X.a and X.b happen to both be ints, or both 
strings, then comparisons should succeed, but if they are different types, I 
should get a TypeError.

The above applies to related enums. If they are unrelated (e.g. Colours.red < 
Insects.ant) then I think TypeError is appropriate.



--
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 -- Adding an Enum type to the Python standard library

[Guido van Rossum]

On Fri, Apr 12, 2013 at 7:07 PM, Steven D'Aprano  wrote:
> On 13/04/13 05:33, Barry Warsaw wrote:
>>
>> On Apr 12, 2013, at 11:21 AM, Russell E. Owen wrote:
>>
>>> I, too, would strongly prefer to see ordering within an enum. I use
>>> home-made enums heavily in my code and find ordering comparisons useful
>>> there.
>>
>>
>> This was all hashed out in gory detail on python-ideas.  I feel strongly
>> that
>> base EnumValues should be unordered, especially because the underlying
>> values
>> can be of any type.  What would you expect to happen in this case:
>>
>>  class X(Enum):
>>  a = 1
>>  b = 'hi'
>>
>>  if X.a < myvalue < X.b:
>>  # whaa?
>
>
>
> I would expect the same behaviour from enums that I get in Python 3 from
> non-enums. That is, if enums X.a and X.b happen to both be ints, or both
> strings, then comparisons should succeed, but if they are different types, I
> should get a TypeError.
>
> The above applies to related enums. If they are unrelated (e.g. Colours.red
> < Insects.ant) then I think TypeError is appropriate.

That's exactly what I'm trying to propose too, but Steven has the
better words. :-)

--
--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 -- Adding an Enum type to the Python standard library

[Steven D'Aprano]

On 13/04/13 10:13, Glenn Linderman wrote:


can't define two names in the same enum to have the same value, per the PEP.



I think that's too strong a restriction. I would expect to be able to do this:

class Insect(Enum):
wsap = 1  # Oops, needed for backward compatibility, do not remove.
wasp = 1  # Preferred. Use this in new code.
bee = 2
ant = 3


Or at the very least:

class Insect(Enum):
wasp = wsap = 1
bee = 2
ant = 3


I googled on "C enum" and the very first hit includes a duplicate value:

http://msdn.microsoft.com/en-AU/library/whbyts4t%28v=vs.80%29.aspx

And two examples from asm-generic/errno.h:

#define EWOULDBLOCK EAGAIN  /* Operation would block */
#define EDEADLOCK   EDEADLK


What's the justification for this restriction? I have looked in the PEP, and 
didn't see one.




--
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 -- Adding an Enum type to the Python standard library

[Eli Bendersky]

On Fri, Apr 12, 2013 at 3:23 PM, Barry Warsaw  wrote:

> On Apr 12, 2013, at 12:56 PM, Guido van Rossum wrote:
>
> >Agreed. I can't easily find that in the PEP though. It doesn't mention
> >__getitem__ and I can't find any examples of using [].
>
> Indeed, this looks like an omission in the PEP.  flufl.enum's usage
> documentation definitely talks about this:
>
> http://pythonhosted.org/flufl.enum/docs/using.html
>
> specifically:
>
> http://pythonhosted.org/flufl.enum/docs/using.html#conversions
>
> Eli, care to add this to the PEP?
>
>
Done. getattr did get a mention there, but now I made it more prominent and
described __getitem__ access as well.


>  >>>Should the metaclass-based API used to create IntEnum be documented,
> >>>so strongly motivated people can write their own crazy variants?
> >>
> >> I think you recommended against that in python-ideas :).
> >
> >I have changed my mind; I am now at least +0 on documenting the
> >metaclass craziness.
>
> It would be fine with me.  I left it out of the flufl.enum docs and we
> left it
> out of the PEP after your original comments, but I'm pretty happy with the
> API
> and can't foresee us changing it (famous last words).
>
> FWIW, we use a special attribute called __value_factory__ on the Enum
> subclass
> to name the class used to create enum values.  This is all there is to
> IntEnum:
>
> class IntEnum(Enum):
> """A specialized enumeration with values that are also integers."""
> __value_factory__ = IntEnumValue
>
> and even the IntEnumValue class isn't that big.  It can be even smaller in
> Python 3.4 because of the workarounds in flufl.enum for Python 2
> compatibility, and deprecations.
>
> Eli, what do you think about documenting the extension API?
>

I don't have major objections...

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