Is there no end to Python?

[Kamilche]

I have been programming in Python for years, and I'm STILL learning new
features about the language.

I'm looking for the best way to handle events with my own UI developed
in PyGame, and I've programmed up 4 ways to do it so far, and have a
couple more waiting to be done! Python is so amazingly flexible, it
will happily accommodate whatever I manage to spew forth as my event
handling system.

It really fires the imagination. In other languages, I was lucky if I
could think of 2 ways... most of the time, there was only one. The
languages were so rigid, they blinkered your thinking.

 

[John Salerno]

in PyGame, and I've programmed up 4 ways to do it so far, and have a
couple more waiting to be done! Python is so amazingly flexible, it
will happily accommodate whatever I manage to spew forth as my event
handling system.

It really fires the imagination. In other languages, I was lucky if I
could think of 2 ways... most of the time, there was only one. The
languages were so rigid, they blinkered your thinking.

But isn't Python sort of known for the opposite, i.e. 'one simple way',
or something to that effect?



John --> still learning the definiton of Pythonic

 

[Kamilche]

Because Python doesn't take as many CPU cycles in your brain, it spares
more time for 'big picture' ideas, such as the event handling framework
I'm working on.

 

[Mark Warburton]

But isn't Python sort of known for the opposite, i.e. 'one simple way',
or something to that effect?

Ha! I was thinking the same thing. But then I realized this only
applies at the microscopic level. If you're doing something like
reversing the order of the elements in a list, there aren't many
different ways to do it.

On the other hand, if you're looking at macroscopic task like writing a
flight simulator, there are many many different ways to approach it. A
pythonic language limits you at the microscopic level but not the
macroscopic! This way the code is readable by anyone (including you!)
and you are free to dream up any algorithms you like.

 

[sjmsoft]

But isn't Python sort of known for the opposite, i.e. 'one simple way',
or something to that effect?

The Python language is clear and concise and so I don't think takes
long to learn. But there's so many libraries and packages available
that I'll probably never use more than a fraction of them. This is
good thing because I can ignore what I don't need.

-- Steve J. Martin

 

[kpp9c]

This is good thing because I can ignore what I don't need.

I am finding that this is really not true for me. I find that if i use
other folks code, collaborate, or get help from other folks i still
have to know all the new constructs that i don't often use, and i
really struggle with iterators and generators and some of the newer
things and folks seem to have fallen in love with ridiculously complex
list comprehensions. (i'll admit i love the list comprehensions too,
but too a point)

Don't get me wrong, i LOVE Python, but since 2.2 or so the language has
started to get some feature creep and is starting to evolve
exponentially fast and while all that pre 2.2 code is really readable
still, i see some stuff now that really really hurts my brain. We see
less silly lambdas than we used to, and Python is more powerful than
ever, but i think there has been a cost too. Python has become harder
to read and *MUCH* harder to learn all of a sudden.

Personally i would like to see the core Python language evolve more
slowly and see work on packages, modules and DOCS!!

but i am sure that is very much a minority opinion. I found the
language additions of 2.3 and 2.4 really hard to absorb.

flame away...

-kp--

 

[Steve Holden]

I am finding that this is really not true for me. I find that if i use
other folks code, collaborate, or get help from other folks i still
have to know all the new constructs that i don't often use, and i
really struggle with iterators and generators and some of the newer
things and folks seem to have fallen in love with ridiculously complex
list comprehensions. (i'll admit i love the list comprehensions too,
but too a point)

Don't get me wrong, i LOVE Python, but since 2.2 or so the language has
started to get some feature creep and is starting to evolve
exponentially fast and while all that pre 2.2 code is really readable
still, i see some stuff now that really really hurts my brain. We see
less silly lambdas than we used to, and Python is more powerful than
ever, but i think there has been a cost too. Python has become harder
to read and *MUCH* harder to learn all of a sudden.

Personally i would like to see the core Python language evolve more
slowly and see work on packages, modules and DOCS!!

but i am sure that is very much a minority opinion. I found the
language additions of 2.3 and 2.4 really hard to absorb.

flame away...

No need for flames. I'll content myself with pointing out that most
1.5.2 programs will run unchanged in 2.5, so the backwards compatibility
picture is very good. Nobody makes you use the new features!

regards
Steve

 

[dan]

Steve wrote:

"""No need for flames. I'll content myself with pointing out that most
1.5.2 programs will run unchanged in 2.5, so the backwards
compatibility
picture is very good. Nobody makes you use the new features!""

Nobody makes you use new features, true...unless you are relying on a
library or module that uses them...;-)

cheers,
Dan

 

[Jeffrey Schwab]

kpp9c wrote:

No need for flames. I'll content myself with pointing out that most
1.5.2 programs will run unchanged in 2.5, so the backwards compatibility
picture is very good. Nobody makes you use the new features!

They do if you ever want to read their code. The point of view you've
just summarized is what causes languages to become write-only.

 

[Jeffrey Schwab]

They do if you ever want to read their code. The point of view you've
just summarized is what causes languages to become write-only.

Sorry, that came out a lot ruder than I meant it.

I've always heard that Python was extremely easy to learn. I'm still
fairly new to the language, though (2.2), and I have not found it any
easier to learn than Perl or Ruby. It's great that all these new
features have been added, but if I want power at the expense of
intuitive language constructs, I'll stick to C++.

 

[Georg Brandl]

Steve wrote:

"""No need for flames. I'll content myself with pointing out that most
1.5.2 programs will run unchanged in 2.5, so the backwards
compatibility
picture is very good. Nobody makes you use the new features!""

Nobody makes you use new features, true...unless you are relying on a
library or module that uses them...;-)

Even then, you are unlikely to have to use them in your own code.

E.g. decorators: you can stick with

def xxx():
pass
xxx = decorator(xxx)

Or genexps: you can still write a listcomp.

On the third hand, there haven't been too many new features in the language.
Let's see through whatsnew24:

PEP218 builtin sets: already there as a library in 2.3
PEP237 unifying long/int: not visible to programmers
PEP289 generator expressions: new feature
PEP292 string substitutions: not widely used, you can ignore it
PEP318 decorators: see above
PEP322 reverse iteration: one new builtin, not too much I hope
PEP324 subprocess module: you don't have to used, stick with popen*
PEP327 decimal data type: if you don't need it, you won't use it,
if you need it, you'll have used a library
PEP328 multi-line imports: a matter of parentheses
PEP331 locale-independent float/string conversions: never heard of it myself

Summa summarum, exactly one new syntax, one new builtin and one new stdlib
module to care about.

Georg

 

[Scott David Daniels]

Personally i would like to see the core Python language evolve more
slowly and see work on packages, modules and DOCS!!

This is a common (and silly) whine. effort in a free system is not
fungible. The odds of your affecting how the people doing the work
by complaining about how they do it and their priorities are about
zero to one.

Kind of like the core developers saying, rather than getting more
users of this language, I'd prefer they submit careful bug reports
with money attached to fix the bugs -- ain't gonna happen.

--Scott David Daniels
(e-mail address removed)

 

[Kamilche]

Heheh, that sounds about right. :-D

I personally haven't used the new stuff yet. Maybe I'm not experienced
enough in Python yet to have encountered the need for them. I've played
with them some, but every time I consider using them, something stops
me. What stops me from using 'setattr' (an old feature), is that it
doesn't fire when a person changes an element of a list... not very
intuitive. What stops me from using properties, is seeing how
populating a dict using the update method wipes them out... again, not
intuitive to me. List comprehensions - REALLY unnecessary. Only handy
if you belong to the 'Likes to impress people with small amounts of
arcane code' crowd. Sets - when I played with them, they were slower
than doing the equivalent code with dicts. It's got to be a reliable,
compelling feature, before I'll add it to my arsenal.

 

[kpp9c]

This is a common (and silly) whine.

1. not a whine
2. if it is really common is it all that silly?
fungible. The odds of your affecting how the people doing the work
by complaining about how they do it and their priorities are about
zero to one.


That is true only if my goals were to actually effect a change. if you
read what i wrote it is 1000% clear i don't expect that at all. Just
stating an opinion about how Python has evolved. We've seen a lot of
gains, in terms of power and speed and have lots of new toys, i am just
point out that any new tech comes at a cost, and that this whole "i
don't need to know this thing that has fundamentally changed how the
program works" idea is a flawed. It don't matter that you don't use it,
at some point someone else will and unless you live in a cave, you are
gonna be staring at other folks code scratching your head. I am a
better programmer than before, but i scratch my head a lot more @ 2.4
that i did at 2.0.

oh, well. i knew some one would flame me.

-kp8--

my main point is that new language constructs giveth and new language
constructs also taketh away.

 

[Peter Hansen]

Kind of like the core developers saying, rather than getting more
users of this language, I'd prefer they submit careful bug reports
with money attached to fix the bugs -- ain't gonna happen.

Actually, it does happen: http://www.python.org/psf/donations/

(The actual list doesn't appear to have survived the transition to the
new site, but there really are people who have donated, and sometimes
simply in the hopes it helps get a problem fix, or out of gratitude that
a bug was fixed. And for about N-1 other reasons (where N is how many
people have donated so far)...)

-Peter

 

[Bruno Desthuilliers]

(e-mail address removed) a écrit :

The Python language is clear and concise and so I don't think takes
long to learn.

To learn the "basics", no. To really grasp all you can do with it -
talking about expressivity and black magic -, this takes *much* more
time. Think of all you can do with decorators, descriptors, metaclasses,
closures, etc...

But there's so many libraries and packages available
that I'll probably never use more than a fraction of them. This is
good thing because I can ignore what I don't need.

Well, I found myself reinventing the (square) wheel(tm) so many times -
I wrote a csv package before noticing there was a much better one the
standard lib - that I don't think it would be wise to ignore too much...

Just my 2 cents...

 

[Terry Reedy]

arcane code' crowd. Sets - when I played with them, they were slower
than doing the equivalent code with dicts. It's got to be a reliable,
compelling feature, before I'll add it to my arsenal.

In 2.3, sets was, I believe, a module written in Python on top of the dict
type. In 2.4, set() is a builtin type written in C adapting the C code of
dicts but without the overhead of values, and with set rather than dict
oriented methods.

tjr

 

[Terry Reedy]

Sorry, that came out a lot ruder than I meant it.

There has been much worse here, and even more in other groups...

I've always heard that Python was extremely easy to learn. I'm still
fairly new to the language, though (2.2), and I have not found it any
easier to learn than Perl or Ruby. It's great that all these new
features have been added, but if I want power at the expense of
intuitive language constructs, I'll stick to C++.

Guido is not completely oblivious to complexification versus ease of
learning. The problem at present is that 2.5 will have most of the
additions that have been planned for 3.0 but, for back-compatibility, few
of the deletions and simplifications.
tjr

 

[Magnus Lycka]

But isn't Python sort of known for the opposite, i.e. 'one simple way',
or something to that effect?

If we compare it with the "opposite" language--Perl, and think
of these languages as natural languages, rather than programming
languages, Perl's inventor Larry Wall, felt that having a lot of
synonymns and allowing a lot of flexibility in word order etc,
would make it easier to express one's ideas well.

Python's inventor Guido van Rossum took a different approach. With
fewer synonyms and a less redundant grammer, it will be easier to
master the language, and certainly easier to read texts written by
others.

I don't know, but I suspect that the difference in approach is
rooted in Guido's understanding that we typically spend much more
time reading source code than we spend writing source code.

As it turns out, having fewer synonyms and grammatic variants, does
not make it harder to come up with different solutions to problems.
It rather seems that the lack of complexity that a simpler grammer
leads to makes it much easier to try out different solutions.