Mailman 3 April 2002 - 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: [Python-Dev] trace.py and the obscurity of Tools/scripts/ (was: Unittest list)
by Michael Hudson 06 Jun '02

06 Jun '02

Zooko <zooko(a)zooko.com> writes: > Since even python-dev'ers find ancient copies of trace.py on ftp > sites before they find the one in the Tools/scripts/ directory, and > since the debian package of Python 2.2 comes without a > Tools/scripts/ directory at all, I conclude that the Tools/scripts/ > directory it isn't doing its job very well. I suggest it either be > killed or fixed. I'm not sure how to do the latter -- link to it > from the doc pages? Kill it and I'll be after you with an axe. Admittedly there's a lot of cruft that should be removed, rewritten or reorganised, but there's some mighty useful stuff there too (eg. logmerge.py). I don't see why I should suffer just because other people don't know where to look... Cheers, M. -- Darned confusing, unless you have that magic ingredient coffee, of which I can pay you Tuesday for a couple pounds of extra-special grind today. -- John Mitchell, 11 Jan 1999

9 16

Re: Stability and change
by Guido van Rossum 29 May '02

29 May '02

On c.p.py, Alex Martelli wrote: > Linus Thorvalds seems to have done pretty well with picking TWO > middle grounds -- two parallel tracks for Linux, "stable" and > "experimental". I'm moving the discussion to python-dev, since that's where I think it belongs. Personally, I hate the way Linux releases are numbered (I can never tell which one is stable and which one isn't). But I could get used to it if we used the micro version number to indicate stability -- in particular, 2.2 would be experimental, and 2.2.1 and following would be stable; 2.3 would be experimental, and 2.3.1 stable. This would require only a very slight change of policy: PEP 6 would have to be renamed from "Bug Fix Releases" to "Stable Releases". It wouldn't even have to loosen up its prohibitions; quoting: """ Prohibitions Patch releases are required to adhere to the following restrictions: 1. There must be zero syntax changes. All .pyc and .pyo files must work (no regeneration needed) with all patch releases forked off from a feature release. 2. There must be zero pickle changes. 3. There must be no incompatible C API changes. All extensions must continue to work without recompiling in all patch releases in the same fork as a feature release. Breaking any of these prohibitions requires a BDFL proclamation (and a prominent warning in the release notes). """ This doesn't prevent us to evolve the standard library. It doesn't prohibit adding new built-in functions, although I'd be reluctant to do so. It would, however, require a big change in how we present new releases to the world. Currently, Once 2.x is out, anything running 2.(x-1) is labeled obsolete, or at least oldfashioned. That needs to change! The website needs to present at least two options: - Bleeding edge (e.g. 2.3 alpha, or 2.3 once it's out) - Stable (e.g. 2.2.1) There may be more options: Zope 2 currently requires 2.1.2 and will require 2.1.3 as soon as it's out; other people still swear by 1.5.2. (I don't think that the 1.6 and 2.0 lines are still popular.) --Guido van Rossum (home page: http://www.python.org/~guido/)

38 173

timeoutsocket.py
by Bernard Yue 06 May '02

06 May '02

Hi Guys, What is the status of integrating timeoutsocket.py into standard library? Are there any body responsible for it currently? If not I would like to give it a shot. Bernie -- There are three schools of magic. One: State a tautology, then ring the changes on its corollaries; that's philosophy. Two: Record many facts. Try to find a pattern. Then make a wrong guess at the next fact; that's science. Three: Be aware that you live in a malevolent Universe controlled by Murphy's Law, sometimes offset by Brewster's Factor; that's engineering. -- Robert A. Heinlein

5 11

iterzip()
by Raymond Hettinger 02 May '02

02 May '02

What do you guys think about the merits of an iterzip() function that behaves like zip() but returns an iterator instead of a list? Raymond Hettinger P.S. There is a patch for experimentation at http://www.python.org/sf/549662

15 85

millions of tuples
by Ian Kjos 01 May '02

01 May '02

Two things spoken by Guido: > But millions of tuples are not uncommon. They're probably the only > thing to worry about here. > Unfortunately, the visit API doesn't make it easy to watch this[*]; a > tuple calls visit() on its items but learns nothing except whether it > failed. (I've never seen a visit() implementation that could fail, so > I'm not sure even why the return code exists.) * "this" is the number of tracked objects visited during a GC scan, as described by MvL If visit() does something sensible (like traversing a directed, potentially cyclic graph), then the only way it could fail is to not return. No doubt there is a clear record of who calls this function. Why not we change the semantics of visit() in this case to provide the required information? Make visit() return a non-negative integer for "number of tracked objects seen". If someone can find a good reason for error codes, then there is the negative half of the integer number line. (/me is going out on a limb and hypothesizing that visit() is in C for all relevant cases.)

2 1

Making None a keyword
by Guido van Rossum 01 May '02

01 May '02

I'd like to make None a keyword. This prevents dumb users from assigning to it and screwing themselves, and can cause a slight speedup because using None avoids two dict lookups. - Any objections? - Can somebody help me implement this? I've got the parser changes ready, but not the compiler changes. Believe it or not, Zope3 contains code that will break with this change: there are functions with a default argument of the form None=None as a speedup hack. I think this is an argument *for* the change. :-) --Guido van Rossum (home page: http://www.python.org/~guido/)

17 51

Re: os.environ.copy()['COPY_HUH'] = "not really"
by Gustavo Niemeyer 30 Apr '02

30 Apr '02

> Under Python2.1 and earlier (back to 1.5.2): > >>> import os > >>> os.environ.copy()['COPY_HUH'] = "not really" > >>> print os.environ['COPY_HUH'] > not really > > Under even 2.3a0 (CVS): > >>> import os > >>> os.environ.copy()['COPY_HUH'] = "not really" > >>> os.system("echo $COPY_HUH") > not really > 0 Here's the problem: >>> print os.environ.__class__ os._Environ >>> copy = os.environ.copy() >>> print copy.__class__ os._Environ It's not a real dictionary, but an os._Environ class. Copying it creates instances of the same class, and that class' behavior is to insert the item in the environment. I belive this should be avoided in this case, returning a true dictionary from copy(). I'll send a patch to SourceForge, if you haven't done so yet. -- Gustavo Niemeyer [ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]

1 1

ServerSocket patch
by Michael Gilfix 30 Apr '02

30 Apr '02

I've just logged the small patch to ServerSocket.py into sourceforge that "fixes", or rather makes apparent the bug Bernard had discovered when writing his unit test for the socket module. The fix was simple: in keeping with the style of the module, a member variable was added to the ThreadingMixIn class 'daemon_threads' which decideds whether threads start in daemon mode. Thus to fix the server problem in the previous thread of convo, Bernard needed to do: class ThreadingTCPServer( SocketServer.ThreadingMixIn, MyTCPServer): daemon_threads = 1 for his final version of the server. Or until this patch is accepted, he could subclass off the threadingMixIn class and change the process_request function. The patch is #550765 in SF. -- Mike -- Michael Gilfix mgilfix(a)eecs.tufts.edu For my gpg public key: http://www.eecs.tufts.edu/~mgilfix/contact.html

2 2

timeoutsocket patch
by Michael Gilfix 30 Apr '02

30 Apr '02

I'm working with Bernard Yue to implement a timeout socket patch. Our question: is it fair to assume that any OS that supports sockets also supports select? Or do have to have added checks? -- Mike -- Michael Gilfix mgilfix(a)eecs.tufts.edu For my gpg public key: http://www.eecs.tufts.edu/~mgilfix/contact.html

3 8