A really bad idea.
M
I use Python in several projects. One of the main benefits of doing
so is that my programmers can quickly learn Python and get productive.
Python is a great language to read. Very seldom does one of my programmers
missunderstand code somebody else have written. This is one, if not the most,
important aspect of a great language. Most of the time are spent in reading
code while adding a new module (to see where it should fit) or fixing
bugs. And by definition, for a non-trivial application, this is code that
somebody else wrote.
The ability to produce readable code is one of the best things with Python.
Python more or less forces you to write nice code. This is a good thing. Not
an issue when you are a single programmer on a project. But when you have a
bunch of programmers with different skills this is great.
But I see a disturbing trend.
Just a few examples...
The new enumerate or zip function. If you look at the code using this function
it is not at all obvious what the code does. Let say a programmer that knows
10 other languages looks at this code. I don't think he would right away
understand what this function does. This construct is not obvious. Generators
are another thing that are just horrible. They just don't work in a way
that one would expect from previous experience.
I understand that one will like to add features to a language in order to
make it more powerfull. But I argue that this must be done in a way so that
programmers of *different skill levels* will understand the code. C++ is one
horrible example of a very powerfull language that very few people actually
understands fully. It takes years to fully understand C++, where does this
leave time to think about architecture and algorithms?
And no, you can't just say that these constructs should never be used. It
won't work! Every language feature will eventually be used by somebody.
Just look at the C++ world. Full of guidelines how to avoid doing things
that nobody will understand anyway. And full of code that breaks these
guidelines.
I hope this is not a start of adding powerfull and hard to understand
features to Python.
Cheers
/Marv
Achim Domma
news:c0abefc3.02111...@posting.google.com...
> Just a few examples...
> The new enumerate or zip function. If you look at the code using this
function
> it is not at all obvious what the code does. Let say a programmer that
knows
> 10 other languages looks at this code. I don't think he would right away
> understand what this function does. This construct is not obvious.
Generators
> are another thing that are just horrible. They just don't work in a way
> that one would expect from previous experience.
> I hope this is not a start of adding powerfull and hard to understand
> features to Python.
As mentioned in other threads one should learn python if one would like to
develop in python. I think you should make a difference between features
which are hard to understand and features which are usually not found in
other languages. In my opinion enumerate, zip and generators are not hard to
understand, but they might be uncommon. But they give you the power to
express concepts in their natural way. Another example is list
comprehension: If you are used to it, they are nearly plain english, but I
know people who prefer writing loops over multiple lines, only because they
are used to do it this way and don't want to learn something new.
regards,
Achim
djw
If Python was the same as all other languages (thus making it easy for a
programmer to easily understand it), it would be like all other
languages (that is to say, not very useful). What makes it special is
that it has powerful constructs that other languages lack. When I first
looked at Python code, I didn't have a clue that {}'s meant a dictionary
and that [::] was a slice operator. After learning these, they become
natural. What I worry about is not things that seem wierd at first, but
things that continue to feel wierd over time and force me to grab the
documentation every time I try to use it (example, the dictionary
setdefault() method. I have to look that sucker up every time. Also,
"".join() always seems wierd.) Stuff like generators, list
comprehensions, etc... languages like C++ don't have these things, why
would you expect a C++ programmer to get them? As long as _Python_
programmers find it natural, why should we care if C++ programmers
don't? 8^)
Just my $0.02,
/d/
Alex Martelli
...
> But I see a disturbing trend.
"trend"?
> The new enumerate or zip function. If you look at the code using this
"new"? _zip_...? It was introduced in Python 2.0...
> function it is not at all obvious what the code does. Let say a programmer
Are you claiming the pre-2.0 code (without zip) doing the rough equivalent
of today's e.g.
x = zip(onething, another)
namely
x = map(None, onething, another)
WAS more obvious...?! I don't see how you can claim a TREND unless you
ARE claiming that "map(None, ..." was indeed "obvious" in a way that
zip isn't. And that is so totally and utterly absurd a claim that I
wouldn't know what to make of it.
Python has a few dozen built-in functions. I wouldn't _expect_ MOST of
them to be "immediately obvious" to somebody who has not even bothered
glancing at the docs, or trying e.g help(zip) at the prompt in an
interactive session. And I don't see any "trend" in that, since e.g.
the time of Python 1.5.2, which is where I came in.
> I hope this is not a start of adding powerfull and hard to understand
> features to Python.
I dispute that "not immediately obvious unless one bothers to read
the docs or try calling help" is equivalent to "hard to understand".
In any case, you cannot possibly be seeing "the start" of adding a
few powerful built-in functions to Python, since most of them were
already in 1.5.2 -- thus, "the start" must have been much older.
Alex
Manuel M. Garcia
(edit)
>The new enumerate or zip function. If you look at the code using this function
>it is not at all obvious what the code does.
Actually, a lot of the things that seem strange to you come directly
from the functional programming world. I have a functional
programming background coming from LISP and Mathematica, so I was
happy to see 'reduce' and 'zip' as built in functions and I use them
often.
Python contains very few "innovations", most everything is borrowed
from other languages. Some of these languages are obscure when
compared to Java or C++, like Haskell, the language that Python
borrowed list comprehensions from. I believe the only places where
Python really "innovated" was with indentation for defining blocks and
namespaces. My point being that anything that seems strange in Python
would probably be second nature to another programmer who comes from a
different background.
Be that as it may, from my experience, programmers from any background
can write non-trivial programs in Python during their first days
learning the language. I believe no other language comes close.
Manuel
Manuel M. Garcia
wrote:
(edit)
>Python has a few dozen built-in functions. I wouldn't _expect_ MOST of
>them to be "immediately obvious" to somebody who has not even bothered
>glancing at the docs, or trying e.g help(zip) at the prompt in an
>interactive session.
A good point. Python is pretty darn small. O'Reilly's Python Pocket
Reference for Python 2 is 124 pages, and only because the major
modules are referenced starting at page 65. And the language is
pretty well covered in those 64 pages, it is rare I need any
documentation beyond the Pocket Reference, even when doing thing that
would be considered tricky in other languages, like handling attribute
access on an object programmatically.
Manuel
Mel Wilson
marv...@hotmail.com (M) wrote:
>The new enumerate or zip function. If you look at the code using this function
>it is not at all obvious what the code does. Let say a programmer that knows
>10 other languages looks at this code. I don't think he would right away
>understand what this function does. This construct is not obvious. Generators
>are another thing that are just horrible. They just don't work in a way
>that one would expect from previous experience.
If you were to think database tables, imagine you had a
list of part numbers, a list of part descriptions, a list of
prices, etc. all corresponding.
`zip` could put these into a list of tuples, each one a
row containing a corresonding part number, part description
and price.
Quite simple, really.
>I understand that one will like to add features to a language in order to
>make it more powerfull. But I argue that this must be done in a way so that
>programmers of *different skill levels* will understand the code.
Different, yes, but not all. Most of us here are
who/what we are because at various times in our lives we
decided we had to become more skillful.
Regards. Mel.
Russell E. Owen
>The new enumerate or zip function. If you look at the code using this function
>it is not at all obvious what the code does...Generators
>are another thing that are just horrible. They just don't work in a way
>that one would expect from previous experience.
I agree with some of this and am always glad to see discussions like
this. I hope you don't get too many dismissive replies -- they often
seem to surface when one discusses warts.
I think generators were done rather poorly in that there is no special
statement to indicate a generator (something many of us lobbied for at
the time). As a result you have to look through the code to see whether
it's a function or a generator, looking for that magic "yield" statement
-- which can be quite buried, especially in a long function (or is that
a generator? damn!).
As a concept, I feel generators and iterators are well worth learning
and using. I make pretty heavy use of them and am glad to be saving
myself the code I'd otherwise have to write. On the other hand:
- There is some area of all this I still find confusing. it's hard to
put my finger on, but I'm not always sure whether I should be obtaining
an iterator and then using it in a for loop or defining __iter__ (or is
it iter?) and using my object directly in a for loop. Also, I'm not
always sure about iterators or generators that call iterators or
generators.
- Iterators have some nasty pitfalls. For instance on a file you cannot
reliably do this:
# read some data
for line in file:
# process the data, break partway through
# read more data:
for line in file: (or maybe that works but file.readline() will not)
You will often lose data--the first "for" loop reads ahead for
efficiency and the later read misses all that data.
Map, reduce and their ilk are quite specialized. I usually (but not
always) find that using them makes my code harder to understand,
probably due to the need to pass in a function. I suspect a big reason
they're in the language is they're so much faster than doing the same
jobs with other constructs.
On the other hand, I like zip just fine (though I lament the lack of an
unzip counterpart). I find it simple and straightforward, though it's
not something I use every day.
Another wart, in my mind, is that map and zip (which are closely
related) handle a set of lists of nonequal lengths in different ways.
I'd much rather have seen consistency between them, and preferably a way
to specify a modifier to get the other behavior (for lists of unequal
lengths). The lack of consistency is all the more surprising to me
because zip was introduced fairly recently, long after map was well
established.
How do you feel about list comprehensions? To me they look a bit like
line noise, but I love them and use them heavily. them. I find myself
wshing there was a similar construct for creating dictionaries.
-- Russell
James J. Besemer
Manuel M. Garcia wrote:
> A good point. Python is pretty darn small.
I disagree.
> O'Reilly's Python Pocket
> Reference for Python 2 is 124 pages, and only because the major
> modules are referenced starting at page 65.
I collect pocket reference guides, and FWIW, Python's is the largest!
Perl 5 (including libraries) is only 48 pages.
I have C/C++ pocket refs that work out to 8 pages for the language and 8
pages for the libraries.
Python includes virtually all of the features commonly available to most
languages plus a bunch of extra features that appear only in non mainstream
languages or that are entirely unique to Python. Tuples, Longs, Imaginary
numbers, list comprehensions, while/else, for/else, generators, are examples
of Python features that are not commonly available in other languages. The
list grows considerably if we include features common to Perl (e.g., lists,
dictionaries, slices, strings) but which are otherwise missing from most
mainstream languages. I suppose the one thing Python (Perl and others) leave
out are variable and type declarations, which goes to making the language
seem smaller than others.
I don't raise this point to complain or suggest Python is bad. I actually
think it's a tribute to Python's superior design that so MUCH functionality
is contained in a manageable tool. Python is so well designed that it SEEMS
small even though it's comparable to the most elaborate programming systems
ever made.
Disagreeing with the OP, I rather think Python tends to go overboard the
other way in deference to newbies and naive programmers. This is why Python
consciously rejects assignment within an expression, ++ and --, ?:, var
parameters and goto, even though most experienced programmers already know
how these constructs work. It's ostensibly the reason why integer division
was redefined to produce a real result -- because naive users might be
"confused" by a truncated integer result. I think the designers are overly
pedantic on this point overall and thus sometimes make the wrong call. In
any case, it's certainly not fair to suggest that Python errs in adding "hard
to understand" features.
Some learning curve is inevitable even in the most readable language.
Regards
--jb
--
James J. Besemer 503-280-0838 voice
2727 NE Skidmore St. 503-280-0375 fax
Portland, Oregon 97211-6557 mailto:j...@cascade-sys.com
http://cascade-sys.com
Erik Max Francis
> I collect pocket reference guides, and FWIW, Python's is the largest!
>
> Perl 5 (including libraries) is only 48 pages.
>
> I have C/C++ pocket refs that work out to 8 pages for the language and
> 8
> pages for the libraries.
I think what's making the difference here is the quality/depth of the
reference guides, not the actual languages. A "C/C++" reference that is
a total of 16 pages simply not comparable to a Python reference that is
124 pages. C and C++ (two different languages, by the way) are not
about 8 times simpler than Python. Far from it, in fact.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Punctuality is the virtue of the bored.
\__/ Evelyn Waugh
WebVal / http://www.alcyone.com/pyos/webval/
URL scanner, maintainer, and validator in Python.
Gonçalo Rodrigues
<ow...@nospam.invalid> wrote:
>In article <c0abefc3.02111...@posting.google.com>,
> marv...@hotmail.com (M) wrote:
>
[text snipped]
>
>As a concept, I feel generators and iterators are well worth learning
>and using. I make pretty heavy use of them and am glad to be saving
>myself the code I'd otherwise have to write. On the other hand:
>- There is some area of all this I still find confusing. it's hard to
>put my finger on, but I'm not always sure whether I should be obtaining
>an iterator and then using it in a for loop or defining __iter__ (or is
>it iter?) and using my object directly in a for loop. Also, I'm not
>always sure about iterators or generators that call iterators or
>generators.
Let me try and shoot at the fog and see if I can clear it up. First a
definition: An object <whatever> is iterable (or is an iterable) if
iter(<whatever>)
returns *something* (and does not raise an exception). Iterables or nice
because they allow for loops, e.g.
for elem in <iterable>:
<whatever>
Examples: list, tuple, file, etc.
>>> print iter([])
<iterator object at 0x01126098>
>>>
Now iter() is a builtin function and when called on an iterable it
returns an *iterator* which may or may not be the same thing as the
iterable itself.
>>> a = []
>>> print id(a), id(iter(a))
17990976 17999536
As you can see the list iterable is different from the iterator itself.
I think (but I am not sure) that files are scheduled in 2.3 to become
their own iterators. Anyway, what the iterator object is supposed to
encapsulate is the traversal through the elements of the iterable. It
does this by having a method, next(), that gives the next element
(whatever that may be) or raises an exception if there is nothing left
to spew.
When Python encounters a
for elem in <iterable>:
<whatever>
it basically is the same: get the iterator of iterable and sucessively
bind elem to whatever the iterator's next method returns until a
StopIteration exception is raised.
Note also that an iterator is also an iterable. But the iterator of an
iterator is the iterator itself (usually - I suppose there is some more
exotic code out there where this rule is broken).
>>> b = iter(a)
>>> print b
<iterator object at 0x01129C68>
>>> print b is iter(b)
1
If you want to code your own iterable just define __iter__. If it is an
iterator make __iter__ return self (unless you know what you are doing)
and provide a next method.
Now for generators. Generators are a cross-breeding between a function
and an iterable. It is better an example first:
>>> def test(n = 0):
... start = n
... while True:
... yield start
... start += 1
...
>>> print test
<function test at 0x01144A88>
As you can see test *is* a function. When called for the first time it
gives
>>> a = test()
>>> print a
<generator object at 0x01148DA0>
A generator. Now a generator *is* an iterator. To see that:
>>> a.next
<method-wrapper object at 0x010D0FD0>
>>> print id(a), id(iter(a))
18124192 18124192
But it is a special kind of iterator. It remembers all the state about
the "function". Let us go back to our little example to see how it
works.
When you first call a.next() (either explicitely or implicitely in a for
loop) it executes the code in test until the first yield. When it gets
there it "returns" whatever expression is in front of the yield but
instead of discarding the function it "suspends" it. This means two
things (at least): The state of all the local variables is kept **and**
the place where you yielded is also kept. On the next next() call you
execute the body of test with your local variables in the state they
were in *and* right from the place where you last yielded: In our case
you start with
start += 1
which bumps start to 1.
And that is basically all there is to it.
>
>-- Russell
All the best,
G. Rodrigues
P.S: Gonna go back to 'Finnegans Wake' to see if I can improve my
english style. Ach, it sucks bad!
Simon Wittber (Maptek)
>reference guides, not the actual languages. A "C/C++" reference that
>is a total of 16 pages simply not comparable to a Python reference that
>is 124 pages. C and C++ (two different languages, by the way) are not
>about 8 times simpler than Python.
> Far from it, in fact.
I disagree. C is a very simple language. Because of its simplicity, one
needs to write lots of C code to achieve complicated things. Python on
the other hand achieves complicated things using minimal code (Imagine
having to code a list slice in C). I doubt that the C / C++ reference
includes examples on slicing lists and using dictionaries, whereas the
Python reference would *have* to, as these constructs are integral to
the language.
What was I saying again? I don't know, its too early on the
morning....
simonw.
Andrew Koenig
Simon> lists and using dictionaries, whereas the Python reference
Simon> would *have* to, as these constructs are integral to the
Simon> language.
You might be surprised what you would find in the C++ standard library...
--
Andrew Koenig, a...@research.att.com, http://www.research.att.com/info/ark
Erik Max Francis
> I disagree. C is a very simple language. Because of its simplicity,
> one
> needs to write lots of C code to achieve complicated things. Python on
> the other hand achieves complicated things using minimal code (Imagine
> having to code a list slice in C).
The C language itself is a fairly straightforward language, but
summarizing that in eight pages does not do it much justice. The
library is fairly large, however, and certainly deserves more than eight
pages.
C++, on the other hand, is quite a complicated language, and it has
downright huge library. As a simple comparison, consider the C99
Standard has 516 pages, the first 163 of which describe the core
language (although the appendices cover a combination of the language
and the library); the C++97 standard has 715 pages, with the core
language description ending on page 310. Oh, by the way, C++ contains
the entire C Standard Library within it, as well.
Condensing all that to 16 pages is, well, not going to do it much
justice. I have serious doubts about the utility of a reference
claiming
> I doubt that the C / C++ reference
> includes examples on slicing lists and using dictionaries, whereas the
> Python reference would *have* to, as these constructs are integral to
> the language.
You keep glossing over the difference between C and C++, but they are
not the same thing, and in this instance the difference in complexity
and library size is essential. I'm guessing you're not familiar with
the Standard C++ Library, which has the equivalent of all these things
and more.
Whether or not you think C and/or C++ is more or less complicated than
Python is really beside the point I was making, and that is simply this:
Comparing a Python reference of 120 or so pages to a "C/C++" reference
of 16 pages is comparing apples and oranges, and says absolutely nothing
about the relative size or complexity of any of these languages.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ The basis of optimism is sheer terror.
\__/ Oscar Wilde
CAGE / http://www.alcyone.com/pyos/cage/
A cellular automaton simulation system in Python.
Simon Wittber (Maptek)
Simon> lists and using dictionaries, whereas the Python reference would
Simon> *have* to, as these constructs are integral to the language.
>You might be surprised what you would find in the C++ standard
library...
Yeah there's plenty of nice things in the STL, but it's a library, not
part of the language.
James J. Besemer
Erik Max Francis wrote:
>
> I think what's making the difference here is the quality/depth of the
> reference guides, not the actual languages. A "C/C++" reference that is
> a total of 16 pages simply not comparable to a Python reference that is
> 124 pages. C and C++ (two different languages, by the way) are not
> about 8 times simpler than Python. Far from it, in fact.
I don't disagree with anything you say. A fairer comparison might be the 1.5
Python pocket ref and the one for Perl 5. There it's 74 vs. 48 pages. The
Python ref is newer, a LITTLE bit more verbose and arguably covers a LITTLE
more library code (though that's unfair to Perl, which includes a lot of what
should be library functions in the base language). If you actually look
through the two booklets, it is evident that it is not an entirely unfair
comparison on a gross level. I view it as circumstantial evidence that
Python and Perl5 are comparable in power and capability (though Python is
much more easy to learn and understand).
In any case, I agree Pocket reference guides are at best a poor metric for
comparing language complexity. I only mentioned the others because Mr.
Garcia cited it as evidence that Python is "small" and I offered what were
intended to be seen as counter examples.
My main point was to disagree with the notion that Python itself is "small".
I think the deceptive thing is that Python omits the declarative syntax which
is standard with static typed languages. Take away the declarative syntax
from C++ and compare what's left to what you can do in Python and in Python
there's a lot more meat to choose from. Yeah, C++ gives you arrays, 14
flavors of fixed sized integers and 3 or 4 flavors of reals, but BFD. It
doesn't have true Longs, complex, lists, dictionaries or even a good string
type to speak of, at least not as first-class objects. Each language has
roughly the same number of operators, although each has some not available in
the other. The control structures in Python are generally more powerful than
C++s. The several omissions from C++ (switch, goto, pointer/reference types,
expression assignment and ++/--) were all intentional and arguably make the
language better, not substantially smaller.
Bring back all the declarative syntax and semantics and, yes, C++ is more
complicated. BUt take it all back out and I submit that Python has more
features -- more tools to apply to your problem. Fred Brooks talks about
'essential' and 'accidental' problems in programming. The essential ones
pertain to the key decisions you make about your algorithms, problem solving
that has a direct bearing on the solution to your application. The
accidental problems are the attendant complexities you have to deal with in
your programming environment in order to implement your solution; they
unrelated to the solution itself. I submit that Python's strength is that a
much greater portion (most?) of it's features go directly to the "essence" of
programming, while other languages contribute less (possess fewer 'essential'
features) and actually add to the problem.
Chad Netzer
> On Thu, 14 Nov 2002 15:33:33 -0800, Russell E Owen wrote:
> > On the other hand, I like zip just fine (though I lament the lack of an
> > unzip counterpart).
>
Hmmm...
Python 2.2.2 (#4, Oct 15 2002, 04:21:28)
>>> a = [1,2,3]
>>> b = ['a','b', 'c']
>>> zip(a,b)
[(1, 'a'), (2, 'b'), (3, 'c')]
>>> zip(zip(a,b))
[((1, 'a'),), ((2, 'b'),), ((3, 'c'),)]
>>> c,d = zip(zip(a,b))
Traceback (most recent call last):
File "<stdin>", line 1, in ?
ValueError: unpack list of wrong size
So, not quite.
But, after some thought, I see that you mean this (which is cool):
>>> c,d = zip(*zip(a,b))
>>> c
(1, 2, 3)
>>> d
('a', 'b', 'c')
ie. it's its own inverse, if you consider some extra syntax (and getting
tuples, not lists).
--
Bay Area Python Interest Group - http://www.baypiggies.net/
Chad Netzer
cne...@mail.arc.nasa.gov
James J. Besemer
Erik Max Francis wrote:
> Condensing all that to 16 pages is, well, not going to do it much
> justice.
Doing "justice" to the language is not the objective. Providing a "crib
sheet" for earstwhile experts is the primary purpose.
Keep in mind these are "pocket reference CARDs". Once upon a time, these
tools were pretty ubiqutious. They often were not booklets, but simply a
cardboard sheet that folds acordian-style to pocket size. "Pages" were 3.5 x
8 in.
The intended audience is people who already know the domain but occasionally
need to double-check some detail, not necessarily newbies just starting out.
E.g., IIRC, It gave the syntax for all the control structs in less than 1
page -- what is there to say about them really? One page for operator
precedence. It gave name and arg signature for stdio functions but not any
lengthy description. Partial page to outline template syntax. Etc.
I can't find the original ones for C/C++ and Standard libraries. However, I
have an analogous "pocket reference" for the PowerPC -- 8 pages for the
entire architecture and instruction set. Of course, it assumes you already
know the meaning of IBAT, DBAT, STWU, STWX, etc.
The current Python "pocket" ref is much more verbose than this standard.
> I have serious doubts about the utility of a reference claiming
Claiming?
I dunno. During most of the 90s I always kept a set in my briefcase and
found them helpful from time to time.
Erik Max Francis
> Doing "justice" to the language is not the objective. Providing a
> "crib
> sheet" for earstwhile experts is the primary purpose.
The only reason I responded was to point out that the size of random
pocket reference guides are not particularly good indications of whether
or not Python is "pretty darn small" compared to other languages.
If your "C/C++" (again, as if that were one language) guide is 16 pages
and the Python one being discussed is 120, it's pretty clear that the
level of detail is simply not comparable.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Does the true light / Of love come in flashes
\__/ Sandra St. Victor
EmPy / http://www.alcyone.com/pyos/empy/
A system for embedding arbitrary Python in template text as markup.
Carl Banks
> On Thu, 14 Nov 2002 15:33:33 -0800, Russell E Owen wrote:
>
>> unzip counterpart).
>
Sure?
>>> a = [(1,2,3,4),(5,6,7,8)]
>>> zip(zip(a))
[(((1, 2, 3, 4),),), (((5, 6, 7, 8),),)]
--
CARL BANKS
Michael Hudson
> Simon> I doubt that the C / C++ reference includes examples on slicing
> Simon> lists and using dictionaries, whereas the Python reference
> Simon> would *have* to, as these constructs are integral to the
> Simon> language.
>
> You might be surprised what you would find in the C++ standard library...
This is the hoary old language/library thing isn't it? Not that C++
gets to be called "simple" or "small" on either count.
C without it's library would get a rating of "useless"... guess this
is true for most languages, but C more than most.
Cheers,
M.
--
languages shape the way we think, or don't.
-- Erik Naggum, comp.lang.lisp
Skip Montanaro
>>> On the other hand, I like zip just fine (though I lament the lack of an
>>> unzip counterpart).
>>
>> Eh? Zip is its own inverse!
Carl> Sure?
Was he perhaps referring to zip the command, and not zip the builtin
function?
--
Skip Montanaro - sk...@pobox.com
http://www.mojam.com/
http://www.musi-cal.com/
Thomas Heller
> C without it's library would get a rating of "useless"... guess this
> is true for most languages, but C more than most.
>
Not at all, imo. You just have to write the library yourself,
and you *can* do it in C.
Thomas
Michael Hudson
I guess... but not portably, surely?
Anyway, it meant to be a serious comment, just the observation that C
puts very little into the language and (relatively speaking) more in
the stdlib.
Cheers,
M.
--
... when all the programmes on all the channels actually were made
by actors with cleft pallettes speaking lines by dyslexic writers
filmed by blind cameramen instead of merely seeming like that, it
somehow made the whole thing more worthwhile. -- HHGTG, Episode 11
Andrew Koenig
Simon> library...
Simon> Yeah there's plenty of nice things in the STL, but it's a
Simon> library, not part of the language.
The distinction isn't particularly important. As with C, every
conforming implementation is required to implement the library, it is
impossible to write a useful, standard-conforming program without
using the library.
Thomas Heller
> Thomas Heller <the...@python.net> writes:
>
> > Michael Hudson <m...@python.net> writes:
> >
> > > C without it's library would get a rating of "useless"... guess this
> > > is true for most languages, but C more than most.
> > >
> > Not at all, imo. You just have to write the library yourself,
> > and you *can* do it in C.
>
> I guess... but not portably, surely?
Ok, you need a core library of system calls, but then you go. As
opposed to Pascal, for example, which I was using when I discovered
C. Mainly, because 'write' is a statement (or special syntax), and cannot
be written in Pascal itself.
> Anyway, it meant to be a serious comment,
I didn't doubt that
> just the observation that C
> puts very little into the language and (relatively speaking) more in
> the stdlib.
And this is IMO what they did right.
Thomas
François Pinard
> Sure?
Paul was surely teasing you, at least a tiny bit. A few stars are needed:
>>> a = [(1, 2, 3, 4), (5, 6, 7, 8)]
>>> zip(*zip(*a))
[(1, 2, 3, 4), (5, 6, 7, 8)]
--
François Pinard http://www.iro.umontreal.ca/~pinard
François Pinard
> "Simon Wittber (Maptek)" wrote:
> > I disagree. C is a very simple language.
> The C language itself is a fairly straightforward language, but
> summarizing that in eight pages does not do it much justice. [...]
> Comparing a Python reference of 120 or so pages to a "C/C++" reference
> of 16 pages is comparing apples and oranges, and says absolutely nothing
> about the relative size or complexity of any of these languages.
I might not be fully singing with the choir here, but I do not find that
C is a simple language. It has fairly intricate points here and there,
and I guess there are very, very few people in this crowd, and in many
other crowds as well, truly able to reply correctly to any question about
C, the language, not even considering its libraries.
C++ as a language is a slightly more regular than C, so it might be
slightly easier in that respect, but it is also much more complex, so
all summed, C++ is undoubtedly a difficult language.
No doubt to me that Python is an easier language, one can learn most of
it quickly, and run quite a long while on that knowledge. But really
knowing Python, deeply, inside out, is a challenge in itself: there is a
great deal of details to know. So, despite Python allows us to be much
more efficient and productive than with other languages, I would never
go as far as saying that Python is fully easy.
Roy Smith
> Ok, you need a core library of system calls, but then you go.
Depends on what you're trying to do. If you're writing an application
to run on top of an operating system, then yes, you need a library of
system calls. But, even at that, most system call libraries are a
very thin layer which do little more than put arguments on the stack
in the right format and execute some flavor of trap instruction.
But, there are plenty of things you might want to do with C which do
not involve any sort of system call library at all. You might be
writing an embedded system which runs directly on top of the hardware.
Or, you might be writing an operating system itself, or a device
driver. It's a pity that most people don't ever get to do either of
those. You miss out on some good experiences by never getting to
touch the hardware directly.
Thomas Heller
Hehe. Absolutely correct! If the hardware supports memory-mapped I/O,
nothing is needed except C itself.
Thomas
holger krekel
> I use Python in several projects. One of the main benefits of doing
> so is that my programmers can quickly learn Python and get productive.
> Python is a great language to read. Very seldom does one of my programmers
> missunderstand code somebody else have written. This is one, if not the most,
> important aspect of a great language. Most of the time are spent in reading
> code while adding a new module (to see where it should fit) or fixing
> bugs. And by definition, for a non-trivial application, this is code that
> somebody else wrote.
>
> The ability to produce readable code is one of the best things with Python.
>
> Python more or less forces you to write nice code. This is a good thing. Not
> an issue when you are a single programmer on a project. But when you have a
> bunch of programmers with different skills this is great.
>
> But I see a disturbing trend.
>
> Just a few examples...
OK, lots of people gave their oppinion on this, already.
Your posting has a *huge* potential :-)
But in fact i'd like to see some examples of what is readable and
what is not readable in your oppinion.
> The new enumerate or zip function.
I am especially interested in seeing some code that enforces your
point about these two.
thanks,
holger
Daniel Dittmar
> But in fact i'd like to see some examples of what is readable and
> what is not readable in your oppinion.
zip, enumerate: readable, because you can search the docs for the words. It
is also easy to implement variations: returning other datatypes, returning
an iterator to preserve memory. Thus the whole program becomes easier to
understand because similar task are called in a similar way.
list comprehension: not readable, because you don't know what to search for.
You can't create dictionary comprehension or generator comprehension (both
have been proposed on c.l.p), thus making the resulting program less
regular.
Daniel
Russell E. Owen
Erik Max Francis <m...@alcyone.com> wrote:
>"James J. Besemer" wrote:
>
>> I collect pocket reference guides, and FWIW, Python's is the largest!
>>
>> Perl 5 (including libraries) is only 48 pages.
>>
>> I have C/C++ pocket refs that work out to 8 pages for the language and
>> 8 pages for the libraries.
>
>I think what's making the difference here is the quality/depth of the
>reference guides, not the actual languages. A "C/C++" reference that is
>a total of 16 pages simply not comparable to a Python reference that is
>124 pages. C and C++ (two different languages, by the way) are not
>about 8 times simpler than Python. Far from it, in fact.
I agree. I'd say that the ratio of power to pitfalls is one very good
way to gauge a language. Consider C++ and Python in that light:
C++ has many nasty pitfalls. Sources of trouble include the lack of
garbage collection, the use of pointers, a complex object implementation
and strong typing (which plays hell with collection classes). Several
entire books are devoted to subtle ways you can shoot yourself in the
foot with C++ (I have Meyer's Effective C++ and More Effective C++ and
found them very useful). It's so bad that I cringe whenever I use C++
classes (did I remember to disable copying and related methods, or
support it specially in some way? are my destructors really solid? am I
doing things the virtual way or not depending on future plans for
inheritance?).
Contrast that with Python. Python has most of the features of C++,
including classes, collections, multiple inheritance, exception
handling. Yet these features are much easier to use (admittedly at a
small hit in power, but it's a tradeoff I heartily endorse) and Python
has many fewer pitfalls. A book of cautions would be very short --
perhaps a worthy chapter in a Python reference manual, but no more.
With regards to Perl, I favor Python for some of its other virtues,
including readability and self-consistency.
In my experience, the only language I've used that comes close to Python
for power, ease of use and overall enjoyable programming is Smalltalk
(which is more self-consistent, has better collection classes and a
much, much better development environment, but of course also has its
own weaknesses--including it's pretty hopeless for short scripts). Ruby
looks very promising, but I've not learned it. The bits of Lisp I
learned were promising. LabView is quite amazing in some ways.
So when you see me pontificating about perceived warts in Python, I do
want to say I speak up because I love the language. Python is great and
I'd like to see it evolve to ever greatness (and certainly not towards a
morass of clutter and featuritis).
In trying to kill 3 birds with one stone, I also want to say something
about division. As I understand it, the primary reason to change / so it
never truncates is because if you are dividing two variables, you may
not know in advance whether they will be floats or integers. The new way
allows you to consistently get a given result. Note that this is
entirely a nonissue in C/C++ because of its strong typing. I personally
heartily endorse the new way of doing things and heartily thank Guido
for taking this stand. Change is very painful, as is not doing things
"the C way", so it's bound to cause anguish.
-- Russell
Eddie Corns
>list comprehension: not readable, because you don't know what to search for.
I disagree with the original point but it did occur to me last night that an
'explain' mode for an expression would be a helpful feature (preferrably
inside an editor).
> explain ('[a for a in foo() if a in bar]')
Create a list of elements ...
Non trivial I know especially if you want to try and give more details for
something like:
[(x,zing(x,y),a) for y,x,_ in records if x>y]
Eddie
Terry Reedy
"Paul Foley" <s...@below.invalid> wrote in message
news:m2of8rg...@mycroft.actrix.gen.nz...
> >>>> a = [(1,2,3,4),(5,6,7,8)]
> >>>> zip(zip(a))
> > [(((1, 2, 3, 4),),), (((5, 6, 7, 8),),)]
>
>
> >>> a = [(1,2,3,4),(5,6,7,8)]
> >>> zip(a)
> [(1, 2, 3, 4), (5, 6, 7, 8)]
On what system/build? Cutting and pasting your entered data...
Python 2.2.1 (#34, Apr 15 2002, 09:51:39) [MSC 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> a = [(1,2,3,4),(5,6,7,8)]
>>> zip(a)
[((1, 2, 3, 4),), ((5, 6, 7, 8),)]
>>> zip(*a)
[(1, 5), (2, 6), (3, 7), (4, 8)]
TJR
>
> and, not surprisingly,
>
> >>> zip(zip(a))
> [(1, 2, 3, 4), (5, 6, 7, 8)]
>
> so it works there. And now
>
> >>> b = zip(*a)
> >>> b
> [(1, 5), (2, 6), (3, 7), (4, 8)]
>
> and
>
> >>> c = zip(*b)
> >>> c
> [(1, 2, 3, 4), (5, 6, 7, 8)]
>
> and
>
> >>> c == a
> 1
>
>
>
> Oh, I see; I wrote a zip function in my startup file before it was a
> builtin, and I've never taken it out...the builtin version does as
you
> say in the first example (but why? Looks like a bug, to me!)
>
> --
> Whenever you find that you are on the side of the majority, it is
time
> to reform. -- Mark
Twain
>
> (setq reply-to
> (concatenate 'string "Paul Foley " "<mycroft" '(#\@)
"actrix.gen.nz>"))
sism...@hebmex.com
> Sent: Friday, November 15, 2002 11:51 AM
>
> ...snip...
>
> waiting-for-someone-to-ask-for-class-comprehensions-ly y'rs - tim
>
Please tell us about this class-comprehension-thingie.
-gus
Skip Montanaro
Russell> and strong typing (which plays hell with collection classes)
^^^^^^
Make that "static". ;-)
sism...@hebmex.com
> Sent: Friday, November 15, 2002 10:43 AM
>
> holger krekel wrote:
> > But in fact i'd like to see some examples of what is readable and
> > what is not readable in your oppinion.
>
> zip, enumerate: readable, because you can search the docs for
> the words. It is also easy to implement variations: returning
> other datatypes, returning an iterator to preserve memory. Thus
> the whole program becomes easier to understand because similar
> task are called in a similar way.
>
> resulting program less regular.
>
> Daniel
>
But these are your *opinions*. And while valid, others on the
same list (or lists) have expressed nothing but rave reviews on
the same things you don't like.
So, what to do?
Macros, a-la Lisp, so anyone can have whatever syntax they want?
A mishmash of features, like Perl?
-gustavo
Dave Brueck
> holger krekel wrote:
> > But in fact i'd like to see some examples of what is readable and
> > what is not readable in your oppinion.
>
[snip]
> list comprehension: not readable, because you don't know what to search for.
It's funny what people do and don't find readable, huh? I use list comps
all the time because to me they are almost always more readable than the
equivalent code and more vertically compact as well. I wouldn't mind
having a dictionary comp but don't need it nearly as much, even less so a
generator comp.
Just my $0.02,
Dave
Tim Peters
> It's funny what people do and don't find readable, huh? I use list
> comps all the time because to me they are almost always more readable
> than the equivalent code and more vertically compact as well. I
> wouldn't mind having a dictionary comp
Do you know that dict() accepts an iterable object producing iterable
objects producing 2 objects each? It's not exactly transparent when phrased
that way <wink>, but an example should help:
>>> dict([(i, i**2) for i in range(0, 20, 2)])
{0: 0, 16: 256, 2: 4, 4: 16, 6: 36, 8: 64, 10: 100, 12: 144,
18: 324, 14: 196}
>>>
Or, more strangely,
>>> def square(i):
... yield i
... yield i**2
>>> dict([square(i) for i in range(0, 20, 2)])
{0: 0, 16: 256, 2: 4, 4: 16, 6: 36, 8: 64, 10: 100, 12: 144, 18: 324, 14:
196}
>>>
dict(zip(keys, values)) is also a useful thing to understand.
> but don't need it nearly as much, even less so a generator comp.
waiting-for-someone-to-ask-for-class-comprehensions-ly y'rs - tim
Skip Montanaro
Dave> I wouldn't mind having a dictionary comp but don't need it nearly
Dave> as much, ...
And you can always fudge it with a dictionary and a list comprehension:
d = {}
[d.update({...}) for ...]
or
d = dict([(k,v) for ...])
Skip
Dave Brueck
> [Dave Brueck]
> > It's funny what people do and don't find readable, huh? I use list
> > comps all the time because to me they are almost always more readable
> > than the equivalent code and more vertically compact as well. I
> > wouldn't mind having a dictionary comp
>
> Do you know that dict() accepts an iterable object producing iterable
> objects producing 2 objects each?
Yup. (Skip pointed this out too) I wouldn't mind having a special syntax
for dictionary comps, but mostly I was just voicing my opinion to the OP
that I need such a thing far less often than list comps.
-Dave
Manuel M. Garcia
<j...@cascade-sys.com> wrote:
(edit)
>In any case, I agree Pocket reference guides are at best a poor metric for
>comparing language complexity. I only mentioned the others because Mr.
>Garcia cited it as evidence that Python is "small" and I offered what were
>intended to be seen as counter examples.
I own a laminated foldout cheatsheet for Perl that is six pages long.
Obviously it is not the only reference I use for Perl. I mention the
Python Pocket Reference because its 124 4"x7" pages gets me farther
with productivity than 248 or 372 pages of documentation in other
languages I use.
I suppose a Forth manual could be written on an index card with a
crayon. I will plead that the metric I should used was the ratio of
daily referenced documentation versus productivity in varied
programming tasks. Python's ratio is pretty darn good, the best I
have found.
Manuel
Manuel M. Garcia
wrote:
(edit)
>waiting-for-someone-to-ask-for-class-comprehensions-ly y'rs - tim
NewClass = [WrapInsideProperty(attribute) for attribute in OldClass]
would be nice.
FastClass = [ImplementAsCExtension(method) for method in SlowClass if
UsedAlotAndRunsTooSlow(method)]
would be very nice.
Python 2.4?
Manuel
Daniel Dittmar
>>the words. It is also easy to implement variations: returning
>>other datatypes, returning an iterator to preserve memory. Thus
>>the whole program becomes easier to understand because similar
>>task are called in a similar way.
>>
>>list comprehension: not readable, because you don't know what to
>>search for. You can't create dictionary comprehension or generator
>>comprehension (both have been proposed on c.l.p), thus making the
>>resulting program less regular.
> But these are your *opinions*.
No. These are criteria (or whatever the plural of criterion is),
although of course there isn't a strict line between 'readable' and 'not
readable'. Most Python programmers will agree that putting something
into a library is generally a better choice than inventing a new syntax.
Where some disagree is if building a list is so common that a new syntax
makes the code actually more readable because the intentions are more
explicit.
> And while valid, others on the
> same list (or lists) have expressed nothing but rave reviews on
> the same things you don't like.
True. But the initial posters concern was that if more of these features
make it into Python, than a specific quality and a specific user group
(the casual Python programmer) may be lost.
Occasionally I have to change a Perl script, so I know what it is like
if you can't look something up by a keyword.
> So, what to do?
> Macros, a-la Lisp, so anyone can have whatever syntax they want?
> A mishmash of features, like Perl?
Or perhaps nothing?
Daniel
Skip Montanaro
Manuel> I will plead that the metric I should used was the ratio of
Manuel> daily referenced documentation versus productivity in varied
Manuel> programming tasks. Python's ratio is pretty darn good, the best
Manuel> I have found.
Indeed. With very rare exception, the only documentation tools I need are
the builtin help() function and the global module index:
http://www.python.org/doc/current/modindex.html
Fred Drake and his minions do a wonderful job keeping the documentation
within spitting distance of the source code.
I don't use any of those fancy-schmancy IDEs, though I do use python-mode,
which has F1 bound to call help() on the dotted attribute expression under
the cursor.
John Hunter
Skip> I don't use any of those fancy-schmancy IDEs, though I do
Skip> use python-mode, which has F1 bound to call help() on the
Skip> dotted attribute expression under the cursor.
Hey ... emacs IS fancy-schmancy!
What is the python-mode function that you bind F1 to? That sounds
useful.
John Hunter
Erik Max Francis
> Indeed. With very rare exception, the only documentation tools I need
> are
> the builtin help() function and the global module index:
>
> http://www.python.org/doc/current/modindex.html
>
> Fred Drake and his minions do a wonderful job keeping the
> documentation
> within spitting distance of the source code.
Same here, and agreed. I do have a copy of the _Python Essential
Reference_, but the only time I really find myself going to it is when I
want to implement a class that behaves like a numeric and so implements
most of the arithmetic operators; there's a concise list of all the
arithmetic operators you can overload in a class, so I frequently find
myself using it as a checklist. Though I think it's a great book,
that's really the only section I've relied upon.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ I never vote for anyone. I always vote against.
\__/ W.C. Fields
Bosskey.net: Aliens vs. Predator 2 / http://www.bosskey.net/avp2/
A personal guide to Aliens vs. Predator 2.
Terry Hancock
> waiting-for-someone-to-ask-for-class-comprehensions-ly y'rs - tim
I'm inspired. Unfortunately, I'm still using 2.1.3 -- pardon my dust:
def meth1():
print 1
def meth2():
print 2
def meth3():
print 3
# Emulate 2.2 built-in?
def dict(l):
d = {}
for pair in l:
d[pair[0]] = pair[1]
return d
class comp:
def __init__(self):
self.__dict__.update(dict(
[(f.__name__,f) for f in globals().values() if callable(f) ] ))
>>> c = comp()
>>> c.meth1()
1
>>> c.meth2()
2
;-D
Still considering whether there's a more compact (or at least clearer) way to
write that.
Practically, of course, using globals() is sort of dumb -- but imagine
importing a module and using the module name instead.
Actually I can think of one practical use for this: In a Zope product, it's
quite convenient to have a separate module containing ZSQL methods defined
using Zope's SQL() factory function (that way you separate SQL and Python
languages for the most part). Then you could use this code with the ZSQL
module to put ALL SQL methods from a given module into a class. That way
you skip a whole lot of:
mySQL_query = SQLmodule.mySQL_query
statements in the class file that have to be updated every time you change
your SQL (which is fairly frequent). This particular ugliness came up in the
Zope list a few months ago, and the OP proposed writing a special parser /
SQL extension language to do it. It turned out that this need to "shovel" the
whole contents of an SQL module into a class was the only real problem it
solved. This would be a simpler solution.
There's other, perhaps better, ways to do it, of course -- it might make more
sense to just use a loop and setattr(), for example.
Just adding to the list comp madness. ;-)
Terry
--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks http://www.anansispaceworks.com
Skip Montanaro
John> What is the python-mode function that you bind F1 to? That sounds
John> useful.
py-help-at-point. I'm using python-mode 4.11. I believe it's part of
recent versions. (I wrote it awhile ago and Barry added it, including the
key binding.)
Skip
Erik Max Francis
> I might not be fully singing with the choir here, but I do not find
> that
> C is a simple language. It has fairly intricate points here and
> there,
> and I guess there are very, very few people in this crowd, and in many
> other crowds as well, truly able to reply correctly to any question
> about
> C, the language, not even considering its libraries.
I think C itself is a relatively straightforward language, but it is
obviously much lower level than (say) Python, and so using it
productively will require considerably greater effort.
Erik Max Francis
> It's funny what people do and don't find readable, huh? I use list
> comps
> all the time because to me they are almost always more readable than
> the
> equivalent code and more vertically compact as well. I wouldn't mind
> having a dictionary comp but don't need it nearly as much, even less
> so a
> generator comp.
Indeed. Certainly list comprehensions take a little getting used to if
you've never seen one before, and they can be abused just like any
language feature can be abused, but I find the liberal use of list
comprehensions very readable and very compact.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ You are in the music / In the man's car next to me
\__/ Sade
Rules for Buh / http://www.alcyone.com/max/projects/cards/buh.html
The official rules to the betting card game, Buh.
Erik Max Francis
> On Thu, 14 Nov 2002 20:00:22 -0800, Erik Max Francis wrote:
>
> > You keep glossing over the difference between C and C++, but they
> > are
> > not the same thing,
>
> Hmm. That's what some of us keep saying about Scheme and Lisp.
> Someone recently called me a crackpot for saying so.
Scheme and (Common) Lisp aren't the same language, of course, but they
are obviously related.
> Is it
> not-crackpottery to tell people C and C++ (which are far closer than
> Scheme and Lisp) are not the same thing?
Just as C and C++ are obviously related, that doesn't mean they're the
same language.
Carl Banks
>> But these are your *opinions*.
>
> No. These are criteria (or whatever the plural of criterion is),
> although of course there isn't a strict line between 'readable' and 'not
> readable'.
These are criteria not everyone considers important. To me, ability
to search for something has nothing to do with its readability.
> Most Python programmers will agree that putting something
> into a library is generally a better choice than inventing a new syntax.
Usually this is true, if it is something that a library function is
capable of. There are a few things in Python that have their own
syntax where a library function will do (print, exec), but not many.
However, list comprehensions have their own syntax because it's
impossibe to do them with a function. This was not a case of someone
saying, "we could do this as a function, but it's so important that we
have to define a new syntax for it."
> Where some disagree is if building a list is so common that a new syntax
> makes the code actually more readable because the intentions are more
> explicit.
Some might argue that list comprehensions are not useful enough or too
unsightly to justify adding complexity to the language, but no correct
thinker would argue that it should have been a function instead of a
new syntax.
--
CARL BANKS
Chad Netzer
> Simon> Yeah there's plenty of nice things in the STL, but it's a
> Simon> library, not part of the language.
>
> The distinction isn't particularly important.
True, but I think the original point in the thread was that in describing
Python, you have to almost immediately talk about tuples, lists, and
dictionaries, since they are so important to the core language (argument
passing, multiple argument returns, introspection of objects, namespaces,
etc.), as well as being immediately useful builtin datatypes for programmers.
With C++, you can get away with not discussing many of the standard library
containers, until after you have discussed references, pointers,
call-by-value vs. call-by-ref, etc.
So, while your point about knowing and using the standard library is well
made, it may be an orthogonal one to how early it should be introduced to new
users of the language (at least, as far as standard containers and such go)
--
Bay Area Python Interest Group - http://www.baypiggies.net/
Chad Netzer
cne...@mail.arc.nasa.gov
David Mertz, Ph.D.
|> You keep glossing over the difference between C and C++, but they are
|> not the same thing,
|Hmm. That's what some of us keep saying about Scheme and Lisp.
|Someone recently called me a crackpot for saying so. Is it
|not-crackpottery to tell people C and C++ (which are far closer than
|Scheme and Lisp) are not the same thing?
Well... I think I'm said crackpot-caller. No offense meant, btw, Paul
(feel free to launch similar allegations to my non-disguised address).
But the allegation was on the equation of Intercal with Java. Those
seem rather far apart to me. Much farther than C and C++ or Scheme and
Lisp.
The first principle I would espouse is: SYNTAX MATTERS! Really it
does. I quite sincerely believe that no matter what the whole "Why is
Python popular and Lisp not" thread said, the biggest problem Lisp has
(popularity-wise, but popularity need not be a goal) is syntax. And,
yes, I also believe that Lisp has parentheses and prefix notation (I
have a half-dozen famous introductions that confirm this belief, and
only some... well, crackpot, asides that dispute it on Jesuitical
reasons).
So on the syntax, we can note the following:
Lisp Scheme Python C C++ Java Intercal
lots-of-parens not so many .............................
prefix notation mostly infix................... sentential
even more parens indents { delimiter blocks } lines
even more parens lines semicolons........... lines
But on semantic issues, the same patterns exists:
Lisp Scheme Python C C++ Java Intercal
largely-functional a little hardly at all.................
code-as-data difficult not really at all.............
dynamic typing yep very static difficult ???
OOP with work OOP procdrl OOP OOP procedural
lots of recursion a little smidgeon less still I think none
continuations old stackless Not a chance...................
multi-paradigm yep No Painful Sort-of less than one
So basically, in every broad category Lisp and its dialect Scheme come
out the same. Python indeed leans closer to the Lisp side of things
than do other languages.
Now indeed, C and C++ differ in some significant ways. But they have a
special relationship in the sense the C++ is a superset of C. Well, at
least close. Almost every valid C program is also a valid C++ program.
In that sense, writing about C/C++ may miss something significant, but
it doesn't quite make "crackpot".
Yours, David...
--
_/_/_/ THIS MESSAGE WAS BROUGHT TO YOU BY: Postmodern Enterprises _/_/_/
_/_/ ~~~~~~~~~~~~~~~~~~~~[me...@gnosis.cx]~~~~~~~~~~~~~~~~~~~~~ _/_/
_/_/ The opinions expressed here must be those of my employer... _/_/
_/_/_/_/_/_/_/_/_/_/ Surely you don't think that *I* believe them! _/_/
Jon Bills
> On Friday 15 November 2002 05:31, Andrew Koenig wrote:
>
>> Simon> Yeah there's plenty of nice things in the STL, but it's a
>> Simon> library, not part of the language.
>>
>> The distinction isn't particularly important.
>
> True, but I think the original point in the thread was that in
> describing Python, you have to almost immediately talk about tuples,
> lists, and dictionaries, since they are so important to the core
> language (argument passing, multiple argument returns, introspection
> of objects, namespaces, etc.), as well as being immediately useful
> builtin datatypes for programmers. With C++, you can get away with
> not discussing many of the standard library containers, until after
> you have discussed references, pointers, call-by-value vs.
> call-by-ref, etc.
That might be technically true, but its not very useful. You would be doing
a newcomer to C++ an injustice by not teaching the mechanisms which allow
them to build useful programs easily, regardless of whether those mechanisms
exist in the language or standard library. This leads me to believe the
distinction between language and library, at least in this context, is not
very valuable.
Jon.
M
for discussing this.
To add fuel I just meantion a few more or less random points...
I'll give you a list of things you must consider when
specifying a function interface in C++. I use C++ as my personal horror
story generator but you could possibly replace C++ with many other
languages. The reason why I make this example is to show something I would
like never to be needed for Python.
So, to define a function in C++, please consider the following:
1) Operator or non-operator function?
2) Free or member function?
3) Virtual or non-virtual function?
4) Pure or non-pure virtual member function?
5) Static or non-static member function?
6) const or non-const member function?
7) Public, protected, or private member function?
8) Return by value, reference, or pointer?
9) Return const or non-const?
10) Optional or required argument?
11) Argument by value, reference or pointer?
12) Pass argument as const or non-const?
13) Friend or non-friend function?
14) inline or non-inline
This is just *one example*. (C++ happens to be the victim here because
I have programmed it) I could have picked something else horrible
about class templates or template parameters or whatever. Nevertheless my
point is that a language can be too complex when trying to make it
powerfull. A function is really a simple abstraction, why make it this
complex?
Some of the posters say that it is "just to learn python properly". Yes, that
would be nice if all programmers in all projects in the world had several years
or more experience in using the tools/languages of the project. But this
is not reality (not mine anyway). Many times people end up fixing things
and adding modules using languages they have never seen and will never see
again. If trying to do this with a complex language that is hard to read one
could easily predict the results...
Its also about $$. I don't want a programmer to be stuck in trying to
understand a complicated language feature. It does not provide value to
our customers. I want a language to be simple, simple, simple. But not
simpler than that ;-) Don't throw in a nice feature that can solve a problem
in a few lines of code if the same problem can already be solved with
the language. Just and example. Operator overloading. Why should we have it?
Just so that you can write vector1 + vector2 instead of vector1.add(vector2)?
Maybe not the best example but I hope you understand my point.
A language that does not give programmers suprises is good. A high suprise
factor just gives you more bugs. The addition of default behaviour can be one
such thing. Look at Perl. Lots of things happen without that you
can see it in the code. It should not happen if you can not see it in
the code! (C++ again; crash before entering main anyone?).
/Marv
Keep on writing...
Greg Ewing
> Operator overloading. Why should we have it?
For consistency. So that user-defined types have the
same rights and privileges as built-in ones.
> Just so that you can write vector1 + vector2
> instead of vector1.add(vector2)?
If you're not heavily into linear algebra you might
not see the value of this, but believe me, it can
make a HUGE difference to the readability of code
that manipulates matrices and vectors a lot. Try
to explain to the Numeric people that they should
enjoy writing matrix1.add(matrix2) all the time
and see how far you get...:-)
--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg
Greg Ewing
> It's ostensibly the reason why
> integer division was redefined to produce a real result -- because naive
> users might be "confused" by a truncated integer result.
No, that's not the reason. The reason is that the
combination of dynamic typing with an operator that
does different things on two closely-related types
is an accident waiting to happen. Even if you're
fully aware of the potential problem, it can
still trip you up.
I believe Guido did the right thing by changing this.
holger krekel
> There seems to be many opinions about my post. That is good. Thanks everybody
> for discussing this.
I'd prefer it if you actually answered to some posts.
holger
Christian Tanzer
Skip Montanaro <sk...@pobox.com> wrote:
Time machine? python.org only has 4.6.
--
Christian Tanzer tan...@swing.co.at
Glasauergasse 32 Tel: +43 1 876 62 36
A-1130 Vienna, Austria Fax: +43 1 877 66 92
John Hunter
Christian> Time machine? python.org only has 4.6.
CVS -
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Misc/python-mode.el
Now at v4.28.
The one feature I'm unhappy with in python mode is text wrapping
If you have
class counting_dict(dict):
"""A specialized dictionary for counting. This help string goes on and on and on"""
def __call__(self, key):
key = key.strip()
self[ key ] = self.get( key , 0 ) + 1
and execute fill-paragraph in the help string, it returns
class counting_dict(dict): """A specialized dictionary for counting.
This help string goes on and on and on""" def __call__(self, key):
key = key.strip() self[ key ] = self.get( key , 0 ) + 1
rather than something like
class counting_dict(dict):
"""A specialized dictionary for counting. This help string goes
on and on and on"""
def __call__(self, key):
key = key.strip()
self[ key ] = self.get( key , 0 ) + 1
Ditto for comments, filling the comment string in
# xreadlines will split the file by newlines. votes is now a list of favorite ice creams.
votes = file('votes.dat').xreadlines()
gives
# xreadlines will split the file by newlines. votes is now a list of
favorite ice creams. votes = file('votes.dat').xreadlines()
when it should give
# xreadlines will split the file by newlines. votes is now a list of
# favorite ice creams.
votes = file('votes.dat').xreadlines()
Is there a function in python-mode that I should be using for this?
or is on the todo wish list? matlab-mode actually gets this right (at
least for '%' comments), so some enterprising individual could go lift
that code....
John Hunter
Michael Hudson
> On Fri, 15 Nov 2002 12:50:39 -0500, Tim Peters <tim...@comcast.net>
> wrote:
> (edit)
> >waiting-for-someone-to-ask-for-class-comprehensions-ly y'rs - tim
>
> NewClass = [WrapInsideProperty(attribute) for attribute in OldClass]
>
> would be nice.
Not quite sure what that means, but I bet you can do it with a
metaclass...
> FastClass = [ImplementAsCExtension(method) for method in SlowClass if
> UsedAlotAndRunsTooSlow(method)]
>
> would be very nice.
That one seems trickier :)
Cheers,
M.
--
It's actually a corruption of "starling". They used to be carried.
Since they weighed a full pound (hence the name), they had to be
carried by two starlings in tandem, with a line between them.
-- Alan J Rosenthal explains "Pounds Sterling" on asr
Bernhard Herzog
> Skip Montanaro <sk...@pobox.com> wrote:
>
> I'm using python-mode 4.11.
[...]
>
> Time machine?
No, CVS
> python.org only has 4.6.
The CVS version is 4.28 (unless it has changed since yesterday :) )
Bernhard
--
Intevation GmbH http://intevation.de/
Sketch http://sketch.sourceforge.net/
MapIt! http://www.mapit.de/
Bernhard Herzog
> The one feature I'm unhappy with in python mode is text wrapping
I posted some code a while ago to get this working for the cases you
mention, strings and comments. It does work for me in most cases but
YMMV:
http://mail.python.org/pipermail/python-list/2002-May/103189.html
Erik Max Francis
> The one feature I'm unhappy with in python mode is text wrapping
>
> If you have
...
> and execute fill-paragraph in the help string, it returns
>
> class counting_dict(dict): """A specialized dictionary for counting.
> This help string goes on and on and on""" def __call__(self,
> key):
> key = key.strip() self[ key ] = self.get( key , 0 ) + 1
Indeed, this is the only fault I have with python-mode as well. It
would be nicer if reformatting strings and constants were more clever
about context.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ The great floodgates of the wonder-world swung open.
\__/ Herman Melville
Bosskey.net: Return to Wolfenstein / http://www.bosskey.net/rtcw/
A personal guide to Return to Castle Wolfenstein.
Skip Montanaro
>> The one feature I'm unhappy with in python mode is text wrapping...
Erik> Indeed, this is the only fault I have with python-mode as well.
I passed the earlier solution along to Barry Warsaw, Elisper Extraordinaire.
He apparently hadn't seen it before. Look for it in a future
python-mode.el, coming to a disk near you...
Skip Montanaro
Skip> you...
John> Great! Will you give us a head up when it makes it into CVS?
Will do.
S
jdhu...@ace.bsd.uchicago.edu
Skip> I passed the earlier solution along to Barry Warsaw, Elisper
Skip> Extraordinaire. He apparently hadn't seen it before. Look
Skip> for it in a future python-mode.el, coming to a disk near
Skip> you...
Great! Will you give us a head up when it makes it into CVS?
Thanks,
John Hunter