Re: [Python-Dev] ctypes compatibility with 2.3
Am 11.05.2016 um 18:04 schrieb Brett Cannon: On Wed, 11 May 2016 at 04:35 Thomas Heller <thel...@ctypes.org <mailto:thel...@ctypes.org>> wrote: Am 10.05.2016 um 19:39 schrieb Brett Cannon: > > > On Tue, 10 May 2016 at 01:18 Martin Panter <vadmium...@gmail.com <mailto:vadmium%2...@gmail.com> > <mailto:vadmium%2...@gmail.com <mailto:vadmium%252...@gmail.com>>> wrote: > > I am working on <https://bugs.python.org/issue22636>, to fix shell > injection problems with ctypes.util.find_library(). The proposal for > Python 3 is to change os.popen(shell-script) calls to use > subprocess.Popen(). > > However the Python 2.7 version of the module has a comment which says > “This file should be kept compatible with Python 2.3, see PEP 291.” > Looking at <https://www.python.org/dev/peps/pep-0291/>, it is not > clear why we have to maintain this compatibility. My best guess is > that there may be an external ctypes package that people want(ed) to > keep compatible with 2.3, and also keep synchronized with 2.7. > > > That's correct and the maintainer is/was Thomas Heller who I have cc'ed > to see if he's okay with lifting the restriction. For me it is totally ok to lift this restriction. Great! I'll also update PEP 291. Cool. While you're at it, the compatibility restriction for modulefinder could also be lifted. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ctypes compatibility with 2.3
Am 10.05.2016 um 19:39 schrieb Brett Cannon: On Tue, 10 May 2016 at 01:18 Martin Panter <vadmium...@gmail.com <mailto:vadmium%2...@gmail.com>> wrote: I am working on <https://bugs.python.org/issue22636>, to fix shell injection problems with ctypes.util.find_library(). The proposal for Python 3 is to change os.popen(shell-script) calls to use subprocess.Popen(). However the Python 2.7 version of the module has a comment which says “This file should be kept compatible with Python 2.3, see PEP 291.” Looking at <https://www.python.org/dev/peps/pep-0291/>, it is not clear why we have to maintain this compatibility. My best guess is that there may be an external ctypes package that people want(ed) to keep compatible with 2.3, and also keep synchronized with 2.7. That's correct and the maintainer is/was Thomas Heller who I have cc'ed to see if he's okay with lifting the restriction. For me it is totally ok to lift this restriction. Thomas ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows
Am 10.02.2015 um 18:45 schrieb Steve Dower: As we've seen from earlier discussions, the main beneficiaries of having Python on PATH are those using the command-line. Most scripts are going to make assumptions or work unnecessarily hard to find the actual location of the Python version they need. Maybe I'm more or less alone with the way I work, but I don't like python.exe on my PATH (and py.exe alloes me to do this). I start python scripts from the command line either with 'script.py' or 'py -3.4 script.py' or 'py -2.7 script.py'. I even like running scripts in this way: 'py -2.7 -m pip install whatever'. However, this only works when the script also can be started as package. Some packages allow this, some don't. Could not py.exe be extended so that it allows starting scripts in a somewhat similar way? 'py-script -2.7 myscript foo bar baz' ??? Which would execute the script myscript.exe, myscript.bat, myscript.py, myscript.cmd or whatever is in the Scripts directory on the Python 2.7 installation, without changing PATH presistently? Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows
Am 12.02.2015 um 18:39 schrieb Ethan Furman: On 02/12/2015 12:05 AM, Thomas Heller wrote: Could not py.exe be extended so that it allows starting scripts in a somewhat similar way? 'py-script -2.7 myscript foo bar baz' ??? Which would execute the script myscript.exe, myscript.bat, myscript.py, myscript.cmd or whatever is in the Scripts directory on the Python 2.7 installation, without changing PATH presistently? I'm pretty sure py.exe should only start .py files, not .bat, .cmd, or .anything-else. To make it clear: My suggestion is (or was, maybe it isn't a good idea) to have some way to start 'something' that is in the Scripts directory of a Python installation (which is usually a python script or an exe-wrapper for it), without typing in the full path. And without changing the PATH envrionment variable. Thomas ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 370 - per-user scripts directory on Windows
Am 12.02.2015 um 15:46 schrieb Paul Moore: On 12 February 2015 at 08:05, Thomas Heller thel...@ctypes.org wrote: Maybe I'm more or less alone with the way I work, but I don't like python.exe on my PATH (and py.exe alloes me to do this). I start python scripts from the command line either with 'script.py' or 'py -3.4 script.py' or 'py -2.7 script.py'. This is how I worked for a long time after py.exe became available. But then I discovered virtualenv, and started using that, and needing to use 2 completely different command sets for when I'm in a virtualenv vs when I'm not became completely unusable. I'm normally not using virtual environments, so my understanding might be wrong. Isn't it the case that in virtual envs you don't have these problems at all? The 'correct' python.exe is on the PATH as well as the Scripts directory: this is what activate.bat does. Thomas ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python 3.4 and pywin32
Am 22.03.2014 00:25, schrieb Nick Coghlan: On 22 March 2014 05:46, Thomas Heller thel...@ctypes.org wrote: With python 3.4 and pywin32 version 218 it is only possible to import win32com or win32api when pywintypes has been imported before. I have no idea if this is a bug in pywin32 or in Python 3.4. Does anyone know more? Do you have a traceback for the failed imports? There were certainly non-trivial changes to the import system in 3.4, but without knowing more details about the failures, it's hard to say what the culprits might be. I have created http://bugs.python.org/issue21050. Thomas ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] python 3.4 and pywin32
With python 3.4 and pywin32 version 218 it is only possible to import win32com or win32api when pywintypes has been imported before. I have no idea if this is a bug in pywin32 or in Python 3.4. Does anyone know more? Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 384 (stable api) question
Am 07.11.2013 19:35, schrieb Martin v. Löwis: Am 07.11.13 13:44, schrieb Thomas Heller: I thought that the stable API would keep exactly the same across releases - is this expectation wrong or is this a bug? Oscar is right - this change doesn't affect the ABI, just the API. That said, please file an issue reporting what change you see in your compiler warnings. 3.4 is not released yet, perhaps there is something that can be done. http://bugs.python.org/issue19538 Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #19512: Add a new _PyDict_DelItemId() function, similar to
Am 08.11.2013 12:19, schrieb Victor Stinner: 2013/11/8 Nick Coghlan ncogh...@gmail.com: In Python 3.3, _PyDict_GetItemIdWithError(), _PyDict_GetItemId() and _PyDict_SetItemId() are part of the stable ABI if I read correctly dictobject.h. _PyObject_GetAttrId() is also part of the stable ABI. Was it a mistake, or did I misunderstand how stable functions are declared? Likely a mistake - the stable ABI is hard to review properly (since it can depend on non local preprocessor checks, so a mistake may not be obvious in a diff), we don't currently have a systematic approach to handling changes and there's no automated test to catch inadvertent additions or (worse) removals :( Would it be possible to remove them from the stable ABI in Python 3.4? They are marked as private using the _Py prefix... I may be confusing API and ABI (see my other message), but adding to or removing functions from the stable ABI seems to be a very serious mistake, IMO - private or not. Unless my understanding of the word 'stable' is wrong... This may be a good thing for us to look at more generally when things settle down a bit after the beta 1 feature freeze. I created the following issue to not forget it: http://bugs.python.org/issue19526 Thomas ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #19512: Add a new _PyDict_DelItemId() function, similar to
Am 08.11.2013 13:03, schrieb Thomas Heller: I may be confusing API and ABI (see my other message), but adding to or removing functions from the stable ABI seems to be a very serious mistake, IMO - private or not. Unless my understanding of the word 'stable' is wrong... Ok - my mistake. The PEP allows functions to be added (but not to be removed). From PEP 384: During evolution of Python, new ABI functions will be added. Applications using them will then have a requirement on a minimum version of Python; this PEP provides no mechanism for such applications to fall back when the Python library is too old. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 384 (stable api) question
PEP 384 describes the stable Python api, available when Py_LIMITED_API is defined. However, there are some (small) changes in the function prototypes available, one example is (in Python 3.3): PyObject* PyObject_CallFunction(PyObject *callable, char *format, ...) which changed in Python 3.4 to 'const char *format' for the third argument. I know that this is only a subtle difference, but in my case it gives compiler warnings when I compile my stuff (my stuff is a little bit special, I have to admit, but anyway). I thought that the stable API would keep exactly the same across releases - is this expectation wrong or is this a bug? Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] libffi inclusion in python
libffi has bugs sometimes (like this http://bugs.python.org/issue17580). Now this is a thing that upstream fixes really quickly, but tracking down issues on bugs.python.org is annoying (they never get commited as quickly as the upstream). is there a good reason why cpython has it's own copy of libffi? I understand historical reasons, but PyPy gets along relying on the system library, so maybe we can kill the inclusion. IIRC, it had (has?) some custom windows patches, which no one knows whether they're relevant or not. The only windows patch that is most certainly not in upstream is the ability to check and correct the stack pointer after a windows function call depending on the calling convention (stdcall or cdecl). Since this is windows 32-bit only (on windows 64-bit these calling conventions are aliases for the same thing), it would probably be good to remove the distinction between them for function calls. Upstream seems to be incredibly responsive. Why not merge them there? At the time when ctypes was implemented, this was different. They didn't even do libffi releases, IIRC. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Safely importing zip files with C extensions
Am 29.03.2013 02:06, schrieb Gregory P. Smith: On Thu, Mar 28, 2013 at 9:09 AM, Brett Cannon br...@python.org mailto:br...@python.org wrote: On Thu, Mar 28, 2013 at 10:44 AM, Thomas Heller thel...@ctypes.org mailto:thel...@ctypes.org wrote: The zip-file itself could support importing compiled extensions when it contains a python-wrapper module that unpacks the .so/.dll file somewhere, and finally calls imp.load_dynamic() to import it and replace itself. Which must be done carefully to prevent a security issue. It shouldn't be unzipped anywhere but into a directory only writable by the process. Once http://sourceware.org/bugzilla/show_bug.cgi?id=11767 is implemented and available in libc, no extraction of .so's should be needed (they will likely need to be stored uncompressed in the .zip file for that though). For windows there is already code that does it: http://www.py2exe.org/index.cgi/Hacks/ZipExtImporter This page is not up-to-date, but it describes the idea and the implementation. The code currently is 32-bit only and for Python 2 but that probably can be fixed. It is based on Joachim Bauch's MemoryModule: https://github.com/fancycode/MemoryModule Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Safely importing zip files with C extensions
Am 27.03.2013 20:38, schrieb Vinay Sajip: This quote is here to stop GMane complaining that I'm top-posting. Ignore. I've already posted this to distutils-sig, but thought that it might be of interest to readers here as it relates to importing C extensions ... zipimport is great, but there can be issues importing software that contains C extensions. But the new wheel format (PEP 427) may give us a better way of importing zip files containing C extensions. Since wheels are .zip files, they can sometimes be used to provide functionality without needing to be installed. But whereas .zip files contain no convention for indicating compatibility with a particular Python, wheels do contain this compatibility information. Thus, it is possible to check if a wheel can be directly imported from, and the wheel support in distlib allows you to take advantage of this using the mount() and unmount() methods. When you mount a wheel, its absolute path name is added to sys.path, allowing the Python code in it to be imported. (A DistlibException is raised if the wheel isn't compatible with the Python which calls the mount() method.) The zip-file itself could support importing compiled extensions when it contains a python-wrapper module that unpacks the .so/.dll file somewhere, and finally calls imp.load_dynamic() to import it and replace itself. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [docs] undocumented argtypes magic in ctypes?
Am 06.03.2013 18:19, schrieb Eli Bendersky: On Wed, Mar 6, 2013 at 8:33 AM, Andrew Svetlov andrew.svet...@gmail.com mailto:andrew.svet...@gmail.com wrote: Looks like bug for me. ctypes seems to auto-convert arguments when argtypes is specified. This fact is documented. However, I'm not sure whether this auto-conversion is advanced enough to apply byref. Because otherwise, DIRENT is certainly not convertible to DIRENT_p If argtypes specify a 'POINTER(X)' type as an argument, then ctypes automatically applies byref() if an 'X' instance is passed to the actual call. This is by design, but I'm not sure if it is documented or not. However, if argtypes is not given, this does (and of course cannot) work. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [docs] undocumented argtypes magic in ctypes?
ctypes seems to auto-convert arguments when argtypes is specified. This fact is documented. However, I'm not sure whether this auto-conversion is advanced enough to apply byref. Because otherwise, DIRENT is certainly not convertible to DIRENT_p If argtypes specify a 'POINTER(X)' type as an argument, then ctypes automatically applies byref() if an 'X' instance is passed to the actual call. This is by design, but I'm not sure if it is documented or not. However, if argtypes is not given, this does (and of course cannot) work. Great, thanks for confirming this, Thomas. I had the feeling it's a documentation issue (hence I sent it to the docs@ list first), because the behavior seems very deliberate and looking at the code of ctypes I did see conversions going on. Have I missed that this is documented somewhere, or should I open a docs issue? I didn't find anything in the docs (in the two minutes I spent for that), so please open a docs issue, or, better, fix it. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] importlib hooray!
I have become a fan of the new python 3.3 importlib in the last few days. It has allowed me to write a ModuleMapper which I put into sys.metapath (in sitecustomize.py, for Python 3.3). This mapper currently does rename modules like 'Queue' or '_winreg' to the Python3 modules 'queue' or 'winreg' without the need to change my 2.7 sourcecode (changing the sourcecode is required when using six.moves to write 2.x/3.x compatible code). The six.moves approach has another problem with freeze tools (py2exe for example): ModuleFinder does not find the moved modules because it cannot track __import__(). I have also started a new modulefinder which uses importlib to find modules; this was quite easy since I could copy a lot of code from importlib._bootstrap. The great thing is that this new modulefinder is much better than the old one: It finds modules in zipped eggs or other zip-archives which are on sys.path; also it finds the renamed modules correctly that my ModuleMapper has mapped. The only thing that I am missing is that it is a bit of guesswork to find out the type of the module that importlib.find_loader() has found. Previously imp.find_module returned a tuple containing the type of module found (like imp.PY_SOURCE), I have to poke around in some attributes of the result of importlib.find_loader() to guess the type. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] importlib.find_loader
In Python3.3, I thought that every loaded module has a __loader__ attribute. Apparently this is not the case for a few builtin modules: Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:57:17) [MSC v.1600 64 bit (AMD64)] on win32 Type help, copyright, credits or license for more information. import importlib def bug(): ... for name in list(sys.modules.keys()): ... try: ... importlib.find_loader(name) ... except Exception as details: ... print(name, type(details), details) ... bug() _frozen_importlib class 'AttributeError' 'module' object has no attribute '__loader__' builtins class 'AttributeError' 'module' object has no attribute '__loader__' signal class 'AttributeError' 'module' object has no attribute '__loader__' importlib._bootstrap class 'AttributeError' 'module' object has no attribute '__loader__' However, the importlib docs talk about a ValueError instead of the AttributeError that I see above: Find the loader for a module, optionally within the specified path. If the module is in sys.modules, then sys.modules[name].__loader__ is returned (unless the loader would be None, in which case ValueError is raised). Is this a bug? Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] importlib.find_loader
Am 01.02.2013 01:42, schrieb Nick Coghlan: Yep, looks like a bug in the bootstrapping, failing to set __loader__ properly. It also has the effect that reload does not work: Type help, copyright, credits or license for more information. import imp import math imp.reload(math) module 'math' (built-in) import signal imp.reload(signal) Traceback (most recent call last): File stdin, line 1, in module File C:\Python33-64\lib\imp.py, line 252, in reload return module.__loader__.load_module(name) AttributeError: 'module' object has no attribute '__loader__' However, I also think the current handling of the no __loader__ attribute case is a separate bug - since we generally aim to tolerate non-modules in sys.modules (albeit somewhat grudgingly), importlib should probably be using getattr(mod, '__loader__', None) rather than assuming the attribute will always be present. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 2.7 releases
Will there be more 2.7 bugfix releases, and when the next one? In other words; if I submit a patch and it is accepted, can I expect that patch be committed also to the 2.7 branch? Thanks, Thomas Been a long time that I've been here - but still using Python (2.7 now) more and more... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.7 releases
Am 26.07.2012 20:16, schrieb mar...@v.loewis.de: Will there be more 2.7 bugfix releases Yes. and when the next one? That's up for Benjamin to decide. My view is that one bugfix release every year is more than enough. Ok. I expect we will still be using 2.7 next year in my company. In other words; if I submit a patch and it is accepted, can I expect that patch be committed also to the 2.7 branch? Don't you have commit rights still? I dont't know. IIRC, I have asked for them to be retracted some years ago. Anyway, I do know nearly nothing about hg and don't have time to learn it. So, I have uploaded a patch and asked for review (since I'm not 1000% sure that it is absolutely correct): http://bugs.python.org/issue15459 Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Please retract my committer rights
I would like my committer rights to be retracted. I have been contributing to Python here and there for 10 years now, and it was a pleasant experience. Unfortunately, since about a year I have lots more things to do, and I won't be able to contribute anymore (I have not even started to learn mercurial yet). Plus I'm still using 2.6 or even 2.5 with my own Python projects. Goodbye. Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org 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 3188: Implementation Questions
Meador Inge schrieb: On Fri, Feb 26, 2010 at 4:08 PM, Greg Ewing greg.ew...@canterbury.ac.nzwrote: Meador Inge wrote: 3. Using Decimal keeps the desired precision, Well, sort of, but then you end up doing arithmetic in decimal instead of binary, which could give different results. Even with the user-defined precision capabilities of the 'Decimal' class? In other words, can I create an instance of a 'Decimal' that behaves (in all operations: arithmetic, comparison, etc...) exactly as the extended double precision type offered by a given machine? Maybe the solution is to give ctypes long double objects the ability to do arithmetic? Maybe, but then we would have to give all numeric 'ctypes' the ability to do arithmetic -- which may be more than we want. See issue 887237: http://bugs.python.org/issue887237 -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org 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 3188: Implementation Questions
Meador Inge schrieb: Hi All, Recently some discussion began in the issue 3132 thread ( http://bugs.python.org/issue3132) regarding implementation of the new struct string syntax for PEP 3118. Mark Dickinson suggested that I bring the discussion on over to Python Dev. Below is a summary of the questions\comments from the thread. Unpacking a long-double === 1. Should this return a Decimal object or a ctypes 'long double'? 2. Using ctypes 'long double' is easier to implement, but precision is lost when needing to do arithmetic, since the value for cytpes 'long double' is converted to a Python float. 3. Using Decimal keeps the desired precision, but the implementation would be non-trivial and architecture specific (unless we just picked a fixed number of bytes regardless of the architecture). 4. What representation should be used for standard size and alignment? IEEE 754 extended double precision? A variant of 2. would be to unpack into a ctypes 'long double', and extend the ctypes 'long double' type to retrive the value as Decimal instance, in addition to the default conversion into a Python float. -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] x86 osx 5 buildbot slave
I have to shutdown the x86 osx 5 buildbot slave permanently, because the machine is getting a new role. Martin, please remove it from the configuration. -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPI comments and ratings, *really*?
A.M. Kuchling schrieb: If the open source approach of 'the maintainer decides' is followed, well, both the maintainer of the code and the admin of the site is Martin. Comments stay, then. If 'BDFL decides' is followed, GvR thinks the idea is reasonable (http://mail.python.org/pipermail/python-dev/2009-November/094058.html), though the implementation might be improved. Again, comments stay. If popular vote is ruled out, I don't see who else could possibly make the decision to disable comments and/or ratings. +1 -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of the Buildbot fleet and related bugs
R. David Murray schrieb: The buildbot waterfall is much greener now. Thanks to all who have contributed to making it so (and it hasn't just been Mark and Antoine and I, though we've been the most directly active (and yes, Mark, you did contribute several fixes!)). [...] In the 'unstable' builder fleet, Antoine's new builder seems to be stable across the board, while mine fails consistently on 3.1 and 3.x because of the test_telnetlib bug. Thomas Heller's OS X buildbot is consistently having lots of test failures (the same ones each time I've checked). My buildbot is behind our companys firewall. Well, I was able to fix the test_smtpnet test by additionally opening port 465 in the firewall; however I'm not really sure I should do that. I had to open another port already although that one is probably less critical. For the other test failures, I have no idea where they come from. -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Where is `ctypes.com` ?
Olemis Lang schrieb: Hello ! Recently I found a code snippet [1]_ illustrating integration between Python and COM technology in Win32 systems. I tried to reproduce it and I can't import module `ctypes.com`. First, the python-dev mailing list is used for developing the Python language itself, not developing WITH Python. For questions about developing with Python, please use the newsgroup comp.lang.python. Q: - Is it (`ctypes.com`) distributed with stdlib ? If that's true then I'm affraid that those py files were removed somehow (accidentally ? who knows ? ) ... ctypes.com is very old and has been superseeded by the comtypes package: http://starship.python.net/crew/theller/comtypes/ An even more popular package for using COM with python is pywin32: http://sourceforge.net/projects/pywin32/ -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] OS X buildbot
I have updated the OS X buildbot to Snow Leopard. -- Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacing PyWin32's PeekNamedPipe, ReadFile, and WriteFile
Christian Heimes schrieb: Can ctypes release the GIL for a function call? It will do that automatically, except for functions using the pythonapi callign convention. -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacing PyWin32's PeekNamedPipe, ReadFile, and WriteFile
Jean-Paul Calderone schrieb: On Thu, 23 Jul 2009 14:21:38 +0200, Christian Heimes li...@cheimes.de wrote: Michael Foord wrote: A big advantage of using ctypes is that it works cross-implementation - on IronPython and PyPy already and on Jython soon. I'd like to see more standard library modules use it. Distributions that choose not to include it are crippling their Python distribution. Interesting, I didn't know that IronPython supports ctypes, too. I still find ctypes a bit problematic because it doesn't us header files for its types, structs and function definitions. This is indeed a big problem with ctypes. Fortunately, a project exists to correct it: http://pypi.python.org/pypi/ctypes_configure/0.1 Anyone writing code with ctypes should be looking at ctypes_configure as well. There is also another project that uses gccxml to parse the header files and generate ctypes-compatible code. http://web.archive.org/web/20080115092648/starship.python.net/crew/theller/wiki/CodeGenerator Especially well on Windows works the dynamic, on-demand code generation. http://web.archive.org/web/20080115092648/starship.python.net/crew/theller/wiki/CodeGenerator/DynamicModule I do all win32 api programming with this stuff. I should note that the ctypeslib project is not well maintained because I don't have the time for that any longer. -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] py3k buildbots
Antoine Pitrou schrieb: Hello Only one of the py3k buildbots seems up: http://www.python.org/dev/buildbot/3.x.stable/ Maybe they are waiting for the snakebite network ;-) (what's up with it, anyway?). I've restarted mine (x86 osx.5), but it isn't in the stable list... -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] py3k buildbots
David Bolen schrieb:
Antoine Pitrou solip...@pitrou.net writes:
Only one of the py3k buildbots seems up:
http://www.python.org/dev/buildbot/3.x.stable/
Strange - everything looks good on my buildbot end (XP-4), including
an established TCP session back to dinsdale. Not sure why the master
thinks it's offline. Although I'm pretty sure I've seen this a handful
of times in the past too.
The fact that it also shows my FreeBSD buildbot offline (which I
rarely have to touch compared to the Windows version and they're on
the same host machine) seems to imply some wierd communication
breakdown.
I've restarted my buildbots.
Well, here is an excerpt from the twistd.log of my osx buildbot, in case someone
want to look at it. I restarted it this morning, at 2009/06/05 11:21 +0200:
2009/06/01 20:20 +0200 [Broker,client] SlaveBuilder._ackFailed:
SlaveBuilder.sendUpdate
2009/06/01 20:20 +0200 [Broker,client] SlaveBuilder._ackFailed:
SlaveBuilder.sendUpdate
2009/06/01 20:20 +0200 [Broker,client] SlaveBuilder._ackFailed:
SlaveBuilder.sendUpdate
2009/06/01 20:20 +0200 [Broker,client] lost remote
2009/06/01 20:20 +0200 [Broker,client] lost remote
2009/06/01 20:20 +0200 [Broker,client] lost remote
2009/06/01 20:20 +0200 [Broker,client] lost remote
2009/06/01 20:20 +0200 [Broker,client] lost remote step
2009/06/01 20:20 +0200 [Broker,client] stopCommand: halting current command
buildbot.slave.commands.SlaveShellCommand instance at 0x10820d0
2009/06/01 20:20 +0200 [Broker,client] command interrupted, killing pid 21579
2009/06/01 20:20 +0200 [Broker,client] trying os.kill(-pid, 9)
2009/06/01 20:20 +0200 [Broker,client] signal 9 sent successfully
2009/06/01 20:20 +0200 [Broker,client] twisted.internet.tcp.Connector instance
at 0x7930a8 will retry in 3 seconds
2009/06/01 20:20 +0200 [Broker,client] Stopping factory
buildbot.slave.bot.BotFactory instance at 0x10080f8
2009/06/01 20:20 +0200 [-] Unhandled Error
Traceback (most recent call last):
File
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/twisted/python/log.py,
line 48, in callWithLogger
return callWithContext({system: lp}, func, *args, **kw)
File
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/twisted/python/log.py,
line 33, in callWithContext
return context.call({ILogContext: newCtx}, func, *args, **kw)
File
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/twisted/python/context.py,
line 59, in callWithContext
return self.currentContext().callWithContext(ctx, func, *args, **kw)
File
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/twisted/python/context.py,
line 37, in callWithContext
return func(*args,**kw)
--- exception caught here ---
File
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/twisted/internet/selectreactor.py,
line 139, in _doReadOrWrite
why = getattr(selectable, method)()
File
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/twisted/internet/abstract.py,
line 113, in doWrite
l = self.writeSomeData(self.dataBuffer)
File
/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/twisted/internet/process.py,
line 879, in writeSomeData
return os.write(self.fd, data)
exceptions.OSError: [Errno 5] Input/output error
2009/06/01 20:20 +0200 [-] command finished with signal 9, exit code None
2009/06/01 20:20 +0200 [-] SlaveBuilder.commandComplete None
2009/06/01 20:20 +0200 [-] Starting factory buildbot.slave.bot.BotFactory
instance at 0x10080f8
2009/06/05 11:21 +0200 [-] Received SIGTERM, shutting down.
2009/06/05 11:21 +0200 [Broker,client] Stopping factory
buildbot.slave.bot.BotFactory instance at 0x10080f8
2009/06/05 11:21 +0200 [-] Main loop terminated.
2009/06/05 11:21 +0200 [-] Server Shut Down.
2009/06/05 11:21 +0200 [-] Log opened.
2009/06/05 11:21 +0200 [-] twistd 2.5.0
(/System/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python
2.5.1) starting up
2009/06/05 11:21 +0200 [-] reactor class: class
'twisted.internet.selectreactor.SelectReactor'
2009/06/05 11:21 +0200 [-] Loading buildbot.tac...
--
Thanks,
Thomas
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python on PowerPC?
Chris Plasun schrieb: Thanks for your reply. Ulrich Eckhardt wrote: On Wednesday 20 May 2009, Chris Plasun wrote: I'm to develop console apps on a Linux embedded PowerPC board (Freescale MPC8313). Is there a Python release for the PowerPC platform? This has pretty little to do with the development of the Python language itself, so it is rather off topic here. This group appeared to be relevant. That said, Linux systems are barely thinkable without Python, even when running on PPC, so yes, Python runs on PPC, too, and is included in probably every Linux distro, e.g. Debian. hmmm, hopefully I can find something to run in an embedded box. If you need to cross-compile, I have a build script and working patches to cross-build Python 2.6.2 for an ARM embedded system. Contact me by private mail if you want them. -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitting out bdist_* (was: interminable 'setuptools' thread)
gl...@divmod.com schrieb: On 07:59 pm, fdr...@acm.org wrote: I'm actually in favor of removing the bdist_* from the standard library, and allowing 3rd-party tools to implement whatever they need for the distros. But I don't think what you're presenting there supports it. I do think that it's relevant that the respective operating system packagers don't find bdist_rpm, bdist_deb, et. al. useful. It's not very useful to have a bdist_deb that nobody actually builds debs with. This has been a problem for me, personally, since debian has made various ad-hoc change to Twisted or Twisted-based packages to break our plugin system, since the distutils metadata has been insufficient for their purposes. If the deb-generating stuff were in a separate project with a faster release cycle that were easier to contribute packages to, perhaps debian packagers could be convinced to contribute their build- hacks there (and bdist_deb could invoke debhelper, or vice-versa). It would be great if someone could volunteer to maintain this stuff independently, put it in a Launchpad project or something. IMHO it would be better for the community at large if this were spun as increasing the release speed of the bdist_* family, rather than removing, which seems to me like it would generate another teacup- tempest on the blogowebs. Of course I'm not volunteering, but I will be best friends forever with whoever does this PR/maintenance :). Given that py2exe and py2app (which includes bdist_mpkg) are both based on distutils, it seems like we're on the way to independent maintenance anyway. Perhaps bdist_wininst/_msi could be donated to the py2exe project if they would be willing to maintain it, and the new project for _deb and _rpm could be called py2packman or something. Well, py2exe is Windows only. And I know that people used bdist_wininst to create windows installers on Linux. -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py_ssize_t support for ctypes arrays and pointers
Trent Nelson schrieb: On Fri, Mar 20, 2009 at 08:00:46PM +0100, Thomas Heller wrote: Since I do not have a machine with so much memory: Does one of the buildbots allow to run tests for this feature, or do I have to wait for the snakebite farm? Will you be at PyCon? The wait might not be as bad as you think ;-) No, I will not. But I've heard some rumors... -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Py_ssize_t support for ctypes arrays and pointers
I received some (so far unfinished) patches for ctypes that will allow to create arrays with more than 2**31 elements and that will eventually also support pointer offsets larger than int, on 64-bit platforms. Since I do not have a machine with so much memory: Does one of the buildbots allow to run tests for this feature, or do I have to wait for the snakebite farm? -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Include C++ code in the ctypes test suite?
I'm currently working on a patch that adds the __thiscall calling convention to ctypes. This calling convention is used on Windows for calling member functions from C++ classes. The idea is to eventually allow ctypes to wrap C++ classes. To test this functionality it is required to add some C++ source code to the ctypes private test module _ctypes_test.pyd/_ctypes_test.so. Is it appropriate to add C++ source files to the Python repository, or would that create too much trouble on some platforms? -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FormatError() in callproc.c under win32
Ulrich Eckhardt schrieb: Hi! In callproc.c from trunk is a function called SetException(), which calls FormatError() only to discard the contents. Can anyone enlighten me to the reasons thereof? Is it just to check if the errorcode is registered in the stringtables? I think that your guess is somewhat similar to what I thought when I wrote the code. The reason I ask is the CE port. The FormatMessage API exists there (or, rather, the FormatMessageW API), but the tables containing the error messages are optional for the OS and for space reasons many vendors chose not to include them. That means that the function there regularly fails to retrieve the requested string. My first approach was to fall back to simply providing a sting with a numeric representation of the errorcode, but that would change the meaning of above function, because then it could never fails. My second approach was to enhance PyErr_SetFromWindowsErr() to handle the additional error codes that are checked in SetException(). However, those require more context than just the error code, they use the EXCEPTION_RECORD passed to SetException() for that. My third approach would be to filter out the special error codes first and delegate all others to PyErr_SetFromWindowsErr(). The latter already handles the lack of a string for the code by formatting it numerically. This would also improve consistency, since the two functions use different ways to format unrecognised errors numerically. This approach would change where and how a completely unrecognised error code is formatted, but would otherwise be pretty equivalent. The third approach is fine with me. Sidenote: The only error codes that I remember having seen in practice are 'access violation reading...' and 'access violation writing...', although it may be that on WinCE 'datatype misalignment' may also be possible. -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a few strdup() questions...
BTW: there is another implementation (called my_strdup) in Modules/_ctypes/_ctypes_test.c, why not use the one in Python/strdup.c there? I guess that's historical, from the times when ctypes was still a separate package. my_strdup is an exported function in _ctypes_test.pyd (on Windows), it is only used in the ctypes tests. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The endless GIL debate: why not remove thread support instead?
Christian Heimes schrieb: Nick Coghlan schrieb: Actually, I believe 3.0 already took a big step towards allowing this by changing the way modules are initialised. You are believing correctly. Martin has designed and implemented a nicely working API to store extension module data per interpreter state. For now interpreter states are used for sub interpreters only. http://www.python.org/dev/peps/pep-3121/ But the extension modules still have to changed to use this mechanism, right? -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Removal of GIL through refcounting removal.
Victor Stinner schrieb: Le Friday 31 October 2008 14:13:01 Christian Heimes, vous avez écrit : ctypes is also missing utilities to write code that works on 32 and 64bit platforms. Without a tool like http://pypi.python.org/pypi/ctypes_configure it's very hard and tedious to avoid and fix segfaults. I wrote some ctypes binding and some ctypes tools are missing. The most important lacks are: - get_errno() - size_t and stdint.h types You may be interrested by my modules: Some of the problems you list here have already been fixed in Python 2.6: get errno value: http://python-ptrace.hachoir.org/trac/browser/trunk/ptrace/ctypes_errno.py (ctypes_support has a get_errno function) A new calling convention has been added for *safe* access to errno. open the C library: http://python-ptrace.hachoir.org/trac/browser/trunk/ptrace/ctypes_libc.py (ok, code is trivial, it's not critical to integrate it to ctypes) This code is not in ctypes, but with Python2.6 it will also work on windows. *size_t* and stdint.h types! http://python-ptrace.hachoir.org/trac/browser/trunk/ptrace/ctypes_stdint.py (my module is incomplete, some types are missing) Well, the signed types are named c_int8, c_uint8, and so on. size_t is named c_size_t, please look into Lib/ctypes/__init__.py. IIRC, these types are present event longer. Some functions to ease ctypes development: http://python-ptrace.hachoir.org/trac/browser/trunk/ptrace/ctypes_tools.py - bytes2type() and bytes2array() are useful to convert a bytes array to a ctypes object There are also new ctypes methods in Python 2.6 .from_buffer() and .from_buffer_copy() which should cover this use case. An example from your module: 124 def bytes2type(bytes, type): 125 126 Cast a bytes string to an objet of the specified type. 127 128 return cast(bytes, POINTER(type))[0] 129 Personally I would prefer to spell out 'cast(bytes, POINTER(type))[0]' instead of documenting and learning what bytes2type() does. Should I open issues? Please decide yourself. Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] svnmerge init in the release26-maint branch?
I have a fix for a modulefinder crash that I'm going to commit into the trunk. Since the bug is also in release26-maint I will also backport it. While preparing this I noticed that in the release26-maint branch 'svnmerge init' has not yet been done. I assume that we will use svnmerge to merge from trunk to release26-maint? So, is it ok to do 'svnmerge init' in it? -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] svnmerge init in the release26-maint branch?
Christian Heimes schrieb: Thomas Heller wrote: I have a fix for a modulefinder crash that I'm going to commit into the trunk. Since the bug is also in release26-maint I will also backport it. While preparing this I noticed that in the release26-maint branch 'svnmerge init' has not yet been done. Are you sure? I did a svnmerge init a couple of days after the release26-maint branch was created. I can see the properties on the branch, too. .../python/release26-maint$ svn proplist -v . | grep svnmerge svnmerge-blocked : /python/trunk:66721-66722,66744-66745,66752,66756,66763-66765,66768,66791-66792,66857 svnmerge-integrated : /python/trunk:1-66720,66723-66743,66746-66751,66753-66755,66757-66762,66766-66767,66769-66790,66793-66800,66802,66805-66812,66814-66821,66824-66831,66833-66835,66837-66851,66853,66858-66860,66862-66863,66881,66891,66906,66922,66928-66931,66933-66937,66939-66940,66958,66984,66995-66996,67000,67030-67031 Oh, sorry - I forgot to 'svn up' first. -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] buildbots
AFAICS there are no buildbots for the release26-maint branch. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] is the 'path' argument to an importer's find_module() just a hint?
Brett Cannon schrieb: I just discovered frozen packages set their __path__ simply to their name and not to a list as expected (http://bugs.python.org/issue4211). This made me think about the 'path' argument to find_module() and whether it can be treated as simply a hint or should always be seriously looked at. Take frozen modules, for instance. If the 'path' argument is meant to always be considered then if a frozen module is within a package a check should be done to make sure that the parent package is in 'path' somewhere. But if it is simply a hint, then 'path' should be ignored and whether the module can be found should depend fully on imp.is_frozen(). So, what do people think? Should 'path' for find_module() always be taken into consideration, or only when it happens to be convenient? At the moment I don't care about find_module for frozen modules/packages (is someone still using these?), but all the code I remember that manipulates a packages __path__ would most certainly break if it finds a string instead of a list. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] No manifest files on Windows?
Mark Hammond schrieb: In http://bugs.python.org/issue4120, the author suggests that it might be possible to completely stop using the manifest mechanism, for VS 2008. Given the many problems that this SxS stuff has caused, this sounds like a very desirable route, although I haven't done any actual testing yet. Can all the Windows experts please comment? Could that work? Does it have any downsides? If it works, I would like to apply it to 3.0, although I probably won't be able to apply it to tomorrow's rc. Would it also be possible to change that in 2.6.1 (even though python26.dll in 2.6.0 already includes a manifest, as do all the pyd files)? My take is that the bug is suggesting the manifest be dropped only from .pyd files. Python's executable and DLL will still have the manifest reference, so the CRT is still loaded from a manifest (FWIW, the CRT will abort() if initialized other than via a manifest!). What about COM objects: isn't pythoncom26.dll or _ctypes.pyd the first executable image that is loaded first for them? And how would they load the crt? -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python dll no longer in system directory?
Amaury Forgeot d'Arc schrieb: 2008/10/8 Martin v. Löwis [EMAIL PROTECTED]: Thomas Heller wrote: Is it intended that python30.dll and python26.dll are not longer installed in the \windows\system32 directory? No, it's not. Please create a bug report (or, better, study the msiexec logs, and msi.py, to find out why this happens). Done. http://bugs.python.org/issue4091 I might not have time to look into this before the next release candidate. I confirm this. The following lines in msi.py seem to be the cause of the change: #dlldir = PyDirectory(db, cab, root, srcdir, DLLDIR, .) #install python30.dll into root dir for now dlldir = root They were added by r61109: Bundle msvcr90.dll as a private assembly. but I don't know if simply restoring the previous value will work in every case: If the C Run-Time is installed privately, then python26.dll must stay in c:\python26. Amaury, can you add your analysis to the tracker, please? -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] python dll no longer in system directory?
Is it intended that python30.dll and python26.dll are not longer installed in the \windows\system32 directory? This (pythonxy.dll not on $PATH) causes problems for COM objects implemented in Python. Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python dll no longer in system directory?
Christian Heimes schrieb: Thomas Heller wrote: Is it intended that python30.dll and python26.dll are not longer installed in the \windows\system32 directory? This (pythonxy.dll not on $PATH) causes problems for COM objects implemented in Python. How did you install Python 2.6? Did you install it only for yourself or for all users? For all users. I only deselected the 'register file extensions' option. This is on XP SP3, with admin rights. -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Real segmentation fault handler
Victor Stinner schrieb: Hi, I would like to be able to catch SIGSEGV in my Python code! So I started to hack Python trunk to support this feature. The idea is to use a signal handler which call longjmp(), and add setjmp() at Py_EvalFrameEx() enter. On windows, ctypes catches fatal errors (exception violations) in foreign function calls, thanks to windows structured exception handling. On other platforms, there is the WAD module by David Beazley which may do something similar: http://www.dabeaz.com/papers/Python2001/python.html I do not know whether the code itself is still available or not. -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add python.exe to PATH environment variable
Perhaps we could have an option to place a python.bat into C:\Windows\ or C:\Windows\System\. Except you still have the last in wins issue, and you have to make a decision on whether or not to delete the file. If this is done the batch file should be named python25.bat or so depending on the version. -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add python.exe to PATH environment variable
Paul Moore schrieb: Bat files don't work when called from another bat file. This hits me regularly, when people supply wrapper bat files. Example: myscript.bat: @echo off do some stuff python my_py_script.py do some more stuff If python is a bat file, do some more stuff will never get run (you need to say call python to allow bat files to nest). -1 (or stronger!) on a bat file. If it goes in anyway, make it optional and off by default. The confusion and wasted time caused by bat files stopping part way through is FAR worse than that caused by having to manage PATH for yourself. Paul. PS If anyone knows a *good* way of writing wrapper scripts on Windows which doesn't suffer from the bat file nesting problem above, please let me (and the rest of the world!) know! /F's exemaker and Philip's setuptools script wrapper come to mind. -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] error: None when building extensions under 2.6
Fredrik Lundh schrieb: Amaury Forgeot d'Arc wrote: when I'm trying to build extensions under Python 2.6 on Windows XP, the build process terminates with single line that says: error: None which is about as useless as an error message can be. Googling for this brings up a few hits which all seem to involve setuptools (and none of the hits contain any answers), but I'm using straightforward distutils stuff that has worked without a glitch since 1.5.2. Has anyone else seen this for 2.6? I tried to rebuild some extensions, and it either succeeds, or fails with a meaningful (for an expert) error message. Which extensions did you try? is there some output before the error? pick any: http://effbot.org/downloads/ ;-) I'm beginning to suspect that I have a botched VS install on this machine, though. I'll investigate. Do you get a traceback when you set the DISTUTILS_DEBUG environment variable? Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Windows buildbot trick
The most annoying thing on the windows buildbots is when Python crashes hard (with a general protection fault or stack overflow, for example). Usually the system pops up a dialog in this case which allows to attach a debugger to the process. This dialog will stay open until the maintainer manually closes it, and will prevent the next builds. On my boxes I have inserted these two lines into the PythonXY/Scripts/buildbot script, right at the top: import win32api; win32api.SetErrorMode(7) print SetErrorMode(7) called. These lines prevent the dialog box to be displayed for critical errors. For example, on Windows AMD64 the test_cpickle test in the trunk currently fails with a stack overflow; instead of hanging with the mentioned dialog box open the test now terminates: http://www.python.org/dev/buildbot/trunk/amd64%20XP%20trunk/builds/40/step-test/0 -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows buildbot trick
Sidnei da Silva schrieb: On Fri, Jul 18, 2008 at 12:42 PM, Sidnei da Silva [EMAIL PROTECTED] wrote: That's a great trick! I seem to remember that there is a way to turn that off globally though, but not sure where. Maybe running drwtsn32.exe and un-checking 'Visual Notification' does the trick? FWIW, here's a kb article that describes this. Although it refers to 32-bit apps on 64-bit XP, I'm pretty sure you can do the same for 32-bit XP? http://support.microsoft.com/kb/283150/EN-US/ Well, generally it is a good idea on a developer machine to automatically start the debugger when a problem in the tested application happens, so I prefer to not change this setting globally. However, some time ago I have tried to turn the notifications off in every way I could find but did not succeed. Although I'm not sure I found the article you mentioned. -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org 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 3101: floats format 'f' and 'F'
Guido van Rossum schrieb:
On Thu, Jul 17, 2008 at 9:25 AM, Raymond Hettinger [EMAIL PROTECTED] wrote:
From: Eric Smith [EMAIL PROTECTED]
I have this ready for checkin (with docs and tests). I'd like to get it
in for this beta, since it does involved changed behavior, no matter how
small ('1e+100' becomes '1E+100' with '%F'). But it relies on the
platform's vsnprintf to do the right thing with 'F', so I'm worried
about breakages on platforms I don't have access to. Resolving those
issues might take a few days.
Any advice on checking this in now, or waiting until after this beta is
released?
I recommend doing it after the release. It's unlikely to be exercised
much by the beta users so there's no real advantage. If you wait
until afterwards, then there is time to let the buildbots have a go
at it and reveal any cross-platform issues.
Besides, Barry said something about getting meaner.
Would hate to find out what he meant the hard way ;-)
I'd advise the opposite -- check it in now. It's not going to break
anything, and if it is, let's find out sooner rather than later.
Before we get old waiting for the windows buildbots, here how test_format
fails now (on XP SP2 x86, trunk rev 65072:
c:\svn\trunk\PCbuild.\\python_d -E -tt ../lib/test/regrtest.py test_format
test_format
test test_format produced unexpected output:
**
'%F' % (1.0,) == '' != '1.00'
u'%F' % (1.0,) == u'' != '1.00'
'%f' % (nan,) == '-1.#IND00' != 'nan'
u'%f' % (nan,) == u'-1.#IND00' != 'nan'
'%F' % (nan,) == '' != 'NAN'
u'%F' % (nan,) == u'' != 'NAN'
'%f' % (inf,) == '1.#INF' != 'inf'
u'%f' % (inf,) == u'1.#INF' != 'inf'
'%F' % (inf,) == '1.#INF' != 'INF'
u'%F' % (inf,) == u'1.#INF' != 'INF'
**
1 test failed:
test_format
[23521 refs]
c:\svn\trunk\PCbuild
Windows vsnprintf does not support '%F' at all, and '%f' does not
behave as expected with nan and inf.
--
Thanks,
Thomas
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ctypes assertion failure
Tim Golden schrieb: This problem was raised on the comtypes-users list as it prevents comtypes from being imported on Python 2.6 at the moment. http://bugs.python.org/issue3258 I'll try to find the time to step through to code to work out what's going on, but it's inside the innards of ctypes which I've never looked into before. Could someone confirm at a glance whether this should be given a high priority, please? It results in an assertion error in debug mode, a SystemError in non-debug referring to a NULL return without an Exception set. The problem is now fixed. -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Vacation
FYI: I'm going to a vacation for the next two or three weeks. I will shutdown my buildbots, and restart them when I'm back: x86 osx.5, x86 XP-3, amd64 XP. Sorry for the inconvenience, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] rest markup in ctypes docs
There are a few cases where the ctypes docs are rendered incorrectly: http://docs.python.org/dev/library/ctypes.html#function-prototypes This looks as if 'prototype' would be a symbol exposed by ctypes; it is not - it is used as a placeholder for the object returned by calls to the ctypes.CFUNCTYPE, ctypes.WINFUNCTYPE, and ctypes.PYFUNCTYPE functions above. The rest markup is like this: .. function:: prototype(address) :noindex: Returns a foreign function at the specified address. Some lines below, it looks like ctypes would export '1', '2', and '4'. Here is the markup: .. function:: prototype(address) :noindex: Returns a foreign function at the specified address. How can this be fixed? -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] rest markup in ctypes docs
Thomas Heller schrieb: There are a few cases where the ctypes docs are rendered incorrectly: http://docs.python.org/dev/library/ctypes.html#function-prototypes This looks as if 'prototype' would be a symbol exposed by ctypes; it is not - it is used as a placeholder for the object returned by calls to the ctypes.CFUNCTYPE, ctypes.WINFUNCTYPE, and ctypes.PYFUNCTYPE functions above. The rest markup is like this: .. function:: prototype(address) :noindex: Returns a foreign function at the specified address. Some lines below, it looks like ctypes would export '1', '2', and '4'. Here is the markup: Sorry, I meant this: .. data:: 1 :noindex: Specifies an input parameter to the function. How can this be fixed? -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP3118, python 2.6
Hi Travis, I'm currently trying to port the pep3118 ctypes changes which are already in the py3k branch to the trunk. In py3k the tests for this stuff (in Lib/ctypes/test/test_pep3118.py) use the memoryview object which exposes attributes like .format, .shape, .strides and so on for objects implementing the new buffer interface. In Python 2.6 memoryview does not exist so the question is how to write a test that checks for the correct attributes. My idea is to implement the __array_interface__ property for ctypes instances, as described in this document http://numpy.scipy.org/array_interface.shtml. Do you think this is a good idea, or would it be better to invent another, private, mechanism for the tests? In other words: Would the __array_interface__ property (version 3) on these objects be useful for external code or would it disrupt external code? BTW: Did you have a chance to look over the test_pep3118 module in py3k, to make sure that I got things correctly (it should be pretty easy to read, imo)? -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP3118, python 2.6
Thomas Heller schrieb: I'm currently trying to port the pep3118 ctypes changes which are already in the py3k branch to the trunk. In py3k the tests for this stuff (in Lib/ctypes/test/test_pep3118.py) use the memoryview object which exposes attributes like .format, .shape, .strides and so on for objects implementing the new buffer interface. In Python 2.6 memoryview does not exist so the question is how to write a test that checks for the correct attributes. My idea is to implement the __array_interface__ property for ctypes instances, as described in this document http://numpy.scipy.org/array_interface.shtml. In private email Travis told me that he has no time to backport the memoryview object to Python 2.6. Maybe there is someone who could do this (Myself I have no time either for this)? Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP3118, python 2.6
Lisandro Dalcin schrieb: On 6/5/08, Thomas Heller [EMAIL PROTECTED] wrote: Thomas, Iff this helps, you have attached the backport but as an extension module. Sorry, I do not have time for the full backport. But at least, I've found that the Py3K implementation works Thanks for the effort. Maybe I will look into that later. (And, if you want to make sure that your patch doesn't get lost and hopefully reviewed you should add it to the bug tracker.) In the meantime I found that I already had a _ctypes private function that can expose the needed info to Python, for ctypes pep3118 testing. Thanks again, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Addition of pyprocessing module to standard lib.
Bill Janssen schrieb: What happens on those platforms where ctypes doesn't work? Does the module fail to import, either because it isn't present, or because it can't load the libffi library? Or does it fail silently in some way? It doesn't compile, and Python's setup.py script removes if afterwards IIRC so it cannot be imported. In some cases it compiles, but the ctypes unittests segfault (I have seen this some days ago on HP-UX PA with gcc). The cause for the segfault is either a ctypes bug or a libffi bug. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Addition of pyprocessing module to standard lib.
A.M. Kuchling schrieb: On Mon, May 19, 2008 at 08:50:39PM +0200, Thomas Heller wrote: Myself I would rather spend my energy to make ctypes more portable, within my skills and the platforms I have access to. Someone could run Solaris x86 inside a hosted virtual machine and make it available to the Python developers. Is it possible to find similar hosting for HP-UX and AIX? Or might IBM or HP be willing to donate a low-end machine to the PSF for porting use? I have a vmware appliance installed that runs solaris 10 update 2, gcc and the sun compiler are installed. As expected (?), ctypes works fine when compiled with gcc, but fails to build with the siun compiler. There is also a solaris buildbot running on a sparc machine. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Addition of pyprocessing module to standard lib.
Ulrich Berning schrieb: If porting libffi to AIX, HP-UX, IRIX, Solaris... (especially using vendor compilers) would be an easy job, I'm sure it would have been done already. If more and more essential packages depend on ctypes, we should make a clear statement, that Python isn't supported any longer on platform/compiler combinations where libffi/ctypes doesn't build. This would give me arguments to drop support of our software on those platforms. Ulrich, if *you* have access to these platforms and want to help a good start which hopefully wouldn't take too much time would be to compile the current libffi release [1], run the test suite, and report the results. Compile with gcc, for a start, and note that the testsuite requires dejagnu (the PyObjC folks have written a dejagnu replacement in Python for testing libffi, but I haven't tried that). [1] http://sourceware.org/libffi/ -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Addition of pyprocessing module to standard lib.
Michael Foord schrieb: James Y Knight wrote: On May 21, 2008, at 11:26 AM, Michael Foord wrote: And what about platforms like the JVM or CLR? Incidentally there were a small but vocal group of Pythonistas who were (are?) certain that IronPython is not Python because it doesn't have [all of...] the C extensions. It seems likely to be easier to port ctypes to Jython/IronPython than it is to port 500 C extensions to Jython. So more software using ctype seems like an improvement for those communities. Yes, both of them have their own FFIs. Seo Sanghyeon started a port of ctypes for IronPython that should be revived by 'someone'. :-) OT: There is also some noise about a ctypes-js implementation for JavaScript; although I do not know how far they are. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Addition of pyprocessing module to standard lib.
Charles Cazabon schrieb: A.M. Kuchling [EMAIL PROTECTED] wrote: On Mon, May 19, 2008 at 08:50:39PM +0200, Thomas Heller wrote: Myself I would rather spend my energy to make ctypes more portable, within my skills and the platforms I have access to. Someone could run Solaris x86 inside a hosted virtual machine and make it available to the Python developers. Is it possible to find similar hosting for HP-UX and AIX? Or might IBM or HP be willing to donate a low-end machine to the PSF for porting use? You can test HPUX and VMS with a (free) HP Testdrive account (along with a bunch of Linuxes and *BSDs) on various hardware platforms. I used it extensively when doing portability testing of another project. http://www.testdrive.hp.com/ Charles I'm doing that. From time to time, these systems are a pain to use IMO. A buildbot is s much better... -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Addition of pyprocessing module to standard lib.
Bill Janssen schrieb: Hmm, perhaps the ctypes documentation could use a more prominent warning that it may not be available on some Unix platforms (HP-UX, AIX, IRIX), and that it may require the use of GCC rather than the vendor compiler on others (Solaris). At the moment, I suspect some projects may be switching to using it without realising the implications for cross-platform portability. I think it's a tad more problematic. As other modules, both in and out of the standard library, move to use ctypes, it implies that *Python* isn't supported on those combinations. Personally, that's fine with me (as long as there's a workaround for Solaris!), but I think that Ulrich is right in saying this should be more prominent. I won't object if anyone adds this notice to the Python docs, so please go ahead. A table of platforms (on the wiki?) where ctypes builds/works or does not may also be helpful. Myself I would rather spend my energy to make ctypes more portable, within my skills and the platforms I have access to. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Addition of pyprocessing module to standard lib.
Ulrich Berning schrieb: Nick Craig-Wood wrote: Jesse Noller [EMAIL PROTECTED] wrote: I am looking for any questions, concerns or benchmarks python-dev has regarding the possible inclusion of the pyprocessing module to the standard library - preferably in the 2.6 timeline. In March, I began working on the PEP for the inclusion of the pyprocessing (processing) module into the python standard library[1]. The original email to the stdlib-sig can be found here, it includes a basic overview of the module: http://mail.python.org/pipermail/stdlib-sig/2008-March/000129.html The processing module mirrors/mimics the API of the threading module - and with simple import/subclassing changes depending on the code, allows you to leverage multi core machines via an underlying forking mechanism. The module also supports the sharing of data across groups of networked machines - a feature obviously not part of the core threading module, but useful in a distributed environment. I think processing looks interesting and useful, especially since it works on Windows as well as Un*x. However I'd like to see a review of the security - anything which can run across networks of machines has security implications and I didn't see these spelt out in the documentation. Networked running should certainly be disabled by default and need explicitly enabling by the user - I'd hate for a new version of python to come with a remote exploit by default... As long as the ctypes extension doesn't build on major Un*x platforms (AIX, HP-UX), I don't like to see ctypes dependend modules included into the stdlib. Please keep the stdlib as portable as possible. More and more people tend to say Runs on Un*x when they really mean Tested on Linux. Un*x is not Linux. Hm, I've never looked at the processing module. Does it depend on ctypes? Anyway, the trunk version of ctypes is a lot more portable than the release25-maint version. I have once tried to build the trunk on HP-UX machines, and, IIRC, it did build on IA64 and PA machines. Of course only with GCC, not with the vendor compilers. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove current Windows executables from Lib/distutils/command in svn?
Martin v. Löwis schrieb: I'd like to propose we delete Lib/Distutils/command/wininst-9.0.exe, and enable the building of that project by default in the standard build process (and I'll setup the x64 build of the executable similarly). There are two issues here: a) how does the binary get into the release tarball? You might argue that it doesn't have to, as it is sufficient when it is included in the Windows installer, however, as currently implemented, bdist_wininst also runs on Unix, and people use it that way. b) IIRC, upx was used to compress these executables. I don't think the the current build process covers this, yet (but then, the current binaries might not be compressed with upx anymore, either - not sure whether that would be a bug). Of course, upx would probably not currently apply to Win64-amd64. I did not compress them with upx anymore because of licensing issues with the upx-created executables, but I do not remember the details anymore. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] osx x86 buildbot offer
I can offer an OS X x86 machine to run a buildbot on. This is a physical machine, running OS X 10.5 Leopard. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] First green Windows x64 buildbots!
Trent Nelson schrieb: We've just experienced our first 2.6 green x64 Windows builds on the build slaves! Well, almost green. Thomas's 'amd64 XP trunk' ran out of disk: 304 tests OK. 1 test failed: test_largefile == ERROR: test_seek (test.test_largefile.TestCase) -- Traceback (most recent call last): File C:\buildbot\trunk.heller-windows-amd64\build\lib\test\test_largefile.py, line 42, in test_seek f.flush() IOError: [Errno 28] No space left on device Sorry about that Thomas ;-) Trent - that's great. I'll try to free some diskspace. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] trunk buildbot status
Neal/Martin, I'd like to promote the following slaves to the stable list: [g4 osx.4] [x86 W2k8] [AMD64 W2k8] [ppc Debian unstable] [sparc Ubuntu] [sparc Debian] [PPC64 Debian] [S-390 Debian] [x86 XP-3] [amd64 XP] [x86 FreeBSD] [x86 FreeBSD 3] The trunk builds of these slaves have been the most reliable since I've been tracking. Most of these have already been promoted to stable. I just didn't restart the buildbot master since making the change. It requires a restart, not just a reconfig. I was waiting for a quiet time when the bots weren't busy, but that hasn't happened yet. :-) I can make more changes and restart when I get home. Hm, what is this 'stable list' anyway? BTW: Although the x86 XP-3 and x86 W2k8 bots are green, there's still a problem: test_tcl test_tcl skipped -- DLL load failed: The specified module could not be found. AFAIK, this is because tcl86g.dll and tk86g.dll fail to load because they cannot find MSVCR90D.DLL; do these dlls need a manifest? Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Consistent platform name for 64bit windows (was: distutils.util.get_platform() for Windows)
M.-A. Lemburg schrieb: About the platform.py changes: if someone could provide the return values of sys.getwindowsversion() for 64bit versions of Windows XP and Vista, I could add support for it (don't have a 64bit version of Windows available to check myself). This is the output of a 32-bit Python running on Windows XP Professional x64 Edition, Version 2003, Service Pack 2: C:\Python24ver Microsoft Windows [Version 5.2.3790] C:\Python24python Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import sys sys.getwindowsversion() (5, 2, 3790, 2, 'Service Pack 2') Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] PEP 361: Python 2.6/3.0 release schedule
Barry Warsaw schrieb: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 18, 2008, at 2:04 AM, Travis Oliphant wrote: Hey Barry, Thanks for putting this PEP together. This is really helpful. Hi Travis... thanks! I didn't see discussion of PEP 3118 and it's features back-ported to Python 2.6. I've already back-ported the new buffer API as an addition to the old buffer protocol. In addition, I've planned to back-port the improvements to the struct module and the addition of the memoryview object (both in PEP 3118). If you have questions, we can talk tomorrow. Let's do that. Neal has put together a list of things that he thinks needs to be backported. We should formalize that list (as best we can given we're still in alpha), and add it to the PEP. I think we should also make sure we have open issues in the tracker for each backporting task. I think that [issue1971] ctypes exposing the pep 3118 buffer interface should / could also be backported to 2.6 (once it is merged into py3k). Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Auto-Assignment
Jeroen Ruigrok van der Werven schrieb: -On [20080307 11:05], Guilherme Polo ([EMAIL PROTECTED]) wrote: When you create a new issue, you have to select a component from a list, those are the available components. I think Thomas was wondering what the definition for a component was within Roundup/the Python project and if ctypes would need to be a component entry as such. Exactly. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Auto-Assignment
Martin v. Löwis schrieb: I just implemented auto-assignment for the tracker, i.e. a component can be linked to a developer so that issues mentioning the component get assigned to that developer (unless an explicit assignment is made). You can autoassign ctypes issues to me, as you might have guessed. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Auto-Assignment
Martin v. Löwis schrieb: Thomas Heller wrote: Martin v. Löwis schrieb: I just implemented auto-assignment for the tracker, i.e. a component can be linked to a developer so that issues mentioning the component get assigned to that developer (unless an explicit assignment is made). You can autoassign ctypes issues to me, as you might have guessed. ctypes is currently not a component in the tracker. Should it be one? Hm, I didn't see that. What is a components, and do you think it should be one? Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows buildbots randomly die with twisted ConnectionLost errors?
Trent Nelson schrieb: I've started to see my build slave dying every so often with a twisted error half way through tests: ... test_htmlparser test_httplib remoteFailed: [Failure instance: Traceback (failure with no frames): twisted.internet.error.ConnectionLost: Connection to the other side was lost in a non-clean fashion. ] Examples: http://www.python.org/dev/buildbot/all/x86%20W2k8%20trunk/builds/46/step-test/0 http://www.python.org/dev/buildbot/all/x86%20W2k8%20trunk/builds/36/step-test/0 I'm not sure if I should read into the fact that it's occurring after networking-oriented tests like test_httplib and test_ftplib. Running rt.bat on the resulting build manually doesn't indicate any errors in these tests. Have other Windows buildbot owners seen this? Trent. I have not observed this behaviour on my buildbots. Have you looked into the twistd.log logfile? Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows buildbots randomly die with twisted ConnectionLost errors?
Trent Nelson schrieb: Had a chat with some Twisted/buildbot folk and they can confirm they've seen it as well on Windows. They've given me a few things to look into. Out of interest, how are you running your buildbot? Via the command line in an interactive desktop session, as a service, or as a scheduled task, or some other way? From the command line in interactive sessions. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing buildbot/external(-amd64).bat files on Windows
Trent Nelson schrieb: Howdy, I'm going through the motions of getting my newly added build slave in a half decent state. I think the buildbot should have a name different from 'x86 XP'. (Martin, Neal?) Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing buildbot/external(-amd64).bat files on Windows
Trent Nelson schrieb: Howdy, I'm going through the motions of getting my newly added build slave in a half decent state. The external.bat and external-amd64.bat files needed the following in order to build db-4.4.20: Index: external.bat === --- external.bat(revision 61125) +++ external.bat(working copy) @@ -10,7 +10,8 @@ @rem Sleepycat db if not exist db-4.4.20 svn export http://svn.python.org/projects/external/db-4.4.20 if not exist db-4.4.20\build_win32\debug\libdb44sd.lib ( - vcbuild db-4.4.20\build_win32\Berkeley_DB.sln /build Debug /project db_static + devenv /upgrade db-4.4.20\build_win32\Berkeley_DB.sln + devenv db-4.4.20\build_win32\Berkeley_DB.sln /build Debug /project db_static ) @rem OpenSSL This change is fine by me (if it works ;-). Do you have commit rights, or do you want me to check it in? (This is against trunk, same thing would apply to py3k I guess, given that we're using %VS90COMNTOOLS%vsvars32.bat there too.) I guess it will be merged automatically by Christian. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing buildbot/external(-amd64).bat files on Windows
Trent Nelson schrieb: Christian Heimes: Trent Nelson wrote: - vcbuild db-4.4.20\build_win32\Berkeley_DB.sln /build Debug /project db_static + devenv /upgrade db-4.4.20\build_win32\Berkeley_DB.sln + devenv db-4.4.20\build_win32\Berkeley_DB.sln /build Debug /project db_static The upgrade is requires only once. It probably belongs next to the checkout or svn up and not in the build section. Makes sense. So we're looking at something like: @rem Sleepycat db if not exist db-4.4.20 ( svn export http://svn.python.org/projects/external/db-4.4.20 devenv /upgrade db-4.4.20\build_win32\Berkeley_DB.sln ) if not exist db-4.4.20\build_win32\debug\libdb44sd.lib ( devenv db-4.4.20\build_win32\Berkeley_DB.sln /build Debug ) I'll test this when I get to work and report back. Great. What's the difference between these two? vcbuild db-4.4.20\build_win32\Berkeley_DB.sln /build Debug devenv db-4.4.20\build_win32\Berkeley_DB.sln /build Debug Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbots for trunk are all red
Neal Norwitz schrieb: On Tue, Feb 26, 2008 at 11:47 PM, Brett Cannon [EMAIL PROTECTED] wrote: Well, in my opinion batteries included is great, but not when one of the batteries consistently acts up and requires a good shake to get working again. The bsddb module has consistent reliability issues when it comes to testing (and I suspect it has more to do with Sleepycat than the bindings). I know I am tired of getting buildbot errors saying that the bsddb tests died more consistently than most tests over their history. I agree that bsddb has been a pain. It's about 1 of 10 tests that fill that category. I've been working on reducing these problems (recently: test_bsddb3, test_smptlib, test_xmlrpclib, and I'm sure there are others I forgot). Rather than remove modules, it would be more productive if we fixed the flaky tests. Then we wouldn't have to ignore failures, we could trust the buildbots. Maybe the flaky tests could be moved towards the end? This way we could at least see if the other tests work. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Error in PEP3118?
Travis Oliphant schrieb: Thomas Heller wrote: Travis Oliphant schrieb: So, I think the example is correct (and intentional). Sorry, I do not think so. If you use a 2-d array in the example, you must describe it correctly. The difference between this pep and the old I don't understand what you mean by must describe it correctly. The [...] Travis, it seems anyone except me understands what you say and thinks it is fine. So, IMO it would be best to live with this misunderstanding and close the discussion. Thanks and sorry about the confusion, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] pep3118, ctypes, py3k
Hi Travis, I have started the pep3118 implementation for ctypes. If you have time, could you please review http://bugs.python.org/issue1971, especially the tests in file Lib/ctypes/test/test_pep3118.py to ensure that I have understood and implemented the pep correctly? Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5.2 release coming up
Neal Norwitz schrieb: We need to fix the Windows buildbots. 2 tests are currently failing for 2.5.2: test_mailbox test_winreg The test_winreg failure is a funny one: The py3k test_winreg fails because of a bug in the test itself; I fixed this in rev. 60236. The failing test leaves a key in the registry that make the trunk and release25-maint tests also fail. I have manually removed the offending key in the registry on the x86 XP-3 buildbot; we'll see if it works now. The real solution, however, would be to change all the test_winreg tests to remove the test-key completely before and after their test. But I'll leave this to someone else. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Error in PEP3118?
Travis Oliphant schrieb: [...] I responded off list to this email and wanted to summarize my response for others to peruse. Basically, the answer is that the struct syntax proposed for multi-dimensional arrays is not intended to mimic how the C-compiler handles statically defined C-arrays (i.e. the pointer-to-pointers style of multi-dimensional arrays). It is intended to handle the contiguous-block-of-data style of multi-dimensional arrays that NumPy uses. I wanted to avoid 2-d static arrays in the examples because it gets confusing and AFAIK the layout of the memory for a double data[16][4] is the same as data[16*4]. The only difference is how the C-compiler translates data[4][3] and data[4]. The intent of the struct syntax is to handle describing memory. The point is not to replicate how the C-compiler deals with statically defined N-D arrays. Thus, even though the struct syntax allows *communicating* the intent of a contiguous block of memory inside a structure as an N-d array, the fundamental memory block is the equivalent of a 1-d array in C. So, I think the example is correct (and intentional). Sorry, I do not think so. If you use a 2-d array in the example, you must describe it correctly. The difference between this pep and the old buffer interface is that the pep allows to describe both how the compiler sees the memory block plus the size and layout of the memory block, while the old buffer interface only describes single-segment memory blocks. And 'double data[16][4]' *is* a single memory block containing a 2-d array, and *not* an array of pointers. --- Here is another typo (?) in the pep; I think it should be changed: Index: pep-3118.txt === --- pep-3118.txt(revision 60037) +++ pep-3118.txt(working copy) @@ -338,7 +338,7 @@ ``len`` the total bytes of memory the object uses. This should be the -same as the product of the shape array multiplied by the number of +same as the length of the shape array multiplied by the number of bytes per item of memory. ``readonly`` After all, imo there's a lot to do to fully implement the pep for python 2.6. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] struct module docs vs reality
Gregory P. Smith schrieb: The documentation for the struct module says: http://docs.python.org/dev/library/struct.html#module-struct short is 2 bytes; int and long are 4 bytes; long long (__int64 on Windows) is 8 bytes and lists 'l' and 'L' as the pack code for a C long. As its implemented today, the documentation is incorrect. On an LP64 host (pretty much any 64-bit linux, bsd or unixish thing) a long is 8 bytes. I assume this means there is existing code out there that expects the current not-as-documented behavior. There is also code out there that expects the documented behavior but behaves wrong when a 64bit Python is used. I assume I should just fix the documentation and anything in Lib that uses the struct module incorrectly (zipfile for example) rather than change the behavior? +1 (actually +100) from me. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Error in PEP3118?
Hi Travis,
The pep contains this sample:
Nested array
::
struct {
int ival;
double data[16*4];
}
i:ival:
(16,4)d:data:
I think it is wrong and must be changed to the following; is this correct?
Nested array
::
struct {
int ival;
double data[16][4];
}
i:ival:
(16,4)d:data:
Thomas
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] building _ctypes in trunk fails first time around
Guido van Rossum schrieb: If I run make clean and then make, builting _ctypes fails with this message: *** WARNING: renaming _ctypes since importing it failed: No module named _weakref Typing make a second time fixes this -- it seems a simple matter of _ctypes being built before _weakref. What a pity. Can the order be changed in which the extensions are built, or should the importing be tried after all the extensions are ready? Or should _weakref be made a builtin module? Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What to do for bytes in 2.6?
Guido van Rossum schrieb: I believe the issue of whether and how to backport bytes (and bytearray?) from 3.0 to 2.6 has come up before, but I don't think we've come to any kind of conclusion. It's quite subtle. In a private email, Thomas Wouters and I discussed this: [Guido] Perhaps the biggest question in my mind is what to do with bytes in 2.6. Make it an alias for str? Or a new type that doesn't mix with either str or unicode? But then how do we get read() calls and the like on binary files or sockets to return bytes instances? Perhaps a trivial str subclass? Or return bytes when -3 is specified? I need to bring this up on the list. [Thomas] I don't know yet. I'm not sure yet what to do with strings and unicode in 2.6 in -3 mode (or perhaps through a future-import, with some hackery.) Perhaps a *set* of str-subclasses makes sense: a will-be-unicode subclass, and a will-be-bytes subclass. String literals and text-mode input would produce will-be-unicode, binary input and byte literals will-be-bytes. Switching between -3 and normal mode for that would be changing a few pointers in the core, making all operations return normal strings in normal mode. And the would-be types can produce whatever warning they wish -- they need not worry about speed. But I'm not sure if that'll work. Is the bytes type required for PEP3118 'Revising the buffer protocol'? I just started to work on implementing this PEP for ctypes, in the hope that these changes can be merged into trunk. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coverity Scan, Python upgraded to rung 2
[EMAIL PROTECTED] schrieb: Christian I read the announcement of the Python Users list and figured Christian out that some of the other core developers might be Christian interested in the news, too. Christian Among other projects Python was upgraded to Rung 2 on the Christian Coverity Scan list: http://scan.coverity.com/ I went to the run2 page: http://scan.coverity.com/rung2.html On this page, when I click the 'sign in' link, I see the page http://scan.coverity.com/maintenance.html which says: Scan administrators are performing maintenance on the selected project. Normally, project members will have received notification in advance of any lengthy unavailability of their project. Please try again later, or contact [EMAIL PROTECTED] with any questions. Return to Main Page Could it be that they were a little bit early with the press release, and the rung2 scanner is not yet active? I shows 6 uninspected defects for Python. How do we see what they are? What is an uninspected defect? Any idea how the Coverity folks compute Defects/KLOC? For example, how does tcl manage to get a 0.0 score? Seems they are referring to the results of the rung 1 run (what ever 'rung' means ;-). With the account Neal made me some months ago, I can login on this page: http://scan.coverity.com:7475/ and see the scan results for Python. Last run at 2007-12-27: 11 Outstanding Defects, 6 of them marked uninspected, 3 marked pending, and 2 marked bug. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coverity Scan, Python upgraded to rung 2
Guido van Rossum schrieb: On Jan 9, 2008 9:47 AM, Christian Heimes [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: I shows 6 uninspected defects for Python. How do we see what they are? What is an uninspected defect? Any idea how the Coverity folks compute Defects/KLOC? For example, how does tcl manage to get a 0.0 score? I can't answer your question. I don't have access to the Python project on their site and the project is currently under maintenance. Maybe Neal can sheds some light on the Coverity Scan project. I'm pretty sure I have an account and I can't get in either. I have contacted coverity asking if they can give accounts to other core developers besides Neal and myself. As I said in the other reply, I can still login on this page: http://scan.coverity.com:7475/ It looks like about 20 users are registered; if wanted I can post the list here. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coverity Scan, Python upgraded to rung 2
Christian Heimes schrieb: Thomas Heller wrote: Seems they are referring to the results of the rung 1 run (what ever 'rung' means ;-). With the account Neal made me some months ago, I can login on this page: http://scan.coverity.com:7475/ and see the scan results for Python. Last run at 2007-12-27: 11 Outstanding Defects, 6 of them marked uninspected, 3 marked pending, and 2 marked bug. My dict says: rung (of a ladder)- Leitersprossen Python has climbed up one step (or rung) of the ladder. Thanks. I was too lazy to fire up dict.leo.org ;-) Do you have the required permission to add more users to the site? No, I can only view the results (and add comments or so...). Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hello, I'm the other new guy
Facundo Batista schrieb: 2007/11/14, Christian Heimes [EMAIL PROTECTED]: After Amaury introduced himself I've decided that I *have* to take some time to introduce myself, too. It's probably too late to say welcome to both Christian and Amaury, also we have already met in the bug tracker. I'm especially pleased that both of you also care about and work on Windows stuff - much appreciated. Thomas PS: I smiled when I saw your introductions. Amaury: I also have 5 children, and Christian: I'm also a 'strange' guy (but not metal and gothic). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] ctypes and libffi
The ctypes sources contain the source code for libffi, in Modules/_ctypes/libffi. These sources were pulled from GCC cvs some time ago, and a new configure system was written by Perky iirc. Now, it seems that these sources are showing their age and a newer libffi version should be used instead. There are issues on certain platforms like mips64, arm, armeabi; also on other systems to correctly use the c_longdouble data type that I added recently. See also http://bugs.python.org/issue1292. Pythons configure command has a --with-system-ffi option that, if specified, uses a system installed libffi package (if present). By default, the bundled sources are used. The cleanest way to fix this problem probably would be to remove the outdated libffi sources from Python svn (in trunk and py3k), and require a system installed libffi for building ctypes. However, I have no idea if there are libffi packages available for systems like solaris, BSD, or OS X (to name a few that come to mind). Another way would be to leave the sources in place, and only use them when no system libffi installation is present - in other words to change the default of the --with-system-ffi option. Matthias Klose has already committed a change to configure.in that sets --with-system-ffi=yes for Linux/arm* systems. This would be a third way: do this for all systems that require newer libffi. Any thoughts? Thanks, Thomas PS: As a test, I changed setup.py (in branches/ctypes-branch) so that always a system installed libffi is used, and manually triggered the build on the bots that failed or even crashed before: ppc Debian unstable, and S-390 Debian. PPS: The above does not apply for Windows; the windows libffi suorces work fine and are in different subdirectories. Also, configure is not used on Windows. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Special file nul in Windows and os.stat
Chris Mellon schrieb: On Oct 24, 2007 11:05 PM, Martin v. Löwis [EMAIL PROTECTED] wrote: So, the question is what we should do?: Before this question can be answered, I think we need to fully understand what precisely is happening in 2.4, and what precisely is happening in 2.5. AFAICT, it is *not* the case that Python 2.4 (indirectly) has hard-coded the names CON, PRN, NUL etc. in the C library. Instead, Python 2.4 *also* relies on kernel32 functions to determine that these files exist. My question now is what specific kernel32 functions Python 2.4 calls to determine that NUL is a file; before that question is sufficiently answered, I don't think any action should be taken. os.path.exist() in win32 just calls os.stat() and decides it doesn't exist if an error is returned. os.stat() uses the vcrt stat()in 2.4, but 2.5 implements it directly in terms of win32 api to deal with limitations in the vcrt implementation. The hand-rolled stat uses GetFileAttributesEx, which returns 0 for the special filenames, with an error code of The parameter is incorrect (87), which is why os.path.exists() claims it doesn't exist. Interestingly, plain old GetFileAttributes() works, and returns FILE_ATTRIBUTE_ARCHIVE for them. See also a recent blog entry of Raymond Chen at http://blogs.msdn.com/oldnewthing/archive/2007/10/23/5612082.aspx Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
