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
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.
>
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,
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
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
"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
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
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
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
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
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
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
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
[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
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
> 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
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
> //
17 matches
Mail list logo
