Mailman 3 February 2004 - Python-Dev

PEP 326
by Josiah Carlson Feb. 22, 2004

Feb. 22, 2004

Hey python-dev-ers, As an update, I've just submitted my final changes to PEP 326, along with a link to my recommended implementation. The latest version of the PEP (until it gets updated in CVS) is available here: http://www.ics.uci.edu/~jcarlson/pep326/pep-0326.html The implementation will be available at the below link until I finish grad school: http://www.ics.uci.edu/~jcarlson/pep326/extremes.py As suggested by Andrew P. Lentvorski Jr. off-list, the names of the singletons are UniversalMaximum and UniversalMinimum, due to their self-documenting nature. If anyone doesn't understand what they are, just by reading their names, then jeebus help them. For those that want or need shorter names, uMax and uMin are equivalent aliases in extremes.py Unless something major happens, this is likely the last message python-dev will hear from me about PEP 326. Thank you for all the comments/questions/etc. during the PEP's lifetime. - Josiah

1 0

PyCon talks and schedule posted
by PyCon Chair Feb. 21, 2004

Feb. 21, 2004

First of all, don't forget that early-bird reg ends midnight Sunday Feb 22. We've now got a list of talks and a planned schedule: http://www.pycon.org/dc2004/talks/ http://www.python.org/pycon/dc2004/schedule.html We've also added Guido van Rossum and Bruce Eckel as keynote speakers: http://www.pycon.org/dc2004/talks/keynote PyCon is a community-oriented conference targeting developers (both those using Python and those working on the Python project). It gives you opportunities to learn about significant advances in the Python development community, to participate in a programming sprint with some of the leading minds in the Open Source community, and to meet fellow developers from around the world. The organizers work to make the conference affordable and accessible to all. DC 2004 will be held March 24-26, 2004 in Washington, D.C. at the GWU Cafritz Conference Center. The keynote speakers are Mitch Kapor, Guido van Rossum, and Bruce Eckel. There will be a four-day development sprint before the conference (March 20-23). We're looking for volunteers to help run PyCon. If you're interested, subscribe to http://mail.python.org/mailman/listinfo/pycon-organizers Don't miss any PyCon announcements! Subscribe to http://mail.python.org/mailman/listinfo/pycon-announce You can discuss PyCon with other interested people by subscribing to http://mail.python.org/mailman/listinfo/pycon-interest The central resource for PyCon DC 2004 is http://www.pycon.org/dc2004/ -- Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/ "Do not taunt happy fun for loops. Do not change lists you are looping over." --Remco Gerlich, comp.lang.python

1 0

string.split
by Andreas Beyer Feb. 21, 2004

Feb. 21, 2004

The documentation of string.split() says: "... The returned list will then have one more item than the number of non-overlapping occurrences of the separator in the string. ..." The behaviour of split with Python 2.3.3 is: >>> '\tb'.split() ['b'] # Bug? >>> '\tb'.split('\t') ['', 'b'] >>> 'a\t\tb'.split() ['a', 'b'] >>> 'a\t\tb'.split('\t') ['a', '', 'b'] >>> I think there are different interpretations of what a separator is. That is not necessarily a bug, because without stripping a new-line at the end of the string would yield a non-intuitive result list. However, the difference between split with and without the 'sep' argument should be documented. Andreas

3 3

logging exceptions
by Jeremy Hylton Feb. 20, 2004

Feb. 20, 2004

Zope 2.7 is using the logging package internally as the implementation for its old zLOG API. We've run into one problem, probably caused by carelessness on our part. zLOG allows you to pass exc_info to be logged, but logging only allows you to specify a flag saying whether the current exception should be logged. (I recall that this was discussed at length, but not why the current solution was reached.) There are several call sites that depend on this feature to capture an exception, try to recover gracefully or log a traceback if recovery is impossible. So we depend on this feature, but can't get it out of logging very easily. We've come up with this as a work-around: prev = sys.exc_info() if prev != exc_info: try: raise exc_info[0], exc_info[1], exc_info[2] except: pass else: prev = None logging.error(..., exc_info=1) if prev is not None: try: raise prev[0], prev[1], prev[2] except: pass This seems like a pretty gross way to set and restore the current exception, but it would work. Would it be possible to add a feature to logging to allow us to specify the traceback directly? The only reason we need to set the current exception is this code in logging: def _log(self, level, msg, args, exc_info=None): # ... if exc_info: exc_info = sys.exc_info() record = self.makeRecord(self.name, level, fn, lno, msg, args, exc_info) self.handle(record) I suppose another option is to create a Logger subclass with a different _log() method. Jeremy

2 2

Re: PEP 309 misuses the term "currying"
by David Abrahams Feb. 20, 2004

Feb. 20, 2004

Gareth McCaughan <gmccaughan(a)synaptics-uk.com> writes: > Dave Abrahams wrote: > >> The operation performed by the operator described here is actually >> called "Partial Application". A good definition of currying can be >> found in http://tinyurl.com/3d6w6 and http://tinyurl.com/ly29. > > I disagree. Currying is turning a function that takes its arguments > all at once as a tuple into a function that takes them one at a time > by partial application. > So if f(1,2,3)=64 and F is the curried version > of f, then F(1)(2)(3)=64. You've introduced some syntactic confusion. 1. The syntax you show above for the uncurried function f(1,2,3) means "pass all the arguments in a single tuple" in some languages -- the same ones that give "f x" the meaning "invoke f with argument x". In Python, the parens are part of the function call operator. It means "pass the arguments one at a time" (internals and implementation details aside). 2. Whether or not a language supports the syntax you show above for partial application can be seen as independent of the meaning of currying. > The idea of currying arose in a context where functions are > fundamentally single-argument; it's a way of converting between > two different ways of building multiple-argument functions > on top of a single-argument-only base. That's handy for > mathematicians and theoretical computer scientists, who > like to keep their underlying concepts as few and as simple > as possible. Sure. > But in Python, and in many other programming > languages, functions with multiple arguments aren't built on > a single-argument substrate Depends how you look at it, but I know what you mean. > so there are *three* options > for passing multiple arguments to a function. > - Collect args into a tuple, pass that. > - Just pass multiple arguments. > - Pass arguments one at a time using partial application. And the language doesn't support the third one by default. > And the middle one, the one that isn't generally considered > by mathematicians doing lambda calculus, happens to be the > *usual* case. How you apply the notion of "currying" to Python, > then, depends on which pair of argument-passing conventions > you choose to assimilate; in other words, on which of the two > distinctions at work here you choose to emphasize. Currying > is ... > > 1. "Turning a function that takes a single tuple argument into > one that takes multiple arguments." > > 2. "Turning a function that takes it arguments all at once into > one that takes them one at a time." > > According to #1, what PEP309 calls currying is no such thing. > According to #2, what PEP309 calls currying *is* currying. > > It looks to me as if the second usage is the dominant one, in > which case I think PEP309 is fine. I dont' see how you can make that claim. Curry is a one argument function that accepts a function and returns a new function; I hope we can agree on that. If this were currying according to your description, the result would always be callable with a single argument (yielding, perhaps, another function object). >>> from pep309 import curry >>> def add(a, b): ... return a+b ... >>> curry(add) <curry.curry object at 0x008E3430> >>> curry(add)(1) Traceback (most recent call last): File "<stdin>", line 1, in ? File "curry.py", line 12, in __call__ return self.fn(*(self.args + args), **d) TypeError: add() takes exactly 2 arguments (1 given) >>> Even if we ignore the syntax issues I brought up earlier, this doesn't appear to resemble what you've been describing at all. If Python needs a function like the one being proposed in the PEP (I'm not convinced it does, since IIUC lambda covers that ability nicely), it should probably be called "bind" and should use something like the Boost interface, which doesn't tread on any existing meanings for the word and has been shown to be flexible, powerful, and useful. http://www.boost.org/libs/bind -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

Re: [Python-Dev] new syntax for wrapping (PEP 318)
by Phillip J. Eby Feb. 20, 2004

Feb. 20, 2004

At 06:48 PM 2/19/04 -0500, Jewett, Jim J wrote: >I think this may be one reason this didn't happen before; >wrapping is good, but it isn't entirely obvious how to >write it or exactly what it should mean. Given that, it >might be premature to use up the [] syntax. Well, I personally prefer the 'as' syntax for both class and function decorators. As for the semantics of class decorators, I would propose that they be identical to the semantics for function decorators. I don't think there's a point to adding more ways to spell '__metaclass__'. :)

3 3

Re: PEP 309 misuses the term "currying"
by Gareth McCaughan Feb. 20, 2004

Feb. 20, 2004

[Dave, this may be the second copy of this message you receive; sorry about that.] Dave Abrahams wrote: > The operation performed by the operator described here is actually > called "Partial Application". A good definition of currying can be > found in http://tinyurl.com/3d6w6 and http://tinyurl.com/ly29. I disagree. Currying is turning a function that takes its arguments all at once as a tuple into a function that takes them one at a time by partial application. So if f(1,2,3)=64 and F is the curried version of f, then F(1)(2)(3)=64. The idea of currying arose in a context where functions are fundamentally single-argument; it's a way of converting between two different ways of building multiple-argument functions on top of a single-argument-only base. That's handy for mathematicians and theoretical computer scientists, who like to keep their underlying concepts as few and as simple as possible. But in Python, and in many other programming languages, functions with multiple arguments aren't built on a single-argument substrate, so there are *three* options for passing multiple arguments to a function. - Collect args into a tuple, pass that. - Just pass multiple arguments. - Pass arguments one at a time using partial application. And the middle one, the one that isn't generally considered by mathematicians doing lambda calculus, happens to be the *usual* case. How you apply the notion of "currying" to Python, then, depends on which pair of argument-passing conventions you choose to assimilate; in other words, on which of the two distinctions at work here you choose to emphasize. Currying is ... 1. "Turning a function that takes a single tuple argument into one that takes multiple arguments." 2. "Turning a function that takes it arguments all at once into one that takes them one at a time." According to #1, what PEP309 calls currying is no such thing. According to #2, what PEP309 calls currying *is* currying. It looks to me as if the second usage is the dominant one, in which case I think PEP309 is fine. -- g

1 0

Call for Papers: 1st International Workshop on Interpreted Languages
by M.-A. Lemburg Feb. 20, 2004

Feb. 20, 2004

Sebastian Bergmann, organizer of the above workshop, asked me to post this announcement to the relevant Python lists. http://www.sebastian-bergmann.de/InterpretedLanguages2004/ I will be giving a talk on how Python is developed representing the PSF. Would be nice if we could get some more talks on Python or Python related subjects into this workshop since it reaches out to a much larger public than the Python specific conferences such as PyCon, PythonUK or EuroPython. The workshop is part of the Net.ObjectDays, a conference on OO- and Internet-based technologies: http://www.netobjectdays.org/node04/en/index.html Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 20 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

1 0

new syntax for wrapping (PEP 318)
by Jewett, Jim J Feb. 20, 2004

Feb. 20, 2004

Bob Ippolito: > Also note that the patch also adds the same sugar to classes, Michael Hudson: > FWIW, I'm rather less convinced this is useful. On the other hand, it seems arbitrary to say that you can do this with one type of definition, but not another. Phillip J. Eby: > class Foo(object) [instancesProvide(IFoo)]: [is more useful for] > class Foo(object): > protocols.advise(instancesProvide=[IFoo]) I think this may be one reason this didn't happen before; wrapping is good, but it isn't entirely obvious how to write it or exactly what it should mean. Given that, it might be premature to use up the [] syntax. This might be a good use of macros ... but I have a feeling they won't appear quickly. -jJ

2 1

[Python-Dev] Re: [Python-checkins] python/dist/src/Misc NEWS, 1.936, 1.937
by M.-A. Lemburg Feb. 20, 2004

Feb. 20, 2004

mwh(a)users.sourceforge.net wrote: > Update of /cvsroot/python/python/dist/src/Misc > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv3489/Misc > > Modified Files: > NEWS > Log Message: > "Fix" (for certain configurations of the planets, including > recent gcc on Linux/x86) > > [ 899109 ] 1==float('nan') > > by implementing rich comparisons for floats. Have you benchmarked this change ? Rich comparisons sound a lot like overhead and the case you are trying to fix here isn't exactly a common one. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 19 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ 2004-01-23: Released mxODBC.Zope.DA 1.0.8 http://zope.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

2 2