Gerhard Häring wrote:
Thomas Heller wrote:
[...] I'm now happy with the tool that converts the ctypes tutorial
from reST to LaTeX,
I will later (today or tomorrow) commit that into Python SVN.
Did you commit that already? Alternatively, can you send it to me, please?
-- Gerhard
I meant
Thomas Wouters wrote:
On 4/27/06, Thomas Wouters [EMAIL PROTECTED] wrote:
Alrighty then. The list has about 12 hours to convince me (and you) that
it's a bad idea to generate that warning. I'll be asleep by the time the
trunk un-freezes, and I have a string of early meetings tomorrow. I'll get
Georg Brandl wrote:
Martin v. Löwis wrote:
Neal Norwitz wrote:
Who is the owner for getting new icons installed with the new logo?
Nobody, so far (for Windows). Somebody should contact the owner and
find out what the license on this work is, and then tell me what
to do with them. I assume
Michael Hudson wrote:
Gerhard Häring [EMAIL PROTECTED] writes:
Currently I'm not subscribed to python-checkins and didn't see a need
to. Is there a need to for Python core developers?
I would say it's encouraged.
I think there's no better way except subscribing and defining a
filter
Neal Norwitz wrote:
The following PEPs are open according to PEP 0 and haven't seen much
activity recently IIRC. I'd like everyone to take a cut and bring
these up to date. For all the PEPs that aren't going anywhere, can we
close them? Please update your PEP if appropriate.
S 298
/
- Standard library name
ctypes
- Contact person
Thomas Heller
- Synchronisation history
* 0.9.9.4 (2.5a1)
* 0.9.9.6 (2.5a2)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Martin v. Löwis wrote:
Dennis Heuer wrote:
Module names
like hashlib are not python-like too (too c/lowlevel-like).
I agree with Greg: hashlib is a Pythonic name for a module,
just like httplib, mhlib, xmlrpclib, cookielib, contextlib,
difflib, ...
OTOH, it might be indeed that the
Greg Ewing wrote:
Paul Moore wrote:
I do things like
python setup.py build --compiler=mingw32 bdist_wininst
which seem to work for me. Is that any help?
Possibly. I'll have to try it next time I have the
problem and see.
BTW, does that do anything different from
python
Martin v. Löwis wrote:
Thomas Heller wrote:
return Py_BuildValue(s,
ver.dwMajorVersion,
ver.dwMinorVersion,
ver.dwBuildNumber,
ver.dwPlatformId
Martin v. Löwis wrote:
Thomas Heller wrote:
Personally, I *like* the ctypes name. But I'm open for suggestions,
and it might have intersting consequences if the Python core package
would be renamed to something else.
Any suggestions?
Well, my only concern was py_object. I wondered
Neal Norwitz wrote:
This was run on linux amd64. It would be great to run purify on
windows and other platforms. If you do, please report back here, even
if nothing was found. That would be a good data point.
Summary of tests with problems:
test_codecencodings_jp (1 invalid read)
Ganesan Rajagopal wrote:
Neal Norwitz [EMAIL PROTECTED] writes:
Please add your project ideas to the existing set at
http://wiki.python.org/moin/SummerOfCode
I'd like to see ctypes supported on GCC ARM platforms. ARM is the only major
Debian architecture that's not supported by
I'm about to import the 0.9.9.6 tag of ctypes into Python svn.
Should this be done in exact the same way as before, so first
commit it into external/ctypes-0.9.9.6, and then 'svn copy'
the two relevant directories into the trunk, and afterwards set
all the svn props again, or is this done in
Neal Norwitz wrote:
On 4/18/06, Barry Warsaw [EMAIL PROTECTED] wrote:
On Wed, 2006-04-19 at 14:57 +1000, Anthony Baxter wrote:
I'm not sure how people would prefer this be handled. I don't think we
need to have a PEP for it - I don't see PEPs for ctypes, elementtree,
pysqlite or cProfile,
[Please let me know if this should go to the machine owner instead]
Why does the ia64 debian buildbot now complain about unaligned accesses,
and how can we find out where they occur?
http://www.python.org/dev/buildbot/trunk/ia64%20Debian%20unstable%20trunk/builds/123/step-test/0
Thanks,
Thomas
Martin v. Löwis wrote:
Thomas Heller wrote:
Why does the ia64 debian buildbot now complain about unaligned accesses,
and how can we find out where they occur?
I don't know why they started show up suddenly; on Debian-Itanium, it
is a configuration option (even per process, through prctl(1
Steven Bethard wrote:
Ok, if I summarize any more of python-dev, my brain's going to explode. ;-)
Here's the summaries for the first half of March. Let me know what to fix!
---
Maintaining ctypes in SVN trunk
---
Thomas Heller
, please let me know the details. Also, if I
missed any, obviously speak up:
- bsddb (still external?)
- sqlite
- ctypes
Maintainer: Thomas Heller
Homepage: http://starship.python.net/crew/theller/ctypes/
Where to report bugs: I do not care. I'll try to keep track of both the
python bug
Is there are #define symbol which allows to determine if
'char' is signed or unsigned? __CHAR_UNSIGNED__, maybe?
I guess the buildbot failures on the ppc debian box are caused by
ctypes using signed chars always.
Thanks,
Thomas
___
Python-Dev mailing
Martin v. Löwis wrote:
Thomas Heller wrote:
But if you make the change to implement option 3, IMO it would be a
good idea to add the Python version number to the .pyd basename as
well.
Can you please elaborate? In the name of what .pyd file do you want
the Python version number? And why
Martin v. Löwis wrote:
I just tried creating a pysqlite VS project, and ran into a naming
conflict: the Windows DLL is called sqlite3.dll. So if it is on
sys.path
import sqlite3
might find the DLL, instead of finding the package. Python then
finds that there is no entry point in sqlite3,
Martin v. Löwis wrote:
I have now produces a snapshot of a Win64 build for AMD64
processors (also known as EM64T or x64); this is different
from IA-64 (which is also known as Itanium)...
Anyway, the binaries are
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.5.13199.amd64.msi
Neal Norwitz wrote:
These issues are on HEAD. There might be some others I missed.
With cc there are at least 2 issues:
* test_file causes interpreter exit due to sys.stdin.seek(-1)
* test_pty fails apparently due to whitespace differences
Martin v. Löwis wrote:
Thomas Heller wrote:
Is this no longer available?
Sorry, I just deleted that. I now replaced it with
python-2.5.13231.amd64.msi
Thanks, I'll try that.
BTW: When I build Python for ReleaseAMD64 myself, the exe crashes at the
first
Py_BuildValue call
Martin v. Löwis wrote:
Thomas Heller wrote:
In sys_getwindowsversion:
return Py_BuildValue(s,
ver.dwMajorVersion,
ver.dwMinorVersion,
ver.dwBuildNumber,
ver.dwPlatformId
Gregory P. Smith wrote:
On Sat, Mar 11, 2006 at 07:08:14PM +0100, Thomas Heller wrote:
Martin v. L?wis wrote:
Josiah Carlson told me had has given up getting a Windows
buildbot running, because every time he installed VS.NET
on his machine, the installation would immediately crash.
So
Georg Brandl wrote:
Hi,
(this makes test_ctypes fail, therefore I noticed)
currently with -Qnew:
2/0
Traceback (most recent call last):
File stdin, line 1, in ?
ZeroDivisionError: float division
2L/0
Traceback (most recent call last):
File stdin, line 1, in ?
Fred L. Drake, Jr. wrote:
On Monday 27 March 2006 16:26, Phillip J. Eby wrote:
Any thoughts on where documentation for the new contextlib module should
go in the library reference?
Most definately in Python Runtime Services.
A similar issue exists for ctypes module, although I
Trent Mick wrote:
[Thomas Heller wrote]
Linking...
Creating library .\./python25.lib and object .\./python25.exp
zipimport.obj : error LNK2001: unresolved external symbol __security_cookie
traceback.obj : error LNK2001: unresolved external symbol __security_cookie
typeobject.obj : error
I'm trying out to build Python for 64-bit Windows, running the tools on WinXP
SP2 (32-bit).
I have installed:
- MSVC .NET 2003
- Platform SDK Feb 2003
- vsextcomp 0.6
Then I fire up MSVC, select the ReleaseAMD64 configuration, and try to build the
pythoncore project.
After lots of compiler
Thomas Heller wrote:
Martin v. Löwis wrote:
Thomas Heller wrote:
Then I fire up MSVC, select the ReleaseAMD64 configuration, and try to
build the
pythoncore project.
After lots of compiler warnings, the build fails with this message:
...
For some reason, VS.NET hasn't picked up the PATH
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
I think it's only fair that I ask the patch authors to complete
the PEP, since the ssize_t patch is causing extension authors
enough trouble already.
Well, the PEP is complete as it stands. It's possible to provide
more guidelines, but the
M.-A. Lemburg wrote:
Martin v. Löwis wrote:
Thomas Heller wrote:
I'm not sure if this is what Marc-Andre means, but maybe these definitions
could go into a new include file:
How would that include file be used? You would have to copy it into your
own source base, and include it, right?
We
Fredrik Lundh wrote:
the definition of sys.executable is a bit unclear, something that has led to
incompatible use in deployed code.
the docstring for sys.executable says pathname of this Python interpreter,
which can be interpreted as either
a) sys.executable points to the executable
Martin v. Löwis wrote:
Thomas Heller wrote:
BTW: Is a porting guide to make extension modules compatible with 2.5
available somewhere? PEP 353 scratches only the surface...
Wrt. ssize_t changes, PEP 353 is meant to be comprehensive. Which
particular aspect are you missing?
I suggest
Tim Peters wrote:
[Martin]
...
I believe it does: the ctypes maintainer wants to keep the
code identical across releases (AFAICT).
Correct, that's why I listed it in PEP 291.
Fair enough -- I reverted the checkin. It's going to need #if'ery on
the Python version, though, if it wants to
Neal Norwitz wrote:
On 3/9/06, Thomas Heller [EMAIL PROTECTED] wrote:
Would it be a solution to move the 'official' ctypes development into
Python SVN external/ctypes, or would this be considered abuse? Another
location in SVN could be used as well, if external is though to contain
only
Trent Mick wrote:
Yup. Looks like my build worked. Another TODO now though:
- Figure out why usage of:
winsound.PlaySound(something, winsound.SND_ALIAS)
fails on my Win2k box. This is why the test suite fails on that box.
Doesn't that always fail when there is no soundcard in the
Thomas Wouters wrote:
On 3/10/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Thomas Heller wrote:
BTW: The buildbot reports ctypes test failures on the gentoo amd64
machine:
http://www.python.org/dev/buildbot/trunk/amd64%20gentoo%20trunk/builds/277/step-test/0
Is there a way to get the actual
Martin v. Löwis wrote:
Josiah Carlson told me had has given up getting a Windows
buildbot running, because every time he installed VS.NET
on his machine, the installation would immediately crash.
So if anybody wants to contribute both a machine and time
to operate it (including the likely
Thomas Wouters wrote:
On 3/10/06, Thomas Heller [EMAIL PROTECTED] wrote:
Would it be a solution to move the 'official' ctypes development into
Python SVN external/ctypes, or would this be considered abuse? Another
location in SVN could be used as well, if external is though to contain
only
Tim Peters wrote:
[Thomas Heller]
...
In the meantime, please: If anyone is going to make fixes to the ctypes
source
code (apart from Tim's regular whitespace cleanup), please do this in the
ctypes CVS repository on sourceforge, in the trunk.
FYI, my regular whitespace cleanup consists
Tim Peters wrote:
[Thomas Heller]
...
And I never had tried it before on a sparc machine - all the intel and ppc
processors
seem to have no problems with it.
Pentiums don't enforce natural alignment restrictions, but run much
slower on unaligned access (varying by specific chip model
Martin v. Löwis wrote:
Thomas Heller wrote:
BTW: The buildbot reports ctypes test failures on the gentoo amd64 machine:
FWIW, ctypes doesn't even build on a Windows AMD64 machine. It wants to
use the Windows x86 FFI code, which does not compile with the AMD64
compiler.
On such a machine
Neal Norwitz wrote:
On 3/10/06, Thomas Heller [EMAIL PROTECTED] wrote:
BTW: The buildbot reports ctypes test failures on the gentoo amd64 machine:
http://www.python.org/dev/buildbot/trunk/amd64%20gentoo%20trunk/builds/277/step-test/0
Is there a way to get the actual failures somehow
ctypes is in SVN now, and the buildbot is green, after I disabled a test that
dumped core
on sparc solaris. The crash was apparently caused
Missing are .vcproj files for Windows, both for the _ctypes.pyd extension and
the _ctypes_test.pyd
extension needed for testing. IIRC, Martin promised
Giovanni Bajo wrote:
Thomas Heller [EMAIL PROTECTED] wrote:
Missing are .vcproj files for Windows, both for the _ctypes.pyd extension
and the _ctypes_test.pyd extension needed for testing. IIRC, Martin
promised to create them - is this offer still valid? I could do that
myself, but only
Giovanni Bajo wrote:
Thomas Heller [EMAIL PROTECTED] wrote:
I discussed with Martin a bit about the opportunity of generating
.vcproj files with a script-driven tool. I'm going to try and
setup something as soon as I find some spare time.
Ideally this would be integrated with distutils
;-)
[Thomas Heller]
Should 'sln' and 'vcproj' be added to the extensions list? I think these are
text-files too. Although PCBuild\pcbuild.sln has a binary mime-type
property,
so the script would not change that.
I don't know whether they're text files in the SVN eol-style native
sense
Tim Peters wrote:
[Thomas Heller]
...
And I never had tried it before on a sparc machine - all the intel and ppc
processors
seem to have no problems with it.
Pentiums don't enforce natural alignment restrictions, but run much
slower on unaligned access (varying by specific chip model
Tim Peters wrote:
[Thomas Heller]
...
I could do that myself, but only for x86, while other .pyd files also have
build
settings for Itanium and x86_64. (I find it always very painful to click
through
the settings dialog in MSVC - isn't there any other way to create these
files
Tim Peters wrote:
[Thomas Heller]
...
The Linux-head is the release manager, prepaing the release on
a unixish platform, in combination with the windows guy who downloads
the source distribution and tries to compile that on Windows.
That sounds like an artificial (process-created) problem
Thomas Wouters wrote:
(about ctypes and Py_ssize_t)
you want to do that yourself, or do you want me to submit a patch? (Or I
could just check it in ;)
You can do it faster then me, I assume - so go ahead and check it in.
I'll backport it to the upstream ctypes CVS repository.
I'm not sure
[CC to python-dev again]
Hye-Shik Chang wrote:
On 3/10/06, Thomas Heller [EMAIL PROTECTED] wrote:
Hye-Shik Chang wrote:
On 3/9/06, Thomas Heller [EMAIL PROTECTED] wrote:
I've now committed ctypes 0.9.9.4 into SVN. It seems to build, at least
on the buildbots
that are online.
Good work
Thomas Wouters wrote:
[ Mailed to python-dev and python-list, as that should cover most of the
users ;P ]
There was a slight disruption on mail.python.org this morning. For about
three and a half hours, it was rejecting most of its mail with the message:
Client host [] blocked using
I know that my unittests should not rely on this, but is this change
intended?
c:\sf\ctypes_headpy24
Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32
Type help, copyright, credits or license for more information.
str(Exception)
'exceptions.Exception'
^Z
Paul Moore wrote:
On 3/7/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 06:29 AM 3/7/2006 +0100, Fredrik Lundh wrote:
see subject and http://python.org/sf/1368955
comments ?
would be nice if you could just call UUID() to create a generic UUID in a
platform-appropriate way. PEAK's uuid
Oleg Broytmann wrote:
On Tue, Mar 07, 2006 at 10:19:03PM +0100, Thomas Heller wrote:
Too bad that ctypes whill be an optional module, so I'm
not sure if it could be used in the Python library itself.
try:
import ctypes
except ImportError:
def fallback():
...
else:
def
Fuzzyman wrote:
Hello all,
Feel free to shoot this down, but a suggestion.
The operator module defines two functions :
isMappingType
isSquenceType
These return a guesstimation as to whether an object passed in supports
the mapping and sequence protocols.
These
Guido van Rossum wrote:
So here's a new proposal.
Let's add a generic missing-key handling method to the dict class, as
well as a default_factory slot initialized to None. The implementation
is like this (but in C):
def on_missing(self, key):
if self.default_factory is not None:
[cc to py-dev again]
Guido van Rossum wrote:
On 2/17/06, Thomas Heller [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
So here's a new proposal.
Let's add a generic missing-key handling method to the dict class, as
well as a default_factory slot initialized to None. The implementation
Jason Orendorff wrote:
Instead of byte literals, how about a classmethod bytes.from_hex(), which
works like this:
# two equivalent things
expected_md5_hash = bytes.from_hex('5c535024cac5199153e3834fe5c92e6a')
I hope this will also be equivalent:
expected_md5_hash = bytes.from_hex('5c
Martin v. Löwis [EMAIL PROTECTED] writes:
I just came up with an idea how to resolve the VC versioning
problems for good: Python should link with mscvrt.dll (which
is part of the operating system), not with the CRT that the
compiler provides.
To do that, we would need to compile and link
.
[Thomas Heller]
My plan is to make separate ctypes releases for 2.3 and 2.4, even after
it is integrated into Python 2.5, so it seems [2] would be better - it
must be possible to build ctypes without Python.
As I said before, docs need still to be written. I think content is
more
Hye-Shik Chang [EMAIL PROTECTED] writes:
On 1/30/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Hye-Shik Chang wrote:
I did some work to make ctypes+libffi compacter and liberal.
http://openlook.org/svnpublic/ctypes-compactffi/ (svn)
I removed sources/gcc and put sources/libffi copied
Hye-Shik Chang [EMAIL PROTECTED] writes:
On 1/30/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Well done! Would you like to derive a Python patch from that?
Yup. I'll do.
On 1/30/06, Thomas Heller [EMAIL PROTECTED] wrote:
That's great! Would you like to integrate these changes
Hye-Shik Chang [EMAIL PROTECTED] writes:
On 1/28/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Thomas Heller wrote:
Can anyone of the python-dev core team comment: can we live with the GPL
licensed aclocal.m4 file, in the source distribution and in SVN?
My understanding that doing so would
John J Lee [EMAIL PROTECTED] writes:
On Thu, 26 Jan 2006, Thomas Heller wrote:
[...]
As I said in the other thread (where the discussion should probably be
continued anyway):
http://mail.python.org/pipermail/python-dev/2006-January/060113.html
only aclocal.m4 isn't clear to me about
[I've added python-dev to cc:]
Anthony Green [EMAIL PROTECTED] writes:
On Fri, 2006-01-27 at 17:08 +0100, Thomas Heller wrote:
Anyway, another question is: Is aclocal.m4 needed at all for building
(or maybe for regenerating the configure scripts), or is it optional?
aclocal.m4 is required
Anthony Green [EMAIL PROTECTED] writes:
On Fri, 2006-01-27 at 18:03 +0100, Thomas Heller wrote:
[I've added python-dev to cc:]
Anthony Green [EMAIL PROTECTED] writes:
On Fri, 2006-01-27 at 17:08 +0100, Thomas Heller wrote:
Anyway, another question is: Is aclocal.m4 needed at all
should have no impact on the licensing of Python
itself, since it isn't really part of the resulting Python binary -
just like your C compiler isn't.
[Thomas Heller]
I guess I understood this already. The difference to the C compiler is
that the compiler is not 'bundled' with Python
Tony Meyer [EMAIL PROTECTED] writes:
-
Adding ctypes to the standard library
-
Thomas Heller suggested that ctypes be included in core Python
(starting with 2.5). The common response was that while ctypes is a
useful
Thomas Wouters [EMAIL PROTECTED] writes:
On Thu, Jan 26, 2006 at 09:54:51AM +0100, Thomas Heller wrote:
The current state is that ctypes uses GPL'd tools to build libffi, and
those can't be committed into Python SVN.
http://mail.python.org/pipermail/python-dev/2006-January/059937.html
James Y Knight [EMAIL PROTECTED] writes:
On Jan 19, 2006, at 4:24 PM, Thomas Heller wrote:
Several of these files are licensed under GPL:
aclocal.m4 config-ml.in config.guess config.sub depcomp ltcf-c.sh
ltconfig missing
Are you sure? The copies of aclocal.m4 and config-ml.in both
Ronald Oussoren [EMAIL PROTECTED] writes:
On Jan 26, 2006, at 9:22 AM, Ronald Oussoren wrote:
It shouldn't be too hard to use Python's main configure script to
calculate the information necessary to build libffi. A lot of it is
already calculated anyway (sizeof various type, endianness), some
Building the readline on OS X 10.4 fails, is this known, or am I doing
something wrong?
Thanks,
Thomas
building 'readline' extension
gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd
-DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I/Users/theller/svn/trunk/./Include
Martin v. Löwis [EMAIL PROTECTED] writes:
Guido van Rossum wrote:
On 1/16/06, Thomas Heller [EMAIL PROTECTED] wrote:
It looks like we need a pronouncement now.
Sorry. It appeared to me that there was general agreement to using a
strongly worded warning in the docs, so I tuned out
Martin v. Löwis [EMAIL PROTECTED] writes:
Guido van Rossum wrote:
On the other hand it breaks one of the most fundamental Python
guidelines: if you get a core dump (segfault etc.) it's a bug in
Python or in a 3rd party extension, not in *your* Python code. An
exception would have to be made
Tony Meyer [EMAIL PROTECTED] writes:
--
Adding zlib module to python25.dll
--
Thomas Heller and Martin Heller had been discussing whether the zlib
Should be 'Martin v. Löwis', as we all know.
module should become builtin
Delaney, Timothy (Tim) [EMAIL PROTECTED] writes:
Martin v. Löwis wrote:
So as for dealing with it somehow: I would make ctypes a dynamically
loaded module (ctypes.pyd), so administrators could remove it, and
I could also make it a separate option in the Windows installer,
so administrators
Martin v. Löwis [EMAIL PROTECTED] writes:
Guido van Rossum wrote:
On the other hand it breaks one of the most fundamental Python
guidelines: if you get a core dump (segfault etc.) it's a bug in
Python or in a 3rd party extension, not in *your* Python code. An
exception would have to be made
Martin v. Löwis [EMAIL PROTECTED] writes:
Thomas Heller wrote:
Sounds good, although it should be noted that ctypes is a package now,
with a ctypes.wrap subpackage (contains the code generator), a
ctypes.macholib subpackage (contains Bob Ippolitos macholib for OS X),
and ctypes.test
I would like to suggest to include ctypes into core Python, starting
with the 2.5 release.
ctypes is nearing the 1.0 release, and works on Windows, OS X, linux,
possibly other platforms (provided that the processor is supported by
libffi), and just recently even on Windows CE.
ctypes does not
Guido van Rossum [EMAIL PROTECTED] writes:
On 1/10/06, Delaney, Timothy (Tim) [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
On 1/10/06, Thomas Heller [EMAIL PROTECTED] wrote:
I would like to suggest to include ctypes into core Python, starting
with the 2.5 release.
On the one hand
The ast-branch merge apparently changed some formerly public functions
to macros. The two that I found out about are PyRun_SimpleString and
PyRun_InteractiveLoop, I have not checked if there are more or not.
This breaks apps which dynamically link at runtime to the Python dll
(the latest py2exe
Jeremy Hylton [EMAIL PROTECTED] writes:
On 1/3/06, Thomas Heller [EMAIL PROTECTED] wrote:
The ast-branch merge apparently changed some formerly public functions
to macros. The two that I found out about are PyRun_SimpleString and
PyRun_InteractiveLoop, I have not checked if there are more
Jeremy Hylton [EMAIL PROTECTED] writes:
On 1/3/06, Thomas Heller [EMAIL PROTECTED] wrote:
Jeremy Hylton [EMAIL PROTECTED] writes:
On 1/3/06, Thomas Heller [EMAIL PROTECTED] wrote:
The ast-branch merge apparently changed some formerly public functions
to macros. The two that I found out
[EMAIL PROTECTED] writes:
I delayed upgrading from 10.2 for awhile and was given the same
advice. I was further told (check the mac sig archives) that you'd
be able to stick with 10.3 for much longer because new apps wouldn't
need to require 10.4. So I upgraded. Now you're telling me that
Thomas Heller [EMAIL PROTECTED] writes:
Would a patch be accepted that implemented an optional second parameter
for the os.startfile function on Windows?
Sometimes I missed the possibility to write
os.startfile(mydocs.pdf, print)
The other possibility would be to extend the subprocess
Thomas Heller [EMAIL PROTECTED] writes:
Thomas Heller [EMAIL PROTECTED] writes:
Building the svn trunk on Windows fails because Python\pyarena.c is
missing in the pythoncore.vcproj file (I'm not yet up to speed with svn,
otherwise I would have checked in a fix for this myself).
Worse, when
Thomas Heller [EMAIL PROTECTED] writes:
Building the svn trunk on Windows fails because Python\pyarena.c is
missing in the pythoncore.vcproj file (I'm not yet up to speed with svn,
otherwise I would have checked in a fix for this myself).
Worse, when running the built exe it segfaults
Building the svn trunk on Windows fails because Python\pyarena.c is
missing in the pythoncore.vcproj file (I'm not yet up to speed with svn,
otherwise I would have checked in a fix for this myself).
Worse, when running the built exe it segfaults in Py_GetBuildInfo(),
because it is picking up
Would a patch be accepted that implemented an optional second parameter
for the os.startfile function on Windows?
Sometimes I missed the possibility to write
os.startfile(mydocs.pdf, print)
Thomas
___
Python-Dev mailing list
Python-Dev@python.org
Bob Ippolito [EMAIL PROTECTED] writes:
On Nov 9, 2005, at 1:22 PM, Bill Janssen wrote:
It's a shame that
1) there's no equivalent of java -jar, i.e., python -z
FILE.ZIP, and
This should work on a few platforms:
env PYTHONPATH=FILE.zip python -m some_module_in_the_zip
It should, yes -
Guido van Rossum [EMAIL PROTECTED] writes:
I vaguely recall that there were problems with distributing the debug
version of the MS runtime.
Right: the debug runtime dlls are not disributable.
Anyway, why can't you do this yourself for all Boost users? It's all
volunteer time, you know...
Shouldn't PYTHON_API_VERSION be different between 2.3 and 2.4?
It is 1012 in both versions.
I tried to detect whether PyTuple_Pack is supported, which was added in
2.4. Or is this only to detect changed apis, and not added apis?
Thomas
___
Python-Dev
[EMAIL PROTECTED] writes:
The Python source code repository is now converted to subversion;
please feel free to start checking out new sandboxes. For a few
days, this installation probably still needs to be considered in
testing. If there are no serious problems found by next Monday,
I would
Oleg Broytmann [EMAIL PROTECTED] writes:
On Fri, Sep 30, 2005 at 09:17:39AM +0200, Thomas Heller wrote:
On several occasions I have seen tracebacks in my code pointing to PIL's
__init__.py file. That is strange, because I have installed PIL but it
is used nowhere.
[skip]
The bug is present
Guido van Rossum [EMAIL PROTECTED] writes:
On 9/30/05, Thomas Heller [EMAIL PROTECTED] wrote:
On several occasions I have seen tracebacks in my code pointing to PIL's
__init__.py file. That is strange, because I have installed PIL but it
is used nowhere.
Finally I traced it down
Bob Ippolito [EMAIL PROTECTED] writes:
Personally my biggest issue with the way the CPython VM works is that
you can't reliably do multiple interpreters in a single process. If
that worked well, you could start an independent interpreter per
thread and with a per-interpreter GIL you'd
201 - 300 of 319 matches
Mail list logo
