Re: [Python-Dev] Drop the new time.wallclock() function?
On 15 March 2012 01:58, Matt Joiner anacro...@gmail.com 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?
2012/3/15 Matt Joiner anacro...@gmail.com: 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?
On Mar 15, 2012 4:23 PM, Paul Moore p.f.mo...@gmail.com wrote: On 15 March 2012 01:58, Matt Joiner anacro...@gmail.com 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
On Wed, 14 Mar 2012 23:27:24 +0100 matthias.klose python-check...@python.org wrote: http://hg.python.org/cpython/rev/55ab7a272f0a changeset: 75659:55ab7a272f0a branch: 3.1 parent: 75199:df3b2b5db900 user:Matthias Klose d...@ubuntu.com 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?
On 15 March 2012 10:06, Matt Joiner anacro...@gmail.com 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?
On Thu, Mar 15, 2012 at 1:10 PM, Paul Moore p.f.mo...@gmail.com 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?
On 15 March 2012 12:12, Nadeem Vawda nadeem.va...@gmail.com wrote: On Thu, Mar 15, 2012 at 1:10 PM, Paul Moore p.f.mo...@gmail.com 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
On 15.03.2012 11:31, Antoine Pitrou wrote: On Wed, 14 Mar 2012 23:27:24 +0100 matthias.klosepython-check...@python.org wrote: http://hg.python.org/cpython/rev/55ab7a272f0a changeset: 75659:55ab7a272f0a branch: 3.1 parent: 75199:df3b2b5db900 user:Matthias Klosed...@ubuntu.com 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
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.klosepython-check...@python.org wrote: http://hg.python.org/cpython/rev/55ab7a272f0a changeset: 75659:55ab7a272f0a branch: 3.1 parent: 75199:df3b2b5db900 user:Matthias Klosed...@ubuntu.com 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
2012/3/15 Georg Brandl g.bra...@gmx.net: 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.klosepython-check...@python.org wrote: http://hg.python.org/cpython/rev/55ab7a272f0a changeset: 75659:55ab7a272f0a branch: 3.1 parent: 75199:df3b2b5db900 user: Matthias Klosed...@ubuntu.com 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
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
2012/3/15 Gil Colgate gcolg...@gmail.com: 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
2012/3/15 Gil Colgate gcolg...@gmail.com: 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 benja...@python.org wrote: 2012/3/15 Gil Colgate gcolg...@gmail.com: 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
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?
In article efe3877620384242a686d52278b7ccd3362...@rkv-it-exch104.ccp.ad.local, Kristján Valur Jónsson krist...@ccpgames.com 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 doesnt 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?
+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 ro...@uw.edu wrote: In article efe3877620384242a686d52278b7ccd3362...@rkv-it-exch104.ccp.ad.local, Kristján Valur Jónsson krist...@ccpgames.com 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 doesnt 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
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 benja...@python.orgwrote: 2012/3/15 Gil Colgate gcolg...@gmail.com: 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
2012/3/15 Gil Colgate gcolg...@gmail.com: 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
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?
On Thu, Mar 15, 2012 at 3:55 PM, Matt Joiner anacro...@gmail.com 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
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
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
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
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?
On 3/15/2012 5:27 PM, Alexander Belopolsky wrote: On Thu, Mar 15, 2012 at 3:55 PM, Matt Joineranacro...@gmail.com 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?
Terry Reedy wrote: On 3/15/2012 5:27 PM, Alexander Belopolsky wrote: On Thu, Mar 15, 2012 at 3:55 PM, Matt Joineranacro...@gmail.com 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
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
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
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
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?
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 Dapos;Aprano st...@pearwood.info wrote: Terry Reedy wrote: On 3/15/2012 5:27 PM, Alexander Belopolsky wrote: On Thu, Mar 15, 2012 at 3:55 PM, Matt Joineranacro...@gmail.com 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-devhttp://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/**mailman/options/python-dev/** anacrolix%40gmail.comhttp://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)
-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 gu...@python.org 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 Designhttp://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
-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 Designhttp://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
