Mailman 3 July 2004 - Python-Dev

Adding directories to configure.in for fink?
by Brett Cannon July 19, 2004

July 19, 2004

I discovered that when compiling for readline against a Fink install a warning was spit out about the lack of a function definition. Turned out a function that #ifdef'ed a macro was not being triggered because configure.in was not catching the header file in /sw/lib for readline. Since /sw is already looked at by setup.py, is there any way to have configure.in do it as well so as to have some consistency? Or is prepending ``LDFLAGS=/sw/lib`` the only way? If so, does it warrant mentioning in the README? -Brett

6 8

[Python-Dev] Re: [Python-checkins] python/dist/src/PC config.c, 1.47, 1.48
by Hye-Shik Chang July 18, 2004

July 18, 2004

On Sat, 17 Jul 2004 22:06:33 -0700, tim_one(a)users.sourceforge.net <tim_one(a)users.sourceforge.net> wrote: > Update of /cvsroot/python/python/dist/src/PC > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv23589/PC > > Modified Files: > config.c > Log Message: > Woo hoo! All the encoding tests pass on Windows (& I downloaded the > 14 input files needed to run all of them). > Thanks for fixing cjkcodecs to build in Windows again. I'll rearrange cjkcodecs.h to get rid of the problem you described, soon. :) Hye-Shik

1 0

Kill FCNTL.py
by Tim Peters July 18, 2004

July 18, 2004

Can we get rid of Lib/FCNTL.py for 2.4? AFAICT, its existence does nothing but create obscure problems for Windows users. For an old example, in tempfile.py: try: import fcntl as _fcntl # If PYTHONCASEOK is set on Windows, stinking FCNTL.py gets # imported, and we don't get an ImportError then. Provoke # an AttributeError instead in that case. _fcntl.fcntl except (ImportError, AttributeError): For an example from yesterday: http://mail.zope.org/pipermail/zope-dev/2004-July/023463.html I don't know all the ways this happens, but a surprising number of Windows users end up with a file named: fcntl.pyc in their Lib directories, and then tons of things break, because imports of fcntl pick that up instead of getting the ImportError cross-platform code expects on Windows. I know that one persistent user traced this to one of the Python-aware installer-builders creating allupper.pyc files from ALLUPPER.py files on Windows, but it's not worth the effort of tracking this down: since the day it was introduced, FCNTL.py has generated a deprecation warning telling you to use fcntl instead. The builtin fcntl was introduced in 1.5a3. Enough already <wink>.

2 1

Re: [Python-Dev] Non-Visual Studio builds on Windows XP?
by Nick Coghlan July 17, 2004

July 17, 2004

Michael Walter wrote: > I was under the impression that nmake worked with .sln or .vcproj files. > > On Sat, 17 Jul 2004 21:59:35 +1000, Nick Coghlan <ncoghlan(a)iinet.net.au> wrote: > >>I'm probably missing something obvious, but what can I use to interpret >>the vcproj build files? >> > That something obvious I mentioned? The main problem I had was that nmake isn't in the free VC Toolkit. It eventually occured to me that it isn't in the VC toolkit because its already in some of the other free downloads from MS. . . Thanks, anyway :) Cheers, Nick. -- Nick Coghlan | Brisbane, Australia Email: ncoghlan(a)email.com | Mobile: +61 409 573 268

2 2

None as constant. Still SyntaxWarning
by Simon Percivall July 17, 2004

July 17, 2004

After the recent change in CVS None in is treated like a constant, and assigment to it fails. But it _seems_ to pass with a SyntaxWarning just like in 2.3.

2 1

Does CVS Python work for anyone else?
by Tim Peters July 17, 2004

July 17, 2004

On WinXP, it segfaults instantly, while trying to import site.py. I'm able to get into the interpreter by passing -S (skips importing site.py). Any attempt to run the test suite also segfaults instantly, even with -S.

2 2

Developer looking to help fix bugs
by Mike Mangino July 17, 2004

July 17, 2004

Hello, My name is Mike Mangino. I am an IT weenie in Chicago Illinois, USA who has used python in various projects for several years. I have recently finished school (again) and am looking for a project I can work on to learn. My huge ambition is to eventually port python to the palm pilot with a reasonable graphical interface. I have learned my lesson in the past about jumping into ambitious projects too quickly. As such, I am interested fixing and triaging bugs in the sourceforge tracker. Earlier today I added a comment to http://www.python.org/sf/982679 to tell the user how to fix the problem they were having (it was a bug in their code, not python) How do I have somebody close that request? In the future, if I fix one of the issues, is there somebody I should email to make changes? I look forward to helping out in whatever way I can. I have experience in C, Java, databases and many other languages in addition to an MBA with focus on Finance. My guess is that the C will be most helpful, but who knows. If you want to discuss asset pricing, I can probably help with that as well. If anyone is in the Chicago area, I would love to buy you a beer and pick your brain. Mike Mangino

5 5

"as" to be a keyword?
by Phillip J. Eby July 16, 2004

July 16, 2004

Is it true that 'as' is going to become a keyword in future? I ask, because I was thinking about implementing an 'as' function, such that: [as(classmethod)] def foo(...): ... will work for Python 2.2 and up. Actually, I've already written and tested the function itself, it's just that I would like to be sure that I shouldn't try to come up with another name. :)

3 2

Planned changes to logging
by Vinay Sajip July 16, 2004

July 16, 2004

I'm planning to check in some changes to the logging package. I'd appreciate comments on the following: 1. A backwards-compatible change to basicConfig(), making simple configuration of logging easier than before. For example, to change the level of the root logger to DEBUG: logging.basicConfig(level=logging.DEBUG) For example, to change the message format: logging.basicConfig(format="%(asctime)s %(levelname)-5s %(message)s") To log to a file in append mode (for write mode, add a filemode="w" argument): logging.basicConfig(filename="/logs/myapp.log") To log to an existing stream: s = open("/logs/myapp.log", "w") ... logging.basicConfig(stream=s) 2. Refactoring of RotatingFileHandler into BaseRotatingHandler and RotatingFileHandler. The reason for this is the addition of a new class, TimedRotatingFileHandler, which rotates files based on time-dependent criteria. (See SF patch #921318 for more details). 3. Logger.log() changed to throw a TypeError if raiseExceptions is set and the level passed in is not an integer. If the changes seem generally acceptable, then I'll also add a section in the docs which describes the above basic use cases under a "Basic use of the logging package" section which appears earlier in the logging docs than it does currently. Except for the documentation changes, I'm planning to commit by 3 July. Thanks, Vinay

3 4

Re: [Python-checkins] python/dist/src/Lib/distutils __init__.py, 1.23, 1.24
by Thomas Heller July 16, 2004

July 16, 2004

theller(a)users.sourceforge.net writes: > Update of /cvsroot/python/python/dist/src/Lib/distutils > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv3551 > > Modified Files: > __init__.py > Log Message: > The new distutils features justify a new version number, imo. > > If someone has other ideas for the numbering scheme, please change to > something else (1.1.0 ?). After I committed this, it ocurred to me: certainly 2.4.0 ? Thomas

1 0

Proposal: C API Macro to decref and set to NULL
by Jim Fulton July 16, 2004

July 16, 2004

Often, in C type implementations, you want to set a PyObject * slot to NULL. Often this goes like: Py_XDECREF(self->foo); self->foo = NULL; However, if your type participates in GC and self->foo is something that might get traversed, this can lead to traversing self->foo after it has been DECREFed, but before it's set to NULL. The correct way to do this is something like: tmp = self->foo; self->foo = NULL; Py_XDECREF(tmp); I suggest that there should be a standard macro to automate this. Py_CLEAR(self->foo) This would be defined to be the same result as Py_XDECREF except that the argument will be set to NULL. Thoughts? If there are no objections I'll add the following definition to object.h, after the definition for Py_DECREF: #define Py_CLEAR(op) \ do { \ if (op) { \ PyObject *tmp = (op); \ (op) = NULL; \ Py_DECREF(tmp); \ } \ } while (0) and update the docs and the tutorial on creating types in C. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

9 24

Absolute/Relative import switcher for packages (PEP 328)
by Wiktor Sadowski July 16, 2004

July 16, 2004

FWIW: Here is the solution for Absolute/Relative problem that we are using in our modified Python distribution... We have added a few lines of code to to get_parent in import.c. The code checks if there is "__absimport__=True" in parent dict and if so: absolute import is used in "child" module (get_parent returns Py_None) Then putting "__absimport__=True" into an __init__.py is enough to force absolute import for the whole package. (The "__absimport__=True" switcher should be put into each subpackage __init__.py,if desired) Such addition is fully compatible with existing Python import syntax and easy to use. Also: absolute import could be default,and "__relimport__=True" would switch to relative import. If nothing else,the switcher really helps with tracking absolute/relative import bugs in Python packages. Wiktor Sadowski

2 1

RELEASED Python 2.4, alpha 1
by Anthony Baxter July 16, 2004

July 16, 2004

On behalf of the Python development team and the Python community, I'm happy to announce the first alpha of Python 2.4. Python 2.4a1 is an alpha release. We'd greatly appreciate it if you could download it, kick the tires and let us know of any problems you find, but it is not suitable for production usage. http://www.python.org/2.4/ In this release we have a number of new modules, a number of existing modules that have been reimplemented in C for speed, a large number of improvements and additions to existing modules and an even larger list of bugs squished. See either the highlights, the What's New in Python 2.4, or the detailed NEWS file -- all available from the Python 2.4 webpage. There will be at least one more alpha release in a couple of weeks to pick up a few new features that didn't make it into the first alpha, before we release 2.4 betas and then the final release. Please log any problems you have with this release in the SourceForge bug tracker (noting that you're using 2.4a1): http://sourceforge.net/bugs/?group_id=5470 Enjoy the new release, Anthony Anthony Baxter anthony(a)python.org Python Release Manager (on behalf of the entire python-dev team)

3 2

RE: [Python-Dev] Planned changes to logging
by Michael Chermside July 16, 2004

July 16, 2004

> Better still, it seems entirely consistent with these semantics to > have the existing log objects reset to their parent settings -- just > like unspecified log objects created after the confguration load do. > I think this is more consistent, more intuitive, and doesn't require > you to figure out what logs may or exist throughout the system when > loading a configuration. +1 (based on my experiences with java.logging, not with the Python module) -- Michael Chermside

1 0

Assignment to None
by Raymond Hettinger July 16, 2004

July 16, 2004

Python 2.4a1+ (#46, Jul 14 2004, 04:25:40) [MSC v.1200 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. IDLE 1.1a2 >>> None = 0 SyntaxError: assignment to None (<pyshell#0>, line 1) >>> def f(): None = 0 SyntaxError: assignment to None (<pyshell#2>, line 2) Do this imply that the compiler can now treat None as a constant? Raymond Hettinger

3 2

[Python Dev] HTML side by side diff - can it go in a2?
by Dan Gass July 16, 2004

July 16, 2004

Python Patch #914575 (https://sourceforge.net/tracker/?func=detail&atid=305470&aid=914575&group_i…) The patch now includes documentation, code, and test changes (in contextual diff format) per a request by Martin v. Löwis in the patch followups. I have also tweaked the user interface and am now comfortable with it. I have seen positive comments from Tim Peters and others and have implemented all suggestions to date. Can this patch be considered for the alpha 2 release? This new feature could be useful for doing full Python build comparisons (generating an HTML page listing all files that changed with hyper links to pages showing the side by side differences). If there would be a use for such a tool to make your release review easier or to get a good feeling in your gut before it goes out the door I would be more than happy to assist in writing one. The tool would be relatively easy to write. Dan Gass

1 0

Proper tail recursion
by Christopher T King July 15, 2004

July 15, 2004

JanC recommended I post this on python-dev to get feedback. To sum up the previous posts in my thread on comp.lang.python, I've created a patch that optimizes tail calls in the CPython interpreter, so that the stack is not used for functions called in a tail context. The current patch is only a partial implementation, and might have some memory leaks with regards to exceptions (I haven't compared this to vanilla 2.4a1's behaviour yet), but works for simple test cases. If such behaviour is deemed desirable, I'll finish the patch, clean up the code, and work out any bugs. The relevant portion of the original message follows. --- I have a preliminary implementation ready, the patch is against 2.4a1: http://users.wpi.edu/~squirrel/temp/tailcall.diff.gz This patch only works for simple functions (i.e. those that can be handled by fast_function), but extension to other function types should be trivial. I haven't fully tested this with regards to exception handling and whatnot, so I want to stick with a simple case for now. The patch works roughly as follows: 1. When a CALL_FUNCTION opcode is encountered, check if the following opcode is RETURN_VALUE. If so, execute the tail call code. 2. The tail call code calls a modified version of call_function that sets up and returns a frame object for the function to be called (if possible), rather than recursively calling PyEval_EvalFrame. This frame is stored in a temporary variable, and a RETURN_VALUE is simulated to exit the loop. 3. After cleaning up the current frame, PyEval_EvalFrame loops back up to the top, now using the temporarily stored frame as the current frame. Of course, instead of a loop, gcc's tail-call optimization feature could be used, but this would be non-portable to other compilers. An example of the patch in action: # Note default arguments aren't supported in the current patch def fact2(n,v): if n: return fact2(n-1,v*n) else: return v def fact(n): return fact2(n,1) Without the patch: >>> fact(10000) RuntimeError: maximum recursion depth exceeded With the patch: >>> fact(10000) <really really huge number> Any feedback would be greatly appreciated!

9 12

RE: [Python-Dev] Proper tail recursion
by Michael Chermside July 15, 2004

July 15, 2004

I wrote: > The recursion limit (the value of it anyhow) is an implementation detail. Martin replies: > No, it is not. In standard Python, the program > > def rec(n): > rec(n-1) > > n=1 > while 1: > try: > rec(n) > except RuntimeError: > break > print "The recursion limit is", n > > will terminate. In the modified Python, it will not terminate. > It is a change in behaviour, and thus a language feature. First, I'm going to make a slight modification to your program, since I want a version that actually does display the recursion limit. I tried the following program instead: >>> def rec(n): ... print n ... rec(n+1) ... >>> rec(1) Running this in Jython 2.1 (a well-known implementation of the Python language) produced the numbers from 1 to 888, then immediately exited. Running it on CPython 2.3 produced the numbers from 1 to 999, then a traceback that looked like this: Traceback (most recent call last): File "<stdin>", line 1, in ? File "<stdin>", line 3, in rec File "<stdin>", line 3, in rec File "<stdin>", line 3, in rec File "<stdin>", line 3, in rec File "<stdin>", line 3, in rec File "<stdin>", line 3, in rec [... etc for a total of about 1000 lines ...] File "<stdin>", line 3, in rec File "<stdin>", line 3, in rec File "<stdin>", line 3, in rec File "<stdin>", line 3, in rec RuntimeError: maximum recursion depth exceeded It then returned me to the interactive prompt. I presume that since the behavior was different, CPython must not actually be a correct implementation of the Python language, right? Not-all-differences-are-language-differences lly yours, Michael Chermside

1 0

RE: [Python-Dev] Proper tail recursion
by Michael Chermside July 15, 2004

July 15, 2004

Guido writes: > Still -1. I was understating my case: I find the "recursion is the > basis of everything" attitude harmful. Just for the record, I understand that is your objection, I simply wanted to publicly disagree with it. I have a great deal of respect for your judgement, but occasionally I think you're wrong <wink>. Michael Walter writes: > Anyway there was no agreement yet that Jython couldn't support that > _feature_, too, IIRC - I would certainly be happy to have it in > Python. Well, I think I understand Jython well enough to provide the assurance: Jython is (intentionally, and for good reason) designed to utilize the JVM's call stack. Thus Jython cannot support tail call elimination *unless* it is run on a JVM which does tail call elimination. I don't believe any such JVM exists, but as far as I know, the JVM specification *allows* it. -- Michael Chermside

3 2

RE: [Python-Dev] Proper tail recursion
by Michael Chermside July 15, 2004

July 15, 2004

> > Well, I think I understand Jython well enough to provide the > > assurance: Jython is (intentionally, and for good reason) designed > > to utilize the JVM's call stack. Thus Jython cannot support tail > > call elimination *unless* it is run on a JVM which does tail call > > elimination. > > I originally thought I'd need to use gcc's tail call optimization to > achieve my aim (since CPython works the same way), but it > turned out a > simple loop would suffice. Unless Jython's implementation is > radically > different (i.e. it doesn't pass frame objects to a function > that evaluates > them) then it should be able to be implemented similarly. Like I said, Jython uses the JVM's call stack. So it certainly doesn't pass frame objects to a function that evaluates them... Jython stack frames are actual Java stack frames. This is part of why Jython does such an incredibly good job of integrating tightly with Java -- Java any Jython functions (methods) can call each other freely because they're practically the same thing. -- Michael Chermside

1 0

What is test__locale supposed to test, anyhow?
by Nick Bastin July 15, 2004

July 15, 2004

test__locale, as written, tests that the data we get from nl_langinfo() matches the data acquired from localeconv(), but it doesn't actually make sure that any part of this data is correct. Is this intentional? Is anybody going to mind if I rewrite this test to check that the values are actually *correct*? This will mean more failures on platforms like solaris, where the system locale data is incorrect. -- Nick

5 11

Pie-thon at OSCON 2004?
by Skip Montanaro July 15, 2004

July 15, 2004

Have Guido and Dan been practicing their aim with a pie? The topic of the Python/Parrot shootout hasn't come up in awhile. I thought I'd ask since OSCON 2K4 is only a couple weeks away. Skip

6 7

PEP 292 for Python 2.4
by Barry Warsaw July 15, 2004

July 15, 2004

PEP 292 is slated for inclusion in Python 2.4, according to PEP 320. At Pycon I checked in my code for this into the sandbox, which I've since updated, adding unit tests. I believe it's ready for inclusion in dist CVS, but I want to get some feedback first. My new stuff provides two classes, dstring() as described in PEP 292 and astring() as hinted at in the PEP. It also provides two dictionary subclasses called safedict() and nsdict() which are not required, but work nicely with dstring() and astring() -- safedict re-expands keys instead of throwing exceptions, and nsdict does namespace lookup and attribute path expansion. Brett and I (I forget who else was there for this) talked about where to situate the PEP 292 support. The interesting idea came up to turn the string module into a package, providing backward support for the existing string module API, then exporting my PEP 292 modules into this namespace. This would make the 'import string' useful again since it would be a place to collect future string related functionality without having to claim some dumb name like 'stringlib'. I believe we can still someday deprecate the old string module functions, retaining the useful constants, as well as new string-y features. This is actually not hard to do, and I have this working (and passing the existing unit tests) in a local checkout. You simply create the Lib/string directory, copy or move Lib/string.py to Lib/string/string.py and do a bit of import-* in Lib/string/__init__.py. The unit tests all passed with no changes necessary. I'd drop my pep292.py file and safedict.py file into Lib/string and import the useful names out of there, exposing them in the string namespace. Is this a good idea? I dunno, but it seems better to me than adding two more top-level modules with largely contrived names; nothing better jumps out to me. I also really want to include safedict.py if we're including pep292.py because they're quite useful and complimentary, IMO, and I can't think of a better place to put those classes either. I'm open to suggestions. I have not yet written docs for these new classes, but will do so once we agree on where they're getting added. The code and test cases are in python/nondist/sandbox/string. -Barry

11 17

Re: [Python-Dev] Why is Bytecode the way it is?
by Chris King July 15, 2004

July 15, 2004

While recently goofing around with the bytecode, I thought of doing something like this: case LOAD_CONST: x = GETITEM(consts, oparg); Py_INCREF(x); + if (*next_instr == RETURN_VAL) { + retval = x; + why = WHY_RETURN; + goto fast_block_end; + } PUSH(x); goto fast_next_opcode; This would skip the stack and a trip through the loop without changing the parser or the bytecode, and with a minimal amount of added code or overhead. This could (of course) be applied to other opcodes, too. Perhaps instead of littering the function with that block, a macro "PUSH_MAYBE_RET" could be added that would replace the final PUSH in the opcode's case block: #define PUSH_MAYBE_RET { if (*next_instr == RETURN_VAL) { \ retval = x; \ why = WHY_RETURN; \ goto fast_block_end; } \ PUSH(x); } Not sure how much this would help speed, if any.

6 5

RE: [Python-Dev] Pie-thon at OSCON 2004?
by Tony Meyer July 15, 2004

July 15, 2004

[amk] > I forget the terms of the bet; is it running on Python 2.3.4, or the > 2.4alpha1 release, or on Python CVS? Maybe we should check that > 2.4CVS hasn't regressed in performance when compared to 2.3. [Skip] > I saw somewhere today when searching (maybe Dan S's > website?) that it was 2.3 as of about December 2003. That's correct: <http://mail.python.org/pipermail/python-dev/2003-December/040977.html> <http://mail.python.org/pipermail/python-dev/2003-December/041527.html> It's also in the README.txt file in the parrotbench directory. =Tony Meyer

5 5