Fat and happy Pythonistas (was Re: Replacement for keyword 'global' good idea? ...)

[Mike Meyer]

"John Roth" <newsgroups at jhrothjr.com> writes:
> "Mike Meyer" <mwm at mired.org> wrote in message
>>> What I want to see in Python 3000 is an AST based language
>>> that lets the editors do the pretty printing. Do you want automatic
>>> indenting or would you prefer end statements? It's an editor formatting
>>> option. The AST neither knows or cares. Don't want to see self?
>>> Editor formatting option. The AST knows what scope each
>>> identifier belongs to because it's right there in the text. No need
>>> for rules that you have to learn, sometimes the hard way.
>>
>> I'm not sure what you mean by "AST based language". Google wasn't much
>> help, even in finding a definition for AST - it gets swamped by time
>> zones and company names. I think you mean abstract syntax tree, but
>> I'm not sure how you would go about basing a language on that. Care to
>> provide pointers?
>
> You got it.
>
> http://martinfowler.com/articles/languageWorkbench.html

Um - I see no mention of "AST" in that article at all. He's mostly
talking about "Language Oriented Programming" (seems to be another
term to describe DSLs) and "Language Workbenches".

> This shows one reason _why_ designing a language with the basic
> AST representation as primary may become a big deal. Maybe
> not, too.

This sentence is meaningless without the definition of AST that I
asked for.

>>> Talk to people who've moved from Python to Ruby, or to
>>> some other language. Ask them why, if Python is so great,
>>> what's even greater in that other language. If you still don't
>>> understand, you might want to read this:
>>>
>>> http://martinfowler.com/bliki/CollectionClosureMethod.html
>>
>> I read it. I don't see what the big deal is. He praises collections
>> and closurs. Python has both. Ok, the closures are sucky, but you can
>> fake real one with classes. He likes anonymous blocks. There are a
>> couple of proposals floating around to add those to Python.
>
> There have been proposals to add them to Python for as long as
> I can remember. They have always been shot down. Vigorously.

PEP 343 is marked as accepted.

> The basic issue here is neither the collection methods nor the
> closures. It's a compact yet readable syntax that puts them
> together. That's what one should get out of the Fowler piece:
> how nice it is to be able to do some rather common things
> compactly.
>
> All steps in that direction have always been resisted.

So you're not complaining about missing functionality, you're
complaining about syntactic sugar. That's not really in line with the
rest of your article, which seems to be complaining that python is
missing out on adding important new functionality.

I'd say resisting such changes is pythonic. Signaling that you're
switching from an expression to statements with a magic character is
hardly readable; statements should look like statements, not
expressions.

>>> I find the notion that there should be one obviously right way
>>> to do something to be a good design principle, so why isn't
>>> there a single supported GUI library? If I'm over in Java-land,
>>> just about everything comes with a GUI. Python ships with a
>>> lot of little demonstration and utility scripts - none of which has
>>> a GUI.
>> The standard library documentation only documents one GUI library. The
>> Python distribution includes one *large* example of GUI programming
>> with that library - IDLE. I agree that more examples and documentation
>> would be usefull, but I'm *not* the person to write them.
> And I never suggested you were.

So you're dropping the complaint that Python doesn't have one standard
GUI?

>>> Why the jihad (and I'm using the word advisedly)
>>> against the map, filter and reduce operators?
>> I'd say that LCs and GEs make map and filter redundant, thus violating
>> the principle of there being one obviously right way to do something
>> that you like. Reduce isn't as clear. Maybe we can get it replaced by
>> inject.
> I've already explained that, if you want to invoke "only one way"
> then list and generator comprehensions are the violation since
> there were other ways of doing it.

First you argue that python isn't improving. Now you complain that
improving some things (and thus obsoleting others) is a bad thing.

LCs are clearly superior to map and filter. They replace two builtin
functions with one more readable language construct.

>>> I'm not suggesting shooting at a moving target. I'm suggesting
>>> getting the head out of the sand, looking at trends, and figuring
>>> out the _large_ steps to take next, not the nickle and dime fixups
>>> that are the only things I see in PEP 3000. (Not to say that some
>>> of them aren't going to be a lot of work. Some of them are.)
>> There are some large steps on the horizon. Interfaces (or maybe
>> Abstract Base Classes) are being considered for addition to the
>> language. <URL:
>> http://www.artima.com/weblogs/viewpost.jsp?thread=92662 >.
> He just blogged on that yesterday; I'm going to have to look at
> it in detail. Not something to look at in the middle of composing
> a response. Please note that it's in terms of the Python 3000
> framework, which should be noted in context of your first point
> at the top of this post.

Yup. I goofed - I should have listed them as the only proposal I knew
of for new features to Python 3000.

>>> Another thing that stands out: the explicit versus dynamic typing debate
>>> has moved on from program correctness (which is a wash) to
>>> other areas that explicit (or derived) type information can be used
>>> for. I see this in PyFit: the languages where explicit type information
>>> is available by reflection have cleaner implementations. The languages
>>> with dynamic typing all have to deal with the fact that they can't get
>>> type information by reflection, and it's a diverse mess.
>> There are people who strongly disagree that the programm correctness
>> issue is a wash. If you've got research to back that up, I'd love to
>> see it.
> It seems to be the concensus on this group anyway: declarative typing
> does not give enough improvement in program correctness to override
> more concise programs and TDD. That may,  of course, be wishful
> thinking on the Python community's part.

"The concensus of this group" is a *long* way from "the debate has
moved on". I agree that it's the concensus of this group - but this is
a group devoted to a dynamic programming language. If you go to a
group devoted to a statically typed language, you'll find a different
concensus. Which means the debate is still very much alive.

>>> The world is moving on, in ways that I think you're not seeing.
>>> And Python is standing still in many of those same ways.
>> I find it hilarious that this arrived at my news server the same day
>> that Peter Hansens rant (look for the subject "Syntax error after
>> upgrading to Python 2.4") about Python changing to fast did.
> You may find it hilarious. I find it kind of sad - painting oneself
> into a corner so that upgrades become a pain for the customer
> base is not a laughing matter.

No, it's hilarious because of the old saw that if you're drawing
criticism from both sides of a debate, you must be doing something
right.

> "I don't want it to change too fast" is the same as "Fat and
> happy", just in different words.

So we have one (count him, 1) user who complains that it's changing to
fast. I suspect most readers here would disagree with him.

It seems that your complaint is really that Python isn't going in the
direction you want it to go. The people developing Python are doing
what they think is best for the language. You may think they're
wrong. I know I do at times. Unless we're one of the people doing the
development, our seat on the board is non-voting, so there's not much
we can do beyond complain. If we want a vote, we can work on Python
rather than in Python. In the extreme case, we can secede and become
BDFL of our own variant of Python.

     <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.