On Mon, 25 Apr 2011 04:47:03 +0200
Jesus Cea j...@jcea.es 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
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]))
type 'set'
On Mon, 25 Apr 2011 14:04:35 +0200
haael ha...@interia.pl 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
On Mon, Apr 25, 2011 at 8:04 AM, haael ha...@interia.pl 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
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
2011/4/25 haael ha...@interia.pl:
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 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 some
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
for
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
type (3.)
type 'float'
3..__class__
type 'float'
type(3)
type 'int'
3.__class__
File stdin, line 1
3.__class__
^
SyntaxError: invalid syntax
Superficially the last example ought to be legal syntax (and return
type 'int').
Is it an oversight which could be fixed in a
On Mon, Apr 25, 2011 at 1:21 PM, Rob Cliffe rob.cli...@btinternet.com wrote:
..
3.__class__
File stdin, line 1
3.__class__
^
SyntaxError: invalid syntax
Superficially the last example ought to be legal syntax (and return type
'int').
If it was valid, then
3.e+7
would
On Tue, Apr 26, 2011 at 3:21 AM, Rob Cliffe rob.cli...@btinternet.com wrote:
type (3.)
type 'float'
3..__class__
type 'float'
type(3)
type 'int'
3.__class__
File stdin, line 1
3.__class__
^
SyntaxError: invalid syntax
Superficially the last example ought to be legal
On 4/25/2011 1:21 PM, Rob Cliffe wrote:
type (3.)
type 'float'
3..__class__
type 'float'
type(3)
type 'int'
3.__class__
File stdin, line 1
3.__class__
^
SyntaxError: invalid syntax
Superficially the last example ought to be legal syntax (and return
type 'int').
You are a more
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
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
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
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 has:
17 matches
Mail list logo
