Mailman 3 November 2002 - Python-Dev

PEP 288: Generator Attributes
by Raymond Hettinger 23 Nov '02

23 Nov '02

PEP 288 has been updated and undeferred. Comments are solicited. The old proposal for generator parameter passing with g.next(val) has been replaced with simply using attributes in about the same way as classes: def outputCaps(logfile): while True: line = __self__.data logfile.write(line.upper) yield None outputCaps.data = "" # optional attribute initialization g = outputCaps(open('logfil.txt','w')) for line in open('myfile.txt'): g.data = line g.next() The separate proposed for generator exceptions is unmodified from before.

5 4

RE: [Python-Dev] Half-baked proposal: * (and **?) in assignments
by Delaney, Timothy 23 Nov '02

23 Nov '02

> From: Brett Cannon [mailto:bac@OCF.Berkeley.EDU] > [Delaney, Timothy] > > > I think the addition of this would lead to a more > functional style of > > programming. This may be a plus for some people, and a > minus for others. > > > > MINUS! > > And yes, I have done my fair share of Scheme and Lisp > programming so this > is not an ignorant statement. Python is not a functional > language. This is true - and yet I find that I program in a more 'functional' way in Python than in any other language I use. I find that for many problems it is natural for me to think in a functional way, and I appreciate that Python allows me to (without imposing it on me). In particular, I tend to produce a lot of filtering functions (whether run through list comps, filter or just standalone) and this is one place where this syntax would be useful. Of course, that presupposes that at least *one* value passes the filter ... but surely a failure there would be a data error ;) > concise code and I want to keep the LHS of the assignment simple. But > then again that might be a bias coming from a right-handed person. =) Nah - I'm right-handed too, but I've got nothing against the LHS. The major point I have against it is that you would presumably have duplication in: a = t *a = t unless that were special-cased. I personally think it should be syntactially correct if the proposal were to be accepted, but with a strong suggestion in the documentation that it be avoided ;) Tim Delaney

2 1

RE: [Python-Dev] Half-baked proposal: * (and **?) in assignments
by Delaney, Timothy 23 Nov '02

23 Nov '02

> From: Gareth McCaughan [mailto:Gareth.McCaughan@pobox.com] > > a,b,*c = 1,2,3,4,5 FWIW, this has been proposed before, but no one ever bothered to make a PEP about it. Each time it's come up, my gut feeling has been that I would really like it. I've often been in the situation where I'd *like* to pass a variable-length tuple from a function, but the current way of splitting it up is too clunky. I hadn't thought of it before, but I do like the suggestion of allowing * in any location of the LHS. This would of course require that the LHS contains exactly zero or one * i.e. a, b, c = t *a, b, c = t # all leading into a, 2nd-last into b, last into c a, *b, c = t # first into a, all middle into b, last into c a, b, *c = t # first into a, second into b, all trailing into c would all be legal constructs, but *a, *b, c = t a, *b, *c = t *a, b, *c = t *a, *b, *c = t would all be illegal constructs. I think the addition of this would lead to a more functional style of programming. This may be a plus for some people, and a minus for others. For myself, the idea (including arbitrary placement of the *) is +1. However, I'm -1 on the idea of additional syntax on the RHS. Tim Delaney

2 1

Half-baked proposal: * (and **?) in assignments
by Gareth McCaughan 23 Nov '02

23 Nov '02

Since def f(a,b,*c): ... f(1,2,3,4,5) does (in effect) a=1, b=2, c=(3,4,5), I suggest that a,b,*c = 1,2,3,4,5 should do a=1, b=2, c=(3,4,5) too. Likewise, a,b,c,d,e = 1,2,*(3,4,5) should be parallel to def f(a,b,c,d,e): ... f(1,2,*(3,4,5)) I shall refrain from suggesting that the following should "work": a,b,c = 1,**{'b':2,'c':3} a,**d = (a=1, b=2, c=3) a,b,c = (b=2, c=3, a=1) though actually it's an amusing thought, and I wouldn't complain if they did. The second of them (in the special case where the LHS is just "**d") would provide an alternative to Just van Rossum's proposal to overload the dict constructor. (The two aren't exclusive.) Note that the parens would be necessary, to avoid ambiguity with "a=b=c=0". The motivating principle is that parameter passing is, or should be, just like assignment[1], so what works in one context should work in the other. I've moderately often actually wanted the a,b,*c=... notation, too, usually when using split() on strings containing an unknown number of fields; the most concise alternative goes like a,b,c = (line.split()+[None])[:3] which both looks and feels ugly. Of course, you can't take "parameter passing is just like assignment" too seriously here, because x = 1,2,3 a,b,c = x works, whereas def f(x): ... def g(a,b,c): ... f(1,2,3) g(x) doesn't. Still, the analogy is (to me) quite a compelling one. Am I nuts? [1] This principle matters more in languages like C++ and Eiffel where parameter passing and assignment can both cause funny (and potentially user-defined) copying operations to happen, not just slinging references. -- g

10 13

test_codeccallbacks failing on Windows
by Tim Peters 23 Nov '02

23 Nov '02

====================================================================== FAIL: test_uninamereplace (__main__.CodecCallbackTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "..\lib\test\test_codeccallbacks.py", line 74, in test_uninamereplace self.assertEqual(sin.encode("ascii", "test.uninamereplace"), sout) File "C:\CODE\PYTHON\lib\unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: '\x1b[1mNOT SIGN, ETHIOPIC SYLLABLE SEE, EURO SIGN, CJK UNIFIED IDEOGRAPH-8000\x1b[0m' != '\x1b[1mNOT SIGN, ETHIOPIC SYLLABLE SEE, EURO SIGN, 0x8000\x1b[0m'

1 0

bsddb3 imported
by martin＠v.loewis.de 23 Nov '02

23 Nov '02

I have now imported bsddb3 3.4.0. Remember to cvs up -d to get Lib/bsddb. The original bsddb module is not built anymore automatically, if it was, it would compile into a module bsddb185. I haven't updated the Windows build process: I recommend that bsddbmodule.c is not built anymore. Instead, _bsddb.c must be compiled into _bsddb.pyd. Since this code does not work with Sleepycat 4.1, I recommend that Sleepycat 4.0 is used, available from http://www.sleepycat.com/update/snapshot/db-4.0.14.zip Barry wants the test suite to be incorporated also, this will happen after we decide on the specifics. I don't have plans to incorporate any of the documentation at the moment. Regards, Martin

5 22

Re: [snake-farm] Re: [Python-Dev] Snake farm
by Guido van Rossum 23 Nov '02

23 Nov '02

> > So it looks like PyOblect_Free() was called with 0x800 as an argument, > > which is a bogus pointer value. Can you go up one stack level and see > > what the value of k in function_call() is? > 713 if (ADDRESS_IN_RANGE(p, pool->arenaindex)) { > (gdb) up > #1 0x080dfef4 in function_call (func=0x826317c, arg=0x8256aac, > kw=0x8269bdc) at Objects/funcobject.c:481 > 481 PyMem_DEL(k); > (gdb) p k > $1 = (struct _object **) 0x800 Well, then maybe you can follow MvL's suggestion and find out how come this value was returned by PyMem_NEW(PyObject *, 2*nk)??? --Guido van Rossum (home page: http://www.python.org/~guido/)

3 3

RE: [Python-Dev] Re: Yet another string formatting proposal
by Chermside, Michael 23 Nov '02

23 Nov '02

> > I'm also bit dubious about the name "cook" (cute though!). > > The rationale behind the name wasn't just "cuteness". The effect > of this method is the exact opposite of the "raw" prefix so the > name "cook" was the most natural and descriptive choice. Got any > other ideas? But I don't think that it IS the opposite of the "raw" prefix. In a case with just substitutions like this, it works: >>> x = 5 >>> s1 = ":\{x}:" >>> s1 ':5:' >>> s2 = r":\{x}:" >>> s2 ':\{x}:' >>> s2.cook() ':5:' But in a case where OTHER escapes are used, it wouldn't be: >>> x = 5 >>> s1 = "\t\{x}" >>> print s1 5 >>> s2 = r"\t\{x}" >>> print s2 \t# >>> print s2.cook() \t5 You could "fix" this by ALSO processing \ escapes in the cook() method, but that confuses two very different processes and would only make the feature MORE difficult to use. Of course, now that I knock your idea down, I'd better come up with a replacement of my own. I suggest ".sub()" from PEP 292 (after all... let's try to build on what was developed in the previous discussions). > > +1 (but, of course, that vote doesn't count until there's a PEP > > to refer to). > > Just wanted to sample the water first. I bet everyone is already > sick of this subject after two PEPs, several other proposals, endless > discussions and no results. Yes, but the reason for so many discussions is that it's an issue which actually matters. So long as new ideas BUILD on existing ones, we're making progress. This is one of those cases where the implementation is trivial, but designing it right... ah, that's HARD. -- Michael Chermside

2 1

release22-maint branch broken
by Tim Rice 22 Nov '02

22 Nov '02

I pulled the release22-maint branch today and tried to build on UnixWare 7 It looks like changes to setup.py and Lib/distutils/sysconfig.py broke the build. At least if there is no pre existing python installed. Here is the CVS log. ... Backport fdrake's revision 1.88 of setup.py revision 1.46 of Lib/distutils/sysconfig.py When using a Python that has not been installed to build 3rd-party modules, distutils does not understand that the build version of the source tree is needed. This patch fixes distutils.sysconfig to understand that the running Python is part of the build tree and needs to use the appropriate "shape" of the tree. This does not assume anything about the current directory, so can be used to build 3rd-party modules using Python's build tree as well. This is useful since it allows us to use a non-installed debug-mode Python with 3rd-party modules for testing. It as the side-effect that set_python_build() is no longer needed (the hack which was added to allow distutils to be used to build the "standard" extension modules). This closes SF patch #547734. ... Here are the errors I get ... running build_ext Traceback (most recent call last): File "/opt/src/utils/python/python-2.2.2/src/setup.py", line 795, in ? main() File "/opt/src/utils/python/python-2.2.2/src/setup.py", line 790, in main scripts = ['Tools/scripts/pydoc'] File "/opt/src/utils/python/python-2.2.2/src/Lib/distutils/core.py", line 138, in setup dist.run_commands() File "/opt/src/utils/python/python-2.2.2/src/Lib/distutils/dist.py", line 902, in run_commands self.run_command(cmd) File "/opt/src/utils/python/python-2.2.2/src/Lib/distutils/dist.py", line 922, in run_command cmd_obj.run() File "/opt/src/utils/python/python-2.2.2/src/Lib/distutils/command/build.py", line 107, in run self.run_command(cmd_name) File "/opt/src/utils/python/python-2.2.2/src/Lib/distutils/cmd.py", line 330, in run_command self.distribution.run_command(command) File "/opt/src/utils/python/python-2.2.2/src/Lib/distutils/dist.py", line 922, in run_command cmd_obj.run() File "/opt/src/utils/python/python-2.2.2/src/Lib/distutils/command/build_ext.py", line 231, in run customize_compiler(self.compiler) File "/opt/src/utils/python/python-2.2.2/src/Lib/distutils/sysconfig.py", line 139, in customize_compiler (cc, opt, ccshared, ldshared, so_ext) = \ File "/opt/src/utils/python/python-2.2.2/src/Lib/distutils/sysconfig.py", line 421, in get_config_vars func() File "/opt/src/utils/python/python-2.2.2/src/Lib/distutils/sysconfig.py", line 326, in _init_posix raise DistutilsPlatformError(my_msg) distutils.errors.DistutilsPlatformError: invalid Python installation: unable to open /usr/local/lib/python2.2/config/Makefile (No such file or directory) gmake: *** [sharedmods] Error 1 ... There is no /usr/local/lib/python2.2/config/Makefile because python has not been built/installed on this machine yet. -- Tim Rice Multitalents (707) 887-1469 tim(a)multitalents.net

2 2

Re: Yet another string formatting proposal
by Chermside, Michael 22 Nov '02

22 Nov '02

> [Oren proposes "\(a) + \(b)" string formatting.] I've been watching the string formatting proposals for a while. Each time I've thought... "well, it seems a LITTLE nicer than %s and %(name)s, but is it really ENOUGH better that it's worth replacing what we've got?". So far I've generally been unsure. But this one is good. It's best features are that it is _simple_, and _elegant_. I would prefer \{} over \() because it is more distinctive ("\(" being used in REs), and somehow the {} seem more consistent with "execution" and () with "grouping" across a broad range of languages. I'm also bit dubious about the name "cook" (cute though!). But The design is clean and readable. The separation between cook() and cook_eval() is probably quite wise (although it will throw a couple of newbies, but in the process it'll teach them to beware of eval'ing arbitrary data). +1 (but, of course, that vote doesn't count until there's a PEP to refer to). -- Michael Chermside

2 1