Why we will use obj$func() often

[Michele Simionato]

I feel strongly that the Python mixture of declaration (global), default
(where assigned) and broken (closures) is broken overall and has to be fixed
in Prothon. I take this as a given. So I see these possible solutions:

1) My Ruby-like symbols, which I think are readable and fast-compilable.

2) Word-like symbols, which are large, less readable (too me) and
cluttering.

3) Declarations, which cause the compiler and user to look around and are
not Pythonic.

Am I missing any other solutions?

You can use a different assignement syntax for outer scope variables;
for instance in Scheme there is "set!" which can do that.
BTW, I do not think the ability to have read-write closures is that
useful in an OOP language; just use objects. I would ignore this
"issue". OTOH, I do agree that Python scope rules are not 100%
perfect,
but I would content myself with changing the rule for "for" loops (see
http://groups.google.it/groups?hl=i...es&btnG=Cerca&meta=group%3Dcomp.lang.python.*)

Michele Simionato

 

[Donn Cave]

I guess the whole problem is my insistence on simple scope indentification
by looking at the variable. It causes the var to need to be tagged.

Well, in a sense this is a simplistic avoidance of scope. Scope
is how unqualified identifiers are resolved. You hope that actual
usage is simple enough that a relative qualifier will prop up the
weaknesses of Python's half-lexical, half-dynamic system; Greg
points out that it doesn't handle more complex usage like nested
functions (and Simon's list comprehension / loop). You can dismiss
those as uncommon problems, but then this whole feature addresses
a problem that bothers only those who choose to be afflicted.

I feel strongly that the Python mixture of declaration (global), default
(where assigned) and broken (closures) is broken overall and has to be fixed
in Prothon. I take this as a given. So I see these possible solutions:

1) My Ruby-like symbols, which I think are readable and fast-compilable.

2) Word-like symbols, which are large, less readable (too me) and
cluttering.

3) Declarations, which cause the compiler and user to look around and are
not Pythonic.

Am I missing any other solutions?

I've already talked about making scope purely lexical, only explicit
dynamic name space binding.
http://groups.google.com/groups?selm=1082827791.810981@yasure&oe=UTF-8&
output=gplain

As I said there, declaration isn't an interesting part of that,
but the idea that declarations are "not Pythonic" strikes me as
particularly absurd (not to mention just seeing you, of all people,
offer this criticism.) What is "class"? What is "def"?

Donn Cave, (e-mail address removed)

 

[Mark Hahn]

Well, in a sense this (&var) is a simplistic avoidance of scope. Scope
is how unqualified identifiers are resolved.

Scope is a noun, not a verb. To me a scope is just a namespace defined by
syntax. There are many ways to specify what scope a var belongs in, and
qualification using &var is just as valid as any other.

Greg points out that it doesn't handle more complex usage like nested
functions (and Simon's list comprehension / loop). You can dismiss
those as uncommon problems, but then this whole feature addresses
a problem that bothers only those who choose to be afflicted.

It turns out that Greg and I were mistaken. The &var syntax can easily
handle unlimited nested scopes and not even slow up my one-pass compiler. I
explained this on the Prothon list.

I'll take a look at Simon's list comprehension problem next. There might be
a solution for that also.

As I said there, declaration isn't an interesting part of that,
but the idea that declarations are "not Pythonic" strikes me as
particularly absurd (not to mention just seeing you, of all people,
offer this criticism.)

I didn't mean to be critical, just stating pros and cons.

What is "class"?

Be fair. You know that I didn't throw out classes on a capricious whim.

What is "def"?

I go through crazy moments where I consider every possibility and throw out
ideas. I considered the idea of replacing def with func (def is misnamed
after all) and that proposal lasted about 30 minutes. Another idea that
lasted about 45 minutes was changing __init__ to init. Please don't hold
anything against me during these trial-idea times. Wait until you see the
final Prothon before you criticize my wanton destruction of the Python
heritage. It also wouldn't hurt to hear you voice on the Prothon mailing
list influencing the outcome.

 

[Donn Cave]

Scope is a noun, not a verb. To me a scope is just a namespace defined by
syntax. There are many ways to specify what scope a var belongs in, and
qualification using &var is just as valid as any other.

Whatever you want scope to mean, that's up to you, but let's
observe that whatever you want to call it, programming languages
have in common a need to resolve multiple occurrences of an
identifier without syntactical aids, and some of them manage
to do it just fine in a fairly complex code structure.

I didn't mean to be critical, just stating pros and cons.


Be fair. You know that I didn't throw out classes on a capricious whim.

I actually had forgotten that you threw out class, that's not
my point. Declarations are "Pythonic", because Python code is
necessarily full of declarations. When you reject a solution
because it's "not Pythonic", that is structurally a criticism.
I don't care how you rationalize your preferences in these
matters, really, and it might be that you would do better to
leave that part alone and just state your preferences. There's
nothing more inflammatory in a place like this than an absurd
proposition.

I go through crazy moments where I consider every possibility and throw out
ideas. I considered the idea of replacing def with func (def is misnamed
after all) and that proposal lasted about 30 minutes. Another idea that
lasted about 45 minutes was changing __init__ to init. Please don't hold
anything against me during these trial-idea times. Wait until you see the
final Prothon before you criticize my wanton destruction of the Python
heritage. It also wouldn't hurt to hear you voice on the Prothon mailing
list influencing the outcome.

You can't afford to indulge my tastes in programming languages,
because the result would be utterly foreign to Python users.
I use Python because it works. Roughly the 2.0 subset of the
language is all I know and seem to need to know to make programs
work. When I dream of a better language, it's not pasting new
gimmicks on Python, it's really a radically different direction.
OOP languages are today's FORTRAN.

Donn Cave, (e-mail address removed)

 

[Bengt Richter]

work. When I dream of a better language, it's not pasting new
gimmicks on Python, it's really a radically different direction.

You teaser ;-)

Regards,
Bengt Richter

 

[Mark Hahn]

When I dream of a better language, it's not pasting new
gimmicks on Python, it's really a radically different direction.

I've daydreamed the same thing and I've thought a classless language was
radical. If it turns out to only be a gimmick in the end and not reap the
payoffs I've been daydreaming about then I'll be quite dissapointed.

If you focus on the closure &var then you are missing the exciting parts of
the language picture. I don't need to ask questions about the exciting
parts.

Can you share some of your daydream ideas?

 

[Greg Ewing]

It turns out that Greg and I were mistaken. The &var syntax can easily
handle unlimited nested scopes and not even slow up my one-pass compiler.

It does incur the expense of a run-time lookup for
intermediate-scoped variables, however.

 

[Mark Hahn]

It does incur the expense of a run-time lookup for
intermediate-scoped variables, however.

Prototype-based systems incur a prototype chain lookup expense on every
single attribute lookup. This is a disadvantage compared to class-based
systems. See the Lieberman paper linked near the top of the Prothon home
page.

That same paper also discusses a cache method that effectively eliminates
that expense. That same expense and cache fix will apply without change to
the closure lookup.

So the bottom line is there will effectively be no expense. We won't be
working on performance in Prothon until July or August though, so you'll
have to take my word on that until then.

 

[Donn Cave]

Can you share some of your daydream ideas?

Not really my ideas, it's pretty much all there in Haskell
and Clean (though I have no experience with the latter.)
Pure functional, strong static typing with type inference,
compile to native. It isn't clear that it's ideal - there
may be some inherent limitations to exception handling, the
execution model is often awkward (cf. Monad) at least for
the beginner programmer. So there's probably room for yet
another variation on the theme, but I'd be using Haskell
now if I could (weakness of platform support, institutional
acceptance.)

Haskell is good for you, though, even if you can't put it
to use in practice. It's a thoroughly different approach
that's at least good for perspective. And it's white space
structured.

Donn Cave, (e-mail address removed)

 

[A. Lloyd Flanagan]

Python can't write to it, but at least it can read it.
Prothon apparently can't even read it.

Actually, when I tried the code I got a NameError. I don't see why I
would want to access a variable defined in an inner scope from an
outer scope; this seems like a great way to clutter up the namespace
and confuse the issue of what the variable actually refers to.

 

[Mark Hahn]

Actually, when I tried the code I got a NameError. I don't see why I
would want to access a variable defined in an inner scope from an
outer scope; this seems like a great way to clutter up the namespace
and confuse the issue of what the variable actually refers to.

I assume you are talking about running that code in Python after removing
the & from &x?

That was supposed to be Prothon code that somehow defined x in function f
from the statement &x = 42, even though that statement was in the inner
function h. The equivalent python code would have the statement x = 42
inside the function f. Greg was asking if I was claiming that Prothon could
do this "magic" somehow from function h (which Prothon cannot).

We were always talking about an x local to f being referred to in h.