On Sat, Feb 23, 2013 at 5:29 AM, Chris Withers ch...@simplistix.co.uk wrote:
...but let's make sure we keep caring about the tools that people really
use, which includes both setuptools and distribute.
The lack of a meaningful transition plan is where I think we fell down
with PEP 345 386, and
On Sat, Feb 23, 2013 at 2:24 PM, Ezio Melotti ezio.melo...@gmail.com wrote:
Hi,
On Sat, Feb 23, 2013 at 5:33 AM, daniel.holth
python-check...@python.org wrote:
http://hg.python.org/peps/rev/de69fe61f300
changeset: 4764:de69fe61f300
user:Daniel Holth dho...@fastmail.fm
date:
Nick Coghlan ncoghlan at gmail.com writes:
Daniel is a fan of this syntax, but I think it is inferior to the
implied approach, so don't expect it to survive to any accepted
version of the PEP :)
Another thing against ~= is that it isn't valid Python syntax. It's not a deal-
breaker, but it
eli.bendersky python-check...@python.org wrote:
+Ordered comparisons between enumeration values are *not* supported. Enums
are
+not integers!
Hmm. I think this limits interoperation with C libraries and prototyping
C code.
Actually all I want from a Python enum is to be like a C enum with
On Sat, 23 Feb 2013 16:02:31 +0100
Stefan Krah ste...@bytereef.org wrote:
eli.bendersky python-check...@python.org wrote:
+Ordered comparisons between enumeration values are *not* supported. Enums
are
+not integers!
Hmm. I think this limits interoperation with C libraries and
On Sun, Feb 24, 2013 at 12:57 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Nick Coghlan ncoghlan at gmail.com writes:
Daniel is a fan of this syntax, but I think it is inferior to the
implied approach, so don't expect it to survive to any accepted
version of the PEP :)
Another thing
On Sun, Feb 24, 2013 at 1:06 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 23 Feb 2013 16:02:31 +0100
Stefan Krah ste...@bytereef.org wrote:
eli.bendersky python-check...@python.org wrote:
+Ordered comparisons between enumeration values are *not* supported.
Enums are
+not
On Sun, 24 Feb 2013 01:31:09 +1000, Nick Coghlan ncogh...@gmail.com wrote:
On Sun, Feb 24, 2013 at 1:06 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 23 Feb 2013 16:02:31 +0100
Stefan Krah ste...@bytereef.org wrote:
eli.bendersky python-check...@python.org wrote:
+Ordered
On Sat, Feb 23, 2013 at 7:57 AM, R. David Murray rdmur...@bitdance.comwrote:
On Sun, 24 Feb 2013 01:31:09 +1000, Nick Coghlan ncogh...@gmail.com
wrote:
On Sun, Feb 24, 2013 at 1:06 AM, Antoine Pitrou solip...@pitrou.net
wrote:
On Sat, 23 Feb 2013 16:02:31 +0100
Stefan Krah
On Feb 23, 2013, at 04:02 PM, Stefan Krah wrote:
Hmm. I think this limits interoperation with C libraries and prototyping
C code.
As for flufl.enums, it doesn't really, because while items are not ints they
are interoperable with ints.
from flufl.enum import make
Colors = make('Colors', 'red
On Sat, 23 Feb 2013 08:27:50 -0800, Eli Bendersky eli...@gmail.com wrote:
On Sat, Feb 23, 2013 at 7:57 AM, R. David Murray rdmur...@bitdance.comwrote:
On Sun, 24 Feb 2013 01:31:09 +1000, Nick Coghlan ncogh...@gmail.com
wrote:
On Sun, Feb 24, 2013 at 1:06 AM, Antoine Pitrou
On Sat, 23 Feb 2013 08:27:50 -0800
Eli Bendersky eli...@gmail.com wrote:
See also http://bugs.python.org/issue16801#msg178542 for another use
case for named values.
I've seen an awful lot of code that uses global variables or class
attributes primarily to get name validation on constant
On 02/23/2013 08:27 AM, Eli Bendersky wrote:
Any suggestions for places in the stdlib where enums could come useful will be
most welcome
codecs.EncodedFile:
errors = 'strict' | 'ignore' | 'xmlcharrefreplace' | 'replace'
socket:
AF_INET, AF_UNIX -- socket domains (first argument to
On Sun, Feb 24, 2013 at 3:15 AM, Eli Bendersky eli...@gmail.com wrote:
Hmm, constants such as os.SEEK_* which serve as *inputs* to stdlib rather
than outputs can actually be a good candidate for enum without worrying
about backwards compatibility.
Not true - users may be taking those values
On Sat, 23 Feb 2013 09:15:54 -0800, Eli Bendersky eli...@gmail.com wrote:
On Sat, Feb 23, 2013 at 9:04 AM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 23 Feb 2013 08:27:50 -0800
Eli Bendersky eli...@gmail.com wrote:
See also http://bugs.python.org/issue16801#msg178542 for another
On 02/23/2013 09:46 AM, Nick Coghlan wrote:
Many other existing libraries would be in the same boat - backwards
compatibility would be an insurmountable barrier to using enums, but
they *could* use named values.
I like the idea of named values, but to be clear about enums: if they are
On Sat, Feb 23, 2013 at 10:46 AM, Nick Coghlan ncogh...@gmail.com wrote:
However, pitching this at the enum level also introduces a mandatory
level of structure we may not care about. All of the arguments about
enums and what they should and shouldn't allow happen at the higher
level, to do
Sounds good to me, thanks for the feedback.. Yes, I guess tackling
known issues is a much better use of time than trying to dig my own up
;)
If you want to be helpful, leave _parse along and find a real bug to work on
;-). There are several urllib bug issues. Or check out the code coverage of
On 2/23/2013 12:46 PM, Nick Coghlan wrote:
For the standard library, we *really don't care* about any of those
things, because we're currently using integers and strings for
everything, so we can't add structure without risking breaking other
people's code. However, just as we can get away with
On Sat, Feb 23, 2013 at 7:02 AM, Stefan Krah ste...@bytereef.org wrote:
eli.bendersky python-check...@python.org wrote:
+Ordered comparisons between enumeration values are *not* supported. Enums
are
+not integers!
I agree with your idea, but note you probably shouldn't call them
On 24 Feb 2013 08:14, Terry Reedy tjre...@udel.edu wrote:
On 2/23/2013 12:46 PM, Nick Coghlan wrote:
For the standard library, we *really don't care* about any of those
things, because we're currently using integers and strings for
everything, so we can't add structure without risking
On Sun, Feb 24, 2013 at 12:19 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 24 Feb 2013 08:14, Terry Reedy tjre...@udel.edu wrote:
I personally think we should skip the bikeshedding over how to avoid
repeating names to make the bound name match the definition name (as with
def, class, and
22 matches
Mail list logo
