Re: [Python-Dev] Setting up a RHEL6 buildbot

[Stefan Krah]

Nick Coghlan  wrote:
> I'm looking into getting a RHEL6 system set up to add to the buildbot
> fleet. The info already on the wiki [1] is pretty helpful, but does
> anyone have any suggestions on appropriate CPU/memory/disk
> allocations?

The Fedora bot has been running ultra-stable under qemu with 512MB
allocated for the VM. I've never limited CPU or disk space. On an i7
quad core with 8GB of memory, I've been running two buildbot VMs,
four deccheck processes at 100% CPU and a web server without any
kind of noticable performance degradation.


Stefan Krah


___
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 (Rationale part 2: Moving the python.exe)

[Paul Moore]

On 23 March 2012 03:20, Brian Curtin  wrote:
>> Breakage of existing tools: Mark Hammond, Paul Moore, and Tim Golden have
>> all expressed that they have existing tools that would break and would need
>> to be adjusted to match the new location of the python.exe, because that
>> location is assumed to be at the root of the python install.
>
> Isn't the proposed "BinaryDir" registry key helpful here? It's not
> like we're telling people to fend for themselves -- we'll tell you
> where it's at.

It won't help me much. I either check a key and fall back on the old
method, or check in bin and fall back on the old method. No major
difference. The key is slightly worse, as I'm already looking in the
filesystem, so why open a registry key, but it's mostly irrelevant.

> I still don't really get how this portion of the proposal, the
> python.exe move to bin, is holding people up. If you're using the
> launcher, the change is invisible. If you're using a setup where bin
> is on the Path, the change is invisible. File associations? Invisible.
> If you're typing out the full path, you have to type "bin" in the
> middle -- this kind of sucks but I think we'll live.

Agreed, it's irrelevant for end users. It's only going to affect tools.

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] [Python-checkins] cpython: Issue #7652: Integrate the decimal floating point libmpdec library to speed

[Stefan Krah]

Dirkjan Ochtman  wrote:
> As a packager, is the libmpdec library used elsewhere? For Gentoo, we
> generally prefer to package libraries separately and have Python
> depend on them. From the site, it seems like you more or less wrote
> libmpdec for usage in Python, but if it's general-purpose and actually
> used in other software, it would be nice if Python grew a configure
> option to make it use the system libmpdec.

libmpdec was actually written before the module. It's general purpose
and it fully implements the specification. I'm only aware of in-house
usage.

Someone has tried to submit a libmpdec package to OpenSUSE, but it
was rejected with the claim that there already exists a package
with the name. I think the claim is false: There is a libmpcdec
package, where "cdec" presumably stands for "codec".


I'll add the --with-system-libmpdec option with the caveat that
changes will probably make it first into the libmpdec shipped
with Python, see also:

http://bugs.python.org/issue7652#msg155744


On the bright side, I don't expect many changes, since the specification
is stable.


Stefan Krah



___
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-checkins] cpython: Issue #7652: Integrate the decimal floating point libmpdec library to speed

[Dirkjan Ochtman]

On Fri, Mar 23, 2012 at 09:26, Stefan Krah  wrote:
> I'll add the --with-system-libmpdec option with the caveat that
> changes will probably make it first into the libmpdec shipped
> with Python, see also:
>
> http://bugs.python.org/issue7652#msg155744

Sounds good, thanks!

Cheers,

Dirkjan
___
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-checkins] cpython: Issue #7652: Integrate the decimal floating point libmpdec library to speed

[Stefan Krah]

Georg Brandl  wrote:
> >>>  Issue #7652: Integrate the decimal floating point libmpdec library to 
> >>> speed
> >>> up the decimal module. Performance gains of the new C implementation are
> >>> between 12x and 80x, depending on the application.
> > 
> > Congrats Stefan! And thanks for the huge chunk of code.
> 
> Seconded.  This is the kind of stuff that will make 3.3 the most awesomest
> 3.x release ever (and hopefully convince people that it does make sense to
> port)...

Thanks! For cdecimal specifically I have the impression that 3.x is already
used in the financial community, where web framework dependencies aren't an
issue.

On the web side, there seems to be a huge interest in speeding up database
accesses, so let me evangelize again: Database applications using decimal
will run 12x faster in 3.3.


Stefan Krah


___
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-checkins] cpython: Issue #7652: Integrate the decimal floating point libmpdec library to speed

[Victor Stinner]

By the way, how much faster is cdecimal? 72x or 80x?
http://docs.python.org/dev/whatsnew/3.3.html#decimal

Victor

2012/3/23 Stefan Krah :
> Georg Brandl  wrote:
>> >>>  Issue #7652: Integrate the decimal floating point libmpdec library to 
>> >>> speed
>> >>> up the decimal module. Performance gains of the new C implementation are
>> >>> between 12x and 80x, depending on the application.
>> >
>> > Congrats Stefan! And thanks for the huge chunk of code.
>>
>> Seconded.  This is the kind of stuff that will make 3.3 the most awesomest
>> 3.x release ever (and hopefully convince people that it does make sense to
>> port)...
>
> Thanks! For cdecimal specifically I have the impression that 3.x is already
> used in the financial community, where web framework dependencies aren't an
> issue.
>
> On the web side, there seems to be a huge interest in speeding up database
> accesses, so let me evangelize again: Database applications using decimal
> will run 12x faster in 3.3.
>
>
> Stefan Krah
>
>
> ___
> 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/victor.stinner%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] [Python-checkins] cpython: Issue #7652: Integrate the decimal floating point libmpdec library to speed

[Stefan Krah]

Amaury Forgeot d'Arc  wrote:
> > Seconded. ?This is the kind of stuff that will make 3.3 the most awesomest
> > 3.x release ever (and hopefully convince people that it does make sense to
> > port)...
> 
> On the other hand, porting PyPy to 3.3 will be more work ;-)

We've got to keep you on your toes, don't we? :)


> Fortunately the libmpdec directory should be reusable as is.
> Nice work!

Thanks, also for helping out with the MutableMapping context.


Stefan Krah


___
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 411 - request for pronouncement

[Eli Bendersky]

Hello,

PEP 411 -- Provisional packages in the Python standard library

Has been updated with all accumulated feedback from list discussions.
Here it is: http://www.python.org/dev/peps/pep-0411/ (the text is also
pasted in the bottom of this email).

The PEP received mostly positive feedback. The only undecided point is
where to specify that the package is provisional. Currently the PEP
mandates to specify it in the documentation and in the docstring.
Other suggestions were to put it in the code, either as a
__provisional__ attribute on the module, or collect all such modules
in a single sys.provisional list.

According to http://blog.python.org/2012/03/2012-language-summit-report.html,
the PEP was discussed in the language summit and overall viewed
positively, although no final decision has been reached.

ISTM a decision needs to be taken, which is why I request
pronouncement, with a recommendation on the requirement the PEP should
make of provisional modules (process details).

Eli



PEP: 411
Title: Provisional packages in the Python standard library
Version: $Revision$
Last-Modified: $Date$
Author: Nick Coghlan ,
Eli Bendersky 
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 2012-02-10
Python-Version: 3.3
Post-History: 2012-02-10


Abstract


The process of including a new package into the Python standard library is
hindered by the API lock-in and promise of backward compatibility implied by
a package being formally part of Python.  This PEP describes a methodology
for marking a standard library package "provisional" for the period of a single
minor release.  A provisional package may have its API modified prior to
"graduating" into a "stable" state.  On one hand, this state provides the
package with the benefits of being formally part of the Python distribution.
On the other hand, the core development team explicitly states that no promises
are made with regards to the the stability of the package's API, which may
change for the next release.  While it is considered an unlikely outcome,
such packages may even be removed from the standard library without a
deprecation period if the concerns regarding their API or maintenance prove
well-founded.


Proposal - a documented provisional state
=

Whenever the Python core development team decides that a new package should be
included into the standard library, but isn't entirely sure about whether the
package's API is optimal, the package can be included and marked as
"provisional".

In the next minor release, the package may either be "graduated" into a normal
"stable" state in the standard library, remain in provisional state, or be
rejected and removed entirely from the Python source tree.  If the package ends
up graduating into the stable state after being provisional, its API may
be changed according to accumulated feedback.  The core development team
explicitly makes no guarantees about API stability and backward compatibility
of provisional packages.


Marking a package provisional
-

A package will be marked provisional by a notice in its documentation page and
its docstring. The following paragraph will be added as a note at the top of
the documentation page:

The  package has been included in the standard library on a
provisional basis.  Backwards incompatible changes (up to and including
removal of the package) may occur if deemed necessary by the core
developers.

The phrase "provisional basis" will then be a link to the glossary term
"provisional package", defined as:

A provisional package is one which has been deliberately excluded from the
standard library's normal backwards compatibility guarantees.  While major
changes to such packages are not expected, as long as they are marked
provisional, backwards incompatible changes (up to and including removal of
the package) may occur if deemed necessary by core developers.  Such changes
will not be made gratuitously - they will occur only if serious flaws are
uncovered that were missed prior to the inclusion of the package.

This process allows the standard library to continue to evolve over time,
without locking in problematic design errors for extended periods of time.
See PEP 411 for more details.

The following will be added to the start of the packages's docstring:

The API of this package is currently provisional.  Refer to the
documentation for details.

Moving a package from the provisional to the stable state simply implies
removing these notes from its documentation page and docstring.


Which packages should go through the provisional state
--

We expect most packages proposed for addition into the Python standard library
to go through a minor release in the provisional state. There may, however,
be some exceptions, such as packages that us

Re: [Python-Dev] [Python-checkins] cpython: Issue #7652: Integrate the decimal floating point libmpdec library to speed

[Stefan Krah]

Victor Stinner  wrote:
> By the way, how much faster is cdecimal? 72x or 80x?
> http://docs.python.org/dev/whatsnew/3.3.html#decimal

It really depends on the precision. Also, the performance of decimal.py
depends on many other things in the Python tree, so it easily changes
+-10%. Currently, decimal.py seems to be 10% faster than in 3.2, maybe
because of the new string representation.


The 80x is a ballpark figure for the maximum expected speedup for
standard numerical floating point applications.


factorial(1000) is 219x faster in _decimal, and with increasing
precision the difference gets larger and larger.


For huge numbers _decimal is also faster than int:

factorial(100):

_decimal, calculation time: 6.844487905502319
_decimal, tostr():  0.033592939376831055

int, calculation time: 17.96010398864746
int, tostr(): ... still running ...



Stefan Krah


___
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 (Rationale part 1: Regularizing the layout)

[M.-A. Lemburg]

VanL wrote:
> As this has been brought up a couple times in this subthread, I figured that 
> I would lay out the
> rationale here.
> 
> There are two proposals on the table: 1) Regularize the install layout, and 
> 2) move the python
> binary to the binaries directory. This email will deal with the first, and a 
> second email will deal
> with the second.
> 
> 1) Regularizing the install layout:
> 
> One of Python's strengths is its cross-platform appeal. Carefully-
> written Python programs are frequently portable between operating
> systems and Python implementations with very few changes. Over the
> years, substantial effort has been put into maintaining platform
> parity and providing consistent interfaces to available functionality,
> even when different underlying implementations are necessary (such
> as with ntpath and posixpath).
> 
> One place where Python is unnecessarily different, however, is in
> the layout and organization of the Python environment. This is most
> visible in the name of the directory for binaries on the Windows platform 
> ("Scripts") versus the
> name of the directory for binaries on every other platform ("bin"), but a 
> full listing of the
> layouts shows
> substantial differences in layout and capitalization across platforms.
> Sometimes the include is capitalized ("Include"), and sometimes not; and
> the python version may or may not be included in the path to the
> standard library or not.
> 
> This may seem like a harmless inconsistency, and if that were all it was, I 
> wouldn't care. (That
> said, cross-platform consistency is its own good). But it becomes a real pain 
> when combined with
> tools like virtualenv or the new pyvenv to create cross-platform development 
> environments.
> 
> In particular, I regularly do development on both Windows and a Mac, and then 
> deploy on Linux. I do
> this in virtualenvs, so that I have a controlled and regular environment. I 
> keep them in sync using
> source control.
> 
> The problem comes when I have executable scripts that I want to include in my 
> dvcs - I can't have it
> in the obvious place - the binaries directory - because *the name of the 
> directory changes when you
> move between platforms.* More concretely, I can't hg add "Scripts/runner.py? 
> on my windows
> environment (where it is put in the PATH by virtualenv) and thendo a pull on 
> Mac or Linux and have
> it end up properly in "bin/runner.py" which is the correct PATH for those 
> platforms.
> 
> This applies anytime there are executable scripts that you want to manage 
> using source control
> across platforms. Django projects regularly have these, and I suspect we will 
> be seeing more of this
> with the new "project" support in virtualenvwrapper.
> 
> While a few people have wondered why I would want this -- hopefully answered 
> above -- I have not
> heard any opposition to this part of the proposal.
> 
> This first proposal is just to make the names of the directories match across 
> platforms. There are
> six keys defined in the installer files (sysconfig.cfg and 
> distutils.command.install): 'stdlib',
> 'purelib', 'platlib', 'headers', 'scripts',  and 'data'.
> 
> Currently on Windows, there are two different layouts defined:
> 
>   'nt': {
> 'stdlib': '{base}/Lib',
> 'platstdlib': '{base}/Lib',
> 'purelib': '{base}/Lib/site-packages',
> 'platlib': '{base}/Lib/site-packages',
> 'include': '{base}/Include',
> 'platinclude': '{base}/Include',
> 'scripts': '{base}/Scripts',
> 'data'   : '{base}',
> },
> 
>   'nt_user': {
> 'stdlib': '{userbase}/Python{py_version_nodot}',
> 'platstdlib': '{userbase}/Python{py_version_nodot}',
> 'purelib': '{userbase}/Python{py_version_nodot}/site-packages',
> 'platlib': '{userbase}/Python{py_version_nodot}/site-packages',
> 'include': '{userbase}/Python{py_version_nodot}/Include',
> 'scripts': '{userbase}/Scripts',
> 'data'   : '{userbase}',
> },
> 
> 
> The proposal is to make all the layouts change to:
> 
>   'nt': {
> 'stdlib': '{base}/lib',
> 'platstdlib': '{base}/lib',
> 'purelib': '{base}/lib/site-packages',
> 'platlib': '{base}/lib/site-packages',
> 'include': '{base}/include',
> 'platinclude': '{base}/include',
> 'scripts': '{base}/bin',
> 'data'   : '{base}',
> },
> 
> The change here is that 'Scripts' will change to 'bin' and the capitalization 
> will be removed. Also,
> "user installs" of Python will have the same internal layout as "system 
> installs" of Python. This
> will also, not coincidentally, match the install layout for posix, at least 
> with regard to the
> 'bin', 'lib', and 'include' directories.
> 
> Again, I have not heard *anyone* objecting to this part of the proposal as it 
> is laid out here.
> (Paul had a concern with the lib directory earlier, but he said he was ok 
> with the above).
> 
> Please let me know if you have any problems or concerns with this part 1.

Since userbase 

Re: [Python-Dev] Python install layout and the PATH on win32 (Rationale part 2: Moving the python.exe)

[Mark Hammond]

On 23/03/2012 7:10 PM, Paul Moore wrote:

On 23 March 2012 03:20, Brian Curtin  wrote:

Breakage of existing tools: Mark Hammond, Paul Moore, and Tim Golden have
all expressed that they have existing tools that would break and would need
to be adjusted to match the new location of the python.exe, because that
location is assumed to be at the root of the python install.


Isn't the proposed "BinaryDir" registry key helpful here? It's not
like we're telling people to fend for themselves -- we'll tell you
where it's at.


It won't help me much. I either check a key and fall back on the old
method, or check in bin and fall back on the old method. No major
difference. The key is slightly worse, as I'm already looking in the
filesystem, so why open a registry key, but it's mostly irrelevant.


That's a really good point.  On reflection, the 2 tools I've been using 
as examples are already sniffing around the file-system relative to the 
install path, looking in the root and the PCBuild directories.  The 
simplest approach for these tools to take is to simply sniff the bin 
directory too - so they are unlikely to refer to the BinaryDir key at all.


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-checkins] cpython: Issue #7652: Integrate the decimal floating point libmpdec library to speed

[Antoine Pitrou]

On Fri, 23 Mar 2012 10:22:55 +0100
Stefan Krah  wrote:
> Georg Brandl  wrote:
> > >>>  Issue #7652: Integrate the decimal floating point libmpdec library to 
> > >>> speed
> > >>> up the decimal module. Performance gains of the new C implementation are
> > >>> between 12x and 80x, depending on the application.
> > > 
> > > Congrats Stefan! And thanks for the huge chunk of code.
> > 
> > Seconded.  This is the kind of stuff that will make 3.3 the most awesomest
> > 3.x release ever (and hopefully convince people that it does make sense to
> > port)...
> 
> Thanks! For cdecimal specifically I have the impression that 3.x is already
> used in the financial community, where web framework dependencies aren't an
> issue.
> 
> On the web side, there seems to be a huge interest in speeding up database
> accesses, so let me evangelize again: Database applications using decimal
> will run 12x faster in 3.3.

Are you sure it isn't 12.5x ?

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] PendingDeprecationWarning

[Antoine Pitrou]

On Thu, 22 Mar 2012 17:13:27 -0400
Terry Reedy  wrote:
> My impression is that the original reason for PendingDeprecationWarning 
> versus DeprecationWarning was to be off by default until the last 
> release before removal. But having DeprecationWarnings on by default was 
> found to be too obnoxious and it too is off by default. So do we still 
> need PendingDeprecationWarnings? My impression is that it is mostly not 
> used, as it is a nuisance to remember to change from one to the other. 
> The deprecation message can always indicate the planned removal time. I 
> searched the Developer's Guide for both deprecation and 
> DeprecationWarning and found nothing.

Warnings are not only for us, they are for third-party libraries.
In this case it seems removing PendingDeprecationWarning would be a
pointless nuisance.

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] Setting up a RHEL6 buildbot

[Antoine Pitrou]

On Fri, 23 Mar 2012 13:48:30 +1000
Nick Coghlan  wrote:
> I'm looking into getting a RHEL6 system set up to add to the buildbot
> fleet. The info already on the wiki [1] is pretty helpful, but does
> anyone have any suggestions on appropriate CPU/memory/disk
> allocations?

One or two cores is enough, unless you want to allow for multiple
builds in parallel (in which case do say so :-)).

You'll need quite a bit of disk space though. At least 20 or 30 GB to
err on the safe side, IMO.

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] [Python-checkins] cpython: Issue #7652: Integrate the decimal floating point libmpdec library to speed

[Stefan Krah]

Antoine Pitrou  wrote:
> > On the web side, there seems to be a huge interest in speeding up database
> > accesses, so let me evangelize again: Database applications using decimal
> > will run 12x faster in 3.3.
> 
> Are you sure it isn't 12.5x ?

Well, that was marketing for 3.3.


Stefan Krah


___
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 (Rationale part 2: Moving the python.exe)

[Paul Moore]

On 22 March 2012 23:15, VanL  wrote:
> Another use case was just pointed out to me: making things consistent with 
> buildout. Given a similar use
> case (create repeatable cross platform environments), they create and use a 
> 'bin' directory for executable files.

Another problem case: cx_Freeze. This currently breaks when installed
in a viretualenv, as it locates the "Scripts" directory by appending
"Scripts" to the directory of the python executable.

So the proposed change *will* break cx_Freeze. The Scripts->bin change
will also break it.

Paul.

PS Yes, I need to report the existing bug. The point remains, however...
___
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 (Rationale part 1: Regularizing the layout)

[PJ Eby]

On Mar 22, 2012 2:57 PM, "VanL"  wrote:
> That said, while I think that the above is a good idea, my personal
ambitions are more modest: If the names of the top-level directories only
were changed to 'bin', 'lib', and 'include' - never mind differences under
'lib' - I would be happy. In fact, even the one change of 'Scripts' to
'bin' everywhere would get 90% of my uses.

Why don't you just install your scripts to 'bin' everywhere then, and add
the bin directory to the path on Windows?  Distutils allows you to
customize your install target for scripts, as does setuptools.  Why do you
need *Python's own default* to change, to support your preference for using
a bin directory?

Even if you are using tools that don't use distutils' configuration
settings for these directories, why not simply fix those tools so that they
do?
___
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?

[Zooko Wilcox-O'Hearn]

> I merged the two functions into one function: time.steady(strict=False).
>
> time.steady() should be monotonic most of the time, but may use a fallback.
>
> time.steady(strict=True) fails with OSError or NotImplementedError if
> reading the monotonic clock failed or if no monotonic clock is available.

If someone wants time.steady(strict=False), then why don't they just
continue to use time.time()?

I want time.steady(strict=True), and I'm glad you're providing it and
I'm willing to use it this way, although it is slightly annoying
because "time.steady(strict=True)" really means
"time.steady(i_really_mean_it=True)". Else, I would have used
"time.time()".

I am aware of a large number of use cases for a steady clock (event
scheduling, profiling, timeouts), and a large number of uses cases for
a "NTP-respecting wall clock" clock (calendaring, displaying to a
user, timestamping). I'm not aware of any use case for "steady if
implemented, else wall-clock", and it sounds like a mistake to me.

Regards,

Zooko
___
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] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2012-03-16 - 2012-03-23)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open3346 ( +9)
  closed 22829 (+50)
  total  26175 (+59)

Open issues with patches: 1434 


Issues opened (42)
==

#5301: add mimetype for image/vnd.microsoft.icon (patch)
http://bugs.python.org/issue5301  reopened by eric.araujo

#10340: asyncore doesn't properly handle EINVAL on OSX
http://bugs.python.org/issue10340  reopened by r.david.murray

#14336: Difference between pickle implementations for function objects
http://bugs.python.org/issue14336  opened by sbt

#14338: Document how to forward POST data on redirects
http://bugs.python.org/issue14338  opened by beerNuts

#14339: Optimizing bin, oct and hex
http://bugs.python.org/issue14339  opened by storchaka

#14340: Update embedded copy of expat - fix security & crash issues
http://bugs.python.org/issue14340  opened by gregory.p.smith

#14341: sporadic (?) test_urllib2 failures
http://bugs.python.org/issue14341  opened by pitrou

#14345: Document socket.SOL_SOCKET
http://bugs.python.org/issue14345  opened by techtonik

#14349: The documentation of 'dis' doesn't describe MAKE_FUNCTION corr
http://bugs.python.org/issue14349  opened by eli.bendersky

#14350: Strange Exception from copying an iterable
http://bugs.python.org/issue14350  opened by Jakob.Bowyer

#14352: Distutils2: add logging message to report successful installat
http://bugs.python.org/issue14352  opened by agronholm

#14353: Proper gettext support in locale module
http://bugs.python.org/issue14353  opened by melflynn

#14354: Crash in _ctypes_alloc_callback
http://bugs.python.org/issue14354  opened by ogre

#14356: Distutils2 ignores site-local configuration
http://bugs.python.org/issue14356  opened by agronholm

#14357: Distutils2 does not work with virtualenv
http://bugs.python.org/issue14357  opened by agronholm

#14360: email.encoders.encode_quopri doesn't work with python 3.2
http://bugs.python.org/issue14360  opened by mitya57

#14361: No link to issue tracker on Python home page
http://bugs.python.org/issue14361  opened by stevenjd

#14362: No mention of collections.ChainMap in What's New for 3.3
http://bugs.python.org/issue14362  opened by stevenjd

#14364: Argparse incorrectly handles '--'
http://bugs.python.org/issue14364  opened by maker

#14365: argparse: subparsers, argument abbreviations and ambiguous opt
http://bugs.python.org/issue14365  opened by jakub

#14366: Supporting bzip2 and lzma compression in zip files
http://bugs.python.org/issue14366  opened by storchaka

#14367: try/except block in ismethoddescriptor() in inspect.py, so tha
http://bugs.python.org/issue14367  opened by ncdave4life

#14368: floattime() should not raise an exception
http://bugs.python.org/issue14368  opened by haypo

#14369: make __closure__ writable
http://bugs.python.org/issue14369  opened by Yury.Selivanov

#14371: Add support for bzip2 compression to the zipfile module
http://bugs.python.org/issue14371  opened by storchaka

#14372: Fix all invalid usage of borrowed references
http://bugs.python.org/issue14372  opened by haypo

#14373: C implementation of functools.lru_cache
http://bugs.python.org/issue14373  opened by anacrolix

#14374: Compiling Python 2.7.2 on HP11i PA-RISC ends with segmentation
http://bugs.python.org/issue14374  opened by donchen

#14375: Add socketserver running property
http://bugs.python.org/issue14375  opened by giampaolo.rodola

#14376: sys.exit documents argument as "integer" but actually requires
http://bugs.python.org/issue14376  opened by Gareth.Rees

#14377: Modify serializer for xml.etree.ElementTree to allow forcing t
http://bugs.python.org/issue14377  opened by adpoliak

#14379: Several traceback docs improvements
http://bugs.python.org/issue14379  opened by techtonik

#14381: Intern certain integral floats for memory savings and performa
http://bugs.python.org/issue14381  opened by krisvale

#14383: Generalize the use of _Py_IDENTIFIER in ceval.c and typeobject
http://bugs.python.org/issue14383  opened by haypo

#14385: Support other types than dict for __builtins__
http://bugs.python.org/issue14385  opened by haypo

#14386: Expose dictproxy as a public type
http://bugs.python.org/issue14386  opened by haypo

#14387: Include\accu.h incompatible with Windows.h
http://bugs.python.org/issue14387  opened by je...@livedata.com

#14390: Tkinter single-threaded deadlock
http://bugs.python.org/issue14390  opened by jcbollinger

#14391: misc TYPO in argparse.Action docstring
http://bugs.python.org/issue14391  opened by shima__shima

#14392: type=bool doesn't raise error in argparse.Action
http://bugs.python.org/issue14392  opened by shima__shima

#14393: Incorporate Guide to Magic Methods?
http://bugs.python.org/issue14393  opened by djc

#14394: missing links on performance claims of cdecimal
http://bugs.python.org/issue14394  o

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

[Victor Stinner]

> I want time.steady(strict=True), and I'm glad you're providing it and
> I'm willing to use it this way, although it is slightly annoying
> because "time.steady(strict=True)" really means
> "time.steady(i_really_mean_it=True)". Else, I would have used
> "time.time()".
>
> I am aware of a large number of use cases for a steady clock (event
> scheduling, profiling, timeouts), and a large number of uses cases for
> a "NTP-respecting wall clock" clock (calendaring, displaying to a
> user, timestamping). I'm not aware of any use case for "steady if
> implemented, else wall-clock", and it sounds like a mistake to me.

time.steady(strict=False) is what you need to implement timeout.

If you use time.steady(strict=True) for timeout, it means that you
cannot use select, threads, etc. if your platform doesn't provide
monotonic clock, whereas it works "well" (except the issue of adjusted
time) with Python < 3.3.

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] Issue 13524: subprocess on Windows

[Brad Allen]

On Thu, Mar 22, 2012 at 2:35 PM, Glyph Lefkowitz
 wrote:

> Also, in order to execute in any installation environment where libraries are 
> found in non-default locations, you will need to set LD_LIBRARY_PATH.  Oh, 
> and you will also need to set $PATH on UNIX so that libraries can find their 
> helper programs and %PATH% on Windows so that any compiled 
> dynamically-loadable modules and/or DLLs can be loaded.  And by the way you 
> will also need to relay DYLD_LIBRARY_PATH if you did a UNIX-style build on OS 
> X, not LD_LIBRARY_PATH.  Don't forget that you probably also need PYTHONPATH 
> to make sure any subprocess environments can import the same modules as their 
> parent.  Not to mention SSH_AUTH_SOCK if your application requires access to 
> _remote_ process spawning, rather than just local.  Oh and DISPLAY in case 
> your subprocesses need GUI support from an X11 program (which sometimes you 
> need just to initialize certain libraries which don't actually do anything 
> with a GUI).  Oh and __CF_USER_TEXT_ENCODING is important sometimes too, 
> don't forget that.  And if your subprocess is in Perl or Ruby or Java you may 
> need a couple dozen other variables which your deployment environment has set 
> for you too.  Did I mention CFLAGS or LC_ALL yet?  Let me tell you a story 
> about this one HP/UX machine...
>
> Ahem.
>
> Bottom line: it seems like screwing with the process spawning environment to 
> make it minimal is a good idea for simplicity, for security, and for 
> modularity.  But take it from me, it isn't.  I guarantee you that you don't 
> actually know what is in your operating system's environment, and 
> initializing it is a complicated many-step dance which some vendor or 
> sysadmin or product integrator figured out how to do much better than your 
> hapless Python program can.
>
> %SystemRoot% is just the tip of a very big, very nasty iceberg.  Better not 
> to keep refining why exactly it's required, or someone will eventually be 
> adding a new variable (starting with %APPDATA% and %HOMEPATH%) that can 
> magically cause your subprocess not to spawn properly to this page every six 
> months for eternity.  If you're spawning processes as a regular user, you 
> should just take the environment you're given, perhaps with a few specific 
> light additions whose meaning you understand.  If you're spawning a process 
> as an administrator or root, you should probably initialize the environment 
> for the user you want to spawn that process as using an OS-specific mechanism 
> like login(1).  (Sorry that I don't know the Windows equivalent.)


Thanks, Glyph. In that case maybe the Python subprocess docs need not
single out SystemRoot, but instead plaster a big warning around the
use of the 'env' parameter.:

Here is what the docs currently state for the Popen constructor 'env' parameter:

>If env is not None, it must be a mapping that defines the environment 
>variables for the new process; these are used instead of inheriting the 
>current process’ environment, which is the default behavior.

> Note: If specified, env must provide any variables required for the program 
> to execute. On Windows, in order to run a side-by-side assembly the specified 
> env must include a valid SystemRoot.

The "Note" section could instead state something like: "In most cases,
the child process will need many of the same environment variables as
the current process. Usually the safest course of action is to build
the env dict to contain all the same keys and values from os.environ.
For example... "
___
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 (Rationale part 1: Regularizing the layout)

[VanL]

On Friday, March 23, 2012 at 11:39 AM, PJ Eby wrote:
> Even if you are using tools that don't use distutils' configuration settings 
> for these directories, why not simply fix those tools so that they do?  

Thats what I do currently - I set things to bin and patch Python and the tools 
so that they work.

However, have considered this to be a little bit of a wart anyway for a long 
time - even before I adopted my current method of working - because it is a 
pointless inconsistency.

The fact that it makes virtual environments consistent across platforms, 
together with pyvenv going into 3.3, gave me enough of a push to elevate this 
from private annoyance to "should fix."

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] Python install layout and the PATH on win32 (Rationale part 2: Moving the python.exe)

[Stephen J. Turnbull]

On Fri, Mar 23, 2012 at 2:37 PM, Paul Moore  wrote:

> Another problem case: cx_Freeze. This currently breaks when installed
> in a viretualenv, as it locates the "Scripts" directory by appending
> "Scripts" to the directory of the python executable.
>
> So the proposed change *will* break cx_Freeze. The Scripts->bin change
> will also break it.
>
> Paul.
>
> PS Yes, I need to report the existing bug. The point remains, however...

This seems to me to be evidence that the things that will be
broken are in need of fixing anyway.<0.5 wink/>  virtualenv
is something that should Just Work in most, if not all, cases.
___
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-checkins] cpython (3.2): attempt to fix asyncore buildbot failure

[Jim Jewett]

What does this verify?

My assumption from the name (test_quick_connect) and the context (an
asynchronous server) is that it is verifying the server can handle a
certain level of load.  Refusing the sockets should then be a failure,
or at least a skipped test.

Would the below fail even if asyncore.loop were taken out of the
threading.Thread target  altogether?


On Fri, Mar 23, 2012 at 10:10 AM, giampaolo.rodola
 wrote:
> http://hg.python.org/cpython/rev/2db4e916245a
> changeset:   75901:2db4e916245a
> branch:      3.2
> parent:      75897:b97964af7299
> user:        Giampaolo Rodola' 
> date:        Fri Mar 23 15:07:07 2012 +0100
> summary:
>  attempt to fix asyncore buildbot failure
>
> files:
>  Lib/test/test_asyncore.py |  10 +++---
>  1 files changed, 7 insertions(+), 3 deletions(-)
>
>
> diff --git a/Lib/test/test_asyncore.py b/Lib/test/test_asyncore.py
> --- a/Lib/test/test_asyncore.py
> +++ b/Lib/test/test_asyncore.py
> @@ -741,11 +741,15 @@
>
>         for x in range(20):
>             s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
> +            s.settimeout(.2)
>             s.setsockopt(socket.SOL_SOCKET, socket.SO_LINGER,
>                          struct.pack('ii', 1, 0))
> -            s.connect(server.address)
> -            s.close()
> -
> +            try:
> +                s.connect(server.address)
> +            except socket.error:
> +                pass
> +            finally:
> +                s.close()
>
>  class TestAPI_UseSelect(BaseTestAPI):
>     use_poll = False
>
> --
> Repository URL: http://hg.python.org/cpython
>
> ___
> Python-checkins mailing list
> python-check...@python.org
> http://mail.python.org/mailman/listinfo/python-checkins
>
___
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 (Rationale part 1: Regularizing the layout)

[PJ Eby]

On Mar 23, 2012 1:37 PM, "VanL"  wrote:
>
> On Friday, March 23, 2012 at 11:39 AM, PJ Eby wrote:
>>
>> Even if you are using tools that don't use distutils' configuration
settings for these directories, why not simply fix those tools so that they
do?
>
>
> Thats what I do currently - I set things to bin and patch Python and the
tools so that they work.

Patch *Python*?  Where?  Are you talking about the distutils/distutils.cfg
file?

My point here is that AFAIK, Python already supports your desired layout -
so your use case doesn't provide much of an argument in favor of making it
the default.

> However, have considered this to be a little bit of a wart anyway for a
long time - even before I adopted my current method of working - because it
is a pointless inconsistency.

In other words, that's the real reason - which, as it's already been
pointed out, is not much of an argument in favor of changing it.
Consistency with previous Python releases seems a far more *useful*
consistency to maintain than cross-platform consistency, which is only of
relevance to cross-platform developers -- at best only a subset of the
Windows developer audience.

Worse, changing it means that tools have to grow version-specific code, not
just platform-specific code.

> The fact that it makes virtual environments consistent across platforms,

Not really seeing a point.  Home directory layouts, "develop" installs,
.pth files, -m scripts... there are *zillions* of ways to develop code in
cross-platform directory layouts, including the one you're using now.

Tool developers are going "meh" about your proposal because it doesn't
actually solve any problems for them: they still have to support the old
layout, and if their code already uses distutils' facilities for obtaining
paths, there's nothing they gain from the change.

IOW, the only person who gains from the consistency is someone who wants
their virtualenv's to look the same and check them into source.  I'm really
not seeing this as being a big enough group to be worth inconveniencing
other people for, vs. telling them to add bin/ to PATH on Windows and edit
a distutils config file.  At best, this might be deserving of a FAQ entry
on how to set up cross platform development environments.

AFAICT, virtualenvs are overkill for most development anyway.  If you're
not using distutils except to install dependencies, then configure
distutils to install scripts and libraries to the same directory, and then
do all your development in that directory.  Presto!  You now have a
cross-platform "virtualenv".  Want the scripts on your path?  Add that
directory to your path... or if on Windows, don't bother, since the current
directory is usually on the path.   (In fact, if you're only using
easy_install to install your dependencies, you don't even need to edit the
distutils configuration, just use "-md targetdir".)

The entire virtualenv concept was originally introduced as a way for
non-root *nix users to have private site-packages directories with .pth
support, in order to be able to install eggs -- a use case which was then
solved by user-specific site directories in Python 2.6, and the addition of
the site.py hacks in easy_install (to allow any directory to be a
virtualenv as far as easy_install was concerned).

Virtualenv seem to have caught on for a variety of other uses than that,
but AFAIK, that's only because it's the most *visible* solution for those
uses.  Just dumping things in a directory adjacent to the corresponding
scripts is the original virtualenv, and it still works just dandy -- most
people just don't *know* this.  (And again, if there are tools out there
that *don't* support single-directory virtualenvs, the best answer is
probably to fix them.)
___
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 (Rationale part 1: Regularizing the layout)

[Carl Meyer]

Hi PJ,

On 03/23/2012 12:35 PM, PJ Eby wrote:
> AFAICT, virtualenvs are overkill for most development anyway.  If you're
> not using distutils except to install dependencies, then configure
> distutils to install scripts and libraries to the same directory, and
> then do all your development in that directory.  Presto!  You now have a
> cross-platform "virtualenv".  Want the scripts on your path?  Add that
> directory to your path... or if on Windows, don't bother, since the
> current directory is usually on the path.   (In fact, if you're only
> using easy_install to install your dependencies, you don't even need to
> edit the distutils configuration, just use "-md targetdir".)

Creating and using a virtualenv is, in practice, _easier_ than any of
those alternatives, so it's hard to see it as "overkill." Not to mention
that the "isolation from system site-packages" feature is quite popular
(the outpouring of gratitude when virtualenv went isolated-by-default a
few months ago was astonishing), and AFAIK none of your alternative
proposals support that at all.

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 (Rationale part 1: Regularizing the layout)

[VanL]

On Friday, March 23, 2012 at 1:35 PM, PJ Eby wrote: 
> Tool developers are going "meh" about your proposal because it doesn't 
> actually solve any problems for them: they still have to support the old 
> layout, and if their code already uses distutils' facilities for obtaining 
> paths, there's nothing they gain from the change.

Three notes. FIrst, distutils.cfg doesn't always work because it is centered 
around the idea of set paths that are the same each time - which doesn't always 
work with virtualenvs. Further, a number of tools find that it doesn't work 
(haven't seen it myself, but look at the comments in pypm's installer). So yes, 
I patch python.

Second, most installer tools don't follow distutils.cfg. Even if that helps for 
python setup.py install, the other tools are still broken when you want to 
specify a layout. That is why changing the defaults is the only effective way 
to make this change - because the defaults drive what is actually implemented. 
I know, because I have looked at and patched these tools to make them work.

Third, there are some tool makers going meh - because you are right, this is 
not a problem they have. This is a problem associated with using those tools. 
And regardless of there being other ways to do it, including your 'dump it in a 
directory' method, development in virtualenvs is convenient, widespread, and on 
the rise. Given that pyvenv will go into 3.3, it will be the 'one obvious way 
to do it' - making going-forward cross-platform compatibility a positive good. 
Again I note the example of buildout.

And fourth, (because nobody expects the spanish inquisition), isn't the 
gratuitous difference a (small but) obvious wart? Does anybody positively like 
'Scripts'? The most common comment I have received when talking to people off 
this list has been, 'yeah, that was always sort of weird.'___
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] Issue #10278 -- why not just an attribute?

[Neil Schemenauer]

Jim J. Jewett  wrote:
> Passing strict as an argument seems like overkill since it will always
> be meaningless on some (most?) platforms.

A keyword argument that gets passed as a constant in the caller is
usually poor API.  Why not have two different functions?

  Neil

___
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?

[Glyph]

On Mar 23, 2012, at 12:55 PM, Zooko Wilcox-O'Hearn wrote:

>> I merged the two functions into one function: time.steady(strict=False).
>> 
>> time.steady() should be monotonic most of the time, but may use a fallback.
>> 
>> time.steady(strict=True) fails with OSError or NotImplementedError if
>> reading the monotonic clock failed or if no monotonic clock is available.
> 
> If someone wants time.steady(strict=False), then why don't they just
> continue to use time.time()?
> 
> I want time.steady(strict=True), and I'm glad you're providing it and
> I'm willing to use it this way, although it is slightly annoying
> because "time.steady(strict=True)" really means
> "time.steady(i_really_mean_it=True)". Else, I would have used
> "time.time()".
> 
> I am aware of a large number of use cases for a steady clock (event
> scheduling, profiling, timeouts), and a large number of uses cases for
> a "NTP-respecting wall clock" clock (calendaring, displaying to a
> user, timestamping). I'm not aware of any use case for "steady if
> implemented, else wall-clock", and it sounds like a mistake to me.

I think I've lost the thread of this discussion.  Is that really what 
"strict=False" was supposed to mean?

I am aware of use-cases which want to respect slew, but reject steps.  The 
local clock might not be all that reliable, and slew actually keeps it closer 
to "real" time.  My understanding was that strict=True was something like 
CLOCK_MONOTONIC_RAW and strict=False was just CLOCK_MONOTONIC.

I am increasingly thinking that the first order of business here should be to 
expose the platform-specific mechanisms directly, then try to come up with a 
unifying abstraction in the time module later.  It's hard enough to understand 
the substantially dense verbiage around all of these different timers on their 
respective platforms; understanding which one exactly Python is swaddling up in 
a portability layer seems bound to generate confusion.  Not to mention that you 
run into awesome little edge cases like this: 
https://github.com/ThomasHabets/monotonic_clock/blob/master/src/monotonic_win32.c#L62
 which means sometimes you really really need to know exactly which clock is 
getting used, if you want to make it work right (unless Python is going to ship 
with all of these workarounds on day 1).

(I still object to the "time.steady" naming, because this is what people in the 
make-believe land of C++ call it.  The people who live in the real world of C 
and POSIX all refer to it as "monotonic".  And even the C++ purists slip up 
sometimes, c.f. : "Class 
std::chrono::steady_clock represents a monotonic clock.")

If there really are some applications for which the desired behavior is 
'monotonic clock, but if you can't get one, nevermind, wallclock is good 
enough', it strikes me that this should be as explicit as possible, it should 
not be the default, and if

try:
value = time.steady()
except OhWowYourComputerReallyHasProblems:
value = time.time()

is generally considered too onerous, it should be spelled 
time.steady(fallback=time.time).

-glyph___
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] Issue 13524: subprocess on Windows

[Glyph]

On Mar 23, 2012, at 1:26 PM, Brad Allen wrote:

> Thanks, Glyph. In that case maybe the Python subprocess docs need not
> single out SystemRoot, but instead plaster a big warning around the
> use of the 'env' parameter.

I agree.  I'm glad that my bitter experience here might be useful to someone in 
the future - all those late nights trying desperately to get my unit tests to 
run on some newly configured, slightly weird buildbot didn't go to waste :).

> The "Note" section could instead state something like: "In most cases,
> the child process will need many of the same environment variables as
> the current process. Usually the safest course of action is to build
> the env dict to contain all the same keys and values from os.environ.
> For example... "

I think including all the examples might be overstating the case.  It is 
probably best to say that other operating systems, vendors, and integration 
tools may set necessary environment variables that there is no way for you to 
be aware of in advance, unless you are an expert sysadmin on every platform 
where you expect your code to run, and that many of these variables are 
required for libraries to function properly, both libraries bundled with python 
and those from third parties.

-glyph___
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 23 March 2012 20:40, Glyph  wrote:
> I am increasingly thinking that the first order of business here should be
> to expose the platform-specific mechanisms directly, then try to come up
> with a unifying abstraction in the time module later.

+1.

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] Issue 13524: subprocess on Windows

[Brad Allen]

On Fri, Mar 23, 2012 at 3:46 PM, Glyph  wrote:
> On Mar 23, 2012, at 1:26 PM, Brad Allen wrote:
>
> Thanks, Glyph. In that case maybe the Python subprocess docs need not
> single out SystemRoot, but instead plaster a big warning around the
> use of the 'env' parameter.
>
>
> I agree.  I'm glad that my bitter experience here might be useful to someone
> in the future - all those late nights trying desperately to get my unit
> tests to run on some newly configured, slightly weird buildbot didn't go to
> waste :).

Ok, I'll open a ticket on the bugtracker for this over the weekend.
___
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?

[Yury Selivanov]

On 2012-03-23, at 4:40 PM, Glyph wrote:
> (I still object to the "time.steady" naming, because this is what people in 
> the make-believe land of C++ call it.  The people who live in the real world 
> of C and POSIX all refer to it as "monotonic".  And even the C++ purists slip 
> up sometimes, c.f. : 
> "Class std::chrono::steady_clock represents a monotonic clock.")

+1.

I also think that the function should be called 'monotonic' and simply fail 
with OSError on platforms that don't support such clocks.  The 'strict' 
argument is non-intuitive.

-
Yury
___
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?

[Yury Selivanov]

On 2012-03-23, at 1:27 PM, Victor Stinner wrote:

>> I want time.steady(strict=True), and I'm glad you're providing it and
>> I'm willing to use it this way, although it is slightly annoying
>> because "time.steady(strict=True)" really means
>> "time.steady(i_really_mean_it=True)". Else, I would have used
>> "time.time()".
>> 
>> I am aware of a large number of use cases for a steady clock (event
>> scheduling, profiling, timeouts), and a large number of uses cases for
>> a "NTP-respecting wall clock" clock (calendaring, displaying to a
>> user, timestamping). I'm not aware of any use case for "steady if
>> implemented, else wall-clock", and it sounds like a mistake to me.
> 
> time.steady(strict=False) is what you need to implement timeout.
> 
> If you use time.steady(strict=True) for timeout, it means that you
> cannot use select, threads, etc. if your platform doesn't provide
> monotonic clock, whereas it works "well" (except the issue of adjusted
> time) with Python < 3.3.

Why can't I use select & threads?  You mean that if a platform does not
support monotonic clocks it also does not support threads and select sys
call? 

-
Yury
___
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]

Yes, call it what it is. monotonic or monotonic_time, because that's why
I'm using it. No flags.

I've followed this thread throughout, and I'm still not sure if "steady"
gives the real guarantees it claims. It's trying to be too much. Existing
bugs complain about backward jumps and demand a clock that doesn't do this.
The function should guarantee monotonicity only, and not get
overcomplicated.
___
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/23 Yury Selivanov :
> Why can't I use select & threads?  You mean that if a platform does not
> support monotonic clocks it also does not support threads and select sys
> call?

Python 3.3 now uses time.steady(strict=False) in the threading and
queue modules. If we replace it by time.steady(strict=True), you may
get an error if your platform doesn't provide a monotonic clock and so
you cannot use these modules.

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?

[Yury Selivanov]

On 2012-03-23, at 7:07 PM, Victor Stinner wrote:

> 2012/3/23 Yury Selivanov :
>> Why can't I use select & threads?  You mean that if a platform does not
>> support monotonic clocks it also does not support threads and select sys
>> call?
> 
> Python 3.3 now uses time.steady(strict=False) in the threading and
> queue modules. If we replace it by time.steady(strict=True), you may
> get an error if your platform doesn't provide a monotonic clock and so
> you cannot use these modules.

Why this won't work?

try:
  from time import monotonic as _time
except ImportError:
  from time import time as _time

OR (if we decide to fail on first call, instead of ImportError)

import time
try:
  time.monotonic()
except OSError:
  _time = time
else:
  _time = time.monotonic

And then just use '_time' in your code?  What's the deal with the
'strict' kwarg?

I really like how it currently works with epoll, for instance.  It either
exists in the 'select' module, or not, if the host OS doesn't support it.
I think it should be the same for 'time.monotonic'.

-
Yury

___
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] Rename time.steady(strict=True) to time.monotonic()?

[Victor Stinner]

Hi,

time.steady(strict=True) looks to be confusing for most people, some
of them don't understand the purpose of the flag and others don't like
a flag changing the behaviour of the function.

I propose to replace time.steady(strict=True) by time.monotonic().
That would avoid the need of an ugly NotImplementedError: if the OS
has no monotonic clock, time.monotonic() will just not exist.

So we will have:

- time.time(): realtime, can be adjusted by the system administrator
(manually) or automatically by NTP
- time.clock(): monotonic clock on Windows, CPU time on UNIX
- time.monotonic(): monotonic clock, its speed may or may not be
adjusted by NTP but it only goes forward, may raise an OSError
- time.steady(): monotonic clock or the realtime clock, depending on
what is available on the platform (use monotonic in priority). may be
adjusted by NTP or the system administrator, may go backward.

time.steady() is something like:

try:
  return time.monotonic()
except (NotImplementError, OSError):
  return time.time()

time.time(), time.clock(), time.steady() are always available, whereas
time.monotonic() will not be available on some platforms.

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] Rename time.steady(strict=True) to time.monotonic()?

[Brian Curtin]

On Mar 23, 2012 6:25 PM, "Victor Stinner"  wrote:
>
> Hi,
>
> time.steady(strict=True) looks to be confusing for most people, some
> of them don't understand the purpose of the flag and others don't like
> a flag changing the behaviour of the function.
>
> I propose to replace time.steady(strict=True) by time.monotonic().
> That would avoid the need of an ugly NotImplementedError: if the OS
> has no monotonic clock, time.monotonic() will just not exist.
>
> So we will have:
>
> - time.time(): realtime, can be adjusted by the system administrator
> (manually) or automatically by NTP
> - time.clock(): monotonic clock on Windows, CPU time on UNIX
> - time.monotonic(): monotonic clock, its speed may or may not be
> adjusted by NTP but it only goes forward, may raise an OSError
> - time.steady(): monotonic clock or the realtime clock, depending on
> what is available on the platform (use monotonic in priority). may be
> adjusted by NTP or the system administrator, may go backward.
>
> time.steady() is something like:
>
> try:
>  return time.monotonic()
> except (NotImplementError, OSError):
>  return time.time()
>
> time.time(), time.clock(), time.steady() are always available, whereas
> time.monotonic() will not be available on some platforms.
>
> Victor

This seems like it should have been a PEP, or maybe should become a PEP.
___
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] Rename time.steady(strict=True) to time.monotonic()?

[Victor Stinner]

> This seems like it should have been a PEP, or maybe should become a PEP.

I replaced time.wallclock() by time.steady(strict=False) and
time.monotonic() by time.steady(strict=True). This change solved the
naming issue of time.wallclock(), but it was a bad idea to merge
monotonic() feature into time.steady(). It looks like everybody
agrees, am I wrong?

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] Rename time.steady(strict=True) to time.monotonic()?

[Yury Selivanov]

On 2012-03-23, at 7:28 PM, Brian Curtin wrote:
> This seems like it should have been a PEP, or maybe should become a PEP.

Why?  AFAIK Victor just proposes to add two new functions: monotonic() and
steady().

time() and clock() do already exist and won't be changed.

-
Yury
___
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] Rename time.steady(strict=True) to time.monotonic()?

[Yury Selivanov]

On 2012-03-23, at 7:25 PM, Victor Stinner wrote:

> - time.steady(): monotonic clock or the realtime clock, depending on
> what is available on the platform (use monotonic in priority). may be
> adjusted by NTP or the system administrator, may go backward.
> 
> time.steady() is something like:
> 
> try:
>  return time.monotonic()
> except (NotImplementError, OSError):
>  return time.time()

Is the use of weak monotonic time so wide-spread in the stdlib that we 
need the 'steady()' function?  If it's just two modules then it's not 
worth adding it.

-
Yury
___
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] Rename time.steady(strict=True) to time.monotonic()?

[Victor Stinner]

>> time.steady() is something like:
>>
>> try:
>>  return time.monotonic()
>> except (NotImplementError, OSError):
>>  return time.time()
>
> Is the use of weak monotonic time so wide-spread in the stdlib that we
> need the 'steady()' function?  If it's just two modules then it's not
> worth adding it.

The Python standard library is not written to be used by Python
itself, but by others. The try/except is a common pattern when
applications use a monotonic clock. I suppose that quite all
applications use this try/except pattern.

I don't see what is the use case requiring a is truly monotonic clock.

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] Rename time.steady(strict=True) to time.monotonic()?

[Steven D'Aprano]

Victor Stinner wrote:
[...]

So we will have:

- time.time(): realtime, can be adjusted by the system administrator
(manually) or automatically by NTP
- time.clock(): monotonic clock on Windows, CPU time on UNIX
- time.monotonic(): monotonic clock, its speed may or may not be
adjusted by NTP but it only goes forward, may raise an OSError


This all sounds good to me. +1 up to this point.

Question: under what circumstances will monotonic() exist but raise OSError?



- time.steady(): monotonic clock or the realtime clock, depending on
what is available on the platform (use monotonic in priority). may be
adjusted by NTP or the system administrator, may go backward.


What makes this "steady", given that it can be adjusted and it can go 
backwards? Doesn't sound steady to me.


Is steady() merely a convenience function to avoid the user having to write 
something like this?


try:
mytimer = time.monotonic
except AttributeError:
mytimer = time.time


or inline:


try:
  return time.monotonic()
except (NotImplementError, OSError):
  return time.time()


Should that be (AttributeError, OSError) instead?



--
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] Rename time.steady(strict=True) to time.monotonic()?

[Steven D'Aprano]

Victor Stinner wrote:


- time.clock(): monotonic clock on Windows, CPU time on UNIX


Actually, I think that is not correct. Or at least *was* not correct in 2006.

http://bytes.com/topic/python/answers/527849-time-clock-going-backwards




--
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] Rename time.steady(strict=True) to time.monotonic()?

[Victor Stinner]

> Question: under what circumstances will monotonic() exist but raise OSError?

On Windows, OSError is raised if QueryPerformanceFrequency fails.
Extract of Microsoft doc:

"If the function fails, the return value is zero. To get extended
error information, call GetLastError. For example, if the installed
hardware does not support a high-resolution performance counter, the
function fails."

On UNIX, OSError is raised if clock_gettime(CLOCK_MONOTONIC) fails.
Extract of clock_gettime() doc:

"ERRORS
   EINVAL The clk_id specified is not supported on this system."

It may occur if the libc exposes CLOCK_MONOTONIC but the kernel
doesn't support it. I don't know if it can occur in practice.

>> - time.steady(): monotonic clock or the realtime clock, depending on
>> what is available on the platform (use monotonic in priority). may be
>> adjusted by NTP or the system administrator, may go backward.
>
> What makes this "steady", given that it can be adjusted and it can go
> backwards? Doesn't sound steady to me.

In practice, it will be monotonic in most cases. "steady" name is used
instead of "monotonic" because it may not be monotonic is other cases.

> Is steady() merely a convenience function to avoid the user having
> to write something like this?

steady() remembers if the last call to monotonic failed or not. The
real implementation is closer to something like:

def steady():
  if not steady.has_monotonic:
return time.time()
  try:
return time.monotonic()
  except (AttributeError, OSError):
steady.has_monotonic = False
return time.time()
steady.has_monotonic = True

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] Rename time.steady(strict=True) to time.monotonic()?

[Victor Stinner]

>> - time.clock(): monotonic clock on Windows, CPU time on UNIX
>
>
> Actually, I think that is not correct. Or at least *was* not correct in
> 2006.
>
> http://bytes.com/topic/python/answers/527849-time-clock-going-backwards

Oh, I was not aware of this issue. Do you suggest to not use
QueryPerformanceCounter() on Windows to implement a monotonic clock?

The python-monotonic-time project uses GetTickCount64(), or
GetTickCount(), on Windows. GetTickCount64() was added to Windows
Seven / Server 2008. GetTickCount() overflows after 49 days.
QueryPerformanceCounter() has a better resolution than
GetTickCount[64]().

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] Playing with a new theme for the docs

[Greg Ewing]

Glyph Lefkowitz wrote:

"do I have to resize my browser every time I visit a new site to get a 
decent width for reading".


If all sites left the width to the browser, then I would
be able to make my browser window a width that is comfortable
for me with my chosen font size and leave it that way.
The only time a site forces me to resize my window is when
it thinks it has a better idea than me how wide the text
should be.

I prefer sites that don't try to control the layout of
everything. When using a site that leaves most of it up
to my browser, I never find myself wishing that the designer
had specified something more tightly.

However, I do often find myself wishing that the designer
*hadn't* overridden the width, or the font size, or the
text colour, or decided that I shouldn't be allowed to know
whether I've visited links before, etc. etc.

A web page is not a printed page. It is not rendered at a
fixed size and viewed in its entirety at once. It needs to
be flexible, able to be rendered in whatever size space
is available or the user wants to devote to it. Browsers
are very good at doing that -- unless the designer defeats
them by fixing something that is better left flexible.

--
Greg
___
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] Rename time.steady(strict=True) to time.monotonic()?

[Steven D'Aprano]

Victor Stinner wrote:


Is steady() merely a convenience function to avoid the user having
to write something like this?


steady() remembers if the last call to monotonic failed or not. The
real implementation is closer to something like:

def steady():
  if not steady.has_monotonic:
return time.time()
  try:
return time.monotonic()
  except (AttributeError, OSError):
steady.has_monotonic = False
return time.time()
steady.has_monotonic = True


Does this mean that there are circumstances where monotonic will work for a 
while, but then fail?


Otherwise, we would only need to check monotonic once, when the time module is 
first loaded, rather than every time it is called. Instead of the above:


# global to the time module
try:
monotonic()
except (NameError, OSError):
steady = time
else:
steady = monotonic



Are there failure modes where monotonic can recover? That is, it works for a 
while, then raises OSError, then works again on the next call.


If so, steady will stop using monotonic and never try it again. Is that 
deliberate?




--
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] Rename time.steady(strict=True) to time.monotonic()?

[Janzert]

On 3/23/2012 7:25 PM, Victor Stinner wrote:
[snip]

- time.monotonic(): monotonic clock, its speed may or may not be
adjusted by NTP but it only goes forward, may raise an OSError
- time.steady(): monotonic clock or the realtime clock, depending on
what is available on the platform (use monotonic in priority). may be
adjusted by NTP or the system administrator, may go backward.

time.steady() is something like:

try:
   return time.monotonic()
except (NotImplementError, OSError):
   return time.time()



I am surprised that a clock with the name time.steady() has a looser 
definition than one called time.monotonic(). To my mind a steady clock 
is by definition monotonic but a monotonic one may or may not be steady.


Janzert

___
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] Rename time.steady(strict=True) to time.monotonic()?

[Steven D'Aprano]

Victor Stinner wrote:

- time.clock(): monotonic clock on Windows, CPU time on UNIX


Actually, I think that is not correct. Or at least *was* not correct in
2006.

http://bytes.com/topic/python/answers/527849-time-clock-going-backwards


Oh, I was not aware of this issue. Do you suggest to not use
QueryPerformanceCounter() on Windows to implement a monotonic clock?


I do not have an opinion on the best way to implement monotonic to guarantee 
that it actually is monotonic.



--
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

[Python-Dev] Rename time.steady(strict=True) to time.monotonic()?

[Jim J. Jewett]

In http://mail.python.org/pipermail/python-dev/2012-March/118024.html
Steven D'Aprano wrote:

> What makes this "steady", given that it can be adjusted
> and it can go backwards?

It is best-effort for steady, but putting "best" in the name would
be an attractive nuisance.

> Is steady() merely a convenience function to avoid the user
> having to write something like this?

>  try:
> mytimer = time.monotonic
>  except AttributeError:
> mytimer = time.time

That would still be worth doing.  But I think the main point is
that the clock *should* be monotonic, and *should* be as precise
as possible.

Given that it returns seconds elapsed (since an undefined start),
perhaps it should be

time.seconds()

or even

time.counter()

-jJ

-- 

If there are still threading problems with my replies, please 
email me with details, so that I can try to resolve them.  -jJ

___
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 (Rationale part 1: Regularizing the layout)

[PJ Eby]

On Mar 23, 2012 4:19 PM, "VanL"  wrote:
>
> Three notes. FIrst, distutils.cfg doesn't always work because it is
centered around the idea of set paths that are the same each time - which
doesn't always work with virtualenvs.

And the virtualenv doesn't contain its own copy of distutils.cfg?

> Second, most installer tools don't follow distutils.cfg. Even if that
helps for python setup.py install, the other tools are still broken when
you want to specify a layout.

So, we should change Python to fix the broken tools that don't follow
documented standards for configuring installation locations?

If the tools are that broken, aren't they going to break even *harder* when
you change the paths for Windows?

> And fourth, (because nobody expects the spanish inquisition), isn't the
gratuitous difference a (small but) obvious wart?

It's hardly the only wart we keep around for backwards compatibility.  If
it's going to change, it needs a proper transition period at the least.
___
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 (Rationale part 1: Regularizing the layout)

[PJ Eby]

On Mar 23, 2012 3:53 PM, "Carl Meyer"  wrote:
>
> Hi PJ,
>
> On 03/23/2012 12:35 PM, PJ Eby wrote:
> > AFAICT, virtualenvs are overkill for most development anyway.  If you're
> > not using distutils except to install dependencies, then configure
> > distutils to install scripts and libraries to the same directory, and
> > then do all your development in that directory.  Presto!  You now have a
> > cross-platform "virtualenv".  Want the scripts on your path?  Add that
> > directory to your path... or if on Windows, don't bother, since the
> > current directory is usually on the path.   (In fact, if you're only
> > using easy_install to install your dependencies, you don't even need to
> > edit the distutils configuration, just use "-md targetdir".)
>
> Creating and using a virtualenv is, in practice, _easier_ than any of
> those alternatives,

Really?  As I said, I've never seen the need to try, since just installing
stuff to a directory on PYTHONPATH seems quite easy enough for me.

> that the "isolation from system site-packages" feature is quite popular
> (the outpouring of gratitude when virtualenv went isolated-by-default a
> few months ago was astonishing), and AFAIK none of your alternative
> proposals support that at all.

What is this isolation for, exactly?  If you don't want site-packages on
your path, why not use python -S?

(Sure, nobody knows about these things, but surely that's a documentation
problem, not a tooling problem.)

Don't get me wrong, I don't have any deep objection to virtualenvs, I've
just never seen the *point* (outside of the scenarios I mentioned), and
thus don't see what great advantage will be had by rearranging layouts to
make them shareable across platforms, when "throw stuff in a directory"
seems perfectly serviceable for that use case already.  Tools that *don't*
support "just throw it in a directory" as a deployment option are IMO
unpythonic -- practicality beats purity, after all.  ;-)
___
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] Playing with a new theme for the docs

[PJ Eby]

On Mar 23, 2012 9:16 PM, "Greg Ewing"  wrote:
>
> Glyph Lefkowitz wrote:
>
>> "do I have to resize my browser every time I visit a new site to get a
decent width for reading".
>
>
> If all sites left the width to the browser, then I would
> be able to make my browser window a width that is comfortable
> for me with my chosen font size and leave it that way.
> The only time a site forces me to resize my window is when
> it thinks it has a better idea than me how wide the text
> should be.

Weird - I have the exact *opposite* problem, where I have to resize my
window because somebody *didn't* set their text max-width sanely (to a
reasonable value based on ems instead of pixels), and I have nearly 1920
pixels of raw text spanning my screen.  Bloody impossible to read that way.

But I guess this is going to turn into one of those vi vs. emacs holy war
things...

(Personally, I prefer jEdit, or nano if absolutely forced to edit in a
terminal. Heretical, I know.  To the comfy chair with me!)
___
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 (Rationale part 1: Regularizing the layout)

[VanL]

On Mar 23, 2012 10:21 PM, "PJ Eby"  wrote:
>
>
> On Mar 23, 2012 4:19 PM, "VanL"  wrote:
> >
> > Three notes. FIrst, distutils.cfg doesn't always work because it is
centered around the idea of set paths that are the same each time - which
doesn't always work with virtualenvs.
>
> And the virtualenv doesn't contain its own copy of distutils.cfg?

It can, but a new one. Virtualenvs don't carry over the distutils.cfg from
the main installation. Thus, using distutils.cfg in the virtualenv would
require editing the .cfg for every new virtualenv-and it still wouldn't
work all the time for the other reasons discussed.

> > Second, most installer tools don't follow distutils.cfg. Even if that
helps for python setup.py install, the other tools are still broken when
you want to specify a layout.
>
> So, we should change Python to fix the broken tools that don't follow
documented standards for configuring installation locations?

If the documented functions don't work for the use cases, there is nothing
else. Again, see the comments in PyPM.

>
> If the tools are that broken, aren't they going to break even *harder*
when you change the paths for Windows?

If people substitute on hard-coded value for another, does cross platform
consistency help? And ifthat focuses attention on the new packaging APIs
and the correct way to do it, isn't that even better?

> > And fourth, (because nobody expects the spanish inquisition), isn't the
gratuitous difference a (small but) obvious wart?
>
> It's hardly the only wart we keep around for backwards compatibility.  If
it's going to change, it needs a proper transition period at the least.

Already proposed, making a transition over three releases with it starting
as an off by default option in 3.3.
___
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] Rename time.steady(strict=True) to time.monotonic()?

[Brian Curtin]

On Fri, Mar 23, 2012 at 18:38, Yury Selivanov  wrote:
> On 2012-03-23, at 7:28 PM, Brian Curtin wrote:
>> This seems like it should have been a PEP, or maybe should become a PEP.
>
> Why?  AFAIK Victor just proposes to add two new functions: monotonic() and
> steady().

We just previously had "Drop time.monotonic() function, rename
time.wallclock() to time.steady()" checked in a few weeks ago, and now
we're renaming a variation on time.steady to time.monotonic? What's
the next move?

I'm not paying close attention here but there's a lot of movement
going on. Figuring out the API before we get too deep is probably a
good idea.
___
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] Playing with a new theme for the docs

[Greg Ewing]

PJ Eby wrote:

Weird - I have the exact *opposite* problem, where I have to resize my 
window because somebody *didn't* set their text max-width sanely (to a 
reasonable value based on ems instead of pixels), and I have nearly 1920 
pixels of raw text spanning my screen.


If you don't want 1920-pixel-wide text, why make your
browser window that large?

--
Greg
___
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] Rename time.steady(strict=True) to time.monotonic()?

[Jeffrey Yasskin]

On Fri, Mar 23, 2012 at 4:25 PM, Victor Stinner
 wrote:
> Hi,
>
> time.steady(strict=True) looks to be confusing for most people, some
> of them don't understand the purpose of the flag and others don't like
> a flag changing the behaviour of the function.
>
> I propose to replace time.steady(strict=True) by time.monotonic().
> That would avoid the need of an ugly NotImplementedError: if the OS
> has no monotonic clock, time.monotonic() will just not exist.
>
> So we will have:
>
> - time.time(): realtime, can be adjusted by the system administrator
> (manually) or automatically by NTP
> - time.clock(): monotonic clock on Windows, CPU time on UNIX
> - time.monotonic(): monotonic clock, its speed may or may not be
> adjusted by NTP but it only goes forward, may raise an OSError
> - time.steady(): monotonic clock or the realtime clock, depending on
> what is available on the platform (use monotonic in priority). may be
> adjusted by NTP or the system administrator, may go backward.

Please don't use the word "steady" for something different from what
C++ means by it. C++'s term means "may not be adjusted at all, even by
NTP; proceeds at as close to the rate of real time as the system can
manage" (paraphrased). If the consensus in the Python community is
that a C++-style "steady" clock is unnecessary, then feel free not to
define it. If the consensus is that "monotonic" already means
everything C++ means by "steady", that's fine with me too. I mentioned
it because I thought it might be worth looking at what other languages
were doing in this space, not because I thought it was a nice word
that you should attach your own definitions to.

Jeffrey
___
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