On 7/3/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:
> > Much though the Algol 60 tickles my nostalgia (it was my first
> > programming language!) I don't think that it's a particularly strong
> > argument. I like to think that we have better ways these days.
>
> Even if so, that's not the point I w
> Much though the Algol 60 tickles my nostalgia (it was my first
> programming language!) I don't think that it's a particularly strong
> argument. I like to think that we have better ways these days.
Even if so, that's not the point I was trying to make. The point is that
there is a programming
On 7/3/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:
> > I don't think "trivial" is the right word to use here,
> > since it implies something that's of so little importance
> > that it can be ignored. But the simple cases are precisely
> > the ones where this wart hurts the most, so we can't
> > ig
> I don't think "trivial" is the right word to use here,
> since it implies something that's of so little importance
> that it can be ignored. But the simple cases are precisely
> the ones where this wart hurts the most, so we can't
> ignore them.
I'd like to inject an example that might help make
Josiah> As for a solution, I find the "global means 'not local'"
Josiah> proposition is the least undesireable of the possibilities. It
Josiah> suffers from a change in semantics and potential name masking
Josiah> issues...
Pychecker and PyLint both already identify cases where bu
Talin wrote:
> To put it another way - I am an advocate of applying Claude Shannon's
> theory of information to language design. The highest level of
> compression should be used for expressions that occur the most frequently.
I believe the proposal in question would cause no
net worsening in t
Josiah Carlson wrote:
> I had hoped that there would be a response to my second (and I believe
> more applicable statement); "if the feature is really only useful for
> generally trivial cases *without* the feature, then making them even
> more trivial, I think, is a bit of over optimization."
I
Josiah Carlson wrote:
> I had hoped that there would be a response to my second (and I believe
> more applicable statement); "if the feature is really only useful for
> generally trivial cases *without* the feature, then making them even
> more trivial, I think, is a bit of over optimization."
It
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
>
> On 7/3/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> >
> > Greg Ewing <[EMAIL PROTECTED]> wrote:
> > > Josiah Carlson wrote:
> > > > If the only code that benefits from such changes are "very *simple*",
> > > > then I think that says something a
On 7/3/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> Greg Ewing <[EMAIL PROTECTED]> wrote:
> > Josiah Carlson wrote:
> > > If the only code that benefits from such changes are "very *simple*",
> > > then I think that says something about its necessity.
> >
> > The point is that they're only "ve
Greg Ewing <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > If the only code that benefits from such changes are "very *simple*",
> > then I think that says something about its necessity.
>
> The point is that they're only "very simple" if you
> can write them using access to an outer scope
Josiah Carlson wrote:
> If the only code that benefits from such changes are "very *simple*",
> then I think that says something about its necessity.
The point is that they're only "very simple" if you
can write them using access to an outer scope. Without
that ability, they become less simple, l
On Sat, 1 Jul 2006, Andrew Koenig wrote:
> I'd rather see a simpler rule: = never defines a variable in a surrounding
> scope. If you want to affect the binding of such a variable, you have to
> define it explicitly in the scope in which you want it.
>
> Example:
>
> x = 42
> def f():
Neil Schemenauer wrote:
> The := would assign but not declare a variable
> in the current scope.
There are other benefits to such a statement, too, since we can make it
similar to other augmented assignments by letting the object being assigned to
interfere with the process.
a := 2
could
> "Fully functional" lexical scopes, then?
Fine-grained scopes?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archiv
On Sat, 1 Jul 2006, Greg Ewing wrote:
> I don't disagree with anything you said, but I think it
> would be a good idea to avoid using phrases like "proper
> lexical scopes", which is likely to set people off on
> a tangent. The issue isn't lexicality, it's writeability.
"Fully functional" lexical
> What about doing something similar to how import was changed?
>
> .a = 5 # this scope (self might be too magical
> ..a = 3 # up one scope
> ...a # up three
>
> Of course, this looks ... perhaps a bit strange. Also, counting is a
> bother.
I'd rather see a simpler rule: = never defines a variab
What about doing something similar to how import was changed?
.a = 5 # this scope (self might be too magical
..a = 3 # up one scope
...a # up three
Of course, this looks ... perhaps a bit strange. Also, counting is a
bother.
//Simon
___
Python-Dev ma
On 7/1/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> There's one very simple way we could do this in Py3k> without requiring any new syntax or keywords: just> redefine the meaning of "global" to mean "not local".I would probably be a solid -0 on such a proposal; I still don't think
it's really ne
Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> Most other languages that support lexical scoping (including Scheme,
> JavaScript, Ruby, Perl, E, Java, Smalltalk) provide a uniform way
> to read and write to scopes at all levels. This is done by letting
> programmers specify the scope in which they want
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
>
> > What I asked before, and what I'd like to ask again, is if there are any
> > _nontrivial uses_ of lexically nested scopes which are made cumbersome
> > by our inability to write to parent scopes.
>
> The trouble with taking t
Josiah Carlson wrote:
> What I asked before, and what I'd like to ask again, is if there are any
> _nontrivial uses_ of lexically nested scopes which are made cumbersome
> by our inability to write to parent scopes.
The trouble with taking that position is that the very
cases which would benefit
Ka-Ping Yee wrote:
> while offering a way to get proper
> lexical scopes for those who want to use them.
I don't disagree with anything you said, but I think it
would be a good idea to avoid using phrases like "proper
lexical scopes", which is likely to set people off on
a tangent. The issue isn
> With "var":
>
> var a = 3
> def f():
> var b = 4
> def g():
> var c = 5
> a, b, c = 0, 1, 2 # changes outer a, outer b, and c
> g()
> f()
>
> Now i think this is a little bit weird, because the statement
> "var b = 4" in an outer scope
Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
[snip lexical scoping option]
> Now i think this is a little bit weird, because the statement
> "var b = 4" in an outer scope changes the meaning of "b" in an
> inner scope. But it does have the virtue of retaining behaviour
> compatible with today's Python,
On Fri, 30 Jun 2006, Guido van Rossum wrote:
> On 6/30/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> > On Fri, 30 Jun 2006, Andrew Koenig wrote:
> > > I hope Py3000 has lexical scoping a la Scheme...
> >
> > Me too -- that would be really nice.
>
> That's not a very constructive proposal (especially
26 matches
Mail list logo
