Am 11.05.2016 um 18:04 schrieb Brett Cannon:
On Wed, 11 May 2016 at 04:35 Thomas Heller <thel...@ctypes.org
<mailto:thel...@ctypes.org>> wrote:
Am 10.05.2016 um 19:39 schrieb Brett Cannon:
>
>
> On Tue, 10 May 2016 at 01:18 Martin Panter
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
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.
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
Am 12.02.2015 um 15:46 schrieb Paul Moore:
On 12 February 2015 at 08:05, Thomas Heller thel...@ctypes.org wrote:
Maybe I'm more or less alone with the way I work, but I don't like
python.exe on my PATH (and py.exe alloes me to do this).
I start python scripts from the command line either
Am 22.03.2014 00:25, schrieb Nick Coghlan:
On 22 March 2014 05:46, Thomas Heller thel...@ctypes.org wrote:
With python 3.4 and pywin32 version 218 it is only possible
to import win32com or win32api when pywintypes has been imported before.
I have no idea if this is a bug in pywin32
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
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
Am 08.11.2013 12:19, schrieb Victor Stinner:
2013/11/8 Nick Coghlan ncogh...@gmail.com:
In Python 3.3, _PyDict_GetItemIdWithError(), _PyDict_GetItemId() and
_PyDict_SetItemId() are part of the stable ABI if I read correctly
dictobject.h. _PyObject_GetAttrId() is also part of the stable ABI.
Was
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
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
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
Am 29.03.2013 02:06, schrieb Gregory P. Smith:
On Thu, Mar 28, 2013 at 9:09 AM, Brett Cannon br...@python.org
mailto:br...@python.org wrote:
On Thu, Mar 28, 2013 at 10:44 AM, Thomas Heller thel...@ctypes.org
mailto:thel...@ctypes.org wrote:
The zip-file itself could support
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
Am 06.03.2013 18:19, schrieb Eli Bendersky:
On Wed, Mar 6, 2013 at 8:33 AM, Andrew Svetlov andrew.svet...@gmail.com
mailto:andrew.svet...@gmail.com wrote:
Looks like bug for me.
ctypes seems to auto-convert arguments when argtypes is specified. This
fact is documented. However, I'm not
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
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'
In Python3.3, I thought that every loaded module has a __loader__
attribute. Apparently this is not the case for a few builtin modules:
Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:57:17) [MSC v.1600 64
bit (AMD64)] on win32
Type help, copyright, credits or license for more information.
Am 01.02.2013 01:42, schrieb Nick Coghlan:
Yep, looks like a bug in the bootstrapping, failing to set __loader__
properly.
It also has the effect that reload does not work:
Type help, copyright, credits or license for more information.
import imp
import math
imp.reload(math)
module 'math'
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...
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
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
Meador Inge schrieb:
On Fri, Feb 26, 2010 at 4:08 PM, Greg Ewing
greg.ew...@canterbury.ac.nzwrote:
Meador Inge wrote:
3. Using Decimal keeps the desired precision,
Well, sort of, but then you end up doing arithmetic in
decimal instead of binary, which could give different
results.
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
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
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
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'
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
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
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
Jean-Paul Calderone schrieb:
On Thu, 23 Jul 2009 14:21:38 +0200, Christian Heimes li...@cheimes.de wrote:
Michael Foord wrote:
A big advantage of using ctypes is that it works cross-implementation -
on IronPython and PyPy already and on Jython soon. I'd like to see more
standard library
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
David Bolen schrieb:
Antoine Pitrou solip...@pitrou.net writes:
Only one of the py3k buildbots seems up:
http://www.python.org/dev/buildbot/3.x.stable/
Strange - everything looks good on my buildbot end (XP-4), including
an established TCP session back to dinsdale. Not sure why the
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
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
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
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
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++
Ulrich Eckhardt schrieb:
Hi!
In callproc.c from trunk is a function called SetException(), which calls
FormatError() only to discard the contents. Can anyone enlighten me to the
reasons thereof? Is it just to check if the errorcode is registered in the
stringtables?
I think that your
BTW: there is another implementation (called my_strdup) in
Modules/_ctypes/_ctypes_test.c, why not use the one in Python/strdup.c there?
I guess that's historical, from the times when ctypes was still a
separate package.
my_strdup is an exported function in _ctypes_test.pyd (on Windows),
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
Victor Stinner schrieb:
Le Friday 31 October 2008 14:13:01 Christian Heimes, vous avez écrit :
ctypes is also missing utilities to write code that works on 32 and
64bit platforms. Without a tool like
http://pypi.python.org/pypi/ctypes_configure it's very hard and tedious
to avoid and fix
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
Christian Heimes schrieb:
Thomas Heller wrote:
I have a fix for a modulefinder crash that I'm going to commit
into the trunk. Since the bug is also in release26-maint I will
also backport it. While preparing this I noticed that in the
release26-maint branch 'svnmerge init' has not yet been
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:
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
Mark Hammond schrieb:
In http://bugs.python.org/issue4120, the author suggests that it might
be possible to completely stop using the manifest mechanism, for VS
2008. Given the many problems that this SxS stuff has caused, this
sounds like a very desirable route, although I haven't done any
Amaury Forgeot d'Arc schrieb:
2008/10/8 Martin v. Löwis [EMAIL PROTECTED]:
Thomas Heller wrote:
Is it intended that python30.dll and python26.dll are not longer
installed in the \windows\system32 directory?
No, it's not. Please create a bug report (or, better, study the
msiexec logs
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
Christian Heimes schrieb:
Thomas Heller wrote:
Is it intended that python30.dll and python26.dll are not longer
installed in the \windows\system32 directory?
This (pythonxy.dll not on $PATH) causes problems for COM objects
implemented in Python.
How did you install Python 2.6? Did you
Victor Stinner schrieb:
Hi,
I would like to be able to catch SIGSEGV in my Python code! So I started to
hack Python trunk to support this feature. The idea is to use a signal
handler which call longjmp(), and add setjmp() at Py_EvalFrameEx() enter.
On windows, ctypes catches fatal errors
Perhaps we could have an option to place a python.bat
into C:\Windows\ or C:\Windows\System\.
Except you still have the last in wins issue, and you have to make a
decision on whether or not to delete the file.
If this is done the batch file should be named python25.bat or so
depending
Paul Moore schrieb:
Bat files don't work when called from another bat file. This hits me
regularly, when people supply wrapper bat files. Example:
myscript.bat:
@echo off
do some stuff
python my_py_script.py
do some more stuff
If python is a bat file, do some more stuff will never get
Fredrik Lundh schrieb:
Amaury Forgeot d'Arc wrote:
when I'm trying to build extensions under Python 2.6 on Windows XP, the
build process terminates with single line that says:
error: None
which is about as useless as an error message can be. Googling for this
brings up a few hits
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
Sidnei da Silva schrieb:
On Fri, Jul 18, 2008 at 12:42 PM, Sidnei da Silva
[EMAIL PROTECTED] wrote:
That's a great trick! I seem to remember that there is a way to turn
that off globally though, but not sure where. Maybe running
drwtsn32.exe and un-checking 'Visual Notification' does the
Guido van Rossum schrieb:
On Thu, Jul 17, 2008 at 9:25 AM, Raymond Hettinger [EMAIL PROTECTED] wrote:
From: Eric Smith [EMAIL PROTECTED]
I have this ready for checkin (with docs and tests). I'd like to get it
in for this beta, since it does involved changed behavior, no matter how
small
Tim Golden schrieb:
This problem was raised on the comtypes-users list
as it prevents comtypes from being imported on Python 2.6
at the moment.
http://bugs.python.org/issue3258
I'll try to find the time to step through to code to work out
what's going on, but it's inside the innards of
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
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
Thomas Heller schrieb:
There are a few cases where the ctypes docs are rendered incorrectly:
http://docs.python.org/dev/library/ctypes.html#function-prototypes
This looks as if 'prototype' would be a symbol exposed by ctypes; it is
not - it is used as a placeholder for the object returned
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
Thomas Heller schrieb:
I'm currently trying to port the pep3118 ctypes changes which are already in
the py3k branch to the trunk.
In py3k the tests for this stuff (in Lib/ctypes/test/test_pep3118.py) use
the memoryview object which exposes attributes like .format, .shape, .strides
and so
Lisandro Dalcin schrieb:
On 6/5/08, Thomas Heller [EMAIL PROTECTED] wrote:
Thomas, Iff this helps, you have attached the backport but as an
extension module. Sorry, I do not have time for the full backport.
But at least, I've found that the Py3K implementation works
Thanks for the effort
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.M. Kuchling schrieb:
On Mon, May 19, 2008 at 08:50:39PM +0200, Thomas Heller wrote:
Myself I would rather spend my energy to make ctypes more portable, within my
skills and the platforms I have access to.
Someone could run Solaris x86 inside a hosted virtual machine and make
it available
Ulrich Berning schrieb:
If porting libffi to AIX, HP-UX, IRIX, Solaris... (especially using
vendor compilers) would be an easy job, I'm sure it would have been done
already. If more and more essential packages depend on ctypes, we should
make a clear statement, that Python isn't supported
Michael Foord schrieb:
James Y Knight wrote:
On May 21, 2008, at 11:26 AM, Michael Foord wrote:
And what about platforms like the JVM or CLR?
Incidentally there were a small but vocal group of Pythonistas who
were (are?) certain that IronPython is not Python because it doesn't
have [all
Charles Cazabon schrieb:
A.M. Kuchling [EMAIL PROTECTED] wrote:
On Mon, May 19, 2008 at 08:50:39PM +0200, Thomas Heller wrote:
Myself I would rather spend my energy to make ctypes more portable, within
my
skills and the platforms I have access to.
Someone could run Solaris x86 inside
Bill Janssen schrieb:
Hmm, perhaps the ctypes documentation could use a more prominent warning
that it may not be available on some Unix platforms (HP-UX, AIX, IRIX),
and that it may require the use of GCC rather than the vendor compiler
on others (Solaris).
At the moment, I suspect some
Ulrich Berning schrieb:
Nick Craig-Wood wrote:
Jesse Noller [EMAIL PROTECTED] wrote:
I am looking for any questions, concerns or benchmarks python-dev has
regarding the possible inclusion of the pyprocessing module to the
standard library - preferably in the 2.6 timeline. In March, I
Martin v. Löwis schrieb:
I'd like to propose we delete Lib/Distutils/command/wininst-9.0.exe, and
enable the building of that project by default in the standard build process
(and I'll setup the x64 build of the executable similarly).
There are two issues here:
a) how does the binary get
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:
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
==
Neal/Martin, I'd like to promote the following slaves to the stable list:
[g4 osx.4]
[x86 W2k8]
[AMD64 W2k8]
[ppc Debian unstable]
[sparc Ubuntu]
[sparc Debian]
[PPC64 Debian]
[S-390 Debian]
[x86 XP-3]
[amd64 XP]
[x86 FreeBSD]
[x86 FreeBSD 3]
The trunk builds of these
M.-A. Lemburg schrieb:
About the platform.py changes: if someone could provide the return
values of sys.getwindowsversion() for 64bit versions of Windows
XP and Vista, I could add support for it (don't have a 64bit version
of Windows available to check myself).
This is the output of a 32-bit
Barry Warsaw schrieb:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 18, 2008, at 2:04 AM, Travis Oliphant wrote:
Hey Barry,
Thanks for putting this PEP together. This is really helpful.
Hi Travis... thanks!
I didn't see discussion of PEP 3118 and it's features back-ported to
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
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
Martin v. Löwis schrieb:
Thomas Heller wrote:
Martin v. Löwis schrieb:
I just implemented auto-assignment for the tracker, i.e. a component
can be linked to a developer so that issues mentioning the component
get assigned to that developer (unless an explicit assignment is
made).
You can
Trent Nelson schrieb:
I've started to see my build slave dying every so often with a
twisted error half way through tests: ... test_htmlparser
test_httplib
remoteFailed: [Failure instance: Traceback (failure with no frames):
twisted.internet.error.ConnectionLost: Connection to the other
Trent Nelson schrieb:
Had a chat with some Twisted/buildbot folk and they can confirm
they've seen it as well on Windows. They've given me a few things to
look into. Out of interest, how are you running your buildbot? Via
the command line in an interactive desktop session, as a service, or
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
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
Trent Nelson schrieb:
Christian Heimes:
Trent Nelson wrote:
- vcbuild db-4.4.20\build_win32\Berkeley_DB.sln /build Debug
/project db_static
+ devenv /upgrade db-4.4.20\build_win32\Berkeley_DB.sln
+ devenv db-4.4.20\build_win32\Berkeley_DB.sln /build Debug
/project db_static
The
Neal Norwitz schrieb:
On Tue, Feb 26, 2008 at 11:47 PM, Brett Cannon [EMAIL PROTECTED] wrote:
Well, in my opinion batteries included is great, but not when one of
the batteries consistently acts up and requires a good shake to get
working again. The bsddb module has consistent reliability
Travis Oliphant schrieb:
Thomas Heller wrote:
Travis Oliphant schrieb:
So, I think the example is correct (and intentional).
Sorry, I do not think so. If you use a 2-d array in the example, you
must describe it correctly. The difference between this pep and the old
I don't understand
Hi Travis,
I have started the pep3118 implementation for ctypes. If you have time,
could you please review http://bugs.python.org/issue1971, especially
the tests in file Lib/ctypes/test/test_pep3118.py to ensure that I have
understood and implemented the pep correctly?
Thanks,
Thomas
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
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
Gregory P. Smith schrieb:
The documentation for the struct module says:
http://docs.python.org/dev/library/struct.html#module-struct
short is 2 bytes; int and long are 4 bytes; long long (__int64 on Windows)
is 8 bytes
and lists 'l' and 'L' as the pack code for a C long.
As its
Hi Travis,
The pep contains this sample:
Nested array
::
struct {
int ival;
double data[16*4];
}
i:ival:
(16,4)d:data:
I think it is wrong and must be changed to the following; is this correct?
Nested array
::
Guido van Rossum schrieb:
If I run make clean and then make, builting _ctypes fails with this
message:
*** WARNING: renaming _ctypes since importing it failed: No module
named _weakref
Typing make a second time fixes this -- it seems a simple matter of
_ctypes being built before
Guido van Rossum schrieb:
I believe the issue of whether and how to backport bytes (and
bytearray?) from 3.0 to 2.6 has come up before, but I don't think
we've come to any kind of conclusion. It's quite subtle. In a private
email, Thomas Wouters and I discussed this:
[Guido]
Perhaps the
[EMAIL PROTECTED] schrieb:
Christian I read the announcement of the Python Users list and figured
Christian out that some of the other core developers might be
Christian interested in the news, too.
Christian Among other projects Python was upgraded to Rung 2 on the
Guido van Rossum schrieb:
On Jan 9, 2008 9:47 AM, Christian Heimes [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
I shows 6 uninspected defects for Python. How do we see what they are?
What is an uninspected defect? Any idea how the Coverity folks compute
Defects/KLOC? For example,
Christian Heimes schrieb:
Thomas Heller wrote:
Seems they are referring to the results of the rung 1 run (what ever 'rung'
means ;-).
With the account Neal made me some months ago, I can login on this page:
http://scan.coverity.com:7475/
and see the scan results for Python.
Last
Facundo Batista schrieb:
2007/11/14, Christian Heimes [EMAIL PROTECTED]:
After Amaury introduced himself I've decided that I *have* to take some
time to introduce myself, too.
It's probably too late to say welcome to both Christian and Amaury,
also we have already met in the bug tracker.
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.
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
1 - 100 of 319 matches
Mail list logo
