On 4/4/2013 10:04 PM, Steven D'Aprano wrote:
When I call int(), I'm expecting an int.
We agree so far...,
That includes well-behaved subclasses of int that continue to behave
like ints in all the ways that matter.
but not here. I currently expect an actual int instance for 3 reasons.
1.
On Fri, Apr 5, 2013 at 6:34 PM, Terry Jan Reedy tjre...@udel.edu wrote:
2. int(rational): for floats, Fractions, and Decimals, this returns the
integral part, truncating toward 0. Decimal and float have __int__ methods.
Fractions, to my surprise, does not, so int must use __floor__ or
Guido van Rossum, 04.04.2013 23:14:
On Thu, Apr 4, 2013 at 1:50 PM, Tim Delaney wrote:
I fall into:
1. int(), float(), str() etc should return that exact class (and
operator.index() should return exactly an int).
2. It could sometimes be useful for __int__() and __index__() to return a
Eric Snow:
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
On 4 April 2013 10:39, Hrvoje Niksic hrvoje.nik...@avl.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 Fri, Apr 5, 2013 at 1:23 AM, Oscar Benjamin
oscar.j.benja...@gmail.com wrote:
The reason for calling int(obj) is to get an object that is precisely
of type int. When I call this I do not want any modified or additional
methods or data attached to the resulting object.
There's something I'm
Am 04.04.2013 16:47, schrieb Chris Angelico:
On Fri, Apr 5, 2013 at 1:23 AM, Oscar Benjamin
oscar.j.benja...@gmail.com wrote:
The reason for calling int(obj) is to get an object that is precisely
of type int. When I call this I do not want any modified or additional
methods or data attached
On Thu, Apr 4, 2013 at 7:47 AM, Chris Angelico ros...@gmail.com wrote:
On Fri, Apr 5, 2013 at 1:23 AM, Oscar Benjamin
oscar.j.benja...@gmail.com wrote:
The reason for calling int(obj) is to get an object that is precisely
of type int. When I call this I do not want any modified or
On 2013-04-04, at 16:47 , Chris Angelico wrote:
Sure, I could override __new__ to do stupid things
Or to do perfectly logical and sensible things, such as implementing
cluster classes or using the base class as a factory of sorts.
in terms of logical expectations, I'd expect
that Foo(x) will
On Fri, Apr 5, 2013 at 1:59 AM, Guido van Rossum gu...@python.org wrote:
On Thu, Apr 4, 2013 at 7:47 AM, Chris Angelico ros...@gmail.com wrote:
Is there any argument that I can pass to Foo() to get back a Bar()?
Would anyone expect there to be one? Sure, I could override __new__ to
do stupid
On 2013-04-04, at 17:01 , Chris Angelico wrote:
On Fri, Apr 5, 2013 at 1:59 AM, Guido van Rossum gu...@python.org wrote:
On Thu, Apr 4, 2013 at 7:47 AM, Chris Angelico ros...@gmail.com wrote:
Is there any argument that I can pass to Foo() to get back a Bar()?
Would anyone expect there to be
On Thu, Apr 4, 2013 at 8:01 AM, Chris Angelico ros...@gmail.com wrote:
On Fri, Apr 5, 2013 at 1:59 AM, Guido van Rossum gu...@python.org wrote:
On Thu, Apr 4, 2013 at 7:47 AM, Chris Angelico ros...@gmail.com wrote:
Is there any argument that I can pass to Foo() to get back a Bar()?
Would
Le Fri, 5 Apr 2013 01:47:45 +1100,
Chris Angelico ros...@gmail.com a écrit :
class Foo:
pass
class Bar(Foo):
pass
Is there any argument that I can pass to Foo() to get back a Bar()?
Would anyone expect there to be one? Sure, I could override __new__ to
do stupid things, but in
On 04/04/2013 08:01 AM, Chris Angelico wrote:
On Fri, Apr 5, 2013 at 1:59 AM, Guido van Rossum gu...@python.org wrote:
On Thu, Apr 4, 2013 at 7:47 AM, Chris Angelico ros...@gmail.com wrote:
Is there any argument that I can pass to Foo() to get back a Bar()?
Would anyone expect there to be one?
On 5 April 2013 02:16, Ethan Furman et...@stoneleaf.us wrote:
On 04/04/2013 08:01 AM, Chris Angelico wrote:
On Fri, Apr 5, 2013 at 1:59 AM, Guido van Rossum gu...@python.org
wrote:
On Thu, Apr 4, 2013 at 7:47 AM, Chris Angelico ros...@gmail.com wrote:
Is there any argument that I can pass
On Thu, Apr 4, 2013 at 1:50 PM, Tim Delaney tim.dela...@aptare.com wrote:
I fall into:
1. int(), float(), str() etc should return that exact class (and
operator.index() should return exactly an int).
2. It could sometimes be useful for __int__() and __index__() to return a
subclass of int.
On 5 Apr 2013 01:07, Chris Angelico ros...@gmail.com wrote:
On Fri, Apr 5, 2013 at 1:59 AM, Guido van Rossum gu...@python.org wrote:
On Thu, Apr 4, 2013 at 7:47 AM, Chris Angelico ros...@gmail.com wrote:
Is there any argument that I can pass to Foo() to get back a Bar()?
Would anyone
On 05/04/13 01:23, Oscar Benjamin wrote:
The reason for calling int(obj) is to get an object that is precisely
of type int. When I call this I do not want any modified or additional
methods or data attached to the resulting object.
When I call int(), I'm expecting an int. That includes
On 04/03/2013 09:04 AM, Steven D'Aprano wrote:
On 04/04/13 01:16, Barry Warsaw wrote:
It's analogous to all
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
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
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
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,
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 Tue, Apr 2, 2013 at 1:44 AM, Nick Coghlan ncogh...@gmail.com wrote:
int() and operator.index() are both type coercion calls to produce true
Python integers - they will never return a subclass, and this is both
deliberate and consistent with all the other builtin types that accept an
On 02/04/13 01:44, Nick Coghlan wrote:
On Mon, Apr 1, 2013 at 12:28 AM, Mark Dickinson dicki...@gmail.com
mailto:dicki...@gmail.com wrote:
As written, int_check would do the wrong thing for bools, too: I
definitely want int(True) to be 1, not True.
For (2) and (4), it's not so
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 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
On Tue, Apr 2, 2013 at 10:53 AM, Mark Dickinson dicki...@gmail.com wrote:
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 Nick's answer to that: int *should* always return something of exact
type int.
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 Nick's answer to that: int *should* always return something of
exact
On Tue, Apr 2, 2013 at 9:58 AM, Maciej Fijalkowski fij...@gmail.com wrote:
My 2 cents here is that which one is called seems to be truly random.
Try looking into what builtin functions call (for example list.pop
calls __int__, who knew)
That sounds like a clear bug to me. It should
On Tue, Apr 2, 2013 at 10:02 AM, Mark Dickinson dicki...@gmail.com wrote:
On Tue, Apr 2, 2013 at 9:58 AM, Maciej Fijalkowski fij...@gmail.comwrote:
My 2 cents here is that which one is called seems to be truly random.
Try looking into what builtin functions call (for example list.pop
calls
On Mon, Apr 1, 2013 at 12:28 AM, Mark Dickinson dicki...@gmail.com wrote:
As written, int_check would do the wrong thing for bools, too: I
definitely want int(True) to be 1, not True.
For (2) and (4), it's not so clear. Are there use-cases for an __index__
return value that's not directly
Hi all,
I was looking into http://bugs.python.org/issue17576 and I found that
the semantics of __int__() and __index__() are not precisely defined in
the documentation and that the implementation (CPython 3.4a) has some
odd behaviour.
Defining two classes:
class Int1(int):
def
On Sun, Mar 31, 2013 at 2:29 PM, Mark Shannon m...@hotpy.org wrote:
class Int1(int):
def __init__(self, val=0):
print(new %s % self.__class__)
class Int2(Int1):
def __int__(self):
return self
and two instances
i1 = Int1()
i2 = Int2()
we get the following
and two instances
i1 = Int1()
i2 = Int2()
we get the following behaviour:
type(int(i1))
class 'int'
I would have expected 'Int1'
type(float(i1))
type 'float'
type(float(i2))
class 'float'
isinstance(int(i1), int)
True
isinstance(int(i2), int)
new class '__main__.Int2'
True
56 matches
Mail list logo
