Re: [Python-Dev] BDFL delegation for PEP 426 (PyPI metadata 1.3)
On Sat, Feb 23, 2013 at 5:29 AM, Chris Withers 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 is also the main reason I've postponed accepting PEP 426 (PJE and others pointed out a couple of major gaps that either made it difficult to update pkg_resources to read the new format, or else made it difficult to generate metadata that existing releases of pkg_resources would understand). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] peps: PEP 426: replace implied 'version starts with' with new ~= operator
On Sat, Feb 23, 2013 at 2:24 PM, Ezio Melotti wrote: > Hi, > > On Sat, Feb 23, 2013 at 5:33 AM, daniel.holth > wrote: >> http://hg.python.org/peps/rev/de69fe61f300 >> changeset: 4764:de69fe61f300 >> user:Daniel Holth >> date:Fri Feb 22 22:33:09 2013 -0500 >> summary: >> PEP 426: replace implied 'version starts with' with new ~= operator >> > > I haven't seen any discussion about this, but FWIW CSS [0] and JQuery > [1] use ^= for this purpose. > ^ also indicates the beginning of the string in regular expressions > (this is why ^= was chosen for CSS/JQuery). > They also use ~= to indicate "attribute contains word" [0][2]. > Perl also has a similar-looking operator [3] (=~) used to test a regex match. 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 :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] peps: PEP 426: replace implied 'version starts with' with new ~= operator
Nick Coghlan 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 does mean that you can't e.g. use the ast module in the implementation. This might be a factor if the mini-language ever grows (as it recently did, adding parentheses). Regards, Vinay Sajip ___ 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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as
eli.bendersky 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 symbolic representations for the values. Stefan Krah ___ 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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as
On Sat, 23 Feb 2013 16:02:31 +0100 Stefan Krah wrote: > eli.bendersky 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. Agreed, this is a deal-breaker IMO. I'd actually argue that enums are not terribly useful apart from interacting with C constants. 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] [Python-checkins] peps: PEP 426: replace implied 'version starts with' with new ~= operator
On Sun, Feb 24, 2013 at 12:57 AM, Vinay Sajip wrote: > Nick Coghlan 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 does mean that you can't e.g. use the ast module in the > implementation. This might be a factor if the mini-language ever grows (as it > recently did, adding parentheses). Daniel persuaded me that the *semantics* of Ruby's ~> pessimistic version comparison operator are highly desirable. I liked them so much, I'm now proposing them as the default behaviour of version specifiers. Thus, the "~=" operator goes away, and you can use "==" to explicitly request the previously proposed default behaviour, or just append an extra ".0" if you're more pessimistic about a dependency's backwards compatibility policies than the default interpretation. This and other aspects will be brought up on distutils-sig at some point not too far in the future :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as
On Sun, Feb 24, 2013 at 1:06 AM, Antoine Pitrou wrote: > On Sat, 23 Feb 2013 16:02:31 +0100 > Stefan Krah wrote: >> eli.bendersky 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. > > Agreed, this is a deal-breaker IMO. I'd actually argue that enums are > not terribly useful apart from interacting with C constants. I've argued in the past that we should have a "Named Value" mechanism *before* we have a proposal to group named constants in some fashion (such as sequential enums, or binary flag groups). It never gained much traction, even though it could be more useful in many cases (think things like being able to tag a file descriptor with the repr of the object it belongs to) After seeing this checkin, I also suggested to Eli and Barry that any new PEP on this topic should come with a survey of *existing* pseudo-enums in the standard library, and an explanation of how the proposal can be used to make those either easier to debug when they show up in error messages or otherwise make it easier to detect when you've made a mistake while working with them. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as
On Sun, 24 Feb 2013 01:31:09 +1000, Nick Coghlan wrote: > On Sun, Feb 24, 2013 at 1:06 AM, Antoine Pitrou wrote: > > On Sat, 23 Feb 2013 16:02:31 +0100 > > Stefan Krah wrote: > >> eli.bendersky 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. > > > > Agreed, this is a deal-breaker IMO. I'd actually argue that enums are > > not terribly useful apart from interacting with C constants. > > I've argued in the past that we should have a "Named Value" mechanism > *before* we have a proposal to group named constants in some fashion > (such as sequential enums, or binary flag groups). It never gained > much traction, even though it could be more useful in many cases > (think things like being able to tag a file descriptor with the repr > of the object it belongs to) > > After seeing this checkin, I also suggested to Eli and Barry that any > new PEP on this topic should come with a survey of *existing* > pseudo-enums in the standard library, and an explanation of how the > proposal can be used to make those either easier to debug when they > show up in error messages or otherwise make it easier to detect when > you've made a mistake while working with them. 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 values, and I think all of that code would be a prime candidate for using Named Values. Some of them are also enum-like, but many of them are not. So I'm with Nick on this one. --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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as
On Sat, Feb 23, 2013 at 7:57 AM, R. David Murray wrote: > On Sun, 24 Feb 2013 01:31:09 +1000, Nick Coghlan > wrote: > > On Sun, Feb 24, 2013 at 1:06 AM, Antoine Pitrou > wrote: > > > On Sat, 23 Feb 2013 16:02:31 +0100 > > > Stefan Krah wrote: > > >> eli.bendersky 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. > > > > > > Agreed, this is a deal-breaker IMO. I'd actually argue that enums are > > > not terribly useful apart from interacting with C constants. > > > > I've argued in the past that we should have a "Named Value" mechanism > > *before* we have a proposal to group named constants in some fashion > > (such as sequential enums, or binary flag groups). It never gained > > much traction, even though it could be more useful in many cases > > (think things like being able to tag a file descriptor with the repr > > of the object it belongs to) > > > > After seeing this checkin, I also suggested to Eli and Barry that any > > new PEP on this topic should come with a survey of *existing* > > pseudo-enums in the standard library, and an explanation of how the > > proposal can be used to make those either easier to debug when they > > show up in error messages or otherwise make it easier to detect when > > you've made a mistake while working with them. > > 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 values, and I > think all of that code would be a prime candidate for using Named Values. > Some of them are also enum-like, but many of them are not. So I'm with > Nick on this one. > Any suggestions for places in the stdlib where enums could come useful will be most welcome 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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as
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 green blue'.split())
>>> int(Colors.green)
2
>>> 7 + int(Colors.green)
9
Cheers,
-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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as
eli.bendersky wrote: +Ordered comparisons between enumeration values are *not* supported. Enums are +not integers! class WeekDays(Enum): SUNDAY = enum(doc='last day of the weekend') MONDAY = enum(doc='back to work!') TUESDAY = enum(doc='ho hum day') WEDNESDAY = enum(doc='rounding the bend!') THURSDAY= enum(doc='almost Friday!') FRIDAY = enum(doc='last day!') SATURDAY= enum(doc='sleeping in...') So you're saying that MONDAY should not come before TUESDAY?? -- ~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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as
On Sat, 23 Feb 2013 08:27:50 -0800, Eli Bendersky wrote: > On Sat, Feb 23, 2013 at 7:57 AM, R. David Murray wrote: > > > On Sun, 24 Feb 2013 01:31:09 +1000, Nick Coghlan > > wrote: > > > On Sun, Feb 24, 2013 at 1:06 AM, Antoine Pitrou > > wrote: > > > > On Sat, 23 Feb 2013 16:02:31 +0100 > > > > Stefan Krah wrote: > > > >> eli.bendersky 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. > > > > > > > > Agreed, this is a deal-breaker IMO. I'd actually argue that enums are > > > > not terribly useful apart from interacting with C constants. > > > > > > I've argued in the past that we should have a "Named Value" mechanism > > > *before* we have a proposal to group named constants in some fashion > > > (such as sequential enums, or binary flag groups). It never gained > > > much traction, even though it could be more useful in many cases > > > (think things like being able to tag a file descriptor with the repr > > > of the object it belongs to) > > > > > > After seeing this checkin, I also suggested to Eli and Barry that any > > > new PEP on this topic should come with a survey of *existing* > > > pseudo-enums in the standard library, and an explanation of how the > > > proposal can be used to make those either easier to debug when they > > > show up in error messages or otherwise make it easier to detect when > > > you've made a mistake while working with them. > > > > 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 values, and I > > think all of that code would be a prime candidate for using Named Values. > > Some of them are also enum-like, but many of them are not. So I'm with > > Nick on this one. > > > > Any suggestions for places in the stdlib where enums could come useful will > be most welcome Heh. I wasn't actually speaking about the stdlib in the second paragraph :) But, if we had a Named Value facility I would use it in the email library for header error sub-codes (something I haven't actually introduced yet). But, speaking of error codes, it would be really nice if the posix error numbers had a repr that included the name. --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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as
On Sun, Feb 24, 2013 at 2:27 AM, Eli Bendersky wrote: > Any suggestions for places in the stdlib where enums could come useful will > be most welcome For named values in general: - 0, 1, 2 as file descriptors (stdin/stdout/stderr) - 0, 1, 2 as relative seek locations (start, current, end, but I forget the exact mapping) - results of inspect.getgeneratorstate() (currently strings) - decimal rounding modes (currently strings) - opcodes - as a building block to simplify other parts of the dis module - HTML error codes I expect there would be many more possibilities if you dove into particular file formats and protocols. The reason I like named values as a starting point is that they can act primarily as the original type, while still being a useful building block for an enum type added later, as well as for any custom enum types created when people don't want quite the same structural behaviour at the higher level. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as
On Sat, 23 Feb 2013 08:27:50 -0800 Eli Bendersky 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 values, and I > > think all of that code would be a prime candidate for using Named Values. > > Some of them are also enum-like, but many of them are not. So I'm with > > Nick on this one. > > Any suggestions for places in the stdlib where enums could come useful will > be most welcome The constants in the os module (os.SEEK_SET, etc.). The constants in the socket module (socket.AF_INET, etc.). And so on :-) 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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as
On Sat, Feb 23, 2013 at 9:04 AM, Antoine Pitrou wrote: > On Sat, 23 Feb 2013 08:27:50 -0800 > Eli Bendersky 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 values, and I > > > think all of that code would be a prime candidate for using Named > Values. > > > Some of them are also enum-like, but many of them are not. So I'm with > > > Nick on this one. > > > > Any suggestions for places in the stdlib where enums could come useful > will > > be most welcome > > The constants in the os module (os.SEEK_SET, etc.). > The constants in the socket module (socket.AF_INET, etc.). > And so on :-) > 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. The reason I make the *input* vs. *output* distinction, is that for stdlib code that returns values, the user may rely on their numeric values and if we switch to enum code will break. However, for os.SEEK_* this is not the case. Thee can be aliases for enums: class SeekKind(Enum): SEEK_SET = 0 SEEK_CUR = 1 SEEK_END = 2 SEEK_SET = SeekKind.SEEK_SET ... lseek() can be changed to call 'int' on its input, and now os.SEEK_* gain useful string representations when printed. Thoughts? 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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as
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 socket() call) SOCK_STREAM, SOCK_DGRAM, SOCK_RAW -- socket types (second argument) httplib: client - many cookiejar - many turtle tkinter logging warning ___ 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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as
On Sun, Feb 24, 2013 at 3:15 AM, Eli Bendersky 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 and passing them to third party APIs that expect them to be integers (since they're explicitly documented as such). 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 with the relations between a *group* of named values, and how the members of the group interact with other data types. 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 switching from producing and consuming tuples to producing and consuming namedtuples without breaking backwards compatibility, we *could* get away with producing and consuming names values in many cases, so long as those values behaved exactly like they did previously (i.e. as integers - there's little benefit to replacing our string "enums", since they're generally chosen for ease of debugging). We *can't* replace errno values, or the os module seek constants, etc with something that doesn't transparently behave like an integer, because people may currently be using comparisons against their integer counterparts, or passing them to non-stdlib APIs which expect the numeric value. But we could probably get away with changing their __repr__ (as well as switching them to subclasses of int rather than ordinary int objects). 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. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as
On Sat, 23 Feb 2013 09:15:54 -0800, Eli Bendersky wrote: > On Sat, Feb 23, 2013 at 9:04 AM, Antoine Pitrou wrote: > > > On Sat, 23 Feb 2013 08:27:50 -0800 > > Eli Bendersky 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 values, and I > > > > think all of that code would be a prime candidate for using Named > > Values. > > > > Some of them are also enum-like, but many of them are not. So I'm with > > > > Nick on this one. > > > > > > Any suggestions for places in the stdlib where enums could come useful > > will > > > be most welcome > > > > The constants in the os module (os.SEEK_SET, etc.). > > The constants in the socket module (socket.AF_INET, etc.). > > And so on :-) > > > > 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. > > The reason I make the *input* vs. *output* distinction, is that for stdlib > code that returns values, the user may rely on their numeric values and if > we switch to enum code will break. However, for os.SEEK_* this is not the > case. Thee can be aliases for enums: > > class SeekKind(Enum): > SEEK_SET = 0 > SEEK_CUR = 1 > SEEK_END = 2 > > SEEK_SET = SeekKind.SEEK_SET > ... > > lseek() can be changed to call 'int' on its input, and now os.SEEK_* gain > useful string representations when printed. Eh, what? Why does int have to be called? (Hrm, I guess I'd better read the PEP before making any more comments :) I'm preferring Named Values more and more. And I'm just as interested in the returned values case as I am in the input case (as the errno example indicates). --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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as
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 int-based (like True and False are) and don't mess with the math operations (like True and False don't) then we could use them with impunity: True + False = 1 os.SEEK_CUR * 3 = 3 (assuming, of course, that os.SEEK_CUR == 1) -- ~Ethan~ P.S. Has the irrevokable decision been made that enums will *not* be int based? If so, I'll stop bringing up this point -- I'm starting to bore myself with it. ___ 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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as
On 02/23/2013 09:15 AM, Eli Bendersky 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. The reason I make the *input* vs. *output* distinction, is that for stdlib code that returns values, the user may rely on their numeric values and if we switch to enum code will break. However, for os.SEEK_* this is not the case. Thee can be aliases for enums: class SeekKind(Enum): SEEK_SET = 0 SEEK_CUR = 1 SEEK_END = 2 SEEK_SET = SeekKind.SEEK_SET ... lseek() can be changed to call 'int' on its input, and now os.SEEK_* gain useful string representations when printed. Thoughts? If that particular enum is int based, you don't have to a) make the distinction between input/output b) call 'int' on its input and you /still/ get the useful string repr. ;) -- ~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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as
On Sat, Feb 23, 2013 at 10:46 AM, Nick Coghlan 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 with the relations between a *group* of named values, and > how the members of the group interact with other data types. > > 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 switching from > producing and consuming tuples to producing and consuming namedtuples > without breaking backwards compatibility, we *could* get away with > producing and consuming names values in many cases, so long as those > values behaved exactly like they did previously (i.e. as integers - > there's little benefit to replacing our string "enums", since they're > generally chosen for ease of debugging). +1 FWIW, I'm a fan of starting with a basic NamedValue API that avoids the structure decisions. The grouping question is valuable but a GroupedConstant can build on a NamedValue. -eric ___ 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] request._parse
Hope this question belongs here and not in python-ideas, but I'm curious about _parse in the Request object. Specifically, why it was decided to write a custom parse function when the likes or urlparse or urlsplit do essentially the same thing. Doesn't really seem DRY to me.. I was going to change this to use one of the aforementioned functions and submit a patch, but wanted to see if there was any rational behind this that I wasn't seeing. Yes, it's a very minor issue. Call me a stickler for things like this :) -- Demian Brecht http://demianbrecht.github.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] request._parse
On 2/23/2013 2:36 PM, Demian Brecht wrote: Hope this question belongs here and not in python-ideas, but I'm curious about _parse in the Request object. Specifically, why it was decided to write a custom parse function when the likes or urlparse or urlsplit do essentially the same thing. urllib.parse contains urlparse, urlsplit, splittype, splithost, and other utility functions. urllib.request imports many, including those four. Request._parse sequentially uses splittype and splithost, raising if splittype fails. So it seems to me that it does both less and more that the more general functions. Since urlparse is used four other places in the module and urlsplit once, I would start with the assumption that either would have been here if it were the best and easiest. > Doesn't really seem DRY to me. Nearly all the work in _parse is done by splittype, splithost, and unquote, which *is* DRY as far as this function is concerned. The rest of the code is assignment, two ifs, and a raise. 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 some test module (see devguide), and see if more tests are needed. -- Terry Jan Reedy ___ 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] Fwd: request._parse
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 > some test module (see devguide), and see if more tests are needed. ___ 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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as
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 switching from producing and consuming tuples to producing and consuming namedtuples without breaking backwards compatibility, we *could* get away with producing and consuming names values in many cases, so long as those values behaved exactly like they did previously (i.e. as integers - there's little benefit to replacing our string "enums", since they're generally chosen for ease of debugging). It seems that what would specifically be useful is a namedint class whose instances would be ints with a .__name__ attribute and a custom .__str__ and __repr__. (Note that None, False, and True do not have such because the name knowledge is elsewhere -- in __str__ I would guess.) In all other respects, lets them be ints, just as namedtuples are otherwise tuples. As you say, a namedstring is hardly useful as a string can be considered to be its own name. 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 import). Actually, they do not have to match and in cases, one might want a short bound name for retrieval and a longer definition name for display. In any case, compared to the number of functions, classes, and imported modules in the stdlib, there would only be a few namedints, and any typos would be caught very quickly. In io (say) stdin = namedint(1, 'stdin') # or namedint(1, 'standard input (fd 1)') etc plus 3 lines for seek. -- Terry Jan Reedy ___ 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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as
On Sat, Feb 23, 2013 at 7:02 AM, Stefan Krah wrote: > eli.bendersky 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 e-num-erations, then. > Hmm. I think this limits interoperation with C libraries and prototyping > C code. Like I say, despite the lack of alignment with C, that this is the right way to go for a high-level language like Python. But I don't think it should be built-into the language. The bigger question is: what things should be comparable? and this is something that has not been settled. Nor do I believe it can be by the language. This is where I rather liked the old __cmp__ function, not only was it easier to implement, but I could define a comparison and it was clearer that I was doing so (within the class at least). Mark ___ 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] Python 2.7.4 and 3.2.4
Hi there, like posted here: https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.python/xXij443PM6I I'm curious to find out are there any timelines when 2.7.4 and 3.2.4 will be available. I was kinda waiting for it to release new Portable Python so now I'm just curious should I wait bit more and release on this python base or should I go for 2.7.3 and 3.2.3 ___ 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] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as
On 24 Feb 2013 08:14, "Terry Reedy" 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 breaking other >> people's code. However, just as we can get away with switching from >> producing and consuming tuples to producing and consuming namedtuples >> without breaking backwards compatibility, we *could* get away with >> producing and consuming names values in many cases, so long as those >> values behaved exactly like they did previously (i.e. as integers - >> there's little benefit to replacing our string "enums", since they're >> generally chosen for ease of debugging). > > > It seems that what would specifically be useful is a namedint class whose instances would be ints with a .__name__ attribute and a custom .__str__ and __repr__. (Note that None, False, and True do not have such because the name knowledge is elsewhere -- in __str__ I would guess.) In all other respects, lets them be ints, just as namedtuples are otherwise tuples. > > As you say, a namedstring is hardly useful as a string can be considered to be its own name. > > 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 import). Actually, they do not have to match and in cases, one might want a short bound name for retrieval and a longer definition name for display. I realised last night that "labelled values" might be a better building block than "named values". I'll see if I can find my old python-ideas posts about the concept (although, to be honest, I'm not sure it has ever been elaborated much further than it has in this thread) > In any case, compared to the number of functions, classes, and imported modules in the stdlib, there would only be a few namedints, and any typos would be caught very quickly. > > In io (say) > > stdin = namedint(1, 'stdin') # or namedint(1, 'standard input (fd 1)') > etc > plus 3 lines for seek. > > > -- > Terry Jan Reedy > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as
On Sun, Feb 24, 2013 at 12:19 PM, Nick Coghlan wrote: > On 24 Feb 2013 08:14, "Terry Reedy" 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 import). Actually, they do not have to match and in cases, >> one might want a short bound name for retrieval and a longer definition name >> for display. > > I realised last night that "labelled values" might be a better building > block than "named values". > > I'll see if I can find my old python-ideas posts about the concept > (although, to be honest, I'm not sure it has ever been elaborated much > further than it has in this thread) Ah, there we go - I created a recipe a couple of years ago showing the basic concept: http://code.activestate.com/recipes/577810-named-values/ Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
