Mailman 3 August 2004 - Python-Dev

Minimal 'stackless' PEP using generators?
by Clark C. Evans Aug. 26, 2004

Aug. 26, 2004

I just read the thread 'Stackless Python' in June 2004 on python-dev and was wondering if you'd comment on a simpler cooperative mechanism, via a small hack to generators: 1. The PEP would introduce a new 'builtin' class called 'Cooperate' 2. Generator semantics would be altered so that 'yield X', where X is an instance of Cooperate, would automagically propigate to the outer-most non-generator. In for example, >>> def MyCooperate(magic.Cooperate): >>> __str__(self): return "cooperate" >>> >>> def top(): >>> yield "one" >>> yield MyCooperate() >>> yield "two" >>> >>> def middle(): >>> """ intermediate generator _only_ sees one and two """ >>> for x in top(): >>> print "middle", x >>> yield x >>> >>> def lower(): >>> """ this is not a generator, so it sees cooperate """ >>> for x in middle(): >>> print "lower", x >>> >>> lower() middle one lower one lower cooperate middle two lower two With these two changes, the "lower" function could be an async reactor like those found in Twisted, or async core. While the result isn't true coutines, it would be a huge improvement for those who would like to do async coding. I've done something similar with Twisted called Flow [1] and it works well, with the exception of being a painful syntax hack and being quite slow. If this was moved into Python's core, we'd get most of the advantages of coroutines without the full cost. Thoughts? Clark [1] http://twistedmatrix.com/documents/current/howto/flow -- Clark C. Evans Prometheus Research, LLC. http://www.prometheusresearch.com/ o office: +1.203.777.2550 ~/ , mobile: +1.203.444.0557 // (( Prometheus Research: Transforming Data Into Knowledge \\ , \/ - Research Exchange Database /\ - Survey & Assessment Technologies ` \ - Software Tools for Researchers ~ *

7 23

RE: [Python-Dev] exit in __builtins__
by Michael Chermside Aug. 26, 2004

Aug. 26, 2004

Andrew Durdin writes: > But does this really belong in __builtins__? Wouldn't it be better for > the interactive interpreter to register it as a global when it sets > up, as it only makes sense in the context of the interactive > interpreter? It's a basic principle that the behavior of the interactive interpreter and the behavior of Python run non-interactively should be as close to the same as is possible. The requirement for blank lines after an indented suite is unavoidable because you can't "look ahead" in the interpreter. There are also the prompts. While I'm sure there are a few others, we try to keep the differences minimal. -- Michael Chermside

1 0

AW: [Python-Dev] exit in __builtins__
by Oliver Walczak Aug. 26, 2004

Aug. 26, 2004

Yes, it's "only" in site.py: __builtin__.quit = __builtin__.exit = exit Allright, I think it makes sense like it is :-) Thanx Oliver -----Ursprüngliche Nachricht----- Von: Rodrigo B. de Oliveira [mailto:rodrigobamboo@gmail.com] Gesendet: Donnerstag, 26. August 2004 14:07 An: Oliver Walczak Cc: python-dev(a)python.org Betreff: Re: [Python-Dev] exit in __builtins__ Hi! Try to type 'exit' or 'quit' in the interactive shell and you see its purpose. Pretty clever. Cheers, Rodrigo On Thu, 26 Aug 2004 14:00:40 +0200, Oliver Walczak <oliver.walczak(a)momatec.de> wrote: > Dear list, > ... > > > Is it a bug or a feature? exit as builtin is not documented anywhere and I > cannot find out where it gets included or attached to the str object in the > sources. Any idea? > > Best regards > Oliver

1 0

exit in __builtins__
by Oliver Walczak Aug. 26, 2004

Aug. 26, 2004

Dear list, as I am already quite experienced in python programming I recently started to dive into the C-depths of the language. So it was a logical implication to register for this newsgroup as there is no one else I can talk about this. So here's one thing I tried to evolve out of the sources but couldn't find out how it works internally: If you call dir(__builtins__) after starting a python (2.3.4) session you get a list all well known builtin functions. I noticed, that there is already an exit function available as builtin (NOT sys.exit!!). But when you call exit(0) it says TypeError: 'str' object is not callable So I called print __builtins__.exit.__doc__ And surprisingly I got the doc string from str. So I started browsing the sources, and in ./Python/bltinmodule.c there get most of the builtin functions attached to __builtin__, but not the "exit" call. Is it a bug or a feature? exit as builtin is not documented anywhere and I cannot find out where it gets included or attached to the str object in the sources. Any idea? Best regards Oliver

3 2

decorators: If you go for it, go all the way!!! :)
by alex_nanou＠cs.msu.su Aug. 26, 2004

Aug. 26, 2004

the inability to decorate anything but a function, is quite a limitation, though I must agree that decorating classes is not such a common task, but using the syntax to *decorate* attributes would indeed prove useful (in both the readability department and the uniformity of code).. here is an example we use quite often: ---cut--- import time import sys def intonly(obj=0, doc=None): ''' intonly(int) -> descriptor the resulting descriptor will prevent both the deletion of the attribute and assignments of any value other than ints. ''' if type(obj) is not int: raise TypeError, 'value must be int (got: %s)' % obj f_locals = sys._getframe(1).f_locals # name the attr (I know this is ugly ^_^ ) while True: name = '_priv_' + str(int(time.time()*10**8)) if name not in f_locals: f_locals[name] = obj break # the descriptor reader function... def read(self): return getattr(self, name) # the descriptor writer... def write(self, val): if type(val) is not int: raise TypeError, 'value must be int (got: %s)' % val setattr(self, name, val) # now create the descriptor and return it... return property(read, write, doc=doc) --uncut-- and here are a couple of usage examples: the desired decorator syntax: ---cut--- class A(object): @intonly i = 123 --uncut-- the current usage syntax: ---cut--- class A(object): i = intonly(123) --uncut-- // sorry if I bring this up agen! :) thanks! --- Best Regards... Alex.

2 1

test_distutils failing in 3 ways today
by Tim Peters Aug. 26, 2004

Aug. 26, 2004

This is on Windows. I've heard that it fails on Linux too. Who isn't running the test suite? A reminder: with lots of people trying to make changes at once, it's essential to run all tests before checking in. C:\Code\python\PCbuild>python ../lib/test/test_distutils.py test_package_data (distutils.tests.test_build_py.BuildPyTestCase) ... ok test_build (distutils.tests.test_build_scripts.BuildScriptsTestCase) ... ERROR test_default_settings (distutils.tests.test_build_scripts.BuildScriptsTestCase) ... ERROR test_command_packages_cmdline (distutils.tests.test_dist.DistributionTestCase) ... ok test_command_packages_configfile (distutils.tests.test_dist.DistributionTestCase) ... ok test_command_packages_unspecified (distutils.tests.test_dist.DistributionTestCase) ... ok test_home_installation_scheme (distutils.tests.test_install.InstallTestCase) ... ok test_default_settings (distutils.tests.test_install_scripts.InstallScriptsTestCase) ... ok test_installation (distutils.tests.test_install_scripts.InstallScriptsTestCase) ... ok ====================================================================== ERROR: test_build (distutils.tests.test_build_scripts.BuildScriptsTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Code\python\lib\distutils\tests\test_build_scripts.py", line 34, in test_build cmd.finalize_options() File "C:\Code\python\lib\distutils\command\build_scripts.py", line 44, in finalize_options ('executable', 'executable')) File "C:\Code\python\lib\distutils\cmd.py", line 309, in set_undefined_options getattr(src_cmd_obj, src_option)) AttributeError: DummyCommand instance has no attribute 'executable' ====================================================================== ERROR: test_default_settings (distutils.tests.test_build_scripts.BuildScriptsTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Code\python\lib\distutils\tests\test_build_scripts.py", line 21, in test_default_settings cmd.finalize_options() File "C:\Code\python\lib\distutils\command\build_scripts.py", line 44, in finalize_options ('executable', 'executable')) File "C:\Code\python\lib\distutils\cmd.py", line 309, in set_undefined_options getattr(src_cmd_obj, src_option)) AttributeError: DummyCommand instance has no attribute 'executable' ---------------------------------------------------------------------- Ran 9 tests in 0.156s FAILED (errors=2) Traceback (most recent call last): File "../lib/test/test_distutils.py", line 17, in ? test_main() File "../lib/test/test_distutils.py", line 13, in test_main test.test_support.run_unittest(distutils.tests.test_suite()) File "C:\Code\python\lib\test\test_support.py", line 290, in run_unittest run_suite(suite, testclass) File "C:\Code\python\lib\test\test_support.py", line 272, in run_suite msg = "errors occurred in %s.%s" \ AttributeError: 'TestSuite' object has no attribute '__name__' C:\Code\python\PCbuild>

1 0

Submitted patch #1014930 to exposes the current parse location in pyexpat
by Dave Cole Aug. 26, 2004

Aug. 26, 2004

I would like someone to review the patch I just submitted - it exposes more the the expat API to the xml.parsers.expat.XMLParser object. Expat supplies the XML_GetCurrentLineNumber, XML_GetCurrentColumnNumber, and XML_GetCurrentByteIndex functions to obtain the current parse location. The patch exposes these as the following respective members of the xml.parsers.expat.XMLParser object; CurrentLineNumber, CurrentColumnNumber, CurrentByteIndex. I have checkin permission, I just want someone to cast their eye over the patch before I commit. - Dave -- http://www.object-craft.com.au

2 2

socketmodule build failures on Un*xs that don't HAVE_GETADDRINFO
by Trent Mick Aug. 25, 2004

Aug. 25, 2004

Building the socket module with the current Python CVS (or at least with the Python 2.4a2 source) on Solaris 2.6, HP-UX 11, and AIX 5.1 fails in Modules/getaddrinfo.c with complaints about cc: ".../python/Modules/getaddrinfo.c", line 204: error 1588: "EAI_MAX" undefined. ".../python/Modules/getaddrinfo.c", line 282.25: 1506-045 (S) Undeclared identifier EAI_BADHINTS. ".../python/Modules/getaddrinfo.c", line 283.40: 1506-045 (S) Undeclared identifier AI_MASK. ".../python/Modules/getaddrinfo.c", line 373.41: 1506-045 (S) Undeclared identifier EAI_PROTOCOL. and the like. The problem seems to stem from this check-in which resulted in Modules/addrinfo.h *not* getting included for Unix flavours that do not HAVE_GETADDRINFO. http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Modules/socket… Wed May 26 17:06:31 2004 UTC (2 months, 4 weeks ago) by mwh > Band-aid type fix for > > [ 728330 ] Don't define _SGAPI on IRIX > > The Right Thing would be nice, for now this'll do. At least it > isn't going to break anything *other* than IRIX... Relevant bug: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_i… Subseqent checkins have gone in to fix the lack of addrinfo.h import on some platforms: http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Modules/socket… http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Modules/socket… So the question: was that original change removing the #include "addrinfo.h" an accident? I.e. should it have been something like this instead? #if defined(__sgi) # if _COMPILER_VERSION>700 \ && !defined(_SS_ALIGNSIZE) /* defined in sys/socket.h */ /* by some newer versions of IRIX */ /* (e.g. not by 6.5.10 but by 6.5.21) */ # include "addrinfo.h" # endif #else # include "addrinfo.h" #endif Cheers, Trent -- Trent Mick TrentM(a)ActiveState.com

3 3

Proposed change to logging
by Vinay Sajip Aug. 25, 2004

Aug. 25, 2004

An improvement to logging has been proposed by Miki Tebeka, which involves the creation of file-like wrapper objects for loggers. This makes it possible to use the print idiom for logging: import logging logging.basicConfig() logger = logging.getLogger("my.app") err = logger.getFileObject(logging.ERROR) dbg = logger.getFileObject(logging.DEBUG) ... print >> err, "My logging message with %s" % "arguments" print >> dbg, "A message at %s level" % "debug" Miki has helpfully sent in a patch (#1001864), and I propose to check it in by the 27th of August. I just wanted to get comments from python-dev first. There's one wart in the implementation - to avoid printing out blank lines caused by the "\n" appended by print, we ignore messages which are == "\n". This works only because print does a separate write for the "\n". Can anyone see a problem with this approach? class LoggerFileObject: """ Simulate a file object for a given logging level. """ def __init__(self, logger, level): """ Initialize file object with logger and level """ self.logger = logger self.level = level self.closed = 0 def write(self, msg): """ Write message to log. """ if self.closed: raise ValueError("I/O operation on closed file") # Avoid printing blank lines. if msg != "\n": self.logger.log(self.level, msg) def flush(self): """ Flush the file object. This flushes the logger's handlers. """ if self.closed: return for handler in self.logger.handlers: handler.flush() def close(self): """ Close file object. Calling "write" after "close" will raise a ValueError. """ self.closed = 1 Regards, Vinay ___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

4 7

Is something wrong with SF patch notifications?
by Raymond Hettinger Aug. 25, 2004

Aug. 25, 2004

I don't think Barry got notes showing that I reviewed his patch. Also, I didn't get a note when Walter assigned a unittest patch to me. That may also explain why I had a hard time soliciting a reviewer for the peepholer patch. IIRC, we always used to get notes whenever we were assigned a patch or had participated in the patch discussions. Raymond

6 5