Replacement for keyword 'global' good idea? (e.g. 'modulescope' or 'module' better?)

[Christopher Subich]

You've got half of the answer. The other half is to have the editor/ide
translate the lexical cues into color coding and hide the lexical cues.

Yes... let's make color a syntactically important feature of the
language; Python can follow the massive success of colorForth.

There are three principles that together mandate the use of a 'global'
keyword:
1) Implicit variable definition: If all variables had to be declared
ahead of time, then "var x" versus "global var x" wouldn't be an issue
at all. Even though you'd still want to make the latter red and the
former blue or something. Removing this from Python would also forbid
things like locals()['a'] = 1, and it would also have great impact on
the class syntax (namely instance variables).
2) Lexical scoping: If variable references didn't go beyond the
immediate scope, then there would be no global variables and thus no
need for a global keyword. Lexical scoping, though, is a fundamental
feature of Python and every other block-scoping procedural language that
I know of, so no-can-do there.
3) Default local scroping: Changing this, as already pointed out, would
just require replacing a 'global' keyword with a 'local' one. In
procedural languages that derive in spirit from Algol-likes, local
variables are the far more common case than global ones, and so by
Huffman/Morse principles should have the shorter syntax. (As a side
note, the 'local first' assumption isn't universal; see some FORTRAN and
BASICs.)

Personally, I don't consider the global keyword a misfeature or even a
wart; for Py3k I'd rather see more explicit namespacing (which would
make it clear that namespaces end at the module-level) rather than
changing even the name of the keyword.

 

[D H]

I'm not saying 'modulescope' and 'module' are the only alternatives or
even
the best anyone can come up with.

'global' has the connotation of being visible *EVERYWHERE*
where in Python it is just visible in one module's space.

Can you think of a better alternative or do you believe
'global' is the best possible?

When designing a language meant to be easy to use as well as powerful
feature-wise, you have to weighh between things like technical accuracy
of a term (which you are focusing on), how much typing it takes, how
easy it is to remember and spell correctly, and how the term is commonly
understood and used.
Sometimes python takes one of those considerations to the extreme (like
"def") or has a uncommon view of "common understanding" (like "lambda").
But global is the best term I can think of for the way it is used, and
it is by far the most common term used for these kind of variables in
numerous other languages including vb, php, ruby, etc.

 

[Paolino]

(e-mail address removed) wrote:
def enclosing():
var=[]
var[0]=2
def enclosed():
var[0]=4
which is like saying python is not working

It's ok to mark non locals,but why var=4 is not searched outside and
var[0]=4 yes?

Because "var=4" rebinds the name "var", while "var[0]=4" does not. It's
exactly the same issue with using "global", where you don't need it if
you aren't rebinding the name.

(Those who don't understand the difference between "rebinding a name"
and "modifying an object" will need to figure out that distinction
before they can participate much in a discussion about Python scopes, I
think.)

The point is not to understand obvious technical things, but having a
coherent programming framework.If I can modify an out of scope object
(ie var list) without saying it's an 'outer' no problem as python looks
for it, in fact I should put 'outer' to rebind var to 4 if I refer to
'var' as an outer binding, python can find it if it exists, if it
doesn't it can raise an error.

Many other ways to identify the scope layer of a binding can be thought
about:having only 'global' and pretending that is the only useful
namspace layer to be identify for changing its bindings is just a piece
of sense.

Paolino





___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it

 

[Devan L]

Maybe "fat and happy" wasn't the best choice of words (and maybe
Extreme Programming wasn't Kent Beck's best choice of words either.)

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. What I don't see is the inspired leap
forward that will once again put Python in the forefront rather than
simply being one choice among many.

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.

Want to see type inference? I haven't a clue how to do it in a
dynamic language like Python, but an AST based language is a
perfect test bed for experimentation.

What's good about other languages? I see very little here
that is an examination of what Smalltalk, Ruby, Perl, etc.
seem to have gotten right and could be moved into Python
to good effect.

Could you give examples of some of what could be moved into Python to
good effect?

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 don't see the connection between the linked article and this
discussion. Not having methods for doing things that have equivalent,
simple implementations does not make Python left behind.

Look at Pep 8. It's a compendium of coding standards
for the standard library. So far, ok. Coding standards
are generally good. But why does Guido like underscores
in method names? I know there was (and the accent is
on the word was) some research, refuted well over a decade
ago, that mixedCase was hard to read. The fact is that
_all_ conventions for separating words are hard to read
until the brain grows new synapses that handle it. Of the
options, no separation is the hardest to handle. There are
reasons why ancient texts, which had neither word
separators nor punctuation, have very contentious translations.

You don't *have* to follow the convention, but it makes it much easier
for other programmers to read your code.

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.

A GUI is not a critical part of a programming language. You only need a
GUI for end users. Not all programmers make programs for end users.

Part of the tone here is because of the PEP 208 voting
process. From day one, I knew it was going to fail.
Anyone who stood back and looked at the process, rather
than getting into the detail, knew it was going to fail. There
was no way that the Python community was going to come
up with a simple majority in favor of one proposal. None.
And it was obvious from the start.

And the sad fact is that a proposition of the form: "We
want a conditional expression; Guido should pick the
syntax he finds the least obnoxious and get on with it"
would have passed. Overwhelmingly.

I came across a better voting process (Condorcet)
later. Unfortunately it was later or I would have
suggested it.

Why the jihad (and I'm using the word advisedly)
against the map, filter and reduce operators?
It seems to be completely irrational from my
viewpoint. I've seen the arguements, and they
make no sense.

Map and filter are not special. Why have two ways to do the same thing?
Reduce is a special case, but the arguments against map and filter are
quite sensible.

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

I came back from Agile2005 last week. The open space session
on Ruby was maybe 5 times as large as the one on Python. And
both of them were kind of an afterthought. Look at the OSCon
blogs. There were a number of hardcore Python people there.
They couldn't get into Ruby sessions because they were jammed.
Standing room only.

More people does not mean better.

There's a report out that the "scripting languages" in general are
losing mindshare big time in Europe, Africa and the east in general.
In fact, everywhere except in North America. I'm generally somewhat
skeptical of these reports unless I can see the methodology, but it's
definitely a data point.

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.

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.

Take another look then.

-Devan L

 

[Dan Sommers]

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.

s/AST based language/machine code/g

s/Editor formatting option/high level language/g

After all, Lisp, FORTRAN, and Python are nothing more than Stupid Text
Editor Tricks for manipulating my CPU's register file.

Not everyone who would like to write a program has the skills (or the
time) to develop their own high level language in which to do so.

I find the notion that there should be one obviously right way to do
something to be a good design principle ...

This idea is directly at odds with the one above. Your vision for
Python 3000 has as many Right Ways to do everything are there are
permutations of configuration options in the text formatter.

Regards,
Dan

 

[Kay Schluehr]

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.

What makes myself a fat and lazy Pythonista is simply motivated by not
wanting Guido throwing any language feature that someone found
accidentally in another language into Python. My personal attitude is
that I have enough self-confidence that I can live with just the second
most popular programming language in the world. And maybe I'm also fat
because I like to feed myself ( my topics of interest ) and not people
with consumerist attitudes.

So you have recognized that dynamic languages don't support type
reflections well. Surprise, surpise! Other wellinformed authors like
Benjamin Pierce wouldn't even agree about Python as being typed but
dynamically *tagged*. Now what do you recommend? Sacrificing
__delattr__, __setattr__, decorators and metaclasses for having
colorcoding editors and a Java-like language with indentation syntax?
What do you believe to ensure with type-declarations extracted by tools
in presence of magic methods that enable to rewrite your class on the
fly? Of course some things become harder in Python because they are
impossible to guarantee in general. The PyPy team spends a lot of
effort in exploring the boundary between what can be inferred from
Python code and translated into lower level languages before program
execution and what has to be passed to some code specializer at
runtime. That's where new insights about dynamic languages may come
from.

Kay

PS. I don't have anything against Ruby. May it have many cheerleaders!
It's just that Haskell is on top of my list of interesting PLs I didn't
devote much time yet and Ruby is far away.

 

[Dennis Lee Bieber]

The point is not to understand obvious technical things, but having a
coherent programming framework.If I can modify an out of scope object

Seems coherent to me:

a) names /BIND/ locally unless declared global (at which point they
bind within the file)

b) name /lookup/ is local first, then global

c) conflict occurs when a name lookup potentially could find a
global [clause b: name not found in local space, found in global], but
later in the same function that same name is bound locally [clause a: no
global declaration was seen so binding is to a local]. However, the
static language parse will have flagged the name as reserved for a
local, and then complains because one is attempting to use a local
before it has been bound to a value.

If you aren't changing the binding of the name, you don't need
to worry about "global"

And, in Python, this concept of BINDING is a core language
feature -- it is NOT something compatible to other languages, and
removing it will mean creating a new language that is NOT Python.

In other languages, a "name" is a synonym for a memory address
(call it a box), and it will always be the same box. Assignment copies
box contents from source to destination box.

In Python, a "name" is a movable label that is stuck to a box,
and the name can be moved to other boxes. "Assignment" in Python moves
the label from the "destination" (the old box) TO the "source" box --
the source box now has multiple labels (names) bound to it. Both names
refer to the same box.

var is a two step process: first find the box with the label
"var", THEN open the box and find the i'th item /in/ the box... You can
change the item /in/ the box without changing the label on the box.

--

 

[Mike Meyer]

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.

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

 

[Terry Reedy]

(e-mail address removed) wrote:
I don't think the global keyword is useful actually.
What's so special in a module nemespace to be priviledged like that.

The specialness of globals and locals was part of Python's original simple
namespace design, and is still reflected in exec statements and eval
functions, as well as in nested functions.

The point IMO is accessing names defined somewhere in the enclosing
namespaces.

Accessing such names is already possible, even *after* the outer function
returns and the rest of its execution context is deleted.

def enclosing():
var=2
def enclosed():
outer var=4

This is rebinding, rather than merely accessing. Similar, but even more
problematical would be initial binding in outer from inner:

def enclosing():
def enclosed():
outer var = 4

this is the base of something useful.

Actually, it is the reinvention of classes:

class enclosing(object):
def __init__(self):
self.var = 2
def enclosed(self):
self.var = 4

There was a long discussion on the pydev list a couple of years ago re
adding rebinding in addition to access (of outer variables). I think, in
the end, Guido concluded that there was no compelling reason, as of then,
to add another general mechanism for private, sharable, rebindable
variables.

I think there is only one or none possible solution to an outer statement

There were lots of proposals for both the exact syntax and semantics of
outer binding/rebinding.

Terry J. Reedy

 

[Paul Rubin]

> I've heard 2 people complain that word 'global' is confusing.
> Perhaps 'modulescope' or 'module' would be better?
> Am I the first peope to have thought of this and suggested it?
> Is this a candidate for Python 3000 yet?

It's not just the word that's confusing, Python's scoping system is
just a mess. I hope that Python 3000 fixes it, but who knows.

 

[Terry Reedy]

Maybe "fat and happy" wasn't the best choice of words

Depends on the reaction you wanted ;-)

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. What I don't see is the inspired leap
forward that will once again put Python in the forefront rather than
simply being one choice among many.

My response is more than a yawn, but yes, the most exciting thing that I
see is completion of the generator revolution started a few years ago.

What I want to see in Python 3000 is an AST based language [much more
snipped]

I presume you mean AST as in human-comprehension oriented AST as in
http://docs.python.org/lib/module-compiler.ast.html.

If I understand correctly, you are proposing that the essence of a Python
program be its logical tree structure rather than its surface presentation.
And this would be understood even if the developers also promoted a
particular presentation as the 'preferred', 'official', or 'commonly
shared' presentation. And this might include a tree serialization format
different from the presentation test format.

Yes, this is an interesting idea. Perhaps, if you can flesh it out a bit
and leave out stuff like 'fat and happy', you could write and submit a PEP.

Some of the developers are trying to finish the AST compiler before 2.5.
If this means what I think it does, compiling ASTs direct to bytecode, it
would be an essential component of your proposal and make it more possible.
But I don't know much more about it.

I also know little about what intermediate forms PyPy used to compile
Python code.

Terry J. Reedy

 

[Peter Hansen]

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.

?? Which rant was that? I posted only one message in that thread, and
it wasn't a rant (according to my definition of the term... what's
yours?) and it wasn't even about Python changing too fast. At least, I
didn't mean it to be about that. Did you really interpret it that way?

-Peter

 

[John Roth]

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.


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.

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.


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.

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.

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.

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.

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.

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

 

[Paul Rubin]

You can't "fix" this. This code (in some python-like langauge that
isn't python):

x = 23

def fun():
x = 25
# Rest of code

has two possible interpretations.

The fix is to add a "local" declaration in "fun":

local x = 25

for example. If you want the one from the outer scope, then use, perhaps,

outer x = 25

One really screwy situation with Python is

x = 23
def f():
x = 25
def g():
x += 3

g obviously is supposed to inherit x from the surrounding scope, but
there's no way for g to actually change x.

 

[Mike Meyer]

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.

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.

And I never suggested you were.

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

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.

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.

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.

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]

?? Which rant was that? I posted only one message in that thread,
and it wasn't a rant (according to my definition of the term... what's
yours?) and it wasn't even about Python changing too fast. At least,
I didn't mean it to be about that. Did you really interpret it that
way?

Sorry, I was looking at the wrong summary line. The rant was posted by
"Fernando" <[email protected]>, and specifically tagged as a <rant>.

Aplogies,
<mike

 

[Peter Hansen]

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.

Although both Mike and John by this time are aware of Mike's mistaken
attribution of the "rant" to me, I feel compelled to point out for
posterity (i.e. anyone searching this thread in the future) that it
wasn't "Peter Hansen" who produced the rant in question, and that
I do NOT feel that Python is changing too quickly.

-Peter

 

[Paul Rubin]

Actually, it is the reinvention of classes:

class enclosing(object):
def __init__(self):
self.var = 2
def enclosed(self):
self.var = 4

Actually, having to wrap classes around operation as simple as variable
binding is a reinvention of Java ;-).

 

[Donn Cave]

Quoth Mike Meyer <[email protected]>:
....
|> 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.

Also an OOP group, which tends to mean that experience with static
typing will have been with C++ or Java, or similar languages. The
ideas I've read for P3000 fortunately show some influence from the
type inference systems popular in FP. What people in this group
think is frankly irrelevant if they're thinking in terms of Java.

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

True, but another statistic that's compromised by self-selecting
population. Earlier in this thread our attention was directed to
an article announcing a fairly radical drop in popularity of Python
(and other interpreted languages) for new projects outside of North
America, citing failure to penetrate the "enterprise" market as a
reason. Ask the enterprise world if they think Python is changing
fast enough. Maybe they're giving up on Python because they decided
they'd never get code blocks. (Ha ha.)

Donn Cave, (e-mail address removed)

 

[Dennis Lee Bieber]

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

For a schizoid view... read both comp.lang.ada and
comp.lang.python together <G>

Though I have to confess my experience is higher in Python than
Ada, even though I used Ada for the report in my "programming languages"
class (1980 -- only "references" were the SIGPlan preliminary
rationale/reference, and the skinny blue book), had a one week class on
the language in 1981 (when the only working compiler was the NYU Ada/Ed
system, and a month after the language became DoD std 1815), etc.

--