On 5/9/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 06:19 AM, 9 May 2006 +, Talin <[EMAIL PROTECTED]> wrote:
> >Now, generic functions are good at dealing with these kinds of
> >situations. However, generic functions (as they are usually concieved)
> >can only deal with specific, concrete
On 5/11/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I think I'm more comfortable with a maximal taxonomy. In a maximal
> taxonomy, I'd describe a large set of invariants, attributes,
> behavior, etc., and say e.g. "this is how a file behaves". A
> particular class can then claim to be a file
> > The only sane proposal i've seen that consistently addresses all
> > these cases, doesn't create new ambiguous situations, and doesn't
> > break most existing Python code is the "nonlocal" declaration.
[snip]
> Agreed - I believe the only real problem with the idea was that nobody could
> com
> there's no connection whatsoever between things that are raised now and
> then in various forums, and things that are real "seriously hurts people
> trying to get things done in Python" warts.
Fair enough.
> the vast majority of all Python programmers never uses nested functions
> at all.
Yes,
> > Yes, but part of the reason for this may be this very wart. I know
> > I'm campaigning for this as a fix for what the OP calls the "read only
> > lexical scoping gotcha". A fix for that makes it much more convienent
> > to write closures that modify closed-over values, which in turn makes
> >
> I'm +1 on `nonlocal` as well, having long been bothered by the absence
> of something like it. Ka-Ping, will you write a PEP? If not, I'll take
> it on.
Since a PEP seems to be on the horizon, I just wanted to give a quick
mention of what eventually became my favorite spelling of this keyword
--
> At some point we're going to run out of all the really well-known Monty
> Python sketches, at which point people will either come to their senses,
> or we are going to see abominations like open source projects named
> "dead bishop" or something.
Cf. "crunchy frog", a really cool application con
> Is anybody working [on a] PEP?
This has gone unanswered for several days, so I wanted to mention that
Ka-Ping Yee said in an off-list email from mid-October that he is
indeed working on a PEP for this, but it would take a while due to
other priorities.
Mike
__
> How about [...] using 'parent' as the keyword?
I once proposed 'parent' in a similar thread a long time ago.
It's a non-starter because it's a commonly used variable name.
Mike
___
Python-3000 mailing list
[email protected]
http://mail.python
> The rule should be:
>
> The keyword 'nonlocal' causes the lookup to be performed as if there
> were no assignments to that variable in the scope containing the
> 'nonlocal' declaration.
>
> No exceptions are needed, and no limitation to the immediately
> surrounding scope is needed. Read accesses
Ka-Ping,
Thanks for all of your hard work on this. Well done!
Mike
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mai
> Also, now that you remind me of it, IronPython could use [annotations] for C#
> overloads.
FWIW, the IronPython folks are looking for a CPython-compatible syntax
for specifying .net attributes. Function decorators (plus class
decorators) don't cover all the use cases because so many different
> One example they give is
>
> ---
> i = revised(i);
> とか、
> i = RevisedByMarubatuMethod(i);
> とか、
> i = revised_by_marubatu_method(i);
>
> と書くよりは、
>
> i = ○×方式による補正を行う(i);
> ---
> And of
13 matches
Mail list logo
