Going the PL/1 way

[Miklós]

Ok, seems like we have @decorators. It's a nice tribute to Intercal. But
I'd prefer #decorators.

We have metaclasses for pleasure brain-melting. We have generators,
new-style classes and old-style classes. Lambdas are wonderful.
We do need real interfaces, not abused classes. Python still needs to have
inlined functions, macros and templates. Operator overloading is not enough,
one should be able to introduce new ones freely. There's a heavy demand for
terciary comparisons. Why don't we have a 'case' statement and 'do... repeat
()'?
We cannot do without general closures, of course. Hm, automatic garbage
collection is sometimes fine but explicite memory allocation/deallocation is
really unavoidable for efficient programs.
Wait, pointers are a must! Static typing should have been introduced a long
time ago. You just cannot do without absolute address variables.

Yes, I'm thorougly annoyed with creeping featurism.

Miklós

 

[Jarek Zgoda]

Ok, seems like we have @decorators. It's a nice tribute to Intercal. But
I'd prefer #decorators.

We have metaclasses for pleasure brain-melting. We have generators,
new-style classes and old-style classes. Lambdas are wonderful.
We do need real interfaces, not abused classes. Python still needs to have
inlined functions, macros and templates. Operator overloading is not enough,
one should be able to introduce new ones freely. There's a heavy demand for
terciary comparisons. Why don't we have a 'case' statement and 'do... repeat
()'?
We cannot do without general closures, of course. Hm, automatic garbage
collection is sometimes fine but explicite memory allocation/deallocation is
really unavoidable for efficient programs.
Wait, pointers are a must! Static typing should have been introduced a long
time ago. You just cannot do without absolute address variables.

Yes, I'm thorougly annoyed with creeping featurism.

Man, you steal my thoughts!

Most of features that made into Python after 2.1 are "just that", like
"nobody has it, so we should" or "somebody has it, so we would too". The
only thing I welcomed in 2.3 was some interpreter speedup, not new features.

Is it really so much needed feature, that "clean, compact and readable"
rule should be broken? Damn, to hell with decorators, noone I know even
knows what it can be good for.

Come on, guys, fix real problems like interpreter thread safety, improve
performance, don't make us, "real-world software developers", screaming
with every new release, please.

 

[Michael Hudson]

Come on, guys, fix real problems like interpreter thread safety,
improve performance, don't make us, "real-world software
developers", screaming with every new release, please.

http://www.python.org/patches/

Cheers,
mwh

 

[Miklós]

Man, you steal my thoughts!

Most of features that made into Python after 2.1 are "just that", like
"nobody has it, so we should" or "somebody has it, so we would too". The
only thing I welcomed in 2.3 was some interpreter speedup, not new features.

Is it really so much needed feature, that "clean, compact and readable"
rule should be broken? Damn, to hell with decorators, noone I know even
knows what it can be good for.

Come on, guys, fix real problems like interpreter thread safety, improve
performance, don't make us, "real-world software developers", screaming
with every new release, please.

Yes, this was exactly my point. Performance and GIL. Those are problems.
And problems must be solved. After that add features... if they are really
needed.

Miklós

 

[Jarek Zgoda]

http://www.python.org/patches/

You want to say "if you want any improvement, do it yourself"? Sure,
it's much better than Java's JCP, but expect
http://catb.org/~esr/jargon/html/F/fork.html if enough people will share
the same annoyance and anger.

I write some free software, but I never tell users "go fix it yourself".
This is rude.

 

[Michael Hudson]

You want to say "if you want any improvement, do it yourself"? Sure,
it's much better than Java's JCP, but expect
http://catb.org/~esr/jargon/html/F/fork.html if enough people will
share the same annoyance and anger.

It's possible.

I write some free software, but I never tell users "go fix it
yourself". This is rude.

Yes, probably. But so were you, so can we call it quits?

Cheers,
mwh

 

[Hans Nowak]

You want to say "if you want any improvement, do it yourself"? Sure,
it's much better than Java's JCP, but expect
http://catb.org/~esr/jargon/html/F/fork.html if enough people will share
the same annoyance and anger.

I may hem and haw whenever a new feature is added that I consider redundant (as
everybody reading my weblog knows well , but I would never support a fork.

 

[Istvan Albert]

Miklós wrote:

Yes, this was exactly my point. Performance and GIL. Those are problems.
And problems must be solved. After that add features... if they are really
needed.

nah,

first we need to attend to pressing needs, such as replacing

my_list.reverse()
for item in my_list:
...

with the incomparably more pythonic:

for item in reversed(my_list):
...

and at the same time, we need to replace the ridiculous:

my_list.sort()
for item in my_list:
...

with:

for item in my_list.sorted():
...

note the consistency in 'sort' and 'reverse' and the lack of
that in the usage of sorted and reversed.

Istvan.

 

[Michael Hudson]

Miklós wrote:



nah,

first we need to attend to pressing needs, such as replacing

my_list.reverse()
for item in my_list:
...

with the incomparably more pythonic:

for item in reversed(my_list):
...

and at the same time, we need to replace the ridiculous:

my_list.sort()
for item in my_list:
...

with:

for item in my_list.sorted():
...

note the consistency in 'sort' and 'reverse' and the lack of
that in the usage of sorted and reversed.

Which you've made up: sorted is a builtin in 2.4.

By all means carp about the new features, but -- particularly if
you're going to be sarcastic about it -- please get it right.

Cheers,
mwh

 

[Tim Peters]

[Jarek Zgoda]
[Michael Hudson]

http://www.python.org/patches/

[Jarek]
You want to say "if you want any improvement, do it yourself"? Sure,
it's much better than Java's JCP, but expect
http://catb.org/~esr/jargon/html/F/fork.html if enough people will share
the same annoyance and anger.

I don't understand. If you believe that nobody is volunteering work
on things you want them to work on now (which may well be true,
although it's false that volunteers don't contribute work on thread
and performance issues already), how could merely forking Python make
such volunteers appear?

I write some free software, but I never tell users "go fix it yourself".
This is rude.

Under the assumption that volunteers exist who want to work on what
you want them to work on, but that they've somehow managed to miss
Python's patch tracker, Michael was helpfully giving them the one clue
they still needed to make you happy <wink>.

 

[Jarek Zgoda]

I may hem and haw whenever a new feature is added that I consider redundant (as
everybody reading my weblog knows well , but I would never support a fork.

It is first time I felt it's "we and them" world, divided into "Python
developers" and "Python users". They want features. We want stability
and performance.

I would rather use Ruby, than support a Python's fork. Moreover, I don't
think the fork would ever happen.

 

[Istvan Albert]

Michael Hudson wrote:

Which you've made up: sorted is a builtin in 2.4.

By all means carp about the new features, but -- particularly if
you're going to be sarcastic about it -- please get it right.

actually, the last time I read this PEP it was about a classmethod
list.sorted()

http://mail.python.org/pipermail/patches/2004-January/013946.html

Istvan.

 

[Jarek Zgoda]

I don't understand. If you believe that nobody is volunteering work
on things you want them to work on now (which may well be true,
although it's false that volunteers don't contribute work on thread
and performance issues already), how could merely forking Python make
such volunteers appear?

Sorry, I am biased, we have "PLD Linux Distribution" in here in Poland,
where forks are considered as "development model".

Generally, I see adding features a more desired attitude in developer's
community than simple fixing problems and this is my point (and I think
Miklos's too).

Under the assumption that volunteers exist who want to work on what
you want them to work on, but that they've somehow managed to miss
Python's patch tracker, Michael was helpfully giving them the one clue
they still needed to make you happy <wink>.

I didn't submit any patch to Python. I even don't know how to improve
Python. I just use Python in my daily work and I go into the same
problems as others get.

 

[A.M. Kuchling]

Yes, this was exactly my point. Performance and GIL. Those are problems.
And problems must be solved.

Problems for who? I have no problems with Python's performance in my
applications. I avoid threads because they're error-prone, so the GIL
doesn't affect me.

Free software projects are run by the people who actually contribute code.
If sorted() and reversed() were added, it's because Raymond Hettinger
actually wrote code to implement them, and GvR didn't dislike them. If
people who want decorators are willing to expend effort to implement them,
test them, conform to the coding standard, then they can be considered for
inclusion. So, if you want to see the GIL fixed, or performance
improvements made, you have to work on these problems.

--amk

 

[Miklós]

Which you've made up: sorted is a builtin in 2.4.

By all means carp about the new features, but -- particularly if
you're going to be sarcastic about it -- please get it right.

It was me, Miklós, who was sarcastic about the feature frenzy and it was
István who brought up .sort() and .reverse()
Sorry, that's two different persons, albeit apparently both Hungarians.

Cheers,
Miklós

 

[Miklós]

Free software projects are run by the people who actually contribute code.
If sorted() and reversed() were added, it's because Raymond Hettinger
actually wrote code to implement them, and GvR didn't dislike them. If
people who want decorators are willing to expend effort to implement them,
test them, conform to the coding standard, then they can be considered for
inclusion. So, if you want to see the GIL fixed, or performance
improvements made, you have to work on these problems.

--amk

So do you say "them and us", Python developers vs. users?
I've always had the "we all"-feeling. Maybe that's over.
I neither have the technical knowledge or the slightest inclination to wade
through tons of C codes,
I've been using Python because it's simple, clean and still very powerful.
I am unhappy to see that Python becomes cryptic, complex but more powerful.

Cheers,
Miklós

 

[mudd]

Yes, this was exactly my point. Performance and GIL. Those are problems.
And problems must be solved.

Problems for who?[/QUOTE]

Me, for one.

Yes, I can code around the GIL. I do that routinely. It's a pain to keep
working around the GIL. Especially knowing that it's not necessary in
other languages, but it can be done. Sigh.

What really hurts is that I can't honestly tell Java programmers that
Python is a slam dunk compared to Java & the JVM. Java has no GIL,
Python does. Once I admit this, nobody listens to what Python does well.
It's a shame.

I have no problems with Python's performance in my
applications. I avoid threads because they're error-prone,

Isn't that like saying, I avoid programming in general because it's
error-prone? I don't follow.

I agree that threads do introduce an additional level of complexity. But
so does programming multi-user applications versus single-user apps. But
I've never heard programmers routinely say that they avoid multi-user apps
because they're "error-prone".

But isn't the GIL on the way out already? Jython offers access to the
non-GIL threads of the JVM. I always use Java threads when working with
Jython. That's great! I suppose Iron Python will do the same with CLR.
And one of the main reasons for the Prothon project (the mythical "Python
fork"?) is the elimination of the GIL. It sound like alternatives are on
the way. But what's the future of Python?

so the GIL
doesn't affect me.

but, but... no programmer is an island?

Free software projects are run by the people who actually contribute code.
If sorted() and reversed() were added, it's because Raymond Hettinger
actually wrote code to implement them, and GvR didn't dislike them. If
people who want decorators are willing to expend effort to implement them,
test them, conform to the coding standard, then they can be considered for
inclusion. So, if you want to see the GIL fixed, or performance
improvements made, you have to work on these problems.

I'm guessing the GIL is beyond any of us. If it was easy, or even
possible, someone would have already eliminated it.

 

[Neil Hodgson]

(e-mail address removed):

I'm guessing the GIL is beyond any of us. If it was easy, or even
possible, someone would have already eliminated it.

Greg Stein did produce a free threading version of Python.
http://python.tpnet.pl/contrib-09-Dec-1999/System/threading.README
It performed much slower than GIL based Python, at something like 60% of
the GIL version with one processor. This is the expected result when
replacing a large scale lock with many finer grained locks: there is more
locking overhead. It is possible that techniques can be found to reduce the
free threading cost so it would be great for people to continue working on
this.
http://mail.python.org/pipermail/python-dev/2001-August/017099.html
The barrier to keeping this code in standard Python as an option is the
amount of maintenance effort it represents both for itself and its impact on
the GIL version.

Neil

 

[Ville Vainio]

Jarek> Most of features that made into Python after 2.1 are "just
Jarek> that", like "nobody has it, so we should" or "somebody has
Jarek> it, so we would too". The only thing I welcomed in 2.3 was
Jarek> some interpreter speedup, not new features.

No way, Python 2.2 was the best thing to happen to Python so far.

Jarek> Come on, guys, fix real problems like interpreter thread
Jarek> safety, improve performance, don't make us, "real-world
Jarek> software developers", screaming with every new release,
Jarek> please.

I guess this depends on the developer. I can't help lovin' stuff like
genexps that are coming in 2.4, while I would harly notice GIL
extermination. It's something that looks important on paper and will
surely help advocacy efforts, but probably wouldn't have significant
impact on the day-to-day lives of the developers. In the meantime, I
don't mind the efforts to shorten that already small gap between the
algorithm in my brain and what's on the editor screen.

I guess this is my feeble attempt to thank the core Python developers
that get all too much flak considering the good job they do. That's
probably how open source works when people care deeply about the
project .

Then again, it's 5am in Finland and I'm still moderately drunk.

 

[A.M. Kuchling]

But isn't the GIL on the way out already? Jython offers access to the
non-GIL threads of the JVM. I always use Java threads when working with
Jython.

Perhaps. That depends on Jython continuing to be developed; if that's of
importance to you, you can help with Jython development or send money to
Samuele Pedroni or assist in other ways.

My basic point is that the features added to projects are those that people
are willing to actually work on. In the case of decorators, some people
wanted decorators, for the sake of PyObjC or ctypes or whatever, and Mark
Russell actually sat down and implemented it. (Because he uses PyObjC?
Because he thought it would be an entertaining task? Whatever the reason,
it did get done.) Decorators weren't added because of some theoretical goal;
they were added because some people wanted them, and because some people
cared enough to implement them.

The only way the GIL or performance will be changed is if someone cares
enough to work on them; so far, apparently no one does.

--amk