Python evolution: Unease

[Iwan van der Kleyn]

Please ignore if you are allergic to ramblings :-)

Despite a puritan streak I've always tried to refrain from language wars
or syntax bickering; call it enforced pragmatism. That's the main reason
why I've liked Python: it's elegant and simple and still dynamic and
flexible. You could do worse for a clean and pragmatic language.

I do know my Smaltalk from my Common Lisp and my Ruby from my C#, so I
think I'm quite capable of escaping the "Blub paradox"
http://c2.com/cgi/wiki?BlubParadox. I do miss some slick features in
Python. But the nice thing about Python is that in those cases I can use
its dynamism to implement it myself (and usually somebody else has done
it for me, of course).

In the end I'm not a language guru nor a framework wizard, but a mere
mortal who designs and writes programs for end-users. For that task I
need: a better standard ide, an integrated db interface with a proper
set of db drivers (!!), a better debugger, a standard widget/windows
toolkit, something akin to a standard for web programming, better
documentation, a standard lib which is better organized, a formalized
set of protocols and patterns for program construction. And an
interpreter which is fast enough to avoid using C or Pyrex in most
obvious cases.

Many will say that Van Rossum's brainstorms/proposals as depicted in

http://www.artima.com/weblogs/viewpost.jsp?thread=86641

will help in the above mentioned. And I'm certainly not against Optional
ype checking.

But I see little to no efforts from the core python team to address my
needs as listed above. They seem mainly to focus on the core attributes
and syntax of the language. Very little or no efforts are taken to
improve the infrastructure around the language.

And then I read the following sentence by Van Rossum:

"In order to make type inferencing a little more useful, I'd like to
restrict certain forms of extreme dynamic behavior in Python"

In the end, it's mindset which counts. And I think that mindset is going
to be determine the way foreward for Python: more features, increased
complexity, less dynamism. Lots of syntax crud, without addressing the
need to improve the infrastructure around the language.

In short: I symphatize Patrick Logan's feeling:

http://patricklogan.blogspot.com/2005/01/road-to-ruin.html

Regards,

Iwan van der Kleyn

[flamesrock]

Re: Python evolution: Unease

Well, I'm not a seasoned programmer like you but I have to say Python
is the singlebest language I've worked with to date. In a matter of
weeks I learned to do things that took me months in other languages and
even found the process enjoyable.

Maybe you are right. If so, couldn't Python be forked into something
like you describe, while still remaining compatible at the core? (if
anyones willing)

Python++ anyone?

[Paul Rubin]

Re: Python evolution: Unease

"flamesrock " <flamesrock@gma il.com> writes:[color=blue]
> Maybe you are right. If so, couldn't Python be forked into something
> like you describe, while still remaining compatible at the core? (if
> anyones willing)[/color]

It's not an issue with the Python core (language); I read that post as
mostly bemoaning the poor state of the runtime library. I feel the
same concerns, however, fixing it is a lot of work.

[michele.simionato@gmail.com]

Re: Python evolution: Unease

Maybe a PSF grant would help? I guess this has been considered ...
Michele Simionato

[Alex Martelli]

Re: Python evolution: Unease

Iwan van der Kleyn <none@none.ne t> wrote:
[color=blue]
> to be determine the way foreward for Python: more features, increased
> complexity, less dynamism. Lots of syntax crud, without addressing the[/color]

As a student of human nature, I'm _really_ curious as to how one could
possibly read the key document:

http://www.python.org/peps/pep-3000.html

and think in consequence of "more features, increased complexity".

Also, you keep talking about "the core python team" on the basis, it
would appear, of reading one document by Guido. Have you bothered doing
a MINIMUM of homework, such as, looking at

http://www.amk.ca/diary/archives/cat_python.html

and specifically AMK's entry for September 30? I'm trying to understand
whether you completely missed doing the most elementary amount of
background searching before venting on the group, or if you did find and
read the obvious documents and somehow STILL manage to completely ignore
their contents or read them as saying exactly the opposite of what they
_do_ say...


Alex

[Iwan van der Kleyn]

Re: Python evolution: Unease

[color=blue]
> Also, you keep talking about "the core python team" on the basis, it
> would appear, of reading one document by Guido. Have you bothered doing
> a MINIMUM of homework, such as, looking at
> http://www.amk.ca/diary/archives/cat_python.html[/color]

Well, you being a member of that core team (meaning nog an
organisational unit, but the group of people doing the really hard job,
getting Python to work. An excellent job at that :-) I can repect you
if not branding me a lamer at least admonishing me for not coming up
with a thorough factual statement. But like I stated: "ramblings" , remember.

I'm not completely unknown with the workings of our species myself,
though. Especially when discourse and policy is dictated by a select
group of people (meaning: the one who actually create python, no
criticism there) with final abritary powers for one indidual (again, no
criticism), mindset *is* just as important as stated fact. Mindset will
dictate future discourse and action.

And I do sense (reading planet python/this newsgroup) a mindset or at
least a tendency by the people who really matter in these discussion to
keep on adding features to the syntax; to add "structure" to Python. My
personal preference would be to leave the language alone for a while and
to improve its infrastructure.

Regards,
Iwan

[Ville Vainio]

Re: Python evolution: Unease

>>>>> "Iwan" == Iwan van der Kleyn <none@none.ne t> writes:

Iwan> And then I read the following sentence by Van Rossum:

Iwan> "In order to make type inferencing a little more useful, I'd
Iwan> like to restrict certain forms of extreme dynamic behavior
Iwan> in Python"

Iwan> In the end, it's mindset which counts. And I think that
Iwan> mindset is going to be determine the way foreward for
Iwan> Python: more features, increased complexity, less
Iwan> dynamism. Lots of syntax crud, without addressing the need
Iwan> to improve the infrastructure around the language.

What form of extreme dynamic behaviour have you been using lately? Do
you really think it's more worthwhile than the benefits provided by
type inference, least of which isn't the ability by IDEs to provide
you accurate code completion.

Also, Python is not a monolithic entity. Guido certainly isn't going
to write a better IDE for Python, so the time used on language
features isn't removed from improving the infrastructure around the
language.

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

[Paul Rubin]

Re: Python evolution: Unease

Ville Vainio <ville@spammers .com> writes:[color=blue]
> Also, Python is not a monolithic entity. Guido certainly isn't going
> to write a better IDE for Python, so the time used on language
> features isn't removed from improving the infrastructure around the
> language.[/color]

There aren't THAT many people working on Python. Any time spent on
feature X does tend to divert resources from feature Y.

I think there should be a moratorium on nontrivial language changes
(as opposed to library improvements) until PyPy is fully deployed.
Too much of Python as we know it today is shaped by the weirdness of
CPython. We ought to be able to get away from that.

[Ville Vainio]

Re: Python evolution: Unease

>>>>> "Paul" == Paul Rubin <http://phr.cx@NOSPAM.i nvalid> writes:

Paul> Ville Vainio <ville@spammers .com> writes:
[color=blue][color=green]
>> Also, Python is not a monolithic entity. Guido certainly isn't
>> going to write a better IDE for Python, so the time used on
>> language features isn't removed from improving the
>> infrastructure around the language.[/color][/color]

Paul> There aren't THAT many people working on Python. Any time
Paul> spent on feature X does tend to divert resources from
Paul> feature Y.

But the people working on wxPython, pygtk, pyqt, pydev, whatever, are
largely not the same guys that commit stuff to CPython CVS.

Paul> fully deployed. Too much of Python as we know it today is
Paul> shaped by the weirdness of CPython. We ought to be able to
Paul> get away from that.

Type declarations are a feature that might benefit IronPython and
Jython more than they would CPython.

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

[Paul Rubin]

Re: Python evolution: Unease

Ville Vainio <ville@spammers .com> writes:[color=blue]
> But the people working on wxPython, pygtk, pyqt, pydev, whatever, are
> largely not the same guys that commit stuff to CPython CVS.[/color]

Right, but for that reason, they don't count as being working on
Python.
[color=blue]
> Type declarations are a feature that might benefit IronPython and
> Jython more than they would CPython.[/color]

CPython seems to be what drives quite a few language design decisions.

[Istvan Albert]

Re: Python evolution: Unease

Iwan van der Kleyn wrote:
[color=blue]
> And I do sense (reading planet python/this newsgroup) a mindset or at
> least a tendency by the people who really matter in these discussion to
> keep on adding features to the syntax; to add "structure" to Python. My
> personal preference would be to leave the language alone for a while and
> to improve its infrastructure.[/color]

In all honesty this:

http://www.artima.com/weblogs/viewpost.jsp?thread=86641

scares me too. Reminds me of Larry Wall's writings on Perl 6
that make me tune out fairly quickly. I don't have the kind of
problems that the these features will solve so I can't relate
to them at all.

But others might do. Especially when using python in an environment
where enforcing a strict contract is important. But if python
were to become overly complicated I'll find something else.
Three years ago I have not not used python at all, now I'm
using it for everything.

Languages should evolve with time, adapt to the needs
of its users. Sometimes that means that in some areas
it might feel worse. But it could also mean that the
problem is with us, so it would be unfair to spend effort
towards holding back this evolution just because
we don't need it.

Istvan.

PS. why can't decorators solve this optional type checking
problem? I clearly remember this as being one of the
selling points for having decorators in the first place...

[Aahz]

Re: Python evolution: Unease

In article <1104831798.408 560.228940@c13g 2000cwb.googleg roups.com>,
<michele.simion ato@gmail.com> wrote:[color=blue]
>
>Maybe a PSF grant would help? I guess this has been considered ...[/color]

The first three PSF grants were all in some way not directly related to
changing the core language. One was for a library, one for improving
Jython, and one for improving docs. Giving the PSF more money increases
the chances for additional work.
--
Aahz (aahz@pythoncra ft.com) <*> http://www.pythoncraft.com/

"19. A language that doesn't affect the way you think about programming,
is not worth knowing." --Alan Perlis

[michele.simionato@gmail.com]

Re: Python evolution: Unease

Aahz:
[color=blue]
> The first three PSF grants were all in some way not directly related[/color]
to[color=blue]
> changing the core language. One was for a library, one for improving
> Jython, and one for improving docs. Giving the PSF more money[/color]
increases[color=blue]
> the chances for additional work.[/color]

Here is the link you forgot to post ;-)

http://www.python.org/psf/grants/

The one about the docs seems more about teaching scientists how to use
Python.

Michele Simionato

[Michael Hobbs]

Re: Python evolution: Unease

Ville Vainio <ville@spammers .com> wrote:[color=blue]
> What form of extreme dynamic behaviour have you been using lately?[/color]

One real-world example: in my new coverage analysis tool (to be
released any month now), I need to trace threads without changing any
code. To do so, I redefine the thread.start_ne w_thread() function from
outside the thread module, like so:


orig_start_new_ thread = thread.start_ne w_thread

def traced_start_ne w_thread(func, args, kwargs={}):
return orig_start_new_ thread(traced_f unc_call, (func, args, kwargs))

def traced_func_cal l(func, args, kwargs):
sys.settrace(my _trace_func)
func(*args, **kwargs)

thread.start_ne w_thread = traced_start_ne w_thread


Granted, doing something like this on a regular basis is really bad
coding style, but the ability to do something like this when I really
need it is what I love about Python.

[Doug Holton]

Re: Python evolution: Unease

Istvan Albert wrote:[color=blue]
> But if python
> were to become overly complicated I'll find something else.
> Three years ago I have not not used python at all, now I'm
> using it for everything.[/color]

You're in luck, python 2.4 won't be significantly changing anytime soon.
[color=blue]
> PS. why can't decorators solve this optional type checking
> problem? I clearly remember this as being one of the
> selling points for having decorators in the first place...[/color]

Because they are quite obviously an ugly and overly complicated
solution. Even Guido understood this:

http://mail.python.org/pipermail/python-dev/2004-September/048518.html

"A warning: some people have shown examples of extreme uses of
decorators. I've seen decorators proposed for argument and return type
annotations, and even one that used a decorator to create an object
that did a regular expression substitution. Those uses are cute, but I
recommend being conservative when deciding between using a decorator
or some other approach, especially in code that will see a large
audience (like 3rd party library packages). Using decorators for type
annotations in particular looks tedious, and this particular
application is so important that I expect Python 3000 will have
optional type declarations integrated into the argument list."