Mailman 3 August 2001 - Python-Dev

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

23 Feb '05

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 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.

18 78

Re: 2.2a1: classmethod() and class attributes
by aahz＠rahul.net 21 Sep '01

21 Sep '01

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't find the arguments about changing __class__ to be particularly persuasive, but I think the above code *is* closely related to standard Python idioms that should work by default. +1 on changing __dynamic__ or at least enabling some kind of class variable mutability by default. -- --- Aahz (@pobox.com) Hugs and backrubs -- I break Rule 6 <*> http://www.rahul.net/aahz/ Androgynous poly kinky vanilla queer het Pythonista I don't really mind a person having the last whine, but I do mind someone else having the last self-righteous whine.

2 3

copy, len and the like as 'object' methods?
by David Ascher 20 Sep '01

20 Sep '01

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 conversion mechanisms. However, there are a few things which still seem oddballish: copy.copy(), copy.deepcopy(), len() These basically call magic methods of their arguments (whether tp_slots or __methods__), and many languages implement them strictly as object methods. str() and repr() are a little weird -- I'm not sure which one will gain 'class constructor' status when the type/class unification work is done -- from the definition I'd say repr() should win, but the name is quite unfortunate given its new role... Guido, thoughts? Summary: Should copy, deepcopy and len be added as object methods? And if yes, how? Not all objects are copyable or measurable. Interfaces seem the right way to do this, but interfaces aren't in the plans so far that I know... What about a stringification method? --david

10 21

PEP 250
by Greg Ward 05 Sep '01

05 Sep '01

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)python.net http://starship.python.net/~gward/ Just because you're paranoid doesn't mean they *aren't* out to get you.

2 3

2.2a2 release next Wednesday
by Guido van Rossum 04 Sep '01

04 Sep '01

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 would be wise to check it in today or before dawn tomorrow. Please mail me if you need me to wait for something specific. PS Martin: I currently have two failing tests! - test_b1 crashes (in the "float" subtest): Traceback (most recent call last): File "../Lib/test/test_b1.py", line 259, in ? if float(unicode(" \u0663.\u0661\u0664 ")) != 3.14: ValueError: invalid literal for float(): \u0663.\u0661\u0664 - test_format.py fails: u'abc %\\\u3000' % 1 works? ... no Unexpected exceptions.ValueError : "unsupported format character '\\' (0x5c) at index 5" I expect these are casualties of the --disable-unicode checkins. --Guido van Rossum (home page: http://www.python.org/~guido/)

10 21

-Dwarn, long->double overflow (was RE: [Python-checkins] CVS: python/dist/src/Misc NEWS,1.219,1.220)
by Tim Peters 04 Sep '01

04 Sep '01

[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", "copyright", "credits" or "license" for more information. >>> 2./3. __main__:1: DeprecationWarning: classic float division 0.66666666666666663 >>> Given that this is going to return the same result even in Python 3.0, what is it warning me about? That is, as an end user, I'm being warned about behavior I can't do anything about, and behavior that Python isn't going to change anyway. Different issue: I would like to add OverflowError when coercion of long to float yields a senseless result. PEP 238 mentions this as a possibility, and >>> from __future__ import division >>> x = 1L << 3000 >>> x/(2*x) -1.#IND >>> really sucks. For that matter, >>> float(1L << 3000) 1.#INF >>> has always sucked; future division just makes it suck harder <wink>. Any objections to raising OverflowError here? Note this is a bit painful for a bogus reason: PyFloat_AsDouble returns a double, and nothing in the codebase now checks it for a -1.0 error return (despite that it can already produce one). So half the effort would be repairing code currently ignoring the possibility of error. Third issue: I don't see a *good* reason for the future-division x/(2*x) above not to return 0.5. long_true_divide could be made smart enough to do that (more generally, to return a good float approximation whenever the true result is representable as a float).

6 14

Would it make sense to issue an extra alpha next week?
by Guido van Rossum 01 Sep '01

01 Sep '01

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 advanced things aren't available in 2.2a2 yet. The next alpha is planned for Sept. 19, almost three weeks off still. Does anybody object against the release of an extra release, 2.2a3, around Sept. 5? We could do 2.2a4 on Sept. 19, or a week later if the schedule gets too crowded. --Guido van Rossum (home page: http://www.python.org/~guido/)

3 2

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

31 Aug '01

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 31 Aug '01

31 Aug '01

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 way to tell the SGI compiler to stop whining about this? </F>

4 3

Negative index in insert()
by Eric S. Raymond 31 Aug '01

31 Aug '01

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 behavior I was expecting but didn't get. Is this a deliberate design choice, an oversight, or a plain bug? If it's a choice, it's damn poorly documented -- this deserves at least a footnote in the list methods table. If it's an oversight or bug, I volunteer to fix it. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> "America is at that awkward stage. It's too late to work within the system, but too early to shoot the bastards." -- Claire Wolfe

4 4