Mailman 3 April 2007 - Python-Dev

Py3: function signatures, type checking, and related crap
by SevenInchBread 15 Apr '07

15 Apr '07

People seem to be pushing for a consistent method for checking the "x-ness" of objects (that is, interfaces that the object implements). So I present an idea for a simple and straightforward type that provides a way to construct descriptions of object structures, and I'd like some help expanding it into a useful extension to Python's standard set of utilities. Its a basic constructor that produces callable interface-checking predicates (which can be use in things such as list comprehensions, filter, if statements, or even a new syntax for function signatures that allows for automatic interface-checking). These predicates check that an object matches the behavior described by the constructor . Since I can't think of a name for this constructor, and because I've never liked the term "interface", I'll just call it "can". Can takes an arbitrary number of keyword arguments and produces a callable object. The keys represent object attributes, while the values are behavior-checking predicates like the ones produced by can. Since the can constructor produces an object that can in turn be used in other can constructors, using previously defined interfaces in new constructions is fairly straight-forward callable = can(__call__ = object)#Returns an object that describes objects with a __call__ attribute readable = can(read = callable) # ...with a callable read attribute writable = can(write = callable) # ...with a callable write attribute #a join operator can be used to combine can objects... #...for now I'll just use "and" and "or" to represent them. isfilelike = readable and writable #returns an object that matches any type that is described #by both readable and writable IOable = readable or writable #any type that is readable or writable objects that are constructed with can, when called, return True or False based on whether or not the passed object matches the behavior described. callable(hash) #returns True - as it would in the current version of Python. Here's some more nifty examples: iterable = can(__iter__=callable) or can(next=callable) hashable = can(__hash__=callable) completefile = isfilelike and iterable and can(fileno=callable, close=callable) def outlines(f, seq): """Outputs a sequence of lines to a file-like object""" assert isfilelike(f), "%r is not a file-like object." % f assert isiterable(seq), "%r must be iterable" % seq f.write("\n".join(seq)) #a trivial example... you'd get similar error messages from Python builtins even without the assertions. As it stands, I don't think that this deserves to be in Python - but I think the basic premise could be used as a foundation for better things. -- "What's money? A man is a success if he gets up in the morning and goes to bed at night and in between does what he wants to do." ~ Bob Dylan

1 0

Summary of Tracker Issues
by Tracker 15 Apr '07

15 Apr '07

ACTIVITY SUMMARY (04/08/07 - 04/15/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1649 open ( +2) / 8584 closed ( +0) / 10233 total ( +2) Average duration of open issues: 764 days. Median duration of open issues: 715 days. Open Issues Breakdown open 1649 ( +2) pending 0 ( +0) Issues Created Or Reopened (2) ______________________________ Art 04/12/07 http://bugs.python.org/issue1028 created artleafoll session error 04/13/07 http://bugs.python.org/issue1029 created artleafoll

1 0

fdopen mode needs sanitizing
by Kristján Valur Jónsson 14 Apr '07

14 Apr '07

In fileobject the mode string is sanitized using a function, sanitize_the_mode(). The same thing needs to happen for posixmodule.fdopen(). Otherwise, the universal_newlines regression test in test_subprocess.py will fail for python compiled with Visual Studio 2005. I have made a local patch by copying this static function over, and it fixes the issue, but I wonder if we would want to share this code? Also, are there other places that spring to mind where we have to sanitize mode strings before handing them to fopen-like functions? Kristján

1 0

Making builtins more efficient
by Steven Elliott 14 Apr '07

14 Apr '07

I'm interested in how builtins could be more efficient. I've read over some of the PEPs having to do with making global variables more efficient (search for "global"): http://www.python.org/doc/essays/pepparade.html But I think the problem can be simplified by focusing strictly on builtins. One of my assumptions is that only a small fractions of modules override the default builtins with something like: import mybuiltins __builtins__ = mybuiltins As you probably know each access of a builtin requires two hash table lookups. First, the builtin is not found in the list of globals. It is then found in the list of builtins. Why not have a means of referencing the default builtins with some sort of index the way the LOAD_FAST op code currently works? In other words, by default each module gets the default set of builtins indexed (where the index indexes into an array) in a certain order. The version stored in the pyc file would be bumped each time the set of default builtins is changed. I don't have very strong feelings whether things like True = (1 == 1) would be a syntax error, but assigning to a builtin could just do the equivalent of STORE_FAST. I also don't have very strong feelings about whether the array of default builtins would be shared between modules. To simulate the current behavior where attempting to assign to builtin actually alters that module's global hashtable a separate array of builtins could be used for each module. As to assigning to __builtins__ (like I mentioned at the beginning of this post) perhaps it could assign to the builtin array for those items that have a name that matches a default builtin (such as "True" or "len"). Those items that don't match a default builtin would just create global variables. Perhaps what I'm suggesting isn't feasible for reasons that have already been discussed. But it seems like it should be possible to make "while True" as efficient as "while 1". -- ----------------------------------------------------------------------- | Steven Elliott | selliott4(a)austin.rr.com | -----------------------------------------------------------------------

13 27

__lltrace__
by Kristján Valur Jónsson 14 Apr '07

14 Apr '07

Hello again. So, using __lltrace__, I stumbled over a crashbug (to which I have already submitted a fix).i To trigger the crash, I modified lib/test/test_trace.py, lines 609 onwards: def test_16_no_jump_into_finally_block(self): globals()["__lltrace__"] = 1 self.run_test(no_jump_into_finally_block) del globals()["__lltrace__"] This would crash in all versions I tried. Now, I wonder, is it worth it adding a regression test for the __lltrace__ functionality? I realize it is a debug feature, only availible in debug builds, for debugging python itself, on the other hand, it had been broken for a long time and no one had noticed, hence perhaps the need for a test? What do you think? Kristján

2 1

Re: [Python-Dev] Changes to decimal.py
by Nick Maclaren 14 Apr '07

14 Apr '07

"Tim Peters" <tim.peters(a)gmail.com> wrote: > > One low-effort approach is to use a general root-finding algorithm and > build ln(x) on top of exp() via (numerically) solving the equation > exp(ln(x)) == x for ln(x). ... Not a general one, please! At least use one that assumes the continuity of second derivatives :-) > However, the IBM spec requires < 1 ULP worst-case error, and that may > be unreasonably hard to meet with a root-finding approach. ... It's a doddle in a software implementation for civilised functions like log. All you do is to do the calculation in a sufficiently extended precision - and you can work that out in advance for very little extra effort. Then you round to the result - and, hey! Bob's your uncle! 0.501 ULPs is as easy as 1, if a bit slower. Now, doing that for the power function is a right royal pain in the neck, and you really DON'T want to even contemplate a generic gamma function, let alone one of the beta functions :-( But none of this is specific to a decimal base, of course. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1(a)cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679

1 0

ok to just checkin minor obvious fixes?
by Trent Mick 13 Apr '07

13 Apr '07

Is it generally accepted to just checkin obviously non-controversial fixes (*) (as long as there is no code freeze), or is it still preferred that I go through adding a patch to the SF tracker and getting review? Trent (*) In my case a tweak to the old VC6 Windows build files to ensure a clean build works (_ctypes project must depend on pythoncore proj). -- Trent Mick trentm at activestate.com

2 1

Extended Buffer Protocol - simple use examples
by Paul Moore 13 Apr '07

13 Apr '07

Hi, I'll admit right off that I haven't followed all of the extended buffer protocol discussions - I have no real need for anything much beyond the existing "here's a blob of memory" level of functionality. I have skimmed (briefly, I'll admit!) the pre-PEP, but I've found it extremely difficult to find a simple example of the basic (in my view) use case of an undifferentiated block of bytes. Can I suggest that the following uses would be the significant majority of buffer protocol uses - they are certainly going to be the basic transitional case from the existing protocol - and deserve to be singled out in the PEP with some description or (better) pseudo-code examples. If they are already there, I apologise, but I did look, and got bogged down in the more sophisticated stuff - so they probably need making more visible. 1. (Producer) I have a block of memory in my C extension and I want to expose it as a simple contiguous block of bytes to Python. 2. (Consumer) I want to get at a block of memory exposed as a buffer. I am only interested in, and only support, viewing a buffer as a block of contiguous bytes. I expect most if not all extensions to be able to provide such a view. I'd hope these 2 cases are pretty simple to code, but I'd like to see that made explicit in the PEP. unsophisticated-ly y'rs Paul.

2 3

test_pty.py hangs in verbose mode on Mac OS X?
by Barry Warsaw 13 Apr '07

13 Apr '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've been getting some test failures in Python 2.5 svn head on Mac OS X 10.4.9 which I'm not getting on Linux (Ubuntu feisty beta). test_sqlite and test_zipimport both fail, however, when run in verbose mode (e.g. ./python.exe Lib/test/test_sqlite.py) both pass. But that's not exactly why I'm writing this email <wink>. In the course of trying to debug this, I ran the following on my Mac: make TESTOPTS=-v test This runs the entire test suite in verbose mode, and you do get a lot of output. However the test suite hangs on test_pty.py. In fact, if you run that test alone: ./python.exe Lib/test/test_pty.py it too hangs for me. The reason is that in verbose mode, debug() actually prints stuff to stdout and on the Mac, when the child of the pty.fork() writes to its stdout, it blocks and so the parent's waitpid () never returns. This doesn't happen on Linux though; the child's stdout prints don't block, it exits, and the parent continues after the waitpid(). Here's a very simple program that reproduces the problem: - -----snip snip----- import os, pty, sys pid, fd = pty.fork() print >> sys.stderr, pid, fd if pid: os.waitpid(pid, 0) else: os._exit(0) - -----snip snip----- stderr, stdout, doesn't matter. This hangs on the Mac but completes successfully on Linux. Of course, in neither case do you see the child's output. I don't know if this is caused by a bug in the Mac's pty implementation or something we're doing wrong on that platform. I played around with several modifications to pty.fork() on the Mac, including letting it drop down to the openpty()/os.fork() code, even adding an explicit ioctl(slave_fd, TIOCSCTTY) call which Stevens chapter 19 recommends for 4.3+BSD. I can't get it to not block. Barring a fix to pty.fork() (or possibly os.forkpty()) for the Mac, then I would like to at least make test_pty.py not block when run in verbose mode. A very simple hack would add something like this to the "if pid == pty.CHILD" stanza: "def debug(msg): pass", possibly protected by a "if verbose:". A less icky hack would be to read the output from the master_fd in the parent, though you have to be careful with that on Linux else the read can throw an input/output error. Disabling debug output is band-aid yes, and any application on the Mac like the above snippet will still fail. If anybody has any suggestions, I'm all ears, but I've reached the limit of my pty-fu. mr-t-says-i-pty-the-fu-ly y'rs, - -Barry P.S. chime on on the test_sqlite and test_zipimport oddities if you want. :) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRh+Ug3EjvBPtnXfVAQJ4HgQAkm3XUq27GPBDKJj1NaIHuYijUerSE2oW 9YWiCYNQ+hBaYJJ16gdqZ2f7t/ENYVBzj3r9fNj+uyI1a6OFFMlE1tOdDFscQWUE e04XGwxo1fEPelJveIw8/dLHCPCpmCqvzLrT8fAtr7HL3thW3rk8s69i9i+CtJ1L LP7AY/SYXxg= =I+pF -----END PGP SIGNATURE-----

2 4

Pydoc Rewrite Discussion at doc-sig list.
by Ron Adam 13 Apr '07

13 Apr '07

If anyone is interested in participating in discussing the details of the PyDoc rewrite/refactoring I've been working on, a discussion is being started on the doc-sig list. Doc-Sig(a)python.org The goal of this discussion will be to get it to a final finished form so a patch can be submitted and a final discussion can take place on the python-dev list at a later date. Thanks and Regards, Ron Adam

1 0