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 15:46 schrieb Paul Moore: On 12 February 2015 at 08:05, Thomas Heller 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] 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] 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 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] 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 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 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
[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] [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 : 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
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
[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] python 3.4 and pywin32
Am 22.03.2014 00:25, schrieb Nick Coghlan: On 22 March 2014 05:46, Thomas Heller 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
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 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
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] 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 mailto:br...@python.org>> wrote: On Thu, Mar 28, 2013 at 10:44 AM, Thomas Heller 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] 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
[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
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
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] 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] 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 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
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] will retry in 3 seconds
2009/06/01 20:20 +0200 [Broker,client] Stopping factory
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)
--- ---
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
2009/06/05 11:21 +0200 [-] Received SIGTERM, shutting down.
2009/06/05 11:21 +0200 [Broker,client] Stopping factory
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:
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] 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 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
[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] 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
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] 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
[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] 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
Re: [Python-Dev] PEP 3188: Implementation Questions
Meador Inge schrieb: > On Fri, Feb 26, 2010 at 4:08 PM, Greg Ewing > wrote: > >> 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
[Python-Dev] Fix for Lib/test/leakers/test_gestalt.py
I think this fixes the leak in Lib/test/leakers/test_gestalt.py. Index: Python/mactoolboxglue.c === --- Python/mactoolboxglue.c (revision 50522) +++ Python/mactoolboxglue.c (working copy) @@ -60,8 +60,9 @@ strncpy(buf, input, sizeof(buf) - 1); buf[sizeof(buf) - 1] = '\0'; } + Py_DECREF(rv); } - + Py_XDECREF(m); return buf; } I'm less sure about this one, but it looks like the DECREF is also required: Index: Python/mactoolboxglue.c === --- Python/mactoolboxglue.c (revision 50522) +++ Python/mactoolboxglue.c (working copy) @@ -60,8 +60,9 @@ strncpy(buf, input, sizeof(buf) - 1); buf[sizeof(buf) - 1] = '\0'; } + Py_DECREF(rv); } - + Py_XDECREF(m); return buf; } 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] Fix for Lib/test/leakers/test_gestalt.py
Thomas Heller schrieb:
> I think this fixes the leak in Lib/test/leakers/test_gestalt.py.
>
> Index: Python/mactoolboxglue.c
> ===
> --- Python/mactoolboxglue.c (revision 50522)
> +++ Python/mactoolboxglue.c (working copy)
> @@ -60,8 +60,9 @@
> strncpy(buf, input, sizeof(buf) - 1);
> buf[sizeof(buf) - 1] = '\0';
> }
> + Py_DECREF(rv);
> }
> -
> + Py_XDECREF(m);
> return buf;
> }
>
>
> I'm less sure about this one, but it looks like the DECREF
> is also required:
(Here's the patch that I *really* meant)
Index: Mac/Modules/macosmodule.c
===
--- Mac/Modules/macosmodule.c (Revision 50515)
+++ Mac/Modules/macosmodule.c (Arbeitskopie)
@@ -375,6 +375,7 @@
/* And try again... */
h = GetResource('Estr', err);
}
+ Py_DECREF(m);
}
}
/*
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] The buffer() function
I just answered a question on comp.lang.python for someone who was asking about how to convert the internal buffer of a ctypes instance into base64 coding, without too much copying: "The conversion calls in the base64 module expect strings as input, so right now I'm converting the binary blocks to strings first, then converting the resulting string to base64. This seems highly inefficient and I'd like to just go straight from binary to a base64 string." Naturally I tried to call base64.encodestring(buffer(ctypes_instance)) and it worked, so that was my answer. As it turns out the guy (unusal!) tried to look up information about the buffer function in the documentation. What he found is this: "Python programmers, trainers, students and bookwriters should feel free to bypass these functions without concerns about missing something important". Not an encouragement to use this function. So, what is the real state of the buffer() function, and the buffer object? IIUC, the buffer object was broken some time ago, but I think it has been fixed. Can the 'status' of the buffer function be changed? To quote the next question from the OP: "Is buffer safe to use? Is there an alternative?" My thinking is that it *is* safe to use, and that there is no alternative (but imo also no alternative is needed). 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] The buffer() function
Fredrik Lundh schrieb: > Thomas Heller wrote: > >> Naturally I tried to call base64.encodestring(buffer(ctypes_instance)) >> and it worked, so that was my answer. > > does ctypes_instance implement the buffer API ? if it does, is the > buffer() call even necessary ? Yes, in both cases. 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 buffer() function
Fredrik Lundh schrieb: > Thomas Heller wrote: > >>>> Naturally I tried to call base64.encodestring(buffer(ctypes_instance)) >>>> and it worked, so that was my answer. > >> >>> does ctypes_instance implement the buffer API ? if it does, is the >>> buffer() call even necessary ? >> >> Yes, in both cases. > > are you sure? does it implement the bf_getreadbuffer slot? afaik, > afaicr, and from what I can tell by looking briefly at the sources, the > binascii.b2a_base64 function uses the the s# marker, and that argument > type accepts strings *and* read only buffers, right away. no extra crud > should be necessary. Yes, for binascii.b2a_base64 you are right: bf_getreadbuffer is sufficient. For binascii.b2a_hex (for example), it is not sufficient. But that was not the question. What about the status of the buffer function? All the above functions accept a buffer object. 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 buffer() function
Josiah Carlson schrieb: > Thomas Heller <[EMAIL PROTECTED]> wrote: >> But that was not the question. What about the status of the buffer function? > >>From what I understand, it is relatively safe as long as you don't > mutate an object while there is a buffer attached to it. > > That is: > > import array > a = array.array(...) > b = buffer(a) > for i in xrange(...): > a.extend(a[:]) > print str(b) > > ... may cause you some problems (the a[:] bit was to pointer movement > movement on realloc). Those problems will depend on your platform. AFAIK, the buffer object now does not hold a pointer into the object it has been constructed from, it only gets it when its needed. IMO Objects/bufferobject.c, revision 35400 is considered safe. The checkin comment (by nascheme) was, more than 2 years ago: "Make buffer objects based on mutable objects (like array) safe." 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] Partial support for dlmodule.c in 64-bits OSes
Pierre Baillargeon schrieb: > Currently, many 64-bits Oses cannot uses the dlmodule due to the conflicts > between the sizes of int, long and char *. That is well. The check is made as > run-time, which is also very well. > > The problem is that the Python configuration script (setup.py) also makes the > check and plainly excludes dlmodule.c from being built and deployed. That is > not > so well. > > The reason is that we use the dlmodule solely to get access to the various > flags > (RTLD_NOW, RTLD_GLOBAL, etc), so that we can do some magic with loaded shared > libraries, such as over-ridding the import mechanism so that the default load > flags get changed (via sys.setdlopenflags()) to force some semantics. > > Currently this doesn't work on most 64-bits OSes because the dl module doesn't > exists, so it cannot be imported and its RTLD_* symbols are not accessible. > > So I ask if it would be possible that the test for sys.maxint == 0x7fff in > setup.py be dropped in future releases. I don't know if your patch is acceptable or not, but if it is applied Lib/test/test_dl.py crashes on 64-bit platforms, so this must be changed as well. Further, patches should be uploaded to the SF tracker so they don't get lost or forgotten. OTOH, the RTLD_ constants are possibly available in the DLFCN module, as the documentation explains. 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] os.utime and os.chmod failures (etc) Python 2.5b2
Michael Foord schrieb: > Hello all, > > There may be a reasonable cause for this (i.e. it is likely to be my > fault) - but it is consistent across two different machines I have tried > it on. > > With Python 2.5b2 (from the msi at Python.org), running on Windows XP > Pro SP2, ``os.utime`` and ``os.chmod`` fail with WindowsError. The same > code runs fine on Python 2.3 and Python 2.4. > > [err] shutil.copytree(thisentry, targetdir) > [err] File "C:\Python25\lib\shutil.py", line 130, in copytree > [err] copystat(src, dst) > [err] File "C:\Python25\lib\shutil.py", line 67, in copystat > [err] os.utime(dst, (st.st_atime, st.st_mtime)) > [err] WindowsError: [Error 13] Access is denied: 'lib\\Pmw' > [err] > > The script uses ``shutil.copytree`` to copy a directory (using relative > paths). IMO this is a bug in Python 2.5, on Windows. The problem is that the call to 'copystat(src, dst)' was added to the shutil.copytree function, in svn r38363 probably. It will fail always on Windows, since os.utime does not work on directories (as the docs correctly explain). I guess that a patch similar to this one should fix it: Index: shutil.py === --- shutil.py (Revision 50710) +++ shutil.py (Arbeitskopie) @@ -127,7 +127,12 @@ # continue with other files except Error, err: errors.extend(err.args[0]) -copystat(src, dst) +try: +copystat(src, dst) +except WindowsError: +pass +except OSError, err: +errors.extend(err.args[0]) if errors: raise Error, errors But you should report this to the bug tracker. 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] Patch for building ctypes on more OpenBSD target platforms
I've uploaded a patch sent to me in private email by Damien Miller, who is packaging ctypes for the OpenBSD port tree. I'm requesting permission to commit this for Python 2.5. http://python.org/sf/1529514 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] Releasemanager, please approve #1532975
Approval requested for patch: http://python.org/sf/1532975 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] segmentation fault in Python 2.5b3 (trunk:51066)
Ralf Schmitt schrieb:
> Hi all,
>
> I've been trying to port our software to python 2.5.
> unfortunately I'm getting constantly hit by segfaults.
>
> I've boiled it down to the following code:
>
> [EMAIL PROTECTED]:~/bug$ cat t.py
> import array
>
> class Indexer(object):
> maximumForwardSize = property(array.array.fromstring)
> [EMAIL PROTECTED]:~/bug$ python t.py
> Segmentation fault
Confirmed under Windows. Here's the problem (Objects/descrobject.c, near line
1200,
in property_init(...):
/* if no docstring given and the getter has one, use that one */
if ((doc == NULL || doc == Py_None) && get != NULL &&
PyObject_HasAttrString(get, "__doc__")) {
if (!(get_doc = PyObject_GetAttrString(get, "__doc__")))
return -1;
Py_DECREF(get_doc); /* it is INCREF'd again below */
^^
doc = get_doc;
}
Py_XINCREF(get);
Py_XINCREF(set);
Py_XINCREF(del);
Py_XINCREF(doc);
If the refcount of get_doc drops to zero in the Py_DECREF(), the Py_XINCREF()
shortly after doesn't help ;-).
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] segmentation fault in Python 2.5b3 (trunk:51066)
> /* if no docstring given and the getter has one, use that one */
> if ((doc == NULL || doc == Py_None) && get != NULL &&
> PyObject_HasAttrString(get, "__doc__")) {
> if (!(get_doc = PyObject_GetAttrString(get, "__doc__")))
> return -1;
> Py_DECREF(get_doc); /* it is INCREF'd again below */
> ^^
> doc = get_doc;
> }
>
> Py_XINCREF(get);
> Py_XINCREF(set);
> Py_XINCREF(del);
> Py_XINCREF(doc);
>
A strange programming style, if you ask me, and I wonder why Coverity doesn't
complain
about 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
Re: [Python-Dev] Releasemanager, please approve #1532975
Thomas Heller schrieb: > Approval requested for patch: > http://python.org/sf/1532975 > What does the silence mean? Should I go ahead and commit this patch? 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] Errors after running make test
There are errors now after the testsuite has finished. Taken from the very end of the amd64 test log (for example). http://www.python.org/dev/buildbot/trunk/amd64%20gentoo%20trunk/builds/1403/step-test/0 [...] 293 tests OK. 26 tests skipped: test_aepack test_al test_applesingle test_bsddb185 test_cd test_cl test_curses test_dl test_gl test_imageop test_imgfile test_linuxaudiodev test_macfs test_macostools test_nis test_ossaudiodev test_pep277 test_plistlib test_rgbimg test_scriptpackages test_startfile test_sunaudiodev test_unicode_file test_winreg test_winsound test_zipfile64 Those skips are all expected on linux2. Error in atexit._run_exitfuncs: Traceback (most recent call last): File "/home/buildslave/buildslave/python/trunk.norwitz-amd64/build/Lib/atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "/home/buildslave/buildslave/python/trunk.norwitz-amd64/build/Lib/logging/__init__.py", line 1351, in shutdown h.flush() File "/home/buildslave/buildslave/python/trunk.norwitz-amd64/build/Lib/logging/__init__.py", line 731, in flush self.stream.flush() ValueError: I/O operation on closed file Error in sys.exitfunc: Traceback (most recent call last): File "/home/buildslave/buildslave/python/trunk.norwitz-amd64/build/Lib/atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "/home/buildslave/buildslave/python/trunk.norwitz-amd64/build/Lib/logging/__init__.py", line 1351, in shutdown h.flush() File "/home/buildslave/buildslave/python/trunk.norwitz-amd64/build/Lib/logging/__init__.py", line 731, in flush self.stream.flush() ValueError: I/O operation on closed file [449107 refs] program finished with exit code 0 ___ 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 remaining issues blocking 2.5 release
Neal Norwitz schrieb: > I just updated the PEP to remove all references to issues blocking > release of 2.5. > I don't know of any. I haven't heard of any issues with the fixes > that have been checked in. > > If you have issues, respond ASAP! The release candidate is planned to > be cut this Thursday/Friday. There are only a few more days before > code freeze. A branch will be made when the release candidate is cut. What is the policy for documentation changes? Am I allowed to check in changes/additions to the ctypes docs without release manager permission after the release candidate is out? I'l always make sure that the html docs can be built. 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] ctypes and win64
The _ctypes extension module does currently not even build on Win64. I'm (slowly) working on this (for AMD64, not for itanium), but it may take a good while before it is stable - It is not even fully implemented currently. The win64 msi installer installs the ctypes package anyway, but it cannot be imported. I suggest that it should be removed from the 2.5 win64 msi installers, so that at least, when it is ready, can be installed as separate package. 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 and win64
Martin v. Löwis schrieb: > Thomas Heller schrieb: >> I suggest that it should be removed from the 2.5 win64 msi installers, so >> that >> at least, when it is ready, can be installed as separate package. > > Unfortunately, I won't be able to work on this until the release is > made. Feel free to work on it, but I suggest to just not worry about > it. > > There are many other problems with Win64 still, e.g. the test suite > doesn't pass. And tons of compiler warnings, IIRC. If the state is still experimental, IMO it should be marked as such. 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 and win64
Martin v. Löwis schrieb: > Thomas Heller schrieb: >> I suggest that it [the ctypes package] should be removed from the 2.5 win64 >> msi installers, so that >> at least, when it is ready, can be installed as separate package. > > Unfortunately, I won't be able to work on this until the release is > made. Feel free to work on it, but I suggest to just not worry about > it. Patch for Tools\msi\msi.py uploaded, and assigned to you. http://python.org/sf/1545507 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] Exceptions and slicing
Is it an oversight that exception instances do no longer support
slicing in Python 2.5?
This code works in 2.4, but no longer in 2.5:
try:
open("", "r")
except IOError, details:
print details[:]
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] Exceptions and slicing
Brett Cannon schrieb:
> On 9/20/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
>>
>> Is it an oversight that exception instances do no longer support
>> slicing in Python 2.5?
>>
>> This code works in 2.4, but no longer in 2.5:
>>
>> try:
>> open("", "r")
>> except IOError, details:
>> print details[:]
>
>
> Technically, yes. There is no entry in the sq_slice field for the
> PySequenceMethods struct. Although you can get to the list of arguments by
> going through the 'args' attribute if you need a quick fix.
Well, Nick Coghlan pointed out in private email:
>> According to PEP 352 it should have at most been deprecated along with the
>> rest of Exception.__getitem__:
>>
>> "This also means providing a __getitem__ method is unneeded for exceptions
>> and
>> thus will be deprecated as well."
> I have a fix in my checkout that I will check into the trunk shortly and
> into 25-maint as soon as Anthony unfreezes it.
I was not aware before I posted that tuple-unpacking of exceptions still works,
so this is another possibility:
except WindowsError, (errno, message):
What I find worse about WindowsError especially is two things:
1. The __str__ of a WindowsError instance hides the 'real' windows
error number. So, in 2.4 "print error_instance" would print
for example:
[Errno 1002] Das Fenster kann die gesendete Nachricht nicht verarbeiten.
while in 2.5:
[Error 22] Das Fenster kann die gesendete Nachricht nicht verarbeiten.
because the new mapping of windows error codes to posix error codes creates
EINVAL (22) when no corresponding posix error code exists.
2. How would one write portable exception handling for Python 2.4 and 2.5?
I have code like this:
try:
do something
except WindowsError, details:
if not details.errno in (TYPE_E_REGISTRYACCESS, TYPE_E_CANTLOADLIBRARY):
raise
Doesn't work in 2.5 any longer, because I would have to use details.winerror
instead of e.errno.
The two portale possibilities I found are these, but neither is elegant imo:
except WindowsError, (winerrno, message):
or
except WindowsError, details:
winerrno = details[0]
And the latter still uses __getitem__ which may go away according to PEP 352.
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] Exceptions and slicing
Martin v. Löwis schrieb: > Thomas Heller schrieb: >> 1. The __str__ of a WindowsError instance hides the 'real' windows >> error number. So, in 2.4 "print error_instance" would print >> for example: >> >> [Errno 1002] Das Fenster kann die gesendete Nachricht nicht verarbeiten. >> >> while in 2.5: >> >> [Error 22] Das Fenster kann die gesendete Nachricht nicht verarbeiten. > > That's a bug. I changed the string deliberately from Errno to error to > indicate that it is not an errno, but a GetLastError. Can you come up > with a patch? Yes, but not today. >> 2. How would one write portable exception handling for Python 2.4 and 2.5? >> > Portable code should do > > def winerror(exc): > try: > return exc.winerror > except AttributeError: #2.4 and earlier > return exc.errno > > and then > > try: > do something > except WindowsError, details: > if not winerror(details) in (TYPE_E_REGISTRYACCESS, > YPE_E_CANTLOADLIBRARY): > raise Ok (sigh ;-). 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] Small Py3k task: fix modulefinder.py
Guido van Rossum schrieb: > Is anyone familiar enough with modulefinder.py to fix its breakage in > Py3k? It chokes in a nasty way (exceeding the recursion limit) on the > relative import syntax. I suspect this is also a problem for 2.5, when > people use that syntax; hence the cross-post. There's no unittest for > modulefinder.py, but I believe py2exe depends on it (and of course > freeze.py, but who uses that still?) > I'm not (yet) using relative imports in 2.5 or Py3k, but have not been able to reproduce the recursion limit problem. Can you describe the package that fails? 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] Relative import bug?
Consider a package containing these files: a/__init__.py a/b/__init__.py a/b/x.py a/b/y.py If x.py contains this: """ from ..b import y import a.b.x from ..b import x """ Python trunk and Python 2.5 both complain: Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import a.b.x Traceback (most recent call last): File "", line 1, in File "a\b\x.py", line 2, in from ..b import x ImportError: cannot import name x >>> 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] Relative import bug?
Phillip J. Eby schrieb: > At 08:10 PM 9/22/2006 +0200, Thomas Heller wrote: >>If x.py contains this: >> >>""" >>from ..b import y >>import a.b.x >>from ..b import x >>""" ... >>ImportError: cannot import name x >> >>> >> >>A bug? > > If it is, it has nothing to do with relative importing per se. Note that > changing it to "from a.b import x" produces the exact same error. > > This looks like a "standard" circular import bug. Of course. 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] difficulty of implementing phase 2 of PEP 302 in Python source
Phillip J. Eby schrieb: > At 11:25 AM 9/28/2006 -0700, Brett Cannon wrote: >>I will think about it, but I am still trying to get the original question >>of how bad the C code is compared to rewriting import in Python from >>people. =) > > I would say that the C code is *delicate*, not necessarily bad. In most > ways, it's rather straightforward, it's actually the requirements that are > complex. :) > > A Python implementation, however, would be a good idea to have around for > PyPy, Py3K, and other versions of Python, and as a refactoring basis for > writing any new C code. FYI, Gordon McMillan had a Python 'model' of the import mechanism in his, (not sure if it was really named) "iu.py". It was part of his installer utility, maybe the code still lives in the PyInstaller project. IIRC, parts of pep 302 were inspired by his code. 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] Exceptions and slicing
Thomas Heller schrieb: > Martin v. Löwis schrieb: >> Thomas Heller schrieb: >>> 1. The __str__ of a WindowsError instance hides the 'real' windows >>> error number. So, in 2.4 "print error_instance" would print >>> for example: >>> >>> [Errno 1002] Das Fenster kann die gesendete Nachricht nicht verarbeiten. >>> >>> while in 2.5: >>> >>> [Error 22] Das Fenster kann die gesendete Nachricht nicht verarbeiten. >> >> That's a bug. I changed the string deliberately from Errno to error to >> indicate that it is not an errno, but a GetLastError. Can you come up >> with a patch? > > Yes, but not today. I submitted a patch for this issue: http://python.org/sf/1576174 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.3.6 for the unicode buffer overrun
Martin v. Löwis schrieb: > Anthony Baxter schrieb: >> Mostly it is easy for me, with the one huge caveat. As far as I know, the >> Mac >> build is a single command to run for Ronald, and the Doc build similarly for >> Fred. I don't know what Martin has to do for the Windows build. > > Actually, for 2.3.x, I wouldn't do the Windows builds. I think Thomas > Heller did the 2.3.x series. Yes. But I've switched machines since I last build an installer, and I do not have all of the needed software installed any longer, for example the Wise Installer. 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] Modulefinder
I have patched Lib/modulefinder.py to work with absolute and relative imports. It also is faster now, and has basic unittests in Lib/test/test_modulefinder.py. The work was done in a theller_modulefinder SVN branch. If nobody objects, I will merge this into trunk, and possibly also into release25-maint, when I have time. 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 and win64
Thomas Heller schrieb (this was before Python 2.5 had been released): > The _ctypes extension module does currently not even build on Win64. > > I'm (slowly) working on this (for AMD64, not for itanium), but it may > take a good while before it is stable - It is not even fully implemented > currently. > > The win64 msi installer installs the ctypes package anyway, but it cannot be > imported. > > I suggest that it should be removed from the 2.5 win64 msi installers, so that > at least, when it is ready, can be installed as separate package. Then, Martin changed the win64 msi installer to exclude the ctypes package when the _ctypes.pyd extension does not exist because it was not built. In the meantime I have integrated patches (in the trunk) so that _ctypes can be built for win64/AMD64, and does even work. Can these changes be merged into release25-maint? IMO this is low-risk because they contain only small changes to the files in Modules/_ctypes/libffi_msvc, plus *some* changes to support the Windows LP64 model. I would prefer to merge these changes into release25-maint, because I want to also release the standalone ctypes packages from this branch (using it with svn:externals from somewhere else). The official Python 2.5.x win64/AMD64 windows installers should still *not* contain the ctypes package, but they could install it separately. 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 and win64
[Resent after subscribing to python-dev with this new email address, sorry if it appears twice] Thomas Heller schrieb (this was before Python 2.5 had been released): > > The _ctypes extension module does currently not even build on Win64. > > > > I'm (slowly) working on this (for AMD64, not for itanium), but it may > > take a good while before it is stable - It is not even fully implemented > > currently. > > > > The win64 msi installer installs the ctypes package anyway, but it cannot be > > imported. > > > > I suggest that it should be removed from the 2.5 win64 msi installers, so > > that > > at least, when it is ready, can be installed as separate package. Then, Martin changed the win64 msi installer to exclude the ctypes package when the _ctypes.pyd extension does not exist because it was not built. In the meantime I have integrated patches (in the trunk) so that _ctypes can be built for win64/AMD64, and does even work. Can these changes be merged into release25-maint? IMO this is low-risk because they contain only small changes to the files in Modules/_ctypes/libffi_msvc, plus *some* changes to support the Windows LP64 model. I would prefer to merge these changes into release25-maint, because I want to also release the standalone ctypes packages from this branch (using it with svn:externals from somewhere else). The official Python 2.5.x win64/AMD64 windows installers should still *not* contain the ctypes package, but they could install it separately. 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 and win64
Martin v. Löwis schrieb: > Thomas Heller schrieb: [I was talking about patches to make ctypes work on 64-bit windows] >> I would prefer to merge these changes into release25-maint, because I want to >> also release the standalone ctypes packages from this branch (using it with >> svn:externals from somewhere else). > > That's not a good reason for back-porting. If you want a "maintenance" > branch for ctypes, feel free to create one in the subversion, likewise > for tags. > > OTOH, I can't comment on whether those changes would be acceptable for > a backport to the 2.5 maintenance branch - if they don't introduce > actual new features, it might be ok. > >> The official Python 2.5.x win64/AMD64 windows installers should still *not* >> contain the ctypes package, but they could install it separately. > > I don't really understand. Are you planning to back-port PCbuild changes > also? If so, how should including those extensions be suppressed? Let me try to put it in different words. The official Python-2.5.amd64.msi does *not* contain ctypes, so the official Python-2.5.x.amd64.msi should also not contain ctypes (I assume). Not many people (I assume again) are running 64-bit windows, and use the 64-bit Python version - but that will probably change soon. I would like to merge the 64-bit windows related ctypes changes in trunk, as soon as I'm sure that they work, back into the release25-maint branch. And also make separate ctypes releases from the release25-maint source code. I will only backport these changes if I'm convinced that they do not change the functionality of tehe current code. This way win64 Python users could install ctypes from the separate release. Also this way the source code for ctypes in the separate and the Python bundled releases are exactly the same, without creating too much work because of the different repositories. Hope that makes the plan clear, 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] Modulefinder
> On 10/13/06, Thomas Heller <[EMAIL PROTECTED]> wrote: >> I have patched Lib/modulefinder.py to work with absolute and relative >> imports. >> It also is faster now, and has basic unittests in >> Lib/test/test_modulefinder.py. >> >> The work was done in a theller_modulefinder SVN branch. >> If nobody objects, I will merge this into trunk, and possibly also into >> release25-maint, when I have time. > Guido van Rossum schrieb: > Could you also prepare a patch for the p3yk branch? It's broken there too... > I'm currently looking into this now. IIUC, 'import foo' is an absolute import now - is this the only change to the import machinery? 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] Modulefinder
> On 10/13/06, Thomas Heller <[EMAIL PROTECTED]> wrote: >> I have patched Lib/modulefinder.py to work with absolute and relative >> imports. >> It also is faster now, and has basic unittests in >> Lib/test/test_modulefinder.py. >> >> The work was done in a theller_modulefinder SVN branch. >> If nobody objects, I will merge this into trunk, and possibly also into >> release25-maint, when I have time. > Guido van Rossum schrieb: > Could you also prepare a patch for the p3yk branch? It's broken there too... > Patch uploaded, and assigned to you. http://www.python.org/sf/1585966 Oh, and BTW: py3k SVN doesn't compile under windows. 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: Adding data-type objects to Python
Travis Oliphant schrieb: > Greg Ewing wrote: >> Travis Oliphant wrote: >> >> >>>Part of the problem is that ctypes uses a lot of different Python types >>>(that's what I mean by "multi-object" to accomplish it's goal). What >>>I'm looking for is a single Python type that can be passed around and >>>explains binary data. >> >> >> It's not clear that multi-object is a bad thing in and >> of itself. It makes sense conceptually -- if you have >> a datatype object representing a struct, and you ask >> for a description of one of its fields, which could >> be another struct or array, you would expect to get >> another datatype object describing that. >> >> Can you elaborate on what would be wrong with this? >> >> Also, can you clarify whether your objection is to >> multi-object or multi-type. They're not the same thing -- >> you could have a data structure built out of multiple >> objects that are all of the same Python type, with >> attributes distinguishing between struct, array, etc. >> That would be single-type but multi-object. > > I've tried to clarify this in another post. Basically, what I don't > like about the ctypes approach is that it is multi-type (every new > data-format is a Python type). > > In order to talk about all these Python types together, then they must > all share some attribute (or else be derived from a meta-type in C with > a specific function-pointer entry). (I tried to read the whole thread again, but it is too large already.) There is a (badly named, probably) api to access information about ctypes types and instances of this type. The functions are PyObject_stgdict(obj) and PyType_stgdict(type). Both return a 'StgDictObject' instance or NULL if the funtion fails. This object is the ctypes' type object's __dict__. StgDictObject is a subclass of PyDictObject and has fields that carry information about the C type (alignment requirements, size in bytes, plus some other stuff). Also it contains several pointers to functions that implement (in C) struct-like functionality (packing/unpacking). Of course several of these fields can only be used for ctypes-specific purposes, for example a pointer to the ffi_type which is used when calling foreign functions, or the restype, argtypes, and errcheck fields which are only used when the type describes a function pointer. This mechanism is probably a hack because it'n not possible to add C accessible fields to type objects, on the other hand it is extensible (in principle, at least). Just to describe the implementation. 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: Adding data-type objects to Python
Travis Oliphant schrieb: > For example, I'm pretty sure you were the one who made me aware that you > can't just extend the PyTypeObject. Instead you extended the tp_dict of > the Python typeObject to store some of the extra information that is > needed to describe a data-type like I'm proposing. > > So, if you I'm just describing data-format information, why do I need > all this complexity (that makes ctypes implementation easier/more > natural/etc)? What if the StgDictObject is the Python data-format > object I'm talking about? It actually looks closer. > > But, if all I want is the StgDictObject (or something like it), then why > should I pass around the whole type object? Maybe you don't need it. ctypes certainly needs the type object because it is also used for constructing instances (while NumPy uses factory functions, IIUC), or for converting 'native' Python object into foreign function arguments. I know that this doesn't interest you from the NumPy perspective (and I don't want to offend you by saying this). > This is all I'm saying to those that want me to use ctypes to describe > data-formats in the extended buffer protocol. I'm not trying to change > anything in ctypes. I don't want to change anything in NumPy, either, and was not the one who suggested to use ctypes objects, although I had thought about whether it would be possible or not. What I like about ctypes, and dislike about Numeric/Numarry/NumPy is the way C compatible types are defined in ctypes. I find the ctypes way more natural than the numxxx or array module way, but what else would anyone expect from me as the ctypes author... I hope that a useful interface is developed from your proposals, and will be happy to adapt ctypes to use it or interface ctypes with it if this makes sense. 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] idea for data-type (data-format) PEP
Travis E. Oliphant schrieb: > Travis E. Oliphant wrote: >> Thanks for all the comments that have been given on the data-type >> (data-format) PEP. I'd like opinions on an idea for revising the PEP I >> have. > >> >> 1) We could define a special string-syntax (or list syntax) that covers >> every special case. The array interface specification goes this >> direction and it requires no new Python types. This could also be seen >> as an extension of the "struct" module to allow for nested structures, etc. >> >> 2) We could define a Python object that specifically carries data-format >> information. >> >> >> Does that explain the goal of what I'm trying to do better? > > In other-words, what I'm saying is I really want a PEP that does this. > Could we have a discussion about what the best way to communicate > data-format information across multiple extension modules would look > like. I'm not saying my (pre-)PEP is best. The point of putting it in > it's infant state out there is to get the discussion rolling, not to > claim I've got all the answers. IIUC, so far the 'data-object' carries information about the structure of the data it describes. Couldn't it go a step further and have also some functionality? Converting the data into a Python object and back? This is what the ctypes SETFUNC and GETFUNC functions do, and what also is implemented in the struct 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] PEP: Adding data-type objects to Python
Ronald Oussoren schrieb: > On Oct 31, 2006, at 6:38 PM, Thomas Heller wrote: > >> >> This mechanism is probably a hack because it'n not possible to add >> C accessible >> fields to type objects, on the other hand it is extensible (in >> principle, at least). > > I better start rewriting PyObjC then :-). PyObjC stores some addition > information in the type objects that are used to describe Objective-C > classes (such as a reference to the proxied class). > > IIRC This has been possible from Python 2.3. I assume you are referring to the code in pyobjc/Modules/objc/objc-class.h ? If this really is reliable I should better start rewriting ctypes then ;-). Hm, I always thought there was some additional magic going on with type objects, fields appended dynamically at the end or whatever. 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] __dir__, part 2
Fredrik Lundh schrieb: > Guido van Rossum wrote: > >> No objection on targetting 2.6 if other developers agree. Seems this >> is well under way. good work! > > given that dir() is used extensively by introspection tools, I'm > not sure I'm positive to a __dir__ that *overrides* the standard > dir() behaviour. *adding* to the default dir() list is okay, re- > placing it is a lot more questionable. One part that *I* would like about a complete overridable __dir__ implementation is that it would be nice to customize what help(something) prints. 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] ctypes and powerpc
I'd like to ask for help with an issue which I do not know how to solve. Please see this bug http://python.org/sf/1563807 "ctypes built with GCC on AIX 5.3 fails with ld ffi error" Apparently this is a powerpc machine, ctypes builds but cannot be imported because of undefined symbols like 'ffi_call', 'ffi_prep_closure'. These symbols are defined in file Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c. The whole contents of this file is enclosed within a #ifdef __ppc__ ... #endif block. IIRC, this block has been added by Ronald for the Mac universal build. Now, it seems that on the AIX machine the __ppc__ symbols is not defined; removing the #ifdef/#endif makes the built successful. We have asked (in the SF bug tracker) for the symbols that are defined; one guy has executed 'gcc -v -c empty.c' and posted the output, as far as I see these are the symbols defined in gcc: -D__GNUC__=2 -D__GNUC_MINOR__=9 -D_IBMR2 -D_POWER -D_AIX -D_AIX32 -D_AIX41 -D_AIX43 -D_AIX51 -D_LONG_LONG -D_IBMR2 -D_POWER -D_AIX -D_AIX32 -D_AIX41 -D_AIX43 -D_AIX51 -D_LONG_LONG -Asystem(unix) -Asystem(aix) -D__CHAR_UNSIGNED__ -D_ARCH_COM What should we do now? Should the conditional be changed to #if defined(__ppc__) || defined(_POWER) or should we suggest to add '-D__ppc__' to the CFLAGS env var, or what? Any suggestions? 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 and powerpc
Thomas Heller schrieb: > I'd like to ask for help with an issue which I do not know > how to solve. > > Please see this bug http://python.org/sf/1563807 > "ctypes built with GCC on AIX 5.3 fails with ld ffi error" > > Apparently this is a powerpc machine, ctypes builds but cannot be imported > because of undefined symbols like 'ffi_call', 'ffi_prep_closure'. > > These symbols are defined in file > Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c. > The whole contents of this file is enclosed within a > > #ifdef __ppc__ > ... > #endif > > block. IIRC, this block has been added by Ronald for the > Mac universal build. Now, it seems that on the AIX machine > the __ppc__ symbols is not defined; removing the #ifdef/#endif > makes the built successful. Of course, the simple solution would be to change it to: #ifndef __i386__ ... #endif 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 and powerpc
Ronald Oussoren schrieb: > > On Friday, November 24, 2006, at 08:21PM, "Thomas Heller" <[EMAIL PROTECTED]> > wrote: >>I'd like to ask for help with an issue which I do not know >>how to solve. >> >>Please see this bug http://python.org/sf/1563807 >>"ctypes built with GCC on AIX 5.3 fails with ld ffi error" >> >>Apparently this is a powerpc machine, ctypes builds but cannot be imported >>because of undefined symbols like 'ffi_call', 'ffi_prep_closure'. >> >>These symbols are defined in file >> Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c. >>The whole contents of this file is enclosed within a >> >>#ifdef __ppc__ >>... >>#endif >> >>block. IIRC, this block has been added by Ronald for the >>Mac universal build. Now, it seems that on the AIX machine >>the __ppc__ symbols is not defined; removing the #ifdef/#endif >>makes the built successful. > > The defines were indeed added for the universal build and I completely > overlooked the fact that ffi_darwin.c is also used for AIX. One way to fix > this is > > #if ! (defined(__APPLE__) && !defined(__ppc__)) > ... > #endif > > That is, compile the file unless __APPLE__ is defined but __ppc__ isn't. This > more clearly documents the intent. Yes, this makes the most sense. I've taken this approach. 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] Adding C99 bool to struct module
Martin v. Löwis schrieb: > #1610575 suggests to introduce the 't' code to support the _Bool > type where available, and uses char if it isn't available. > > Any objections to adding it? Not from me, although the patch should probably be extended to add a ctypes.c99_bool (or how it would be named) type - see also the comments that I posted to the tracker. 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] MSI being downloaded 10x more than all other files?!
Guido van Rossum schrieb: > I looked through the python.org web stats (as I usually do when > preparing for a keynote) and discovered that > /ftp/python/2.5/python-2.5.msi is by far the top download -- 271,971 > hits, more than 5x the next one, /ftp/python/2.5/Python-2.5.tgz > (47,898 hits). Are these numbers real? (The byte counts suggest they > are.) You probably have to add the downloads for /ftp/python/2.5/Python-2.5.tar.bz2 (31,492 hits) to the last number. Also interesting are the hits for 64-bit windows Pythons: /ftp/python/2.5/python-2.5.amd64.msi (23192 hits) /ftp/python/2.5/python-2.5.ia64.msi (22523 hits) > What could cause this dramatic popularity of Python on Windows? Have the ratios changed against past figures (too lazy to look them up now)? > Does some vendor have an auto-install hook that installs Python > whenever someone opens up their new computer? Or have we just hit the > jackpot? > 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] Pythn 2.5 buildbots do not build anymore?
Why don't the Python 2.5 buildbots build anymore? http://www.python.org/dev/buildbot/2.5/ 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] Summary: rejection of 'dynamic attribute' syntax
Steve Holden schrieb: > Ben North wrote: > [...] >> Guido van Rossum wrote: >>> I missed discussion of the source of the 1%. Does it slow down pystone >>> or other benchmarks by 1%? That would be really odd, since I can't >>> imagine that the code path changes in any way for code that doesn't >>> use the feature. Is it that the ceval main loop slows down by having >>> two more cases? >> >> That seems to be it, yes. I tested this by leaving the grammar, >> compilation, and AST changes in, and conditionally compiling just the >> three extra cases in the ceval main loop. Measurements were noisy >> though, as Josiah Carlson has also experienced: >> >>> I've found variations of up to 3% in benchark times that seemed to be >>> based on whether I was drinking juice or eating a scone while working. >> >> I'm afraid I can't remember what I was eating or drinking at the time I >> did my tests. >> > A further data point is that modern machines seem to give timing > variabilities due to CPU temperature variations even if you always eat > exactly the same thing. > > One of the interesting facts to emerge from the Need for Speed sprint > last year is that architectural complexities at many levels make it > extremely difficult nowadays to build a repeatable benchmark of any kind. My personal experience using a dual core machine (on WinXP) is that timing results become much more reproducible. 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] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)
[EMAIL PROTECTED] schrieb: > On 02:20 am, [EMAIL PROTECTED] wrote: > >> If Twisted is designed so that it absolutely *has* to use its own >> special event mechanism, and everything else needs to be modified >> to suit its requirements, then it's part of the problem, not part >> of the solution. > > I've often heard this complaint, usually of the form "that's > twisted-specific". The thing is, Twisted isn't specific. Its event > mechanism isn't "special". In fact it's hard to imagine how it might > be made less "special" than it currently is. > > Whatever your event dispatch mechanism, *some* code has to be > responsible for calling the OS API of select(), > WaitForMultipleEvents(), g_main_loop_run(), or whatever. Twisted > actually imposes very few requirements for code to participate in > this, and was designed from day one specifically to be a generalized > mainloop mechanism which would not limit you to one underlying > multiplexing implementation, event-dispatch mechanism, or operating > system if you used its API. When I last looked at twisted (that is several years ago), there were several reactors - win32reactor, wxreactor, maybe even more. And they didn't even work too well. The problems I remember were that the win32reactor was limited to a only handful of handles, the wxreactor didn't process events when a wx modal dialog boy was displayed, and so on. Has this changed? 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] Patch 1644818: Allow importing built-in submodules
Phillip J. Eby schrieb: > At 11:50 PM 3/12/2007 +0100, Martin v. Löwis wrote: >>Does distutils support this kind of setup? Modules/Setup? > > distutils does, and has from its inception, as far as I know. > > >>IOW, I would expect that there are sooo many places where extension >>modules in packages are not supported > > The only thing I know of that doesn't support it very well is py2exe, > actually. PEAK has had extensions modules in subpackages for many years > now, and never run into any problems. In fact, py2exe's only problem with > it is that it still requires such modules to have globally unique names -- > you can't have both a foo.speedups extension and a bar.speedups > extension. (This actually happened with RuleDispatch and PyProtocols; I > ended up renaming them to _p_speedups and _d_speedups to better support > py2exe users.) > It is kind of funny that I contributed a patch to the McMillan installer to support extension modules in packages years ago, but never bothered to implement that in py2exe. If anyone contributes a patch for py2exe, I can integrate 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
Re: [Python-Dev] RELEASED Python 2.5.1, release candidate 1
Anthony Baxter schrieb: > On behalf of the Python development team and the Python community, > I'm happy to announce the release of Python 2.5.1 (release > candidate 1). > On the 2.5.1 page http://www.python.org/download/releases/2.5.1/ several things are wrong: - The download link for the AMD64 windows installer is missing; probably http://www.python.org/ftp/python/2.5.1/python-2.5.1c1.amd64.msi - The links in the last section (Files, MD5 checksums, signatures and sizes) are all wrong. Example: http://www.python.org/ftp/python/python-2.5.1c1.amd64.msi/Python-2.5.1c1.tgz 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] SystemErrors in generator (just happened in 2.5)
>> *** The following messages occur in other successful tests too:
>> a DOS box should flash briefly ...
>
> Always happens in test_subprocess, during the Windows-specific
> test_creationflags. This is expected. When you /watch/ the tests
> running on Windows, it's intended to prevent panic when a mysterious
> DOS box appears ;-)
>
>> find_library('c') -> None
>> find_library('m') -> None
>
> Mysterious. Looks like debug/trace(!) output while running
> Lib/ctypes/test/test_loading.py's test_find().
I enabled these prints to have a way to examine what find_library() returns
on the buildbots, without checking for a certain result in a test.
Should these prints be removed 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] x64 and the testsuite
Kristján Valur Jónsson schrieb:
> Hello again.
> A lot of overflow tests fail in the testsuite, by expecting overflow using
> sys.maxint.
> for example this line, 196, in test_index.py:
> self.assertEqual(x[self.neg:self.pos], (-1, maxint))
On my (virtual) win64-machine, which has less than 1GB, quite some tests fail
with MemoryError.
The tests pass on 64-bit linux machines, though.
> At the moment, I am disabling these tests with
> if "64 bit" not in sys.version:
>
> So, two questions: Should we add something like sys.maxsize to keep these
> overflow tests valid?
>
> Also, some tests just kill the computer when given large values, that are
> expected to overflow. Sometimes
> it would be good to test for a 64 bit machine with virtually infinite ram.
> Is there a better way
> than the "64 bit" in sys.version test? Should we have something like
> sys.bits?
You can use 'struct.calcsize("P")' to find out the pointer size.
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] \u and \U escapes in raw unicode string literals
M.-A. Lemburg schrieb:
> On 2007-05-11 07:52, Martin v. Löwis wrote:
>>> This is what prompted my question, actually: in Py3k, in the
>>> str/unicode unification branch, r"\u1234" changes meaning: before the
>>> unification, this was an 8-bit string, where the \u was not special,
>>> but now it is a unicode string, where \u *is* special.
>>
>> That is true for non-raw strings also: the meaning of "\u1234" also
>> changes.
>>
>> However, traditionally, there was *no* escaping mechanism in raw strings
>> in Python, and I feel that this is a good principle, because it is
>> easy to learn (if you leave out the detail that \ can't be the last
>> character in a raw string - which should get fixed also, IMO). So I
>> think in Py3k, "\u1234" should continue to be a string with 6
>> characters. Otherwise, people will complain that
>> os.stat(r"c:\windows\system32\user32.dll") fails. Telling them to write
>> os.stat(r"c:\windows\system32\u005Cuser32.dll") will just cause puzzled
>> faces.
>
> Using double backslashes won't cause that reaction:
>
> os.stat("c:\\windows\\system32\\user32.dll")
Sure. But I want to use raw strings for Windows path names; it's much easier
to type.
> Also note that Windows is smart enough nowadays to parse
> the good old Unix forward slash:
>
> os.stat("c:/windows/system32/user32.dll")
In my opinion this is a windows bug and not a features. Especially because
there
are Windows api functions (the shell functions, IIRC) that do NOT accept
forward slashes.
Would you say that *nix is dumb because it doesn't parse "\\usr\\include"?
>> Windows path names are one of the two primary applications of raw
>> strings (the other being regexes).
>
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] Embedded Python startup is slow
Am 24.03.2011 12:18, schrieb "Martin v. Löwis": 1. Is there anything I can do at compile time to tell Python these files don't exist and avoid trying to open them? If you disable dynamic loading of extension modules, the number of stat calls will go down significantly. 2. Is it possible to make python first try and open the ".pyc" and only then look for ".py" ? If you then further reduce sys.path, and zip up the standard library .pyc files, you get further reductions. On my embedded ARM system (400MHz ARM926EJ-S, linux 2.6.38) Python starts up even slower when the standard library is in a zip-file. The effect is worse when the zip-file is compressed, but the slow-down is still there if the zip-file is not compressed. 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] Embedded Python startup is slow
Am 24.03.2011 16:58, schrieb bruce bushby: My main concern was that a freshly compiled Python attempts to open 168 non-existent files before starting. I understand that an interpreted language is probably not the best choice for an embedded device (although it's very nice for prototyping) , Python really should know what exists after it's just been compiledie before any corrupting modules or other nonsense has been added. It appears it is hard coded to open these files regardless of any "configure" options. On my desktop pc, when I run the most simple "Hello World" 78% of the overall execution time is spent opening filesmost of which don't exist. Some form of "cache" would help the startup time on the "second go" . but arguably just a "band aid" covering a deeper problem. So maybe you should try to come up with a patch, to find out if the cache helps? ___ 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 (Was: buildbot failure in x86 W2k trunk)
Trent Mick schrieb: > http://www.python.org/dev/buildbot/all/x86%20W2k%20trunk > > Is my buildbot the only reliable Windows buildbot machine? > It is possible that within a couple of weeks or so I'll have to take > this one offline. > > Are there others that can provide a Windows buildbot? It would probably > be good to have two -- and a WinXP one would be good. How much work is it to set one up, and to maintain it? Maybe I can offer an XP VMWare image. 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 (Was: buildbot failure in x86 W2k trunk)
>> Are there others that can provide a Windows buildbot? It would probably >> be good to have two -- and a WinXP one would be good. > > It certainly would be good. Unfortunately, Windows users are not that > much engaged in the open source culture, so few of them volunteer > (plus it's more painful, with Windows not being a true multi-user > system). I'll try to setup a buildbot under WinXP. Whom do I contact to get HOST:PORT and PASSWORD ? 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 (Was: buildbot failure in x86 W2k trunk)
Thomas Heller schrieb: >>> Are there others that can provide a Windows buildbot? It would probably >>> be good to have two -- and a WinXP one would be good. >> >> It certainly would be good. Unfortunately, Windows users are not that >> much engaged in the open source culture, so few of them volunteer >> (plus it's more painful, with Windows not being a true multi-user >> system). > > I'll try to setup a buildbot under WinXP. The buildbot is now working. 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 (Was: buildbot failure in x86 W2k trunk)
Thomas Heller schrieb: > Thomas Heller schrieb: >>>> Are there others that can provide a Windows buildbot? It would probably >>>> be good to have two -- and a WinXP one would be good. >>> >>> It certainly would be good. Unfortunately, Windows users are not that >>> much engaged in the open source culture, so few of them volunteer >>> (plus it's more painful, with Windows not being a true multi-user >>> system). >> >> I'll try to setup a buildbot under WinXP. > > The buildbot is now working. Should I try to setup another buildbot client for win32/AMD64? 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 (Was: buildbot failure in x86 W2k trunk)
Martin v. Löwis schrieb: >> Should I try to setup another buildbot client for win32/AMD64? > > We don't have a Win64 buildbot yet. Depending on whether you plan > to use PCbuild or PCbuild8, this might be a challenge to get working > (I think it's a challenge either way, but different). > If it could actually work, it might be useful. For release25-maint, probably PCBuild should be used since that is used to create the installer. For trunk/Python 2.6 I don't know what you will use for the release version. Where do you think is the challange to get it working? For the buildbot client itself I would use the same stuff as in the WinXP buildbot (32-bit python2.4, twisted, buildbot, pywin32). For the build scripts in Tools\buildbot I made some small changes to the batch files (appended). They look for a PROCESSOR_ARCHITECTURE env var, and if this is equal to AMD64 the build target and one or two small other things are changed from the default. So these scripts currently build the PCBuild process. I can run Tools\buildbot\build.bat, then Tools\buildbot\test.bat, and Tools\buildbot\clean.bat successfully. Of course this does not mean that *everything* is built correctly - currently _sqlite3, bz2, _tkinter, and _ssl are not build because of several reasons. If you want me to go online with the buildbot please send me a HOST:PORT and PASSWORD. Thomas Index: Tools/buildbot/build.bat === --- Tools/buildbot/build.bat(revision 55792) +++ Tools/buildbot/build.bat(working copy) @@ -2,4 +2,6 @@ cmd /c Tools\buildbot\external.bat call "%VS71COMNTOOLS%vsvars32.bat" cmd /q/c Tools\buildbot\kill_python.bat -devenv.com /useenv /build Debug PCbuild\pcbuild.sln +set TARGET=Debug +if "%PROCESSOR_ARCHITECTURE%" == "AMD64" set _TARGET=ReleaseAMD64 +devenv.com /useenv /build %_TARGET% PCbuild\pcbuild.sln Index: Tools/buildbot/test.bat === --- Tools/buildbot/test.bat (revision 55792) +++ Tools/buildbot/test.bat (working copy) @@ -1,3 +1,5 @@ @rem Used by the buildbot "test" step. cd PCbuild -call rt.bat -d -q -uall -rw +set _DEBUG=-d +if "%PROCESSOR_ARCHITECTURE%"=="AMD64" set _DEBUG= +call rt.bat %_DEBUG% -q -uall -rw Index: Tools/buildbot/clean.bat === --- Tools/buildbot/clean.bat(revision 55792) +++ Tools/buildbot/clean.bat(working copy) @@ -2,5 +2,9 @@ call "%VS71COMNTOOLS%vsvars32.bat" cd PCbuild @echo Deleting .pyc/.pyo files ... -python_d.exe rmpyc.py -devenv.com /clean Debug pcbuild.sln +set _PYTHON=python_d.exe +if "%PROCESSOR_ARCHITECTURE%"=="AMD64" set _PYTHON=python.exe +%_PYTHON% rmpyc.py +set TARGET=Debug +if "%PROCESSOR_ARCHITECTURE%" == "AMD64" set TARGET=ReleaseAMD64 +devenv.com /clean %TARGET% pcbuild.sln ___ 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] Need help fixing failing Py3k Unittests in py3k-struni
Christian Heimes schrieb: > > By the way the ctypes unit tests are causing a segfault on my machine: > test_ctypes > Warning: could not import ctypes.test.test_numbers: unpack requires a > string argument of length 1 > Segmentation fault > > Ubunutu 7.04 on i386 machine with an Intel P3. I can reproduce this. ctypes.test.test_numbers is easy to fix, but there are other severe problems with ctypes. I would love to look into these, but I prefer debugging on Windows. However, the windows build does not work because the _fileio builtin module is missing from config.c. Again, this is not so easy to fix, because the ftruncate function does not exist on Windows. 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] adding a "test" fork to a setup.py package
Barry Warsaw schrieb: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Sep 11, 2007, at 2:12 PM, Bill Janssen wrote: > >> I'm packaging up the SSL support for Python 2.3, and I'd like to be >> able to include the unit test for it along with the package. Ideally, >> I'd like to be able to say >> >> % python setup.py build >> % python setup.py test >> >> and have the regrtest.py module run my tests. Any ideas (examples) of >> how to do that? > > The email package does something like this by having most of the > tests in a subpackage of enum, with a shim in Lib/test for regrtest. > The standalone package has a testall script, but that should really > be converted to nosetests or some such. ctypes does it in a similar way. Tests are in the Lib/ctypes/test package. 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] Decimal news
Thomas Wouters schrieb: > On 9/27/07, Eric Smith <[EMAIL PROTECTED]> wrote: >> >> Thomas Wouters wrote: >> >> > Unfortunately, that's not how it works :-) If you check something into >> > the trunk, it will be merged into Py3k sooner or later. I may ask the >> > original submitter for assistance if it's incredibly hard to figure out >> > the changes, but so far, I only had to do that with the SSL changes. The >> > decimal changes are being merged as I write this (tests running now.) Is >> > there anything in particular that needs to be done for decimal in Py3k, >> > besides renaming __div__ to __truediv__? >> > >> > If you re-eally need to check something into the trunk that re-eally >> > must not be merged into py3k, but you're afraid it's not going to be >> > obvious to the merger, please record the change as 'merged' using >> > "svnmerge merge -M -r". Please take care when picking the >> > revision ;) You can also just email me or someone else you see doing >> > merges, as I doubt this will be a common occurance. I think that the 'svnmerge block -r' command should be used. Or not? 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] anon svn down?
It looks like anonymous SVN is down: http://svn.python.org/projects/python/ 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 is coming
Neal Norwitz schrieb:
> We are planning the release of 2.5.2 for next week. Unless there are
> serious bugs, please hold off making big changes to the 2.5 branch
> until after 2.5.2 final is released. Anthony gets cranky when things
> break and he scares me...a lot. :-) Doc/test fixes as always are
> still fine.
>
> The plan is cut the release candidate around Tuesday/Wednesday next
> week (Oct 16/17). If all goes well, 2.5.2 final will follow a week
> later.
>
> Please test the 2.5 branch now and let us know if there are any
> serious problems. If there are serious bugs that you think should be
> addressed, let us know. Bugs are here: http://bugs.python.org/
>
Neal, I have one patch for ctypes still sitting in some of my sandboxes.
ctypes doesn't work when configured with --with-system-ffi on machines
where 'sizeof(long long) != sizeof(long)', in other words on 32-bit boxes.
This is because I misinterpreted the meaning of the FFI_ type codes.
See also this bug: https://bugs.launchpad.net/bugs/72505
Here is the fairly simple patch, even a little bit simpler than the patch
posted on the page above, which I want to apply to thrunk AND
release25-maint branch:
[EMAIL PROTECTED]:~/devel/release25-maint$ svn diff
Index: Modules/_ctypes/cfield.c
===
--- Modules/_ctypes/cfield.c(revision 52840)
+++ Modules/_ctypes/cfield.c(working copy)
@@ -1541,18 +1541,22 @@
/* XXX Hm, sizeof(int) == sizeof(long) doesn't hold on every platform */
/* As soon as we can get rid of the type codes, this is no longer a problem */
#if SIZEOF_LONG == 4
- { 'l', l_set, l_get, &ffi_type_sint, l_set_sw, l_get_sw},
- { 'L', L_set, L_get, &ffi_type_uint, L_set_sw, L_get_sw},
+ { 'l', l_set, l_get, &ffi_type_sint32, l_set_sw, l_get_sw},
+ { 'L', L_set, L_get, &ffi_type_uint32, L_set_sw, L_get_sw},
#elif SIZEOF_LONG == 8
- { 'l', l_set, l_get, &ffi_type_slong, l_set_sw, l_get_sw},
- { 'L', L_set, L_get, &ffi_type_ulong, L_set_sw, L_get_sw},
+ { 'l', l_set, l_get, &ffi_type_sint64, l_set_sw, l_get_sw},
+ { 'L', L_set, L_get, &ffi_type_uint64, L_set_sw, L_get_sw},
#else
# error
#endif
#ifdef HAVE_LONG_LONG
- { 'q', q_set, q_get, &ffi_type_slong, q_set_sw, q_get_sw},
- { 'Q', Q_set, Q_get, &ffi_type_ulong, Q_set_sw, Q_get_sw},
+#if SIZEOF_LONG_LONG == 8
+ { 'q', q_set, q_get, &ffi_type_sint64, q_set_sw, q_get_sw},
+ { 'Q', Q_set, Q_get, &ffi_type_uint64, Q_set_sw, Q_get_sw},
+#else
+# error
#endif
+#endif
{ 'P', P_set, P_get, &ffi_type_pointer},
{ 'z', z_set, z_get, &ffi_type_pointer},
#ifdef CTYPES_UNICODE
[EMAIL PROTECTED]:~/devel/release25-maint$
Is is ok to apply this patch?
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] Buildbot failure AMD64 trunk
Thomas Heller schrieb: > The 64-bit windows trunk buildbot now only fails the test_winsound test. > This is because for whatever reasons the machine cannot play any sounds. > I have no idea why this is so, and I'm not too inclined to fix this. The > buildbot is running Window XP 64-bit in a vmware image running under ubuntu. > > Is there a way to display the winsound test on this machine? I'm annoyed > by the red color ;-). I mean: Is there a way to DISABLE the winsound test? Sorry for the confusion... ___ 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] Buildbot failure AMD64 trunk
The 64-bit windows trunk buildbot now only fails the test_winsound test. This is because for whatever reasons the machine cannot play any sounds. I have no idea why this is so, and I'm not too inclined to fix this. The buildbot is running Window XP 64-bit in a vmware image running under ubuntu. Is there a way to display the winsound test on this machine? I'm annoyed by the red color ;-). 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] bug submitting procedure
I've just received a private email from Christian Jacobsen (we were discussing some ctypes bugs/deficiencies that do not matter in this context). He wrote: > [...] The bug > reporting procedures for documentation is a big inconsistent: > http://wiki.python.org/moin/SubmittingBugs, says: "If you find errors > in the documentation, please use either the Add a comment or the > Suggest a change features of the relevant page in the most recent > online documentation at http://docs.python.org/.";, but the most > recent online documentation points to the SF bugtracker or > [EMAIL PROTECTED] The SF bugtracker in points back to bugs.python.org > :) I feel with him. Further, there is no 'Add a comment' or 'Suggest a change' link in the 2.5 documentation shown at http://docs.python.org. 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] 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
[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
