Re: [Python-Dev] Semantics of __int__(), __index__()

On Fri, Apr 5, 2013 at 6:34 PM, Terry Jan Reedy 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 __round__ > as a backu

Re: [Python-Dev] Semantics of __int__(), __index__()

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.

Re: [Python-Dev] Semantics of __int__(), __index__()

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 r

Re: [Python-Dev] Semantics of __int__(), __index__()

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 as

Re: [Python-Dev] Semantics of __int__(), __index__()

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 well-be

Re: [Python-Dev] Semantics of __int__(), __index__()

On 5 Apr 2013 01:07, "Chris Angelico" wrote: > > On Fri, Apr 5, 2013 at 1:59 AM, Guido van Rossum wrote: > > On Thu, Apr 4, 2013 at 7:47 AM, Chris Angelico 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 over

Re: [Python-Dev] Semantics of __int__(), __index__()

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 > subclass of int. > > So, for the

Re: [Python-Dev] Semantics of __int__(), __index__()

On 5 April 2013 02:16, Ethan Furman wrote: > On 04/04/2013 08:01 AM, Chris Angelico wrote: > >> On Fri, Apr 5, 2013 at 1:59 AM, Guido van Rossum >> wrote: >> >>> On Thu, Apr 4, 2013 at 7:47 AM, Chris Angelico wrote: >>> Is there any argument that I can pass to Foo() to get back a Bar()? >>

Re: [Python-Dev] Semantics of __int__(), __index__()

On 04/04/2013 08:01 AM, Chris Angelico wrote: On Fri, Apr 5, 2013 at 1:59 AM, Guido van Rossum wrote: On Thu, Apr 4, 2013 at 7:47 AM, Chris Angelico 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__ t

Re: [Python-Dev] Semantics of __int__(), __index__()

Le Fri, 5 Apr 2013 01:47:45 +1100, Chris Angelico 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 terms

Re: [Python-Dev] Semantics of __int__(), __index__()

On Thu, Apr 4, 2013 at 8:01 AM, Chris Angelico wrote: > On Fri, Apr 5, 2013 at 1:59 AM, Guido van Rossum wrote: > > On Thu, Apr 4, 2013 at 7:47 AM, Chris Angelico 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 co

Re: [Python-Dev] Semantics of __int__(), __index__()

On 2013-04-04, at 17:01 , Chris Angelico wrote: > On Fri, Apr 5, 2013 at 1:59 AM, Guido van Rossum wrote: >> On Thu, Apr 4, 2013 at 7:47 AM, Chris Angelico 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 overr

Re: [Python-Dev] Semantics of __int__(), __index__()

On Fri, Apr 5, 2013 at 1:59 AM, Guido van Rossum wrote: > On Thu, Apr 4, 2013 at 7:47 AM, Chris Angelico 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 things, but in terms of log

Re: [Python-Dev] Semantics of __int__(), __index__()

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) w

Re: [Python-Dev] Semantics of __int__(), __index__()

On Thu, Apr 4, 2013 at 7:47 AM, Chris Angelico wrote: > On Fri, Apr 5, 2013 at 1:23 AM, 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

Re: [Python-Dev] Semantics of __int__(), __index__()

Am 04.04.2013 16:47, schrieb Chris Angelico: > On Fri, Apr 5, 2013 at 1:23 AM, 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 obj

Re: [Python-Dev] Semantics of __int__(), __index__()

On Fri, Apr 5, 2013 at 1:23 AM, 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. There's something I'm fundamentally not unders

Re: [Python-Dev] Semantics of __int__(), __index__()

On 4 April 2013 10:39, Hrvoje Niksic wrote: > >> On Wed, Apr 3, 2013 at 6:47 AM, Hrvoje Niksic >> 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 s

Re: [Python-Dev] Semantics of __int__(), __index__()

Eric Snow: On Wed, Apr 3, 2013 at 6:47 AM, Hrvoje Niksic 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, including in

Re: [Python-Dev] Semantics of __int__(), __index__()

On 4 Apr 2013 14:58, "Eric Snow" wrote: > > On Wed, Apr 3, 2013 at 6:47 AM, Hrvoje Niksic 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 usa

Re: [Python-Dev] Semantics of __int__(), __index__()

On Wed, Apr 3, 2013 at 6:47 AM, Hrvoje Niksic 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, > including in C cod

Re: [Python-Dev] Semantics of __int__(), __index__()

On 04/04/13 09:07, Cameron Simpson wrote: On 03Apr2013 14:47, Hrvoje Niksic 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 a

Re: [Python-Dev] Semantics of __int__(), __index__()

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.

Re: [Python-Dev] Semantics of __int__(), __index__()

On 03Apr2013 14:47, Hrvoje Niksic 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 instance of an int, and

Re: [Python-Dev] Semantics of __int__(), __index__()

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

Re: [Python-Dev] Semantics of __int__(), __index__()

On 03/31/2013 09:13 PM, francis wrote: why is printing new ? read twice before you write :-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/pyth

Re: [Python-Dev] Semantics of __int__(), __index__()

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 t

Re: [Python-Dev] Semantics of __int__(), __index__()

-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() ca

Re: [Python-Dev] Semantics of __int__(), __index__()

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 be

Re: [Python-Dev] Semantics of __int__(), __index__()

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 fo

Re: [Python-Dev] Semantics of __int__(), __index__()

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. Wh

Re: [Python-Dev] Semantics of __int__(), __index__()

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

Re: [Python-Dev] Semantics of __int__(), __index__()

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 int

Re: [Python-Dev] Semantics of __int__(), __index__()

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 repr(

Re: [Python-Dev] Semantics of __int__(), __index__()

-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)

Re: [Python-Dev] Semantics of __int__(), __index__()

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(),

Re: [Python-Dev] Semantics of __int__(), __index__()

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(i

Re: [Python-Dev] Semantics of __int__(), __index__()

Le Wed, 03 Apr 2013 08:21:22 -0700, Ethan Furman a écrit : > On 04/03/2013 08:14 AM, Nick Coghlan wrote: > > > > On 4 Apr 2013 00:18, "Barry Warsaw" > > wrote: > >> > >> __index__() is a bit trickier because it is not tied directly to > >> type conversion. In this case,

Re: [Python-Dev] Semantics of __int__(), __index__()

On 04/03/2013 08:14 AM, Nick Coghlan wrote: On 4 Apr 2013 00:18, "Barry Warsaw" 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, returning int-subclas

Re: [Python-Dev] Semantics of __int__(), __index__()

On 4 Apr 2013 00:18, "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

Re: [Python-Dev] Semantics of __int__(), __index__()

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 operat

Re: [Python-Dev] Semantics of __int__(), __index__()

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

Re: [Python-Dev] Semantics of __int__(), __index__()

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 g

Re: [Python-Dev] Semantics of __int__(), __index__()

On Wed, Apr 3, 2013 at 12:17 PM, Nick Coghlan 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 > type, so deprecat

Re: [Python-Dev] Semantics of __int__(), __index__()

On 2 Apr 2013 19:04, "Antoine Pitrou" wrote: > > Le Tue, 2 Apr 2013 09:53:41 +0100, > Mark Dickinson a écrit : > > On Tue, Apr 2, 2013 at 9:33 AM, Mark Shannon wrote: > > > > > > > > Hence my original question: what *should* the semantics be? > > > > > > > > I like Nick's answer to that: int *sh

Re: [Python-Dev] Semantics of __int__(), __index__()

On Tue, Apr 2, 2013 at 10:02 AM, Mark Dickinson wrote: > On Tue, Apr 2, 2013 at 9:58 AM, Maciej Fijalkowski 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) >> > >

Re: [Python-Dev] Semantics of __int__(), __index__()

On Tue, Apr 2, 2013 at 9:58 AM, Maciej Fijalkowski 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 definitely be using

Re: [Python-Dev] Semantics of __int__(), __index__()

Le Tue, 2 Apr 2013 09:53:41 +0100, Mark Dickinson a écrit : > On Tue, Apr 2, 2013 at 9:33 AM, Mark Shannon 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: [Python-Dev] Semantics of __int__(), __index__()

On Tue, Apr 2, 2013 at 10:53 AM, Mark Dickinson wrote: > On Tue, Apr 2, 2013 at 9:33 AM, Mark Shannon 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

Re: [Python-Dev] Semantics of __int__(), __index__()

On Tue, Apr 2, 2013 at 9:33 AM, Mark Shannon 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 perhaps ev

Re: [Python-Dev] Semantics of __int__(), __index__()

On 02/04/13 01:44, Nick Coghlan wrote: On Mon, Apr 1, 2013 at 12:28 AM, Mark Dickinson 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 clear. Are there u

Re: [Python-Dev] Semantics of __int__(), __index__()

On Tue, Apr 2, 2013 at 8:07 AM, Mark Dickinson wrote: > On Tue, Apr 2, 2013 at 1:44 AM, Nick Coghlan wrote: > >> There's code in the slot wrappers so that if you return a non-int object >> from either __int__ or __index__, then the interpreter will complain about >> it, and if you return a subcl

Re: [Python-Dev] Semantics of __int__(), __index__()

On Tue, Apr 2, 2013 at 1:44 AM, Nick Coghlan 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 > instance of themselve

Re: [Python-Dev] Semantics of __int__(), __index__()

On Mon, Apr 1, 2013 at 12:28 AM, Mark Dickinson 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 of type int?

Re: [Python-Dev] Semantics of __int__(), __index__()

and two instances i1 = Int1() i2 = Int2() we get the following behaviour: >>> type(int(i1)) I would have expected 'Int1' >>> type(float(i1)) >>> type(float(i2)) >>> isinstance(int(i1), int) True >>> isinstance(int(i2), int) new True >>> isinstance(float(i1), float) True >>> isinstanc

Re: [Python-Dev] Semantics of __int__(), __index__()

On Sun, Mar 31, 2013 at 2:29 PM, Mark Shannon 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 behav