Re: [Python-Dev] What does this mean?

[Georg Brandl]

[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 property on the
> file hosed?
> 
> 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
svn. It occurs at the definition of "ac_cr".

I've since always asked Benjamin regenerate configure, who seems to have
a setup where ac_cr isn't inserted into the generated file.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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%40mail-archive.com

Re: [Python-Dev] autoconf version (Was: What does this mean?)

[Martin v. Löwis]

>> 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
> svn. It occurs at the definition of "ac_cr".
> 
> I've since always asked Benjamin regenerate configure, who seems to have
> a setup where ac_cr isn't inserted into the generated file.

For that very reason, we should continue to use autoconf 2.61. Not sure
why Benjamin put in the comment that 2.63 is being used. If you look at
the configure files that Benjamin has checked in, you'll notice that he
has been using 2.61.

Regards,
Martin
___
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%40mail-archive.com

Re: [Python-Dev] __import__ problems

[Mart Somermaa]

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 you disable the hack while you are at it as well so that
people will be aware of their misdoings?

> talked about Django's need for this as PyCon so I am very aware of
> needing this API and it will be addressed in the simplest way possible
> (heck, the __import__ API might actually become a wrapper around the
> simpler API in the end).

Even better (the bracketed part).

> And since nothing can go into 3.0 anyway,
> there is no need to rush into solving this right now.

Agreed, I just wanted to get the ball rolling.

Let me know if you want me to do some gruntwork (tests,
documentation) once the improved implementation is taking shape.

---

As for the other comments, I'll try to wrap things up:

* I did get the impression from some posts that it was assumed
  to be somehow "my problem" -- although indeed seeing both
  'foo' and 'foo.' when printing sys.modules in a popular web
  framework I frequently use makes me wince in discomfort, the
  hack is present in 2000 lines in various projects as seen in
  the Google Code Search.

* runpy.run_module() is not the solution as it runs the module
  each time it is called and particularly because access to the
  submodule object is generally needed (again, look around in
  the Google Code Search results).

* changing the signature of __import__ is out of question both
  because it would break the existing __import__ replacements
  and would perpetuate the wrong assumption that it should be
  directly used (instead of the presently missing simpler
  interface).

---

It looks that the

__import__(modname)
mod = sys.modules[modname]

idiom is the clear winner for the import submodule use case.
I've updated http://bugs.python.org/issue4457 with proposed
additions to current __import__ docs. Once the simpler interface
emerges, the docs should be updated again and __import__
use should be discouraged.
___
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%40mail-archive.com

Re: [Python-Dev] autoconf version (Was: What does this mean?)

[Benjamin Peterson]

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
>> literal \r, i.e. chr(13), into the generated configure, and that trips up
>> svn. It occurs at the definition of "ac_cr".
>>
>> I've since always asked Benjamin regenerate configure, who seems to have
>> a setup where ac_cr isn't inserted into the generated file.
>
> For that very reason, we should continue to use autoconf 2.61. Not sure
> why Benjamin put in the comment that 2.63 is being used. If you look at
> the configure files that Benjamin has checked in, you'll notice that he
> has been using 2.61.

I've been trying to find an autoconf that works with all my projects,
so when I wrote, that I may have been using 1.63. Anyway, I've updated
the comment to say 1.61.



-- 
Cheers,
Benjamin Peterson
"There's nothing quite as beautiful as an oboe... except a chicken
stuck in a vacuum cleaner."
___
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%40mail-archive.com

[Python-Dev] Attribute error: providing type name

[Filip Gruszczyński]

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 catched. It is
done for functions, like:

AttributeError: 'function' object has no attribute 'getValue'

but for some objects there is only:

AttributeError: connectToBases

This is cool, when you know exactly what type of object cast the
exception. But if there might be many of them, you must do one of two
things: add print statement just before the line with the exception
and check the type or iterate over all classes that might appear them.
Showing the class name would solve this problem and could save a lot
of time.

-- 
Filip Gruszczyński
___
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%40mail-archive.com

Re: [Python-Dev] Attribute error: providing type name

[Adam Olsen]

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 to provide type name of the
> object invoking the exception, when Attribute error is catched. It is
> done for functions, like:
>
> AttributeError: 'function' object has no attribute 'getValue'
>
> but for some objects there is only:
>
> AttributeError: connectToBases
>
> This is cool, when you know exactly what type of object cast the
> exception. But if there might be many of them, you must do one of two
> things: add print statement just before the line with the exception
> and check the type or iterate over all classes that might appear them.
> Showing the class name would solve this problem and could save a lot
> of time.

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.


-- 
Adam Olsen, aka Rhamphoryncus
___
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%40mail-archive.com

Re: [Python-Dev] __import__ problems

[Brett Cannon]

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 and I have
>
> Sounds good. I can finally rest in peace :) . May I suggest
> that you disable the hack while you are at it as well so that
> people will be aware of their misdoings?
>

Possibly since 'warnings' was re-written in C partially so it could be
used by the import rewrite. I will worry about that more when the code
actually lands.

>> talked about Django's need for this as PyCon so I am very aware of
>> needing this API and it will be addressed in the simplest way possible
>> (heck, the __import__ API might actually become a wrapper around the
>> simpler API in the end).
>
> Even better (the bracketed part).
>

Well, it's only a maybe. There  is the balance between a good API for
people versus a good API for the compiler to compile to. Not sure if
they will line up nicely or not.

>> And since nothing can go into 3.0 anyway,
>> there is no need to rush into solving this right now.
>
> Agreed, I just wanted to get the ball rolling.
>
> Let me know if you want me to do some gruntwork (tests,
> documentation) once the improved implementation is taking shape.
>

As of right now I am rewriting the tests to use more mock objects as I
was originally testing too often against actual files. I also needed
to untangle the tests as I was testing too much at once. Unfortunately
it's not grunt work as I am purposefully not looking at the old tests
to make sure that I get as much test coverage as possible in terms of
semantics (they are rather involved as I am sure you have noticed).

After that it's little compatibility things and then cleaning up the
bootstrapping code.

As for the docs, once the code  is in the docs will need to be
thoroughly rewritten so they are finally updated to include PEP 302.
But one thing at a time. =)

-Brett
___
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%40mail-archive.com

Re: [Python-Dev] Attribute error: providing type name

[Filip Gruszczyński]

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, but couldn't find any simple place, where I
could place the required type information.

I can of course post it on the bug tracker, but I believe I could
learn something on this ;-) And I don't like missing a chance to get a
glance at something new.

> 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.
>
>
> --
> Adam Olsen, aka Rhamphoryncus
>



-- 
Filip Gruszczyński
___
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%40mail-archive.com

Re: [Python-Dev] Attribute error: providing type name

[Christian Heimes]

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 break existing doc tests.


Christian

___
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%40mail-archive.com

Re: [Python-Dev] Attribute error: providing type name

[Martin v. Löwis]

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 browsing
> exceptions.c and errors.c, but couldn't find any simple place, where I
> could place the required type information.

You need to look at the places that raise AttributeError; grep the
entire source for it (both C and .py files). In PyObject_GetAttr
(or PyObject_GenericGetAttr), you'll find the place where the case
of functions is dealt with.

Alternatively, pick a specific test case, and try to find out where
it raises the exception. E.g. set a debugger breakpoint, on
PyErr_SetString and PyErr_Format, and see whether your test case
triggers that breakpoint. Then walk up the stack to find out where
the exception is raised.

> I can of course post it on the bug tracker, but I believe I could
> learn something on this ;-) 

I sure hope so.

> And I don't like missing a chance to get a
> glance at something new.

Good luck!

Martin
___
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%40mail-archive.com

Re: [Python-Dev] Attribute error: providing type name

[André Malo]

* 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 modified exception message would break existing doc tests.

As the exception text is officially not part of the API, I'd say, let them.

nd
-- 
Winnetous Erbe: 
___
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%40mail-archive.com

Re: [Python-Dev] Attribute error: providing type name

[Guilherme Polo]

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 to provide type name of the
> object invoking the exception, when Attribute error is catched. It is
> done for functions, like:
>
> AttributeError: 'function' object has no attribute 'getValue'
>
> but for some objects there is only:
>
> AttributeError: connectToBases

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.

I have added a patch in http://bugs.python.org/issue4475

>
> This is cool, when you know exactly what type of object cast the
> exception. But if there might be many of them, you must do one of two
> things: add print statement just before the line with the exception
> and check the type or iterate over all classes that might appear them.
> Showing the class name would solve this problem and could save a lot
> of time.
>
> --
> Filip Gruszczyński
> ___
> 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/ggpolo%40gmail.com
>



-- 
-- Guilherme H. Polo Goncalves
___
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%40mail-archive.com

Re: [Python-Dev] Attribute error: providing type name

[Filip Gruszczyński]

> 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 try to change this, without breaking anything. Thanks for help :)

-- 
Filip Gruszczyński
___
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%40mail-archive.com

Re: [Python-Dev] Attribute error: providing type name

[Nick Coghlan]

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 modified exception message would break existing doc tests.

It wouldn't be the first time we've broken doc tests that way. Since the
details of the error messages aren't guaranteed to remain the same
across releases, doctests that aren't part of Python's own test suite
really should be using IGNORE_EXCEPTION_DETAIL when checking for
exceptions that are raised directly by the interpreter or standard library.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
___
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%40mail-archive.com

Re: [Python-Dev] Attribute error: providing type name

[Filip Gruszczyński]

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 qt, that can be not derived from QObject) it can
only display information about the name of the function. PyQt are
python bindings for C++ qt library. Can this be the reason for not
displaying type of the object?

2008/11/30 Nick Coghlan <[EMAIL PROTECTED]>:
> 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 modified exception message would break existing doc tests.
>
> It wouldn't be the first time we've broken doc tests that way. Since the
> details of the error messages aren't guaranteed to remain the same
> across releases, doctests that aren't part of Python's own test suite
> really should be using IGNORE_EXCEPTION_DETAIL when checking for
> exceptions that are raised directly by the interpreter or standard library.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
> ---
> ___
> 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/gruszczy%40gmail.com
>



-- 
Filip Gruszczyński
___
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%40mail-archive.com

Re: [Python-Dev] Attribute error: providing type name

[Nick Coghlan]

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 (or possibly
> some other class from qt, that can be not derived from QObject) it can
> only display information about the name of the function. PyQt are
> python bindings for C++ qt library. Can this be the reason for not
> displaying type of the object?

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.

This could possibly be made easier to do correctly via a specific
AttributeError class method (also exposed through the C API) that
accepted a type object and an attribute name and then produced a nicely
formatted error message the way the builtin types do.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
___
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%40mail-archive.com

Re: [Python-Dev] Attribute error: providing type name

[Filip Gruszczyński]

> 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 have to go to Phil Thompson at Riverbank
and try to convince him to change the message.

-- 
Filip Gruszczyński
___
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%40mail-archive.com

Re: [Python-Dev] Python for windows.

[Mark Hammond]

> > [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 assumed that HP were tweaking the installer at least that much...

But wouldn't that leave us in the situation where Python's installer is
*not* "OEM Ready", nor has it been certified as such - but an installer
based on ours, but with unspecified changes has?

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.

Cheers,

Mark

___
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%40mail-archive.com

Re: [Python-Dev] [ANN] VPython 0.1

[Jeffrey Yasskin]

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 64-bit build.

There's also a crashing bug on:
  def f():
a+=1
  f()
I have a fix by changing the load_fast opcode to adjust the stack on
error, but it requires removing all the superinstructions involving
load_fast, which costs me 1-2% in performance. The fix is not included
in these numbers.

---
PYBENCH 2.0
---
* using CPython 2.6+ (unknown, Nov 19 2008, 09:14:51) [GCC 4.0.1
(Apple Inc. build 5484)]
* disabled garbage collection
* system check interval set to maximum: 2147483647
* using timer: time.time

---
Benchmark: /Users/jyasskin/src/python/bzr/2.6_cxx/build_c4.0/pybench.out
---

   Rounds: 10
   Warp:   10
   Timer:  time.time

   Machine Details:
  Platform ID:Darwin-9.5.0-i386-32bit
  Processor:  i386

   Python:
  Implementation: CPython
  Executable:
/Users/jyasskin/src/python/bzr/2.6_cxx/build_c4.0/python.exe
  Version:2.6.0
  Compiler:   GCC 4.0.1 (Apple Inc. build 5484)
  Bits:   32bit
  Build:  Nov 19 2008 09:14:51 (#unknown)
  Unicode:UCS2


---
Comparing with: /Users/jyasskin/src/python/bzr/2.6_vmgen/build/pybench.out
---

   Rounds: 10
   Warp:   10
   Timer:  time.time

   Machine Details:
  Platform ID:Darwin-9.5.0-i386-32bit
  Processor:  i386

   Python:
  Implementation: CPython
  Executable: /Users/jyasskin/src/python/bzr/2.6_vmgen/build/python.exe
  Version:2.6.0
  Compiler:   GCC 4.0.1 (Apple Inc. build 5488)
  Bits:   32bit
  Build:  Nov 24 2008 20:20:04 (#unknown)
  Unicode:UCS2


Test minimum run-timeaverage  run-time
thisother   diffthisother   diff
---
 BuiltinFunctionCalls:   131ms   118ms  +10.9%   134ms   120ms  +11.3%
  BuiltinMethodLookup:   109ms90ms  +20.9%   111ms96ms  +15.7%
CompareFloats:91ms65ms  +40.4%92ms66ms  +39.2%
CompareFloatsIntegers:99ms85ms  +16.5%99ms85ms  +16.4%
  CompareIntegers:83ms49ms  +67.3%83ms50ms  +67.2%
   CompareInternedStrings:93ms72ms  +30.3%95ms73ms  +29.3%
 CompareLongs:84ms62ms  +36.6%86ms63ms  +37.3%
   CompareStrings:82ms68ms  +20.2%84ms71ms  +17.7%
   CompareUnicode:   104ms89ms  +17.5%   109ms94ms  +15.1%
   ComplexPythonFunctionCalls:   139ms   126ms  +11.1%   142ms   127ms  +11.4%
ConcatStrings:   149ms   138ms   +8.0%   154ms   148ms   +3.8%
ConcatUnicode:88ms84ms   +4.7%90ms85ms   +5.8%
  CreateInstances:   142ms   130ms   +9.5%   143ms   131ms   +9.0%
   CreateNewInstances:   106ms99ms   +7.4%   107ms99ms   +7.6%
  CreateStringsWithConcat:   116ms94ms  +23.3%   118ms95ms  +25.0%
  CreateUnicodeWithConcat:91ms83ms  +10.3%92ms84ms   +9.6%
 DictCreation:92ms80ms  +14.8%93ms81ms  +14.8%
DictWithFloatKeys:95ms90ms   +5.2%98ms91ms   +6.7%
  DictWithIntegerKeys:99ms91ms   +9.1%   104ms92ms  +13.8%
   DictWithStringKeys:83ms73ms  +13.8%87ms76ms  +14.9%
 ForLoops:77ms62ms  +23.2%79ms63ms  +24.5%
   IfThenElse:78ms55ms  +41.6%79ms56ms  +42.7%
  ListSlicing:   115ms   185ms  -37.7%   120ms   187ms  -36.1%
   NestedForLoops:   135ms   100ms  +35.0%   136ms   102ms  +33.8%
 NormalClassAttribute:   105ms98ms   +6.9%   106ms99ms   +6.8%
  NormalInstanceAttribute:93ms84ms  +11.2%94ms85ms  +10.8%
  PythonFunctionCalls:   102ms90ms  +13.5%   105ms93ms  +13.4%
PythonMethodCalls:   147ms   133ms  +10.5%   148ms   135ms   +9.7%
Recursion:   142ms   118ms  +20.2%   147ms   119ms  +22.9%
 SecondImport:99ms98ms   +1.3%   100ms   100ms   +0.1%
  SecondPackageImport:   102ms  

Re: [Python-Dev] Python for windows.

[Martin v. Löwis]

> 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 can" is about right. If its only the
changes HP discussed so far, I think we should be able to help.
For the Program Files issue, without going into the discussion whether
Python's defaults are good or not, I think there would be still a number
of technical solutions (such as providing a merge module which changes
the default).

Regards,
Martin
___
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%40mail-archive.com

Re: [Python-Dev] Attribute error: providing type name

[Alex Martelli]

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 error
>> message if they raise AttributeError directly.
>
> I guess, this means that I have to go to Phil Thompson at Riverbank
> and try to convince him to change the message.

Yes, but he should be able to change it in one place (in sip, the C++
to Python wrapper generator he's also authored and uses for PyQt) AND
it would make sip even better, so he may want to put it on his
backlog.

Alex
___
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%40mail-archive.com

[Python-Dev] Patch to speed up non-tracing case in PyEval_EvalFrameEx (2% on pybench)

[Jeffrey Yasskin]

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 Pro (Intel Core2 processor, probably Merom) with
a 32-bit build from Apple's gcc-4.0.1. (Apple's gcc consistently
produces a faster python than gcc-4.3.)

2) Assuming this speeds things up for most people, should I check it
in anywhere besides the trunk? I assume it's out for 3.0; is it in for
2.6.1 or 3.0.1?



Pybench output:

---
PYBENCH 2.0
---
* using CPython 2.7a0 (trunk:67458M, Nov 30 2008, 17:14:10) [GCC 4.0.1
(Apple Inc. build 5488)]
* disabled garbage collection
* system check interval set to maximum: 2147483647
* using timer: time.time

---
Benchmark: pybench.out
---

Rounds: 10
Warp:   10
Timer:  time.time

Machine Details:
   Platform ID:Darwin-9.5.0-i386-32bit
   Processor:  i386

Python:
   Implementation: CPython
   Executable:
/Users/jyasskin/src/python/trunk-fast-tracing/build/python.exe
   Version:2.7.0
   Compiler:   GCC 4.0.1 (Apple Inc. build 5488)
   Bits:   32bit
   Build:  Nov 30 2008 17:14:10 (#trunk:67458M)
   Unicode:UCS2


---
Comparing with: ../build_orig/pybench.out
---

Rounds: 10
Warp:   10
Timer:  time.time

Machine Details:
   Platform ID:Darwin-9.5.0-i386-32bit
   Processor:  i386

Python:
   Implementation: CPython
   Executable:
/Users/jyasskin/src/python/trunk-fast-tracing/build_orig/python.exe
   Version:2.7.0
   Compiler:   GCC 4.0.1 (Apple Inc. build 5488)
   Bits:   32bit
   Build:  Nov 30 2008 13:51:09 (#trunk:67458)
   Unicode:UCS2


Test minimum run-timeaverage  run-time
 thisother   diffthisother   diff
---
  BuiltinFunctionCalls:   127ms   130ms   -2.4%   129ms   132ms   -2.1%
   BuiltinMethodLookup:90ms93ms   -3.2%91ms94ms   -3.1%
 CompareFloats:88ms91ms   -3.3%89ms93ms   -4.3%
 CompareFloatsIntegers:97ms99ms   -2.1%97ms   100ms   -2.4%
   CompareIntegers:79ms82ms   -4.2%79ms85ms   -6.1%
CompareInternedStrings:90ms92ms   -2.4%94ms94ms   -0.9%
  CompareLongs:86ms83ms   +3.6%87ms84ms   +3.5%
CompareStrings:80ms82ms   -3.1%81ms83ms   -2.3%
CompareUnicode:   103ms   105ms   -2.3%   106ms   108ms   -1.5%
ComplexPythonFunctionCalls:   139ms   137ms   +1.3%   140ms   139ms   +0.1%
 ConcatStrings:   142ms   151ms   -6.0%   156ms   154ms   +1.1%
 ConcatUnicode:87ms92ms   -5.4%89ms94ms   -5.7%
   CreateInstances:   142ms   144ms   -1.4%   144ms   145ms   -1.1%
CreateNewInstances:   107ms   109ms   -2.3%   108ms   111ms   -2.1%
   CreateStringsWithConcat:   114ms   137ms  -17.1%   117ms   139ms  -16.0%
   CreateUnicodeWithConcat:92ms   101ms   -9.2%95ms   102ms   -7.2%
  DictCreation:77ms81ms   -4.4%80ms85ms   -5.9%
 DictWithFloatKeys:91ms   107ms  -14.5%93ms   109ms  -14.6%
   DictWithIntegerKeys:95ms94ms   +1.4%   108ms96ms  +12.3%
DictWithStringKeys:83ms88ms   -5.8%84ms88ms   -4.7%
  ForLoops:72ms72ms   -0.1%79ms74ms   +5.8%
IfThenElse:83ms80ms   +3.9%85ms80ms   +5.3%
   ListSlicing:   117ms   118ms   -0.7%   118ms   121ms   -1.8%
NestedForLoops:   116ms   119ms   -2.4%   121ms   121ms   +0.0%
  NormalClassAttribute:   106ms   115ms   -7.7%   108ms   117ms   -7.7%
   NormalInstanceAttribute:96ms98ms   -2.3%97ms   100ms   -3.1%
   PythonFunctionCalls:92ms95ms   -3.7%94ms99ms   -5.2%
 PythonMethodCalls:   147ms   147ms   +0.1%   152ms   149ms   +2.1%
 Recursion:   135ms   136ms   -0.3%   140ms   144ms   -2.9%
  SecondImport:   101ms99ms   +2.1%   103ms   101ms   +2.2%
  

Re: [Python-Dev] Patch to speed up non-tracing case in PyEval_EvalFrameEx (2% on pybench)

[Brett Cannon]

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 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 Pro (Intel Core2 processor, probably Merom) with
> a 32-bit build from Apple's gcc-4.0.1. (Apple's gcc consistently
> produces a faster python than gcc-4.3.)
>
> 2) Assuming this speeds things up for most people, should I check it
> in anywhere besides the trunk? I assume it's out for 3.0; is it in for
> 2.6.1 or 3.0.1?
>
>
>
> Pybench output:
>
> ---
> PYBENCH 2.0
> ---
> * using CPython 2.7a0 (trunk:67458M, Nov 30 2008, 17:14:10) [GCC 4.0.1
> (Apple Inc. build 5488)]
> * disabled garbage collection
> * system check interval set to maximum: 2147483647
> * using timer: time.time
>
> ---
> Benchmark: pybench.out
> ---
>
>Rounds: 10
>Warp:   10
>Timer:  time.time
>
>Machine Details:
>   Platform ID:Darwin-9.5.0-i386-32bit
>   Processor:  i386
>
>Python:
>   Implementation: CPython
>   Executable:
> /Users/jyasskin/src/python/trunk-fast-tracing/build/python.exe
>   Version:2.7.0
>   Compiler:   GCC 4.0.1 (Apple Inc. build 5488)
>   Bits:   32bit
>   Build:  Nov 30 2008 17:14:10 (#trunk:67458M)
>   Unicode:UCS2
>
>
> ---
> Comparing with: ../build_orig/pybench.out
> ---
>
>Rounds: 10
>Warp:   10
>Timer:  time.time
>
>Machine Details:
>   Platform ID:Darwin-9.5.0-i386-32bit
>   Processor:  i386
>
>Python:
>   Implementation: CPython
>   Executable:
> /Users/jyasskin/src/python/trunk-fast-tracing/build_orig/python.exe
>   Version:2.7.0
>   Compiler:   GCC 4.0.1 (Apple Inc. build 5488)
>   Bits:   32bit
>   Build:  Nov 30 2008 13:51:09 (#trunk:67458)
>   Unicode:UCS2
>
>
> Test minimum run-timeaverage  run-time
> thisother   diffthisother   diff
> ---
>  BuiltinFunctionCalls:   127ms   130ms   -2.4%   129ms   132ms   -2.1%
>   BuiltinMethodLookup:90ms93ms   -3.2%91ms94ms   -3.1%
> CompareFloats:88ms91ms   -3.3%89ms93ms   -4.3%
> CompareFloatsIntegers:97ms99ms   -2.1%97ms   100ms   -2.4%
>   CompareIntegers:79ms82ms   -4.2%79ms85ms   -6.1%
>CompareInternedStrings:90ms92ms   -2.4%94ms94ms   -0.9%
>  CompareLongs:86ms83ms   +3.6%87ms84ms   +3.5%
>CompareStrings:80ms82ms   -3.1%81ms83ms   -2.3%
>CompareUnicode:   103ms   105ms   -2.3%   106ms   108ms   -1.5%
>ComplexPythonFunctionCalls:   139ms   137ms   +1.3%   140ms   139ms   +0.1%
> ConcatStrings:   142ms   151ms   -6.0%   156ms   154ms   +1.1%
> ConcatUnicode:87ms92ms   -5.4%89ms94ms   -5.7%
>   CreateInstances:   142ms   144ms   -1.4%   144ms   145ms   -1.1%
>CreateNewInstances:   107ms   109ms   -2.3%   108ms   111ms   -2.1%
>   CreateStringsWithConcat:   114ms   137ms  -17.1%   117ms   139ms  -16.0%
>   CreateUnicodeWithConcat:92ms   101ms   -9.2%95ms   102ms   -7.2%
>  DictCreation:77ms81ms   -4.4%80ms85ms   -5.9%
> DictWithFloatKeys:91ms   107ms  -14.5%93ms   109ms  -14.6%
>   DictWithIntegerKeys:95ms94ms   +1.4%   108ms96ms  +12.3%
>DictWithStringKeys:83ms88ms   -5.8%84ms88ms   -4.7%
>  ForLoops:72ms72ms   -0.1%79ms74ms   +5.8%
>IfThenElse:83ms80ms   +3.9%85ms80ms   +5.3%
>   ListSlicing:   117ms   118ms   -0.7%   118ms   121ms   -1.8%
>NestedForLoops:   116ms   119ms   -2.4%   121ms   121ms   +0.0%
>  NormalClassAttribute:   106ms   115ms   -7.7%   108ms   117ms   -7.7%
>   NormalInstanceAttribute:96ms98ms   -2.3%97ms   100ms   -3.1%
>   P

Re: [Python-Dev] Patch to speed up non-tracing case in PyEval_EvalFrameEx (2% on pybench)

[Jeffrey Yasskin]

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]> wrote:
>> 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 Pro (Intel Core2 processor, probably Merom) with
>> a 32-bit build from Apple's gcc-4.0.1. (Apple's gcc consistently
>> produces a faster python than gcc-4.3.)
>>
>> 2) Assuming this speeds things up for most people, should I check it
>> in anywhere besides the trunk? I assume it's out for 3.0; is it in for
>> 2.6.1 or 3.0.1?
>>
>>
>>
>> Pybench output:
>>
>> ---
>> PYBENCH 2.0
>> ---
>> * using CPython 2.7a0 (trunk:67458M, Nov 30 2008, 17:14:10) [GCC 4.0.1
>> (Apple Inc. build 5488)]
>> * disabled garbage collection
>> * system check interval set to maximum: 2147483647
>> * using timer: time.time
>>
>> ---
>> Benchmark: pybench.out
>> ---
>>
>>Rounds: 10
>>Warp:   10
>>Timer:  time.time
>>
>>Machine Details:
>>   Platform ID:Darwin-9.5.0-i386-32bit
>>   Processor:  i386
>>
>>Python:
>>   Implementation: CPython
>>   Executable:
>> /Users/jyasskin/src/python/trunk-fast-tracing/build/python.exe
>>   Version:2.7.0
>>   Compiler:   GCC 4.0.1 (Apple Inc. build 5488)
>>   Bits:   32bit
>>   Build:  Nov 30 2008 17:14:10 (#trunk:67458M)
>>   Unicode:UCS2
>>
>>
>> ---
>> Comparing with: ../build_orig/pybench.out
>> ---
>>
>>Rounds: 10
>>Warp:   10
>>Timer:  time.time
>>
>>Machine Details:
>>   Platform ID:Darwin-9.5.0-i386-32bit
>>   Processor:  i386
>>
>>Python:
>>   Implementation: CPython
>>   Executable:
>> /Users/jyasskin/src/python/trunk-fast-tracing/build_orig/python.exe
>>   Version:2.7.0
>>   Compiler:   GCC 4.0.1 (Apple Inc. build 5488)
>>   Bits:   32bit
>>   Build:  Nov 30 2008 13:51:09 (#trunk:67458)
>>   Unicode:UCS2
>>
>>
>> Test minimum run-timeaverage  run-time
>> thisother   diffthisother   diff
>> ---
>>  BuiltinFunctionCalls:   127ms   130ms   -2.4%   129ms   132ms   
>> -2.1%
>>   BuiltinMethodLookup:90ms93ms   -3.2%91ms94ms   
>> -3.1%
>> CompareFloats:88ms91ms   -3.3%89ms93ms   
>> -4.3%
>> CompareFloatsIntegers:97ms99ms   -2.1%97ms   100ms   
>> -2.4%
>>   CompareIntegers:79ms82ms   -4.2%79ms85ms   
>> -6.1%
>>CompareInternedStrings:90ms92ms   -2.4%94ms94ms   
>> -0.9%
>>  CompareLongs:86ms83ms   +3.6%87ms84ms   
>> +3.5%
>>CompareStrings:80ms82ms   -3.1%81ms83ms   
>> -2.3%
>>CompareUnicode:   103ms   105ms   -2.3%   106ms   108ms   
>> -1.5%
>>ComplexPythonFunctionCalls:   139ms   137ms   +1.3%   140ms   139ms   
>> +0.1%
>> ConcatStrings:   142ms   151ms   -6.0%   156ms   154ms   
>> +1.1%
>> ConcatUnicode:87ms92ms   -5.4%89ms94ms   
>> -5.7%
>>   CreateInstances:   142ms   144ms   -1.4%   144ms   145ms   
>> -1.1%
>>CreateNewInstances:   107ms   109ms   -2.3%   108ms   111ms   
>> -2.1%
>>   CreateStringsWithConcat:   114ms   137ms  -17.1%   117ms   139ms  
>> -16.0%
>>   CreateUnicodeWithConcat:92ms   101ms   -9.2%95ms   102ms   
>> -7.2%
>>  DictCreation:77ms81ms   -4.4%80ms85ms   
>> -5.9%
>> DictWithFloatKeys:91ms   107ms  -14.5%93ms   109ms  
>> -14.6%
>>   DictWithIntegerKeys:95ms94ms   +1.4%   108ms96ms  
>> +12.3%
>>DictWithStringKeys:83ms88ms   -5.8%84ms88ms   
>> -4.7%
>>  ForLoops:72ms72ms   -0.1%79ms74ms   
>> +5.8%
>>IfThenElse:83ms80ms   +3.9%85ms80ms   
>> +5.3%
>>   ListSli