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?
Chris
59  3792  se******@spawar.navy.mil wrote: 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 is likely that more people would find module or modulescope confusing.
Plus module has a different customary meaning already:
import <module>
I think D H is right. Or even if you'd find out that most of the people
would better like 'modulescope' or 'module', (what is, i think,
imposible), you'd destroy the backward-compatibility with older
versions of Puthon if you implement it. But it won't be implemented.
Trust me.
<se******@spawar.navy.mil> wrote in message
news:11*********************@g47g2000cwa.googlegro ups.com... 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?
Chris
A much better idea would be to fix the underlying
situation that makes the global statement necessary.
I doubt if this is going to happen either, though.
John Roth
<se******@spawar.navy.mil> wrote in message
news:11*********************@g47g2000cwa.googlegro ups.com... I've heard 2 people complain that word 'global' is confusing.
I did to at first.
Perhaps 'modulescope' or 'module' would be better?
Global is an somewhat short adjective that plausibly becomes a noun when
pluralized. That is hard to match. I have thought of 'modular' as the
actual meaning of 'global', but 'modulars' does not sound as good to me.
Am I the first peope to have thought of this and suggested it?
You are the first people I remember making at least the 'modulescope'
suggestion. Searching the newsgroup archive at Google would make sure ;-).
Is this a candidate for Python 3000 yet?
Unlikely. I suspect that global meaning global to the module (as opposed to
the collection of modules or compilation units) is established CS usage.
Terry J. Reedy
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?
Python 3000 is not worried about backward compatibility.
It is worried more about what is *best* and getting it done.
Trust me.
Let me ask an academic question....Is 'global' the
*best* choice of all choices in Webster's dictionary?
If it is then I'll give up and go home. If not then well.....
Chris
Your solution is the best of them all. However, I don't
have the foggiest idea how it would be accomplished.
Are you *sure* you can change design so that there
is no need for a keyword like 'global'? Please enlighten
me. I'd really appreciate it.
Chris
I appreciate your comments. You give reasons why you
think 'global' is a good idea.
Are you sure that 'global' is widely assumed to mean
global to a *file* in proper CS theory? Coming from C....I assumed
'global' meant global to ENTIRE EXECUTABLE!?!? You
even admitted you also thought 'global' was confusing in past!
So how can you say you think CS community in general won't
have any problem like we BOTH did????
Chris
"John Roth" <ne********@jhrothjr.com> writes: <se******@spawar.navy.mil> wrote in message
news:11*********************@g47g2000cwa.googlegro ups.com...
A much better idea would be to fix the underlying
situation that makes the global statement necessary.
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.
Either the occurrence of x in fun references the global, or it
references a local that shadows the global. There are reasons for
wanting both behaviors. So you have to have some way to distinguish
between the two, and you want it to happen per variable, not per
function. The method with the fewest keywords is to have one be the
default, and some keyword that triggers the other.
So the only way to remove the global statement would be to have some
way to mark the other interpretation, with say a "local"
decleration. I thik that would be much worse than "global". For one
thing, most variables would be local whether or not they are
declared. Second, having an indication that you need to check module
globals in the function is a better than not having that clue there.
<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. se******@spawar.navy.mil wrote: 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?
Chris
Hmm.. instead of 'global', how about 'outside' ? It seems a bit more
intuitive to me because it suggests that you mean, "the variable defined
outside this scope" or outside any nestedness.
But then again it could be confused to mean "just one scope above this
one" which isn't necessarily module scope (nested functions, etc.)...
still, might be less confusing than 'global'.
Another alternative to having to say "global var" would be to use some
sort of indicator that you want the global with each usage, like,
"global.var" or "outside.var"
<se******@spawar.navy.mil> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com... Are you sure
If I were, I would not have started the statement 'I suspect...'. I do not
insert such words accidentally.
TJR
On 5 Aug 2005 21:31:02 -0700, "se******@spawar.navy.mil"
<se******@spawar.navy.mil> declaimed the following in comp.lang.python: I appreciate your comments. You give reasons why you
think 'global' is a good idea.
Are you sure that 'global' is widely assumed to mean
global to a *file* in proper CS theory? Coming from C....I assumed
'global' meant global to ENTIRE EXECUTABLE!?!? You
Considering that "global" is only useful within the body of a
"def" block would seem to imply that it is something special within the
file and not program-wide...
If "global" were used at the top of a module, then I could see
that interpretation. It would be similar to a named COMMON in FORTRAN --
global x
equivalent to
COMMON /X/ x
{My college FORTRAN IV actually /did/ have a "GLOBAL" statement which
functioned in just that way: each variable specified became the only
content of a common block named the same as the variable}
-- ================================================== ============ <
wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
================================================== ============ <
Home Page: <http://www.dm.net/~wulfraed/> <
Overflow Page: <http://wlfraed.home.netcom.com/> <
"Mike Meyer" <mw*@mired.org> wrote in message
news:86************@bhuda.mired.org... "John Roth" <ne********@jhrothjr.com> writes: <se******@spawar.navy.mil> wrote in message
news:11*********************@g47g2000cwa.googlegro ups.com...
A much better idea would be to fix the underlying
situation that makes the global statement necessary.
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.
Either the occurrence of x in fun references the global, or it
references a local that shadows the global. There are reasons for
wanting both behaviors. So you have to have some way to distinguish
between the two, and you want it to happen per variable, not per
function. The method with the fewest keywords is to have one be the
default, and some keyword that triggers the other.
So the only way to remove the global statement would be to have some
way to mark the other interpretation, with say a "local"
decleration. I thik that would be much worse than "global". For one
thing, most variables would be local whether or not they are
declared. Second, having an indication that you need to check module
globals in the function is a better than not having that clue there.
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.
It's not going to happen because the Python community is fat and happy,
and is not seeing the competition moving up on the outside. Characteristics
that make a great language one day make a mediocre one a few years
later, and make a has-been a few years after that.
John Roth
<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more
information.
John Roth wrote: It's not going to happen because the Python community is fat and happy,
and is not seeing the competition moving up on the outside. Characteristics
that make a great language one day make a mediocre one a few years
later, and make a has-been a few years after that.
And here I thought that was the point of Python 3000. To let the
community produce a much improved language while avoiding the problems
caused by too much change occurring while people are trying to get
useful things done with what the language is _now_. The competition
(and let's see a description of just what that means, too) probably has
the dual advantage of newness and a small, hackerish community that is
more than happy to see rapid and radical change. You're right -- as
with the stereotypical large/slow vs. small/agile company motif -- that
smaller and more agile will pass larger and slow "on the outside", but
you're wrong if you think that means the larger-slower entity should
drop what it's been doing so well and try to compete entirely on the
smaller-faster entity's own ground.
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.
-Peter se******@spawar.navy.mil wrote: 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?
Chris
I don't think the global keyword is useful actually.
What's so special in a module nemespace to be priviledged like that.
The point IMO is accessing names defined somewhere in the enclosing
namespaces.
def enclosing():
var=2
def enclosed():
outer var=4
this is the base of something useful.
as it is now you neeed
def enclosing():
class Var:_=2
def enclosed():
Var._=4
or like others suggested
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?
I think there is only one or none possible solution to an 'outer'
statement which is the first bound name matching the 'outer' vars name
in the chain of enclosing namespaces.
Why every instance doesn't point to its namespace and every namespace to
its namespace? Unpythonic ?
Illogicities to my eyes or at least non-linerities that makes 'global'
an interesting strangeness to talk about.
And that namespaces should start being easy sooner or later.
Regards Paolino
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it se******@spawar.navy.mil wrote: 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?
Chris
Maybe a solution would be best that is able to resolve shadowing of a
variable in an explicit manner.
Example. you might have the following nested function:
x = 0
def h():
x = 1 # module scoped x will be shadowed
def g():
x = 2 # module scoped x and h's local x will be
shadowed
def f():
print x # printing x defined locally in g
f()
g()
The module level x is always accessible from each inner function using
the global keyword but it is not possible to access x defined locally
in h from f.
Two hypothetical variants using an "unshadow operator" & explicitely:
x = 0
def h():
x = 1
def g():
x = 2
def f():
print &x # unshadowing x defined in h
f()
g()
x = 0
def h():
x = 1
def g():
x = 2
def f():
print &&x # unshadowing x defined on module level
f()
g()
Since we can always shadow some module scoped variable defining a local
one we might create a side-effect binding values to the unshadowed
name:
x = 0
def f():
x = 1
&x = 7 f()
x
7
Regards,
Kay
Paolino wrote: se******@spawar.navy.mil 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.)
-Peter
"Peter Hansen" <pe***@engcorp.com> wrote in message
news:C9********************@powergate.ca... John Roth wrote: It's not going to happen because the Python community is fat and happy,
and is not seeing the competition moving up on the outside.
Characteristics
that make a great language one day make a mediocre one a few years
later, and make a has-been a few years after that.
And here I thought that was the point of Python 3000. To let the
community produce a much improved language while avoiding the problems
caused by too much change occurring while people are trying to get useful
things done with what the language is _now_. The competition (and let's
see a description of just what that means, too) probably has the dual
advantage of newness and a small, hackerish community that is more than
happy to see rapid and radical change. You're right -- as with the
stereotypical large/slow vs. small/agile company motif -- that smaller and
more agile will pass larger and slow "on the outside", but you're wrong if
you think that means the larger-slower entity should drop what it's been
doing so well and try to compete entirely on the smaller-faster entity's
own ground.
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.
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/Collec...ureMethod.html
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.
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.
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.
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.)
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.
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.
John Roth
John Roth
-Peter
"Paolino" <pa*************@tiscali.it> wrote in message
news:ma***************************************@pyt hon.org... se******@spawar.navy.mil wrote: 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?
Chris
I don't think the global keyword is useful actually.
What's so special in a module nemespace to be priviledged like that.
The point IMO is accessing names defined somewhere in the enclosing
namespaces.
The issue isn't _accessing_ the module namespace. It's
binding to identifiers in the module namespace.
The reason is that _assigning_ to an identifier in a
function or method makes that identifier local, so
there needs to be a simply way of saying that you
want to be able to assign to an identifier in the
module namespace. (There's already a more
complicated way: use the global() built-in function.)
John Roth
Regards Paolino
John Roth wrote:
"Mike Meyer" <mw*@mired.org> wrote in message
news:86************@bhuda.mired.org...
So the only way to remove the global statement would be to have some
way to mark the other interpretation, with say a "local"
decleration. I thik that would be much worse than "global". For one
thing, most variables would be local whether or not they are
declared. Second, having an indication that you need to check module
globals in the function is a better than not having that clue there.
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.
Peter Hansen wrote: Paolino wrote:
se******@spawar.navy.mil 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 se******@spawar.navy.mil wrote: 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.
John Roth wrote: "Peter Hansen" <pe***@engcorp.com> wrote in message
news:C9********************@powergate.ca... John Roth wrote: It's not going to happen because the Python community is fat and happy,
and is not seeing the competition moving up on the outside.
Characteristics
that make a great language one day make a mediocre one a few years
later, and make a has-been a few years after that.
And here I thought that was the point of Python 3000. To let the
community produce a much improved language while avoiding the problems
caused by too much change occurring while people are trying to get useful
things done with what the language is _now_. The competition (and let's
see a description of just what that means, too) probably has the dual
advantage of newness and a small, hackerish community that is more than
happy to see rapid and radical change. You're right -- as with the
stereotypical large/slow vs. small/agile company motif -- that smaller and
more agile will pass larger and slow "on the outside", but you're wrong if
you think that means the larger-slower entity should drop what it's been
doing so well and try to compete entirely on the smaller-faster entity's
own ground.
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/Collec...ureMethod.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.
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.)
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
On Sat, 6 Aug 2005 11:53:04 -0600,
"John Roth" <ne********@jhrothjr.com> wrote: 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
--
Dan Sommers
<http://www.tombstonezero.net/dan/>
John Roth wrote: 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.
On Sat, 06 Aug 2005 21:16:13 +0200, Paolino <pa*************@tiscali.it>
declaimed the following in comp.lang.python: 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[i] 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.
-- ================================================== ============ <
wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
================================================== ============ <
Home Page: <http://www.dm.net/~wulfraed/> <
Overflow Page: <http://wlfraed.home.netcom.com/> <
"John Roth" <ne********@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/Collec...ureMethod.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 <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
"Paolino" <pa*************@tiscali.it> wrote in message
news:42************@tiscali.it... se******@spawar.navy.mil 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
"se******@spawar.navy.mil" <se******@spawar.navy.mil> writes: 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.
"John Roth" <ne********@jhrothjr.com> wrote in message
news:11*************@news.supernews.com... 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
Mike Meyer wrote: "John Roth" <ne********@jhrothjr.com> writes: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.
?? 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
"Mike Meyer" <mw*@mired.org> wrote in message
news:86************@bhuda.mired.org... "John Roth" <ne********@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/Collec...ureMethod.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 <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more
information.
Mike Meyer <mw*@mired.org> writes: 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.
"John Roth" <ne********@jhrothjr.com> writes: "Mike Meyer" <mw*@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/Collec...ureMethod.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 <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Peter Hansen <pe***@engcorp.com> writes: Mike Meyer wrote: "John Roth" <ne********@jhrothjr.com> writes: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.
?? 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" <fr*@easyjob.net>, and specifically tagged as a <rant>.
Aplogies,
<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Mike Meyer wrote: "John Roth" <ne********@jhrothjr.com> writes:"Mike Meyer" <mw*@mired.org> wrote in messageI 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.
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
"Terry Reedy" <tj*****@udel.edu> writes: 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 ;-).
Quoth Mike Meyer <mw*@mired.org>:
| "John Roth" <ne********@jhrothjr.com> writes:
....
|> 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, do**@drizzle.com
On Sat, 06 Aug 2005 21:37:54 -0400, Mike Meyer <mw*@mired.org> declaimed
the following in comp.lang.python:
"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.
-- ================================================== ============ <
wl*****@ix.netcom.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
================================================== ============ <
Home Page: <http://www.dm.net/~wulfraed/> <
Overflow Page: <http://wlfraed.home.netcom.com/> <
Terry Reedy wrote: "Paolino" <pa*************@tiscali.it> wrote in message
news:42************@tiscali.it...
se******@spawar.navy.mil 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
This is using some really 'featured' namespace called class to do things
which are useful to all namespaces.So not a solution but a hack.
Also 'self' is something really away from my example.A cloned namespace
of the class probably.
Working hard with python namespaces is hacking: probably this makes us
masters of python, when using namespaces should be a base knowledge.
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.
You cut the phrase and the meaning of it.
The only one solution I'm talking about is this:
Stated 'outer var' in a namespace, jumping out of the namespace
we found ourselves in another namespace.
If 'var' is bound there, that's the solution to
the 'outer' ,if not we jump out again.If the 'var' is never found we
can raise an UnboundOuter error probably.
Regards Paolino
___________________________________
Yahoo! Messenger: chiamate gratuite in tutto il mondo http://it.beta.messenger.yahoo.com
Dennis Lee Bieber <wl*****@ix.netcom.com> writes: On Sat, 06 Aug 2005 21:37:54 -0400, Mike Meyer <mw*@mired.org> declaimed
the following in comp.lang.python: "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>
Will you settle for comp.lang.eiffel + the smalleiffel list and
comp.lang.python?
<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
On Sat, 6 Aug 2005 19:28:13 -0400, "Terry Reedy" <tj*****@udel.edu> wrote:
"Paolino" <pa*************@tiscali.it> wrote in message
news:42************@tiscali.it... se******@spawar.navy.mil 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.
Ok ;-) But that's historical, and tells us something about how we got to the status quo.
ISTM someone wants to discuss possibilities for the future (unless they are just complaining ;-) 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.
No doubt ;-)
It might be interesting to compare attribute names with bare names. For attributes
we also have a legacy from the historical evolution of current functionaly. E.g.,
classic vs new classes, descriptors, and most relevenat to the current discussion,
mro and super.
Bare names do not (yet ;-) have an explicit "nro" (name resolution order), and there
is no "super" for names (though someone recently proposed an "unshadow" operator here
on c.l.p, so the subject is alive ;-)
Nor do we have any correspondence for bare names analogous to
setattr(obj, "name", value) <=> obj.name = value
e.g.,
setname(<namespace_selection>, "name", value)
There is nowhere near the kind of control the programmer has over attribute namespace
use for bare-name use, even though by various means we are able to select from a limited
set of namespaces. (BTW, if <namespace_selection> were a call to a suitable builtin function
that could return objects whose attribute namespace were the desired name space, then setname
could be effected with setattr, e.g.,
setattr(get_ns_obj(), "name", value) # name = value (defaulting to local, same as get_ns_obj(0))
setattr(get_ns_obj(1), "name", value) # name = value (in lexically immediately (1) enclosing scope)
setattr(get_ns_obj(-1), "name", value) # name = value (in global module scope)
)
I am thinking that there is a subliminal discussion under a layer of red herrings ;-)
I refer to the subject of unification/generalizing/orthogonalizing by removing special
legacy restrictions (or not introducing special restrictions in a new feature).
E.g., recently decorators were introduced, and part of the discussion (which became explicit ;-)
was whether to allow the expression following the '@' to be a fully general expression, or
whether to restrict it to names, dotted names, and function calls. The latter won out.
Some regard this kind of restriction as paternalistic, and protest that "we are adults here"
(even though we are not all, and we others not all the time ;-)
The BDFL has introduced many new ideas, yet has retained or introduced restrictions on fully
orthogonal functionality that might otherwise be allowed if e.g. names in certain contexts
were allowed to be full expressions. It goes the other way too. IIRC the list of bases for
a class will be allowed to be an empty "()" soon.
Bottom line, I think Python is eminently usable and very pleasant to use, but I think bare name
mechanisms could be improved.
<another HOTTOMH idea ;-)>
What about more namespace control in the definition of functions, along the lines of
"nro" for bare name lookup in the function body? This could be in the form of a sequence
of ordinary objects whose attribute name spaces should be searched before looking in globals().
Also using := rather than = to override local namespace binding with extended name space lookup,
e.g., (discuss **=<name space object sequence> syntax later ;-)
def fun(a, b=2, *args, **kw, **=(nso, nso2, etc)):
print x # looks for local x, nso.x, nso2.x, etc.x, and then globals()['x']
# i.e., not a used-before-bound error if **= spec exists
x = 123 # binds local x in any case
print x # finds the local x first
del x # unshadow **= namespace sequence
x := 456 # not local binding unless pre-existing, but if so rebind.
# Also rebind if found in enclosing closure scope, BTW.
# Otherwise find the first object nsofound with x attr in **= object attribute name space sequence,
# and then do nsofound.x=456 -- where x could be a normal property defined by type(nsofound)
The property possibility should be interesting ;-)
</another>
Be kind, I've suggested := for find-and-rebind before, but I haven't thought very far about this combination
with extended function namespace ;-)
Regards,
Bengt Richter
"Mike Meyer" <mw*@mired.org> wrote in message
news:86************@bhuda.mired.org... 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".
AST means Abstract Syntax Tree and there are lots of mentions of ASTs and
'abstract syntax' in the collection of pages. Moreover, elevating abstract
representations is the key idea of Fowler's essay. Near the beginning he
says
"This is a good moment to introduce a common distinction that you run into
in programming language circles - the distinction between abstract and
concrete syntax. The concrete syntax of a language is its syntax in its
representation that we see. The XML and custom language files have
different concrete syntaxes. However both share the same basic structure:
you have multiple mappings, each with a code, a target class name, and a
set of fields. This basic structure is the abstract syntax. When most
developers think about programming language syntax they don't make this
separation, but it's an important one when you use DSLs. You can think of
this in two ways. You can either say we have one language with two concrete
syntaxes, or two languages that share the same abstract syntax."
Roth (following Fowler) talked about taking the first view of seeing the
abstract syntax as the language with multiple possible concrete syntaxes.
Fowler later introduces a section with the summary sentence
"One of the strongest qualities of language workbenches is that they alter
the relationship between editing and compiling the program. Essentially
they shift from editing text files to editing the abstract representation
of the program."
Again, this is what John proposed for Python (if defined by its abstract
syntax (high-level, I presume)). The multiple-paragraph explanation of the
above includes
"For the purposes of this discussion we can break the
[traditional]compilation process into two steps. The first step takes the
text from the file foo.cs and parses it into an abstract syntax tree (AST).
The second step walks this tree generating CLR byte codes that it puts into
an assembly (an exe file)."
His companion article Generating Code for DSLs http://martinfowler.com/articles/codeGenDsl.html
expands the sentence above and includes this:
"What's the advantage of separating the two stages? It does cost us a bit
of complexity - we have to add the AST classes. If we were only reading and
writing to a single format it's arguable whether the AST is worth the
effort - at least for this simple case. The real advantage in the AST lies
when we want to read or write multiple formats."
That is three "AST"s in three sentences, albeit on a different page of his
multipage essay. Anyway, back where we were, Fowler continues that in a
Language Workbench (by contrast to the traditional system)
"The key difference here is that the 'source' is no longer the editable
textual files. The key source that you manipulate is the abstract
representation itself. In order to edit it, the language workbench projects
the abstract representation into some form of editable representation. But
this editable representation is purely transient - it's only there to help
the human. The true source is the persistent abstract representation. "
So it seems that John Roth proposes that Python become at least in part a
'Language Workbench' language. as Fowler defines his new term. It also
seems that ASTs or some sort of abstract representation are central to such
a system.
Terry J.Reedy
"John Roth" <ne********@jhrothjr.com> wrote in message
news:11*************@news.supernews.com... http://martinfowler.com/articles/languageWorkbench.html
This clarified your proposal for Python considerably. So I note that now
and especially once the AST compiler is completed, you are quite free to
start a Python AST Extension (PASTE) project quite independently of Guido
and the PSF developers. Build an AST-based editor like Fowler described,
with transient text presentations. (And pick your preferred GUI for doing
so.) Or design a system for translating domain-specific languages into
PyASTs, from whence they can be compiled to bytecode and run.
Terry J. Reedy
On Sun, 7 Aug 2005 18:37:42 -0400, "Terry Reedy" <tj*****@udel.edu> wrote:
"John Roth" <ne********@jhrothjr.com> wrote in message
news:11*************@news.supernews.com... http://martinfowler.com/articles/languageWorkbench.html
This clarified your proposal for Python considerably. So I note that now
and especially once the AST compiler is completed, you are quite free to
start a Python AST Extension (PASTE) project quite independently of Guido
and the PSF developers. Build an AST-based editor like Fowler described,
with transient text presentations. (And pick your preferred GUI for doing
so.) Or design a system for translating domain-specific languages into
PyASTs, from whence they can be compiled to bytecode and run.
(Not implying that you need this for your edification ;-)
I think the relationship of abstract entities and their concrete representations
is very interesting. And it is useful to note that the representation of an AST
in computer memory with a python interpreter looking at the AST node representations
involves another layer of concrete representation. And the interpreter is an abstraction
with a concrete representation, etc. down to the CPU as interpreter of of instructions
etc., and the CPU being an abstraction made concrete my aggregating concrete elements
chosen for their physical nature as representations of abstractions and behaving
so as to transform concrete states in ways that reflect the transformations of the
corresponding abstractions. And so forth ;-)
IOW, a compiled python program AST in the abstract, would be the same abstraction
even if both compiler and tree represention were done in lisp and you had lispython
instead of cpython etc. Or whether we kept track of everything scribbling in beach
sand with our toes.
BTW, maybe this is a place to mention the concept of an AST decorator, that works like
a function decorator except that it is prefixed with @@ instead of @ and it operates
at compile time when the AST becomes available, but before it gets translated to code,
and what gets passed to the decorator is the AST and the node of its own call (which it would
typically eliminate from the AST as it does whatever else it is programmed to do). Which means
that the decorator must already be compiled and avaiable at that point, so it can be looked
up somewhere by the name. The idea is that this form of decoration could transform the
AST arbitrarily before code generation, and be a very flexible tool for mischief of course,
but also useful tricky things IWT.
Regards,
Bengt Richter
"Bengt Richter" <bo**@oz.net> wrote in message
news:42****************@news.oz.net... I think the relationship of abstract entities and their concrete
representations
is very interesting.
ditto
BTW, maybe this is a place to mention the concept of an AST decorator,
that works like
a function decorator except that it is prefixed with @@ instead of @ and
it operates
at compile time when the AST becomes available, but before it gets
translated to code,
and what gets passed to the decorator is the AST
One can do this much today:
import compiler
new_ast = ast_transformer(compiler.parse('''\
<code here>
''')
However, I can't see any way in the docs to get a code object from the AST.
I believe the AST-to-code compilet is currently being worked on. When it
is, @@ would be nice syntactic sugar but not really necessary.
The idea is that this form of decoration could transform the
AST arbitrarily before code generation, and be a very flexible tool
for mischief of course, but also useful tricky things.
At the moment, we are limited to manipulating concrete text before
compiling it.
Terry J. Reedy
Bengt Richter wrote: Nor do we have any correspondence for bare names analogous to
setattr(obj, "name", value) <=> obj.name = value
e.g.,
setname(<namespace_selection>, "name", value)
Probably this parallelism is a better approach to what I commented
before.Thanks for clarity. There is nowhere near the kind of control the programmer has over attribute namespace
use for bare-name use, even though by various means we are able to select from a limited
set of namespaces. (BTW, if <namespace_selection> were a call to a suitable builtin function
that could return objects whose attribute namespace were the desired name space, then setname
could be effected with setattr, e.g.,
setattr(get_ns_obj(), "name", value) # name = value (defaulting to local, same as get_ns_obj(0))
setattr(get_ns_obj(1), "name", value) # name = value (in lexically immediately (1) enclosing scope)
setattr(get_ns_obj(-1), "name", value) # name = value (in global module scope)
)
Yes namespaces should be unified in their base behaviour. I am thinking that there is a subliminal discussion under a layer of red herrings ;-)
I refer to the subject of unification/generalizing/orthogonalizing by removing special
legacy restrictions (or not introducing special restrictions in a new feature).
E.g., recently decorators were introduced, and part of the discussion (which became explicit ;-)
was whether to allow the expression following the '@' to be a fully general expression, or
whether to restrict it to names, dotted names, and function calls. The latter won out.
Some regard this kind of restriction as paternalistic, and protest that "we are adults here"
(even though we are not all, and we others not all the time ;-)
Uhmpf, adults==theorists and childrens==experimentals ? The BDFL has introduced many new ideas, yet has retained or introduced restrictions on fully
orthogonal functionality that might otherwise be allowed if e.g. names in certain contexts
were allowed to be full expressions. It goes the other way too. IIRC the list of bases for
a class will be allowed to be an empty "()" soon.
Bottom line, I think Python is eminently usable and very pleasant to use, but I think bare name
mechanisms could be improved.
A good dose of humility could be good for reingeneering something ,if
necessary.Python is very usable,and has an almost perfect surface layer.
But this is not enough.It needs to be strong and elegant in the insides
to survive.More, isn't the "Namespaces do more of them" a Python Zen Law ?
Thanks again for putting things in a saner and more open way then I did.
Regards Paolino
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it
On Sun, 7 Aug 2005 23:52:40 -0400, "Terry Reedy" <tj*****@udel.edu> wrote:
"Bengt Richter" <bo**@oz.net> wrote in message
news:42****************@news.oz.net... I think the relationship of abstract entities and their concrete
representations
is very interesting.
ditto
BTW, maybe this is a place to mention the concept of an AST decorator,
that works like
a function decorator except that it is prefixed with @@ instead of @ and
it operates
at compile time when the AST becomes available, but before it gets
translated to code,
and what gets passed to the decorator is the AST
One can do this much today:
import compiler
new_ast = ast_transformer(compiler.parse('''\
<code here>
''')
However, I can't see any way in the docs to get a code object from the AST.
I believe the AST-to-code compilet is currently being worked on. When it
is, @@ would be nice syntactic sugar but not really necessary.
The idea is that this form of decoration could transform the
AST arbitrarily before code generation, and be a very flexible tool
for mischief of course, but also useful tricky things.
At the moment, we are limited to manipulating concrete text before
compiling it.
Have we gone backwards from this? http://groups.google.com/group/comp....2351b221063a8c
I've been meaning to do something with that, to implement @@ decoration, I think probably in the context
of a customized importer, where I would be able to control the whole source conversion process, anticipating
usage something like (ut is my hodgepodge utility package ;-)
from ut.astdecoimport import astdecoimport
amodule = astdecoimport('amodule') # searches like import for amodule.py and does its thing
Regards,
Bengt Richter se******@spawar.navy.mil wrote: 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?
Chris
After reading though some of the suggestions in this thread, (but not
all of them), how about something a bit more flexible but not too different.
For python 3000 if at all...
Have the ability to define names as shared that only live while the
function that declared them has not exited.
The new statements could be called *share* and *shared*.
def boo():
shared x,y,z # Used names predefined in shared name space.
return x+1,y+2,z+3
def foo():
x,y,z = 1,2,3
share x,y,z # These would be visible to sub functions
# but not visible to parent scopes once the
# function ends. [*1]
boo() # modify shared x,y and z in foo.
[*1.] Unless they have also declared the same names as share. (See below.)
'Share' is used to define names to be visible in child scopes, and
'shared' allows access to shared names declared in parent scopes.
Having too keywords is more explicit, although this may work with a
single key word pretty much as it does now.
A single shared name space would still be used where 'share' adds names
to be 'shared' and those names are deleted when the function that
declared them exits. They don't need to live past the life of the
function they were first declared in.
In recursive functions, (or when a name is reshared), declaring a name
as shared could just increment a reference counter, and it wouldn't be
removed from shared until it reaches zero again.
Using 'share' twice with the same name in the same function should cause
an error. Using 'shared' with a name that is not in shared name space
would cause an error.
Just a few thoughts.
Cheers,
Ron This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Tim Tyler |
last post by:
PHP puts most of its functions into a big flat global namespace.
That leads to short function names - but creates a namespace
minefield for programmers.
Lots of the functions are legacies from...
|
by: Bryan Parkoff |
last post by:
I have noticed that C programmers put static keyword beside global
variable and global functions in C source codes. I believe that it is not
necessary and it is not the practice in C++. Static...
|
by: MLH |
last post by:
I've read some posts indicating that having tons of GV's in
an Access app is a bad idea. Personally, I love GVs and I
use them (possibly abuse them) all the time for everything
imaginable - have...
|
by: newbie |
last post by:
Hello,
I have questions about global variables in OOP (in general) and Python
(in specific). I understand (I think) that global variables are
generally not a good idea. However, if there are...
|
by: fabio |
last post by:
Why? i' ve heard about this, the usage of global vars instead of
locals is discouraged, but why?
thx :)
|
by: tracyyun |
last post by:
Hello everyone,
I have a question and would like some advice on network connectivity. I have one computer connected to my router via WiFi, but I have two other computers that I want to be able to...
|
by: giovanniandrean |
last post by:
The energy model is structured as follows and uses excel sheets to give input data:
1-Utility.py contains all the functions needed to calculate the variables and other minor things (mentions...
|
by: NeoPa |
last post by:
Hello everyone.
I find myself stuck trying to find the VBA way to get Access to create a PDF of the currently-selected (and open) object (Form or Report).
I know it can be done by selecting :...
|
by: Teri B |
last post by:
Hi, I have created a sub-form Roles. In my course form the user selects the roles assigned to the course.
0ne-to-many. One course many roles.
Then I created a report based on the Course form and...
|
by: nia12 |
last post by:
Hi there,
I am very new to Access so apologies if any of this is obvious/not clear.
I am creating a data collection tool for health care employees to complete. It consists of a number of...
|
by: NeoPa |
last post by:
Introduction
For this article I'll be focusing on the Report (clsReport) class. This simply handles making the calling Form invisible until all of the Reports opened by it have been closed, when it...
|
by: isladogs |
last post by:
The next online meeting of the Access Europe User Group will be on Wednesday 6 Dec 2023 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, Mike...
|
by: GKJR |
last post by:
Does anyone have a recommendation to build a standalone application to replace an Access database? I have my bookkeeping software I developed in Access that I would like to make available to other...
|
by: SueHopson |
last post by:
Hi All,
I'm trying to create a single code (run off a button that calls the Private Sub) for our parts list report that will allow the user to filter by either/both PartVendor and PartType. On...
| |
