More random python observations from a perl programmer

Michael Hudson mwh21 at cam.ac.uk
Thu Aug 19 18:31:08 EDT 1999


I sooo want to keep out of this; just a couple of points.

Tom Christiansen <tchrist at mox.perl.com> writes:
> :> GOTCHA: (medium)
> :>     Perl's hex() function is the opposite of Python's.  Perl's hex
> :>     function converts 22 into 37.  Python's hex function converts 37 into
> :>     0x22.  Oh my!  Like hex, Python has oct() completely backwards from
> :>     Perl.  Python's oct(44) returns 054, but Perl's oct(44) return 36.
> :
> :This would have to do with strings not being automatically coerced
> :into numbers, methinks.
> 
> No, that's not it.  Perl's hex takes a hex number and returns 
> a decimal one; same with oct.  Python's is the reverse.  Very weird.
> 
>     echo 'print oct(12)' | python
>     14
> 
>     echo 'print oct(12)' | perl -l
>     10
> 
> See what I mean?

Well, in Python an integer's an integer. It has no property of being
hex or decimal or octal. So by the time the hex/oct function sees it,
it's just an integer irrespective of the way it was typed.

It would seem to me that perl's

oct(12)

is like Python's 

012

A difference.

> :There's info format if you look for it and you have to have a CLI.
> 
> At the very least, python needs a top-level python(1) manpage that gives
> calling conventions, options, envariables etc, and an explanation of how
> to locate the rest of the documentation (even if it's in non-man form).
> That's a POSIX.2 requirement.

On this subject I'll just say: If people before you had cared as much
about the existence of a python(1) manpage, it would have one.

> :> GOTCHA: (low)
> :>     Often Python's error messages leave something to be desired.
> :>     I don't know whether 
> :
> :Is this a joke? This is improving.
> 
> No, it isn't a joke.

I was referring to the unfinished "I don't know whether" line.

[explanantion of slicing dicts elided]

Oh, I see.

> :new = old.copy()
> 
> I wonder how many times I'll have to explain that I read the 
> Lutz book, wasn't on the Internet at the time, and found no manpages
> installed with python on my laptop.

Ah, have you discovered rlcompleter yet? Put this in your ~/.pythonrc:

import rlcompleter
readline.parse_and_bind('tab: complete')

set PYTHONSTARTUP=~/.pythonrc and then in python type:

d={}
d.

and whack tab a couple of times. This should definitely be better
advertised; I use it all the time.

> :Yes this is a bit annoying. The Right Way to attach state to a
> :function is a class, of course. Not that that helps much.
> 
> That sounds like religion.

I suppose, but not Python's particularly.

>  And aren't bound methods inherent
> memory leaks?
> 
>     fn = obj.method;

No.
 
> :> GOTCHA: (low)
> :>     Python's eval() only works on expressions, not full code blocks full
> :>     of statements.  You need exec() for the whole thing.
> :
> :Writing exec() suggests it's a function; it isn't, it's a statement.
> 
> Funny that you guys are all flustered about this statement/function thing.
> I think of if and def as statements.  I'm not saying print and exec
> aren't, but they sure look just like it.

I was just being accurate.

Cheers,
Michael




More information about the Python-list mailing list