Hi Brett,
Here are some comments on your proposal. Sorry this took so long.
I apologize if any of these comments are out of date (but also look
forward to your answers to some of the questions, as they'll help
me understand some more of the details of your proposal). Thanks!
> Introduction
> //
> Some buildbots will fail because they got revision r51793, and it
> has a change I made to fix a problem in the subprocess module.
I've removed the offending test in r51794 and buildbots should be
happy again.
One of the ways of exploring the issue reported is using sys.stdout
as the stdout key
Some buildbots will fail because they got revision r51793, and it
has a change I made to fix a problem in the subprocess module.
Please do not rollback any changes. I'm handling the issue.
Also notice that there's no broken code there. The problem is that
the issue in subprocess is related to st
[Tim Peters]
>> Package a Python wrapper and see how popular it becomes. Some reasons
>> against trying to standardize on fdlibm were explained here:
>>
>>http://mail.python.org/pipermail/python-list/2005-July/290164.html
[Andreas Raab]
> Thanks, these are good points. About speed, do you hav
IMO it's fine. The only time you'll see this in reality is when
someone passed you the wrong type of object by mistake, and then the
type mentioned in the message is plenty help to debug it. Anyone with
even a slight understanding of 'with' knows it involves '__exit__',
and the linenumber should be
Nick Coghlan wrote:
> Ralf Schmitt wrote:
>> Nick Coghlan wrote:
>>> It looks like the problem is the call to getabspath() in getmodule().
>>> This happens every time, even if the file name is already in the
>>> modulesbyfile cache. This calls os.path.abspath() and
>>> os.path.normpath() every t
Georg Brandl wrote:
> Current trunk:
>
with 1:
> ... print "1"
> ...
> Traceback (most recent call last):
> File "", line 1, in
> AttributeError: 'int' object has no attribute '__exit__'
>
> Isn't that a bit crude? For "for i in 1" there's a better
> error message, so why shouldn't the a
Ralf Schmitt wrote:
> Nick Coghlan wrote:
>>
>> It looks like the problem is the call to getabspath() in getmodule().
>> This happens every time, even if the file name is already in the
>> modulesbyfile cache. This calls os.path.abspath() and
>> os.path.normpath() every time that inspect.findsou
Current trunk:
>>> with 1:
... print "1"
...
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'int' object has no attribute '__exit__'
Isn't that a bit crude? For "for i in 1" there's a better
error message, so why shouldn't the above give a
TypeError: 'int' object is no
Nick Coghlan wrote:
>
> It looks like the problem is the call to getabspath() in getmodule(). This
> happens every time, even if the file name is already in the modulesbyfile
> cache. This calls os.path.abspath() and os.path.normpath() every time that
> inspect.findsource() is called.
>
> That
Ralf Schmitt wrote:
> The problem seems to originate from the module=getmodule(object) in
> findsource. If I outcomment that code (or rather do a module=None),
> things seem to be back as normal. (linecache.getlines has been called
> with a None module in python 2.4's inspect.py).
It looks like
"Gustavo Carneiro" <[EMAIL PROTECTED]> writes:
> On 9/4/06, Nick Maclaren <[EMAIL PROTECTED]> wrote:
>> "Gustavo Carneiro" <[EMAIL PROTECTED]> wrote:
>> > I am now thinking of something along these lines:
>> > typedef void (*PyPendingCallNotify)(void *user_data);
>> > PyAPI_FUNC(void) Py_AddPend
Fernando Perez wrote:
>
> These enormous numbers of calls are the origin of the slowdown, and the more
> modules have been imported, the worse it gets.
--- /exp/lib/python2.5/inspect.py 2006-08-28 11:53:36.0 +0200
+++ inspect.py 2006-09-06 12:10:45.0 +0200
@@ -444,7 +444,8
Steve Holden wrote:
>> * I acknowledge that Python *code* is almost certainly going to be edited in
>> a
>> left-to-right text editor, because it's an English-based programming
>> language.
>> But the strings that string methods like partition() and rpartition() are
>> used
>> with are quite
Nick Coghlan wrote:
> Phillip J. Eby wrote:
>
>>At 04:55 PM 9/5/2006 -0400, Barry Warsaw wrote:
>>
>>>On Sep 5, 2006, at 4:43 PM, Jim Jewett wrote:
>>>
>>>
I think I finally figured out where Raymond is coming from.
For Raymond, "head" is where he started processing -- for rpartition,
Phillip J. Eby wrote:
> At 04:55 PM 9/5/2006 -0400, Barry Warsaw wrote:
>> On Sep 5, 2006, at 4:43 PM, Jim Jewett wrote:
>>
>>> I think I finally figured out where Raymond is coming from.
>>>
>>> For Raymond, "head" is where he started processing -- for rpartition,
>>> this is the .endswith part.
>
Raymond Hettinger wrote:
[...]
> That's fine with me. I accept there will always be someone who stands
> on their head [...]
You'd have to be some kind of contortionist to stand on your head.
willfully-misunderstanding-ly y'rs - steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Ho
17 matches
Mail list logo
