Octal notation: severe deprecation

Reinhold Birkenfeld reinhold-birkenfeld-nospam at wolke7.net
Fri Jan 14 14:10:30 EST 2005


Simon Brunning wrote:
> On Thu, 13 Jan 2005 16:50:56 -0500, Leif K-Brooks <eurleif at ecritters.biz> wrote:
>> Tim Roberts wrote:
>> > Stephen Thorne <stephen.thorne at gmail.com> wrote:
>> >
>> >>I would actually like to see pychecker pick up conceptual errors like this:
>> >>
>> >>import datetime
>> >>datetime.datetime(2005, 04,04)
>> >
>> >
>> > Why is that a conceptual error?  Syntactically, this could be a valid call
>> > to a function.  Even if you have parsed and executed datetime, so that you
>> > know datetime.datetime is a class, it's quite possible that the creation
>> > and destruction of an object might have useful side effects.
>> 
>> I'm guessing that Stephen is saying that PyChecker should have special
>> knowledge of the datetime module and of the fact that dates are often
>> specified with a leading zero, and therefor complain that they shouldn't
>> be used that way in Python source code.
> 
> It would be useful if PyChecker warned you when you specify an octal
> literal and where the value would differ from what you might expect if
> you didn't realise that you were specifying an octal literal.
> 
> x = 04 # This doesn't need a warning: 04 == 4
> #x = 09 # This doesn't need a warning: it will fail to compile
> x= 012 # This *does* need a warning: 012 == 10

Well, this would generate warnings for all octal literals except
01, 02, 03, 04, 05, 06 and 07.

However, I would vote +1 for adding such an option to PyChecker. For
code that explicitly uses octals, it can be turned off and it is _very_
confusing to newbies...

Reinhold



More information about the Python-list mailing list