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

[John Roth]

"Mike Meyer" <mwm at mired.org> wrote in message 
news:86br4avf5t.fsf at bhuda.mired.org...
> "John Roth" <newsgroups at jhrothjr.com> writes:
>> However. I see nothing in the existing Python 3000 PEP that does
>> anything other than inspire a yawn. Sure, it's a bunch of cleanup, and
>> some of it is definitely needed.
>
> Actually, that's pretty much *all* it is. I always figured it was a
> warning about things that were liable to break, rather than a list of
> new features that Python 3000 would incorporate.
>
> For those - well, if a change won't break existing code, why put it
> off until Python 3000? I don't think I've seen *any* new features
> proposed for Python 3000. It's to far in the future, so new features
> are proposed in such a way that don't break current code. Interfaces
> come to mind.
>
>> 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

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


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

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.

> What I do see are a couple of collection methods (find and inject)
> that would maken nice additions to the language. I've already posted a
> suggestion to add them.
>
>> 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.

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

You've got the horse harnessed backwards. The jihad against
the "functional" operators was being conducted long before
list comprehensions were in sight. The first action on that was
to replace apply() with the * and ** notations in function/method
definitions and calls.

Guido has said (Python  Regrets) that he regrets ever
allowing them into the language. It's a jihad.


>
>> It seems to be completely irrational from my
>> viewpoint. I've seen the arguements, and they
>> make no sense.
>
> They make perfect sense to me. Either you like there's only one way
> (obvious) to do it, or you don't.

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.

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

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

You might, by the way, find it equally amusing to look at
what your arguements are supporting rather than just sniping
at whatever happens to attract your attention.

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

John Roth


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