Mailman 3 February 2004 - Python-Dev

RE: [Python-Dev] Optional separatorargument for file.writelines()and StringIO.writelines()
by Moore, Paul Feb. 25, 2004

Feb. 25, 2004

From: Alex Martelli > On 2004 Feb 25, at 12:13, Dmitry Vasiliev wrote: >> Raymond Hettinger wrote: >>> Currently, writelines() does not add trailing line separators.. >>> This is fine when working with readlines() but a PITA in other >>> situations. >>> If we added an optional separator argument, it would be easier to add >>> newlines and we would gain some of the flexibility of str.join() at >>> full C speed. >> >> Maybe not a separator but suffix, so newline will be added to last >> line too? > > Good point. And while a separator would be a slight nuisance to > express otherwise, a "suffix" isn't -- it seems to me that > f.writelines(x+'\n' for x in mylines) is a rather good way of > expressing "suffix each line with a \n". I don't think this suffixing > operation is so widely more important than other elaborations on items > of mylines to make it worth specialcasing into a writelines argument > [if anything, f.writelines(str(x) for x in mylines) would be the one > elaboration that seems to me to be by far the most frequent -- still > not worth specialcasing though, IMHO]. Maybe there's a useful itertool lurking in here. I'm thinking of something that takes a list of iterables, and generates elements from each in turn, like a flattened izip: def interleave(*iterables): iterables = [iter(it) for it in iterables] while 1: # Let StopIteration fall through, but make sure that # each iterable generates the same number of results vals = [it.next() for it in iterables] for val in vals: yield val Then, we're talking about f.writelines(interleave(mylines, repeat('\n'))) [or if you want separators rather than suffixes, use f.writelines(islice(interleave(repeat('\n'), mylines), 2, None)) instead] Frankly, it's not an obvious win for the writelines case, but I was surprised that there was nothing like interleave in itertools, and that I couldn't find an easy way to write such a thing. Maybe a flatten itertool would be more generally useful - def flatten(iterable): for it in iterable: for val in it: yield val then interleave(*iterables) is flatten(izip(*iterables))... Thoughts? If not added as functions, would these be useful additions to the documentation? Paul.

2 1

Re: [Python-Dev] Re: PEP 309, function currying
by Edward Loper Feb. 24, 2004

Feb. 24, 2004

Peter Harris wrote: >>* curry() >> >>* closure() >> >>* partial() >> >>* partial_apply() >> >>* delayed() >> >>* other ? bind() and bindargs() seem pretty reasonable to me. But if you don't like those, then how about fixargs() or fix_args()? That gets across the message that we're generating a new function that fixes the values of a subset of the arguments. Side note: I think that the following code will have unexpected behavior with the current implementations: >>> def f(x,y,z): return (x,y,z) >>> g = f.bind(y=3) >>> print g(1,2) TypeError: f() got multiple values for keyword argument 'y' (I would have expected this to return (1,3,2).) Of course, there's not really any way around it without using inspection, and even then you can't really inspect argument lists for builtins. But it might be worth noting in the docs the circumstances under which it's appropriate to bind w/ keyword args. -Edward

1 0

Plea for function/method syntax sugar (PEP 318, with a different syntax)
by Bob Ippolito Feb. 24, 2004

Feb. 24, 2004

Some time ago, mwh developed a patch that adds some syntactical sugar to def, which is equivalent to PEP 318 though it has a different and more flexible syntax... previous threads can be easily found here: http://www.google.com/search?q=+site:mail.python.org+%22meth-syntax- sugar%22 the latest version of mwh's patch is here: http://starship.python.net/crew/mwh/hacks/meth-syntax-sugar-3.diff Here's a quick overview: def foo(args) [sugary, expressions, list]: pass This is equivalent to: def foo(args): pass foo = list(expressions(sugary(foo))) This evaluation order is Guido approved, though at least one person wanted it to be the other way around One would use this in scenarios such as: class FooClass(object): def className(klass) [classmethod]: return klass.__name__ or, even more importantly (to me anyway): # we would change PyObjC to make this a built-in feature.. but, for completeness: import objc def signature(sig): def _signature(fn): return objc.selector(fn, signature=sig) return _signature class FooClass(NSObject): def returnsAnInteger(self) [signature('i@:')]: return 1 def returnsVoidTakesAnInteger_(self, anInteger) [signature('v@:i')]: pass With current syntax, PyObjC is extremely cumbersome: class FooClass(NSObject): def returnsAnInteger(self): return 1 returnsAnInteger = objc.selector(returnsAnInteger, signature='i@:') def returnsVoidTakesAnInteger_(self, anInteger): pass returnsVoidTakesAnInteger_ = objc.selector(returnsVoidTakesAnInteger_, signature='v@:i') # these are actually short examples, compare to something like: # textView_completions_forPartialWordRange_indexOfSelectedItem_ Why we need this: Without it, it's hard use PyObjC correctly. ObjC selector nomenclature is extremely verbose, and your fingers hurt after a while having to type each function name three times. The function __name__ is important, because the objc.selector type has to convert it to a selector:that:uses:colons:, or else the colon:using:name: would have to be specified manually. It makes classmethod/staticmethod/etc more palatable. What the patch doesn't do: lambda is not allowed in the "sugary expressions list" there's no *expansion and it won't take an actual list so if you want a prebaked list of transformations then you'll have to roll a callable that does it such as: def prebake(*expressions): def _prebake(fn): for transformation in expressions: fn = transformation(fn) return fn return fn This syntactical sugar for def is so unbelievably important to PyObjC (and likely other projects) that I am willing to distribute my own modified version of Python if it doesn't make 2.4 (though I would probably use Stackless as the base, but that's another plea for another day). The patch looks like it still applies to CVS HEAD, but there is a little fuzz on hunk 2. I have not tested it yet, but I have tested it against CVS HEAD of the 2.3.3 based Stackless. I'm willing to help however I can in order to get this into Python 2.4. -bob

8 21

RE: [Python-Dev] Re: PEP 309, function currying
by Moore, Paul Feb. 24, 2004

Feb. 24, 2004

From: Peter Harris > Yes, that's currying alright, which PEP 309 does in no way describe. > Hmm. > OK, there is way too much imprecise thinking behind that PEP. Sorry. > Quick unscientific name poll. Who likes... > * curry() > > * closure() > > * partial() > > * partial_apply() > > * delayed() > > * other ? I like curry(). The others don't bring the right concept to mind for me. I apologise if this offends the purists, but *all* of the recent attempts to "clarify" the difference between partial application and currying have simply confused me. If curry() gets screams of outrage, someone suggested bind() to follow the Boost C++ library's usage. That's tolerable, although I find it too generic a word. Paul

6 5

cPickle incompatibility!
by Christian Tismer Feb. 24, 2004

Feb. 24, 2004

Hi developers, while hunting for problems with Stackless pickling, I found a bug in cPickle. Pickling of functions: pickle.py first tries a save_global. If that doesn't work, it tries a save_reduce. cPickle doesn't do that. This bug exists since Python 2.3. cvs -z9 diff -u -wb cPickle.c (in directory D:\cvsdown\python\dist\src\Modules\) Index: cPickle.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/cPickle.c,v retrieving revision 2.148 diff -u -w -b -r2.148 cPickle.c --- cPickle.c 12 Oct 2003 19:09:36 -0000 2.148 +++ cPickle.c 24 Feb 2004 14:28:34 -0000 @@ -2418,6 +2418,11 @@ case 'f': if (type == &PyFunction_Type) { res = save_global(self, args, NULL); + if (res && PyErr_ExceptionMatches(PickleError)) { + /* fall back to reduce */ + PyErr_Clear(); + break; + } goto finally; } break; May I check this one in? (or somebody else do it) ciao - chris -- Christian Tismer :^) <mailto:tismer@stackless.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

2 1

Re: [Python-Dev] Re: new syntax for wrapping (PEP 318)
by Jewett, Jim J Feb. 24, 2004

Feb. 24, 2004

From: Greg Ewing <greg(a)cosc.canterbury.ac.nz> > "Jewett, Jim J" <jim.jewett(a)eds.com>: >> With the current syntax, I think the cost is too high >> for the benefit. It might help to add a keyword, like >> def foo() wrapped_by [sugary, syntax, list]: > Some keyword might help, but I don't like that particular > choice, as it draws too much attention to the mechanism, I'm certainly not wedded to that specific word; how about "providing" "also_providing", "including", "extended_by", or "acting_as"? ("as" is better than nothing, but does suggest an alias more than a wrapper.) > I think it ought to be very readable without any keyword, > provided the names of the wrapper functions are chosen > appropriately. By someone with similar background. > Can you honestly say that, as a Python > newbie, if you had come across > def marmalade(self) [classmethod]: ... > you wouldn't have been able to guess the intent, if not > the mechanism being used to achieve it? The problem isn't that *this* function would be too mysterious; the problem is that it adds mystery to the *rest* of the language. I would have assumed that I have to make a (possibly implicit) similar declaration about every function, and that the declarations come from a (hopefully) small set, such as {public, private, static, synchronized, final, abstract} The fact that I would have to learn this set (and rules about which went together) would be a barrier to entry. The fact that I couldn't quickly find the exhaustive list (since no such declaration is actually required) would make me nervous. If I saw example code not using the [] declaration, I would assume that the defaults were *mostly* reasonable, but not always, and it would bother me that I couldn't find the information about when I needed to override it. My newbieness is still recent enough that this objection isn't theoretical; "how long before I can spend more time coding than searching through the manual" and "how long before surprises -- even in other people's code -- are at least immediately recognizable instead of deep bugs" were among the main reasons to choose python over Perl or Ruby. > def marmalade(self) [classmethod]: looks basic enough that I assume I have to understand it before I can write even a simple program - particularly since [] characters are pretty common in the rest of the language. The huge difference between (legal) definitions def marmalade(self): [classmethod] and def marmalade(self) [classmethod]: in a language that supposedly uses whitespace instead of syntax characters would make me assume that the language really does use all sorts of obsure syntax, but just hides it in ways that I can't easily recognize. def marmalade(self) unusual_modifiers[x,y,z]: at least tells me that this is an unusual case, and that [x, y, z] has its normal meaning, with any unexpected behavior attributable to the "unusual_modifiers" that calls/uses them. In this case, there would be only one possible unusual modifier, and it would be listed in the appropriate part of the documentation, and it would then be clear that I didn't need to worry about it for most of my own programs. (Note that "unusual_modifiers" doesn't even have to be self-documenting to get this benefit, so long as it is clearly optional and clearly not applicable to *all* definitions. "extended_format1" would already be useful.) I also suspect that this won't be the last extension to definition syntax. Adding a keyword to describe the extension means that someone who doesn't often use that particular extension can still skim the code without a manual handy. Adding new anonymous syntax is already a bit confusing, and would be unworkable by the fourth or fifth extension. -jJ

3 2

Re: PEP 309, function currying
by Peter Harris Feb. 24, 2004

Feb. 24, 2004

Greg Ewing wrote: > But isn't that just as wrong as the first version? It still seems > >to be describing partial application, not currying as you defined >it above. Maybe it should say > > Function currying is the process of transforming a function that > takes n arguments into a function that takes one argument and > returns another function (itself also curried, if n > 2) that > takes the remaining n-1 arguments. > > > Yes, that's currying alright, which PEP 309 does in no way describe. Hmm. OK, there is way too much imprecise thinking behind that PEP. Sorry. I did originally describe it as a closure in the first version, then someone corrected me about that too. I'll give the wording some more thought, but the problem I have is that to be useful, the class or function that implements it has to have a wieldy and clear name. Myself, I wouldn't like to use PartiallyApply(fn,*args,**kw). Quick unscientific name poll. Who likes... * curry() * closure() * partial() * partial_apply() * delayed() * other ? Thanks for your thoughts, folks. Peter Harris scav at blueyonder, co, uk

2 1

PEP 309, function currying
by Peter Harris Feb. 23, 2004

Feb. 23, 2004

Hi I've updated PEP309 a little, since someone sent me a better implementation. I haven't mentioned in the latest version the recent objection by Dave Abrahams that: Several languages have misused the term "curry" this way mostly on the grounds that the main language using curry that way is English :) The first Google result I found that mentioned function currying was this: [ http://www.engr.uconn.edu/~jeffm/Papers/curry.html ] Function Currying in Scheme I'll quote from the abstract: Function currying is the process of partially, or incrementally, supplying arguments to a function. Curried functions are delayed functions expecting the remainder of the arguments to be supplied. Once all the arguments are supplied, the function evaluates normally. I haven't the time for an exhausive statistical and linguistic analysis. My vote goes for the prevalent definition of currying that is actually a useful functional programming abstraction, i.e. the one described above. Anyway, this is my last request for flames about the presentation and content of the PEP itself before I post a full draft of the proposed 'functional' module. Peter Harris

4 6

Re: [Python-checkins] python/nondist/sandbox/statistics statistics.py, NONE, 1.1 test_statistics.py, NONE, 1.1
by Skip Montanaro Feb. 23, 2004

Feb. 23, 2004

Raymond> The module focuses on everyday data reduction functions and Raymond> omits more sophisticated statistical tools. ... Raymond> __all__ = ['mean', 'stddev', 'product', 'nlargest', Raymond> 'nsmallest', 'select'] Raymond It's been years since I last looked at a statistics book or thought much about statistics, but I think the standard deviation was generally defined as the square root of the variance. Perhaps you could easily add the variance to your collection of functions by renaming "stddev" to "variance", remove the "** 0.5" from the return statements, then define stddev as def stddev(data, sample=True): return variance(data, sample) ** 0.5 Skip

1 0

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

Feb. 23, 2004

Summary: With the current syntax, I think the cost is too high for the benefit. It might help to add a keyword, like def foo() wrapped_by [sugary, syntax, list]: Details: Phillip J. Eby: >> 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__'. :) Paul Moore: > I don't see anyone arguing for different *semantics*. In that very paragraph are two alternatives for what it would mean on a class. One matches the function meaning for consistency. The other replaces __metaclass__, which someone thought would be more useful. Personally, I see the PEP as useful, but not useful enough to justify having to remember new syntax. Definately not useful enough to add new meaning to an unmarked list. Alternative syntax won't make it more useful, but might make it less costly to the rest of the language. When I follow a def with an immediate assignment, it is usually to something other than the original name. For instance, I may want to define a module-level function, even though I'm already within a function, or I might want to bind a second alias to the same function. (Come to think of it, "alias" is also a different but logical meaning, particularly for the "as" format.) The ugly solution is to use exec: # Note that this string is just a string, and the editor # won't help me. fn_str = (""" def %(name)s(): print "in fn %(name)s" globals()['%(name)s'] = %(name)s """) # Verified with 2.3, since multiple interpolation is subject # to too many typos. def makealpha(): for fn in 'abcde': exec(fn_str % dict(name='%s' % fn)) I would love a better solution - but this proposal is too limited to help. (= not enough benefit) That's fine, so long as it is also easy to ignore. (= low cost) A new definition type similar to class or def would be OK; I just wouldn't use it much. Changing the syntax of def is a bit more worrisome. With this patch, def foo():[sugary, syntax, list] and def foo() [sugary, syntax, list]: would have very different meanings. To be honest, when I first looked at Python, one of the selling points was that it strongly encouraged readable code. If I had come across the above distinction too soon (like, say, when I wondered how to define a function or class), ... I'm not sure I would have continued to look. def foo() wrapped_by [sugary, syntax, list]: would be far less problematic, because the keyword (1) serves notice that this is a special case (2) serves as a reminder of what the list does. (3) leaves open the possibility of future extensions with other keywords. -jJ

3 2