Paul Moore writes:
> 2008/12/23 R. Bernstein :
> > 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
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
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 pyd
On Sun, 21 Dec 2008 06:45:11 am Antoine Pitrou wrote:
> Steven D'Aprano 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 stil
>> 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 wel
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.
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
> 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 a
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 mak
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:
http://mail.python.org/mailman/options/python-dev/archive
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 patc
Done: http://bugs.python.org/issue4731
On Tue, Dec 23, 2008 at 12:13 PM, Brett Cannon wrote:
> On Tue, Dec 23, 2008 at 09:59, Mike Coleman 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
>> t
On Tue, Dec 23, 2008 at 09:59, Mike Coleman 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 stupidity on my part
On Tue, Dec 23, 2008 at 08:00, Paul Moore wrote:
> 2008/12/23 Nick Coghlan :
>> 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 t
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 Sat, Dec 20, 2008 at 6:22 PM, Mike Coleman 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
tried, there we
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)
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 libr
2008/12/23 R. Bernstein :
> 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 better now.
>
Paul Moore writes:
> 2008/12/23 :
> > 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 exampl
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
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
Paul Moore writes:
> 2008/12/23 Rocky Bernstein :
> > 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?
>
2008/12/23 Nick Coghlan :
> 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
> pseudo-filename (rememberi
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
2008/12/23 :
> 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 because peo
Rocky Bernstein wrote:
> As best as I can tell, PEP 302 which discussed importer hooks and
> suggests a standard way to get file data. But it doesn't address a
> standard way to get container package and/or loader information.
If a "filename" may not be an actual filename, but instead a
pseduo-fil
2008/12/23 Rocky Bernstein :
> 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 (http://www.python.org/d
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 somebo
On 2008-12-22 22:45, Steven D'Aprano wrote:
> On Mon, 22 Dec 2008 11:20:59 pm M.-A. Lemburg wrote:
>> On 2008-12-20 23:16, Martin v. Löwis wrote:
> I will try next week to see if I can come up with a smaller,
> submittable example. Thanks.
These long exit times are usually caused by t
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:
>> 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 nee
> 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 alre
> 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
>
34 matches
Mail list logo
