Mailman 3 May 2003 - Python-Dev

composition sjvdkhxa k
by Karla Trotter May 9, 2003

May 9, 2003

1 0

RE: [Python-Dev] MS VC 7 offer
by Moore, Paul May 8, 2003

May 8, 2003

From: Guido van Rossum [mailto:guido@python.org] > > If this means that those of us with VC6, and with no plans/reasons to > > upgrade can no longer build our own extensions, this would be a > > disaster. > Part of the offer was: > | Potentially we can even figure out how to enable anyone to > | build Python using the freely downloadable compilers I mentioned > | above... Which is good news (don't get me wrong, I'm glad to see Microsoft supporting open source projects in this way). But wouldn't that imply unoptimised builds? I just checked: >cl /O2 Microsoft (R) 32-bit C/C++ Standard Compiler Version 13.00.9466 for 80x86 Copyright (C) Microsoft Corporation 1984-2001. All rights reserved. cl : Command line warning D4029 : optimization is not available in the standard edition compiler So, specifically, if PythonLabs releases Python 2.3 built with MSVC7, and I want to build the latest version of PIL, (maybe because Fredrik hasn't released a binary version yet), do I have no way of getting an optimised build (I pick PIL deliberately, because I guess that image processing would benefit from optimisation, and in the past, PIL binaries have been relatively hard to obtain at times)? That's the problem I see, personally. I have VC6 because my employer uses Visual Studio for Visual Basic development. But VB has changed so much in the transition to .NET, that I don't believe they will ever going to VS7. So I will have to remain with VS6 (I'm never going to buy VS7 myself, just for this sort of job). Paul.

3 2

RE: [Python-Dev] MS VC 7 offer
by Moore, Paul May 8, 2003

May 8, 2003

From: Neil Hodgson [mailto:nhodgson@bigpond.net.au] > Possible issues with moving to VC7 are ensuring compatibility with > extension modules That's the one that I see as most important. For the PythonLabs distribution to move to VC7, it sounds as if many of the Windows binary extensions in existence will also need to be built with VC7. I've no idea how much of a problem this would be to extension authors, but it would be a problem to end users if extension authors could no longer provide binaries. For reference, extensions I'd be in trouble without include win32all, wxPython, cx_Oracle, pyXML (on occasion), ctypes, PIL, mod_python. I've used many others on occasion, and no VC7 version would be an issue for me. So I guess that's the key issue. Can the majority of extension authors produce VC7-compatible binaries? This probably needs to be asked on comp.lang.python, not just on python-dev. Paul.

1 0

Re: [Python-checkins] python/dist/src/Doc/ext noddy2.c,NONE,1.1 noddy3.c,NONE,1.1 newtypes.tex,1.21,1.22
by Michael Hudson May 8, 2003

May 8, 2003

[Ccing python-dev because of the last paragraph] Jim Fulton <jim(a)zope.com> writes: > Michael Hudson wrote: >> dcjim(a)users.sourceforge.net writes: >> >>>Update of /cvsroot/python/python/dist/src/Doc/ext >>>In directory sc8-pr-cvs1:/tmp/cvs-serv13294 >>> >>>Modified Files: >>> newtypes.tex Added Files: >>> noddy2.c noddy3.c Log Message: >>>Rewrote the basic section of the chapter on defining new types. >> As the original author of this section, thank you! > > You're welcome. :) > > My main reason for doing this was to learn the material myself. > (I had the luxury of sitting next to Guido as I did it and bugging > him with questions. :) That would help :-) >> Do you mention anywhere that this only works for 2.2 and up? That >> might be an idea. > > OK, I'll add that in the introduction. It was *already* dependent on > Python 2.3 due to the use of PyMODINIT_FUNC as the type of the init > function. Yes. That wasn't me, and whoever changed it didn't keep the .c file in sync with the bits of it quoted in the .tex file, grumble. > I'm not sure why this is needed rather than void. Maybe I should change this > so it works with Python 2.2. I'll talk to Guido and Fred about this. The Py_MODINIT()/DL_IMPORT() thing is an annoying incompatibility-causer ... perhaps something to deal with this could be added to pymemcompat.h? (in which case it's misnamed...) Cheers, M. -- ARTHUR: Ford, you're turning into a penguin, stop it. -- The Hitch-Hikers Guide to the Galaxy, Episode 2

1 0

odd interpreter feature
by Skip Montanaro May 8, 2003

May 8, 2003

I was editing the tutorial just now and noticed the secondary prompt (...) in a situation where I didn't think it was appropriate: >>> # The argument of repr() may be any Python object: ... repr(x, y, ('spam', 'eggs')) "(32.5, 40000, ('spam', 'eggs'))" It's caused by the trailing colon at the end of the comment. I verified it using current CVS: >>> hello = 'hello, world\n' hellos = repr(hello) print hellos 'hello, world\n' >>> # hello: ... >>> Shouldn't the trailing colon be ignored in comments? Bug, feature or wart? Skip

8 11

local import cost
by Skip Montanaro May 8, 2003

May 8, 2003

Thanks to Raymond H for pointing out the probably fallacy in my original timeit runs. Here's a simple timer which I think gets at what I'm after: import time import math import sys N = 500000 def fmath(): import math def fpass(): pass v = sys.version.split()[0] t = time.clock() for i in xrange(N): fmath() fmathcps = N/(time.clock()-t) t = time.clock() for i in xrange(N): fpass() fpasscps = N/(time.clock()-t) print "%s fpass/fmath: %.1f" % (v, fpasscps/fmathcps) On my Mac I get these outputs: 2.1.3 fpass/fmath: 5.0 2.2.2 fpass/fmath: 5.6 2.3b1+ fpass/fmath: 5.3 Naturally, I expect fpass() to run a lot faster than fmath(). If my presumption is correct though, there will be a sharp increase in the ratio, maybe in 2.0 or 2.1, or whenever nested scopes were first introduced. I can't run anything earlier than 2.1.x (I'll see about building 2.1) on my Mac. I'd have to break out my Linux laptop and do a bunch of downloading and compiling to get earlier results.

1 0

Building Python with .NET 2003 SDK
by logistix May 8, 2003

May 8, 2003

I decided to see if you really could build Python with the .NET compiler. I just got a preliminary build done that passed 67 tests (and failed 17) Two big gothas: 1) You also need to install the "Platform SDK". This one makes the .NET SDK download seem fast. 2) VC6 generated makefiles include references to a few .lib files that aren't included. They also don't seem to be needed either. The offending librarys are largeint.lib, odbc32.lib, and odbccp32.lib. More detailed notes on what had to be done to get it working can be found here, http://www.cathoderaymission.net/~logistix/python/buildingPythonWithDotN et.html Enjoy! -Grant

1 0

bsddb185 module changes checked in
by Skip Montanaro May 7, 2003

May 7, 2003

The various bits necessary to implement the "build bsddb185 when appropriate" have been checked in. I'm pretty sure I don't have the best possible test for the existence of a db library, but it will have to do for now. I suspect others can clean it up later during the beta cycle. The current detection code in setup.py should work for Nick on OSF/1 and for platforms which don't require a separate db library. I'd appreciate some extra pounding on this code. Thanks, Skip

3 2

Re: [Python-Dev] odd interpreter feature
by Pat Miller May 7, 2003

May 7, 2003

Skip writes: > >>> # hello: > ... > >>> > > Shouldn't the trailing colon be ignored in comments? Bug, feature or wart? I figured it was a feature... Taking the view that any source block asks for continuations seemed natural, so I assumed Guido intended it that way ;-) If the comments were active objects (like doc strings), then it would be the desired association. >>> # About to do something tricky ... tricky() >>> Pat -- Patrick Miller | (925) 423-0309 | http://www.llnl.gov/CASC/people/pmiller All you need in this life is ignorance and confidence, and then success is sure. -- Mark Twain

1 0

Relying on ReST in the core?
by Andrew Kuchling May 7, 2003

May 7, 2003

For PEP 314, it's been suggested that the Description field be written in RestructuredText. This change doesn't affect the Distutils code, because the Distutils just takes this field and copies it into an output file; programs using the metadata defined in PEP 314 would have to be able to process ReST, though. I know the plan is to eventually add ReST/docutils to the standard library, and that this isn't happening for Python 2.3. Question: is it OK to make something in the core implicitly depend on ReST before ReST is in the core? Until docutils is added, there's always the risk that we decide to never add ReST to the core, or ReST 2.0 changes the format completely, or we decide XYZ is much better, or something like that. --amk (www.amk.ca) IAGO: Poor and content is rich and rich enough. -- _Othello_, III, iii

2 1