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 … [View More]

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 … [View More]

3 3

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

Jan. 25, 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. 25, 2009

Jan. 25, 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, … [View More]

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:… [View More]

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 … [View More]

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 … [View More]

12 22

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

Jan. 24, 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 … [View More]

12 39

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

Jan. 24, 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. 24, 2009

Jan. 24, 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 … [View More]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. ************************************************************************************** [View Less]

2 1