On Apr 25, 2011, at 11:43 AM, cool-RR wrote:
> Today I was trying to use `total_ordering` for the first time. I was
> expecting that in order to implement e.g. `x > y` it would do `not x < y and
> not x == y`, assuming that `__lt__` and `__eq__` are defined.
This was fixed. The current code
> Ok, I added OS/2 and VMS to the PEP 11. I also opened any issue to
> remember that I should do something to raise an error on build.
For OS/2, I propose to syntactically break the makefile; anybody trying
to build it should then run into that, and
a) can easily overcome the limitation (probably
Hello,
Today I was trying to use `total_ordering` for the first time. I was
expecting that in order to implement e.g. `x > y` it would do `not x < y and
not x == y`, assuming that `__lt__` and `__eq__` are defined. But I see it
just does `y < x`, which is problematic. For example if you have a cl
Because there's no reason to include them, since they are already in
the root (builtins) namespace.
You'll notice that in Python 3, the "types" module only contains types
which are not obviously accessed through easier means:
OK, makes sense, but in this case it would be handy to have some
On 4/25/2011 1:21 PM, Rob Cliffe wrote:
>>> type (3.)
>>> 3..__class__
>>> type(3)
>>> 3.__class__
File "", line 1
3.__class__
^
SyntaxError: invalid syntax
Superficially the last example ought to be legal syntax (and return
).
You are a more sophisticated parser than Python, which is l
On Tue, Apr 26, 2011 at 3:21 AM, Rob Cliffe wrote:
type (3.)
>
3..__class__
>
type(3)
>
3.__class__
> File "", line 1
> 3.__class__
> ^
> SyntaxError: invalid syntax
>
> Superficially the last example ought to be legal syntax (and return 'int'>).
> Is it an
On Mon, Apr 25, 2011 at 1:21 PM, Rob Cliffe wrote:
..
3.__class__
> File "", line 1
> 3.__class__
> ^
> SyntaxError: invalid syntax
>
> Superficially the last example ought to be legal syntax (and return 'int'>).
If it was valid, then
>>> 3.e+7
would have to raise an attr
>>> type (3.)
>>> 3..__class__
>>> type(3)
>>> 3.__class__
File "", line 1
3.__class__
^
SyntaxError: invalid syntax
Superficially the last example ought to be legal syntax (and return
).
Is it an oversight which could be fixed in a straightforward way, or are
there reaso
On 02:01 pm, ha...@interia.pl wrote:
Because there's no reason to include them, since they are already in
the root (builtins) namespace.
You'll notice that in Python 3, the "types" module only contains types
which are not obviously accessed through easier means:
OK, makes sense, but in this
Le mardi 19 avril 2011 à 23:21 +0200, "Martin v. Löwis" a écrit :
> > Well, not "remove" directly, but plan to remove it using the PEP 11
> > procedure (mark OS/2 and VMS as unsupported, and remove the code in
> > Python 3.4).
>
> I think the PEP 11 procedure is just right for this. It *is* a call
Le lundi 25 avril 2011 à 04:47 +0200, Jesus Cea a écrit :
> If a patch in 3.2 is not applicable in 3.3, a "null merge" should be
> done.
Correct. Sorry, I forgot that. And yes, the 3.2 fix was not applicable
to 3.3, that's why I forgot to merge.
> If not, next developer tring to merge will find s
2011/4/25 haael :
>
>> Because there's no reason to include them, since they are already in
>> the root (builtins) namespace.
>>
>> You'll notice that in Python 3, the "types" module only contains types
>> which are not obviously accessed through easier means:
>
>
> OK, makes sense, but in this cas
Because there's no reason to include them, since they are already in
the root (builtins) namespace.
You'll notice that in Python 3, the "types" module only contains types
which are not obviously accessed through easier means:
OK, makes sense, but in this case it would be handy to have some l
On Mon, Apr 25, 2011 at 8:04 AM, haael wrote:
> Sorry if I am asking the obvious, but why are the aliases of set types not
> included in the 'types' module? I thought for a moment that they are just
> classes, but no, they introduce themselves as built-in types, just like any
> other standard Pyth
On Mon, 25 Apr 2011 14:04:35 +0200
haael wrote:
>
> Sorry if I am asking the obvious, but why are the aliases of set types not
> included in the 'types' module?
Because there's no reason to include them, since they are already in
the root (builtins) namespace.
You'll notice that in Python 3, t
Sorry if I am asking the obvious, but why are the aliases of set types not
included in the 'types' module? I thought for a moment that they are just
classes, but no, they introduce themselves as built-in types, just like any
other standard Python type.
> print type(set([1, 2, 4]))
> print
On Mon, 25 Apr 2011 04:47:03 +0200
Jesus Cea wrote:
>
> And yes, I fully realized that I should try to compile locally first.
> Dealing with this unexpected merge when merging my own patch was...
> unexpected, and the code seemed sensible enough.
You should *always* recompile and run the affecte
17 matches
Mail list logo
