Re: [Python-Dev] PEP 3142: Add a "while" clause to generator expressions
Terry Reedy wrote: Cameron Simpson wrote: Back at uni we had to implement a small language in our compilers class and the lecturer had specified a proper generic while loop, thus: loop: suite while invariant suite endloop In Python, that is spelled while True: suite if not invariant: break suite Indeed. This is the well known "loop and a half" problem. Eric. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
Hello, On Wed, Jan 21, 2009 at 22:07, Luke Kenneth Casson Leighton wrote: > On Wed, Jan 21, 2009 at 7:42 PM, "Martin v. Löwis" wrote: >>> sorry, martin - i thought the win32 builds generated python25.lib, >>> python25.dll >> >> Correct. >> >>> and python25.def >> >> No. >> >>> so as to fit into the 8.3 filename convention. >> >> No. It generates python25.lib because that's the import library >> for python25.dll. It calls it python25.dll because the lib prefix >> is atypical for the platform, and also redundant (DLL means >> "dynamic link library"). >> >> The Python binary installer also includes libpython25.a, for use >> with mingw32. > > ok, so - different from what's being generated by ./configure under > msys under wine or native win32 - what's being generated (libpython 2 > . 5 . a and libpython 2 . 5 . dll . a) is more akin to the cygwin > environment. > > therefore, there's absolutely no doubt that the two are completely different. > > and on that basis, would i be correct in thinking that you _can't_ go > linking or building modules or any python win32 code for one and have > a hope in hell of using it on the other, and that you would _have_ to > rebuild e.g. numpy for use with a mingw32-msys-built version of > python? > > or, is the .pyd loading a bit cleverer (or perhaps a bit less > cleverer) than i'm expecting it to be? On Windows, you must turn on the --enable_shared option if you want to build extension modules. You could take the cygwin build as an example, see what's done in ./configure.in. -- Amaury Forgeot d'Arc ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
On Wed, Jan 21, 2009 at 9:13 PM, "Martin v. Löwis" wrote: >> ok, so - different from what's being generated by ./configure under >> msys under wine or native win32 - what's being generated (libpython 2 >> . 5 . a and libpython 2 . 5 . dll . a) is more akin to the cygwin >> environment. >> >> therefore, there's absolutely no doubt that the two are completely different. >> >> and on that basis, would i be correct in thinking that you _can't_ go >> linking or building modules or any python win32 code for one and have >> a hope in hell of using it on the other, and that you would _have_ to >> rebuild e.g. numpy for use with a mingw32-msys-built version of >> python? > > I can't comment on that, because I don't know what your port does. > Does it not produce a .dll containing the majority of Python? no, it contains the minimal necessary amount of python modules, exactly like when python is built using cygwin. actualy, there's a few modules that _have_ to be included. roumen discovered that you have to have these: _functools _functoolsmodule.c# Tools for working with functions and callable objects operator operator.c # operator.add() and similar goodies _locale _localemodule.c # -lintl _struct _struct.c _subprocess ../PC/_subprocess.c _winreg ../PC/_winreg.c and i've discovered that when running under wine you have to also have these: _weakref _weakref.c and also when running unde wine with msvcr80, so far, you have to also have these: collections collectionsmodule.c thread threadmodule.c all the rest can be done as .pyd > And is that not called python25.dll? no, it's called libpython2.5.dll.a, just like when python is built using cygwin. the configure scripts, thanks to the cygwin build, already end up copying that to libpython2.5.dll. _not_ python25.dll l. p.s. there's nothing to stop you adding every single module and then renaming the resultant blob to libpython25.dll - i just haven't been given, or found, a good reason to do so yet. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
On Thu, Jan 22, 2009 at 9:18 AM, Amaury Forgeot d'Arc wrote: >> or, is the .pyd loading a bit cleverer (or perhaps a bit less >> cleverer) than i'm expecting it to be? > > On Windows, you must turn on the --enable_shared option if you want to > build extension modules. > You could take the cygwin build as an example, see what's done in > ./configure.in. amaury, thank you for mentioning that - yes, as it turns out, all of the mingw ports (dan, roumen etc) do pretty much exactly this. also it turns out that on mingw, if you _don't_ disable shared (i.e. if you try to build a static library) mingw32 gcc runtime utils .16, .17 _and_ .19 all segfault or have runtime assertions when creating the archives!! either ar.exe or ranlib.exe choke themselves to death. which is greaaat. so, i've had to set the variable which specifies the libpython2.5.a static library to "" in order to stop it from being built. it would be helpful if there was a --enable-static=yes/no configure option, but there isn't one. leaving that aside, you understand therefore that dan, roumen and i have all managed to achieve building of .pyd extension modules. so, the question i am asking is: would it be reasonable to expect mingw-compiled .pyd modules to work with a proprietary-compiled msvc python.exe, and vice-versa? l. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3142: Add a "while" clause to generator expressions
Hi, Gerald Britton wrote: The sieve is just one example. The basic idea is that for some infinite generator (even a very simple one) you want to cut it off after some point. As for the number of characters, I spelled lambda incorrectly (left out a b) and there should be a space after the colon to conform to design guides. So, actually the takewhile version is two characters longer, not counting "import itertools" of course! the only usefull approach I could see is to enable slice syntax on generators which would make it possible to describe the exact or maximum lenght of results you want out of it. something like: >> g=(i for i in xrange(1000))[2:5] >> g.next() # wrapper would now step 2 times w/o yield and 1 with yield 2 >> g.next() 3 >> g.next() 4 >> g.next() Traceback (most recent call last): File "", line 1, in StopIteration as expected - this could be included into itertools for now. Regards Tino On Mon, Jan 19, 2009 at 11:44 AM, Daniel Stutzbach wrote: On Mon, Jan 19, 2009 at 10:37 AM, Gerald Britton wrote: prime = (p for p in sieve() while p < 1000) prime = takewhile(lamda p:p<1000, sieve()) I'm pretty sure the extra cost of evaluating the lambda at each step is tiny compared to the cost of the sieve, so I don't you can make a convincing argument on performance. Also, you know the latter is actually fewer characters, right? :-) -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/tino%40wildenhain.de smime.p7s Description: S/MIME Cryptographic Signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3142: Add a "while" clause to generator expressions
Tino Wildenhain wrote: >>> g=(i for i in xrange(1000))[2:5] >>> g.next() # wrapper would now step 2 times w/o yield and 1 with yield > 2 >>> g.next() > 3 >>> g.next() > 4 >>> g.next() > Traceback (most recent call last): > File "", line 1, in > StopIteration > > as expected - this could be included into itertools for now. Slicing of arbitrary iterators has been supported by itertools ever since the module was first added to the standard library. >>> from itertools import islice >>> g = islice((i for i in xrange(1000)), 2, 5) >>> list(g) [2, 3, 4] Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3142: Add a "while" clause to generator expressions
Nick Coghlan wrote: Tino Wildenhain wrote: g=(i for i in xrange(1000))[2:5] g.next() # wrapper would now step 2 times w/o yield and 1 with yield 2 g.next() 3 g.next() 4 g.next() Traceback (most recent call last): File "", line 1, in StopIteration as expected - this could be included into itertools for now. Slicing of arbitrary iterators has been supported by itertools ever since the module was first added to the standard library. from itertools import islice g = islice((i for i in xrange(1000)), 2, 5) list(g) [2, 3, 4] Yeah right, I actually believed it is already there but didn't bother to check ;-) Thx Tino smime.p7s Description: S/MIME Cryptographic Signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3142: Add a "while" clause to generator expressions
On 22 Jan 2009, at 12:42 , Nick Coghlan wrote: Tino Wildenhain wrote: g=(i for i in xrange(1000))[2:5] g.next() # wrapper would now step 2 times w/o yield and 1 with yield 2 g.next() 3 g.next() 4 g.next() Traceback (most recent call last): File "", line 1, in StopIteration as expected - this could be included into itertools for now. Slicing of arbitrary iterators has been supported by itertools ever since the module was first added to the standard library. islice is pretty annoying in some aspects, though. Mainly because it doesn't accept kwargs and defaults to requiring the stop argument. So drop(iterable, n) has to be written islice(iterable, n, None) (and of course the naming isn't ideal), and you can't really use functools.partial since the iterator is the first argument (unless there's a way to partially apply only the tail args without kwargs). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Single Sign-On for *.python.org
I do have some old patches for roundup that I was unable to test, because of blocking issues with openidenabled python-openid library and my Blogger server. See the top issue with the patch at openidenabled tracker: http://trac.openidenabled.com/trac/query?status=new&status=assigned&status=reopened&project=python-openid&order=priority Judging from complaints in development mailing list during the last three months I may conclude that the library isn't supported anymore. I do not know alternative OpenID implementation for Python, so the only way I see to continue development is to fork the lib. However, it is not really clear to me how to do this in case of Apache license. On Mon, Jan 19, 2009 at 8:36 AM, "Martin v. Löwis" wrote: >> I've also had fruitless discussions about adding OpenID authentication >> to Roundup. > > Did you offer patches to roundup during these discussions? > > Regards, > Martin > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/techtonik%40gmail.com > -- --anatoly t. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] About SCons Re: progress: compiling python2.5 under msys (specifically but not exclusively under wine) with msvcr80
On Thu, Jan 22, 2009 at 12:51 AM, Roumen Petrov 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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Questions/comments on documentation formatting
Brett Cannon schrieb: >>> 3. Are brackets for optional arguments (e.g. ``def fxn(a [, b=None [, >>> c=None]])``) really necessary when default argument values are >>> present? And do we really need to nest the brackets when it is obvious >>> that having on optional argument means the rest are optional as well? >> >> We've discussed that once on the doc-SIG, and I agreed that the bracketing >> is not really pretty, especially if it's heavily nested. Python functions >> where it makes sense should use the default-value syntax, while C functions >> without kwargs support need to keep the brackets. >> > > That was my thinking. > >> Making this consistent throughout the docs is no small task, of course. >> > > Nope, but perhaps all new docs should stop their use. OK. Perhaps we can sprint a bit on automatic replacement at PyCon. >>> 4. The var directive is not working even though the docs list it as a >>> valid directive; so is it still valid and something is broken, or the >>> docs need to be updated? >> >> (First, you're confusing "directive" and "role" which led to some confusion >> on Benjamin's part.) >> >> Where is a "var" role documented? If it is, it is a bug. > > http://docs.python.org/dev/3.0/documenting/markup.html#inline-markup. I assume you're referring to "Variable names are an exception, they should be marked simply with *var*."? Do you have suggestions how to improve clarity? Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Questions/comments on documentation formatting
On Thu, Jan 22, 2009 at 10:12, Georg Brandl wrote: > Brett Cannon schrieb: > 3. Are brackets for optional arguments (e.g. ``def fxn(a [, b=None [, c=None]])``) really necessary when default argument values are present? And do we really need to nest the brackets when it is obvious that having on optional argument means the rest are optional as well? >>> >>> We've discussed that once on the doc-SIG, and I agreed that the bracketing >>> is not really pretty, especially if it's heavily nested. Python functions >>> where it makes sense should use the default-value syntax, while C functions >>> without kwargs support need to keep the brackets. >>> >> >> That was my thinking. >> >>> Making this consistent throughout the docs is no small task, of course. >>> >> >> Nope, but perhaps all new docs should stop their use. > > OK. Perhaps we can sprint a bit on automatic replacement at PyCon. > That's a possibility. 4. The var directive is not working even though the docs list it as a valid directive; so is it still valid and something is broken, or the docs need to be updated? >>> >>> (First, you're confusing "directive" and "role" which led to some confusion >>> on Benjamin's part.) >>> >>> Where is a "var" role documented? If it is, it is a bug. >> >> http://docs.python.org/dev/3.0/documenting/markup.html#inline-markup. > > I assume you're referring to "Variable names are an exception, they should > be marked simply with *var*."? Do you have suggestions how to improve > clarity? > "... variables, including function/method arguments, ...". -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Questions/comments on documentation formatting
Brett Cannon schrieb: > 4. The var directive is not working even though the docs list it as a > valid directive; so is it still valid and something is broken, or the > docs need to be updated? (First, you're confusing "directive" and "role" which led to some confusion on Benjamin's part.) Where is a "var" role documented? If it is, it is a bug. >>> >>> http://docs.python.org/dev/3.0/documenting/markup.html#inline-markup. >> >> I assume you're referring to "Variable names are an exception, they should >> be marked simply with *var*."? Do you have suggestions how to improve >> clarity? >> > > "... variables, including function/method arguments, ...". Thanks, I've changed it a bit along these lines in r68859. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
>> I can't comment on that, because I don't know what your port does. >> Does it not produce a .dll containing the majority of Python? > > no, it contains the minimal necessary amount of python modules, > exactly like when python is built using cygwin. actualy, there's a > few modules that _have_ to be included. That's actually not my question. Do you have a DLL that contains all of Python/*.o and Objects/*.o? >> And is that not called python25.dll? > > no, it's called libpython2.5.dll.a, just like when python is built > using cygwin. the configure scripts, thanks to the cygwin build, > already end up copying that to libpython2.5.dll. > > _not_ python25.dll I'm giving up for now. I don't quite understand why the file gets first called libpython2.5.dll.a, and then renamed to libpython2.5.dll. Could it be perhaps that the .a file is an import library, and actually different from the .dll file? > p.s. there's nothing to stop you adding every single module and then > renaming the resultant blob to libpython25.dll - i just haven't been > given, or found, a good reason to do so yet. That doesn't really matter, I guess. An extension module build by your port will either fail to load into the regular Python (if libpython2.5.dll is not found), or load and then crash (because it uses a different copy of the Python runtime). Likewise vice versa. If this port ever takes off, we get another binary-incompatible Python version. I hope that users will understand that it is disjoint from the python.org version (as they seem to understand fine for the Cygwin build, which already picks up its extension modules also from a disjoint location, which helps to keep the two separate). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Single Sign-On for *.python.org
> I do not know alternative OpenID implementation for Python, so the > only way I see to continue development is to fork the lib. PyPI reports 15 packages when you search for OpenID. Not sure whether any of these are any good. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Unable to resolve svn.python.org: OS/X
The other day, Martin pointed out that my buildslave had gone off the reservation: on restarting it via the "buildbot start ~/buildarea" command - Martin noticed the slave had started throwing the DNS resolution error: closing stdin using PTY: True svn: PROPFIND request failed on '/projects/python/branches/py3k' svn: PROPFIND of '/projects/python/branches/py3k': Could not resolve hostname `svn.python.org': Temporary failure in name resolution (http://svn.python.org) program finished with exit code 1 Apparently, this has bothered a few buildbots. Some quick googling popped up the fix: http://buildbot.net/trac/wiki/UsingLaunchd After dropping the attached plist file in /Library/LaunchDaemons and setting the permissions right (and then chown -R'ing the existing buildarea for the buildbot user to buildbot:daemon) - running "sudo launchctl load org.python.buildbot.slave.plist" brought the buildbot back up in working order. Hopefully this helps out. -jesse org.python.buildbot.slave.plist Description: Binary data ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
On Thu, Jan 22, 2009 at 6:43 PM, "Martin v. Löwis" wrote: >>> I can't comment on that, because I don't know what your port does. >>> Does it not produce a .dll containing the majority of Python? >> >> no, it contains the minimal necessary amount of python modules, >> exactly like when python is built using cygwin. actualy, there's a >> few modules that _have_ to be included. > > That's actually not my question. ah right - sorry to not quite fully understand. > Do you have a DLL that contains > all of Python/*.o and Objects/*.o? yes. >>> And is that not called python25.dll? >> >> no, it's called libpython2.5.dll.a, just like when python is built >> using cygwin. the configure scripts, thanks to the cygwin build, >> already end up copying that to libpython2.5.dll. >> >> _not_ python25.dll > > I'm giving up for now. I don't quite understand why the file gets > first called libpython2.5.dll.a, and then renamed to libpython2.5.dll. > Could it be perhaps that the .a file is an import library, and actually > different from the .dll file? ... *thinks*... sorry, you're right. it's the way that dlltool is used on cygwin. dlltool on cygwin and gcc on cygwin create files with the following equivalence: python25.lib on msvc <---> libpython2.5.dll.a on cygwin and mingw32 python2.5.dll on msvc <--> libpython2.5.dll on cygwin and mingw32 >> p.s. there's nothing to stop you adding every single module and then >> renaming the resultant blob to libpython25.dll - i just haven't been >> given, or found, a good reason to do so yet. > > That doesn't really matter, I guess. An extension module build by your > port will either fail to load into the regular Python (if > libpython2.5.dll is not found), or load and then crash (because it uses > a different copy of the Python runtime). Likewise vice versa. > > If this port ever takes off, we get another binary-incompatible Python > version. there are at least three [mingw] already. > I hope that users will understand that it is disjoint from > the python.org version (as they seem to understand fine for the > Cygwin build, which already picks up its extension modules also from > a disjoint location, which helps to keep the two separate). there are already no less than _four_ mingw ports of python, of varying degrees. * http://jove.prohosting.com/iwave/ipython/pyMinGW.html * http://sebsauvage.net/python/mingw.html * http://python-mingw.donbennett.org/ * roumen's cross-compile+native port * the port i'm working on - extending roumen's native mingw compile one dates back to... python 2.2 i didn't include that one. another is python2.4. don's work is a cygwin cross-compile (note NOT a "compile of python for cygwin such that you need CYGWIN.DLL to run python"), so, using cygwin under win32 to cross-compile a native python.exe. smart, that. roumen then worked on that further, to make it compile under mingw / msys, not cygwin. and i'm working on taking windows _completely_ out of the loop, by getting python.exe to both compile _and_ run under wine, with the added benefit that if you _did_ happen to want to compile (or run) under either native windows or both, you can. l. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unable to resolve svn.python.org: OS/X
Jesse> The other day, Martin pointed out that my buildslave had gone off Jesse> the reservation: on restarting it via the "buildbot start Jesse> ~/buildarea" command - Martin noticed the slave had started Jesse> throwing the DNS resolution error: ... Thanks for this. This appears to be exactly what's gone wrong with the OS/X community buildbot I run. I'll try to plop your solution in place when I get home and see how it works after that. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
> version. I hope that users will understand that it is disjoint from > the python.org version (as they seem to understand fine for the > Cygwin build, which already picks up its extension modules also from > a disjoint location, which helps to keep the two separate). yes i made the default installation location (--prefix=) c:/python2.5 _not_ c:/python25 but obviously it _has_ been necessary to make the installation of modules into the exact same _style_ of location as the msvc build, because it has obviously also been necessary to use PC/getpathp.c not getpath.c so, .pyd modules will get installed in c:/python2.5/lib/site-packages/ and most importantly they'll get _looked_ for in there! for a while, they were being installed in c:/python2.5/lib/python2.5/site-packages which was a bit of a mess - that's the "unix" style of module locations. getpathp.c looks for "Lib/os.py" whilst getpath.c looks for "os.py" there's a whole _stack_ of knock-on effect little things like that. l. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
> there are already no less than _four_ mingw ports of python, of varying > degrees. > > * http://jove.prohosting.com/iwave/ipython/pyMinGW.html Ok, this one builds pythonXY, so it tries to be compatible with the official distribution (although it seems to link against MSVCRT.dll) > * http://sebsauvage.net/python/mingw.html That's *not* a port of Python to MingW. Instead, it is a set of instructions on how to build Python extension modules, using the official Python binaries, with mingw. I think this is obsolete now, as this now ships with Python itself. > * http://python-mingw.donbennett.org/ This doesn't seem to be distributing binaries. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
> That doesn't really matter, I guess. An extension module build by your > port will either fail to load into the regular Python (if > libpython2.5.dll is not found), or load and then crash (because it uses > a different copy of the Python runtime). Likewise vice versa. excellent, excellent that's _really_ good - and here's why: if it is _guaranteed_ to crash, regardless of what i do (because the copy of the python runtime is different), then it _doesn't_ matter what version of msvcrt i link the mingw-built python runtime with, does it? am i right? and if _that's_ the case, i can stop fricking about with msvcr80 :) which would be an absolute godsend because msvcr80 under wine is a frickin nightmare. the python regression tests pretty much hammer the daylights out of wine and it's squeaking in all sorts of weird places. adding in msvcr80, an undocumented transparent "blob" into the mix just makes getting this port fully operational all the more difficult. i'd like to avoid that :) l. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
On Thu, Jan 22, 2009 at 7:40 PM, "Martin v. Löwis" wrote: >> there are already no less than _four_ mingw ports of python, of varying >> degrees. >> >> * http://jove.prohosting.com/iwave/ipython/pyMinGW.html > > Ok, this one builds pythonXY, so it tries to be compatible with the > official distribution (although it seems to link against MSVCRT.dll) > >> * http://sebsauvage.net/python/mingw.html > > That's *not* a port of Python to MingW. Instead, it is a set of > instructions on how to build Python extension modules, using the > official Python binaries, with mingw. oh? ah, sorry, i didn't check . >> * http://python-mingw.donbennett.org/ > > This doesn't seem to be distributing binaries. sourceforge page. i checked the statistics, there don't seem to be very many hits (sorry to hear that don, if you're reading this!) ok. there _is_ a sourceforge page,... yep, downloads here: http://sourceforge.net/project/showfiles.php?group_id=182839 ok , so that makes... 3? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
> am i right? You should test that. I'm not sure whether it will crash (in particular, it might not on load), but it *might* crash, or fail in strange ways (e.g. when it checks whether something is a string, and decides it is not, because it is looking at the other PyString_Type) > and if _that's_ the case, i can stop fricking about with msvcr80 :) If so, I think there is little point in submitting patches to the Python bug tracker. I'm -1 on supporting two different-but-similar builds on Windows. I could accept a different build *process*, but the outcome must be the same either way. (of course, msvcr80 is irrelevant, because Python had never been using that officially) Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
>> This doesn't seem to be distributing binaries. > > sourceforge page. i checked the statistics, there don't seem to be > very many hits (sorry to hear that don, if you're reading this!) ok. > there _is_ a sourceforge page,... yep, downloads here: > > http://sourceforge.net/project/showfiles.php?group_id=182839 Where *exactly* do you get binaries there? All I can find is patches-2.5.1v2.gz Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [issue5029] Odd slicing behaviour
I cannot find that the documentation states "with negative step swap left with right". This is perhaps non-obvious. It is the words of the tutorial that caused issue 5029 author's confusion. 'a'[0::-1] != [] (is True, author expected False). The tutorial says: "One way to remember how slices work is to think of the indices as pointing between characters, with the left edge of the first character numbered 0. Then the right edge of the last character of a string of n characters has index n, for example:" ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
On Thu, Jan 22, 2009 at 8:17 PM, "Martin v. Löwis" wrote: >> am i right? > > You should test that. I'm not sure whether it will crash (in particular, > it might not on load), but it *might* crash, or fail in strange ways > (e.g. when it checks whether something is a string, and decides it is > not, because it is looking at the other PyString_Type) mrmmm... how? apps won't end up loading _both_ libpython2.5.dll _and_ python25.dll (or libpython2.N.dll and python2N.dll) will they? >> and if _that's_ the case, i can stop fricking about with msvcr80 :) > > If so, I think there is little point in submitting patches to the Python > bug tracker. I'm -1 on supporting two different-but-similar builds on > Windows. I could accept a different build *process*, but the outcome > must be the same either way. > > (of course, msvcr80 is irrelevant, because Python had never been using > that officially) oh? i saw the PCbuild8 and thought it was. oh that's even better - if python2.5 only officially support msvcrt whew. ok , i see - python2.6 uses msvcr90. i'll cross that bridge when i come to it. l. > Regards, > Martin > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
On Thu, Jan 22, 2009 at 8:22 PM, "Martin v. Löwis" wrote: >>> This doesn't seem to be distributing binaries. >> >> sourceforge page. i checked the statistics, there don't seem to be >> very many hits (sorry to hear that don, if you're reading this!) ok. >> there _is_ a sourceforge page,... yep, downloads here: >> >> http://sourceforge.net/project/showfiles.php?group_id=182839 > > Where *exactly* do you get binaries there? > > All I can find is patches-2.5.1v2.gz doh! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
> mrmmm... how? apps won't end up loading _both_ libpython2.5.dll _and_ > python25.dll (or libpython2.N.dll and python2N.dll) will they? Of course they will! python.exe (say, the official one) loads python25.dll. Then, an import is made of a ming-wine extension, say foo.pyd, which is linked with libpython2.5.dll, which then gets loaded. Voila, you have two interpreters in memory, with different type objects, memory heaps, and so on. This was always the problem when an old extension module (say, from 2.4) was loaded into a new interpreter (say, 2.5), then you load both python25.dll and python24.dll, causing crashes. To prevent this issue, Python now checks whether the module is linked with an incorrect pythonxy.dll, but won't catch that libpython2.5.dll is also a VM. >> (of course, msvcr80 is irrelevant, because Python had never been using >> that officially) > > oh? i saw the PCbuild8 and thought it was. oh that's even better - > if python2.5 only officially support msvcrt whew. No, Python 2.5 is linked with msvcr71.dll. PCbuild8 was never officially used. > ok , i see - python2.6 uses msvcr90. Correct. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Single Sign-On for *.python.org
On Thu, Jan 22, 2009 at 8:50 PM, "Martin v. Löwis" wrote: >> I do not know alternative OpenID implementation for Python, so the >> only way I see to continue development is to fork the lib. > > PyPI reports 15 packages when you search for OpenID. Not sure whether > any of these are any good. django-authopenid 0.9.6 7 Openid authentification application for Django - uses openidenabled http://code.google.com/p/django-authopenid/wiki/README plone.app.openid 1.17 Plone OpenID authentication support - the same openidenabled requirement http://pypi.python.org/pypi/plone.app.openid/1.1 plone.openid 1.27 OpenID authentication support for PAS - GPLd, openidenabled - http://svn.plone.org/svn/plone/plone.openid/trunk/setup.py python-openid 2.2.1 7 OpenID support for servers and consumers. - well, it is the openidenabled lib itself - http://openidenabled.com/python-openid/ silva.pas.openid 1.17 OpenID suport for Silva - openidenabled - https://svn.infrae.com/silva.pas.openid/trunk/setup.py TracOpenIDDelegate 1.0 7 Add OpenID delegation links to a Trac site. - merely delegates the auth to other site authopenid_middleware 0.1 6 OpenID authentication middleware for WSGI applications - yep, another openenabled wrapper TGOpenIDLogin 0.1 6 OpenID login controller for TurboGears - guess what? http://nxsy.org/code/tgopenidlogin/ TracAuthOpenId 0.1.96 OpenID plugin for Trac - the same middleware wrapper, openidenabled TestOpenID 0.2.25 A test consumer and server for Open ID. - demonstration of how to use the python-openid library, enabled gracie 0.2.83 Gracie - OpenID provider for local accounts - GPLed and enabled AuthKit 0.4.3 1 An authentication and authorization toolkit for WSGI applications and frameworks - you know the answer - http://authkit.org/trac/browser/AuthKit/trunk/setup.py plone.app.layout 1.1.7 1 Layout mechanisms for Plone - irrelevant Products.SilvaForum 0.3.1 1 Forum for Silva - irrelevant wsgiauth 0.1 - uses openidenabled No option. -- --anatoly t. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
On 23/01/2009 7:01 AM, Luke Kenneth Casson Leighton wrote: That doesn't really matter, I guess. An extension module build by your port will either fail to load into the regular Python (if libpython2.5.dll is not found), or load and then crash (because it uses a different copy of the Python runtime). Likewise vice versa. excellent, excellent that's _really_ good - and here's why: if it is _guaranteed_ to crash, regardless of what i do (because the copy of the python runtime is different), then it _doesn't_ matter what version of msvcrt i link the mingw-built python runtime with, does it? I'm very confused about this: It seems you started this work precisely so you can be compatible between MSVC built Python's and mingw builds - ie, this thread starts with you saying: > this is a fairly important issue for python development > interoperability - but now you seem to be saying it is actually a *feature* if they don't work together? > and if _that's_ the case, i can stop fricking about with msvcr80 :) If all you are doing is trying to get a version of Python working under Wine that isn't compatible with MSVC built binaries, I can't work out why you are fricking around with msvcr80 either! Cheers, Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] progress: compiling python2.5 under msys (specifically but not exclusively under wine) with msvcr80
Cesare Di Mauro wrote: Have you made some benchmarks like pystone? There is result from pystone test test run an old PC (NT 5.1): - 2.6(official build): 42194,6; 42302,4; 41990,8; 42658,0; 42660,6; 42770,1 average=42429,4 deviation=311,6 - 2.6.1(official build): 35612,1; 35778,8; 35666,7; 35697,9; 35514,9; 35654,0 average=35654,1 deviation=88,1 - trunk(my mingw based build): 35256,7; 35272,5; 35247,2; 35270,7; 35225,6; 35233,5 average=35251,0 deviation=19,2 There is problem with python performance between 2.6 and 2.6.1 ~ 19% :(. Also the test for GCC-mingw is not with same source base. Roumen ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
Luke Kenneth Casson Leighton wrote: On Wed, Jan 21, 2009 at 9:13 PM, "Martin v. Löwis" wrote: ok, so - different from what's being generated by ./configure under msys under wine or native win32 - what's being generated (libpython 2 . 5 . a and libpython 2 . 5 . dll . a) is more akin to the cygwin environment. therefore, there's absolutely no doubt that the two are completely different. and on that basis, would i be correct in thinking that you _can't_ go linking or building modules or any python win32 code for one and have a hope in hell of using it on the other, and that you would _have_ to rebuild e.g. numpy for use with a mingw32-msys-built version of python? I can't comment on that, because I don't know what your port does. Does it not produce a .dll containing the majority of Python? no, it contains the minimal necessary amount of python modules, exactly like when python is built using cygwin. actualy, there's a few modules that _have_ to be included. roumen discovered that you have to have these: _functools _functoolsmodule.c# Tools for working with functions and callable objects operator operator.c # operator.add() and similar goodies _locale _localemodule.c # -lintl _struct _struct.c _subprocess ../PC/_subprocess.c _winreg ../PC/_winreg.c Yes and this is issue in native build - setup.py fail to load :(. In cross-build where I use python from build system I could produce those as modules. and i've discovered that when running under wine you have to also have these: _weakref _weakref.c and also when running unde wine with msvcr80, so far, you have to also have these: collections collectionsmodule.c thread threadmodule.c all the rest can be done as .pyd [SNIP] Actually I didn't spend time to find why MSVC build include so many modules as build-ins. Roumen ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
Luke Kenneth Casson Leighton wrote: version. I hope that users will understand that it is disjoint from the python.org version (as they seem to understand fine for the Cygwin build, which already picks up its extension modules also from a disjoint location, which helps to keep the two separate). yes i made the default installation location (--prefix=) c:/python2.5 _not_ c:/python25 but obviously it _has_ been necessary to make the installation of modules into the exact same _style_ of location as the msvc build, because it has obviously also been necessary to use PC/getpathp.c not getpath.c I'm thinking about possibility to avoid compatible paths, i.e. to drop windows specific PC/getpathp.c and to return back to posix getpath.c. The problem is that MSVC based build is not installed in tree compatible to the posix build. Now I think that GCC(mingw) build has to use same tree as other posix builds. Mixing posix build and install (makefile) with paths used by from MSVC build require additional changes either in makefile or in PC/getpathp.c. In the both case change is more the 100 lines and now I prefer mingw to use posix tree. This open another issue. Тhe posix build install in fixed location. I think that with a small change in distutils (no more then 10-20 lines) we may overcome this. so, .pyd modules will get installed in c:/python2.5/lib/site-packages/ and most importantly they'll get _looked_ for in there! for a while, they were being installed in c:/python2.5/lib/python2.5/site-packages which was a bit of a mess - that's the "unix" style of module locations. getpathp.c looks for "Lib/os.py" whilst getpath.c looks for "os.py" there's a whole _stack_ of knock-on effect little things like that. :) The installation is the last issue. Roumen ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __del__ and tp_dealloc in the IO lib
On Mon, 19 Jan 2009 01:38:18 +, Gregory P. Smith wrote: > I regularly point out in code reviews that the very convenient and > common idiom of open(name, 'w').write(data) doesn't guarantee when the > file will be closed; its up to the GC implementation details. Which, to me, sounds like "please, don't assume that bytes are 8-bits wide; this depends on implementation details of your CPU". CPython will always use reference counting and thus have a simple and clear GC criteria that can be exploited to simplify the code. I personally don't like defensive programming, nor coding for situations that will never arise . When I write CPython applications (thus, for instance, using C extensions), I don't see *any* point in trying to achieve any cross-python-implementation compatibility. I simply don't need it. Probably, library programmers have a different point of view. But I always object when I'm told that I should make my code longer and harder to read only because CPython might stop using reference counting (... when hell freezes over). Back to the topic, please let's keep things as they are now: the file descriptor is automatically closed as soon as the file object is destroyed. If you then feel "safer" always using with or try/finally, nobody is going to complain. And everybody will be happy :) -- Giovanni Bajo Develer S.r.l. http://www.develer.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __del__ and tp_dealloc in the IO lib
On Thu, Jan 22, 2009 at 5:22 PM, Giovanni Bajo wrote: > On Mon, 19 Jan 2009 01:38:18 +, Gregory P. Smith wrote: > >> I regularly point out in code reviews that the very convenient and >> common idiom of open(name, 'w').write(data) doesn't guarantee when the >> file will be closed; its up to the GC implementation details. > > Which, to me, sounds like "please, don't assume that bytes are 8-bits > wide; this depends on implementation details of your CPU". I think it's a lot more like "please, don't assume that there's a Global Interpreter Lock" -- something that the implementation shouldn't change without good reason and sufficient warning, but which isn't actually part of the language specification. And of course, such advice always carries more weight for code that's intended to be reusable than it does for code that has little chance of escaping the application it's in. -- Curt Hagenlocher [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __del__ and tp_dealloc in the IO lib
Giovanni Bajo wrote: > On Mon, 19 Jan 2009 01:38:18 +, Gregory P. Smith wrote: > >> I regularly point out in code reviews that the very convenient and >> common idiom of open(name, 'w').write(data) doesn't guarantee when the >> file will be closed; its up to the GC implementation details. > > Which, to me, sounds like "please, don't assume that bytes are 8-bits > wide; this depends on implementation details of your CPU". > Which it does, assuming you are using (for example) an ancient DECSystem-10. But you really can't assume in your writings about Python that all readers will be using CPython, so it seems like a reasonable point to make. > CPython will always use reference counting and thus have a simple and > clear GC criteria that can be exploited to simplify the code. I > personally don't like defensive programming, nor coding for situations > that will never arise . When I write CPython applications (thus, for > instance, using C extensions), I don't see *any* point in trying to > achieve any cross-python-implementation compatibility. I simply don't > need it. > Who gave you this guarantee of CPython's future behavior? Who knows which implementation of Python will be used to support your code and mine in five years? > Probably, library programmers have a different point of view. As they properly should. > But I > always object when I'm told that I should make my code longer and harder > to read only because CPython might stop using reference counting (... > when hell freezes over). > Ah, religious beliefs ... ;-) > Back to the topic, please let's keep things as they are now: the file > descriptor is automatically closed as soon as the file object is > destroyed. If you then feel "safer" always using with or try/finally, > nobody is going to complain. And everybody will be happy :) And what are the IronPython team, and the Jython team, supposed to do when they get around to implementing Python 3? Clearly (since both teams are already committed to implementing it) the more we can do to accommodate them the better it will be for cross-implementation compatibility. Or did I miss something? You are, of course, free to make whatever assumptions you like about the environment in which your code executes. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __del__ and tp_dealloc in the IO lib
On Thu, Jan 22, 2009 at 5:22 PM, Giovanni Bajo wrote: > CPython will always use reference counting and thus have a simple and > clear GC criteria that can be exploited to simplify the code. Believe this at your own peril. Once, CPython didn't have GC at all (apart from refcounting). Now it does. There are GC techniques that delay DECREF operations until it's more convenient. If someone finds a way to exploit that technique to save 10% of execution time it would only be right to start using it. You *can* assume that objects that are no longer referenced will *eventually* be GC'ed, and that GC'ing a file means flushing its buffer and closing its file descriptor. You *cannot* assume that objects are *immediately* GC'ed. This is already not always true in CPython for many different reasons, like objects involved in cycles, weak references, or tracebacks saved with exceptions, or perhaps profiling/debugging hooks. If we found a good reason to introduce file objects into some kind of cycle or weak reference dict, I could see file objects getting delayed reclamation even without changes in GC implementation. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Should ftplib use UTF-8 instead of latin-1 encoding?
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 374 (DVCS) now in reST
I have now converted PEP 374 (http://www.python.org/dev/peps/pep-0374/) from Google Docs to reST and checked it in. I am not going to paste it into an email as it is nearly 1500 lines in reST form. Because there are four authors handling corrections it is a little different than normal on who you contact to suggest changes. For each specific VCS there is a primary author as listed in the PEP in the intro to the Scenarios section. Email the proper author if you find an issue with a specific VCS. Otherwise email me for general PEP issues. Core developers can make changes on their own while taking into account they should let the author in charge of the PEP know if they make a big change. Since I will be the author making the final recommendation I am documenting my thought processes on my decision making for this whole thing as I go along in the PEP so as to be as transparent as possible. I am not even close to being done, so please don't email me about the section. And I would like to thank my co-authors for their time and effort thus far in filling in the PEP on behalf of their favorite DVCS. Everyone has put in a lot of time already with I am sure more time in the future. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
On Thu, Jan 22, 2009 at 9:09 PM, "Martin v. Löwis" wrote: >> mrmmm... how? apps won't end up loading _both_ libpython2.5.dll _and_ >> python25.dll (or libpython2.N.dll and python2N.dll) will they? > > Of course they will! yeah, silly - i worked that out juust after i pressed "send". > python.exe (say, the official one) loads > python25.dll. Then, an import is made of a ming-wine extension, say > foo.pyd, which is linked with libpython2.5.dll, which then gets loaded. > Voila, you have two interpreters in memory, with different type objects, > memory heaps, and so on. ok, there's a solution for that - the gist of the solution is already implemented in things like Apache Runtime and Apache2 (modules), and is an extremely common standard technique implemented in OS kernels. the "old school" name for it is "vector tables". so you never let the .pyd (or so even) modules "link" to the libpythonN.N.dll, pythonNN.dll (or libpythonN.N.so even), you _pass in_ a pointer to everything it's ever going to need (in its init) function. > This was always the problem when an old extension module (say, from 2.4) > was loaded into a new interpreter (say, 2.5), then you load both > python25.dll and python24.dll, causing crashes. To prevent this issue, > Python now checks whether the module is linked with an incorrect > pythonxy.dll, but won't catch that libpython2.5.dll is also a VM. ok. i'll look at making libpython2.5.dll equal to python25.dll. >>> (of course, msvcr80 is irrelevant, because Python had never been using >>> that officially) >> >> oh? i saw the PCbuild8 and thought it was. oh that's even better - >> if python2.5 only officially support msvcrt whew. > > No, Python 2.5 is linked with msvcr71.dll. ehn? i don't see that anywhere in any PC/* files - i do see that there's a dependency on .NET SDK 1.1 which uses msvcr71.dll still, 71 is good news - as long as it's not involving assemblies. 2.6 is a different matter, but, thinking about it, i have hopes that the better-tested-codepath of the 2.6 codebase would have better luck with 9.0 [than i had with 2.5 and 8.0] simply because... it's been tested already! [and 2.5 with 8.0 hadn't] l. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
On Fri, Jan 23, 2009 at 6:36 AM, Luke Kenneth Casson Leighton wrote: > On Thu, Jan 22, 2009 at 9:09 PM, "Martin v. Löwis" wrote: >>> mrmmm... how? apps won't end up loading _both_ libpython2.5.dll _and_ >>> python25.dll (or libpython2.N.dll and python2N.dll) will they? >> >> Of course they will! > > yeah, silly - i worked that out juust after i pressed "send". ironically, i started out with the intent of going for python2N.dll interoperability. then i noticed that all the other mingw ports dropped the total-inclusion-of-all-modules because you _can_. i should have stuck with my original plan :) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
On Thu, Jan 22, 2009 at 10:16 PM, Mark Hammond wrote: > On 23/01/2009 7:01 AM, Luke Kenneth Casson Leighton wrote: >>> >>> That doesn't really matter, I guess. An extension module build by your >>> port will either fail to load into the regular Python (if >>> libpython2.5.dll is not found), or load and then crash (because it uses >>> a different copy of the Python runtime). Likewise vice versa. >> >> >> excellent, excellent that's _really_ good - and here's why: >> >> if it is _guaranteed_ to crash, regardless of what i do (because the >> copy of the python runtime is different), then it _doesn't_ matter >> what version of msvcrt i link the mingw-built python runtime with, >> does it? > > I'm very confused about this: It seems you started this work precisely so > you can be compatible between MSVC built Python's and mingw builds yeah that's where i _started_ - and after being on this for what nearly eight days straight i was hoping to get away with as little extra work as possible. > - ie, > this thread starts with you saying: > >> this is a fairly important issue for python development >> interoperability > > - but now you seem to be saying it is actually a *feature* if they don't > work together? *sigh* no, that was me getting confused >> and if _that's_ the case, i can stop fricking about with msvcr80 :) > > If all you are doing is trying to get a version of Python working under Wine > that isn't compatible with MSVC built binaries, I can't work out why you are > fricking around with msvcr80 either! ha ha :) existence of PCbuild8 is the main reason :) that and getting the wrong end of the stick. i'll get there eventually. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Should ftplib use UTF-8 instead of latin-1 encoding?
Giampaolo Rodola' wrote: 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. I read it the same way. The whole point of the RFC is that UTF-8 rather than the very limited latin-1 is needed for true internationalization. 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
