Mailman 3 January 2009 - Python-Dev

Additional behaviour for itertools.combinations
by Konrad Delong Jan. 25, 2009

Jan. 25, 2009

I'm not sure if it's the right place to post it. If so - I'll be glad to learn where is one. Anyway: I think the function itertools.combinations would benefit from making the 'r' (length of the combinations) argument optionally a sequence. With that change one could call combinations(sequence, [2, 3]) in order to get all combinations of length 2 and 3. In particular, one could call combinations(sequence, range(len(sequence)) in order to get *all* combinations of given sequence. The change would be backwards compatible as it would check for sequential arguments. Is it worth the shot? best regards Konrad PS. Didn't want to spoil the beginning of the post, but I consider it to be a good practice to introduce oneself when posting the first time, so: Hello, my name is Konrad, I'm an IT student and I'm following python-dev for some time, but never posted before.

4 4

Change Makefile.pre.in based on configure?
by skip＠pobox.com Jan. 25, 2009

Jan. 25, 2009

I'm working on issue 4111 which will add dtrace support to Python when requested by the builder and when supported by the platform (currently just Solaris and Mac OSX I believe). Sun and Apple have quite different ways to generate the code necessary to link into the executable. Sun's dtrace command supports a -G flag which generates a .o file from a .d file. Apple instead generates an include file using the -h flag to dtrace (-G and .o file generation are not supported). This puts a bit of a crimp in generating Makefile dependencies. In the Sun case you have a couple extra .o files to link into libpython. In the Apple case you have a couple extra .h files which define Dtrace macros. How do I work around this difference in Makefile.pre.in? I can detect Sun vs. Apple in the configure script, but I see no conditional logic in Makefile.pre.in to use as an example. It seems to only use variable expansion on the RHS of stuff. Can I do something like if @WITH_DTRACE_SUN@ = 1 then ... Sun-style dependencies here ... else ... Apple-style dependencies here ... fi where WITH_DTRACE_SUN is a macro defined in pyconfig.h by the configure script? Thanks, Skip

3 3

ac_sys_system == Monterey*?
by skip＠pobox.com Jan. 24, 2009

Jan. 24, 2009

>From configure.in: # The current (beta) Monterey compiler dies with optimizations # XXX what is Monterey? Does it still die w/ -O? Can we get rid of this? case $ac_sys_system in Monterey*) OPT="" ;; esac What is Monterey? Can this check be removed from trunk/py3k branches? Skip

3 4

mingw+msys port of python2.7a0 (svn #r68884)
by Luke Kenneth Casson Leighton Jan. 24, 2009

Jan. 24, 2009

http://bugs.python.org/issue5046 mingw+msys port which was previously done against python-2.5.2 has been brought forward to latest subversion r68884. the primary reason for initially doing python 2.5.2 was to 1) "stay out of the way" of primary python development 2) provide some hope for those people still using win98 and nt. builds using msvcr90 are possible with the --enable-msvcr9build switch. install mingw, install msys, optionally install a boat-load of libraries such as sqlite3, zlib, bz2, dbm etc. (good luck, it's a pain - ask me if you'd like some prebuilt). make sure you patch the mingw runtime if you want to use --enable-msvcr9build (again, ask me if you'd like the patched headers and prebuilt libmsvcrNN.a files). also added is the msi module - http:/ /lkcl.net/msi.tgz and run make in the msi directory, to install the import libraries and header files borrowed from Wine and beaten into submission. run ./configure --enable-win32build=yes --enable-shared=yes and go do something else for about 10 minutes, then run make and make install. no proprietary compilers or tools were used or harmed [*] in the making or development of this patch. l. [*] such a shame...

1 0

Should ftplib use UTF-8 instead of latin-1 encoding?
by Giampaolo Rodola' Jan. 24, 2009

Jan. 24, 2009

Hi, while attempting to port pyftpdlib [1] to Python 3 I have noticed that ftplib differs from the previous 2.x version in that it uses latin-1 to encode everything it's sent over the FTP command channel, but by reading RFC-2640 [2] it seems that UTF-8 should be preferred instead. I'm far from being an expert of encodings, plus the RFC is quite hard to understand, so sorry in advance if I have misunderstood the whole thing. Just wanted to put this up to people more qualified than me. [1] http://code.google.com/p/pyftpdlib [2] http://www.ietf.org/rfc/rfc2640.txt --- Giampaolo http://code.google.com/p/pyftpdlib

9 13

About SCons Re: progress: compiling python2.5 under msys (specifically but not exclusively under wine) with msvcr80
by anatoly techtonik Jan. 24, 2009

Jan. 24, 2009

On Thu, Jan 22, 2009 at 12:51 AM, Roumen Petrov <bugtrack(a)roumenpetrov.info> wrote: >> >> Against 2.3, rejected due to dependence on SCons. >> Also appears to have been incomplete, needing more work. > > No it was complete but use SCons. Most of changes changes in code you will > see again in 3871. > I would better use SCons for both unix and windows builds. In case of windows for both compilers - mingw and microsoft ones. To port curses extension to windows I need to know what gcc options mean, what are the rules to write Makefiles and how to repeat these rules as well as find options in visual studio interface. Not mentioning various platform-specific defines and warning fixes. -- --anatoly t.

2 2

__del__ and tp_dealloc in the IO lib
by Antoine Pitrou Jan. 24, 2009

Jan. 24, 2009

Dear python-dev, The Python implementation of IOBase, the base class for everything IO, has the (strange) idea to define a __del__ method. It is probably meant to avoid code duplication, so that users subclassing IOBase automatically get the close-on-destruct behaviour. (there is an even stranger test in test_io which involves overriding the __del__ method in a class derived from FileIO...) However, it has the drawback that all IO objects inherit a __del__ method, meaning problems when collecting reference cycles (the __del__ may not get called if caught in a reference cycle, defeating the whole point). While rewriting the IO stack in C, we have tried to keep this behaviour, but it seems better to just do it in the tp_dealloc function, and kill the __del__ (actually, we *already* do it in tp_dealloc, because __del__ / tp_del behaviour for C types is shady). Subclassing IOBase in Python would keep the tp_dealloc and therefore the close-on-destruct behaviour, without the problems of a __del__ method. (the implementation has to take a few precautions, first revive the object, then check its "closed" attribute/property - ignoring errors -, and if "closed" ended False then call the close() method) What do you think? Antoine.

12 22

compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
by Luke Kenneth Casson Leighton Jan. 23, 2009

Jan. 23, 2009

folks, hi, this is a fairly important issue for python development interoperability - martin mentioned that releases of mingw-compiled python, if done with a non-interoperable version of msvcrt, would cause much mayhem. well, compiling python on mingw with msvcr80 _can_ be done; using it can also be a simple matter of creating a python.exe.manifest file, but i can't actually do any testing because it doesn't work under wine. so, pending any further advice and guidance from anyone which allows me to successfully proceed, i'm not going to continue to compile - or release - python2.5 *or* python2.6 builds (when i get round to that) using msvcr80 or msvcr9X. one issue in favour of this decision is that the DLL that's produced by the autoconf build process is "libpython2.5.dll.a" - not "python2.5.dll". it has a different name. it should be abundantly clear to users and developers that "if name equals libpython2.5.dll.a then duh build equals different". additionally, the setup.py distutils all goes swimmingly well and lovely - using libpython2.5.dll.a. the only issue which _is_ going to throw a spanner in the works is that people who download win32-built precompiled c-based modules are going to find that hey, "it don't work!" and the answer will have to be "go get a version of that module, compiled with mingw, not MSVC". of course - if python for win32 ENTIRELY DROPPED msvc as a development platform, and went for an entirely free software development toolchain, then this problem goes away. thoughts, anyone? l.

12 39

distutils.mwerkscompiler and macpath deprecation
by Tarek Ziadé Jan. 23, 2009

Jan. 23, 2009

Hi, for http://bugs.python.org/issue4863 If no one objects, I am going to remove the mwerkscompiler module from distutils without any deprecation process, as Martin suggested (since it is linked into ccompiler with "mac" for the os.name) Now the question is, should I add a ticket to deprecate macpath.py as well ? Regards Tarek -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/

1 0

Update on MS Windows CE port
by Ulrich Eckhardt Jan. 23, 2009

Jan. 23, 2009

Hi! Just a short update on my porting issues. I tried various things in the holidays/vacation, filed several bug reports, got a few patches applied and I think the thing is taking shape now. However, I couldn't work on it for the past two weeks since I'm just too swamped at work here. I haven't given up though! What still needs work? The main component that requires porting is the pythoncore project, but that port isn't finished yet. I'm using the VS8.0 project files as a base and adapted it in the following steps (note that this is preliminary): 0. Check out trunk (i.e. 2.x, not 3.x). 1. Create new project configuration for your CE target and use the win32 one as a base. 2. In the preprocessor settings, add these entries: UNICODE,_UNICODE,UNDER_CE,_WIN32_WCE=$(CEVER) 3. Try compiling. ;) What issues are left? There are two classes of errors you will encounter, those that are related to CE itself (like missing errno and other parts of standard C) and those that are more general, like assuming TCHAR=char. Those that assume that TCHAR=char can also be found with the plain win32 variant by simply adding UNICODE and _UNICODE to the preprocessor defines. What are the future plans? I'm trying to fix errors in pythoncore one by one and provide separate bug reports with patches. Note that there are already several patches in the BTS which would merit reviews if you have time, even if it's only a "patch applies and doesn't cause regressions". When I get pythoncore to compile (and be it by disabling a few builtin modules), I will try to get the commandline interface to work. Note that IIRC there are two commandlines availabel under CE, one is a common cmd.exe, the other is called AYGShell or some such. Both will/might require different approaches. Another problem is the fact that there is not just one target platform but a potentially infinite number of them, since every CE device can have a separate SDK which further might provide different features. This probably requires autogenerated build files or some other autoconf-like procedure that allows enabling or disabling certain features for builds. so much for now Uli -- Sator Laser GmbH Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 ************************************************************************************** Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 ************************************************************************************** Visit our website at <http://www.satorlaser.de/> ************************************************************************************** Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden. E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich. **************************************************************************************

2 1