Re: [Python-Dev] casefolding in pathlib (PEP 428)
Le Thu, 11 Apr 2013 15:42:00 -0700, Guido van Rossum gu...@python.org a écrit : On Thu, Apr 11, 2013 at 2:27 PM, Antoine Pitrou solip...@pitrou.net wrote: On Thu, 11 Apr 2013 14:11:21 -0700 Guido van Rossum gu...@python.org 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)
On 12 April 2013 09:39, Antoine Pitrou solip...@pitrou.net 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)
On Fri, Apr 12, 2013 at 4:39 AM, Antoine Pitrou solip...@pitrou.net 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)
Le Fri, 12 Apr 2013 08:06:37 -0400, Devin Jeanpierre jeanpierr...@gmail.com a écrit : On Fri, Apr 12, 2013 at 4:39 AM, Antoine Pitrou solip...@pitrou.net 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)
On 12 Apr, 2013, at 10:39, Antoine Pitrou solip...@pitrou.net 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
Re: [Python-Dev] casefolding in pathlib (PEP 428)
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)
On 12 Apr, 2013, at 15:00, Christian Heimes christ...@python.org 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 http://lists.apple.com/archives/darwin-dev/2007/Apr/msg00036.html, 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
On Fri, Apr 12, 2013 at 2:55 PM, Eli Bendersky eli...@gmail.com 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 stdin, line 1, in module 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
On Fri, 12 Apr 2013 05:55:00 -0700, Eli Bendersky eli...@gmail.com 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
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
Eli Bendersky eli...@gmail.com 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
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 rdmur...@bitdance.comwrote: On Fri, 12 Apr 2013 05:55:00 -0700, Eli Bendersky eli...@gmail.com 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
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/archive%40mail-archive.com
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
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 rdmur...@bitdance.comwrote: 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
On Apr 12, 2013, at 03:53 PM, Lele Gaifax wrote: Eli Bendersky eli...@gmail.com 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
On 4/12/2013 9:53 AM, Lele Gaifax wrote: Eli Bendersky eli...@gmail.com 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
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
EnumValue: Colors.blue [value=3]
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)
Le Fri, 12 Apr 2013 14:43:42 +0200, Ronald Oussoren ronaldousso...@mac.com a écrit : On 12 Apr, 2013, at 10:39, Antoine Pitrou solip...@pitrou.net 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
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
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
On Apr 12, 2013, at 03:31 PM, Dirkjan Ochtman wrote: On Fri, Apr 12, 2013 at 2:55 PM, Eli Bendersky eli...@gmail.com 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 stdin, line 1, in module 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
On Fri, 12 Apr 2013 10:50:44 -0400, Barry Warsaw ba...@python.org 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
On Fri, 12 Apr 2013 11:02:54 -0400, Barry Warsaw ba...@python.org wrote: On Apr 12, 2013, at 03:31 PM, Dirkjan Ochtman wrote: On Fri, Apr 12, 2013 at 2:55 PM, Eli Bendersky eli...@gmail.com 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 stdin, line 1, in module 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 stdin, line 1, in module 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)
On 12 Apr, 2013, at 16:59, Antoine Pitrou solip...@pitrou.net wrote:
Le Fri, 12 Apr 2013 14:43:42 +0200,
Ronald Oussoren ronaldousso...@mac.com a écrit :
On 12 Apr, 2013, at 10:39, Antoine Pitrou solip...@pitrou.net 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
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
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
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 eli...@gmail.com 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 stdin, line 1, in module 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 stdin, line 1, in module 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
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
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
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
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=EnumValue: Colors.red [value=(256, 0, 0)]) 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 rdmur...@bitdance.com wrote: On Fri, 12 Apr 2013 10:50:44 -0400, Barry Warsaw ba...@python.org 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
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
Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
On Fri, Apr 12, 2013 at 8:02 AM, Barry Warsaw ba...@python.org 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
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
On Fri, Apr 12, 2013 at 9:34 AM, Guido van Rossum gu...@python.org 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)
On Fri, Apr 12, 2013 at 1:39 AM, Antoine Pitrou solip...@pitrou.net 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)
Guido van Rossum gu...@python.org 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)
On Fri, 12 Apr 2013 19:42:25 +0200 Ralf Schmitt r...@systemexit.de wrote: Guido van Rossum gu...@python.org 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
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
In article CAP7+vJLUO0B0y+=Jcg8D=jq3mggsam1tb9zztto7ncrke6m...@mail.gmail.com, Guido van Rossum gu...@python.org wrote: On Fri, Apr 12, 2013 at 9:34 AM, Guido van Rossum gu...@python.org 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
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=EnumValue: X.b [value=2])
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
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
On Fri, Apr 12, 2013 at 9:30 AM, Barry Warsaw ba...@python.org 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
On Fri, Apr 12, 2013 at 7:21 PM, Russell E. Owen ro...@uw.edu 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
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] casefolding in pathlib (PEP 428)
On 04/12/2013 10:05 AM, Guido van Rossum wrote: On Fri, Apr 12, 2013 at 1:39 AM, Antoine Pitrou solip...@pitrou.net 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
On Fri, 12 Apr 2013 14:06:55 -0700, Eli Bendersky eli...@gmail.com 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 stdin, line 1, in module 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
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 stdin, line 1, in module 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
So, pragmatically, if e and f are values of the same enum class, couldn't e cmp f (where cmp is any comparison operator) defer to e.value cmp f.value ? Or is the problem with cmp 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 rdmur...@bitdance.com wrote: On Fri, 12 Apr 2013 14:06:55 -0700, Eli Bendersky eli...@gmail.com 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 stdin, line 1, in module 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
On Fri, Apr 12, 2013 at 2:17 PM, R. David Murray rdmur...@bitdance.comwrote: On Fri, 12 Apr 2013 14:06:55 -0700, Eli Bendersky eli...@gmail.com 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 stdin, line 1, in module 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
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 enumclass[int]. 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
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
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
On 13 April 2013 08:32, Barry Warsaw ba...@python.org 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
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 cmp f (where cmp is any comparison operator) defer to e.value cmp f.value ? Or is the problem with cmp 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
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 :^) mailto:tis...@stackless.com 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
On Fri, Apr 12, 2013 at 3:44 PM, Barry Warsaw ba...@python.org 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 cmp f (where cmp is any comparison operator) defer to e.value cmp f.value ? Or is the problem with cmp 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
On Fri, 12 Apr 2013 18:35:58 -0400, Barry Warsaw ba...@python.org 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
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
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
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
Well, even better. :-) On Fri, Apr 12, 2013 at 5:13 PM, Glenn Linderman v+pyt...@g.nevcal.com 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
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
On Fri, Apr 12, 2013 at 7:07 PM, Steven D'Aprano st...@pearwood.info 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
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
On Fri, Apr 12, 2013 at 3:23 PM, Barry Warsaw ba...@python.org 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 enumclass[int]. 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
