Python-Dev May 2001

python-dev@python.org

59 participants
151 discussions

RE: [Python-Dev] Those import related syntax errors again...

by Samuele Pedroni

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.

16 years, 8 months

%b format?

by Greg Wilson

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 message in error or there are any problems please notify the originator immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. This footnote confirms that this email message has been swept by Baltimore MIMEsweeper for Content Security threats, including computer viruses.

20 years, 4 months

Re: [Python-checkins] CVS: python/dist/src/Modules stropmodule.c,2.81,2.82

by Greg Stein

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. > > Add this to the NEWS. Something that I ran into the other day... >>> ob = some_object_implementing_the_buffer_interface >>> string.find(ob, '.') (fails because ob does not define the .find method) >>> strop.find(ob, '.') (succeeds) The point is that strop uses the t# to get a ptr/len pair to do its work. Thus, it can work on many things that export the buffer interface. Dropping strop means we no longer have many of those functions. Instead, the functionality must be copied to *every* object that implements the buffer interface. We can say ob.find() now, but we can't say find(ob) any longer. And saying that all objects (which implement the buffer API) must now implement a bunch of "standard" methods is awfully burdensome. In my particular case, I was trying to do a find on a BufferObject referring to a subset of another object. Blam. No good. Thankfully, when I did a find() on a mmap object, it worked simply because mmaps happen to define a .find method. [ of course, the find method on an mmap was totally broken, but I checked in a fix for that (last week or so) ] So... my question is: is there any way that we can retain a generic find() (and similar functions from the string/strop module) that operates on any type that implements the buffer API? Maybe there is some way we can do a mixin for Python types? e.g. "this mixin implements some standard methods for 8-bit character data (using the buffer API), which can be mixed into new Python types" That would reduce the burden for new types. Thoughts? Cheers, -g -- Greg Stein, http://www.lyra.org/

20 years, 4 months

One more dict trick

by Tim Peters

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 guarantees it will visit every slot), but perturbs that by adding in a few bits from the full hash code shifted right each time (that's what guarantees every bit of the hash code eventually influences the probe sequence, avoiding simple quadratic-time degenerate cases).

20 years, 4 months

RE: What happened to Idle's extend.py?

by Tim Peters

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 an extend.py module that was > used to extend Idle. We've used this extensively, building entire > "applications" as Idle extensions. > > Now that we're moving to Python 2.1, we find the same old directions > for extending Idle (in extend.txt), but there appears to be no > extend.py in Idle-0.8. > > Does anyone know how we can add extensions to Idle-0.8? > > Thanks in advance, > David > -- > http://mail.python.org/mailman/listinfo/python-list

20 years, 4 months

Damn... I think I might have just muffed a checkin

by Skip Montanaro

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

20 years, 4 months

One more dict trick

by Mark Favas

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

20 years, 4 months

weird webbrowser behavior

by Skip Montanaro

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', 'netscape', 'kfm', 'mozilla']. I think webbrowser should either ignore elements of BROWSER if they have not previously been registered (and can't be found by _iscommand) or try to register them using GenericBrowser. Users are apparently not the only people setting BROWSER, so the comment in the code: # It's the user's responsibility to register handlers for any unknown # browser referenced by this value, before calling open(). seems like flawed logic to me. Skip

20 years, 4 months

Re: 2.1 strangness

by Skip Montanaro

>>>>> "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 __all__ = ["HTTP", "HTTPResponse", "HTTPConnection", "HTTPSConnection", "HTTPException", "NotConnected", "UnknownProtocol", "UnknownTransferEncoding", "IllegalKeywordArgument", "UnimplementedFileMode", "IncompleteRead", "ImproperConnectionState", "CannotSendRequest", "CannotSendHeader", "ResponseNotReady", "BadStatusLine", "error"] and will check the change into CVS shortly. (Thomas, keep an eye open for this as an addition to 2.1.1.) The workaround I would choose is to not use from "httplib import *": import httplib class Bongo(httplib.HTTPConnection): pass Robin> Changing the * to HTTPConnection in ttt.py removes the problem. Yup, that will also work. Before anyone asks, "Who died and make Skip King?", the scenario as I recall it was that the semantics of __all__ got settled on during discussions on python-dev (the goal of __all__ being to minimize namespace pollution by "from ... *"), but nobody stepped up immediately to do the gtunt work, so I volunteered. The problem in relying on one person (well, at least this one person) to do this was that I had only the following tools at my disposal to decide what belonged in __all__: * what was documented in the lib reference manual (which was at times incomplete) * my experience with the various modules (some of which was specialized, some of which was nonexistent) * the standard library (which generally doesn't use "from ... *" much) * input from python-dev (whose members also appear not to use "from ... *" very liberally) In retrospect, I probably should have polled c.l.py with a summary of what I came up with before the 2.1 ship date. If people would like me to do that now (before 2.2 gets anywhere close to release) to try and fill in as many missing symbols as possible, let me know. -- Skip Montanaro (skip(a)pobox.com) (847)971-7098

20 years, 4 months

RE: Iteration variables and list comprehensions

by David Beazley

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 I would be opposed to changing normal for-loop semantics to match any change made in list-comprehensions. There are too many cases where you use a loop variable after finishing a loop and I suspect that this would break a huge amount of code. For example: for i in r: ... if whatever: break print i Besides, the semantic mismatch created between a listcomp and a for-loop pales in comparison to the mismatch that currently exists between the behavior of listcomps and all of the other operators. Of course, that's just my opinion--I could be wrong. > Then we won't have to go > into hiding until Guido dies or lifts the fatwah against us. fatwah? Uh... should I start talking to the witness protection program folks? Cheers, Dave

20 years, 4 months

Jump to page:

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev May 2001