Mailing List Archive

On Fri, 20 Aug 1999 00:27:48 -0500, "Gordon McMillan"
<gmcm@hypernet.com> wrote:

>Couple comments -
>
>Tom Christiansen wrote:
>> Yes, slices in python don't include
>> the termination point.
>
>This might be a surprise if you're not used to it, but it turns out
>to be very nice. Basically any way of expressing a range will result
>in something that includes the left hand side, but excludes the right
>hand. So when you're slicing, chopping up, inserting... you (almost)
>never have to use "i-1".

It also means that len(seq[start:end]) == end - start. It is also
convenient when using negative indices.

>> 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.
>
>I'm not sure I've *ever* seen this used in Python. But it hints at a
>very nice piece of syntactic sugaring you can do.

I've seen it used in wrapper classes where the classes' __delattr__
method needs to delete the data object's attribute.

[snip rest]

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

Couple comments -

Tom Christiansen wrote:
> Yes, slices in python don't include
> the termination point.

This might be a surprise if you're not used to it, but it turns out
to be very nice. Basically any way of expressing a range will result
in something that includes the left hand side, but excludes the right
hand. So when you're slicing, chopping up, inserting... you (almost)
never have to use "i-1".

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

I'm not sure I've *ever* seen this used in Python. But it hints at a
very nice piece of syntactic sugaring you can do.

class A:
pass

a = A()
a.name = "Joe"
a.shoesize = 13

All I'm doing is manipulating a dict (a's __dict__), but in a way
that (sometimes) yields much more readable code than:
a = {}
a["name"] = "Joe"
a["shoesize"] = 13


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

Are you referring to "ni"? Again, this is something that has changed.
Although Python packages may well have their own "gotchas" for Perl
folks.

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

It often is, and defaults to repr. But if they are differnt, str
means "as something a user should see" and repr means "as something
a programmer should see" (and, if at all possible, something that
eval will do the inverse of).

> 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;

When you get used to them, you find that you use lists and tuples
completely differently. The first thing you find is that because
tuples are immutable, they can be used as keys in dicts. But
more to the point, lists are used as collections, while tuples are
used as structs or instances of simplistic classes might be. So you
soon think of them as completely different beasts, even if they are
syntactically similar.

> type(obj) ref($obj) returns its string type

Nit: In Python, "type" returns a type object.

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

This is not the normal way to leave a Python program, either. The
normal way is just to fall out. Also note that an import of a
built-in costs (almost) nothing. Namespaces are kept as clean as
possible - maybe because you can clobber any name except a keyword.

> sys.setcheckinterval(reps) n/a. This is some event hook
> processing
> thing.

Actually, it's how may byte code instructions to do in one
"time-slice" if you're using threads.

> string.splitfields(s,sep) @a = split(/sep/, $s) # no import
> If you don't want regex magic chars:
> @a = split(/\Qsep/, $s)

Deprecated. Use the (newer) optional args to split().

> string.joinfields(x, sep) $s = join($sep, @x); # no import

Deprecated. Use optional args to join().

> posix.environ The %ENV hash; no import
> needed in Perl. However, assignment doesn't
> appear to propagate to
> unborn children as it does in Perl.

Use putenv() to do that.


- Gordon

[courtesy cc of this posting mailed to cited author]

In comp.lang.python,
Greg McFarlane <gregm@iname.com> writes:
:I also appreciated your mapping between the two languages. How hard
:would it be to write a reverse mapping? I know very little perl, but
:occasionally need to look at an existing perl script and try to figure
:out what it does. A table that gives the python equivalent of common
:perl expressions could be very useful.

I'm not sure what that would entail. Perhaps the operators from the
perlop manpage, the statement keywords from the perlsyn manpage, the
data types in the perldata manpage, and then all the built-ins from the
perlfunc manpage. Would that suffice?

--tom
--
Bus error - passengers dumped

wtanksle@dolphin.openprojects.net (William Tanksley) writes:

>
> > Note that Python doesn't support hash
> > slices, which in Perl are simple:
> > @hash{k1,k2,k3} = (v1, v2, v3)
>
> That's a good point, although I'm not sure what Python can do about it --
> our slice semantics talk about gaps, and hashes don't have gaps. I
> suspect we'd have to call it something other than slicing (this seems
> pretty reasonable).

You can use `hash.update({k1: v1, k2: v2, k3: v3})', which has the
additional benefit of putting keys and values closely together.

kernr@mail.ncifcrf.gov (Robert Kern) writes:

| On Fri, 20 Aug 1999 00:27:48 -0500, "Gordon McMillan"
| <gmcm@hypernet.com> wrote:
|
| >Couple comments -
| >
| >Tom Christiansen wrote:
| >> Yes, slices in python don't include
| >> the termination point.
| >
| >This might be a surprise if you're not used to it, but it turns out
| >to be very nice. Basically any way of expressing a range will result
| >in something that includes the left hand side, but excludes the right
| >hand. So when you're slicing, chopping up, inserting... you (almost)
| >never have to use "i-1".
|
| It also means that len(seq[start:end]) == end - start. It is also
| convenient when using negative indices.

For the record, this is how slicing-style stuff works in the STL in
C++ as well; foo.begin() and foo.end() give you 'first element' and
'one past the end' iterators, and all the generic functions like
for_each take pairs of iterators with that convention.

--
Dan Schmidt -> dfan@harmonixmusic.com, dfan@alum.mit.edu
Honest Bob & the http://www2.thecia.net/users/dfan/
Factory-to-Dealer Incentives -> http://www2.thecia.net/users/dfan/hbob/
Gamelan Galak Tika -> http://web.mit.edu/galak-tika/www/

Tom Christiansen wrote:
> posix.environ The %ENV hash; no import
> needed in Perl. However, assignment doesn't
> appear to propagate to
> unborn children as it does in Perl.

Gordon McMillan writes:
> Use putenv() to do that.


I think the current recommendation is to use os.environ instead of
posix.environ; there's something about that in the documentation for
posix.environ as well.


-Fred

--
Fred L. Drake, Jr. <fdrake@acm.org>
Corporation for National Research Initiatives

James Logajan writes:
> the STL. For your benefit I've included the Python man page as an
> attachment. I hope this helps clear up any misunderstanding you may have
> about Python documentation.
...
> .TH PYTHON "7 September, 1997"

James,
This is old. I'll be glad to send anyone who asks (nicely, now!) a
current version, or (perhaps better) put it on the Web site if there
are enough requests.


-Fred

--
Fred L. Drake, Jr. <fdrake@acm.org>
Corporation for National Research Initiatives

On Fri, 20 Aug 1999 04:03:30 GMT, wtanksle@dolphin.openprojects.net
(William Tanksley) wrote:

>On 19 Aug 1999 08:21:55 -0700, Tom Christiansen wrote:

[snip]

>>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.
>
>True for 1.4, not true after that.
>
>And "ni!" isn't disgusting -- what's disgusting is what the times have
>come to, that ruffians can walk about saying "ni!" to innocent old ladies.

Besides, it could be much, much worse. It could have been named
EckyEckyEckyEckyPikangZoopBoingGoodemZooOwliZhiv.

:-)

[snip]

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

William Tanksley wrote:
> Python, OTOH, doesn't seem to have a way to set a file's flushing
> properties -- you have to explicitly flush whenever you need it. True?

you can open the file without buffering (pass 0 as
the third argument to open).

this cannot be changed after you've opened the file,
though (python's I/O is based on stdio, and some stdio
implementations crash if you try to change the buffer
size after you've accessed the file).

alternatively, you can wrap the file object in a
small class which explicitly calls flush after each
write.

</F>