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]

Miklós wrote:

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.

--
Jarek Zgoda
http://jpa.berlios.de/

[Michael Hudson]

Jarek Zgoda <jz****@gazeta.usun.pl> writes:

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

--
Monte Carlo sampling is no way to understand code.
-- Gordon McMillan, comp.lang.python

[Miklós]

"Jarek Zgoda" <jz****@gazeta.usun.pl> wrote in message
news:cf**********@nemesis.news.tpi.pl...

Miklós wrote:

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.

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://jpa.berlios.de/

[Jarek Zgoda]

Michael Hudson wrote:

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/

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.

--
Jarek Zgoda
http://jpa.berlios.de/

[Michael Hudson]

Jarek Zgoda <jz****@gazeta.usun.pl> writes:

Michael Hudson wrote:

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/

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

--
ARTHUR: Why should he want to know where his towel is?
FORD: Everybody should know where his towel is.
ARTHUR: I think your head's come undone.
-- The Hitch-Hikers Guide to the Galaxy, Episode 7

[Hans Nowak]

Jarek Zgoda wrote:

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.

--
Hans Nowak (ha**@zephyrfalcon.org)
http://zephyrfalcon.org/

[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]

Istvan Albert <ia*****@mailblocks.com> writes:

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.

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

--
7. It is easier to write an incorrect program than understand a
correct one.
-- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html

[Jarek Zgoda]

Hans Nowak <ha**@zephyrfalcon.org> pisze:

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.

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.

--
Jarek Zgoda
http://jpa.berlios.de/

[Tim Peters]

[Jarek Zgoda]

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] 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>.

[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/pat...ry/013946.html

Istvan.

[Jarek Zgoda]

Tim Peters <ti********@gmail.com> pisze:

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?

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).

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>.

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.

--
Jarek Zgoda
http://jpa.berlios.de/

[A.M. Kuchling]

On Sat, 7 Aug 2004 22:20:31 +0200,
Miklós <no****@nowhere.hu> wrote:

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]

"Michael Hudson" <mw*@python.net> wrote in message
news:m3************@pc150.maths.bris.ac.uk...

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

Cheers,
mwh

--
7. It is easier to write an incorrect program than understand a
correct one.
-- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html

[Miklós]

"A.M. Kuchling" <am*@amk.ca> wrote in message
news:rt********************@speakeasy.net...

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]

> On Sat, 7 Aug 2004 22:20:31 +0200,

Miklós <no****@nowhere.hu> wrote:

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

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.


--amk

[Neil Hodgson]

mu**@vex.net:

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-De...reading.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/pyt...st/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" == Jarek Zgoda <jz****@gazeta.usun.pl> writes:

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.

--
Ville Vainio http://tinyurl.com/2prnb

[A.M. Kuchling]

On Sat, 7 Aug 2004 20:18:00 -0400 (EDT),
mu**@vex.net <mu**@vex.net> wrote:

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

[A.M. Kuchling]

On Sun, 8 Aug 2004 01:21:31 +0200,
Miklós <no****@nowhere.hu> wrote:

So do you say "them and us", Python developers vs. users?
I've always had the "we all"-feeling. Maybe that's over.

That's always been the case, between people who contribute (in time, money,
skills) and people who don't, for whatever reason. The saving grace is that
it's very easy to become a developer; just write some code, help with
development, and all of a sudden you're a developer.

--amk

[Istvan Albert]

A.M. Kuchling wrote:

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?

I think one of the latent messages of this thread was that adding
new "gratuitous" features to the core language is a bad thing.

Just because someone sits down and codes it does not mean it
should be added to the language. Features are forever, you
cannot just can't eliminate them in the next version.

Why putter around with banalities like sorted() and reversed()
that only add to the cognitive overhead, break the consistency
in dealing with lists yet save at most a line or two of
coding? And what you imply here, that the fact of
having decorators works for PyObjC was considered in
the overall decision feels like putting the cart before
the horse.

Python is said to come with the batteries included, then
that's where new features should go, to the battery level
not into the wiring.

Istvan.

[Xavier Combelle]

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 don't agree with the comparison. Programming may be error prone, but
can you suggest something
to replace it? In the other side, there is different way to avoid
threads: make a heavy process, doing a
single event loop. You should have a really special and hard work to use
them routinely.

[Dominic]

> threads: make a heavy process, doing a

single event loop.

Well, often chaining generators is good enough!

Another -- probably not so good solution is to
do an interface specification and generate
code with it. "Active Tasks" could be
automatically _inverted_ , depending on your choice.
Michael Jackson (hee, not the singer) has
done this in the 70s in COBOL. Maybe
you have heard of JSD or JSP ;-)
(JSP (Jackson Structured Programming) and
JSD (Jackson System Development))
In JSD you model entities as processes. (CSP)
(Yes it is OOP analysis ;-) )
Afterwards you map processes too processors.
Probably you have only one, so all
processes but one must be inverted.
However a scheduler solution is
also possible.

Maybe someone comes up with a @decorator
solution, which does invert active
tasks on the fly :-)

Ciao,
Dominic

[Dominic]

Yes, I'm thorougly annoyed with creeping featurism.

Well, you need not use them in your own code.
Define and enforce a subset like it is common in ADA.

However I am not sure myself were decorators will
takes us, they'll certainly(?) have a major influence.
Maybe it is a bit like generator-introduction.
They seemed strange at first and now I think
they are natural and help to simplify coding patterns.

Some postings about @decorators remind me of that
old farmer who only eats stuff he knows already.
Ciao,
Dominic

[Anthony Baxter]

On Sun, 08 Aug 2004 00:00:25 -0400, Istvan Albert
<ia*****@mailblocks.com> wrote:

Just because someone sits down and codes it does not mean it
should be added to the language. Features are forever, you
cannot just can't eliminate them in the next version.

The discussion on decorators has been going on for over 2 years
on python-dev. There is a broad concensus that they're a useful
feature, and are not _just_ being added for PyObjC.

As far as "fixing" the GIL - well, no-one on Python-Dev has obviously
found it to be a problem for them. I certainly can't recall a time in the
last 5 years where the GIL has been a problem in any application I've
written (including a number of heavily threaded applications). Coding
threaded applications in Python does require _knowledge_ of the GIL,
true, but there's nearly always ways to get around it.

As a couple of people have said already - if it's truly a problem for you,
you're able to do something about it. Either look into how it could be
fixed, or hell, pay someone else to work on it for you. No-one is going
to work on something merely because you assert that it is important.
Heck, put together a decent case for _why_ it is a problem.

Greg's free-threading patches for Python 1.4 were there for years.
The interest in them was so low that no-one was even interested
in keeping them up-to-date with current Python (which would have
been a much smaller task than writing them from scratch).

One final point is that with the various new implementations of
Python (Jython, IronPython, Python-on-Parrot, Python-on-smalltalk-VM,
Python-on-Scheme-VM) it's quite possible that one or more of
these new implementations won't have the GIL. You might look into
one of these implementations, and if it looks good to you, contribute!

This is not saying "fix it yourself". This is saying "the people who
work on Python, in their own spare time (almost no-one is paid
to hack on Python) don't consider that the GIL is an issue for
them". You can't just say "fix it!" and expect volunteers to do the
work for you.

Anthony

[Miklós]

"Dominic" <no****@nospam.no> wrote in message
news:cf**********@news.uni-kl.de...

Yes, I'm thorougly annoyed with creeping featurism. Well, you need not use them in your own code.
Define and enforce a subset like it is common in ADA.

I've got a faint idea that this "subset" approach greatly contributes to the
unpopularity of Ada.
Once a core feature is in place, you just cannot insulate yourself from
that.
Some postings about @decorators remind me of that
old farmer who only eats stuff he knows already.
And perhaps he might stay healthy longer than that young one who eats each
and every new nutriment and colourful shiny berries. <wink>

Cheers,
Miklós


Ciao,
Dominic

[Harald Massa]

Ville,

just to add some:

I guess this depends on the developer. I can't help lovin' stuff like
genexps that are coming in 2.4,

yeah, I am really looking forward to them. List comprehensions are a so
natural way to express some situations, and with the additional elegance
of "not having to lock memory" it will be even more phantastic.

Also ... the sets module, introduced with 2.3, I think. It is SO natural
- many, many problems can be formulated within sets-algebra (find all
customers who have X and Y ... just get the intersections of two sets).
And with 2.4 sets will be a builtin, that shows me the commitment of the
Python community that they will be supported for EVEN longer than the
usual many years of a stdlib module.

And: the decimals data type. When working in the financial industry, it
is UNBELIEVABLE PHANTASTIC to finally get a feature that helped COBOL
live THROUGH AGES. (while being the MOST UGLY chick on the block, COBOL
allways had VERY WEALTHY boy friends - not being cool, but having a big
car, big house...) - and now Python will be ONE OF THE FIRST really sexy
chicks of programming languages that will have a DECIMAL type!!

Than: datetime, introduced with 2.3. Yes, there was mx.datetime before.
Who has read a DBAPI-Database-Driver? "try: import mx.datetime ...
except: print some wired error" --- with datetime in the standard lib
there is no longer a need to download additional modules just to print
nice dates. GREAT!!!

I do not understand at all what's that decorators thingy, but I know that
girls often put some deco into flats and it really looks cosy after, so I
assume that decorators are not on the dark side of the source.

Maybe we should ask for a ternary decorator, because I learned that
"ternary" and "decorator" triggers high emotions within the Python
community.

I often struggle with encodings - and in growing versions of Python you
can see that also Python does sth. more with encodings - allowing unicode
in more and more places, growing "string types" instead , putting
Encoding-Tags within source code. That's a healty relationship with a
language, I feel, when the language and me are struggling with the same
problems.

So: I am really looking forward to Python 2.4, decorated or not, I will
take it.

Harald

[Ronald Oussoren]

On 8-aug-04, at 10:16, Anthony Baxter wrote:

On Sun, 08 Aug 2004 00:00:25 -0400, Istvan Albert
<ia*****@mailblocks.com> wrote:

Just because someone sits down and codes it does not mean it
should be added to the language. Features are forever, you
cannot just can't eliminate them in the next version.

The discussion on decorators has been going on for over 2 years
on python-dev. There is a broad concensus that they're a useful
feature, and are not _just_ being added for PyObjC.

I sure hope not :-)[*]. I just happened to dumb enough to volunteer a
use-case for decorators in the last round of discussions, and somehow
this got misunderstood :-(

I do believe decorators are generally useful, as shown by various
examples shown on python-dev. The also happen to make live easier for
users of PyObjC.

Ronald
[*] I'm one of the primairy developers for PyObjC, don't interpreted
this a "-1" for decorators.

[Miklós]

"Harald Massa" <cp*********@spamgourmet.com> wrote in message
news:Xn*********************************@195.20.22 4.116...

Ville,
I do not understand at all what's that decorators thingy, but I know that
girls often put some deco into flats and it really looks cosy after, so I
assume that decorators are not on the dark side of the source.
The rest of the novelties in v2.4 are more or less fine with me, too.
But IMHO decorators are exactly Dark Code Wader stuff. Basically it's about
self-modifying code.
Maybe we should ask for a ternary decorator, Great stuff for my original sarcastic post. :)

Cheers,
Miklós
Harald

[Robin Becker]

Miklós wrote:

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

......

I'm not exactly against 'decorators' although it seems to me thay should
be called 'transformers' as it seems they act to transform the following
function definition.

On the other hand the proposed syntax is abominable.

Additionally there now seems to be at least two 'one and only obvious'
ways to handle these transformations.

@classmethod
def meth(...):
...

or
def meth(...):
...
meth = classmethod(meth)
As a final silliness (or perhaps miracle) this can apparently all be
done in python using code from PJ Eby so a standard decorate mechanism
could have gone into the library while the Gods argue.

Decision by exhaustion is surely not a good recipe.
--
Robin Becker

[Harald Massa]

Miklós,

I do not understand at all what's that decorators thingy, but I know
that girls often put some deco into flats and it really looks cosy
after, so I assume that decorators are not on the dark side of the
source.

The rest of the novelties in v2.4 are more or less fine with me, too.
But IMHO decorators are exactly Dark Code Wader stuff. Basically it's
about self-modifying code.

So you are suggesting that THE SOURCE it is strong with this young padawan?
But I'm sure considered carefully the BDFL has before giving in, hasn't he?

I honestly ask that someone could explain to the less enlightened like me
what this decorator thingy really is. What does it make a correct step on
the path to enlightenment?

Harald

[Anthony Baxter]

On Sun, 08 Aug 2004 12:10:15 +0100, Robin Becker
<ro***@spamremovejessikat.fsnet.co.uk> wrote:

As a final silliness (or perhaps miracle) this can apparently all be
done in python using code from PJ Eby so a standard decorate mechanism
could have gone into the library while the Gods argue.
PJE's implementation is pretty nasty. There's no way that would go into
a released version of Python. Guido's also said that he's not happy with
the approach.
Decision by exhaustion is surely not a good recipe.

It might be approaching exhaustion after the last few days, but before
then, it was more decision-by-exhaustive-argument. After 2+ years of
discussion, and no concensus, eventually it comes down to Guido to
decide which way feels best.

[Xavier Combelle]

As far as "fixing" the GIL - well, no-one on Python-Dev has obviously
found it to be a problem for them. I certainly can't recall a time in the
last 5 years where the GIL has been a problem in any application I've
written (including a number of heavily threaded applications). Coding
threaded applications in Python does require _knowledge_ of the GIL,
true, but there's nearly always ways to get around it.

For information is there some internet resources to understand what
exactly the GIL is about ?

[Anthony Baxter]

On Sun, 08 Aug 2004 14:57:12 +0200, Xavier Combelle
<xa*************@free.fr> wrote:

For information is there some internet resources to understand what
exactly the GIL is about ?

Plenty - try this google search:
http://www.google.com/search?q=site%...python.org+GIL
for a couple of simple ones, but there's plenty more - google for
"python GIL" (or "python free-threading" for patches that were
written against Python 1.4 to remove the single lock. They ended
up slowing down Python significantly.

Note that much has been written about the GIL. Much of the stuff
I've seen has been from people who obviously don't understand
it, but fear it anyway.

Anthony

[Dominic]

> I've got a faint idea that this "subset" approach greatly contributes to the

unpopularity of Ada. Well, this may be true. I do not know.
I have read some papers about the SPARK ADA subset.
It has been chosen so that they can prove
certain properties and be happy with most compilers.
For safety critical or embedded applications ADA
is not too bad. It is probably more often used
in this field than Python.
Maybe this can be changed for better.. ;-)
And perhaps he might stay healthy longer than that young one who eats each
and every new nutriment and colourful shiny berries. <wink>

Yes, there is some truth in here.
I knew you were going to write that. ;-)

Nikolaus Wirth must have had such an attitude
when he designed Oberon.
Aesthetically Oberon is a very fine language.
However if you peek into Oberon source
code you will often see that they have
used linked lists and rewritten the
code everywhere. Because they do not
have _generics_ and casting seems not
popular among Oberon programmers.
Purity comes with a price tag.

Nevertheless, I think Python has been
pretty feature complete and I am not
sure if @decorators are good or bad.
The addition of generators though
has helped me a lot.
I'll have to trust the Python
language designers since
nobody seems to have actual data
to support or discard @decorators.
As far as I know they are part
of C# and Java (recently).
Maybe some experience and data
has been gathered by them.

Ciao,
Dominic

[Miklós]

"Dominic" <no****@nomail.nomail> wrote in message
news:cf**********@news.uni-kl.de...

And perhaps he might stay healthy longer than that young one who eats each and every new nutriment and colourful shiny berries. <wink> Yes, there is some truth in here.
I knew you were going to write that. ;-)

Sure thing I wrote that. :-)
Nevertheless, I think Python has been
pretty feature complete and I am not
sure if @decorators are good or bad.
Decorators, the way things are now, will IMHO actively entice people to
abuse code.
A flawed analogy is computed goto's. We all know by now that 'goto' is evil
;-) but computed goto's (albeit made code flow 'more powerful')
only worsened reading the spaghetti code which results in the usage of
goto's.
As far as I know they are part
of C# and Java (recently).
Maybe some experience and data
has been gathered by them.
Dunno anything about C# but Java decorators are not that 'dynamic'. And IMHO
this is a good thing in this case.

Cheers,
Miklós

Ciao,
Dominic

[Arthur]

On Sun, 8 Aug 2004 16:14:09 +0200, "Miklós" <no****@nowhere.hu> wrote:

Decorators, the way things are now, will IMHO actively entice people to
abuse code.

Undoubtedly we will begin to see the decorator equivalent of the
3-tier architecture embedded in a list comprehension that one comes
across from time to time.

Though I find it hard to get too upset about the addition of a feature
that accommodates a portion of the community, and that can be safely
ignored in writing one's own code if it serves no needs of one's own.

And while I guess that could be said of most, if not all new features
that have caused controversy, I somehow see this feature more
modularized and offset than the others.

Perhaps the fact that it is so appraently unPythonic is what
modularizes it effectly enough to be considered non-infectious.

One hopes.

Art

[Xavier Combelle]

Thank you for the address.this page is especially clear
I am quite agree with you.

Anthony Baxter wrote:

On Sun, 08 Aug 2004 14:57:12 +0200, Xavier Combelle
<xa*************@free.fr> wrote:

For information is there some internet resources to understand what
exactly the GIL is about ?
Plenty - try this google search:
http://www.google.com/search?q=site%...python.org+GIL
for a couple of simple ones, but there's plenty more - google for
"python GIL" (or "python free-threading" for patches that were
written against Python 1.4 to remove the single lock. They ended
up slowing down Python significantly.

That is not really surprizing, the GIL is a very simple and very
efficient way to manage
multithreading. After reading, I can't undersand that other interpreted
languages don't do the same.
The use of GIL make that interpreter work as a single thread process.
Note that much has been written about the GIL. Much of the stuff
I've seen has been from people who obviously don't understand
it, but fear it anyway.
Why fear it ? There is no really problems: from a performance point of
view, it's a very light way
to limit the overhead of mutltithreading.. From developper point of
view, it seems to be just
a constraint to write C code which access to Python. Moreover, just
blocking IO, or code
wich do a lot of computing seems to worry about it. For blocking IO, I
wonder, if the main part
si not used by the development team of python and for long computing
task, a different heavy
process seems be better design. I am certainly wrong, but I don't see where.
Anthony

[G. S. Hayes]

mu**@vex.net wrote in message news:<ma**************************************@pyt hon.org>...

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,
Java has drunk the threads Kool-Aid, and Java programmers are very
likely to be thread-crazy because of the lack of a select equivalent
(until recently) and the lack of good access to processes via fork or
similar. Luckily, it's usually pretty easy to convince people of the
benefits of NOT overusing threads once they've made that mistake once.

I honestly think a big reason the GIL isn't a major issue to most
Pythonistas is because they tend to know that there's a better way to
approach most problems than using threads.
Isn't that like saying, I avoid programming in general because it's error-prone? I don't follow.

Not really. You need to program to get things done, but presumably
you leverage all the work that's been done over the past 40+ years to
make that an easier, less error-prone task. It's like saying you
shouldn't program in assembly because it's error prone; sure, there
are some cases where it makes sense, but in general it's not a great
idea.

Threads are error-prone because they intentionally circumvent the
years of OS work that went into getting protected memory for us in the
first place. Even for tasks that aren't neatly divided into an event
loop, processes are available for parallel execution. 99% of the time
they're a better choice _except_ that two of the most dominant
programming platforms out there don't have a good (efficient and
featureful) implementation (Java and Windows). It's absolutely insane
that many Windows programmers believe that to use parallel processing
requires you throw out memory protection; the two concepts are very
distantly related. The decision to use threads vs. processes ought to
come down to whether you want to share ALL memory (and deal with the
locking and reentrancy issues that come along with that choice) or
only a specified subset of memory. When you view it from that
perspective, threads are only rarely the right choice.

Indeed, in all the years that I've been writing code I've never once
found a problem where I felt threads were the right approach--and that
includes work on high-performance servers with thousands of concurrent
users, large-scale data visualization applications that depend on the
results of many parallel searches, and realtime audio processing
applications with non-realtime visualization and UI components.
That's not to say there aren't limited problem domains where threads
are the right answer, but as a general construct they're wildly
overused. I'm frankly glad that Python doesn't encourage more of the
same.

[mudd]

> That's not to say there aren't limited problem domains where threads

are the right answer, but as a general construct they're wildly
overused. I'm frankly glad that Python doesn't encourage more of the
same.

Is there anything else that Python doesn't do well that we should appreciate?

[Anthony Baxter]

On Sun, 8 Aug 2004 22:18:45 -0400 (EDT), mu**@vex.net <mu**@vex.net> wrote:

Is there anything else that Python doesn't do well that we should appreciate?

I wouldn't go so far as to say that we should _appreciate_ the GIL, more that
it ends up being not so much of a problem because Python gives us many,
many better ways to do things than with threads.

About the only actual issue with the GIL is that it stops a single
Python interpreter
from taking better advantage of multiple CPUs in a box. But, if you code with a
knowledge of the GIL, this is easy enough to work around.

The advantages of the GIL is that the implementation is far more robust, and far
less overhead is wasted in lots of tiny little locks. In addition, it
means that a single
python instruction is guaranteed to be thread safe - so in a threaded app I can
do something like
somedict['foo'] = 1
without having to wrap access in a lock to make sure I don't end up with a
hosed dictionary. Once you end up with lots of little locks in a threaded
application, madness is surely not far away.

Anthony

[G. S. Hayes]

mu**@vex.net wrote in message news:<ma**************************************@pyt hon.org>...

That's not to say there aren't limited problem domains where threads are the right answer, but as a general construct they're wildly overused. I'm frankly glad that Python doesn't encourage more of the same.

Is there anything else that Python doesn't do well that we should appreciate?

That wasn't really the point; the point was more to argue against the
viewpoint that work on language features like list comprehensions or
decorators is somehow less important than working on removing the GIL.
Obviously in an ideal world you could implement every idea that came
along, but in the real world developers tend to work on problems that
affect them--and if you have a bunch of developers who rarely run into
problems with the GIL (because they're not often abusing threads) then
it's just not going to be a very high priority. Rightly so, IMO,
since it only affects a very small percentage of well-designed
programs, so putting work into bigger problem areas (especially any
language features that genuinely improve development speed and
readability) gets a much higher payoff.

I wouldn't be against removing the GIL if an approach was found that
didn't adversely affect the common case; naive approaches to
fine-grained locking are often really bad for general case behavior,
but there are approaches that can mitigate this. But I would be
against lobbying core language developers to take time off of other
projects to work on this one; it's definitely more of a "scratch an
itch" type problem` that can wait until someone feels motivated to do
it than a "suck it up because the community needs it" kind of thing.

[Christian Tismer]

Harald Massa wrote:

Miklós,

I do not understand at all what's that decorators thingy, but I know
that girls often put some deco into flats and it really looks cosy
after, so I assume that decorators are not on the dark side of the
source.

The rest of the novelties in v2.4 are more or less fine with me, too.
But IMHO decorators are exactly Dark Code Wader stuff. Basically it's
about self-modifying code.

Ooh, this is truely too much fear. Decorators are about
modification of how code is understood, but not modification.
[ If it were so, then I'd be probably much more interested :-) ]
I honestly ask that someone could explain to the less enlightened like me
what this decorator thingy really is. What does it make a correct step on
the path to enlightenment?

Here a very short and very incomplete explainment of what
a decorator is. FOr a more complete explanation, please
refer to the PEP, or even wade through python-dev.
I also just give one simple example, there are lots of
other uses for decorators.
But since probably more than 95 percent of Python code will
not need decorators in the near future, just one example
should be enough to just don't let you worry about what
the Voodoo is.

Something many Python programmers even don't know about are
class methods and static methods.

A static method is simply a method which is defined in a class,
but that does not operate on self. The self variable is not
supplied. A static method is not supposed to be a method of an
instance. It is just sitting in a class for convenience, but
behaves like an ordinary function.

There is a more advanced concept: a class method. Instead of self
or nothing, it always receives the class as first parameter.
But please read the docstring of the classmethod function.
We will stick with the simple static method, here.

Until Python 2.3, it was necessary to "declare" a static method
by calling the function staticmethod on it.

Sample code:

class MyClass(object):

def func(arg1, arg2):
return arg1 + arg2

func = classmethod(func)

What can you see here?
The "def func" lacks a self parameter. You want to call it
with the two parameters arg1 and arg2, but without the
extra line
func = classmethod(func)

you would get this result:
Trying to call func via the class gives you

MyClass.func(2, 3) Traceback (most recent call last):
File "<interactive input>", line 1, in ?
TypeError: unbound method func() must be called with MyClass instance as
first argument (got int instance instead)
Trying to call func via an instance also doesn't work:
inst = MyClass()
inst.func(2, 3) Traceback (most recent call last):
File "<interactive input>", line 1, in ?
TypeError: func() takes exactly 2 arguments (3 given)
Now, with the mentioned extra line, the function object is
modified in a way that it understands that it is an ordinary
function, and it works in both cases:
class MyClass(object): .... def func(arg1, arg2):
.... return arg1 + arg2
.... func=staticmethod(func)
.... MyClass.func(2, 3) 5 inst = MyClass()
inst.func(2, 3) 5

--- now finally on the decorator issue ---

What you have see is, that staticmethod has to be called *after*
the function is defined. The modified function is assigned to
the class as a post process.
For very long functions, this can become cumbersome.
Not only that you have to type the function name three times,
you also have to scroll through the full function definition,
possibly even through the rest of the whole class definition,
to see whther the function is modified somehow.

One of the purposes of decorators is now to overcome this
problem, and to annotate the function earlier than at its end.
There are many proposals how to do this, also with extended
functionality. But I'll reduce the example to the currently
proposed syntax:

class MyClass(object):

@classmethod

def func(arg1, arg2):
return arg1 + arg2
This is the basic idea what a decorator does:
Make modifiers like classmethod into a prefix
of a function.
I know this description is incomplete, but I beg those who
know better _not_ to respond and prove their knowledge.
I wanted to give a simple idea. Corrections are welcome, of course.
Everything else is documented in PEP318.

ciao - chris

--
Christian Tismer :^) <mailto:ti****@stackless.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work [phone] home [phone] mobile [phone]
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/

[Robin Becker]

Christian Tismer wrote:

........

Trying to call func via an instance also doesn't work:

>>> inst = MyClass()
>>> inst.func(2, 3) Traceback (most recent call last):
File "<interactive input>", line 1, in ?
TypeError: func() takes exactly 2 arguments (3 given) >>>
Now, with the mentioned extra line, the function object is
modified in a way that it understands that it is an ordinary
function, and it works in both cases:
>>> class MyClass(object): ... def func(arg1, arg2):
... return arg1 + arg2
... func=staticmethod(func)
... >>> MyClass.func(2, 3) 5 >>> inst = MyClass()
>>> inst.func(2, 3) 5 >>>

Isn't robustness an issue with the @ decorator as well? The most important
symbol can be omitted without causing a syntax error, but I suppose the same can
be argued for any of the unary operations.
--
Robin Becker

[Miklós]

"Christian Tismer" <ti****@stackless.com> wrote in message
news:ma**************************************@pyth on.org...

Ooh, this is truely too much fear. Decorators are about
modification of how code is understood, but not modification.
[ If it were so, then I'd be probably much more interested :-) ]
[..snip..]
Now, with the mentioned extra line, the function object is
modified in a way that it understands that it is an ordinary
function, and it works in both cases:
[..snip..] What you have see is, that staticmethod has to be called *after*
the function is defined. The modified function is assigned to
the class as a post process. [..snip..] to see whther the function is modified somehow. [..snip..] This is the basic idea what a decorator does:
Make modifiers like classmethod into a prefix
of a function.
Great, so it's still about code modification.
With Python decorators, a method/function can be modified virtually in any
way, outside its declaration.
Sure you could override things before, too, but now this is a request for
code abuse.

Best,
Miklós
--
Christian Tismer :^) <mailto:ti****@stackless.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work [phone] home [phone] mobile [phone]
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/

[Christian Tismer]

Miklós wrote:

....

This is the basic idea what a decorator does:
Make modifiers like classmethod into a prefix
of a function.

Great, so it's still about code modification.

No, this is, with respect, nonsense.
With Python decorators, a method/function can be modified virtually in any
way, outside its declaration.
No. You cannot do anything that could not be done
without decorators, before (at least today).
Sure you could override things before, too, but now this is a request for
code abuse.

My explanation was *not* meant as a request for list abuse.

--
Christian Tismer :^) <mailto:ti****@stackless.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work [phone] home [phone] mobile [phone]
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/

[Michael Ekstrand]

On Saturday 07 August 2004 16:19, Jarek Zgoda wrote:

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.

Perhaps I am unique among Python users. But I've always welcomed the new
features Python has introduced in recent times, especially the
new-style class stuff in 2.3.

Perhaps it is because my programing paradigm is intensely theoretical,
with a lot of thought put towards purity of model. But it seems that
the features the "Python developers" are adding increase Python's
theoretical beauty, and hence make life easier for me as a user. Except
for when I'm stuck needing to code for pre-2.3 Python. Or coding with
Zope, where I feel that my hands are tied because I can't use some new
features.

-Michael

[Donn Cave]

In article <41***********************@news.free.fr>,
Xavier Combelle <xa*************@yahoo.fr> wrote:

Anthony Baxter wrote:

On Sun, 08 Aug 2004 14:57:12 +0200, Xavier Combelle
<xa*************@free.fr> wrote: ....Plenty - try this google search:
http://www.google.com/search?q=site%...python.org+GIL
for a couple of simple ones, but there's plenty more - google for
"python GIL" (or "python free-threading" for patches that were
written against Python 1.4 to remove the single lock. They ended
up slowing down Python significantly.

That is not really surprizing, the GIL is a very simple and very
efficient way to manage
multithreading. After reading, I can't undersand that other interpreted
languages don't do the same.
The use of GIL make that interpreter work as a single thread process.

Right, and other languages do indeed do the same, for
example I believe ocaml has a global lock - even though
compiled to native code, it has the same kind of shared
global state for storage and so forth.

It is very effective, and it works fine for the kinds
of things people usually do today with threads. If the
computer of the future makes many processors available
for concurrent processing, it won't work quite so well
for that, but who knows what will happen.

I'm not sure if I followed the rest of your post, but
note that Python's thread architecture works well with
blocking I/O. It just depends on the native code module
that actually posts the I/O request to release the lock
first, and recover it afterwards, so any other threads
that may be waiting can be scheduled. On the other hand,
there are often better ways to deal with blocking I/O
than threads.

Donn Cave, do**@u.washington.edu

[Jarek Zgoda]

G. S. Hayes <sj*******@yahoo.com> pisze:

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,

Java has drunk the threads Kool-Aid, and Java programmers are very
likely to be thread-crazy because of the lack of a select equivalent
(until recently) and the lack of good access to processes via fork or
similar. Luckily, it's usually pretty easy to convince people of the
benefits of NOT overusing threads once they've made that mistake once.

Try GUI programming without using threads.

--
Jarek Zgoda
http://jpa.berlios.de/