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
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 oth
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
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
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
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 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.
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
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 relation
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 std
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-bas
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.
> > > >
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 the
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 soc
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 clas
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,
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
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
> > >
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 =
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'
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 compa
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
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 wi
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 v
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-
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
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
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 4
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 re
29 matches
Mail list logo
