Mailman 3 August 2001 - Python-Dev

RE: [Python-Dev] Those import related syntax errors again...
by Samuele Pedroni Feb. 23, 2005

Feb. 23, 2005

Hi. [Mark Hammond] > The point isn't about my suffering as such. The point is more that > python-dev owns a tiny amount of the code out there, and I don't believe we > should put Python's users through this. > > Sure - I would be happy to "upgrade" all the win32all code, no problem. I > am also happy to live in the bleeding edge and take some pain that will > cause. > > The issue is simply the user base, and giving Python a reputation of not > being able to … [View More]painlessly upgrade even dot revisions. I agree with all this. [As I imagined explicit syntax did not catch up and would require lot of discussions.] [GvR] > > Another way is to use special rules > > (similar to those for class defs), e.g. having > > > > <frag> > > y=3 > > def f(): > > exec "y=2" > > def g(): > > return y > > return g() > > > > print f() > > </frag> > > > > # print 3. > > > > Is that confusing for users? maybe they will more naturally expect 2 > > as outcome (given nested scopes). > > This seems the best compromise to me. It will lead to the least > broken code, because this is the behavior that we had before nested > scopes! It is also quite easy to implement given the current > implementation, I believe. > > Maybe we could introduce a warning rather than an error for this > situation though, because even if this behavior is clearly documented, > it will still be confusing to some, so it is better if we outlaw it in > some future version. > Yes this can be easy to implement but more confusing situations can arise: <frag> y=3 def f(): y=9 exec "y=2" def g(): return y return y,g() print f() </frag> What should this print? the situation leads not to a canonical solution as class def scopes. or <frag> def f(): from foo import * def g(): return y return g() print f() </frag> [Mark Hammond] > > This probably won't be a very popular suggestion, but how about pulling > > nested scopes (I assume they are at the root of the problem) > > until this can be solved cleanly? > > Agreed. While I think nested scopes are kinda cool, I have lived without > them, and really without missing them, for years. At the moment the cure > appears worse then the symptoms in at least a few cases. If nothing else, > it compromises the elegant simplicity of Python that drew me here in the > first place! > > Assuming that people really _do_ want this feature, IMO the bar should be > raised so there are _zero_ backward compatibility issues. I don't say anything about pulling nested scopes (I don't think my opinion can change things in this respect) but I should insist that without explicit syntax IMO raising the bar has a too high impl cost (both performance and complexity) or creates confusion. [Andrew Kuchling] > >Assuming that people really _do_ want this feature, IMO the bar should be > >raised so there are _zero_ backward compatibility issues. > > Even at the cost of additional implementation complexity? At the cost > of having to learn "scopes are nested, unless you do these two things > in which case they're not"? > > Let's not waffle. If nested scopes are worth doing, they're worth > breaking code. Either leave exec and from..import illegal, or back > out nested scopes, or think of some better solution, but let's not > introduce complicated backward compatibility hacks. IMO breaking code would be ok if we issue warnings today and implement nested scopes issuing errors tomorrow. But this is simply a statement about principles and raised impression. IMO import * in an inner scope should end up being an error, not sure about 'exec's. We will need a final BDFL statement. regards, Samuele Pedroni. [View Less]

18 78

Re: 2.2a1: classmethod() and class attributes
by aahz＠rahul.net Sept. 21, 2001

Sept. 21, 2001

Aahz: > It's not particularly convenient for me to try out 2.2a1, so I'm just > going by what's written. One little hole that I don't see an answer to > is what happens when you do this: > > class C(object): > x = 0 > def foo(cls): > cls.x += 1 > foo = classmethod(foo) > > C.foo() Okay, after thinking about this a bit, I think that if the above code requires __dynamic__=1 to work, then the default for __dynamic__ should be changed. I don'… [View More]

2 3

copy, len and the like as 'object' methods?
by David Ascher Sept. 20, 2001

Sept. 20, 2001

I just came back from teaching Python on a cruise ship attended by mostly Perl folks. It was an interesting experience teaching Python with Randal in the audience =). One issue that came up is some of the lack of uniformity on what things are statements, methods and built-in functions. In the long-term version of the type/class unification work, things like int() become class constructors, which makes beautiful sense. The fact that int() calls __int__ methods fits nicely with type … [View More]

10 21

PEP 250
by Greg Ward Sept. 5, 2001

Sept. 5, 2001

Thomas -- have you been following the saga of patch #449054, part of the PEP 250 implementation. If I understand things correctly, this patch only partly implements PEP 250 -- the rest is waiting on a change to bdist_wininst. What's the status of this change? Going to make it in? Please see http://sourceforge.net/tracker/?func=detail&atid=305470&aid=449054&group_id… if you haven't already... Greg -- Greg Ward - geek-at-large gward(a)… [View More]

2 3

2.2a2 release next Wednesday
by Guido van Rossum Sept. 4, 2001

Sept. 4, 2001

Barry & I are planning to release Python 2.2a2 next Wednesday (August 19), according to the (updated) schedule in PEP 251. Tomorrow (Saturday, August 15) I plan to fork off a short-lived "release branch", from which the release will be done. Nobody but Barry & I should be checking things in on the release branch. We'll selectively merges the trunk into the branch if needed. We'll merge the branch back to the trunk after the release. Anybody who wants something to show up in 2.2a2 … [View More]

10 21

-Dwarn, long->double overflow (was RE: [Python-checkins] CVS: python/dist/src/Misc NEWS,1.219,1.220)
by Tim Peters Sept. 3, 2001

Sept. 3, 2001

[Guido] > + + A new command line option, -D<arg>, is added to control run-time > + warnings for the use of classic division. > ... > + Using -Dwarn issues a run-time warning about all uses of classic > + division for int, long, float and complex arguments. I'm unclear on why we warn about classic division when a float or complex is involved: C:\Code\python\PCbuild>python -Dwarn Python 2.2a2+ (#22, Aug 31 2001, 14:36:57) [MSC 32 bit (Intel)] on win32 Type "help", "… [View More]

6 14

Would it make sense to issue an extra alpha next week?
by Guido van Rossum Sept. 1, 2001

Sept. 1, 2001

When I was updating the NEWS file this morning, I realized that we've already added a truckload of nifty stuff in the 9 days since 2.2a2 was released: int overflows return longs, classic division warnings, subclassing builtins, super, getset, two fixes to float literals, the new GC API, and PyString_FromFormat[V]. I expect that I'll be concentrating on documentation for the type/class unification next. While writing the first piece of documentation, I realized that, sadly, several more … [View More]

3 2

Re: [Python-Dev] Would it make sense to issue an extra alpha next week?
by Jack Jansen Aug. 31, 2001

Aug. 31, 2001

I would be very much in favor of a 2.2a3 release next week, it would save me a lot of explaining differences between 2.2a2 on unix/win and on the Mac. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Re: [Python-checkins] CVS: python/dist/src/Modules _sre.c,2.63,2.64
by Fredrik Lundh Aug. 31, 2001

Aug. 31, 2001

sjoerd wrote: > > Modified Files: > _sre.c > Log Message: > Removed unreachable return to silence SGI compiler. > > ! /* shouldn't end up here */ > ! return SRE_ERROR_ILLEGAL; > } > > --- 1141,1145 ---- > } > > ! /* can't end up here */ > } I hate stuff like this: that line was there to make sure *I* don't mess up when developing SRE, not to deal with potentially broken compilers or misfired electrons. isn't there any … [View More]

4 3

Negative index in insert()
by Eric S. Raymond Aug. 31, 2001

Aug. 31, 2001

Given >>> a = [1, 2, 3, 4] because >>> a[-2] -3 I expected that a.insert(-2, 0) would yield [1, 2, 0, 3, 4]. It was a rude shock to discover that >>> a [0, 1, 2, 3, 4] In fact I think this may be the nastiest surprise Python has handed me since I started using it. The reference manual says "same as s[i:i] = [x] if i >= 0" which of course doesn't cover the i < 0 case. David Beasley's reference says "Inserts x at index i" which sounds like the … [View More]

4 4