On Wed, Apr 3, 2013 at 4:42 AM, iMath 2281570...@qq.com wrote:
Hi,
It will be my first post here.
could gevent be apart the standard Python library in future ?
Hi.
Such question generally belongs to python-ideas. To start with you
need to restart the question whether greenlets module
On Sun, Mar 24, 2013 at 2:09 AM, Devin Jeanpierre jeanpierr...@gmail.comwrote:
On Sat, Mar 23, 2013 at 11:21 AM, Nick Coghlan ncogh...@gmail.com wrote:
In this specific case, the error message is
confusing-but-not-really-wrong, due to the two-types-in-one nature
of Python 2.x strings -
On 2 Apr 2013 19:04, Antoine Pitrou solip...@pitrou.net wrote:
Le Tue, 2 Apr 2013 09:53:41 +0100,
Mark Dickinson dicki...@gmail.com a écrit :
On Tue, Apr 2, 2013 at 9:33 AM, Mark Shannon m...@hotpy.org wrote:
Hence my original question: what *should* the semantics be?
I like
On Wed, Apr 3, 2013 at 12:17 PM, Nick Coghlan ncogh...@gmail.com wrote:
Perhaps we should start emitting a DeprecationWarning for int subclasses
returned from __int__ and __index__ in 3.4?
+1. Sounds good to me.
(I like the idea of an explicit error over implicit conversion to the base
On 04/03/2013 01:17 PM, Nick Coghlan wrote:
I like Nick's answer to that: int *should* always return something of
exact type int. Otherwise you're always left wondering whether you
have to do int(int(x)), or perhaps even int(int(int(x))), to be
absolutely sure of getting an int.
On 2013-04-03 13:47, Hrvoje Niksic wrote:
On 04/03/2013 01:17 PM, Nick Coghlan wrote:
I like Nick's answer to that: int *should* always return something of
exact type int. Otherwise you're always left wondering whether you
have to do int(int(x)), or perhaps even int(int(int(x))),
On Apr 03, 2013, at 09:17 PM, Nick Coghlan wrote:
Perhaps we should start emitting a DeprecationWarning for int subclasses
returned from __int__ and __index__ in 3.4?
I definitely agree with doing this for __int__(), since it's intimately tied
to int(), which is clearly a type conversion
Hello,
There's a new mailing-list related to Python code-quality tools.
Are you concerned about the evolution of various code checkers?
Do you have questions or suggestions?
Subscribe here:
http://mail.python.org/mailman/listinfo/code-quality
Best regards,
Ian
On 4 Apr 2013 00:18, Barry Warsaw ba...@python.org wrote:
On Apr 03, 2013, at 09:17 PM, Nick Coghlan wrote:
Perhaps we should start emitting a DeprecationWarning for int subclasses
returned from __int__ and __index__ in 3.4?
I definitely agree with doing this for __int__(), since it's
On 04/03/2013 08:14 AM, Nick Coghlan wrote:
On 4 Apr 2013 00:18, Barry Warsaw ba...@python.org
mailto:ba...@python.org wrote:
__index__() is a bit trickier because it is not tied directly to type
conversion. In this case, int subclasses could be valid, and as Hrvoje later
points out,
Le Wed, 03 Apr 2013 08:21:22 -0700,
Ethan Furman et...@stoneleaf.us a écrit :
On 04/03/2013 08:14 AM, Nick Coghlan wrote:
On 4 Apr 2013 00:18, Barry Warsaw ba...@python.org
mailto:ba...@python.org wrote:
__index__() is a bit trickier because it is not tied directly to
type conversion.
On 03/04/13 23:47, Hrvoje Niksic wrote:
On 04/03/2013 01:17 PM, Nick Coghlan wrote:
I like Nick's answer to that: int *should* always return something of
exact type int. Otherwise you're always left wondering whether you
have to do int(int(x)), or perhaps even int(int(int(x))), to
On 04/04/13 01:16, Barry Warsaw wrote:
On Apr 03, 2013, at 09:17 PM, Nick Coghlan wrote:
Perhaps we should start emitting a DeprecationWarning for int subclasses
returned from __int__ and __index__ in 3.4?
I definitely agree with doing this for __int__(), since it's intimately tied
to int(),
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/03/2013 11:49 AM, Steven D'Aprano wrote:
-1 on forcing __int__, __str__, __float__ etc. to return instances of
the built-in types.
- -1 as well, for the reasons Steven lists.
The only quasi-legitimate reason I know of for checking 'type(x)
I always intended for int() and str() to case subclasses to the built-in
base class, and I don't want to change that rule.
Consider a subclass of int() that overrides __repr__() and __str__() to
print something fancy (maybe it defaults to hex; maybe it's an enum :-). I
want to be able to say
On 04/04/13 03:36, Guido van Rossum wrote:
Consider a subclass of int() that overrides __repr__() and __str__() to
print something fancy (maybe it defaults to hex; maybe it's an enum :-). I
want to be able to say repr(int(x)) and get the standard decimal
representation. Same with strings. If
On Apr 04, 2013, at 01:14 AM, Nick Coghlan wrote:
Implementing __index__ just means This type can be converted to a Python
integer without losing information. Aside from that extra without
information loss qualification, it's the same as __int__.
Hmm.
object.__index__(self)
Called to
On Apr 04, 2013, at 03:04 AM, Steven D'Aprano wrote:
On 04/04/13 01:16, Barry Warsaw wrote:
the other built-in types-as-functions, so int() calls __int__() which must
return a concrete integer.
Why must it? I think that's the claim which must be justified, not just taken
as a given. When we
On Apr 03, 2013, at 01:46 PM, Barry Warsaw wrote:
It's a consistency-of-implementation issue. Where built-in types are
callable, they return concrete instances of themselves. This is true for
e.g. list, tuple, dict, bytes, str, and should also be true of int.
Well, I guess it's consistent for
On 04/03/2013 10:46 AM, Barry Warsaw wrote:
On Apr 04, 2013, at 03:04 AM, Steven D'Aprano wrote:
On 04/04/13 01:16, Barry Warsaw wrote:
the other built-in types-as-functions, so int() calls __int__() which must
return a concrete integer.
Why must it? I think that's the claim which must
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/03/2013 01:50 PM, Ethan Furman wrote:
On 04/03/2013 10:46 AM, Barry Warsaw wrote:
On Apr 04, 2013, at 03:04 AM, Steven D'Aprano wrote:
On 04/04/13 01:16, Barry Warsaw wrote:
the other built-in types-as-functions, so int() calls __int__()
On 04/03/2013 12:21 PM, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/03/2013 01:50 PM, Ethan Furman wrote:
On 04/03/2013 10:46 AM, Barry Warsaw wrote:
On Apr 04, 2013, at 03:04 AM, Steven D'Aprano wrote:
On 04/04/13 01:16, Barry Warsaw wrote:
the other built-in
On 03/31/2013 09:13 PM, francis wrote:
why is printing new class '__main__.Int2'?
read twice before you write :-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On 2013-04-03, at 19:46 , Barry Warsaw wrote:
On Apr 04, 2013, at 03:04 AM, Steven D'Aprano wrote:
On 04/04/13 01:16, Barry Warsaw wrote:
the other built-in types-as-functions, so int() calls __int__() which must
return a concrete integer.
Why must it? I think that's the claim which
On 03Apr2013 14:47, Hrvoje Niksic hrvoje.nik...@avl.com wrote:
| On 04/03/2013 01:17 PM, Nick Coghlan wrote:
| Why would one want to be absolutely sure of getting an int?
So that arithmetic can be relied upon? If a subclass can override
the add methods etc it can look like an int, be a subclass
Hi,
Are you planning to cover the code quality of the interpreter itself
too? I've been recently reading through the cert.org secure coding
practice recommendations and was wondering if there has is any ongoing
effort to perform static analysis on the cpython codebase.
Thanks,
Alfredo
On Wed,
On 4/3/2013 3:36 PM, Ethan Furman wrote:
On 04/03/2013 12:21 PM, Tres Seaver wrote:
Given that requirement, we still don't have to mandate that __int__
return an actual instance of the int type: the coercion could happen
inside int() (as it would for any non-subclass).
I don't understand.
On 04/04/13 09:07, Cameron Simpson wrote:
On 03Apr2013 14:47, Hrvoje Niksic hrvoje.nik...@avl.com wrote:
| On 04/03/2013 01:17 PM, Nick Coghlan wrote:
| Why would one want to be absolutely sure of getting an int?
So that arithmetic can be relied upon? If a subclass can override
the add methods
On Wed, Apr 3, 2013 at 6:47 AM, Hrvoje Niksic hrvoje.nik...@avl.com wrote:
It seems like a good feature that an __int__ implementation can choose to
return an int subclass with additional (and optional) information. After
all, int subclass instances should be usable everywhere where ints are,
Are you planning to cover the code quality of the interpreter itself
too? I've been recently reading through the cert.org secure coding
practice recommendations and was wondering if there has is any ongoing
effort to perform static analysis on the cpython codebase.
AFAICT CPython already
On Mon, Apr 1, 2013 at 4:52 PM, Nick Coghlan ncogh...@gmail.com wrote:
This is really a quality-of-implementation issue in the import system rather
than a core language design problem. It's just that those of us with the
knowledge and ability to fix it aren't inclined to do so because circular
On 4 Apr 2013 14:58, Eric Snow ericsnowcurren...@gmail.com wrote:
On Wed, Apr 3, 2013 at 6:47 AM, Hrvoje Niksic hrvoje.nik...@avl.com
wrote:
It seems like a good feature that an __int__ implementation can choose
to
return an int subclass with additional (and optional) information. After
On 4/3/13, Charles-François Natali cf.nat...@gmail.com wrote:
Are you planning to cover the code quality of the interpreter itself
too? I've been recently reading through the cert.org secure coding
practice recommendations and was wondering if there has is any ongoing
effort to perform static
33 matches
Mail list logo
