I'm working on refactoring Python/import.c, currently the case_ok()
function.
I was wondering about these lines:
/* new-fangled macintosh (macosx) */
#elif defined(__MACH__) defined(__APPLE__) defined(HAVE_DIRENT_H)
Is this for Mac OSX? Does the Mac have a case insensitive file system
(my
Alex Martelli [EMAIL PROTECTED] writes:
PEP: 246
Title: Object Adaptation
Minor nit (or not?): You could provide a pointer to the Liskov
substitution principle, for those reader that aren't too familiar with
that term.
Besides, the text mentions three times that LiskovViolation is a
subclass
Armin Rigo [EMAIL PROTECTED] writes:
... is that the __adapt__() and __conform__() methods should work just
like all other special methods for new-style classes. The confusion
comes from the fact that the reference implementation doesn't do that.
It should be fixed by replacing:
conform
Anthony Baxter [EMAIL PROTECTED] writes:
As I'd kinda feared, my return to work has left me completely
buried this week, and so I'm going to have to push 2.3.5 until
next week. Thomas and Fred: does one of the days in the
range 25-27 January suit you? The 26th is a public holiday here,
and
The 2.4 python.org installer installs msvcr71.dll on the target system.
If someone uses py2exe or a similar tool to create a frozen application,
is he allowed to redistribute this msvcr71.dll to other users together
with his application or not, even if he doesn't own MSVC?
This was asked on the
Neil Hodgson [EMAIL PROTECTED] writes:
Anders J. Munch:
1. John X. Programmer buys the product, agrees to the EULA and puts
the DLL up for download, with the explicit and stated intent of
distributing it to anyone who needs it.
Disallowed in 3.1(a):
# you agree: ... to distribute
Tim Peters [EMAIL PROTECTED] writes:
[Trent Mick]
Has anyone else noticed that viewcvs is broken on SF?
It failed the same way from Virginia just now. I suppose that's your
reward for kindly updating the Python copyright wink.
The failure lasts already for several days:
The following message is a courtesy copy of an article
that has been posted to comp.lang.python as well.
[CC to python-dev]
Fuzzyman [EMAIL PROTECTED] writes:
Python 2.4 is built with Microsoft Visiual C++ 7. This means that it
uses msvcr7.dll, which *isn't* a standard part of the windows
Phillip J. Eby [EMAIL PROTECTED] writes:
At 05:34 AM 3/14/05 -0800, Michael Chermside wrote:
Nice... thanks. But I have to ask: is this really the right set of metadata to
be updating? Here are a few things that perhaps ought be copied by
update_meta:
f.__name__ (already included)
I always wondered why there usually is very sloppy error checking in
initmodule functions. Usually it goes like this (I removed
declarations and some other lines for clarity):
PyMODINIT_FUNC
PyInit_zlib(void)
{
m = Py_InitModule4(zlib, zlib_methods,
Michiel De Hoon [EMAIL PROTECTED] writes:
I'd like to ask your attention to this patch:
[ 1049855 ] PyOS_InputHook inconsistency on Windows
Kurt Kaiser has already looked at this patch, but was hesitant to check it in
because he wasn't able to test it on Windows. I'd be happy to send a
Nick Coghlan [EMAIL PROTECTED] writes:
Gareth McCaughan wrote:
[Keith Dart:]
By normal integer I mean the mathematical definition.
Then you aren't (to me) making sense. You were distinguishing
this from a unified int/long. So far as I can see, a unified int/long
type *does* implement
Guido van Rossum:
Whoa! Do we really need a completely different mechanism for doing the
same stuff we can already do?
Neil Hodgson [EMAIL PROTECTED] writes:
One benefit I see for the path module is that it makes it easier to
write code that behaves correctly with unicode paths on
Neil Hodgson [EMAIL PROTECTED] writes:
Thomas Heller:
OTOH, Python is lacking a lot when you have to handle unicode strings on
sys.path, in command line arguments, environment variables and maybe
other places.
A new patch #1231336 Add unicode for sys.argv, os.environ,
os.system
Neil Hodgson [EMAIL PROTECTED] writes:
Guido van Rossum:
Ah, sigh. I didn't know that os.listdir() behaves differently when the
argument is Unicode. Does os.listdir(.) really behave differently
than os.listdir(u.)?
Yes:
os.listdir(.)
['abc', '']
os.listdir(u.)
[u'abc',
Brett Cannon [EMAIL PROTECTED] writes:
On 8/10/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
Then I don't follow what you mean by moved under os.
In other words, to get the exception, do ``from os import
WindowsError``. Unfortunately we don't have a generic win module to
put it
Neil Schemenauer [EMAIL PROTECTED] writes:
[Please mail followups to [EMAIL PROTECTED]
The PEP has been rewritten based on a suggestion by Guido to change
str() rather than adding a new built-in function. Based on my
testing, I believe the idea is feasible. It would be helpful if
people
Michael Hudson [EMAIL PROTECTED] writes:
Raymond Hettinger [EMAIL PROTECTED] writes:
[Raymond Hettinger]
This patch should be reverted or fixed so that the Py2.5 build works
again.
It contains a disasterous search and replace error that prevents it
from
compiling. Hence, it
Fredrik Lundh [EMAIL PROTECTED] writes:
Greg Ewing wrote:
Maybe backquotes could be repurposed in Py3k for interpolated
string literals?
backquotes are a PITA to type on many non-US keyboards.
Even more since they are especially broken in Windows XEmacs.
Thomas
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
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
[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
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
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...
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 -
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
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
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
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
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
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
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
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
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
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
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
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/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
.
[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
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
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
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
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
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
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
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:
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
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, 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
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
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
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
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
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
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
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
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
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 ?
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
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
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:
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
1 - 100 of 319 matches
Mail list logo
