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

[Mike Meyer]

"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?

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

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.

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

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

>> BTW, I think "large and stable" would have been less offensive than
>> "fat and happy", but perhaps you meant to imply we're both lazy and
>> complacent, rather than just satisfied with something that works and
>> not inclined to shoot for moving targets every working day.  If so,
>> I'm not sure why you'd say that, since the evidence doesn't support
>> 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 >.

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

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

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