Mailman 3 May 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

%b format?
by Greg Wilson June 6, 2001

June 6, 2001

I would like to add a "%b" format for converting numbers to binary format (1's and 0's). I realize this isn't a C-ism, but it would be very useful for teaching purposes, as newcomers find 101101 a lot easier to understand than 0x2D. Reactions? Greg ----------------------------------------------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this … [View More]

10 23

Re: [Python-checkins] CVS: python/dist/src/Modules stropmodule.c,2.81,2.82
by Greg Stein June 5, 2001

June 5, 2001

On Mon, May 14, 2001 at 07:14:46PM -0700, Guido van Rossum wrote: > Update of /cvsroot/python/python/dist/src/Modules > In directory usw-pr-cvs1:/tmp/cvs-serv26415/Modules > > Modified Files: > stropmodule.c > Log Message: > Add warnings to the strop module, for to those functions that really > *are* obsolete; three variables and the maketrans() function are not > (yet) obsolete. > > Add a compensating warnings.filterwarnings() call to test_strop.py. > &… [View More]

9 35

One more dict trick
by Tim Peters June 5, 2001

June 5, 2001

If anyone has an app known or suspected to be sensitive to dict timing, please try the patch here. Best I've been able to tell, it's a win. But it's a radical change in approach, so I don't want to rush it. This gets rid of the polynomial machinery entirely, along with the branches associated with updating the things, and the dictobject struct member holding the table's poly. Instead it relies on that i = (5*i + 1) % n is a full-period RNG whenever n is a power of 2 (that's what … [View More]

8 18

RE: What happened to Idle's extend.py?
by Tim Peters June 4, 2001

June 4, 2001

Guido's on vacation. Anyone have an answer for this? I don't, and can't make time to dig into now. If you can, David's address showed up as mailto:boogiemorg@aol.com > -----Original Message----- > From: python-list-admin(a)python.org > [mailto:python-list-admin@python.org]On Behalf Of David Morgenthaler > Sent: Wednesday, May 23, 2001 6:20 PM > To: python-list(a)python.org > Subject: What happened to Idle's extend.py? > > > Idle-0.3, shipped with Python 1.5.2 had … [View More]

2 2

Damn... I think I might have just muffed a checkin
by Skip Montanaro June 1, 2001

June 1, 2001

I just updated httplib.py to expand the list of names in its __all__ list. I was operating on version 1.34. After the checkin I am looking at version 1.34.2.1. I see that Lib/CVS/Tag exists in my directory tree and says "release21-maint". Did I muff it? If so, how should I do an unmuff operation? Skip

4 6

One more dict trick
by Mark Favas May 31, 2001

May 31, 2001

Tried the patch (thanks, Tim!) - but I guess the things I'm running aren't too sensitive to dict speed <grin>. I see a slight speed-up, around 1-2%... Nice, elegant patch that should go places! Maybe the bio-informatics people on c.l.py (Andrew Dalke?) would be interested in trying it out? -- Mark Favas - m.favas(a)per.dem.csiro.au CSIRO, Private Bag No 5, Wembley, Western Australia 6913, AUSTRALIA

1 0

weird webbrowser behavior
by Skip Montanaro May 31, 2001

May 31, 2001

I'm using Gnome under Mandrake 8.0 and getting very strange results using webbrowser (indirectly via pydoc). Apparently, Gnome's init code sets the BROWSER environment variable to "nautilus" (much to my surprise) and webbrowser trusts it as the god's honest truth, even though nautilus has not been registered with the webbrowser module (am I supposed to add that sort of stuff to site.py?). Accordingly, _tryorder is ['nautilus'] but doesn't appear in _browser.keys() is ['lynx', 'links', '… [View More]

3 3

Re: 2.1 strangness
by Skip Montanaro May 31, 2001

May 31, 2001

>>>>> "Robin" == Robin Becker <robin(a)jessikat.fsnet.co.uk> writes: Robin> from httplib import * Robin> class Bongo(HTTPConnection): Robin> pass ... Robin> NameError: name 'HTTPConnection' is not defined It was a brain fart on my part when creating httplib.__all__. HTTPConnection was not included in that list. I will check in a fix. In the 2.1 release __all__ was defined as __all__ = ["HTTP"] I have changed that to … [View More]

2 2

RE: Iteration variables and list comprehensions
by David Beazley May 31, 2001

May 31, 2001

Greg Ewing writes: > Another advantage of changing both together is that > we can continue to describe listcomp semantics in terms > of for-loops instead of lambdas. Is this really an advantage? To me, the lambda semantics are a lot more intuitive in terms of matching the way that list comprehensions are actually used and ought to work (although I will agree that the for-loop explanation is a good way to describe the internals of what a list comprehension actually does). I think … [View More]

1 0