Re: [Python-Dev] Drop the new time.wallclock() function?

[Paul Moore]

On 15 March 2012 01:58, Matt Joiner  wrote:
> Victor, I think that steady can always be monotonic, there are time sources
> enough to ensure this on the platforms I am aware of. Strict in this sense
> refers to not being adjusted forward, i.e. CLOCK_MONOTONIC vs
> CLOCK_MONOTONIC_RAW.

I agree - Kristján pointed out that you can ensure that backward jumps
never occur by implementing a cache of the last value.

> Non monotonicity of this call should be considered a bug.

+1

> Strict would be used for profiling where forward leaps would disqualify the 
> timing.

I'm baffled as to how you even identify "forward leaps". In relation
to what? A more accurate time source? I thought that by definition
this was the most accurate time source we have!

+1 on a simple time.steady() with guaranteed monotonicity and no flags
to alter behaviour.

Paul.
___
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] Drop the new time.wallclock() function?

[Victor Stinner]

2012/3/15 Matt Joiner :
> Victor, I think that steady can always be monotonic, there are time sources
> enough to ensure this on the platforms I am aware of. Strict in this sense
> refers to not being adjusted forward, i.e. CLOCK_MONOTONIC vs
> CLOCK_MONOTONIC_RAW.

I don't think that CLOCK_MONOTONIC is available on all platforms.
clock_gettime() and QueryPerformanceFrequency() can fail. In practice,
it should not fail on modern OSses.

But if the monotonic clock fails, Python should use another less
stable clock but provide something. Otherwise, each project would have
to implement its own fallback.

Victor
___
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] Drop the new time.wallclock() function?

[Matt Joiner]

On Mar 15, 2012 4:23 PM, "Paul Moore"  wrote:
>
> On 15 March 2012 01:58, Matt Joiner  wrote:
> > Victor, I think that steady can always be monotonic, there are time
sources
> > enough to ensure this on the platforms I am aware of. Strict in this
sense
> > refers to not being adjusted forward, i.e. CLOCK_MONOTONIC vs
> > CLOCK_MONOTONIC_RAW.
>
> I agree - Kristján pointed out that you can ensure that backward jumps
> never occur by implementing a cache of the last value.

Without knowing more, either QPC was buggy on his platform, or he didn't
account for processor affinity (QPC derives from a per processor counter).

>
> > Non monotonicity of this call should be considered a bug.
>
> +1
>
> > Strict would be used for profiling where forward leaps would disqualify
the timing.
>
> I'm baffled as to how you even identify "forward leaps". In relation
> to what? A more accurate time source? I thought that by definition
> this was the most accurate time source we have!

Monotonic clocks are not necessarily hardware based, and may be adjusted
forward by NTP.

>
> +1 on a simple time.steady() with guaranteed monotonicity and no flags
> to alter behaviour.
>
> Paul.

I don't mind since I'll be using it for timeouts, but clearly the strongest
possible guarantee should be made. If forward leaps are okay, then by
definition the timer is monotonic but not steady.
___
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] cpython (3.1): - rename configure.in to configure.ac

[Antoine Pitrou]

On Wed, 14 Mar 2012 23:27:24 +0100
matthias.klose  wrote:
> http://hg.python.org/cpython/rev/55ab7a272f0a
> changeset:   75659:55ab7a272f0a
> branch:  3.1
> parent:  75199:df3b2b5db900
> user:Matthias Klose 
> date:Wed Mar 14 23:10:15 2012 +0100
> summary:
>   - rename configure.in to configure.ac
> - change references from configure.in to configure.ac

What's the rationale for this change? There doesn't seem to be an issue
number.

Regards

Antoine.


___
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] Drop the new time.wallclock() function?

[Paul Moore]

On 15 March 2012 10:06, Matt Joiner  wrote:
>> I'm baffled as to how you even identify "forward leaps". In relation
>> to what? A more accurate time source? I thought that by definition
>> this was the most accurate time source we have!
>
> Monotonic clocks are not necessarily hardware based, and may be adjusted
> forward by NTP.

I appreciate that. But I'm still unclear how you would tell that had
happened as part of the implementation. One call to the OS returns
12345. The next returns 13345. Is that because 100 ticks have passed,
or because the clock "leapt forward"? With no point of reference, how
can you tell?

But I agree, the key thing is just to have the strongest guarantee possible.

Paul.
___
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] Drop the new time.wallclock() function?

[Nadeem Vawda]

On Thu, Mar 15, 2012 at 1:10 PM, Paul Moore  wrote:
>> Monotonic clocks are not necessarily hardware based, and may be adjusted
>> forward by NTP.
>
> I appreciate that. But I'm still unclear how you would tell that had
> happened as part of the implementation. One call to the OS returns
> 12345. The next returns 13345. Is that because 100 ticks have passed,
> or because the clock "leapt forward"? With no point of reference, how
> can you tell?

The point (AIUI) is that you *can't* identify such adjustments (in the
absence of some sort of log of NTP updates), so we should provide a
mechanism that is guaranteed not to be affected by them.

Cheers,
Nadeem
___
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] Drop the new time.wallclock() function?

[Paul Moore]

On 15 March 2012 12:12, Nadeem Vawda  wrote:
> On Thu, Mar 15, 2012 at 1:10 PM, Paul Moore  wrote:
>> I appreciate that. But I'm still unclear how you would tell that had
>> happened as part of the implementation. One call to the OS returns
>> 12345. The next returns 13345. Is that because 100 ticks have passed,
>> or because the clock "leapt forward"? With no point of reference, how
>> can you tell?
>
> The point (AIUI) is that you *can't* identify such adjustments (in the
> absence of some sort of log of NTP updates), so we should provide a
> mechanism that is guaranteed not to be affected by them.

OK, I see (sort of). But if that is the case, what's the use case for
the variation that *is* affected by them? The use cases I've seen
mentioned are timeouts and performance testing, both of which don't
want to see clock adjustments.

Note that when Victor started this thread, he said:

> I prefer to keep only monotonic() because it is not affected by system
> clock update and should help to fix issues on NTP update in functions
> implementing a timeout.

which seems to me to be exactly this point. So I guess I support
Victor's original proposal. (Which is good, because he has thought
about this issue far more than I have :-))

Paul.
___
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] cpython (3.1): - rename configure.in to configure.ac

[Matthias Klose]

On 15.03.2012 11:31, Antoine Pitrou wrote:

On Wed, 14 Mar 2012 23:27:24 +0100
matthias.klose  wrote:

http://hg.python.org/cpython/rev/55ab7a272f0a
changeset:   75659:55ab7a272f0a
branch:  3.1
parent:  75199:df3b2b5db900
user:Matthias Klose
date:Wed Mar 14 23:10:15 2012 +0100
summary:
   - rename configure.in to configure.ac
- change references from configure.in to configure.ac


What's the rationale for this change? There doesn't seem to be an issue
number.


autoconf files up to 2.13 have the .in extension, autoconf files for 2.50 and 
newer the .ac extension.  This is a no change, except for having autoconf2.13 
installed, and the autoconf then failing.

___
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] cpython (3.1): - rename configure.in to configure.ac

[Georg Brandl]

On 15.03.2012 17:33, Matthias Klose wrote:

On 15.03.2012 11:31, Antoine Pitrou wrote:

 On Wed, 14 Mar 2012 23:27:24 +0100
 matthias.klose   wrote:

 http://hg.python.org/cpython/rev/55ab7a272f0a
 changeset:   75659:55ab7a272f0a
 branch:  3.1
 parent:  75199:df3b2b5db900
 user:Matthias Klose
 date:Wed Mar 14 23:10:15 2012 +0100
 summary:
- rename configure.in to configure.ac
 - change references from configure.in to configure.ac


 What's the rationale for this change? There doesn't seem to be an issue
 number.


autoconf files up to 2.13 have the .in extension, autoconf files for 2.50 and
newer the .ac extension.  This is a no change, except for having autoconf2.13
installed, and the autoconf then failing.


Not sure it belongs in 3.1 though.

Georg

___
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] cpython (3.1): - rename configure.in to configure.ac

[Benjamin Peterson]

2012/3/15 Georg Brandl :
> On 15.03.2012 17:33, Matthias Klose wrote:
>>
>> On 15.03.2012 11:31, Antoine Pitrou wrote:
>>>
>>>  On Wed, 14 Mar 2012 23:27:24 +0100
>>>  matthias.klose   wrote:

  http://hg.python.org/cpython/rev/55ab7a272f0a
  changeset:   75659:55ab7a272f0a
  branch:      3.1
  parent:      75199:df3b2b5db900
  user:        Matthias Klose
  date:        Wed Mar 14 23:10:15 2012 +0100
  summary:
    - rename configure.in to configure.ac
  - change references from configure.in to configure.ac
>>>
>>>
>>>  What's the rationale for this change? There doesn't seem to be an issue
>>>  number.
>>
>>
>> autoconf files up to 2.13 have the .in extension, autoconf files for 2.50
>> and
>> newer the .ac extension.  This is a no change, except for having
>> autoconf2.13
>> installed, and the autoconf then failing.
>
>
> Not sure it belongs in 3.1 though.

I told him he could change 3.1 for ease of maintenance in the future.



-- 
Regards,
Benjamin
___
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] What letter should an UnsignedLongLong get

[Gil Colgate]

We use a lot of UnsignedLongLongs in our program (ids) and have been
parsing in PyArg_ParseTuple with 'K', which does not do error checking.
I am planning to add a new type to our local build of python for parsing
Unsigned Long Longs (64 bit numbers) that errrors if the number has more
than the correct number of bits.

I am thinking to use the letter 'N' for this purpose, since l,k,K,U,u are
all taken.

Does anyone have any better ideas?
___
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] What letter should an UnsignedLongLong get

[Benjamin Peterson]

2012/3/15 Gil Colgate :
> We use a lot of UnsignedLongLongs in our program (ids) and have been parsing
> in PyArg_ParseTuple with 'K', which does not do error checking.
> I am planning to add a new type to our local build of python for parsing
> Unsigned Long Longs (64 bit numbers) that errrors if the number has more
> than the correct number of bits.
>
> I am thinking to use the letter 'N' for this purpose, since l,k,K,U,u are
> all taken.

Unfortunately, the would conflict with Py_BuildValue's 'N'.



-- 
Regards,
Benjamin
___
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] What letter should an UnsignedLongLong get

[Benjamin Peterson]

2012/3/15 Gil Colgate :
> I must be using a different version of python, (3.2), I don't see that one
> in use. Do you have a different suggestion?

It's not used in PyArg_Parse*, but it is for Py_BuildValue. Adding it
to PyArg_Parse could create confusion.

>
> On Thu, Mar 15, 2012 at 11:49 AM, Benjamin Peterson 
> wrote:
>>
>> 2012/3/15 Gil Colgate :
>> > We use a lot of UnsignedLongLongs in our program (ids) and have been
>> > parsing
>> > in PyArg_ParseTuple with 'K', which does not do error checking.
>> > I am planning to add a new type to our local build of python for parsing
>> > Unsigned Long Longs (64 bit numbers) that errrors if the number has more
>> > than the correct number of bits.
>> >
>> > I am thinking to use the letter 'N' for this purpose, since l,k,K,U,u
>> > are
>> > all taken.
>>
>> Unfortunately, the would conflict with Py_BuildValue's 'N'.
>>
>>
>>
>> --
>> Regards,
>> Benjamin
>
>



-- 
Regards,
Benjamin
___
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] What letter should an UnsignedLongLong get

[Nadeem Vawda]

The lzma module ran into a similar issue with 32-bit unsigned ints.
I worked around it by writing a custom converter function to use
with the "O&" code.

You can find the converter definition here:

http://hg.python.org/cpython/file/default/Modules/_lzmamodule.c#l134

And an example usage here:

http://hg.python.org/cpython/file/default/Modules/_lzmamodule.c#l261

Cheers,
Nadeem
___
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] Drop the new time.wallclock() function?

[Russell E. Owen]

In article 
,
 Kristján Valur Jónsson  wrote:

> What does "jumping forward" mean?  That's what happens with every clock at 
> every time quantum.  The only effect here is that this clock will be slightly 
> noisy, i.e. its precision becomes worse.  On average it is still correct.  
> Look at the use cases for this function
> 1) to enable timeouts for certaing operations, like acquiring locks:
>   Jumping backwards is bad, because that may cause infinite wait time.  
> But 
> jumping forwards is ok, it may just mean that your lock times out a bit early
> 2) performance measurements:
>   If you are running on a platform with a broken runtime clock, you are 
> not 
> likely to be running performance measurements.
> 
> Really, I urge you to skip the "strict" keyword.  It just adds confusion.  
> Instead, lets just give the best monotonic clock we can do which doesn"t move 
> backwards.
> Let's just provide a "practical" real time clock with high resolution that is 
> appropriate for providing timeout functionality and so won't jump backwards 
> for the next 20 years.  Let's simply point out to people that it may not be 
> appropriate for high precision timings on old and obsolete hardware and be 
> done with it.

I agree. I prefer the name time.monotonic with no flags. It will suit 
most use cases. I think supplying truly steady time is a low level 
hardware function (e.g. buy a GPS timer card) with a driver.

-- Russell

___
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] Drop the new time.wallclock() function?

[Matt Joiner]

+1. I now prefer time.monotonic(), no flags. It attempts to be as high
precision as possible and guarantees never to jump backwards. Russell's
comment is right, the only steady sources are from hardware, and these are
too equipment and operating system specific. (For this call anyway).
On Mar 16, 2012 3:23 AM, "Russell E. Owen"  wrote:

> In article
> ,
>  Kristján Valur Jónsson  wrote:
>
> > What does "jumping forward" mean?  That's what happens with every clock
> at
> > every time quantum.  The only effect here is that this clock will be
> slightly
> > noisy, i.e. its precision becomes worse.  On average it is still correct.
> > Look at the use cases for this function
> > 1) to enable timeouts for certaing operations, like acquiring locks:
> >   Jumping backwards is bad, because that may cause infinite wait
> time.  But
> > jumping forwards is ok, it may just mean that your lock times out a bit
> early
> > 2) performance measurements:
> >   If you are running on a platform with a broken runtime clock, you
> are not
> > likely to be running performance measurements.
> >
> > Really, I urge you to skip the "strict" keyword.  It just adds confusion.
> > Instead, lets just give the best monotonic clock we can do which doesn"t
> move
> > backwards.
> > Let's just provide a "practical" real time clock with high resolution
> that is
> > appropriate for providing timeout functionality and so won't jump
> backwards
> > for the next 20 years.  Let's simply point out to people that it may not
> be
> > appropriate for high precision timings on old and obsolete hardware and
> be
> > done with it.
>
> I agree. I prefer the name time.monotonic with no flags. It will suit
> most use cases. I think supplying truly steady time is a low level
> hardware function (e.g. buy a GPS timer card) with a driver.
>
> -- Russell
>
>
> ___
> 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/anacrolix%40gmail.com
>
>
___
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] What letter should an UnsignedLongLong get

[Gil Colgate]

How about 'G'? (Giant, or perhaps gynormous, integer?)


Then I could also map 'g' to the signed version (same as L) for consistency.

On Thu, Mar 15, 2012 at 11:49 AM, Benjamin Peterson wrote:

> 2012/3/15 Gil Colgate :
> > We use a lot of UnsignedLongLongs in our program (ids) and have been
> parsing
> > in PyArg_ParseTuple with 'K', which does not do error checking.
> > I am planning to add a new type to our local build of python for parsing
> > Unsigned Long Longs (64 bit numbers) that errrors if the number has more
> > than the correct number of bits.
> >
> > I am thinking to use the letter 'N' for this purpose, since l,k,K,U,u are
> > all taken.
>
> Unfortunately, the would conflict with Py_BuildValue's 'N'.
>
>
>
> --
> Regards,
> Benjamin
>
___
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] What letter should an UnsignedLongLong get

[Benjamin Peterson]

2012/3/15 Gil Colgate :
> How about 'G'? (Giant, or perhaps gynormous, integer?)
>
>
> Then I could also map 'g' to the signed version (same as L) for consistency.

Sounds okay to me.



-- 
Regards,
Benjamin
___
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] What letter should an UnsignedLongLong get

[Serhiy Storchaka]

15.03.12 21:59, Gil Colgate написав(ла):

How about 'G'? (Giant, or perhaps gynormous, integer?)


Then I could also map 'g' to the signed version (same as L) for consistency.


What about unsigned char, short, int, and long with overflow checking?

___
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] Drop the new time.wallclock() function?

[Alexander Belopolsky]

On Thu, Mar 15, 2012 at 3:55 PM, Matt Joiner  wrote:
> +1. I now prefer time.monotonic(), no flags.

Am I alone thinking that an adjective is an odd choice for a function
name?  I think monotonic_clock or monotonic_time would be a better
option.
___
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] What letter should an UnsignedLongLong get

[Serhiy Storchaka]

15.03.12 21:59, Gil Colgate написав(ла):

How about 'G'? (Giant, or perhaps gynormous, integer?)


Then I could also map 'g' to the signed version (same as L) for consistency.


For consistency 'g' must be `unsigned long` with overflow checking.

And how about 'M'? 'K', 'L', and 'M' are neighboring letters.

___
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] PEP 405 (built-in virtualenv) status

[Carl Meyer]

A brief status update on PEP 405 (built-in virtualenv) and the open issues:

1. As mentioned in the updated version of the language summit notes,
Nick Coghlan has agreed to pronounce on the PEP.

2. Ned Deily discovered at the PyCon sprints that the current reference
implementation does not work with an OS X framework build of Python.
We're still working to discover the reason for that and determine
possible fixes.

3. If anyone knows of a pair of packages in which both need to build
compiled extensions, and the compilation of the second depends on header
files from the first, that would be helpful to me in testing the other
open issue (installation of header files). (I thought numpy and scipy
might fit this bill, but I'm currently not able to install numpy at all
under Python 3 using pysetup, easy_install, or pip.)

Thanks,

Carl



signature.asc
Description: OpenPGP digital signature
___
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 install layout and the PATH on win32

[VanL]

On 3/14/2012 6:30 PM, Mark Hammond wrote:


So why not just standardize on that new layout for virtualenvs?


That sounds like the worst of all worlds - keep all the existing special 
cases, and add one.


The fact is that most code doesn't know about this, only installers or 
virtual environments. Most code just assumes that distutils does its 
thing correctly and that binaries are installed... wherever the binaries go.


Again, I have experience with this, as I have edited my own install to 
do this for a couple of years. The breakage is minimal and it makes 
things much more consistent and easier to use for cross-platform 
development.


Right now we are in front of the knee on major 3.x adoption - I would 
like to have things be standardized going forth everywhere.


Thanks,
Van

___
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] PEP 405 (built-in virtualenv) status

[Carl Meyer]

On 03/15/2012 03:02 PM, Lindberg, Van wrote:
> FYI, the location of the tcl/tk libraries does not appear to be set in 
> the virtualenv, even if tkinter is installed and working in the main 
> Python installation. As a result, tk-based apps will not run from a 
> virtualenv.

Thanks for the report! I've added this to the list of open issues in the
PEP and I'll look into it.

Carl



signature.asc
Description: OpenPGP digital signature
___
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] Drop the new time.wallclock() function?

[Terry Reedy]

On 3/15/2012 5:27 PM, Alexander Belopolsky wrote:

On Thu, Mar 15, 2012 at 3:55 PM, Matt Joiner  wrote:

+1. I now prefer time.monotonic(), no flags.


Am I alone thinking that an adjective is an odd choice for a function
name?


I would normally agree, but in this case, it is a function of a module 
whose short name names what the adjective is modifying. I expect that 
this will normally be called with the module name.



I think monotonic_clock or monotonic_time would be a better option.


time.monotonic_time seems redundant.

--
Terry Jan Reedy

___
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] Drop the new time.wallclock() function?

[Steven D'Aprano]

Terry Reedy wrote:

On 3/15/2012 5:27 PM, Alexander Belopolsky wrote:

On Thu, Mar 15, 2012 at 3:55 PM, Matt Joiner  wrote:

+1. I now prefer time.monotonic(), no flags.


Am I alone thinking that an adjective is an odd choice for a function
name?


I would normally agree, but in this case, it is a function of a module 
whose short name names what the adjective is modifying. I expect that 
this will normally be called with the module name.



I think monotonic_clock or monotonic_time would be a better option.


time.monotonic_time seems redundant.


Agreed. Same applies to "steady_time", and "steady" on its own is weird. 
Steady what?


While we're bike-shedding, I'll toss in another alternative. Early Apple 
Macintoshes had a system function that returned the time since last reboot 
measured in 1/60th of a second, called "the ticks".


If I have understood correctly, the monotonic timer will have similar 
properties: guaranteed monotonic, as accurate as the hardware can provide, but 
not directly translatable to real (wall-clock) time. (Wall clocks sometimes go 
backwards.)


The two functions are not quite identical: Mac "ticks" were 32-bit integers, 
not floating point numbers. But the use-cases seem to be the same.


time.ticks() seems right as a name to me. It suggests a steady heartbeat 
ticking along, without making any suggestion that it returns "the time".




--
Steven

___
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 install layout and the PATH on win32

[Mark Hammond]

On 16/03/2012 8:57 AM, VanL wrote:

On 3/14/2012 6:30 PM, Mark Hammond wrote:


So why not just standardize on that new layout for virtualenvs?


That sounds like the worst of all worlds - keep all the existing special
cases, and add one.


I'm not so sure.  My concern is that this *will* break external tools 
that attempt to locate the python executable from an installed 
directory.  However, I'm not sure this requirement exists for virtual 
environments - such tools probably will not attempt to locate the 
executable in a virtual env as there is no standard place for a virtual 
env to live.


So having a standard layout in the virtual envs still seems a win - we 
keep the inconsistency in the layout of the "installed" Python, but 
tools which work with virtualenvs still get a standardized layout.


[At least I think that is your proposal - can you confirm that the 
directory layouts in your proposal exactly match the directory layouts 
in virtual envs on all other platforms?  ie, that inconsistencies like 
the python{py_version_short} suffix will not remain?]


Just to be completely clear, my current concern is only with the 
location of the executable in an installed Python.



The fact is that most code doesn't know about this, only installers or
virtual environments. Most code just assumes that distutils does its
thing correctly and that binaries are installed... wherever the binaries
go.


Of course - but this raises 2 points:

* I'm referring to *external* tools that launch Python.  They obviously 
need to know where the binaries are to launch them.  Eg, the PEP397 
launcher; the (admittedly few) people who use the launcher would need to 
upgrade it to work under your scheme.  Ditto *all* other such tools that 
locate and launch Python.


* "most code" isn't a high enough bar.  If we only considered such 
anecdotes, most backwards compatibility concerns would be moot.



Again, I have experience with this, as I have edited my own install to
do this for a couple of years. The breakage is minimal and it makes
things much more consistent and easier to use for cross-platform
development.


All due respect, but I'm not sure that is a large enough sample to draw 
any conclusions from.  I've offered 2 concrete examples of things that 
*will* break and I haven't looked for others.


Also, I'm still yet to see what exactly becomes "easier" in your model? 
 As you mention, most Python code will not care; distutils and other 
parts of the stdlib will "do the right thing" - and indeed, already do 
for Windows.  So the proposal wants to change distutils and other parts 
of the stdlib even though "most code" won't notice.  But the code that 
will notice will be broken!


So I dispute it is "easier" for anyone; I agree it is more consistent, 
but given the *certainty* external tools will break, I refer to you the 
Zen of Python's thoughts on consistency ;)



Right now we are in front of the knee on major 3.x adoption - I would
like to have things be standardized going forth everywhere.


It is a shame this wasn't done as part of py3k in the first place.  But 
I assume you would be looking at Python 3.4 for this, right?  So if 
people start working with Python 3.3 now and finds this change in 3.4, 
we are still asking them to take the burden of supporting the multiple 
locations.  I guess I'd be less concerned if we managed to get it into 
3.3 and also recommended to people that they should ignore 3.2 and 
earlier when porting their tools/libraries to 3.x.


I think I've made all the points I can make in this discussion.  As I 
mentioned at the start, I'm not quite -1 on the idea, so I'm not going 
to push this barrow any further (although I'm obviously happy to clarify 
anything I've said...)


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] Python install layout and the PATH on win32

[Carl Meyer]

On 03/15/2012 04:19 PM, Mark Hammond wrote:
> On 16/03/2012 8:57 AM, VanL wrote:
>> On 3/14/2012 6:30 PM, Mark Hammond wrote:
>>>
>>> So why not just standardize on that new layout for virtualenvs?
>>
>> That sounds like the worst of all worlds - keep all the existing special
>> cases, and add one.
> 
> I'm not so sure.  My concern is that this *will* break external tools
> that attempt to locate the python executable from an installed
> directory.  However, I'm not sure this requirement exists for virtual
> environments - such tools probably will not attempt to locate the
> executable in a virtual env as there is no standard place for a virtual
> env to live.
> 
> So having a standard layout in the virtual envs still seems a win - we
> keep the inconsistency in the layout of the "installed" Python, but
> tools which work with virtualenvs still get a standardized layout.

The implementation of virtualenv (and especially PEP 405 pyvenv) are
largely based around making sure that the internal layout of a
virtualenv is identical to the layout of an installed Python on that
same platform, to avoid any need to special-case virtualenvs in
distutils. The one exception to this is the location of the python
binary itself in Windows virtualenvs; we do place it inside Scripts\ so
that the virtualenv can be "activated" by adding only a single path to
the shell PATH. But I would be opposed to any additional special-casing
of the internal layout of a virtualenv that would require tools
installing software inside virtualenv to use a different install scheme
than when installing to a system Python.

In other words, I would much rather that tools have to understand a
different layout between Windows virtualenvs and Unixy virtualenvs
(because most tools don't have to care anyway, distutils just takes care
of it, and to the extent they do have to care, they have to adjust
anyway in order to work with installed Pythons) than that they have to
understand a different layout between virtualenv and non- on the same
platform. To as great an extent as possible, tools shouldn't have to
care whether they are dealing with a virtualenv.

A consistent layout all around would certainly be nice, but I'm not
venturing any opinion on whether it's worth the backwards incompatibility.

Carl



signature.asc
Description: OpenPGP digital signature
___
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 install layout and the PATH on win32

[Mark Hammond]

On 16/03/2012 10:48 AM, Carl Meyer wrote:
...


The implementation of virtualenv (and especially PEP 405 pyvenv) are
largely based around making sure that the internal layout of a
virtualenv is identical to the layout of an installed Python on that
same platform, to avoid any need to special-case virtualenvs in
distutils. The one exception to this is the location of the python
binary itself in Windows virtualenvs; we do place it inside Scripts\ so
that the virtualenv can be "activated" by adding only a single path to
the shell PATH. But I would be opposed to any additional special-casing
of the internal layout of a virtualenv

...

Unless I misunderstand, that sounds like it should keep everyone happy; 
there already is a special case for the executable on Windows being in a 
different place in an installed layout vs a virtual-env layout. 
Changing this to use "bin" instead of "Scripts" makes the virtualenv 
more consistent across platforms and doesn't impose any additional 
special-casing for Windows (just slightly changes the existing 
special-case :)


Thanks,

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] Python install layout and the PATH on win32

[Carl Meyer]

On 03/15/2012 05:10 PM, Mark Hammond wrote:
> On 16/03/2012 10:48 AM, Carl Meyer wrote:
>> The implementation of virtualenv (and especially PEP 405 pyvenv) are
>> largely based around making sure that the internal layout of a
>> virtualenv is identical to the layout of an installed Python on that
>> same platform, to avoid any need to special-case virtualenvs in
>> distutils. The one exception to this is the location of the python
>> binary itself in Windows virtualenvs; we do place it inside Scripts\ so
>> that the virtualenv can be "activated" by adding only a single path to
>> the shell PATH. But I would be opposed to any additional special-casing
>> of the internal layout of a virtualenv
> ...
> 
> Unless I misunderstand, that sounds like it should keep everyone happy;
> there already is a special case for the executable on Windows being in a
> different place in an installed layout vs a virtual-env layout. Changing
> this to use "bin" instead of "Scripts" makes the virtualenv more
> consistent across platforms and doesn't impose any additional
> special-casing for Windows (just slightly changes the existing
> special-case :)

Changing the directory name is in fact a new and different (and much
more invasive) special case, because distutils et al install scripts
there, and that directory name is part of the distutils install scheme.
Installers don't care where the Python binary is located, so moving it
in with the other scripts has very little impact.

Carl



signature.asc
Description: OpenPGP digital signature
___
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] Drop the new time.wallclock() function?

[Matt Joiner]

Windows also has this albeit course grained and also 32 bit. I don't think
ticks reflects the reason why using the timer is desirable.

monotonic_time seems reasonable, there's no reason to persist short names
when users can import it how they like.
On Mar 16, 2012 7:20 AM, "Steven D'Aprano"  wrote:

> Terry Reedy wrote:
>
>> On 3/15/2012 5:27 PM, Alexander Belopolsky wrote:
>>
>>> On Thu, Mar 15, 2012 at 3:55 PM, Matt Joiner
>>>  wrote:
>>>
 +1. I now prefer time.monotonic(), no flags.

>>>
>>> Am I alone thinking that an adjective is an odd choice for a function
>>> name?
>>>
>>
>> I would normally agree, but in this case, it is a function of a module
>> whose short name names what the adjective is modifying. I expect that this
>> will normally be called with the module name.
>>
>>  I think monotonic_clock or monotonic_time would be a better option.
>>>
>>
>> time.monotonic_time seems redundant.
>>
>
> Agreed. Same applies to "steady_time", and "steady" on its own is weird.
> Steady what?
>
> While we're bike-shedding, I'll toss in another alternative. Early Apple
> Macintoshes had a system function that returned the time since last reboot
> measured in 1/60th of a second, called "the ticks".
>
> If I have understood correctly, the monotonic timer will have similar
> properties: guaranteed monotonic, as accurate as the hardware can provide,
> but not directly translatable to real (wall-clock) time. (Wall clocks
> sometimes go backwards.)
>
> The two functions are not quite identical: Mac "ticks" were 32-bit
> integers, not floating point numbers. But the use-cases seem to be the same.
>
> time.ticks() seems right as a name to me. It suggests a steady heartbeat
> ticking along, without making any suggestion that it returns "the time".
>
>
>
> --
> Steven
>
> __**_
> 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/**
> anacrolix%40gmail.com
>
___
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] Unpickling py2 str as py3 bytes (and vice versa) - implementation (issue #6784)

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/13/2012 06:49 PM, Nick Coghlan wrote:
> On Wed, Mar 14, 2012 at 8:08 AM, Guido van Rossum 
> wrote:
>> If you can solve your problem with a suitably hacked Unpickler 
>> subclass that's fine with me, but I would personally use this 
>> opportunity to change the app to some other serialization format
>> that is perhaps less general but more robust than pickle. I've been
>> bitten by too many pickle-related problems to recommend pickle to
>> anyone...
> 
> It's fine for in-memory storage of (almost) arbitrary objects (I use 
> it to stash things in a memory backed sqlite DB via SQLAlchemy) and 
> for IPC, but yeah, for long-term cross-version persistent storage,
> I'd be looking to something like JSON rather than pickle.

Note the Zope ecosystem (including Plone) is an *enoromous* installed
base[1] using pickle for storage of data over many years and multiple
versions of Python:  until this point, it has always been possible to
arrange for old pickles to work (e.g., by providing aliases for missing
module names, etc.).

]1] tens of thousands of Zope-based sites in production, including very
high-profile ones:  http://plone.org/support/sites




Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9ixhEACgkQ+gerLs4ltQ7hUwCfSdjbGnIIrNr6sxoztvb3pvx5
Ns0An1GmcYHClvsgx22bdru5Hl+G09nx
=sm0/
-END PGP SIGNATURE-

___
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] PEP 405 (built-in virtualenv) status

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/15/2012 05:43 PM, Carl Meyer wrote:
> A brief status update on PEP 405 (built-in virtualenv) and the open
> issues:
> 
> 1. As mentioned in the updated version of the language summit notes, 
> Nick Coghlan has agreed to pronounce on the PEP.
> 
> 2. Ned Deily discovered at the PyCon sprints that the current
> reference implementation does not work with an OS X framework build of
> Python. We're still working to discover the reason for that and
> determine possible fixes.
> 
> 3. If anyone knows of a pair of packages in which both need to build 
> compiled extensions, and the compilation of the second depends on
> header files from the first, that would be helpful to me in testing
> the other open issue (installation of header files). (I thought numpy
> and scipy might fit this bill, but I'm currently not able to install
> numpy at all under Python 3 using pysetup, easy_install, or pip.)

ExtensionClass and Acquisition would fit the bill, except they aren't
ported to Python3 (Acquisition needs the headers from ExtensionClass).



Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9ix9EACgkQ+gerLs4ltQ5HsgCdEFbb0utGPbBJ2059+KBbhkIB
M2IAnjFNoJh1UKB76k6nd6nTMfo78s3Z
=T6fh
-END PGP SIGNATURE-

___
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