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> &

Re: [Python-Dev] ctypes compatibility with 2.3

t 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 s

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, m

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 'sc

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.

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

[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 mail

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

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 mis

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 d

[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

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 lib

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 compile

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

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

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-

[Python-Dev] importlib hooray!

I have become a fan of the new python 3.3 importlib in the last few days. It has allowed me to write a ModuleMapper which I put into sys.metapath (in sitecustomize.py, for Python 3.3). This mapper currently does rename modules like 'Queue' or '_winreg' to the Python3 modules 'queue' or 'winreg'

Re: [Python-Dev] importlib.find_loader

Am 01.02.2013 01:42, schrieb Nick Coghlan: Yep, looks like a bug in the bootstrapping, failing to set __loader__ properly. It also has the effect that reload does not work: Type "help", "copyright", "credits" or "license" for more information. >>> import imp >>> import math >>> imp.reload(math

[Python-Dev] importlib.find_loader

In Python3.3, I thought that every loaded module has a __loader__ attribute. Apparently this is not the case for a few builtin modules: Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:57:17) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more inform

Re: [Python-Dev] 2.7 releases

Am 26.07.2012 20:16, schrieb mar...@v.loewis.de: Will there be more 2.7 bugfix releases Yes. and when the next one? That's up for Benjamin to decide. My view is that one bugfix release every year is more than enough. Ok. I expect we will still be using 2.7 next year in my company. In o

[Python-Dev] 2.7 releases

Will there be more 2.7 bugfix releases, and when the next one? In other words; if I submit a patch and it is accepted, can I expect that patch be committed also to the 2.7 branch? Thanks, Thomas Been a long time that I've been here - but still using Python (2.7 now) more and more... __

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) , Pyt

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 ma

[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 mer

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. >> > > Ev

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 > sum

[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

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/piperma

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'

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 it

[Python-Dev] OS X buildbot

I have updated the OS X buildbot to Snow Leopard. -- Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Replacing PyWin32's PeekNamedPipe, ReadFile, and WriteFile

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

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.py

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

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, Thoma

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 l

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 thi

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

[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 ru

[Python-Dev] Include C++ code in the ctypes test suite?

I'm currently working on a patch that adds the __thiscall calling convention to ctypes. This calling convention is used on Windows for calling member functions from C++ classes. The idea is to eventually allow ctypes to wrap C++ classes. To test this functionality it is required to add some C++

Re: [Python-Dev] FormatError() in callproc.c under win32

Ulrich Eckhardt schrieb: > Hi! > > In callproc.c from trunk is a function called SetException(), which calls > FormatError() only to discard the contents. Can anyone enlighten me to the > reasons thereof? Is it just to check if the errorcode is registered in the > stringtables? I think that yo

Re: [Python-Dev] a few strdup() questions...

>> BTW: there is another implementation (called my_strdup) in >> Modules/_ctypes/_ctypes_test.c, why not use the one in Python/strdup.c there? > > I guess that's historical, from the times when ctypes was still a > separate package. my_strdup is an exported function in _ctypes_test.pyd (on Windo

Re: [Python-Dev] The endless GIL debate: why not remove thread support instead?

Christian Heimes schrieb: > Nick Coghlan schrieb: >> Actually, I believe 3.0 already took a big step towards allowing this by >> changing the way modules are initialised. > > You are believing correctly. Martin has designed and implemented a > nicely working API to store extension module data per

Re: [Python-Dev] Fwd: Removal of GIL through refcounting removal.

Victor Stinner schrieb: > Le Friday 31 October 2008 14:13:01 Christian Heimes, vous avez écrit : >> ctypes is also missing utilities to write code that works on 32 and >> 64bit platforms. Without a tool like >> http://pypi.python.org/pypi/ctypes_configure it's very hard and tedious >> to avoid and

Re: [Python-Dev] Fwd: Removal of GIL through refcounting removal.

Christian Heimes schrieb: > Nick Coghlan wrote: >> If I recall correctly, the main blocker to ctypes portability is libffi >> portability. So if anyone would like to see ctypes on more platforms, >> then that's the limitation they really need to attack. > > ctypes is also missing utilities to writ

[Python-Dev] buildbots

AFAICS there are no buildbots for the release26-maint branch. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-arch

Re: [Python-Dev] svnmerge init in the release26-maint branch?

Christian Heimes schrieb: > Thomas Heller wrote: >> I have a fix for a modulefinder crash that I'm going to commit >> into the trunk. Since the bug is also in release26-maint I will >> also backport it. While preparing this I noticed that in the >> release26-main

[Python-Dev] svnmerge init in the release26-maint branch?

I have a fix for a modulefinder crash that I'm going to commit into the trunk. Since the bug is also in release26-maint I will also backport it. While preparing this I noticed that in the release26-maint branch 'svnmerge init' has not yet been done. I assume that we will use svnmerge to merge fro

Re: [Python-Dev] is the 'path' argument to an importer's find_module() just a hint?

Brett Cannon schrieb: > I just discovered frozen packages set their __path__ simply to their > name and not to a list as expected (http://bugs.python.org/issue4211). > This made me think about the 'path' argument to find_module() and > whether it can be treated as simply a hint or should always be

Re: [Python-Dev] No manifest files on Windows?

Mark Hammond schrieb: >> In http://bugs.python.org/issue4120, the author suggests that it might >> be possible to completely stop using the manifest mechanism, for VS >> 2008. Given the many problems that this SxS stuff has caused, this >> sounds like a very desirable route, although I haven't done

Re: [Python-Dev] python dll no longer in system directory?

Amaury Forgeot d'Arc schrieb: > 2008/10/8 "Martin v. Löwis" <[EMAIL PROTECTED]>: >> Thomas Heller wrote: >>> Is it intended that python30.dll and python26.dll are not longer >>> installed in the \windows\system32 directory? >> >> No,

Re: [Python-Dev] python dll no longer in system directory?

Christian Heimes schrieb: > Thomas Heller wrote: >> Is it intended that python30.dll and python26.dll are not longer >> installed in the \windows\system32 directory? >> >> This (pythonxy.dll not on $PATH) causes problems for COM objects >> implemented in Python

[Python-Dev] python dll no longer in system directory?

Is it intended that python30.dll and python26.dll are not longer installed in the \windows\system32 directory? This (pythonxy.dll not on $PATH) causes problems for COM objects implemented in Python. Thanks, Thomas ___ Python-Dev mailing list Python-Dev

Re: [Python-Dev] Real segmentation fault handler

Victor Stinner schrieb: > Hi, > > I would like to be able to catch SIGSEGV in my Python code! So I started to > hack Python trunk to support this feature. The idea is to use a signal > handler which call longjmp(), and add setjmp() at Py_EvalFrameEx() enter. On windows, ctypes catches fatal err

Re: [Python-Dev] Add python.exe to PATH environment variable

Paul Moore schrieb: > Bat files don't work when called from another bat file. This hits me > regularly, when people supply wrapper bat files. Example: > > myscript.bat: > @echo off > do some stuff > python my_py_script.py > do some more stuff > > If "python" is a bat file, "do some more stuff" wi

Re: [Python-Dev] Add python.exe to PATH environment variable

> > Perhaps we could have an option to place a "python.bat" > > into C:\Windows\ or C:\Windows\System\. > > Except you still have the "last in wins" issue, and you have to make a > decision on whether or not to delete the file. If this is done the batch file should be named "python25.bat" or s

Re: [Python-Dev] "error: None" when building extensions under 2.6

Fredrik Lundh schrieb: > Amaury Forgeot d'Arc wrote: > >>> when I'm trying to build extensions under Python 2.6 on Windows XP, the >>> build process terminates with single line that says: >>> >>>error: None >>> >>> which is about as useless as an error message can be. Googling for this >>> br

Re: [Python-Dev] Windows buildbot trick

Sidnei da Silva schrieb: > On Fri, Jul 18, 2008 at 12:42 PM, Sidnei da Silva > <[EMAIL PROTECTED]> wrote: >> That's a great trick! I seem to remember that there is a way to turn >> that off globally though, but not sure where. Maybe running >> drwtsn32.exe and un-checking 'Visual Notification' does

[Python-Dev] Windows buildbot trick

The most annoying thing on the windows buildbots is when Python crashes hard (with a general protection fault or stack overflow, for example). Usually the system pops up a dialog in this case which allows to attach a debugger to the process. This dialog will stay open until the maintainer manually

Re: [Python-Dev] PEP 3101: floats format 'f' and 'F'

Guido van Rossum schrieb: > On Thu, Jul 17, 2008 at 9:25 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: >> From: "Eric Smith" <[EMAIL PROTECTED]> >>> >>> I have this ready for checkin (with docs and tests). I'd like to get it >>> in for this beta, since it does involved changed behavior, no matt

Re: [Python-Dev] ctypes assertion failure

Tim Golden schrieb: > This problem was raised on the comtypes-users list > as it prevents comtypes from being imported on Python 2.6 > at the moment. > > http://bugs.python.org/issue3258 > > I'll try to find the time to step through to code to work out > what's going on, but it's inside the innar

[Python-Dev] Vacation

FYI: I'm going to a vacation for the next two or three weeks. I will shutdown my buildbots, and restart them when I'm back: x86 osx.5, x86 XP-3, amd64 XP. Sorry for the inconvenience, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail

Re: [Python-Dev] rest markup in ctypes docs

Thomas Heller schrieb: > There are a few cases where the ctypes docs are rendered incorrectly: > > http://docs.python.org/dev/library/ctypes.html#function-prototypes > > This looks as if 'prototype' would be a symbol exposed by ctypes; it is > not - it is used as

[Python-Dev] rest markup in ctypes docs

There are a few cases where the ctypes docs are rendered incorrectly: http://docs.python.org/dev/library/ctypes.html#function-prototypes This looks as if 'prototype' would be a symbol exposed by ctypes; it is not - it is used as a placeholder for the object returned by calls to the ctypes.CFUNCT

Re: [Python-Dev] PEP3118, python 2.6

Lisandro Dalcin schrieb: > On 6/5/08, Thomas Heller <[EMAIL PROTECTED]> wrote: > Thomas, Iff this helps, you have attached the backport but as an > extension module. Sorry, I do not have time for the full backport. > But at least, I've found that the Py3K implementatio

Re: [Python-Dev] PEP3118, python 2.6

Thomas Heller schrieb: > I'm currently trying to port the pep3118 ctypes changes which are already in > the py3k branch to the trunk. > > In py3k the tests for this stuff (in Lib/ctypes/test/test_pep3118.py) use > the memoryview object which exposes attributes like .format, .s

[Python-Dev] PEP3118, python 2.6

Hi Travis, I'm currently trying to port the pep3118 ctypes changes which are already in the py3k branch to the trunk. In py3k the tests for this stuff (in Lib/ctypes/test/test_pep3118.py) use the memoryview object which exposes attributes like .format, .shape, .strides and so on for objects imple

Re: [Python-Dev] PEP 371 Discussion (pyProcessing Module)

Jesse Noller schrieb: > On Fri, May 30, 2008 at 2:19 AM, Farshid Lashkari <[EMAIL PROTECTED]> wrote: >> On Wed, May 28, 2008 at 10:03 AM, Jesse Noller <[EMAIL PROTECTED]> wrote: >>> I would like to renew the discussion now that "there is a PEP" to see >>> if there are any outstanding things people

Re: [Python-Dev] Addition of "pyprocessing" module to standard lib.

Martin v. Löwis schrieb: >> As said before, PyOpenGL is an example of an extension that moved from C >> code to Python/ctypes, luckily we don't use it, but what if the >> maintainers of MySQL-Python or cx_Oracle decide to move to ctypes. >> Having the ctypes extension in the stdlib doesn't imply it

Re: [Python-Dev] Addition of "pyprocessing" module to standard lib.

Ulrich Berning schrieb: > > If porting libffi to AIX, HP-UX, IRIX, Solaris... (especially using > vendor compilers) would be an easy job, I'm sure it would have been done > already. If more and more essential packages depend on ctypes, we should > make a clear statement, that Python isn't suppo

Re: [Python-Dev] Addition of "pyprocessing" module to standard lib.

A.M. Kuchling schrieb: > On Mon, May 19, 2008 at 08:50:39PM +0200, Thomas Heller wrote: >> Myself I would rather spend my energy to make ctypes more portable, within my >> skills and the platforms I have access to. > > Someone could run Solaris x86 inside a hosted virtual

Re: [Python-Dev] Addition of "pyprocessing" module to standard lib.

Bill Janssen schrieb: > What happens on those platforms where ctypes doesn't work? Does the > module fail to import, either because it isn't present, or because it > can't load the libffi library? Or does it fail silently in some way? It doesn't compile, and Python's setup.py script removes if a

Re: [Python-Dev] Addition of "pyprocessing" module to standard lib.

Michael Foord schrieb: > James Y Knight wrote: >> >> On May 21, 2008, at 11:26 AM, Michael Foord wrote: >> >>> And what about platforms like the JVM or CLR? >>> >>> Incidentally there were a small but vocal group of Pythonistas who >>> were (are?) certain that IronPython is not Python because it d

Re: [Python-Dev] Addition of "pyprocessing" module to standard lib.

Martin v. Löwis schrieb: >>> We actually have a couple of Solaris buildbots already - as I >>> understand it, the issue there isn't Solaris as such, it's being able >>> to use the Sun compiler instead of GCC to compile ctypes/libffi. >> >> Does that mean that we need access to the Sun compiler or

Re: [Python-Dev] Addition of "pyprocessing" module to standard lib.

Charles Cazabon schrieb: > A.M. Kuchling <[EMAIL PROTECTED]> wrote: >> On Mon, May 19, 2008 at 08:50:39PM +0200, Thomas Heller wrote: >> > Myself I would rather spend my energy to make ctypes more portable, within >> > my >> > skills and the platforms

Re: [Python-Dev] Addition of "pyprocessing" module to standard lib.

Bill Janssen schrieb: >> Hmm, perhaps the ctypes documentation could use a more prominent warning >> that it may not be available on some Unix platforms (HP-UX, AIX, IRIX), >> and that it may require the use of GCC rather than the vendor compiler >> on others (Solaris). >> >> At the moment, I s

Re: [Python-Dev] Addition of "pyprocessing" module to standard lib.

Ulrich Berning schrieb: > Nick Craig-Wood wrote: > >>Jesse Noller <[EMAIL PROTECTED]> wrote: >> >> >>> I am looking for any questions, concerns or benchmarks python-dev has >>> regarding the possible inclusion of the pyprocessing module to the >>> standard library - preferably in the 2.6 timelin

Re: [Python-Dev] Remove "current" Windows executables from Lib/distutils/command in svn?

Martin v. Löwis schrieb: >> I'd like to propose we delete Lib/Distutils/command/wininst-9.0.exe, and >> enable the building of that project by default in the standard build process >> (and I'll setup the x64 build of the executable similarly). > > There are two issues here: > a) how does the binar

[Python-Dev] osx x86 buildbot offer

I can offer an OS X x86 machine to run a buildbot on. This is a physical machine, running OS X 10.5 Leopard. Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.o

Re: [Python-Dev] Consistent platform name for 64bit windows (was: distutils.util.get_platform() for Windows)

M.-A. Lemburg schrieb: > About the platform.py changes: if someone could provide the return > values of sys.getwindowsversion() for 64bit versions of Windows > XP and Vista, I could add support for it (don't have a 64bit version > of Windows available to check myself). This is the output of a 32-b

Re: [Python-Dev] trunk buildbot status

>> Neal/Martin, I'd like to promote the following slaves to the stable list: >> [g4 osx.4] >> [x86 W2k8] >> [AMD64 W2k8] >> [ppc Debian unstable] >> [sparc Ubuntu] >> [sparc Debian] >> [PPC64 Debian] >> [S-390 Debian] >> [x86 XP-3] >> [amd64 XP] >> [x86 FreeBSD] >> [x86 FreeBSD 3] >> >

Re: [Python-Dev] First green Windows x64 buildbots!

Trent Nelson schrieb: > We've just experienced our first 2.6 green x64 Windows builds on the > build slaves! Well, almost green. Thomas's 'amd64 XP trunk' ran out > of disk: > > 304 tests OK. 1 test failed: test_largefile > ==

Re: [Python-Dev] [Python-3000] PEP 361: Python 2.6/3.0 release schedule

Barry Warsaw schrieb: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Mar 18, 2008, at 2:04 AM, Travis Oliphant wrote: >> >> Hey Barry, >> >> Thanks for putting this PEP together. This is really helpful. > > Hi Travis... thanks! > >> I didn't see discussion of PEP 3118 and it's feature

Re: [Python-Dev] Auto-Assignment

Jeroen Ruigrok van der Werven schrieb: > -On [20080307 11:05], Guilherme Polo ([EMAIL PROTECTED]) wrote: >>When you create a new issue, you have to select a component from a >>list, those are the available components. > > I think Thomas was wondering what the definition for a component was within

Re: [Python-Dev] Auto-Assignment

Martin v. Löwis schrieb: > Thomas Heller wrote: >> Martin v. Löwis schrieb: >>> I just implemented auto-assignment for the tracker, i.e. a component >>> can be linked to a developer so that issues mentioning the component >>> get assigned to that develop

Re: [Python-Dev] Auto-Assignment

Martin v. Löwis schrieb: > I just implemented auto-assignment for the tracker, i.e. a component > can be linked to a developer so that issues mentioning the component > get assigned to that developer (unless an explicit assignment is > made). > You can autoassign ctypes issues to me, as you might

Re: [Python-Dev] Windows buildbots randomly die with twisted ConnectionLost errors?

Trent Nelson schrieb: > Had a chat with some Twisted/buildbot folk and they can confirm > they've seen it as well on Windows. They've given me a few things to > look into. Out of interest, how are you running your buildbot? Via > the command line in an interactive desktop session, as a service,

Re: [Python-Dev] Windows buildbots randomly die with twisted ConnectionLost errors?

Trent Nelson schrieb: > I've started to see my build slave dying every so often with a > twisted error half way through tests: ... test_htmlparser > test_httplib > > remoteFailed: [Failure instance: Traceback (failure with no frames): > twisted.internet.error.ConnectionLost: Connection to the oth

Re: [Python-Dev] Fixing buildbot/external(-amd64).bat files on Windows

Trent Nelson schrieb: > Christian Heimes: >> Trent Nelson wrote: >> > - vcbuild db-4.4.20\build_win32\Berkeley_DB.sln /build Debug >> /project db_static >> > + devenv /upgrade db-4.4.20\build_win32\Berkeley_DB.sln >> > + devenv db-4.4.20\build_win32\Berkeley_DB.sln /build Debug >> /project db

Re: [Python-Dev] Fixing buildbot/external(-amd64).bat files on Windows

Trent Nelson schrieb: > Howdy, > > I'm going through the motions of getting my newly added build slave in a half > decent state. I think the buildbot should have a name different from 'x86 XP'. (Martin, Neal?) Thomas ___ Python-Dev mailing list Pytho

Re: [Python-Dev] Fixing buildbot/external(-amd64).bat files on Windows

Trent Nelson schrieb: > Howdy, > > I'm going through the motions of getting my newly added build slave in a half > decent state. The external.bat and external-amd64.bat files needed the > following in order to build db-4.4.20: > > Index: external.bat > =

Re: [Python-Dev] Buildbots for trunk are all red

Neal Norwitz schrieb: > On Tue, Feb 26, 2008 at 11:47 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: >> >> Well, in my opinion "batteries included" is great, but not when one of >> the batteries consistently acts up and requires a good shake to get >> working again. The bsddb module has consistent

Re: [Python-Dev] Error in PEP3118?

Travis Oliphant schrieb: > Thomas Heller wrote: >> Travis Oliphant schrieb: >> >>> So, I think the example is correct (and intentional). >> >> Sorry, I do not think so. If you use a 2-d array in the example, you >> must describe it correctly. The diff

[Python-Dev] pep3118, ctypes, py3k

Hi Travis, I have started the pep3118 implementation for ctypes. If you have time, could you please review , especially the tests in file Lib/ctypes/test/test_pep3118.py to ensure that I have understood and implemented the pep correctly? Thanks, Thomas _

Re: [Python-Dev] 2.5.2 release coming up

Neal Norwitz schrieb: > We need to fix the Windows buildbots. 2 tests are currently failing > for 2.5.2: test_mailbox test_winreg The test_winreg failure is a funny one: The py3k test_winreg fails because of a bug in the test itself; I fixed this in rev. 60236. The failing test leaves a key in

Re: [Python-Dev] struct module docs vs reality

Gregory P. Smith schrieb: > The documentation for the struct module says: > > http://docs.python.org/dev/library/struct.html#module-struct > > "short is 2 bytes; int and long are 4 bytes; long long (__int64 on Windows) > is 8 bytes" > > and lists 'l' and 'L' as the pack code for a C long. > >

Re: [Python-Dev] Error in PEP3118?

Travis Oliphant schrieb: [...] > I responded off list to this email and wanted to summarize my response > for others to peruse. > > Basically, the answer is that the struct syntax proposed for > multi-dimensional arrays is not intended to mimic how the C-compiler > handles statically defined

[Python-Dev] Error in PEP3118?

Hi Travis, The pep contains this sample: """ Nested array :: struct { int ival; double data[16*4]; } """i:ival: (16,4)d:data: """ """ I think it is wrong and must be changed to the following; is this correct? """ Nested

Re: [Python-Dev] What to do for bytes in 2.6?

Guido van Rossum schrieb: > I believe the issue of whether and how to backport bytes (and > bytearray?) from 3.0 to 2.6 has come up before, but I don't think > we've come to any kind of conclusion. It's quite subtle. In a private > email, Thomas Wouters and I discussed this: > > [Guido] >> > Perha

Re: [Python-Dev] building _ctypes in trunk fails first time around

Guido van Rossum schrieb: > If I run "make clean" and then "make", builting _ctypes fails with this > message: > > *** WARNING: renaming "_ctypes" since importing it failed: No module > named _weakref > > Typing "make" a second time fixes this -- it seems a simple matter of > _ctypes being built

  1   2   3   4   >