Mailman 3 December 2003 - Python-Dev

test_unicode_file failing on trunk, Win98SE
by Tim Peters Dec. 3, 2003

Dec. 3, 2003

C:\Code\python\PCbuild>python ../lib/test/test_unicode_file.py test_directories (__main__.TestUnicodeFiles) ... ERROR test_equivalent_files (__main__.TestUnicodeFiles) ... ok test_single_files (__main__.TestUnicodeFiles) ... ERROR ====================================================================== ERROR: test_directories (__main__.TestUnicodeFiles) ---------------------------------------------------------------------- Traceback (most recent call last): File "../lib/test/… [View More]

3 2

RE: [Python-Dev] re: Tutorial: Brief Introduction to the Standard Libary
by Delaney, Timothy C (Timothy) Dec. 3, 2003

Dec. 3, 2003

> From: Arthur > > What is fundamentally wrong with copy(list) as an alternative > to list[:]? Well, it's slower ... it involves a Python function call and python code, whereas list[:] is all C. Of course, I didn't say it's a *lot* slower ... the actual copying is likely to take longer. However, I have to agree that I've almost never used copy or deepcopy. Tim Delaney

2 1

re: Tutorial: Brief Introduction to the Standard Libary
by Arthur Dec. 3, 2003

Dec. 3, 2003

Greg writes: >The result of all this is that I don't think I've *ever* used >copy() or deepcopy(). Whenever I've need to copy something I've >always used something type-specific such as list[:] or dict.copy(), >or written my own copying function. What is fundamentally wrong with copy(list) as an alternative to list[:]? Guess I am feeling invincible. Worst case, I can be told that I need to read a tutorial ;), Art

1 0

Re: [Python-Dev] minor interruption to service.
by Anthony Baxter Dec. 3, 2003

Dec. 3, 2003

>>> Skip Montanaro wrote > Anthony> In the meantime, if someone wants to take on the "upgrade to > Anthony> autoconf 2.59" task, I'd appreciate it very much. > > Do you mean 2.58? I looked here: > > http://ftp.gnu.org/gnu/autoconf/ > > and 2.58 appears to be the latest release. There's a 2.59 release announced on the autoconf list http://mail.gnu.org/archive/html/autoconf-maintainers/2003-11/msg00001.html but it's never appeared on the … [View More]

1 0

re: Tutorial: Brief Introduction to the Standard Libary
by Arthur Dec. 3, 2003

Dec. 3, 2003

Michael writes - >I don't want to be rude -- is English your first language? -- but I >found this article to be written in particularly baroque prose. English first and only. Same with Python. But if I have your demographics correct, I am of a different era. Baroque? I prefer Dylan, actually, >I'm not quite sure what your central point is. I believe you. >Well, I dunno. If it was my decision, there's no way it would be >mentioned in the built-ins Or in the tutorial … [View More]accompanying Python? Which is what is under discussion. >No changes here in a long while. I believe you again. >I don't think it's unreasonable at all. To me the copy module is >something you only need when you really need it, then you go looking >for it. If you understand a) when you need it b) it exists. Tutorial discussion. In the negative, if you like. It exists, it does this, and if you think you need it in a particular case are probably wrong, because...would serve my purpose. Perfectly. >Certainly, the failure to understand assignment and erroneous beliefs >that the copy module is necessary in a given situation go hand in hand. I don't think that view is inconsistent with anything I am asserting. >Assignment in Python *isn't* particularly subtle, though. My >impression is that it's people from e.g. C who get tripped up here, >not total newbies. That assertion is, IMO, an overly convenient way to put the matter to bed. It is an assertion with which I disagree. And I don't know who can claim particular insight or expertise on this kind of issue, and on what basis. Which is a problem. I can promise you that a background slanted by C was not at work in my case. It would be nice if it were. >Another reason might just be that copy() is implemented in Python... I prefer those kinds of reasons, than the newbies ones. Sound weighty and beyond my ken. The newbies ones don't. Sorry. >Have you ever used the copy module? I am *not* a beginner, and have >used it *once* (and I can't remember what for, either). In my view, there are usually more convenient ways to accomplish what copy is about, because you don't have to import copy. And we are just in a circular argument. And its use is discouraged, as a matter of style. More circles. But isn't it a harmless alternative, and a bit more explicit, in a good deal of circumstances - arguably. But I truly do understand that I may be missing something fundamental here. Performance issues? Who knows what else. I'm afraid to find out, actually. [OT] """ EuroPython: What do you like best about Python? MH: I think, probably, the single biggest plus of Python is that it blurs the distinction between using and programming a computer. """ One of my favorite Python quotes of recent vintage, BTW. Art [View Less]

2 1

Re: "groupby" iterator
by Christos Georgiou Dec. 3, 2003

Dec. 3, 2003

Guido van Rossum said: >> The nasty thing about it is that it smells a bit too much like a >> clever trick. It's really abusing the syntax to make it mean >> something different from what it usually means. > >It is also somewhat weak in that it only addresses lambdas with one >argument, and only allows a single reference to that argument in the >resulting expression, and can't really be made to handle method calls >without more gross notational hacks -- even … [View More]

5 4

Re: "groupby" iterator
by Christos Georgiou Dec. 3, 2003

Dec. 3, 2003

Guido van Rossum said: [Christos] >> A minor correction: the Voodoo approach handles fine method calls by >> defining a __call__ method in the Voodoo class; [...] >> >> lambda x: x.startswith("text") >> This works fine as: >> Voodoo().startswith("text") > >Hm. But the whole point of Voodoo is that the resulting object has a >__call__ method that evaluates the expression for a given argument. >How do you do that? (I suppose you can do it if you … [View More]

2 1

RE: [Python-Dev] Re: "groupby" iterator
by Robert Brewer Dec. 3, 2003

Dec. 3, 2003

After: > > > I agree with Thomas - rather than adding yet more specialised > > > functions, it would seem more sensible to optimize lambda > - probably > > > via special cases like this. > > > > One question that remains is: do a handful of these specialized > > functions make it possible to replace the remaining uses lambda > > completely? > > > > Looking at parts of my codebase nearly all uses of lambda are > > 'lambda … [View More]self: self.someattr'. > Guido van Rossum wrote: > Aha. Very interesting ideas both! > > So again, here we have a mechanism that's rather generic (lambda) > which is frequently used in a few stylized patterns (to extract an > attribute or field). So Raymond's new functions attrgetter and > itemgetter (whose names I cannot seem to remember :-) take care of > these. > > But, at least for attrgetter, I am slightly unhappy with the outcome, > because the attribute name is now expressed as a string literal rather > than using attribute notation. This makes it harder to write > automated tools that check or optimize code. (For itemgetter it > doesn't really matter, since the index is a literal either way.) > > So, while I'm not particularly keen on lambda, I'm not that keen on > attrgetter either. But what could be better? All I can think of are > slightly shorter but even more crippled forms of lambda; for example, > we could invent a new keyword XXX so that the expression (XXX.foo) is > equivalent to (lambda self: self.foo). This isn't very attractive. > Maybe the idea of recognizing some special forms of lambda and > implementing them more efficiently indeed makes more sense! I swore I wouldn't post here without lurking for a couple months, but I can't help myself. I mentioned on c.l.p. that extract() looked like a classic case for currying to me, using getattr() and currying the attribute name. So that instead of (lambda self: self.foo), you'd end up with (rightcurry(getattr, 'foo')), which might give some of the speed increase desired. If one could assure that each object in an iteration had that 'foo' attribute at the same mem location (for example, instances of a class with a common function def), you could optimize further. > Now the question remains, would it be better to hide this and simply > use it under the hood as an alternative way of generating code for > lambda, or should it be some sort of standard library module, to be > invoked explicitly? In favor of the latter pleads that this would > solve the semantic differences with lambda when free variables are > involved: obviously X+q would evaluate q only once, while > (lamda X: X+q) evaluates q on each invocation. Remember that for > generator expressions we've made the decision that > (X+q for X in seq) > should evaluate q only once. Which currying would do, no? Instead of (lambda X: X+q) you get (rightcurry(operator.add, q)). The reason I bring it up is because I see curry applying in many more and more powerful situations than just extract(). Kill 16 birds with one stone. Obviously, there's been some work on curry already in PEP 309, which included the community response of "Lambda is good enough." Perhaps it's not in this case. Criticism welcomed, constructive or destructive. :) Robert Brewer MIS Amor Ministries fumanchu(a)amor.org [View Less]

6 8

pprint and list/tuple/dict subclasses
by Walter Dörwald Dec. 3, 2003

Dec. 3, 2003

Currently pprint refuses to prettyprint subclasses of list, tuple and dict. Does it make sense to change that for 2.4? Of course once __repr__() is overwritten by a subclass, pprint has to use that instead of its own formatting. Bye, Walter Dörwald

4 10

Re: [Python-Dev] Re: "groupby" iterator
by Phillip J. Eby Dec. 3, 2003

Dec. 3, 2003

At 11:14 AM 12/3/03 -0800, Guido van Rossum wrote: > > I think this is the key thing here. Lambda in its full form is very > > flexible and wide ranging - but 90% of the time, this flexibility > > isn't needed. And everything pays a cost for that flexibility, even > > when it's not used. > > > > Something that did that 90%, fast and efficiently, while leaving > > lambda for the few remaining cases where its flexibility is needed > > (possibly with … [View More]

1 0