Re: [Python-Dev] Those import related syntax errors again...
I will try to be intellectually honest:
[Thomas Wouters]
And I'd like to note that none of these issues were addressed in the PEP.
This also a *point*. Few days ago I have scanned the pre-checkin archive on this topic, the fix-point was, under BDFL influence:
- It will not do that much harm (but many issues were not raised) - Please no explicit syntax - Let's do it - Future newbies will be thankful because this was always a confusing point for them (if they come from pascal-like languages?)
I should admit that I like the idea of nested scopes, because I like functional programming style, but I don't know whether this returning 3 is nice ;)?
def f(): def g(): return y # put as many innoncent code lines as you like y=3 return g()
The point is that nested scopes cause some harm, not that much but people are asking themself whether is that necessary. Maybe the request that old code should compile as it is, is a bit pedantic, and making it always work but with a new semantic is worse.
But simply catching up as problem arise does not give a good impression. It really seems that there's not been enough discussion about the change, and I think that is also ok to honestely be worried about what user will feel about this? (and we can only think about this beacuse the feedback is not that much) Will this code breakage "scare" them and slow down migration to new versions of python? They are already afraid of going 2.0(?). It is maybe just PR matter but ...
The *point* is that we are not going from version 0.8 to version 0.9 of our toy research lisp dialect, passing from dynamic scoping to lexical scoping. (Yes, I think, that changing semantic behind the scene is not a polite move.)
We really need the BDFL proposing the right thing.
regards, Samuele Pedroni.
BTW, are people similarly opposed to that comparisons can now raise exceptions? It's been mentioned a few times on c.l.py this week, but apparently not (yet) by people who bumped into it in practice.
I should admit that I like the idea of nested scopes, because I like functional programming style, but I don't know whether this returning 3 is nice ;)?
def f(): def g(): return y # put as many innoncent code lines as you like y=3 return g()
This is a red herring; I don't see how this differs from the confusion in
def f(): print y # lots of code y = 3
and I don't see how nested scopes add a new twist to this known issue.
It really seems that there's not been enough discussion about the change,
Maybe,
and I think that is also ok to honestely be worried about what user will feel about this? (and we can only think about this beacuse the feedback is not that much)
FUD.
Will this code breakage "scare" them and slow down migration to new versions of python? They are already afraid of going 2.0(?). It is maybe just PR matter but ...
More FUD.
The *point* is that we are not going from version 0.8 to version 0.9 of our toy research lisp dialect, passing from dynamic scoping to lexical scoping. (Yes, I think, that changing semantic behind the scene is not a polite move.)
Well, I'm actually glad to hear this -- Python now has such a large user base that language changes are deemed impractical.
We really need the BDFL proposing the right thing.
We'll discuss this more at the PythonLabs group meeting. For now, I prefer to move forward with nested scopes, breaking code and all.
--Guido van Rossum (home page: http://www.python.org/~guido/)
BTW, are people similarly opposed to that comparisons can now raise exceptions? It's been mentioned a few times on c.l.py this week, but apparently not (yet) by people who bumped into it in practice.
but that's not a new thing in 2.1, is it?
Python 1.5.2 (#0, May 9 2000, 14:04:03) [MSC 32 bit (Intel)] on win32 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
class spam:
... def __cmp__(self, other): ... raise "Hi tim!" ...
a = [spam(), spam(), spam()] a.sort()
Traceback (innermost last): File "<stdin>", line 1, in ? File "<stdin>", line 3, in __cmp__ Hi tim!
Cheers /F
Guido van Rossum wrote:
and I think that is also ok to honestely be worried about what user will feel about this? (and we can only think about this beacuse the feedback is not that much)
FUD.
Will this code breakage "scare" them and slow down migration to new versions of python? They are already afraid of going 2.0(?). It is maybe just PR matter but ...
More FUD.
but FUD is what we have to deal with on the market.
I know from my 2.0 experiences that lots of people are concerned about even small changes (more ways to do it isn't always what a large organization wants). Pointing out that "hey, it's a major release" or "you can ignore the new features, and pretend it's just a better 1.5.2" helps a little bit, but the scepticism is still there.
And here we have something that breaks code, breaks tools, breaks training material, and breaks books.
"Everything you know about Python scoping is wrong. Get over it".
The more I think about it, the less I think it belongs in any version before 3.0.
Cheers /F
BTW, are people similarly opposed to that comparisons can now raise exceptions? It's been mentioned a few times on c.l.py this week, but apparently not (yet) by people who bumped into it in practice.
That's not exactly news though, is it? Comparisons have been raising exceptions since, oh, Python 1.4 at least.
--Guido van Rossum (home page: http://www.python.org/~guido/)
[tim]
BTW, are people similarly opposed to that comparisons can now raise exceptions? It's been mentioned a few times on c.l.py this week, but apparently not (yet) by people who bumped into it in practice.
[/F]
but that's not a new thing in 2.1, is it?
No, but each release raises cmp exceptions in cases it didn't the release before. If we were dead serious about "no backward incompatibility ever, no way no how", I'd expect arguments just as intense about that. So I conclude we're not dead serious about that. Which is good! But in a world without absolutes, there are no killer arguments either.
participants (4)
-
Fredrik Lundh -
Guido van Rossum -
Samuele Pedroni -
Tim Peters