Mailman 3 October 2003 - Python-Dev

Re: [Python-Dev] replacing 'global'
by Michael Chermside 28 Oct '03

28 Oct '03

Alex lists this flaw: > -- it's the wrong keyword, doesn't really _mean_ "global" Guido says: > I haven't heard anyone else in this thread agree with you on that > one. I certainly don't think it's of earth-shattering ugliness. Well, I agree. But I also agree with your point that it's certainly not earth-shattering... just a little confusing to newbies, who expect "global" to mean "global", not "module-wide". Not worth changing the language, but if you were to re-invent Python from the ground up, I'd consider it. Greg Ewing writes: > We'd be having two kinds of assignment, and there's no > prior art to suggest to suggest which should be = and > which :=. That's the "arbitrary" part. No one will ever confuse these, because no one will learn about := until long after = is well understood. The one spelled "=" will be "the normal one" and ":=" will be "the funny one". Just mentions: > (Alex noted in private mail that one disadvantage of this idea is that > it makes using globals perhaps TOO easy...) Indeed, that would be my concern. At least the word "global" has strong negative associations (mostly undeserved in this case since it really means "module-level" not "global" ;-). Skip writes: > It seems that use > of > x := 2 > and > x = 4 > should be disallowed in the same function so that the compiler can > flag such mistakes. I agree. When writing a function, we ALLOW name shadowing because we want the author of the function to be able to use local variables without having to know anything about the outer scope(s). But if the author of the function ALREADY KNOWS that there's an outer variable named "x" (MUST know it since she is modifying that outer variable), then there's no excuse for the poor choice of names... the local variable should be renamed to avoid the conflict. The "global" statement as it currently exists enforces this... if one assignment in a scope is "global", then ALL will be. I maintain that the use of := vs = should be the same... all or none! Despite Just's original preference for thinking of it as "find somplace and rebind", I would always wind up thinking of this as the "bind in some outer scope" operator. ----- Anyhow, that's as far as I got in reading the discussion so far. Whew! What a lot of traffic! -- Michael Chermside

1 0

Re: [Python-Dev] RE: cloning iterators again
by Guido van Rossum 28 Oct '03

28 Oct '03

> Ok on this point, the question was whether (the error-checking obfuscated > equivalent of) > > PyObject *m = PyImport_ImportModule("copy"); > PyObject_CallMethod(m, "deepcopy", x, memo); > > should be done inside a built-in __deepcopy__ implementation. It looks like > it will make a hell of a lot of quite slow calls to PyImport_ImportModule() > for structures like lists of generators, which is the kind of structure you > are interested in when you deepcopy generators. Yeah, you should ideally be able to cache the resuls of the import, except then your code wouldn't work when theer are multiple interpreters. Maybe using PyObject *modules = PySys_GetObject("modules"); PyObject *m = PyDict_Lookup(modules, "copy"); would be faster? PySys_GetObject() doesn't waste much time. :-) --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

RE: copysort patch, was RE: [Python-Dev]inline sort option
by Michael Chermside 28 Oct '03

28 Oct '03

Alex Martelli writes: > BTW, I think I should point out one POSSIBLE problem with > classmethods -- since unfortunately they CAN be called on an > instance, and will ignore that instance, this may confuse an > unsuspecting user. Alex, that's a good point, and one we should be careful of. However, (as you said) I suspect that the unsuspecting users will always call it with zero arguments. So long as that call always fails (preferably with a useful error message) I think we should be OK. So what if we make the error message maximally useful? Something like this: _privateObj= Object() def sorted(iteratorToSort=_privateObj): if iteratorToSort == _privateObj: raise TypeError('sorted is a classmethod of list ' + 'taking an iterator argument') else: <... normal body here ...> The only thing I've done here was to make the text of the message more helpful (I've even left the type of the exception as TypeError even though that might not be the most useful thing). Okay... there's one other change... if you pass 2 or more arguments, then it will complain that it expected "at least 0 arguments", but try it once with 0 arguments and you'll immediately understand. -- Michael Chermside

2 1

Re: [Web-SIG] Threading and client-side support
by John J Lee 28 Oct '03

28 Oct '03

[background for python-dev-ers: In the process of making my client-side cookie module a suitable candidate for inclusion in the standard library, I'm trying to make it thread-safe] On Tue, 28 Oct 2003 amk(a)amk.ca wrote: > On Tue, Oct 28, 2003 at 10:35:33AM +0000, John J Lee wrote: > > Thanks. So, in particular, httplib, urllib and urllib2 are thread-safe? > > No idea; reading the code would be needed to figure that out. That might not be helpful if the person reading it (me) has zero threading experience ;-) I certainly plan to gain that experience, but surely *somebody* already knows whether they're thread-safe? I presume they are, broadly, since a couple of violations of thread safety are commented in urllib2 and urllib. Right? John

2 1

RE: [Python-Dev] product()
by Michael Chermside 28 Oct '03

28 Oct '03

Nick Coghlan writes: > >>> if all(pred(x) for x in values): pass # alltrue > >>> if any(pred(x) for x in values): pass # anytrue > >>> if any(not pred(x) for x in values): pass # anyfalse > >>> if all(not pred(x) for x in values): pass # allfalse > > The names from the earlier thread do read nicely. . . +1 Very nicely indeed. -- Michael Chermside

1 0

list.sort, was Re: [Python-Dev] decorate-sort-undecorate
by Bob Ippolito 28 Oct '03

28 Oct '03

> [Gustavo Niemeyer wrote] > > > You can do reverse with [::-1] now. > > [Holger Krekel] > > sure, but it's a bit unintuitive and i mentioned not only reverse :-) > > > > Actually i think that 'reverse', 'sort' and 'extend' algorithms > > could nicely be put into the new itertools module. > > > > There it's obvious that they wouldn't mutate objects. And these > > algorithms > > (especially extend and reverse) would be very efficient as iterators > > because > > they wouldn't create temporary lists/tuples. > > To be considered as a possible itertool, an ideal candidate should: > > * work well in combination with other itertools > * be a fundamental building block > * accept all iterables as inputs > * return only an iterator as an output > * run lazily so as not to force the inputs to run to completion > unless externally requested by list() or some such. > * consume constant memory (this rule was bent for itertools.cycle(), > but should be followed as much as possible). > * run finitely if some of the inputs are finite (itertools.repeat(), > count() and cycle() are the only intentionally infinite tools) > > There is no chance for isort(). Once you've sorted the whole list, > there is no advantage to returning an iterator instead of a list. > > The problem with ireverse() is that it only works with objects that > support __getitem__() and len(). That pretty much precludes > generators, user defined class based iterators, and the outputs > from other itertools. So, while it may make a great builtin (which > is what PEP-322 is going to propose), it doesn't fit in with other > itertools. How about making islice be more lenient about inputs? For example x[::-1] should be expressable by islice(x, None, None, -1) when the input implements __len__ and __getitem__ -- but it's not. [::-1] *does* create a temporary list, because Python doesn't have "views" of lists/tuples. islice should also let you go backwards in general, islice(x, len(x)-1, None, -2) should work. -bob

3 2

Re: [Python-Dev] PEP 289: Generator Expressions (second draft)
by Guido van Rossum 27 Oct '03

27 Oct '03

I've checked in an update to Raymond's PEP 289 which (I hope) clarifies a lot of things, and settles the capturing of free variables. Raymond, please take this to c.l.py for feedback! Wear asbestos. :-) I'm sure there will be plenty of misunderstandings in the discussion there. If these are due to lack of detail or clarity in the PEP, feel free to update the PEP. If there are questions that need us to go back to the drawing board or requiring BDFL pronouncement, take it back to python-dev. --Guido van Rossum (home page: http://www.python.org/~guido/)

12 22

Let's table the discussion of replacing 'global'
by Skip Montanaro 27 Oct '03

27 Oct '03

[ on changing Python's global variable access mechanisms ] I'm going to make a suggestion. Let's shelve this topic for the time being and simply summarize the issues in an informational PEP aimed at Py3k. We don't even know (at least I don't) if we want an implicit search for outer scope variables or an explicit specification of which scope such variables should be defined in. If, for some reason, nested scopes make a quick exit in Py3k, this would all be moot anyway. It's not clear nested scopes really offer anything to Python other than muddled semantics and a more complex virtual machine implementation. Skip

4 4

Alternate notation for global variable assignments
by Zack Weinberg 27 Oct '03

27 Oct '03

I like Just's := concept except for the similarity to =, and I worry that the presence of := in the language will flip people into "Pascal mode" -- thinking that = is the equality operator. I also think that the notation is somewhat unnatural -- "globalness" is a property of the _variable_, not the operator. So I'd like to suggest instead :var = value # var in module scope :scope:var = value # var in named enclosing scope An advantage of this notation is that it can be used anywhere, not just in an assignment. This has primary value for people reading the code -- if you have a fairly large class method that uses a module variable (not by assigning it) somewhere in the middle, writing it :var means the reader knows to go look for the assignment way up top. This should obviously be optional, to preserve backward compatibility. zw

6 6

Inconsistent error messages in Py{Object, Sequence}_SetItem()
by Greg Ward 27 Oct '03

27 Oct '03

I just noticed a subtle inconsistency in the error messages when trying to assign to a tuple: >>> (1,)[0] = "foo" Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: object doesn't support item assignment >>> (1,)['foo'] = "foo" Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: object does not support item assignment Note the "doesn't" vs "does not". It's easily tracked down to PyObject_SetItem() and PySequence_SetItem() (in Objects/abstract.c). Is this deliberate, or a simple oversight? I'm inclined to assume the latter, and change "doesn't" to "does not" on the grounds that error messages are formal writing, and I was taught not to use contractions in formal writing. Any objections? Greg -- Greg Ward <gward(a)python.net> http://www.gerg.ca/ Eschew obfuscation!

5 5