Python rocks
Mark Carter
I've been enchanted by the siren calls of Scheme, Lisp and Forth, but in
the end, I find Python much easier. I even tried a little bit of Tcl.
To give a bit of context ... I have recently switched from Windows to OS
X and Linux. I missed MS Money, but couldn't get on with GnuCash. So I
decided to write my own little home-brew money management program that
includes things like downloading share price info from Yahoo Finance.
I picked Chicken Scheme for OS X. Things started well, and even the web
download and regex stuff worked fairly painlessly. I wanted to work with
dates, and decided that I needed the SRFI-19 library. Chicken has
"eggs", which you can download and install. The problem is that it
needed further dependencies. Well, no need to panic just because of
that; but I found that it ultimately depended on gmp, which turned out a
pain to compile.
Other languages seem to have neat ideas; like closures or macros in
Scheme, or ultra-simple syntax like Forth. But what I have generally
found is that other languages seem to require too much pain for too
little return. I just seem to be way more productive in Python than in
any other language.
Steve Howell
--- Mark Carter <m...@privacy.net> wrote:
> Well, I know I'm preaching to the converted - but
> Python rocks.
> [...]
A few questions from the choir:
As a recent newcomer to the language, did you
encounter any traps or pitfalls while you were
learning? Also, could you single out anything in
particular about Python that started making you more
productive, or was it just the overall design?
____________________________________________________________________________________
Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.
http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow
Mark Carter
> --- Mark Carter <m...@privacy.net> wrote:
>
>> Well, I know I'm preaching to the converted - but
>> Python rocks.
>> [...]
>
> A few questions from the choir:
>
> As a recent newcomer to the language, did you
> encounter any traps or pitfalls while you were
> learning? Also, could you single out anything in
> particular about Python that started making you more
> productive, or was it just the overall design?
Well, I've been around the block a few times with Python, and had
decided to try a couple of other languages. Having poked around, I've
come to the conclusion that Python is the best language out there, and
thought I'd share my observation with everyone. I hadn't posted to Lisp,
because that'd be, like, considered trollish.
Python's biggest win is probably its "batteries included" philosophy.
Plus its extensive documentation. IDLE is simple, but it gets the job
done. The syntax is obvious enough, so there's not much to dislike about
Python.
Not that I'm particularly knowledgeable about language design issues,
but maybe closures and slightly different scoping rules would be nice. A
pitfall of Python is knowing whether an operation is destructive or not.
I guess if it was a purely functional language, that particular question
wouldn't arise. Not that I'm saying I want Python to be a purely
functional language. Oh, and when I read a line, I'd like it to get rid
of the trailing line-ending characters.
Python is accreting a lot of language features, and I'm not sure that's
a good idea. Still, I guess if I don't like them, I don't have to use them.
The thing about Lisp I found is that it's horribly fragmented, and
doesn't do what I want it to do out of the box. Lisp is just too
tedious. Python Just Works. I checked out Ruby a couple of years ago,
but couldn't find anything to be worth the switch. I'm amazed at some of
the things people have been able to do in Forth; but then, it doesn't
beat Python's truckload of libraries and stuff like dictionaries, lists
and other goodies that I get out of the box.
George Sakkis
> --- Mark Carter <m...@privacy.net> wrote:
>
> > Well, I know I'm preaching to the converted - but
> > Python rocks.
> > [...]
>
> A few questions from the choir:
>
> As a recent newcomer to the language, did you
> encounter any traps or pitfalls while you were
> learning?
I had probably stumbled on many/most of the common pitfalls usually
mentioned (e.g. http://www.ferg.org/projects/python_gotchas.html,
http://zephyrfalcon.org/labs/python_pitfalls.html) while learning, but
picked them up easily after the first or second time. Off the top of
my head, two errors that keep coming back even years after are:
- Comparing instances of (semantically) incomparable types (http://
www.ibm.com/developerworks/library/l-python-elegance-1.html).
Thankfully this will be fixed in Py3k.
- Strings being iterable; unfortunately this will stay in Py3K.
> Also, could you single out anything in
> particular about Python that started making you more
> productive, or was it just the overall design?
If I were to pick a single feature, this would be the triplet
iterators-generators-itertools, not only for the productivity gains
but perhaps even more for changing the way of thinking about
programming, making Python worth learning [1]. But in general it's the
overall design, making the right tradeoffs in most cases.
George
[1] "A language that doesn't affect the way you think about
programming, is not worth knowing." - Alan Perlis
Josiah Carlson
> Not that I'm particularly knowledgeable about language design issues,
> but maybe closures and slightly different scoping rules would be nice.
Python has had closures for years. What kind of scoping did you desire?
> A
> pitfall of Python is knowing whether an operation is destructive or not.
If it returns None, it probably changes the content of an object.
> I guess if it was a purely functional language, that particular question
> wouldn't arise.
You can certainly do your programming in a functional style with Python.
List comprehensions and generator expressions are very good for this
kind of thing.
> Oh, and when I read a line, I'd like it to get rid
> of the trailing line-ending characters.
Refuse the temptation to guess. As many people want to keep the
newlines as not (it disambiguates the case of end of file and blank
line), and it is a simple thing to deal with: line.rstrip('\r\n') .
- Josiah
Aahz
George Sakkis <george...@gmail.com> wrote:
>
>I had probably stumbled on many/most of the common pitfalls usually
>mentioned (e.g. http://www.ferg.org/projects/python_gotchas.html,
>http://zephyrfalcon.org/labs/python_pitfalls.html) while learning, but
>picked them up easily after the first or second time. Off the top of
>my head, two errors that keep coming back even years after are:
>- Comparing instances of (semantically) incomparable types (http://
>www.ibm.com/developerworks/library/l-python-elegance-1.html).
>Thankfully this will be fixed in Py3k.
>- Strings being iterable; unfortunately this will stay in Py3K.
I'll repeat the comment I made on python-3000:
"...string iteration isn't about treating strings as sequences of
strings, it's about treating strings as sequences of characters. The
fact that characters are also strings is the reason we have problems,
but characters are strings for other good reasons."
Thing is, the fact that you can e.g. slice strings just like other
sequence types creates the consequence that you can also iterate over
strings -- moreover, some of us actually do iterate over strings (though
of course we could if necessary create lists/tuples of characters). In
the grand scheme of things, I rarely see people running into problems
with iterating over strings.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"as long as we like the same operating system, things are cool." --piranha
Mark Carter
> Mark Carter wrote:
>> Not that I'm particularly knowledgeable about language design issues,
>> but maybe closures and slightly different scoping rules would be nice.
>
> Python has had closures for years.
I just looked up
http://www.secnetix.de/~olli/Python/lambda_functions.hawk
and was amazed to discover that you were right. Nice one.
> What kind of scoping did you desire?
Well, I had in mind so that if you defined a function, but wanted to
access a global var, that you didn't have to use the global keyword. Not
much of a biggie, I guess.
> Refuse the temptation to guess. As many people want to keep the
> newlines as not (it disambiguates the case of end of file and blank
> line), and it is a simple thing to deal with: line.rstrip('\r\n') .
I guess that about wraps it up, then. Python pretty much has it all.
Except for macros - which is not necessarily a dealbreaker, anyway.
Alex Martelli
> I picked Chicken Scheme for OS X. Things started well, and even the web
...
> that; but I found that it ultimately depended on gmp, which turned out a
> pain to compile.
Yes, GMP is a pain to compile (especially on Mac OS X), but I believe
that the Universal Binary library version I've put among the gmpy
downloads (see http://code.google.com/p/gmpy/downloads/list) works fine
(at least it seems to work fine for gmpy, which is my Python extension
that wraps GMP, and gmpy exposes and copiously unit-tests essentially
all of GMP's functionality).
Just mentioning this in case you want to give Scheme another chance
(which it may well deserve, although closures are hardly unique to it; I
wonder if you meant continuations). Python may enjoy better tools and
libraries than Scheme, but then Java enjoys better ones yet, yet I
prefer to stick with Python because I like it better *as a language*...
Alex
Alex Martelli
> > pitfall of Python is knowing whether an operation is destructive or not.
>
> If it returns None, it probably changes the content of an object.
A reasonable heuristic, but with lots of exceptions, alas:
somedict.get(somekey)
will often return None without performing any change, while
somelist.pop()
does modify somelist but typically returns non-None.
The use of trailing-exclamation-point (by convention) to indicate
"mutating methods" is a nice plus in languages that allow it.
Alex
Josiah Carlson
> Josiah Carlson wrote:
>> What kind of scoping did you desire?
>
> Well, I had in mind so that if you defined a function, but wanted to
> access a global var, that you didn't have to use the global keyword. Not
> much of a biggie, I guess.
You already get read access to globals without using the global keyword.
To replace what the global name points to you need to use the global
keyword, but if it is mutable (list, dictionary, etc.), you can append
to it, delete items from it, etc., all without keywords.
> I guess that about wraps it up, then. Python pretty much has it all.
> Except for macros - which is not necessarily a dealbreaker, anyway.
Yeah, the lack of macros sometimes bothers me, then I remember that if I
*really* need them, there's always Logix and bytecodehacks.inline:
http://bytecodehacks.sourceforge.net/bch-docs/bch/module-bytecodehacks.inline.html
I don't know how much work it would take to get the bytecodehacks
working in a modern Python, but it may be an interesting exercise.
- Josiah
Hendrik van Rooyen
> Josiah Carlson wrote:
> > What kind of scoping did you desire?
>
> Well, I had in mind so that if you defined a function, but wanted to
> access a global var, that you didn't have to use the global keyword. Not
> much of a biggie, I guess.
You can access them without the global keyword - for "reading" .
You only need global if you are assigning to it - else you get a new function
local:
>>> x = 7
>>> def rubbish():
print x
>>> rubbish()
7
>>> def more_rubbish():
x = x+1
print x
>>> more_rubbish()
Traceback (most recent call last):
File "<pyshell#10>", line 1, in ?
more_rubbish()
File "<pyshell#9>", line 2, in more_rubbish
x = x+1
UnboundLocalError: local variable 'x' referenced before assignment
>>>def other_rubbish():
y = x+1
print y
>>> other_rubbish()
8
>>> x
7
>>> def global_rubbish():
global x
x = x + 1
print x
>>> global_rubbish()
8
>>> print x
8
>>>
- Hendrik
Mark Carter
> Mark Carter <m...@privacy.net> wrote:
> Yes, GMP is a pain to compile (especially on Mac OS X), but I believe
> Just mentioning this in case you want to give Scheme another chance
Thanks. I'll take a look at it.
I think I've decided to finish off my little in project in Python first,
though. I'd like to actually get it done (!). I may well decide to
reimplement bits in either Scheme, or I might try my hand at Forth. My
app will be small enough to permit re-writes.
I had actually done a small 3-month Java project professionally about 7
years ago. Can't say I was too impressed. IMO, it was too verbose, I'm
not an OO fanatic, and some immutable strings turned out to be not quite
as immutable as I expected.
I had a brief toy around with Java using Xcode very recently, and I was
able to figure out how to download webpages easy enough (I do this to
scrape stock quotes). I felt fairly confident that I could achieve what
I wanted in Java, even though I'm fairly raw with it. I started from a
default project using Xcode, and it seemed to generate a lot of base
code. I quickly abandoned the Java idea, as I'm not gunning to be a Java
developer, and Python seems to do what I want without fuss.
I think that's the key to Python. You can do what you want without fuss,
and it's copiously documented.
Mark Carter
Actually, that'd be nice to have in Python. And whilst we're about it,
might as well go the whole hog and allow hyphens in names, too.
Alex Martelli
> Alex Martelli wrote:
> > Mark Carter <m...@privacy.net> wrote:
>
> > Yes, GMP is a pain to compile (especially on Mac OS X), but I believe
>
> > Just mentioning this in case you want to give Scheme another chance
>
> Thanks. I'll take a look at it.
You're welcome.
> I think I've decided to finish off my little in project in Python first,
> though. I'd like to actually get it done (!). I may well decide to
> reimplement bits in either Scheme, or I might try my hand at Forth. My
> app will be small enough to permit re-writes.
Excellent situation to play around with many languages, then. If your
app can run on dotNET or Mono, you might also want to try Boo, a
language somewhat inspired by Python but with a different approach to
typing (based on type-inferencing, with an explicit 'duck' type for
those rare cases in which you really _want_ a single variable to take on
values of heterogeneous types during execution).
> I had actually done a small 3-month Java project professionally about 7
> years ago. Can't say I was too impressed. IMO, it was too verbose, I'm
> not an OO fanatic, and some immutable strings turned out to be not quite
> as immutable as I expected.
Nolo contendere on the verbosity and the need to stuff _every_thing into
a class, but the non-immutable-strings looks like a serious bug in
whatever JVM you were using at the time. Anyway, what's impressive with
Java today is not the language (maybe a bit better than it was 7 years
ago but still substantially Java:-), it's the array of excellent tools,
libraries and frameworks grown around it; Java's standard library has
arguably surpassed Python's, and third-party offerings for Java are
really great.
> I had a brief toy around with Java using Xcode very recently, and I was
Not the best IDE for Java, btw -- Apple doesn't seem to like Java all
that much any more, and it looks to me like it's backpedaling on Java's
integration in MacOSX (in favor of Python, Ruby, etc). BTW, ObjectiveC
is another language worth trying (though its non-Apple implementations
lag far, far behind, alas). Eclipse is probably "the" Java IDE nowadays
(and it's free, cross-platform, and all).
> able to figure out how to download webpages easy enough (I do this to
> scrape stock quotes). I felt fairly confident that I could achieve what
> I wanted in Java, even though I'm fairly raw with it. I started from a
> default project using Xcode, and it seemed to generate a lot of base
> code. I quickly abandoned the Java idea, as I'm not gunning to be a Java
> developer, and Python seems to do what I want without fuss.
>
> I think that's the key to Python. You can do what you want without fuss,
> and it's copiously documented.
Yes, excellent points. Although I have a long-time fascination with
many programming languages, Python does still stand out from the crowd
in enabling me to get any given app done "without fuss"!-)
Alex
Alex Martelli
Hyphens look the same as minus signs, so that allowing them in names in
a language with infix operator syntax is far from a clear win. Right
now, in Python and all cognate languages, a-b means a minus b; the
tectonic shift to having it be a 3-character identifier instead, in
addition to breaking millions of lines of existing code, would rightly
produce extreme resistance in anybody whose main programming experience
comes from Basic, C, Java, Fortran, C++, PL/I, Perl, C#, and Python
itself (and dozens of other languages, too, of course).
I noticed this effect when I was playing with Dylan (never did anything
"serious" with it, but I did like many aspects of the language): I kept
writing a-b (and for that matter a+b, etc) and getting weird syntax
errors because I had not interposed all needed spaces. (If a-b is not
allowed as an expression, it makes sense that a+b isn't either).
Despite substantial previous experience with Lisp, Scheme, and Forth, in
all of which a-b would "of course" be an identifier, that experience
just didn't guide my fingers -- in those languages operator are prefix
(Lisp, Scheme) or suffix (Forth), so it's "natural" that sticking an
operator sign "between" sequences of letters means nothing special...
but moving to an infix language just shifts my brain in a different
gear. Cobol has preferably-prefix notation too, i.e., the natural way
to express the difference would be "SUBTRACT C FROM B", and the
alternative "algebraic" (infix) notation is and feels very "bolted-on",
so it's kind of an intermediate case, where hyphens are still OK.
Not only is the cost of making a-b an identifier extremely high, but the
gains are tiny: what conventional difference is there supposed to be
between a-b and a_b? Looks like nothing but one more category of easily
confusable identifiers. Big pain, little gain == not so great an idea.
Allowing a trailing ! in method names has no such cost, because in no
language I know is ! used as a "postfix unary operator"; the gain in the
convention "mutators end with !" is not huge, but substantial. So, the
tradeoffs are different: small pain, substantial gain == not a bad idea.
However, this is all quite theoretical, because no more PEPs will be
accepted for Python 3000, so any language change like this would have to
wait for Python 4000, which is no doubt quite a distant prospect:-).
Alex
George Sakkis
> In article <1180807432.351720.123...@p47g2000hsd.googlegroups.com>,
> George Sakkis <george.sak...@gmail.com> wrote:
>
>
>
> >I had probably stumbled on many/most of the common pitfalls usually
> >mentioned (e.g.http://www.ferg.org/projects/python_gotchas.html,
> >http://zephyrfalcon.org/labs/python_pitfalls.html) while learning, but
> >picked them up easily after the first or second time. Off the top of
> >my head, two errors that keep coming back even years after are:
> >- Comparing instances of (semantically) incomparable types (http://
> >www.ibm.com/developerworks/library/l-python-elegance-1.html).
> >Thankfully this will be fixed in Py3k.
> >- Strings being iterable; unfortunately this will stay in Py3K.
>
> I'll repeat the comment I made on python-3000:
>
> "...string iteration isn't about treating strings as sequences of
> strings, it's about treating strings as sequences of characters. The
> fact that characters are also strings is the reason we have problems,
> but characters are strings for other good reasons."
No, the reason we have problems is that far more often than not
strings are treated as atomic values, not sequences of smaller strings
or characters. A classic example is flatten(), where most people are
surprised if flatten([1, (3.14, 'hello')]) returns [1, 3.14, 'h', 'e',
'l', 'l', 'o'].
> Thing is, the fact that you can e.g. slice strings just like other
> sequence types creates the consequence that you can also iterate over
> strings -- moreover, some of us actually do iterate over strings (though
> of course we could if necessary create lists/tuples of characters). In
> the grand scheme of things, I rarely see people running into problems
> with iterating over strings.
One class of problems is functions such as flatten() that expect "a
collection or an atom", with strings being typically considered
atomic. A second common pitfall are functions that expect file-like
objects but are given file names instead:
def process_file(input_file):
for line in input_file:
do_stuff(line)
process_file('/home/george/.bashrc') # oops
I now try to remember to write such functions as:
def process_file(input_file):
if isinstance(input_file, basestring):
input_file = open(input_file)
for line in input_file:
...
It's not a huge impediment by any means but it's certainly a gotcha.
George
Michele Simionato
> Josiah Carlson wrote:
> > Mark Carter wrote:
> >> Not that I'm particularly knowledgeable about language design issues,
> >> but maybe closures and slightly different scoping rules would be nice.
>
> > Python has had closures for years.
>
> and was amazed to discover that you were right. Nice one.
I am not sure why you posted that link. Closures have nothing to do
with lambda
functions (if lambdas were removed, Python would have closures still)
and it is
shows idioms which are now deprecated or that have better alternative
using
list or generator-expressions, generators, and the itertools module.
So my advice
is to forget about that link and to read the standard library more ;)
Michele Simionato
Klaas
> Allowing a trailing ! in method names has no such cost, because in no
> language I know is ! used as a "postfix unary operator"; the gain in the
> convention "mutators end with !" is not huge, but substantial. So, the
> tradeoffs are different: small pain, substantial gain == not a bad idea.
>
> However, this is all quite theoretical, because no more PEPs will be
> accepted for Python 3000, so any language change like this would have to
> wait for Python 4000, which is no doubt quite a distant prospect:-).
Would it? If it isn't backwards-incompatible, it could even go in 2.6
-Mike
Aahz
George Sakkis <george...@gmail.com> wrote:
>On Jun 2, 4:58 pm, a...@pythoncraft.com (Aahz) wrote:
>> In article <1180807432.351720.123...@p47g2000hsd.googlegroups.com>,
>> George Sakkis <george.sak...@gmail.com> wrote:
>>>
>>>- Strings being iterable; unfortunately this will stay in Py3K.
>>
>> I'll repeat the comment I made on python-3000:
>>
>> "...string iteration isn't about treating strings as sequences of
>> strings, it's about treating strings as sequences of characters. The
>> fact that characters are also strings is the reason we have problems,
>> but characters are strings for other good reasons."
>
>No, the reason we have problems is that far more often than not
>strings are treated as atomic values, not sequences of smaller strings
>or characters. A classic example is flatten(), where most people are
>surprised if flatten([1, (3.14, 'hello')]) returns [1, 3.14, 'h', 'e',
>'l', 'l', 'o'].
Enh. That's not my experience -- the ability to slice, dice, and
concatenate strings is intrinsic to their usefulness.
>> Thing is, the fact that you can e.g. slice strings just like other
>> sequence types creates the consequence that you can also iterate over
>> strings -- moreover, some of us actually do iterate over strings (though
>> of course we could if necessary create lists/tuples of characters). In
>> the grand scheme of things, I rarely see people running into problems
>> with iterating over strings.
>
>One class of problems is functions such as flatten() that expect "a
>collection or an atom", with strings being typically considered
>atomic. A second common pitfall are functions that expect file-like
>objects but are given file names instead:
>
>def process_file(input_file):
> for line in input_file:
> do_stuff(line)
>
>process_file('/home/george/.bashrc') # oops
That's a problem, yes, and it has oddly enough gotten worse since
iterators were introduced into Python. Nevertheless, I have yet to see
anyone suggest a mechanism for fixing this particular gotcha without
creating more problems. Strings are just too useful as sequences.
Moreover, my experience is that these kinds of problems don't show up
all that frequently in practice.
Carl Banks
> Allowing a trailing ! in method names has no such cost, because in no
> language I know is ! used as a "postfix unary operator";
Some math oriented languages use it as the factorial function. E.g.,
Mathematica:
In[1] := 10!
Out[1]= 3628800
(The more you know....)
Carl Banks