headers
Victor Stinner | 1 May 2012 10:35
Picon
Gravatar

Re: cpython: Issue #14428: Use the new time.perf_counter() and time.process_time() functions

>> diff --git a/Lib/timeit.py b/Lib/timeit.py
>> --- a/Lib/timeit.py
>> +++ b/Lib/timeit.py
>>  <at>  <at>  -15,8 +15,8  <at>  <at> 
>>    -n/--number N: how many times to execute 'statement' (default: see below)
>>    -r/--repeat N: how many times to repeat the timer (default 3)
>>    -s/--setup S: statement to be executed once initially (default 'pass')
>> -  -t/--time: use time.time() (default on Unix)
>> -  -c/--clock: use time.clock() (default on Windows)
>> +  -t/--time: use time.time()
>> +  -c/--clock: use time.clock()
>
> Does it make sense to keep the options this way?  IMO the distinction should be
> to use either perf_counter() or process_time(), and the options could implement
> this (-t -> perf_counter, -c -> process_time).

You might need to use exactly the same clock to compare performance of
Python 3.2 and 3.3.

Adding an option to use time.process_time() is a good idea. Is anyone
interested to implement it?

Victor
_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Permalink | Reply | 1 comment |
headers
Georg Brandl | 1 May 2012 11:59
Picon
Gravatar

Re: cpython: Issue #14428: Use the new time.perf_counter() and time.process_time() functions

On 01.05.2012 10:35, Victor Stinner wrote:
>>> diff --git a/Lib/timeit.py b/Lib/timeit.py
>>> --- a/Lib/timeit.py
>>> +++ b/Lib/timeit.py
>>>  <at>  <at>  -15,8 +15,8  <at>  <at> 
>>>    -n/--number N: how many times to execute 'statement' (default: see below)
>>>    -r/--repeat N: how many times to repeat the timer (default 3)
>>>    -s/--setup S: statement to be executed once initially (default 'pass')
>>> -  -t/--time: use time.time() (default on Unix)
>>> -  -c/--clock: use time.clock() (default on Windows)
>>> +  -t/--time: use time.time()
>>> +  -c/--clock: use time.clock()
>>
>> Does it make sense to keep the options this way?  IMO the distinction should be
>> to use either perf_counter() or process_time(), and the options could implement
>> this (-t -> perf_counter, -c -> process_time).
> 
> You might need to use exactly the same clock to compare performance of
> Python 3.2 and 3.3.
> 
> Adding an option to use time.process_time() is a good idea. Is anyone
> interested to implement it?

I implemented it in d43a8aa9dbef.  I also updated the docs in 552c207f65e4.

Georg
Permalink | Reply | 0 comments |
headers
Antoine Pitrou | 1 May 2012 12:37

Re: cpython: Move make_key() out of the decorator body. Make keys that only need to be

On Tue, 01 May 2012 07:32:36 +0200
raymond.hettinger <python-checkins <at> python.org> wrote:
> http://hg.python.org/cpython/rev/f981fe3b8bf7
> changeset:   76681:f981fe3b8bf7
> user:        Raymond Hettinger <python <at> rcn.com>
> date:        Mon Apr 30 22:32:16 2012 -0700
> summary:
>   Move make_key() out of the decorator body. Make keys that only need to be hashed once.

How does it work? A new _CacheKey instance is created at each cache
lookup anyway.

Regards

Antoine.
Permalink | Reply | 0 comments |
headers
Georg Brandl | 1 May 2012 13:57
Picon
Gravatar

Open PEPs and large-scale changes for 3.3

With 3.3a3 tagged and the beta stage currently 2 months away, I would like
to draw your attention to the following list of possible features for 3.3
as specified by PEP 398:

Candidate PEPs:

* PEP 362: Function Signature Object
* PEP 395: Qualified Names for Modules
* PEP 397: Python launcher for Windows
* PEP 402: Simplified Package Layout (likely a new PEP derived from it) --
  I assume PEP 420 is a candidate for that?
* PEP 405: Python Virtual Environments
* PEP 421: Adding sys.implementation
* PEP 3143: Standard daemon process library
* PEP 3144: IP Address manipulation library
* PEP 3154: Pickle protocol version 4

Other planned large-scale changes:

* Addition of the "regex" module
* Email version 6
* A standard event-loop interface (PEP by Jim Fulton pending)
* Breaking out standard library and docs in separate repos?

Benjamin: I'd also like to know what will become of PEP 415.

If anyone feels strongly about one of these items, please get ready to
finalize and implement it well before June 23 (beta 1), or we have to
discuss about adding another alpha.
(Continue reading)

Permalink | Reply | 30 comments |
headers
Eric V. Smith | 1 May 2012 14:11
Favicon

Re: Open PEPs and large-scale changes for 3.3

On 5/1/2012 7:57 AM, Georg Brandl wrote:
> With 3.3a3 tagged and the beta stage currently 2 months away, I would like
> to draw your attention to the following list of possible features for 3.3
> as specified by PEP 398:
...

> Also, if I missed any obvious candidate PEP or change, please let me know.

I'd like to include PEP 420, Implicit Namespace Packages. We discussed
it at PyCon, and a sample implementation is available at
features/pep-420. Barry Warsaw, Jason Coombs, and I are sprinting this
Thursday to hopefully finish up tests and other loose ends. Then we'll
ask that it be accepted. If accepted, we should be able to get it in
before alpha 4.

Eric.
Permalink | Reply | 2 comments |
headers
Eric V. Smith | 1 May 2012 14:24
Favicon

Re: Open PEPs and large-scale changes for 3.3

On 5/1/2012 8:11 AM, Eric V. Smith wrote:
> On 5/1/2012 7:57 AM, Georg Brandl wrote:
>> With 3.3a3 tagged and the beta stage currently 2 months away, I would like
>> to draw your attention to the following list of possible features for 3.3
>> as specified by PEP 398:
> ...
> 
>> Also, if I missed any obvious candidate PEP or change, please let me know.
> 
> I'd like to include PEP 420, Implicit Namespace Packages.

Oops, I missed your reference to PEP 402 and PEP 420. Sorry about that.

It is indeed 420 that would replace 402.

Eric.
Permalink | Reply | 1 comment |
headers
Nick Coghlan | 1 May 2012 15:30
Picon
Gravatar

Re: Open PEPs and large-scale changes for 3.3

On Tue, May 1, 2012 at 9:57 PM, Georg Brandl <g.brandl <at> gmx.net> wrote:
> With 3.3a3 tagged and the beta stage currently 2 months away, I would like
> to draw your attention to the following list of possible features for 3.3
> as specified by PEP 398:

A few of those are on my plate, soo...

> * PEP 395: Qualified Names for Modules

I'm currently thinking I'll defer this to 3.4. With the importlib
change and PEP 420, there's already going to be an awful lot of churn
in that space for 3.3, plus I have other things that I consider more
important that I want to get done first.

> * PEP 405: Python Virtual Environments

I pinged Carl and Vinay about the remaining open issues yesterday, and
indicated I'd really like to have something I can pronounce on soon so
we can get it into the fourth alpha on May 26. I'm hoping we'll see
the next draft of the PEP soon, but the ball is back in their court
for the moment.

> * PEP 3144: IP Address manipulation library

This is pretty close to approval. Peter's addressed all the
substantive comments that were made regarding the draft API, and he's
going to provide an update to the PEP shortly that should get it into
a state where I can mark it as Approved. Integration of the library
and tests shouldn't be too hard, but it would really help if a sphinx
expert could take a look at my Stack Overflow question [1] about
(Continue reading)

Permalink | Reply | 9 comments |
headers
Eli Bendersky | 1 May 2012 15:34
Picon
Gravatar

Re: Open PEPs and large-scale changes for 3.3

>> * PEP 3144: IP Address manipulation library
>
> This is pretty close to approval. Peter's addressed all the
> substantive comments that were made regarding the draft API, and he's
> going to provide an update to the PEP shortly that should get it into
> a state where I can mark it as Approved. Integration of the library
> and tests shouldn't be too hard, but it would really help if a sphinx
> expert could take a look at my Stack Overflow question [1] about
> generating an initial version of the API reference docs. (I've been
> meaning to figure out the right mailing list to send sphinx questions
> to, but haven't got around to it yet).
>
> [1] http://stackoverflow.com/questions/10377576/emit-restructuredtext-from-sphinx-autodoc
>

Will this package go through the provisional state mandated by PEP 411 ?

Eli
Permalink | Reply | 4 comments |
headers
Benjamin Peterson | 1 May 2012 15:38
Favicon
Gravatar

Re: time.clock_info() field names

I've now renamed "is_monotonic" to "monotonic" and "is_adjusted" to "adjusted".

2012/4/29 Benjamin Peterson <benjamin <at> python.org>:
> Hi,
> I see PEP 418 gives time.clock_info() two boolean fields named
> "is_monotonic" and "is_adjusted". I think the "is_" is unnecessary and
> a bit ugly, and they could just be renamed "monotonic" and "adjusted".
>
> Thoughts?
>
> --
> Regards,
> Benjamin

--

-- 
Regards,
Benjamin
Permalink | Reply | 0 comments |
headers
Nick Coghlan | 1 May 2012 15:43
Picon
Gravatar

Re: Open PEPs and large-scale changes for 3.3

On Tue, May 1, 2012 at 11:34 PM, Eli Bendersky <eliben <at> gmail.com> wrote:
>>> * PEP 3144: IP Address manipulation library
>>
>> This is pretty close to approval. Peter's addressed all the
>> substantive comments that were made regarding the draft API, and he's
>> going to provide an update to the PEP shortly that should get it into
>> a state where I can mark it as Approved. Integration of the library
>> and tests shouldn't be too hard, but it would really help if a sphinx
>> expert could take a look at my Stack Overflow question [1] about
>> generating an initial version of the API reference docs. (I've been
>> meaning to figure out the right mailing list to send sphinx questions
>> to, but haven't got around to it yet).
>>
>> [1] http://stackoverflow.com/questions/10377576/emit-restructuredtext-from-sphinx-autodoc
>>
>
> Will this package go through the provisional state mandated by PEP 411 ?

Yeah, it will. While the ipaddr heritage means we can be confident the
underlying implementation is solid, there's no need to be hasty in
locking down the cleaned up API. Clarifying that is one of the updates
I've asked Peter to make to the PEP before I can accept it.

Cheers,
Nick.

--

-- 
Nick Coghlan   |   ncoghlan <at> gmail.com   |   Brisbane, Australia
Permalink | Reply | 0 comments |

Gmane