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

2013-04-03 Thread 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

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

2013-04-03 Thread 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 usa

Re: [Python-Dev] relative import circular problem

2013-04-03 Thread 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 usuall

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

2013-04-03 Thread 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 b

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

2013-04-03 Thread 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 cod

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

2013-04-03 Thread 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 a

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

2013-04-03 Thread 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.

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

2013-04-03 Thread 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, A

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

2013-04-03 Thread 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

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

2013-04-03 Thread 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

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

2013-04-03 Thread 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/pyth

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

2013-04-03 Thread 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 t

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

2013-04-03 Thread 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() ca

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

2013-04-03 Thread 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

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

2013-04-03 Thread 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 fo

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

2013-04-03 Thread 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. Wh

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

2013-04-03 Thread 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

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

2013-04-03 Thread 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

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

2013-04-03 Thread 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(

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

2013-04-03 Thread 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)

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

2013-04-03 Thread 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(),

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

2013-04-03 Thread 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(i

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

2013-04-03 Thread 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,

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

2013-04-03 Thread 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-subclas

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

2013-04-03 Thread 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

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

2013-04-03 Thread 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 __

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

2013-04-03 Thread 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 operat

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

2013-04-03 Thread 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

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

2013-04-03 Thread 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 g

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

2013-04-03 Thread 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 deprecat

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

2013-04-03 Thread 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 *sh

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

2013-04-03 Thread 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