Python to Perl Conversions

[Robert Kern]

I'll skip parts that have already been addressed (hopefully).

On 19 Aug 1999 08:21:55 -0700, Tom Christiansen <tchrist at mox.perl.com>
wrote:
>Per your collective requests, here is one of the documents
>with my collective observations from learning Python.

Cool.

[snips left unmarked]

>delattr(object,name)            n/a?  "delete named attribute from object".
>                                I suppose this might be
>                                        delete $obj->{name}
>                                but that's pretty uncool to do it without 
>                                asking the object.

BTW, Python does ask the object.  If object is of a builtin type, this
delattr (or "del object.attr" where "attr" is name's value) will call
the C function that the type defines for __delattr__.  If object is an
instance of a class that has a __delattr__ method, then delattr will
be equivalent to object.__delattr__(name).  If object's class doesn't
define __delattr__, then Python will simply delete that attribute.

>eval(code)                      Same as Perl, but Perl's handles
>                                statements, and python's only handles
>                                expressions.  Also, python hurls an
>                                exception if it doesn't like you,
>                                whereas Perl sets $@.  People use this
>                                to convert string to numbers.  This is
>                                a terrible security hazard.

Not used so much for converting strings to numbers since int(x),
float(x), and long(x) were changed to handle strings.  This change
(IIRC) was made from 1.4 -> 1.5, I believe, to solve this very issue.

>exec(code)                      eval(code);  plus see previous entry.

I only say this in case you revise this document for use elsewhere:
The parens are unnecessary.  "exec" is a statement keyword.

>getattr(obj,name)               n/a?  maybe just $obj->{$name}.  I don't
>                                understand why this exits.  Oh heck, yes I
>                                do.  Because you can say
>                                    name = "widget_count"
>                                    obj.name
>                                Because there's no interpolation and
>                                otherwise it will look up name.  Oh my.
>                                This is like the apply() mess.

It's really not so bad.  This actually keeps Python simple and clear.
IMO, it is not desirable for interpolation to exist for the usual
attribute access method "obj.name".  In debugging a complicated class
definition, this unambiguity can be very important.

We could add special punctuation to do this interpolation (which, if I
read you correctly, perl does?), but getattr works just as well
without futzing with the grammar.

Truly, getattr isn't used a whole lot.  I don't think that we'd
benefit from interpolation.

>hash(x)                         huh?  "returns the hash value of the object,
>                                if any"

Most (all?) immutable objects and class instances that define a
__hash__ method can be assigned a hash value with this function.  This
value is the same one that is used internally for dictionaries (IIRC).
This can be useful for some arcane things.

>input(prompt?)                  n/a.  This reads and evals the input
>                                stream!  Needed because otherwise you can't
>                                read a number.  Or you could read the
>                                string and convert it.  Ick.  Security
>                                hazard waiting to happen.

The number issue changed from 1.4 to 1.5, so no-one uses input to take
care of numbers anymore.  The only thing I think it would really be
used for anymore is a quick-and-dirty interpreter shell.

>reload(module)                  First delete from %INC, then require the
>                                module again, as in:
>                                    delete $INC{"Module.pm"}
>                                    require Module;
>                                Note that Python doesn't directly support
>                                nested modules as in
>                                    require Dir1::Dir2::Dir3::Module;
>                                except via a disgustingly named hackaround
>                                module.

Again (whoops, there goes my promise), this changed from 1.4 to 1.5.
You owe us a shrubbery.

>setattr(obj,name,value)         $obj->{$name} = $value;
>                                Interpolation wins again.  See getattr.

Shrug.  Simplicity won in Guido's mind, I guess.

>str(x)                          I thought this was the same as repr().

repr() *should* return a string that can be popped into eval and
recover the original object (well, one that is equivalent in value to
the original).  str() is sometimes used for a prettier version
designed for viewing, not evaluating.

E.g. for Numeric Python arrays
>>> from Numeric import *
>>> a = reshape(arange(16), (4,4))
>>> print repr(a)
array([[ 0,  1,  2,  3],
       [ 4,  5,  6,  7],
       [ 8,  9, 10, 11],
       [12, 13, 14, 15]])
>>> print str(a)
[[ 0  1  2  3]
 [ 4  5  6  7]
 [ 8  9 10 11]
 [12 13 14 15]]

>tuple(seq)                      n/a.  This is a nasty hack to deal with the
>                                fact that (1,2,3) is different from [1,2,3].
>                                Hm... maybe it's like this:
>                                    $aref = [1,2,3]; 
>                                    @list = @$aref;

Not so nasty.  Tuples have properties (like immutability and
hashability) that justify their co-existence with lists.  A function
to convert objects to tuples is desirable, just like int(), float(),
list(), etc. are desirable.

>sys.exit(status)                exit(status) and no import is bloody
>                                necessary just to leave the program.
>                                But that Python does this by raising
>                                a SystemExit exception.  Perl can use
>                                END{} handlers to catch these and do
>                                at-exit processing, and Python doesn't.
>                                You have to roll your own.

Non-issue really.  There aren't many times where sys.exit() is needed.
If the interpreter is run in non-interactive mode, it will exit when
the script is completed successfully or it hits an unhandled
exception.  Exiting the interpeter from interactive mode is done by
the user with Ctrl-D on UNIX and CTRL-Z on Windows.  

Unless you really need to set the exit status, explicitly calling
sys.exit or raising SystemExit isn't usually beneficial.  The default
behaviour is sufficient for most contexts, especially debugging in
interactive mode.  Instead of exiting when it hits an unhandled
exception in interactive mode, the interpreter gives you the prompt.
>From there, you can sometimes diagnose the problem.

>sys.exitfunc                    This is one function to call on normal exit
>                                (not exception exits, unlike perl).
>                                It would have to manage all the handlers
>                                in your roll-your-own scheme.  Very ugly.

Not much of an issue, really.

>        +-------------------------------------------------------------+
>        | POSIX library.  These aren't there unless you have imported |
>        | the library module via "import posix".                      |
>        +-------------------------------------------------------------+

Generally, you should use the os module which loads the right
OS-dependent module for your environment.

Thanks for listening.

>-- 
>If you consistently take an antagonistic approach, however, people are
>going to start thinking you're from New York.   :-)
>        --Larry Wall to Dan Bernstein in <10187 at jpl-devvax.JPL.NASA.GOV>

Robert Kern           |
----------------------|"In the fields of Hell where the grass grows high
This space            | Are the graves of dreams allowed to die."
intentionally         |           - Richard Harter
left blank.           |