«

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/200...d-to-ruin.html








Regards,

Iwan van der Kleyn

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?

"flamesrock" <> writes:
> 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)

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.

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

Iwan van der Kleyn <> wrote:

> to be determine the way foreward for Python: more features, increased
> complexity, less dynamism. Lots of syntax crud, without addressing the

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

> 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

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

>>>>> "Iwan" == Iwan van der Kleyn <> 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

Ville Vainio <> writes:
> 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.

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.

>>>>> "Paul" == Paul Rubin <http://> writes:

Paul> Ville Vainio <> writes:

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

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

Ville Vainio <> writes:
> But the people working on wxPython, pygtk, pyqt, pydev, whatever, are
> largely not the same guys that commit stuff to CPython CVS.

Right, but for that reason, they don't count as being working on
Python.

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

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