Re: [Python-Dev] Are undocumented exceptions considered bugs?

[Stefan Bucur]

On Sun, Mar 24, 2013 at 2:09 AM, Devin Jeanpierre wrote:

> On Sat, Mar 23, 2013 at 11:21 AM, Nick Coghlan  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 - 8-bit strings are used as both text sequences
> > (generally not containing NUL characters) and also as arbitrary binary
> > data, including encoded text (quite likely to contain NUL bytes).
>
> With your terminology, three types: char, non-NUL-text, encoded-text
> (e.g. what happens with ord('ab'))
>
> That's pretty silly, considering that these are all one Python type,
> and TypeError is raised into Python code. Obviously it can't change,
> because of historical reasons, but documenting it would be
> straightforward and helpful. These are not errors you can just infer
> will happen, you need to see it via documentation, reading the source,
> or experimentation (and re experimentation, then you have to establish
> whether or not this was an accident or deliberate).
>

Thanks for your answers, guys, and sorry for replying so late (had a
research paper submission deadline in the mean time...). Filing a bug
report for this issue sounds like a good idea. I have just submitted
http://bugs.python.org/issue17624

Stefan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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 *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.
>
> Agreed.

Perhaps we should start emitting a DeprecationWarning for int subclasses
returned from __int__ and __index__ in 3.4?

(I like the idea of an explicit error over implicit conversion to the base
type, so deprecation of subtypes makes sense as a way forward. We should
check the other type coercion methods, too.)

Cheers,
Nick.

>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Mark Dickinson]

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 deprecation of subtypes makes sense as a way forward. We should
> check the other type coercion methods, too.)
>
Agreed on both points.

Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Hrvoje Niksic]

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

Perhaps we should start emitting a DeprecationWarning for int subclasses
returned from __int__ and __index__ in 3.4?


Why would one want to be absolutely sure of getting an int?

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 code.  I can imagine numpy and similar projects 
would be making use of this ability already -- just think of uses for 
numpy's subclasses of "float".


If one wants to break the abstraction and be absolutely positively sure 
of getting an int and not a subclass thereof, they can write something 
like (0).__add__(obj).  But I suspect this will be extremely rare.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Robert Kern]

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)))", to be
 > > absolutely sure of getting an int.
 >
 > Agreed.

Perhaps we should start emitting a DeprecationWarning for int subclasses
returned from __int__ and __index__ in 3.4?


Why would one want to be absolutely sure of getting an int?

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
code.  I can imagine numpy and similar projects would be making use of this
ability already -- just think of uses for numpy's subclasses of "float".


We don't.

[~]
|1> type(float(np.float64(1.0)))
float

[~]
|2> type(int(np.int32(1)))
int

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Barry Warsaw]

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 operation.  It's analogous to all
the other built-in types-as-functions, so int() calls __int__() which must
return a concrete integer.

__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-subclasses from __index__() should still work for
all valid use cases.

(Bug 17576 would still be a bug in this scenario, since obj.__index__() still
needs to be called by operator.index() even when it's an int subclass.)

>(I like the idea of an explicit error over implicit conversion to the base
>type, so deprecation of subtypes makes sense as a way forward. We should
>check the other type coercion methods, too.)

+1

-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] [Announcement] New mailing list for code quality tools including Flake8, Pyflakes and Pep8

[Ian Cordasco]

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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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
tied
> to int(), which is clearly a type conversion operation.  It's analogous
to all
> the other built-in types-as-functions, so int() calls __int__() which must
> return a concrete integer.
>
> __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-subclasses from __index__() should still work
for
> all valid use cases.

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

Cheers,
Nick.

>
> (Bug 17576 would still be a bug in this scenario, since obj.__index__()
still
> needs to be called by operator.index() even when it's an int subclass.)
>
> >(I like the idea of an explicit error over implicit conversion to the
base
> >type, so deprecation of subtypes makes sense as a way forward. We should
> >check the other type coercion methods, too.)
>
> +1
>
> -Barry
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ethan Furman]

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-subclasses from __index__() should still work for
all valid use cases.


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


How is that possible?  Whether int or int subclass, if I'm implementing __index__ it means my type is not an int 
subclass, and when I return an int I most certainly have lost information from the original type.


--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Antoine Pitrou]

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, int subclasses could be valid, and
> >> as Hrvoje later points out, returning int-subclasses from
> >> __index__() should still work for all valid use cases.
> >
> > 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__.
> 
> How is that possible?  Whether int or int subclass, if I'm
> implementing __index__ it means my type is not an int subclass, and
> when I return an int I most certainly have lost information from the
> original type.

Without losing information about the numeric value.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Steven D'Aprano]

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 be
 > > absolutely sure of getting an int.
 >
 > Agreed.

Perhaps we should start emitting a DeprecationWarning for int subclasses
returned from __int__ and __index__ in 3.4?


Why would one want to be absolutely sure of getting an int?

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



I agree with Hrvoje here, and I have code that's probably going to be impacted 
by any change in behaviour.

In OO terms, an instance of an int subclass *is* an int, and we shouldn't care 
whether __int__ returns a subclass or a builtin. I think that before any change 
is made, even mere DeprecationWarning, there needs to be a very strong reason 
justifying restricting __int__ to return a built-in int.

To put it another way, I think it is perfectly reasonable for __int__ to 
enforce the constraint ``isinstance(result, int)`` but *not* to enforce the 
constraint ``type(result) is int``. We rarely, if ever, write explicit type 
checks like the second. Why should __int__ etc. implicitly do so?


This issue doesn't just apply to ints. For example:

py> class MyStr(str):
... def __str__(self):
... return self
...
py> s = MyStr('spam')
py> type(str(s))



This seems perfectly reasonable to me: __str__ is expected to return a string, 
and it does. If I absolutely must have a built-in str, I can do this:

py> type(''.join(s))


But I can't really think of any cases where I am going to insist on a built-in 
str, instead of accepting anything that passes either the weaker isinstance 
check. Even if there are such cases, surely they are going to be rare and 
unusual.

(I note that in OO terms, we don't really have good terminology for "an instance of 
a class, excluding instances of any subclasses". That's because in OO terms we 
shouldn't care whether the type of the instance is the superclass or subclass, at least 
not in general.)


-1 on forcing __int__, __str__, __float__ etc. to return instances of the 
built-in types.



--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Steven D'Aprano]

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(), which is clearly a type conversion operation.  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 a given.


When we call n = int(something), what's the use-case for caring that n is an
instance of built-in int but not of a subclass, and is that use-case so
compelling that it must be enforced for all uses of int() etc.?

As I see it, what I expect is this:


n = int(something)
assert isinstance(n, int)


not this:


n = int(something)
assert type(n) is int


I haven't cared about checking type identity since "Unifying types and classes" 
way back in Python 2.2, and I don't see why we should enforce a more restrictive rule now.




--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Tres Seaver]

-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) is int'
rather than 'isinstance(x, int)' is speed.



Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlFcV/wACgkQ+gerLs4ltQ6OBwCg0YMyUdiji82TwYQZTx85F9cJ
wmMAoKBL13C+a4MN640jL5X+X+G9RP5b
=8q3C
-END PGP SIGNATURE-

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Guido van Rossum]

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(int(x)) and get the standard decimal
representation. Same with strings. If int() or str() were allowed to return
a subclass instance, this wouldn't work, and I'd have to resort to
draconian measures. (Betcha the first few solutions you come up with don't
even work. :-)

There are plenty of other use cases where a trivial subclass of one of the
built-in types is used as some kind of "flag" -- e.g. maybe for values that
ought to be serialized differently, or to enable some kind of type checking
-- but it should always be possible to convert such values to the
underlying base class to remove the special treatment.

-- 
--Guido van Rossum (python.org/~guido
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Steven D'Aprano]

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() or str() were allowed to return
a subclass instance, this wouldn't work, and I'd have to resort to
draconian measures.



int and str currently are allowed to return subclass instances.



(Betcha the first few solutions you come up with don't
even work. :-)


Well, I'm always game to learn something. Challenge accepted.


# Force a string subclass s to a built-in string.
''.join(s)


# Force an int subclass n to a built-in int.
(0).__add__(n)


# And similarly for float subclass.
0.0.__add__(x)



--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Barry Warsaw]

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 implement operator.index(). Also called whenever Python needs an
integer object (such as in slicing, or in the built-in bin(), hex() and
oct() functions). Must return an integer.

operator.index(a)
operator.__index__(a)
Return a converted to an integer. Equivalent to a.__index__().

bin(x)
Convert an integer number to a binary string. The result is a valid Python
expression. If x is not a Python int object, it has to define an
__index__() method that returns an integer.

Certainly, in slicing an int subclass will work fine:

>>> class myint(int):
...pass
... 
>>> range(10)[myint(2):myint(3)]
range(2, 3)

Same goes for hex/oct/bin:

>>> hex(myint(4))
'0x4'
>>> bin(myint(4))
'0b100'
>>> oct(myint(4))
'0o4'

Also, hex/oct/bin aren't types, they're functions, so this doesn't seem
equivalent to int or str for me.  The latter two are much more equivalent to
the built-in tuple, dict, and list types.

So I don't think there's any inconsistency in allowing int subclasses to be
returned from __index__(), and nothing should break, so I see no reason to
change the status quo here.

>>> class anint(int):
...   def __index__(self):
... return myint(self)
... 
>>> from operator import index
>>> type(index(anint(7)))


Aside: It seems a bit odd to me that bin/hex/oct are defined to use
__index__() instead of __int__(), but that's probably not worth arguing
about.

Cheers,
-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Barry Warsaw]

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 call n = int(something), what's the use-case for caring
>that n is an instance of built-in int but not of a subclass, and is that
>use-case so compelling that it must be enforced for all uses of int() etc.?

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.

-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Barry Warsaw]

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 some of those built-in types .

-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ethan Furman]

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 justified, not just taken
as a given.  When we call n = int(something), what's the use-case for caring
that n is an instance of built-in int but not of a subclass, and is that
use-case so compelling that it must be enforced for all uses of int() etc.?


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.


+1
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Tres Seaver]

-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__()
 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 call n = int(something), what's
>>> the use-case for caring that n is an instance of built-in int but
>>> not of a subclass, and is that use-case so compelling that it must
>>> be enforced for all uses of int() etc.?
>> 
>> 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.

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



Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlFcgVcACgkQ+gerLs4ltQ4ScwCfScssK/Cv74lPitQxbygmk5h/
RGoAnj2yUEgmEgorJi8GZh0GEB/iJrN1
=0I+y
-END PGP SIGNATURE-

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ethan Furman]

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 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 call n = int(something), what's
the use-case for caring that n is an instance of built-in int but
not of a subclass, and is that use-case so compelling that it must
be enforced for all uses of int() etc.?


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.


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.  A non-int could only become an int via __int__, which int() calls.  What magic is there in int() to 
turn any arbitrary object into an integer?


--> class NonInt():
...   def __str__(self):
... return "Not an integer!"
...
--> ni = NonInt()
--> ni
<__main__.NonInt object at 0x267a090>
--> str(ni)
'Not an integer!'
--> int(ni)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: int() argument must be a string or a number, not 'NonInt'

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[francis]

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/python-dev/archive%40mail-archive.com

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

[Xavier Morel]

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 must be justified, not just taken
>> as a given.  When we call n = int(something), what's the use-case for caring
>> that n is an instance of built-in int but not of a subclass, and is that
>> use-case so compelling that it must be enforced for all uses of int() etc.?
> 
> 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.

FWIW unless I missed something it's true for none of bytes, str or
float, though it's true for complex (for some reason):

types = (int, float, complex, bytes, str)
Obj = type('Obj', (), {
'__{0.__name__}__'.format(t): (lambda t: lambda self:
type('my_{0.__name__}'.format(t), (t,), {})())(t)
for t in types
})

obj = Obj()
for t in types:
print("{} = {} ? {}".format(t, type(t(obj)), type(t(obj)) is t))

> python3 test.py
 =  ? False
 =  ? False
 =  ? True
 =  ? False
 =  ? False

bool can not be subclassed so the question doesn't make sense for it

Broadly speaking (complex doesn't fit it), if there's a dedicated dunder
method in the data model, the only check on what it returns is that it's
a subtype of the conversion type. list, tuple and dict use non-dedicated
conversion methods (iteration or a fallback thereof) so they don't have
this occasion and have no choice but to instantiate "themselves"
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Cameron Simpson]

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 yet not act like an int in all ways.

If I go int(x), I personally want a real int out the end of it.
-- 
Cameron Simpson 

Q: What's the difference between a psychotic and a neurotic?
A: A psychotic doesn't believe that 2 + 2 = 4.  A neurotic knows it's true,
   but it bothers him.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Announcement] New mailing list for code quality tools including Flake8, Pyflakes and Pep8

[Alfredo Solano Martínez]

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, Apr 3, 2013 at 4:24 PM, Ian Cordasco  wrote:
> 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
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/asolano%40icai.es
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Terry Jan Reedy]

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.  A non-int could only become an int via __int__,
which int() calls.  What magic is there in int() to turn any arbitrary
object into an integer?


From the 2.7 manual:
"
object.__complex__(self)
object.__int__(self)
object.__long__(self)
object.__float__(self)
Called to implement the built-in functions complex(), int(), long(), and 
float(). Should return a value of the appropriate type."


I have always understood 'value of the appropriate type' to mean just 
what Guido says he intended it to mean. Changing to 'instance of the 
class or subclass thereof' is a change.





___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Steven D'Aprano]

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 an int, be a subclass instance
of an int, and yet not act like an int in all ways.


Python is generally a consenting adults language. If you don't trust the 
subclass to actually behave like an int in ways that matter, why are you using 
it?

Ultimately, something may have monkey-patched builtins int without your 
knowledge, so even calling int() doesn't guarantee anything about the object 
you get back.

Isn't it funny how we have differences in opinion on just when and how we're 
allowed to shoot ourselves in the foot? I personally hate the idea that global 
constants aren't constant, and can be rebound by anything, but others 
apparently don't care. You hate the idea that int() might return an instance of 
a subclass, and I think that's a feature, not a bug.



--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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 C code.

Unless you want to try to use the concrete C-API in CPython.  In my
experience the concrete API is not very subclass friendly.

-eric
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Announcement] New mailing list for code quality tools including Flake8, Pyflakes and Pep8

[Charles-François Natali]

> 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 benefits from Coverity scans (I guess the
Python-security guys receive those notifications). Note that this only
covers the C codebase.

cf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] relative import circular problem

[Eric Snow]

On Mon, Apr 1, 2013 at 4:52 PM, Nick Coghlan  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
> imports usually (although not quite always) indicate a need to factor some
> common code out into a third support module imported by both of the original
> modules. At that point, the code is cleaner and more decoupled, and the
> uneven circular import support ceases to be a problem for that application.

+1

-eric
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nick Coghlan]

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 usable everywhere where ints are,
> > including in C code.
>
> Unless you want to try to use the concrete C-API in CPython.  In my
> experience the concrete API is not very subclass friendly.

Using it with subclasses is an outright bug (except as part of a subclass
implementation).

Cheers,
Nick.

>
> -eric
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Announcement] New mailing list for code quality tools including Flake8, Pyflakes and Pep8

[Olemis Lang]

On 4/3/13, Charles-François Natali  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 analysis on the cpython codebase.
>
> AFAICT CPython already benefits from Coverity scans (I guess the
> Python-security guys receive those notifications). Note that this only
> covers the C codebase.
>

... but the question seems to be « is there anything similar that
could be used for Python code ? »

-- 
Regards,

Olemis.

Apache™ Bloodhound contributor
http://issues.apache.org/bloodhound

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com