Home Original page

Perl is worse!

David Bolen db3l at fitlinxx.com
Fri Jul 28 20:49:20 EDT 2000 
grey at despair.rpglink.com (Steve Lamb) writes:

> On 28 Jul 2000 15:37:05 -0400, David Bolen <db3l at fitlinxx.com> wrote:
> >In the case here it seems as if you don't really want to define the
> >name and associate it with nothing, you want to define the name and
> >associate it with an object that will support being appended to.  In
> 
>     Will this work if the decision is to make it a string, not a list?

If your requirement is to have your label reference an object that
supports an ".append" (in-place appending) method then no, as Python
strings do not support that method (strings are immutable, although a
new string may be formed by concatenating two strings).

But that's actually quite consistent in terms of design, because the
root question still remains identifying the appropriate objects to be
working with.  In effect, a Python "string" object does not fit your
"interface" requirements.  In this case your interface requirements
appear to be sequence based, since you want a mutable sequence that
you can append to (in Python, a "list").  Note of course, that you
could certainly use strings in this sequence, and at any point produce
a single string representing all of the entries from the list.

I think in this respect you'll find Python much more object oriented
than Perl, at sort of a basic level.  I think this also ties into the
other discussion in this thread of Perl having operators that control
the type interpretation, whereas Python strongly types the objects
themselves.

In the example in this mini-thread, I think a perspective shift
between a Perl approach and a Python approach is indicated in how you
tried to form the example.   You first considered obtaining some
storage and then manipulating/converting that storage into what you
wanted via operations.  But in Python, it's the type of object that
you use that controls what you can do with it (its interface) and not
the other way around, so development becomes more focused (and more
clean, IMO) on building an object model of what you are doing.  There
are, of course, ways to create a new object out of data from another
object (e.g., produce a list representing the individual sequence of
characters in a string), but that yields a new object with a new
interface and doesn't actually do any "conversion" on the old object.

I realize it was probably just to highlight a specific issue, but even
choosing such an example is interesting, since arbitrary object
conversions (e.g., something to a list) don't tend to happen with high
frequency in Python programs, since it was the object model and data
types that were most likely involved in the design.

It's really easy to gloss over this with the basic object types since
in many respects they behave much as other languages in common sorts
of operations, but it can lead to confusion when the simpler view
starts to break down.  I don't know that this explains all that much
discussed in this thread, but there have been various points where I
think it's just an issue of the Perl and Python approaches being quite
different under the covers even though they may appear very close
superficially.  Getting past that mental hurdle (as far as
understanding, not putting any good/bad slant on it) might
significantly shrink your current store of Python behaviors you
consider "quirks".

> >(Oh, and as an aside - this is an impressive thread - even with the
> >few warts, I think there's useful information going on)
> 
>     Agreed.  I know I'm prolly coming off as a newbie troll but I am learning
> things and I really do mean it when I say I don't want to see the language
> changed, just expressing an opinion.

Well, besides being impressed that you're keeping it up this long, and
without trying to sound condescending, I'm enjoying seeing how your
examples are exposing what learned traits/visualizations from using
Perl so much.  I hope that you still give Python some time and
experimentation, as you may find yourself forming new opinions :-)

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/
More information about the Python-list mailing list