My understanding of the problem is that clearerr() needs to be called
before any FILE read operations on *some* platforms. The only platform I
saw mentioned was OS X. Towards that end, I have attached a much simpler
patch onto the tracker issue, which maybe somebody can verify solves the
I am hoping someone can assist me. I normally don’t care if the _ctypes
module builds or not, but I now need to have it build.
I am running Solaris 10 with Sun’s C compiler under SunStudio 11.
I don't think ctypes (rather, libffi) supports Sun C. You will need to
port it (as you have already
Martin v. Löwis wrote:
I am hoping someone can assist me. I normally don’t care if the _ctypes
module builds or not, but I now need to have it build.
I am running Solaris 10 with Sun’s C compiler under SunStudio 11.
I don't think ctypes (rather, libffi) supports Sun C. You will need to
Now that there is a package mechanism (are package mechanisms?) like
zipimporter that bundle source code into a single file, should the
notion of a file location should be adjusted to include the package
and/or importer?
Is there a standard API or routine which can extract this information
given
Martin v. Löwis wrote:
My understanding of the problem is that clearerr() needs to be called
before any FILE read operations on *some* platforms. The only platform I
saw mentioned was OS X. Towards that end, I have attached a much simpler
patch onto the tracker issue, which maybe somebody can
2008/12/23 Rocky Bernstein ro...@gnu.org:
Now that there is a package mechanism (are package mechanisms?) like
zipimporter that bundle source code into a single file, should the
notion of a file location should be adjusted to include the package
and/or importer?
Check PEP 302
2008/12/23 ro...@gnu.org:
What is wanted is a uniform way get and describe a file location
from a code object that takes into account the file might be a member
of an archive.
But a code object may not have come from a file. Ignoring the
interactive prompt (not because it's unimportant, just
M.-A. Lemburg wrote:
On 2008-12-22 22:45, Steven D'Aprano wrote:
This behaviour appears to be specific to deleting dicts, not deleting
random objects. I haven't yet confirmed that the problem still exists
in trunk (I hope to have time tonight or tomorrow), but in my previous
tests deleting
2008/12/23 Nick Coghlan ncogh...@gmail.com:
Finding a loader given only a pseudo-filename and no module is actually
possible in the specific case of zipimport, but is still pretty obscure
at this point in time:
1. Scan sys.path looking for an entry that matches the start of the
Paul Moore writes:
2008/12/23 Rocky Bernstein ro...@gnu.org:
Now that there is a package mechanism (are package mechanisms?) like
zipimporter that bundle source code into a single file, should the
notion of a file location should be adjusted to include the package
and/or importer?
At 06:55 AM 12/23/2008 -0500, Rocky Bernstein wrote:
Now that there is a package mechanism (are package mechanisms?) like
zipimporter that bundle source code into a single file, should the
notion of a file location should be adjusted to include the package
and/or importer?
Is there a standard
At 04:00 PM 12/23/2008 +, Paul Moore wrote:
PPS Seriously, setuptools and the adoptions of eggs has pushed a lot
of code to be much more careful about unwarranted assumptions that
code lives in the filesystem. That's an incredibly good thing, and
very hard to do right (witness the setuptools
Paul Moore writes:
2008/12/23 ro...@gnu.org:
What is wanted is a uniform way get and describe a file location
from a code object that takes into account the file might be a member
of an archive.
But a code object may not have come from a file.
Right. That's why I mentioned for
2008/12/23 R. Bernstein ro...@panix.com:
A use case here I am thinking of here is in a stack trace or a
debugger, or a tool which wants to show in great detail, information
from a code object obtained possibly via a frame object.
Thanks for the clarifications. I see what you're after much
Nick Coghlan writes:
3. Do what a number of standard library APIs (e.g. linecache) that
accept filenames do and also accept an optional module globals
argument.
Actually, I did this and committed a change (to pydb) before posting
any of these queries. ;-)
If a number of standard library
Martin,
Thank you very much. At least I know what I need to do now.
From: Martin v. Löwis [mailto:mar...@v.loewis.de]
I don't think ctypes (rather, libffi) supports Sun C. You will need to
port it (as you have already ruled out the other options, such as using
gcc, or not using ctypes).
On Sat, Dec 20, 2008 at 6:22 PM, Mike Coleman tutu...@gmail.com wrote:
Re held and intern_it: Haha! That's evil and extremely evil,
respectively. :-)
P.S. I tried the held idea out (interning integers in a list), and
unfortunately it didn't make that much difference. In the example I
I was thrown by the Failed to find the necessary bits to build these
modules message at the end of newer Python builds, and thought that
this indicated that the Python executable itself was not built.
That's arguably stupidity on my part, but I wonder if others will not
trip on this, too.
Would
On Tue, Dec 23, 2008 at 08:00, Paul Moore p.f.mo...@gmail.com wrote:
2008/12/23 Nick Coghlan ncogh...@gmail.com:
Finding a loader given only a pseudo-filename and no module is actually
possible in the specific case of zipimport, but is still pretty obscure
at this point in time:
1. Scan
On Tue, Dec 23, 2008 at 09:59, Mike Coleman tutu...@gmail.com wrote:
I was thrown by the Failed to find the necessary bits to build these
modules message at the end of newer Python builds, and thought that
this indicated that the Python executable itself was not built.
That's arguably
Done: http://bugs.python.org/issue4731
On Tue, Dec 23, 2008 at 12:13 PM, Brett Cannon br...@python.org wrote:
On Tue, Dec 23, 2008 at 09:59, Mike Coleman tutu...@gmail.com wrote:
I was thrown by the Failed to find the necessary bits to build these
modules message at the end of newer Python
On behalf of the Python development team and the Python community, I'm
happy to announce the release of Python 2.5.4 (final).
Python 2.5.3 unfortunately contained an incorrect patch that could
cause interpreter crashes; the only change in Python 2.5.4 relative
to 2.5.4 is the reversal of this
Allright then, I understand the problem...
Thanks a lot,
regards,
Pascal
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
I'd like to suggest here, if you are giving this code a facelift, that on
Windows you use VirtualAlloc and friends to allocate the arenas. This gives
you the most direct access to the VM manager and makes sure that a release
arena is immediately availible to the rest of the system. It also
I'd like to suggest here, if you are giving this code a facelift,
that on Windows you use VirtualAlloc and friends to allocate the
arenas. This gives you the most direct access to the VM manager and
makes sure that a release arena is immediately availible to the rest
of the system. It also
Martin v. Löwis wrote:
For more information on Python 2.5.4, including download
links for various platforms, release notes, and known issues, please
see:
http://www.python.org/2.5.4
http://www.python.org/download/releases/2.5.4/
___
Python-Dev
R. Bernstein wrote:
Nick Coghlan writes:
3. Do what a number of standard library APIs (e.g. linecache) that
accept filenames do and also accept an optional module globals
argument.
Actually, I did this and committed a change (to pydb) before posting
any of these queries. ;-)
If a
For more information on Python 2.5.4, including download
links for various platforms, release notes, and known issues, please
see:
http://www.python.org/2.5.4
http://www.python.org/download/releases/2.5.4/
Thanks for pointing that out; the original URL now also works as well
(as it
On Sun, 21 Dec 2008 06:45:11 am Antoine Pitrou wrote:
Steven D'Aprano steve at pearwood.info writes:
In November 2007, a similar problem was reported on the
comp.lang.python newsgroup. 370MB was large enough to demonstrate
the problem. I don't know if a bug was ever reported.
Do you still
Nick Coghlan writes:
R. Bernstein wrote:
Nick Coghlan writes:
3. Do what a number of standard library APIs (e.g. linecache) that
accept filenames do and also accept an optional module globals
argument.
Actually, I did this and committed a change (to pydb) before posting
R. Bernstein wrote:
Nick Coghlan writes:
R. Bernstein wrote:
Nick Coghlan writes:
3. Do what a number of standard library APIs (e.g. linecache) that
accept filenames do and also accept an optional module globals
argument.
Actually, I did this and committed a
Paul Moore writes:
2008/12/23 R. Bernstein ro...@panix.com:
A use case here I am thinking of here is in a stack trace or a
debugger, or a tool which wants to show in great detail, information
from a code object obtained possibly via a frame object.
Thanks for the clarifications.
32 matches
Mail list logo
