[EMAIL PROTECTED] schrieb:
> I just ran "svn up" in my 2.6 sandbox and got this warning about the
> configure script:
>
> svn: File 'configure' has inconsistent newlines
> svn: Inconsistent line ending style
>
> I don't see any newlines other than just LF. Is some pro
>> I should point out that it is 'M'odified in my sandbox, but I just ran
>> autoconf (v2.63) to recreate it from a modified configure.in.
>
> Happens for me too. I investigated a bit and found that autoconf inserts a
> literal \r, i.e. chr(13), into the generated configure, and that trips up
> sv
Brett Cannon wrote:
> The old-hands on python-dev know this is where I plug my import
> rewrite vaporware. It will be in 3.1, and as part of it there will be
> a new API for handling direct imports. Jacob Kaplan-Moss and I have
Sounds good. I can finally rest in peace :) . May I suggest
that y
On Sun, Nov 30, 2008 at 5:22 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>>> I should point out that it is 'M'odified in my sandbox, but I just ran
>>> autoconf (v2.63) to recreate it from a modified configure.in.
>>
>> Happens for me too. I investigated a bit and found that autoconf inserts a
This is my first message in this list, therefore I would like to say
hello to everyone. I also hope, that I am not breaking any rules or
guidelines for sending proposals.
I would like to ask, if it is possible to provide type name of the
object invoking the exception, when Attribute error is catch
On Sun, Nov 30, 2008 at 11:41 AM, Filip Gruszczyński <[EMAIL PROTECTED]> wrote:
> This is my first message in this list, therefore I would like to say
> hello to everyone. I also hope, that I am not breaking any rules or
> guidelines for sending proposals.
>
> I would like to ask, if it is possible
On Sun, Nov 30, 2008 at 05:02, Mart Somermaa <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
>
>> The old-hands on python-dev know this is where I plug my import
>> rewrite vaporware. It will be in 3.1, and as part of it there will be
>> a new API for handling direct imports. Jacob Kaplan-Moss a
Well, if this is not an inconvenient spot that requires a gross hack
to print the type name I'd love to get some instructions or direction,
and try to change it myself. Unfortunately it's the first time I
looked into Python source and it's pretty big - I tried browsing
exceptions.c and errors.c, bu
Adam Olsen wrote:
I'm sure you'll get support for this, unless it's a really
inconvenient spot that requires a gross hack to print the type name.
Post a patch on the bug tracker.
So far I can see only one argument against the proposed idea: doc tests.
The modified exception message would brea
Filip Gruszczyński wrote:
> Well, if this is not an inconvenient spot that requires a gross hack
> to print the type name I'd love to get some instructions or direction,
> and try to change it myself. Unfortunately it's the first time I
> looked into Python source and it's pretty big - I tried brow
* Christian Heimes wrote:
> Adam Olsen wrote:
> > I'm sure you'll get support for this, unless it's a really
> > inconvenient spot that requires a gross hack to print the type name.
> > Post a patch on the bug tracker.
>
> So far I can see only one argument against the proposed idea: doc tests.
>
On Sun, Nov 30, 2008 at 4:41 PM, Filip Gruszczyński <[EMAIL PROTECTED]> wrote:
> This is my first message in this list, therefore I would like to say
> hello to everyone. I also hope, that I am not breaking any rules or
> guidelines for sending proposals.
>
> I would like to ask, if it is possible
> I would say this is due to Py_FindMethod being used.
> It is a nice and easy function to use, but it fails to set a good
> error message so maybe you are experiencing these error messages from
> modules that are using it.
Yep, found it and it does call PyErr_SetString with proper values.
I'll tr
Christian Heimes wrote:
> Adam Olsen wrote:
>> I'm sure you'll get support for this, unless it's a really
>> inconvenient spot that requires a gross hack to print the type name.
>> Post a patch on the bug tracker.
>
> So far I can see only one argument against the proposed idea: doc tests.
> The
I have done some testing and it seems, that it might not be Python
problem. Well, when I use only pure Python objects, I get really nice
description of the object (which means the type). But I am using PyQt
and it seems, that when an object is subclassing QObject (or possibly
some other class from
Filip Gruszczyński wrote:
> I have done some testing and it seems, that it might not be Python
> problem. Well, when I use only pure Python objects, I get really nice
> description of the object (which means the type). But I am using PyQt
> and it seems, that when an object is subclassing QObject (
> Yeah, any time someone implements their own attribute lookup process for
> a class (be it via __getattr__, __getattribute__ or the C equivalents),
> it is up to the reimplementation to appropriately format their error
> message if they raise AttributeError directly.
I guess, this means that I ha
> > [Hrm - looking closer at that HTML link I sent before, it says
> > specifically "Per-machine installs must install to Program Files
> > by default in order to
> > pass this test case" - that seems pretty clear...]
>
> Given that the links in Gerald's examples were under Program Files, I
> had
Here's another data point. My results are similar to Skip's
(unsurprising since I'm also using a mac). My wild guess is that the
30% vs 10% improvement is an AMD vs. Intel thing? It's not 32-bit vs.
64-bit since both David and Jakob got a 30% speedup, but David had a
32-bit build while Jakob had a
> Of course, I don't object to that and still think we should help where we
> can, but if that is true it would make the premise of this thread a little
> misleading, as obviously HP could then make *any* necessary changes without
> our agreement or even knowledge.
Perhaps. However, "help where we
On Sun, Nov 30, 2008 at 2:02 PM, Filip Gruszczyński <[EMAIL PROTECTED]> wrote:
>> Yeah, any time someone implements their own attribute lookup process for
>> a class (be it via __getattr__, __getattribute__ or the C equivalents),
>> it is up to the reimplementation to appropriately format their err
Tracing support shows up fairly heavily an a Python profile, even
though it's nearly always turned off. The attached patch against the
trunk speeds up PyBench by 2% for me. All tests pass. I have 2
questions:
1) Can other people corroborate this speedup on their machines? I'm
running on a Macbook
Can you toss the patch into the issue tracker, Jeffrey, so that any
patch comments can be done there?
-Brett
On Sun, Nov 30, 2008 at 17:54, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
> Tracing support shows up fairly heavily an a Python profile, even
> though it's nearly always turned off. The at
Done: http://bugs.python.org/issue4477
On Sun, Nov 30, 2008 at 8:14 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> Can you toss the patch into the issue tracker, Jeffrey, so that any
> patch comments can be done there?
>
> -Brett
>
> On Sun, Nov 30, 2008 at 17:54, Jeffrey Yasskin <[EMAIL PROTECTED]
24 matches
Mail list logo
