[Michael]
> > > Generators are cool once you understand them, but they raise the bar
> > > for someone new to the language.
[Guido]
> > That all depends. You don't have to teach generators at all in an
> > introductory course -- you don't even have to teach iterators. But
> > all this has been discussed many times before here in numerous
> > threads.
[Mark]
> Not true. I don't think people on python-dev are in touch
> with the impacts of their changes on the Python learning curve.
>
> In every organization, there will be both advanced programmers
> and beginners. And in every organization, there will be at least
> one advanced programmer who will discover and use the new
> cool features, and thus impose them upon everyone else.
>
> Trust me on this. I've met these people; hell, I used to be one
> of these people :-). The fact is, today, some of the most common
> questions I get in Python classes have to do with new things like
> list comprehensions and generators, regardless of class makeup.
>
> I don't have time to argue the merits of adding new features in the
> first place. But please, let's not be naive about their impact on
> the perceived simplicity of Python. Like it or not, beginners do
> need to know about new things, even if they will not be coding them.
>
> And like it or not, Python has indeed lost much of the simplicity that
> attracted some. There's always been a dichotomy of people who want
> to keep it simple, and people who want to add new features. After
> just updating Learning Python, it's pretty obvious that the latter group
> has won the tug of war in recent years. Try explaining the current 3
> flavors of division to a beginner sometime and you'll see what I mean.
Thanks for the reality check!
One of the problems with "improving" a complex software system is
that, no matter how hard you try, it's nearly impossible to take away
thing, so that when a new solution for an old issue is added, the old
solution stays around.
The division operator is a case in point: in Python 3.0, there will
only be two division operators: floor division and true division.
Arguably, this is no more complex than the situation before // was
introduced: while there was only one division operator, there were two
kinds of semantics that one had to learn and watch out for. (I assure
you we've all been bitten by this more than once. Most recently, I
saw it on the review page of a certain conference, in the calculation
of the average score of submitted papers. [*]) But the transitional
situation has the union of the old and the new world, and hence is
more messy than either.
There's also the tension between making the language simpler (to
learn) and making programs simpler (to read). For example, *if* (and
that's still a very big if) we were to add a language feature that
would let you write
synchronized(lock):
BLOCK
instead of
lock.aqcuire()
try:
BLOCK
finally:
lock.release()
I assure you that this makes programs that use locks more readable,
which reduces maintenance costs down the road. But at the same time
we can't hope to reduce every idiom to a single statement, and we must
be careful not to destroy the language by adding too many "neat
tricks".
It's a delicate balance, and the occasional reality check from the
field is much appreciated.
_____
[*] In 3.0, you'll have to remember that if you want integer division,
you must write // instead of /. But the problems caused by writing /
where you intended // are usually immediately obvious (often the
program won't even run, if the resulting float is used as an index
somewhere); while the problems caused by silent truncation of int/int
are often only discovered by careful checking of actual results with
expected results.
--Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4