Re: [Python-Dev] SocketServer issues

[Antoine Pitrou]

On Wed, 14 Mar 2012 04:26:16 +
Kristján Valur Jónsson  wrote:
> Hi there.
> I want to mention some issues I've had with the socketserver module, and 
> discuss if there's a way to make it nicer.
> So, for a long time we were able to create magic stackless mixin classes for
> it, like ThreadingMixIn, and assuming we had the appropriate socket
> replacement library, be able to use it nicely using tasklets.

I don't really think the ability to "create magic stackless mixin
classes" should be a driving principle for the stdlib.
I would suggest using a proper non-blocking framework such as Twisted.

> So, my first question is:  Why not simply rely on the already built-in timeout
> support in the socket module?

In case you didn't notice, the built-in timeout support *also* uses
select().

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] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

[Antoine Pitrou]

On Wed, 14 Mar 2012 10:55:35 +1100
Steven D'Aprano  wrote:
> 
> What problem are we actually trying to solve here? Do we think that there are 
> users who really have no clue where to find 3rd party software AND don't know 
> how to use Google, BUT read the Python docs? I find it difficult to believe 
> that there are people who both read the docs and are so clueless that they 
> need to be told that there are alternatives available and which they should 
> be 
> using.

I find it quite easy to believe myself. Many people will learn some
Python by reading the docs, without knowing the rest of the ecosystem.

So, yes, publicizing the widely accepted alternatives (such as Twisted
for asyncore) *is* helpful.

(that doesn't mean any shiny new gadget must be advocated, though;
third-party libraries should be mature enough before we start
mentioning them)

> Should we recommend wxPython over Pyjamas or PyGUI or PyGtk? On what basis?

You don't have to recommend anything. Just mention them.
You know what, we *already* do that job:
http://docs.python.org/dev/library/othergui.html#other-gui-packages

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?

[Antoine Pitrou]

On Wed, 14 Mar 2012 02:03:42 +0100
Victor Stinner  wrote:
> 
> We may merge both functions with a flag to be able to disable the
> fallback. Example:
> 
>  - time.realtime(): best-effort monotonic, with a fallback
>  - time.realtime(monotonic=True): monotonic, may raise OSError or
> NotImplementedError

That's a rather awful name.  time.time() is *the* real time.

time.monotonic(fallback=False) would be a better API.

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?

[Stefan Krah]

Antoine Pitrou  wrote:
> time.monotonic(fallback=False) would be a better API.

+1


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] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

[Antoine Pitrou]

On Wed, 14 Mar 2012 11:31:34 +0800
Matt Joiner  wrote:
> 
> Rather than indicating apathy on the party of third party developers, this
> might be a sign that core Python is unapproachable or not worth the effort.
> 
> For instance I have several one line patches languishing, I can't imagine
> how disappointing it would be to have significantly larger patches ignored,
> but it happens.

Can you give a pointer to these one-liners?
Once a patch gets a month old or older, it tends to disappear from
everyone's radar unless you somehow "ping" on the tracker, or post a
message to the mailing-list.

(of course, you shouldn't spam the list with open issues either)

Thanks

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] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

[Stefan Krah]

Antoine Pitrou  wrote:
> > For instance I have several one line patches languishing, I can't imagine
> > how disappointing it would be to have significantly larger patches ignored,
> > but it happens.
> 
> Can you give a pointer to these one-liners?

Almost a one-liner, but vast knowledge required (how do you prove that
using (freefunc) is safe if it's the first usage in the tree?).

http://bugs.python.org/file21610/atexit-leak.patch


I think there are many issues like that one where the implications
of a short patch can only be assessed by small number of committers.


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] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

[Antoine Pitrou]

On Wed, 14 Mar 2012 10:58:10 +0100
Stefan Krah  wrote:
> Antoine Pitrou  wrote:
> > > For instance I have several one line patches languishing, I can't imagine
> > > how disappointing it would be to have significantly larger patches 
> > > ignored,
> > > but it happens.
> > 
> > Can you give a pointer to these one-liners?
> 
> Almost a one-liner, but vast knowledge required (how do you prove that
> using (freefunc) is safe if it's the first usage in the tree?).
> 
> http://bugs.python.org/file21610/atexit-leak.patch

Well, can you please post a URL to the issue itself?

Thanks

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] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

[Mark Shannon]

Stefan Krah wrote:

Antoine Pitrou  wrote:

For instance I have several one line patches languishing, I can't imagine
how disappointing it would be to have significantly larger patches ignored,
but it happens.

Can you give a pointer to these one-liners?


Almost a one-liner, but vast knowledge required (how do you prove that
using (freefunc) is safe if it's the first usage in the tree?).

http://bugs.python.org/file21610/atexit-leak.patch



But how do you find issues?

I want to do some reviews, but I don't want to wade through issues on
components I know little or nothing about in order to find the ones I 
can review.


There does not seem to be a way to filter search results in the tracker.

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] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

[Stefan Krah]

Antoine Pitrou  wrote:
> > Almost a one-liner, but vast knowledge required (how do you prove that
> > using (freefunc) is safe if it's the first usage in the tree?).
> > 
> > http://bugs.python.org/file21610/atexit-leak.patch
> 
> Well, can you please post a URL to the issue itself?

That sounds like an excellent plan. :)


http://bugs.python.org/issue11826


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

[Facundo Batista]

Hello!

In the "Maximum Line Length" section of PEP 8 it says:

"The preferred place to break around a binary operator is *after*
the operator, not before it."

And after that is an example (trimmed here):

if (width == 0 and height == 0 and
color == 'red' and emphasis == 'strong' or
highlight > 100):
raise ValueError("sorry, you lose")

In the example the line is broken after the 'and' or 'or' *keywords*,
not after the '==' *operator* (which is the nice way of doing it).

Maybe the sentence above is misleading?

Thanks!

-- 
.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
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 8 misnaming

[Geoffrey Spear]

On Wed, Mar 14, 2012 at 7:21 AM, Facundo Batista
 wrote:
> Hello!
>
> In the "Maximum Line Length" section of PEP 8 it says:
>
>    "The preferred place to break around a binary operator is *after*
> the operator, not before it."
>
> And after that is an example (trimmed here):
>
>            if (width == 0 and height == 0 and
>                color == 'red' and emphasis == 'strong' or
>                highlight > 100):
>                raise ValueError("sorry, you lose")
>
> In the example the line is broken after the 'and' or 'or' *keywords*,
> not after the '==' *operator* (which is the nice way of doing it).
>
> Maybe the sentence above is misleading?

'and' and 'or' are both binary logical operators. The fact that they
are keywords is irrelevant; the sentence isn't misleading.
___
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/14 Antoine Pitrou :
> On Wed, 14 Mar 2012 02:03:42 +0100
> Victor Stinner  wrote:
>>
>> We may merge both functions with a flag to be able to disable the
>> fallback. Example:
>>
>>  - time.realtime(): best-effort monotonic, with a fallback
>>  - time.realtime(monotonic=True): monotonic, may raise OSError or
>> NotImplementedError
>
> That's a rather awful name.  time.time() is *the* real time.
>
> time.monotonic(fallback=False) would be a better API.

I would prefer to enable the fallback by default with a warning in the
doc, just because it is more convinient and it is what user want even
if they don't know that they need a fallback :-)

Enabling the fallback by default allow to write such simple code:

try:
  from time import monotonic as get_time
except ImportError:
  # Python < 3.3
  from time import time as get_time

Use time.monotonic(strict=True) if you need a truly monotonic clock.

monotonic() may not be the best name in this case. Jeffrey Yasskin
proposed time.steady_clock(), so time.steady_clock(monotonic=False)?

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?

[Antoine Pitrou]

On Wed, 14 Mar 2012 13:27:19 +0100
Victor Stinner  wrote:
> 
> monotonic() may not be the best name in this case. Jeffrey Yasskin
> proposed time.steady_clock(), so time.steady_clock(monotonic=False)?

I don't know what "steady" is supposed to mean here, so perhaps the
best solution is to improve the doc?

Also, "monotonic=False" implies that it won't be monotonic, which is
false.

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] PEP 8 misnaming

[Ben Finney]

Facundo Batista  writes:

> if (width == 0 and height == 0 and
> color == 'red' and emphasis == 'strong' or
> highlight > 100):
> raise ValueError("sorry, you lose")
>
> In the example the line is broken after the 'and' or 'or' *keywords*,

‘and’ and ‘or’ are binary operators (that also happen to be keywords).
The description is accurate and IMO not misleading.

> not after the '==' *operator* (which is the nice way of doing it).

−1. The lower-priority binding operator is the better place to break the
line. The binary logical operators bind at lower priority than the
equality operator.

-- 
 \   “If you do not trust the source do not use this program.” |
  `\—Microsoft Vista security dialogue |
_o__)  |
Ben Finney

___
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] 2012 Language Summit Report

[Brian Curtin]

As with last year, I've put together a summary of the Python Language
Summit which took place last week at PyCon 2012. This was compiled
from my notes as well as those of Eric Snow and Senthil Kumaran, and I
think we got decent coverage of what was said throughout the day.

http://blog.python.org/2012/03/2012-language-summit-report.html

If you have questions or comments about discussions which occurred
there, please create a new thread for your topic.

Feel free to contact me directly if I've left anything out or
misprinted anything.
___
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] Python install layout and the PATH on win32

[Jim J. Jewett]

In 
view-source:http://mail.python.org/pipermail/python-dev/2012-March/117586.html
van.lindberg at gmail.com posted:

>>> 1) The layout for the python root directory for all platforms should be
>>> as follows:
 
>>> stdlib = {base/userbase}/lib/python{py_version_short}
>>> platstdlib = {base/userbase}/lib/python{py_version_short}
>>> purelib = {base/userbase}/lib/python{py_version_short}/site-packages
>>> platlib = {base/userbase}/lib/python{py_version_short}/site-packages
>>> include = {base/userbase}/include/python{py_version_short}
>>> scripts = {base/userbase}/bin
>>> data = {base/userbase}

Why?

Pure python vs compiled C doesn't need to be separated at the directory
level, except for cleanliness.

Some (generally unix) systems prefer to split the libraries into several
additional pieces depending on CPU architecture.

The structure listed above doesn't have a location for docs.

Some packages (such as tcl) may be better off in their own area.

What is "data"?  Is this an extra split compared to today, or does it
refer to things like LICENSE.txt, README.txt, and NEWS.txt?

And even once I figure out where files have moved, and assume that
the split is perfect -- what does this buy me over the current
situation?  I was under the impression that programs like distutils
already handled finding the appropriate directories for a program;
if you're rewriting that logic, you're just asking for bugs on a
strange platform that you don't use.

If you're looking for things interactively, then platform conventions
are probably more important than consistency across platforms.  If you
disagree, you are welcome to reorganize your personal linux installation
so that it matches windows, and see whether it causes you any problems.

> ... We *already* have this. The only difference in this proposal is
> that we go from py_version_nodot to py_version_short, i.e. from

> c:\python33\lib\python33 

> to

> c:\python33\lib\python3.3

I have not seen that redundancy before on windows.

I'm pretty sure that it is a relic of your Linux provider wanting
to support multiple python versions using shared filesystems.  The
Windows standard is to use a local disk, and to bundle it all up
into its own directory, similar to the way that java apps sometimes
ship with their own JVM.

Also note that using the dot in a directory name is incautious.
I haven't personally had trouble in several years, but doing so is
odd enough that some should be expected.  Python already causes
some grief by not installing in "Program Files", but that is at
least justified by the "spaces in filenames" problem; what is the
advantange of 3.3?


I'm using windows, and I just followed the defaults at installation.
It is possible that the installer continued to do something based
on an earlier installation, but I don't think this machine has ever
had a customized installation of any python version.

C:\python32\*
Everything is under here; I assume {base/userbase} would be
set to C:\python32

As is customary for windows, the base directory contains the
license/readme/news and all executables that the user is
expected to use directly.  (python.exe, pythonw.exe.  It also
contains w9xpopen.exe that users do not use, but that too is
fairly common.)

There is no data directory.

Subdirectories are:

C:\python32\DLLs
In additional to regular DLL files, it contains .pyd files
and icons.  It looks like modules from the stdlib that happen
to be written in C.  Most users will never bother to look here.

C:\python32\Doc
A .chm file; full html would be fine too, but removing it
would be a bad idea.

C:\python32\include
These are the header files, though most users will never have
any use for them, as there isn't generally a compiler.

C:\python32\Lib
The standard library -- or at least the portion implemented
in python.

Note that site-packages is a subdirectory here.  It doesn't
happen to have an __init__.py, but to an ordinary user it
looks just like any other stdlib package, such as xml or
multiprocessing.

I personally happen to keep things in subdirectories of
site-packages, but I can't say what is standard.

Moving site-packages out of the Lib directory might make
sense, but probably isn't worth the backward compatibility hit.

C:\python32\libs
.lib files.  I'm not entirely sure what these (as opposed to
the DLLs) are for; lib files aren't that common on windows.
My machine does not appear to have any that aren't associated
with cross-platform tools or unix emulation.

C:\python32\tcl
Note that this is in addition to associated files under DLLs
and libs.  I would prefer to see them in one place, but
moving it in with non-tcl stuff would not be an improvement.
Most users will never look (or care); those that do usually
appreciate knowing that, for example, the dde subdirectory
is for tcl.

C:\python32\Tools
T

Re: [Python-Dev] Python install layout and the PATH on win32

[VanL]

On 3/13/2012 9:58 PM, Terry Reedy wrote:


Given that we already repeat it, isn't it better to be consistent?


But there is no repetition currently on Windows installations.
I though you were just proposing to switch lib (lower-cased, and scripts
renamed as bin, and pythonxx). So I do not think I yet understand what
the proposal is and how it would be different from what I have now.


Aaah, I was looking at my local installations, which happen to be 
"nt-user". Looking at the system installation ("nt") I see that there is 
no repetition.


I am fine with keeping the distinction between base installs (no 
py_version) and user installs (including a py_version). I would just 
suggest that when you have a py_version, it be the same py_version (not 
dots sometimes, nodot other times).


It also begs the question as to whether the py_version is *ever* needed.

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] SocketServer issues

[Guido van Rossum]

Hopefully it doesn't use select if no timeout is set...

--Guido van Rossum (sent from Android phone)
On Mar 14, 2012 2:08 AM, "Antoine Pitrou"  wrote:

> On Wed, 14 Mar 2012 04:26:16 +
> Kristján Valur Jónsson  wrote:
> > Hi there.
> > I want to mention some issues I've had with the socketserver module, and
> discuss if there's a way to make it nicer.
> > So, for a long time we were able to create magic stackless mixin classes
> for
> > it, like ThreadingMixIn, and assuming we had the appropriate socket
> > replacement library, be able to use it nicely using tasklets.
>
> I don't really think the ability to "create magic stackless mixin
> classes" should be a driving principle for the stdlib.
> I would suggest using a proper non-blocking framework such as Twisted.
>
> > So, my first question is:  Why not simply rely on the already built-in
> timeout
> > support in the socket module?
>
> In case you didn't notice, the built-in timeout support *also* uses
> select().
>
> 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/guido%40python.org
>
___
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

[Scott Dial]

On 3/13/2012 9:57 PM, VanL wrote:
> On Mar 13, 2012, at 8:37 PM, "Martin v. Löwis"  wrote:
>> The installation will end up in
>>
>> c:\python33\lib\python3.3
>>
>> which has the software name and version twice in the path.
>>
>> Do we *really* need this?
> 
> We *already* have this. The only difference in this proposal is that we go 
> from py_version_nodot to py_version_short, i.e. from
> 
> c:\python33\lib\python33 
> 
> to
> 
> c:\python33\lib\python3.3
> 
> Given that we already repeat it, isn't it better to be consistent?
> 

Is it?

I think you are confusing two different configuration sections in
sysconfig.cfg:

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

-- 
Scott Dial
sc...@scottdial.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 install layout and the PATH on win32

[VanL]

On 3/14/2012 9:53 AM, Jim J. Jewett wrote:

In 
view-source:http://mail.python.org/pipermail/python-dev/2012-March/117586.html
van.lindberg at gmail.com posted:


1) The layout for the python root directory for all platforms should be
as follows:



stdlib = {base/userbase}/lib/python{py_version_short}
platstdlib = {base/userbase}/lib/python{py_version_short}
purelib = {base/userbase}/lib/python{py_version_short}/site-packages
platlib = {base/userbase}/lib/python{py_version_short}/site-packages
include = {base/userbase}/include/python{py_version_short}
scripts = {base/userbase}/bin
data = {base/userbase}


Why?

Pure python vs compiled C doesn't need to be separated at the directory
level, except for cleanliness.



I am deliberately being cautious here. I actually agree with you. I am 
only suggesting we maintain all of these different distinctions because 
that is what we have already.


You can see what we have currently at 
http://hg.python.org/distutils2/file/2cec52b682a9/distutils2/_backport/sysconfig.cfg


I am *not* suggesting that docs, etc change at all - that is included in 
a different part of the configuration and is not modified by what I 
propose here (lines 1-26).


As noted earlier in the thread, I also change my proposal to maintain 
the existing differences between system installs and user installs.


Thus, the only place I am proposing changing are the values for the keys 
listed above. Specifically, this (lines 57-65 in the file above):


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

Would become this:

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

and this (lines 86-93):

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

would become this:

[nt_user]
stdlib = {userbase}/python{py_version_short}
platstdlib = {userbase}/python{py_version_short}
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}/bin
data = {userbase}



... if you're rewriting that logic, you're just asking for bugs on a
strange platform that you don't use.


I am not rewriting the logic - the logic is driven by these 
configuration values. And this is a platform I use, and that is why this 
drives me crazy!




Subdirectories are:


You forgot one:

C:\python32\Scripts
Would change to C:\python32\bin. The python binary and scripts meant to 
be run direction (easy_install, etc) would all go in this directory.



C:\python32\DLLs

Would not change.


C:\python32\Doc

Would not change.


C:\python32\include

Would be specified as lower case only - but otherwise would not change.



C:\python32\Lib

Would be specified as lower case only - but otherwise would not change.


C:\python32\libs

Would not change.


C:\python32\tcl

Would not change.


C:\python32\Tools
This proposal does not change this, although I do think that this could 
be eliminated or made into "examples".


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

[VanL]

On 3/14/2012 10:09 AM, Scott Dial wrote:

I think you are confusing two different configuration sections in
sysconfig.cfg:

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



I was lumping them together, yes, but now note that I modify the 
proposal to maintain this distinction. These would 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}

[nt_user]
stdlib = {userbase}/python{py_version_short}
platstdlib = {userbase}/python{py_version_short}
purelib = {userbase}/python{py_version_short}/site-packages
platlib = {userbase}/python{py_version_short}/site-packages
include = {userbase}/python{py_version_short}/include
scripts = {userbase}/bin
data = {userbase}


___
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

[Terry Reedy]

On 3/14/2012 11:22 AM, VanL wrote:

On 3/13/2012 9:58 PM, Terry Reedy wrote:


Given that we already repeat it, isn't it better to be consistent?


But there is no repetition currently on Windows installations.
I though you were just proposing to switch lib (lower-cased, and scripts
renamed as bin, and pythonxx). So I do not think I yet understand what
the proposal is and how it would be different from what I have now.


Aaah, I was looking at my local installations, which happen to be
"nt-user". Looking at the system installation ("nt") I see that there is
no repetition.


Are you talking about 'install for all users' versus 'install for this 
user only'? I have always done the former as I see no point to the 
latter on my machine, even if another family member has an account.



I am fine with keeping the distinction between

> base installs (no py_version)

I have no idea what this means. As far as I can remember, each 
installation of Python x.y (back to 1.3 for me, on DOS) has gone into a 
pythonxy (no dot) directory, with subdirectories much as Jim J. described.



and user installs (including a py_version). I would just
suggest that when you have a py_version, it be the same py_version (not
dots sometimes, nodot other times).

It also begs the question as to whether the py_version is *ever* needed.


Whenever multiple versions are installed, of course a version marker is 
needed. Even if not, it is helpful to be able to see what version is 
installed. But I probably am not understanding what you mean.


--
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] 2012 Language Summit Report

[Terry Reedy]

On 3/14/2012 10:12 AM, Brian Curtin wrote:

As with last year, I've put together a summary of the Python Language
Summit which took place last week at PyCon 2012. This was compiled
from my notes as well as those of Eric Snow and Senthil Kumaran, and I
think we got decent coverage of what was said throughout the day.

http://blog.python.org/2012/03/2012-language-summit-report.html


Nicely done. Thank you.

--
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] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

[R. David Murray]

On Wed, 14 Mar 2012 10:05:11 -, Mark Shannon  wrote:
> But how do you find issues?
> 
> I want to do some reviews, but I don't want to wade through issues on
> components I know little or nothing about in order to find the ones I 
> can review.
> 
> There does not seem to be a way to filter search results in the tracker.

Is the advanced search ('search' link on left hand side) missing
some filtering capabilities?

--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python install layout and the PATH on win32

[VanL]

On 3/14/2012 1:32 AM, Mark Hammond wrote:

As per comments later in the thread, I'm -1 on including
"python{py_version_short}" in the lib directories for a number of
reasons; one further reason not outlined is that it would potentially
make running Python directly from a built tree difficult. For the same
reason, I'm also -1 on having that in the include dir.


A built tree would look the same as always - the directories would only 
be moved (if at all) during installation. Thus, you will still be able 
to run python directly from a built installation.


Also note that the py_version_short will not be in platform installs.



scripts = {base/userbase}/bin


We should note that this may cause pain for a number of projects - I've
seen quite a few projects that already assume "Scripts" on Windows - eg,
virtualenv and setuptools IIRC


If you look at these projects, though, they *special case* Windows to 
account for the different layout. Removing this difference will allow 
these projects to remove their special-casing code.




- and also assume the executable is where
it currently lives - one example off the top of my head is the mozilla
"jetpack" project - see:

https://github.com/mozilla/addon-sdk/blob/master/bin/activate.bat#L117


This code actually reinforces my point:

First, this code would actually still work. The section ":FoundPython" 
sets the PATH to "%VIRTUAL_ENV%\bin;%PYTHONINSTALL%;%PATH%" (L80), which 
would still allow python.exe to be found and run.


Second, look at that line again. Mozilla actually has edited this code 
so that the jetpack uses a cross-platform "bin" convention, just as I am 
proposing.


Third, one element of this proposal is that there would be a key placed 
in the registry that points directly to the location of the python 
executable, making locating it trivial to locate programmatically on 
Windows.


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

[VanL]

On 3/14/2012 10:56 AM, Terry Reedy wrote:

Are you talking about 'install for all users' versus 'install for this
user only'? I have always done the former as I see no point to the
latter on my machine, even if another family member has an account.


Yes, but some people are on corporate machines that only allow "install 
for this user" installations.




I am fine with keeping the distinction between

 > base installs (no py_version)

I have no idea what this means. As far as I can remember, each
installation of Python x.y (back to 1.3 for me, on DOS) has gone into a
pythonxy (no dot) directory, with subdirectories much as Jim J. described.


I am referring to the currently-existing install schemes 'nt' ('install 
for all users') and 'nt-user' ('install for this user only'). The 
*current* layouts are described at 
http://hg.python.org/distutils2/file/2cec52b682a9/distutils2/_backport/sysconfig.cfg:


L57-65:
[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}

L86-93:
[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}

I am proposing that these 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}

[nt_user]
stdlib = {userbase}/python{py_version_short}
platstdlib = {userbase}/python{py_version_short}
purelib = {userbase}/python{py_version_short}/site-packages
platlib = {userbase}/python{py_version_short}/site-packages
include = {userbase}/python{py_version_short}/include
scripts = {userbase}/bin
data = {userbase}

All the other diuectories that Jim talked about would not be affected by 
this proposal.


Does this make it clearer?

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

[Matt Joiner]

I have some observations regarding this:

Victor's existing time.monotonic and time.wallclock make use of
QueryPerformanceCounter, and CLOCK_MONOTONIC_RAW as possible. Both of
these are hardware-based counters, their monotonicity is just a
convenient property of the timer sources. Furthermore, time values can
actually vary depending on the processor the call is served on.
time.hardware()? time.monotonic_raw()?

There are bug reports on Linux that CLOCK_MONOTONIC isn't always
monotonic. This is why CLOCK_MONOTONIC_RAW was created. There's also
the issue of time leaps (forward), which also isn't a problem with the
latter form. time.monotonic(raw_only=False)?

The real value of "monotonic" timers is that they don't leap
backwards, and preferably don't leap forwards. Whether they are
absolute is of no consequence. I would suggest that the API reflect
this, and that more specific time values be obtained using the proper
raw syscall wrapper (like time.clock_gettime) if required.
time.relative(strict=False)?

The ultimate use of the function name being established is for use in
timeouts and relative timings.

Where an option is present, it disallows fallbacks like
CLOCK_MONOTONIC and other weaker forms:
 * time.hardware(fallback=True) -> reflects the source of the timing
impeccably. alerts users to possible affinity issues
 * time.monotonic_raw() -> a bit linux specific...
 * time.relative(strict=False) -> matches the use case. a warning
could be put regarding hardware timings
 * time.monotonic(raw_only=False) -> closest to the existing
implementation. the keyword name i think is better.
___
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] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

[julien tayon]

Hello,

2012/3/13 Guido van Rossum :
> On Mon, Mar 12, 2012 at 9:23 PM, Brian Curtin  wrote:
>> Downloads don't mean the code is good. Voting is gamed. I really don't
>> think there's a good automated solution to tell us what the
>> high-quality replacement projects are.
>
> Sure, these are imperfect metrics. But not having any metrics at all
> is flawed too. Despite the huge flamewar we had 1-2 years ago about
> PyPI comments, I think we should follow the lead of the many app
> stores that pop up on the web -- users will recognize the pattern and
> will tune their skepticism sensors as needed.
>

unittest and functional testing are obctive metrics.

It it passes a unittest, and it has the same API, therefore it is a
legitimate replacement for the stdlib. If a benchmark is also given
that can be considered **not biased** and faster it is pretty neat.
(but why not contribute to stdlib then?)

Functional testing is however a little more tricky, subjective and
interesting. Since stdlib replacements are mostl functionnaly
equivalent (like requests) of one or more stdlib module and that is
what people are searching for.
People willing to be considered compliant with some functionalities of
a stdlib would have to give example of porting from libA to libB plus
the given *functionnal tests*.

An interesting point may also be PEP compliance. (it is sometimes a
tedious tasks when playing with SA to know if a python package of a
DBDriver is DB-API 2.0 compliant).

This would make pypi even greater if package maintainers added these
metadata (implements, functions_like, pep_compliance) in their
setup.py given they comply with the logic. And it would pretty much
automate the search for alternative to stdlib.

The huge problem is how to trust that maintainers are self disciplined
enough, willing,  and have enough knowledge to tag their packages
properly, plus what is the extra strain on code and infrastructure to
automate this ?

Without these informations we may become like senior java developpers
whose greatests skills are not coding, but knowing in a wide
ecosystems of packages which one are
revelant/reliable/compatible/stable. (needle in a haystack)

Maybe the answer is not one of code but one of trend setting and Noise
Signal Ratio on python hubs. (http://www.pythonmeme.com/,
http://planet.python.org/, http://pypi.org (and still in a lesser way
of classification)).



Cheers,
-- 
Julien Tayon
___
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] SocketServer issues

[PJ Eby]

On Wed, Mar 14, 2012 at 5:02 AM, Antoine Pitrou  wrote:

> On Wed, 14 Mar 2012 04:26:16 +
> Kristján Valur Jónsson  wrote:
> > Hi there.
> > I want to mention some issues I've had with the socketserver module, and
> discuss if there's a way to make it nicer.
> > So, for a long time we were able to create magic stackless mixin classes
> for
> > it, like ThreadingMixIn, and assuming we had the appropriate socket
> > replacement library, be able to use it nicely using tasklets.
>
> I don't really think the ability to "create magic stackless mixin
> classes" should be a driving principle for the stdlib.
>

But not needlessly duplicating functionality already elsewhere in the
stdlib probably ought to be.  ;-)


> So, my first question is:  Why not simply rely on the already built-in
> timeout
> > support in the socket module?
>
> In case you didn't notice, the built-in timeout support *also* uses
> select().
>

That's not really the point; the frameworks that implement nonblocking I/O
by replacing the socket module (and Stackless is only one of many) won't be
using that code.  If SocketServer uses only the socket module's API, then
those frameworks will be told about the timeout via the socket API, and can
then implement it their own way.
___
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] [Issue1531415] Using PyErr_WarnEx on parsetok

[Michele Orrù]

As pointed by Sean Reifschneider in issue 1531415,  I'm writing this
mail mainly to ask for advices concerning python's makefile.

Currently, Parser/parsetok.c writes directly to stderr in case no more
memory is avaible. So, it would be nice™ to use, instead of a raw
printf, the functions provided by Python/_warnings.c (PyErr_NoMemory
and/or PyErr_WarnEx). This, right now, leads to a circular dependency,
as described here: http://bugs.python.org/msg154939 .

So far I've seen some functions present both in Python/ and pgenmain.c
: PyErr_Occurred(), Py_FatalError(const char *msg), Py_Exit(int).
This means a dirty alternative could be to implement another function
PyErr_WarnEx; but probably there is a better way to organize the
makefile, becouse currently I'm using the entire $(PYTHON_OBJS) (seems
needed by warnigs.o).

This is the first time I run into python c code, so please be patient :)
-- 
ù
___
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] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

[Matt Joiner]

> Can you give a pointer to these one-liners?
> Once a patch gets a month old or older, it tends to disappear from
> everyone's radar unless you somehow "ping" on the tracker, or post a
> message to the mailing-list.

All of these can be verified with a few minutes of checking the
described code paths.

http://bugs.python.org/issue13839
http://bugs.python.org/issue13872
http://bugs.python.org/issue12684
http://bugs.python.org/issue13694

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

[Guido van Rossum]

I have a totally different observation. Presumably the primary use
case for these timers is to measure real time intervals for the
purpose of profiling various operations. For this purpose we want them
to be as "steady" as possible: tick at a constant rate, don't jump
forward or backward. (And they shouldn't invoke the concept of "CPU"
time -- we already have time.clock() for that, besides it's often
wrong, e.g. you might be measuring some sort of I/O performance.) If
this means that a second as measured by time.time() is sometimes not
the same as a second measured by this timer (due to time.time()
occasionally jumping due to clock adjustments), that's fine with me.
If this means it's unreliable inside a VM, well, it seems that's a
property of the underlying OS timer, and there's not much we can do
about it except letting a knowledgeable user override the timer user.
As for names, I like Jeffrey's idea of having "steady" in the name.

--Guido

On Wed, Mar 14, 2012 at 9:11 AM, Matt Joiner  wrote:
> I have some observations regarding this:
>
> Victor's existing time.monotonic and time.wallclock make use of
> QueryPerformanceCounter, and CLOCK_MONOTONIC_RAW as possible. Both of
> these are hardware-based counters, their monotonicity is just a
> convenient property of the timer sources. Furthermore, time values can
> actually vary depending on the processor the call is served on.
> time.hardware()? time.monotonic_raw()?
>
> There are bug reports on Linux that CLOCK_MONOTONIC isn't always
> monotonic. This is why CLOCK_MONOTONIC_RAW was created. There's also
> the issue of time leaps (forward), which also isn't a problem with the
> latter form. time.monotonic(raw_only=False)?
>
> The real value of "monotonic" timers is that they don't leap
> backwards, and preferably don't leap forwards. Whether they are
> absolute is of no consequence. I would suggest that the API reflect
> this, and that more specific time values be obtained using the proper
> raw syscall wrapper (like time.clock_gettime) if required.
> time.relative(strict=False)?
>
> The ultimate use of the function name being established is for use in
> timeouts and relative timings.
>
> Where an option is present, it disallows fallbacks like
> CLOCK_MONOTONIC and other weaker forms:
>  * time.hardware(fallback=True) -> reflects the source of the timing
> impeccably. alerts users to possible affinity issues
>  * time.monotonic_raw() -> a bit linux specific...
>  * time.relative(strict=False) -> matches the use case. a warning
> could be put regarding hardware timings
>  * time.monotonic(raw_only=False) -> closest to the existing
> implementation. the keyword name i think is better.



-- 
--Guido van Rossum (python.org/~guido)
___
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] SocketServer issues

[Antoine Pitrou]

On Wed, 14 Mar 2012 08:27:08 -0700
Guido van Rossum  wrote:
> Hopefully it doesn't use select if no timeout is set...

No, it doesn't :-)

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] SocketServer issues

[Antoine Pitrou]

On Wed, 14 Mar 2012 12:17:06 -0400
PJ Eby  wrote:
> 
> > So, my first question is:  Why not simply rely on the already built-in
> > timeout
> > > support in the socket module?
> >
> > In case you didn't notice, the built-in timeout support *also* uses
> > select().
> >
> 
> That's not really the point; the frameworks that implement nonblocking I/O
> by replacing the socket module (and Stackless is only one of many) won't be
> using that code.

Then they should also replace the select module.
Again, I don't think SocketServer (or any other stdlib module) should
be designed in this regard.

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?

[Kristján Valur Jónsson]

Yes, the intended use is relative timings and timeouts.
I think we are complicating things far too much. 
1) Do we really need a fallback on windows? Will QPC ever fail?
2) is it a problem for the intended use if we cannot absolutely guarantee that 
time won't ever tick backwards?

IMHO, we shouldn't compilicate the api, and make whatever best try we can in C. 
 On windows I would do this (pseudocode)

Static last_time = 0
If (QPC_works) time = QueryPerformanceCounter() else time = 
GetSystemTimeAsFileTime()   
if (time > last_time) last_time=time else time = last_time
return time

in other words:
1) use QPC.  If the api indicates that it isn't available (does this ever 
happen in real life?) use a fallback of system time
2) enforce monotonicity with a static.  QPC, if the OS doesn"t is buggy (calls 
cpu counter rather than timer chip) can cause jitter because it is called on 
different cores.

No options in the api.  No nothing.  We simply provide the best api possible 
and some hardware/software combos might be less accurate.

K

-Original Message-
From: python-dev-bounces+kristjan=ccpgames@python.org 
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of Matt 
Joiner
Sent: 14. mars 2012 09:12
To: Antoine Pitrou; Victor Stinner; Guido van Rossum
Cc: python-dev@python.org
Subject: Re: [Python-Dev] Drop the new time.wallclock() function?

I have some observations regarding this:

Victor's existing time.monotonic and time.wallclock make use of 
QueryPerformanceCounter, and CLOCK_MONOTONIC_RAW as possible. Both of these are 
hardware-based counters, their monotonicity is just a convenient property of 
the timer sources. Furthermore, time values can actually vary depending on the 
processor the call is served on.
time.hardware()? time.monotonic_raw()?

There are bug reports on Linux that CLOCK_MONOTONIC isn't always monotonic. 
This is why CLOCK_MONOTONIC_RAW was created. There's also the issue of time 
leaps (forward), which also isn't a problem with the latter form. 
time.monotonic(raw_only=False)?

The real value of "monotonic" timers is that they don't leap backwards, and 
preferably don't leap forwards. Whether they are absolute is of no consequence. 
I would suggest that the API reflect this, and that more specific time values 
be obtained using the proper raw syscall wrapper (like time.clock_gettime) if 
required.
time.relative(strict=False)?

The ultimate use of the function name being established is for use in timeouts 
and relative timings.

Where an option is present, it disallows fallbacks like CLOCK_MONOTONIC and 
other weaker forms:
 * time.hardware(fallback=True) -> reflects the source of the timing 
impeccably. alerts users to possible affinity issues
 * time.monotonic_raw() -> a bit linux specific...
 * time.relative(strict=False) -> matches the use case. a warning could be put 
regarding hardware timings
 * time.monotonic(raw_only=False) -> closest to the existing implementation. 
the keyword name i think is better.
___
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/kristjan%40ccpgames.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] SocketServer issues

[Guido van Rossum]

2012/3/13 Kristján Valur Jónsson :
> I want to mention some issues I‘ve had with the socketserver module, and
> discuss if there‘s a way to make it nicer.
>
> So, for a long time we were able to create magic stackless mixin classes for
> it, like ThreadingMixIn, and assuming we had the appropriate socket
> replacement library, be able to use it nicely using tasklets.
>
> Then, at some point, the run_forever loop was changed to support timeout
> through the use of select.select() before every socket.accept() call.  This
> was very awkward because the whole concept of select() really goes contrary
> to the approach of using microthreads, non-blocking IO and all that.

I'm surprised -- surely a non-blocking framework should have no
problem implementing select(), especially if it's for one file
descriptor?

> The only reason for this select call, was to support timeout for the
> accept.  And even for vanilla applications, it necessiates an extra kernel
> call for every accept, just for the timeout.

I think it's fine to change the code so that if poll_interval is
explicitly set to None, the select() call is skipped. I don't think
the default should change though. The select() call is normally needed
to support the shutdown() feature, which is very useful. And also the
overridable service_actions() method.

Oh, there's another select() call, in handle_request(), that should
also be skipped if timeout is None.

At least, I *think* a select() with a timeout of None blocks forever
or until the socket is ready or until it is interrupted; I think this
can always be skipped, since the immediately following I/O call will
block in exactly the same way. Unless the socket is set in
non-blocking mode; we may have to have provisions to avoid breaking
that situation too.

> The way around this for me has to do local modifications to the SocketServer
> and just get rid of the select.

I hope the above suggestion is sufficient? It's the best we can do
while maintaining backward compatibility. This class has a lot of
different features, and is designed to be subclassed, so it's hard to
make changes that don't break anything.

> So, my first question is:  Why not simply rely on the already built-in
> timeout support in the socket module?  Setting the correct timeout value on
> the accepting socket, will achieve the same thing.  Of course, one then has
> to reset the timeout value on the accepted socket, but this is minor.

I don't think it's the same thing at all. If you set a timeout on the
socket, the accept() or recvfrom() call in get_request() will raise an
exception if no request comes in within the timeout (default 0.5 sec);
with the timeout implemented in serve_forever(), get_request() and its
callers won't have to worry about the timeout exception.

> Second: Of late the SocketServer has grown additional features and
> attributes.  In particular, it now has two event objects, __shutdown_request
> and __is_shut_down.
>
> Notice the double underscores.
>
> They make it impossible to subclass the SocketServer class to provide a
> different implementation of run_forever().  Is there any good reason why
> these attributes have been made „private“ like this?  Having just seen
> Raymond‘s talk on how to subclass right, this looks like the wrong way to
> use the double leading underscores.

Assuming you meant serve_forever(), I see no problem at all. If you
override serve_forever() you also have to override shutdown(). That's
all. They are marked private because they are involved in subtle
invariants that are easily disturbed if users touch them.

I could live with making them single-underscore protected, only to be
used by knowledgeable subclasses. But not with making then public
attributes.

> So, two things really:
>
> The use of select.select in SocketServer makes it necessary to subclass it
> to write a new version of run_forever() for those that wish to use a
> non-blocking IO library instead of socket. And the presence of these private
> attributes make it (theoretically) impossible to specialize run_forever in a
> mix-in class.
>
>
>
> Any thoughs?  Is anyone interested in seeing how the timeouts can be done
> without using select.select()?  And what do you think about removing the
> double underscores from there and thus making serve_forever owerrideable?

Let's see a patch (based on my concerns above) and then we can talk again.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Nadeem Vawda]

A summary of the discussion so far, as I've understood it:

- We should have *one* monotonic/steady timer function, using the
  sources described in Victor's original post.

- By default, it should fall back to time.time if a better source is
  not available, but there should be a flag that can disable this
  fallback for users who really *need* a monotonic/steady time source.

- Proposed names for the function:
  * monotonic
  * steady_clock
  * wallclock
  * realtime

- Proposed names for the flag controlling fallback behavior:
  * strict (=False)
  * fallback (=True)
  * monotonic (=False)


For the function name, I think monotonic() and steady_clock() convey
the purpose of the function much better than the other two; the term
"wallclock" is actively misleading, and "realtime" seems ambiguous.

For the flag name, I'm -1 on "monotonic" -- it sounds like a flag to
decide whether to use a monotonic time source always or never, while
it actually decides between "always" and "sometimes". I think "strict"
is nicer than "fallback", but I'm fine with either one.

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] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

[Antoine Pitrou]

On Thu, 15 Mar 2012 00:26:09 +0800
Matt Joiner  wrote:
> > Can you give a pointer to these one-liners?
> > Once a patch gets a month old or older, it tends to disappear from
> > everyone's radar unless you somehow "ping" on the tracker, or post a
> > message to the mailing-list.
> 
> All of these can be verified with a few minutes of checking the
> described code paths.
> 
> http://bugs.python.org/issue13839
> http://bugs.python.org/issue13872
> http://bugs.python.org/issue12684
> http://bugs.python.org/issue13694

Thanks. You did get some comments and answers on some of these issues,
though (especially on http://bugs.python.org/issue13872 ).

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] Docs of weak stdlib modules should encourage exploration of 3rd-party alternatives

[Terry Reedy]

On 3/14/2012 6:05 AM, Mark Shannon wrote:


But how do you find issues?


It takes some practice. Since you patched core component dict, I tried 
All text: dict and Components: Interpreter Core. (Leave default Status: 
open as is.) 51 issues. Add Keyword: needs review. 0 issues. Whoops, 
seems not to be used. Change to Keyword: patch. 31 issues. That seems 
like a manageable number of titles to 'wade through', middle clicking 
ones that seem promising to open in a new tab.



I want to do some reviews, but I don't want to wade through issues on
components I know little or nothing about in order to find the ones I
can review.


If you want more help, ask me here or privately. I am probably better at 
searching than fixing.



There does not seem to be a way to filter search results in the tracker.


I am not sure what you mean as there are multiple search fields. The 
basic text box is, admittedly, limited in that it combines multiple 
words with AND, with no other choices. An OR search requires multiple 
searches. Exclusion is not possible that I know of, and perhaps that is 
what you meant. The other fields that seem most useful to me are Stage, 
Type, Components, and Status.


--
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] SocketServer issues

[PJ Eby]

On Wed, Mar 14, 2012 at 12:29 PM, Antoine Pitrou wrote:

> On Wed, 14 Mar 2012 12:17:06 -0400
> PJ Eby  wrote:
> > That's not really the point; the frameworks that implement nonblocking
> I/O
> > by replacing the socket module (and Stackless is only one of many) won't
> be
> > using that code.
>
> Then they should also replace the select module.
>

That actually sounds like a good point.  ;-)

I'm not the maintainer of any of those frameworks, but IIRC some of them
*do* replace it.  Perhaps this would solve Stackless's problem here too?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Matt Joiner]

On Thu, Mar 15, 2012 at 12:22 AM, Guido van Rossum  wrote:
> I have a totally different observation. Presumably the primary use
> case for these timers is to measure real time intervals for the
> purpose of profiling various operations. For this purpose we want them
> to be as "steady" as possible: tick at a constant rate, don't jump
> forward or backward. (And they shouldn't invoke the concept of "CPU"
> time -- we already have time.clock() for that, besides it's often
> wrong, e.g. you might be measuring some sort of I/O performance.) If
> this means that a second as measured by time.time() is sometimes not
> the same as a second measured by this timer (due to time.time()
> occasionally jumping due to clock adjustments), that's fine with me.
> If this means it's unreliable inside a VM, well, it seems that's a
> property of the underlying OS timer, and there's not much we can do
> about it except letting a knowledgeable user override the timer user.
> As for names, I like Jeffrey's idea of having "steady" in the name.

In that case I'd suggest either time.hardware(strict=True), or
time.steady(strict=True), since the only timers exposed natively that
are both high resolution and steady are on the hardware. A warning
about CPU affinity is also still wise methinks.
___
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?

[Kristján Valur Jónsson]

> - By default, it should fall back to time.time if a better source is
>  not available, but there should be a flag that can disable this
>  fallback for users who really *need* a monotonic/steady time source.
As pointed out on a different thread, you don"t need this "flag" since the code 
can easily enforce the monotonic property by maintaining a static value.
This is how we worked around buggy implementations of QueryPerformanceCounter 
on windows ().
K


-Original Message-
From: python-dev-bounces+kristjan=ccpgames@python.org 
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of 
Nadeem Vawda
Sent: 14. mars 2012 09:47
To: Guido van Rossum
Cc: Antoine Pitrou; python-dev@python.org
Subject: Re: [Python-Dev] Drop the new time.wallclock() function?

A summary of the discussion so far, as I've understood it:

- We should have *one* monotonic/steady timer function, using the
  sources described in Victor's original post.

- By default, it should fall back to time.time if a better source is
  not available, but there should be a flag that can disable this
  fallback for users who really *need* a monotonic/steady time source.

- Proposed names for the function:
  * monotonic
  * steady_clock
  * wallclock
  * realtime

- Proposed names for the flag controlling fallback behavior:
  * strict (=False)
  * fallback (=True)
  * monotonic (=False)


For the function name, I think monotonic() and steady_clock() convey the 
purpose of the function much better than the other two; the term "wallclock" is 
actively misleading, and "realtime" seems ambiguous.

For the flag name, I'm -1 on "monotonic" -- it sounds like a flag to decide 
whether to use a monotonic time source always or never, while it actually 
decides between "always" and "sometimes". I think "strict"
is nicer than "fallback", but I'm fine with either one.

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/kristjan%40ccpgames.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] SocketServer issues

[Kristján Valur Jónsson]

>I don't really think the ability to "create magic stackless mixin classes" 
>should be a driving principle for the stdlib.
> I would suggest using a proper non-blocking framework such as Twisted.

There is a lot of code out there that uses SocketServer.  It was originally 
designed to be easily extensable, with various mixins to control ultimate
Behavior.  It just seems that there have been some design decisions made 
recently that make this subclassability / extensibility more difficult, and 
those
Are the two changes I pointed out.  The thing with the select.select wouldn't 
be so bad if I could simply override serve_forever but that function
Can't be overridden because of the poor choice of adding __attributes to the 
class.

And, you would run into the same kind of trouble if you wanted to create a 
TwistedMixIn, a geventMixIn, or what not.

> In case you didn't notice, the built-in timeout support *also* uses select().
Yes, that's how the normal blocking framework supports timeout.  Asynchronous 
frameworks do it differently, though.

> Then they should also replace the select module.
> Again, I don't think SocketServer (or any other stdlib module) should be 
> designed in this regard.

And so we do too, but now every socket accept requires two rounds round the 
event loop.  Also, emulating select() is not a critical part of frameworks 
designed to help you avoid to use it in the first place.  The point of 
frameworks such as gevent, stackless, etc, is to let you write code with 
zillions of sockets without ever touching select.  The quick and dirty emulated 
version I use, uses a thread to make it non-blocking!

It just seems odd to me that it was designed to use the "select" api to do 
timeouts, where timeouts are already part of the socket protocol and can be 
implemented more efficiently there.

Anyway, I'm not talking about rewriting anything, I merely want to fix some 
small design problems that prevent SocketServer to be specialized.  I'll submit 
a simple patch for review.

K
-Original Message-
From: python-dev-bounces+kristjan=ccpgames@python.org 
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of 
Antoine Pitrou
Sent: 14. mars 2012 02:02
To: python-dev@python.org
Subject: Re: [Python-Dev] SocketServer issues

On Wed, 14 Mar 2012 04:26:16 +
Kristján Valur Jónsson  wrote:
> Hi there.
> I want to mention some issues I've had with the socketserver module, and 
> discuss if there's a way to make it nicer.
> So, for a long time we were able to create magic stackless mixin 
> classes for it, like ThreadingMixIn, and assuming we had the 
> appropriate socket replacement library, be able to use it nicely using 
> tasklets.

I don't really think the ability to "create magic stackless mixin classes" 
should be a driving principle for the stdlib.
I would suggest using a proper non-blocking framework such as Twisted.

> So, my first question is:  Why not simply rely on the already built-in 
> timeout support in the socket module?

In case you didn't notice, the built-in timeout support *also* uses select().

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/kristjan%40ccpgames.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] Drop the new time.wallclock() function?

[Matt Joiner]

FWIW the name is quite important, because these kind of timings are
quite important so I think it's worth the effort.

> - By default, it should fall back to time.time if a better source is
>  not available, but there should be a flag that can disable this
>  fallback for users who really *need* a monotonic/steady time source.

Agreed. As Guido mentioned, some platforms might not be able to access
to hardware times, so falling back should be the default, lest unaware
users trigger unexpected errors.

> - Proposed names for the function:
>  * monotonic

Doesn't indicate that the timing is also prevented from leaping forward.

>  * steady_clock

I think the use of clock might infer CPU time on doc-skimming user.
"clock" is overloaded here.

> For the flag name, I'm -1 on "monotonic" -- it sounds like a flag to
> decide whether to use a monotonic time source always or never, while
> it actually decides between "always" and "sometimes". I think "strict"
> is nicer than "fallback", but I'm fine with either one.

I agree, "strict" fits in with existing APIs.

I think time.hardware(), and time.steady() are still okay here.
___
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?

[Guido van Rossum]

+1 for steady().

On Wed, Mar 14, 2012 at 10:15 AM, Matt Joiner  wrote:
> FWIW the name is quite important, because these kind of timings are
> quite important so I think it's worth the effort.
>
>> - By default, it should fall back to time.time if a better source is
>>  not available, but there should be a flag that can disable this
>>  fallback for users who really *need* a monotonic/steady time source.
>
> Agreed. As Guido mentioned, some platforms might not be able to access
> to hardware times, so falling back should be the default, lest unaware
> users trigger unexpected errors.
>
>> - Proposed names for the function:
>>  * monotonic
>
> Doesn't indicate that the timing is also prevented from leaping forward.
>
>>  * steady_clock
>
> I think the use of clock might infer CPU time on doc-skimming user.
> "clock" is overloaded here.
>
>> For the flag name, I'm -1 on "monotonic" -- it sounds like a flag to
>> decide whether to use a monotonic time source always or never, while
>> it actually decides between "always" and "sometimes". I think "strict"
>> is nicer than "fallback", but I'm fine with either one.
>
> I agree, "strict" fits in with existing APIs.
>
> I think time.hardware(), and time.steady() are still okay here.



-- 
--Guido van Rossum (python.org/~guido)
___
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] SocketServer issues

[Antoine Pitrou]

On Wed, 14 Mar 2012 16:59:47 +
Kristján Valur Jónsson  wrote:
> 
> It just seems odd to me that it was designed to use the "select" api to do 
> timeouts, > where timeouts are already part of the socket protocol and can be 
> implemented more
> efficiently there.

How is it more efficient if it uses the exact same system calls?
And why are you worrying exactly? I don't understand why accept() would
be critical for performance.

Thanks

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?

[Andrew Svetlov]

On Wed, Mar 14, 2012 at 10:21 AM, Guido van Rossum  wrote:
> +1 for steady().
>

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

[Lennart Regebro]

On Wed, Mar 14, 2012 at 10:16, Antoine Pitrou  wrote:
> That's a rather awful name.  time.time() is *the* real time.
>
> time.monotonic(fallback=False) would be a better API.

I think calling the function "monotonic" isn't really a good name if
it's not always monotonic.

  time.monotonic(fallback=False)

Really just means

  time.monotonic(monotonic=False)

And

  time.monotonic(strict=True)

Really means

  time.monotonic(i_really_mean_it=True)

This is potentially confusing. Therefore

  time.clock()
  time.time()
  time.realtime()
  time.wallclock()

Are all better options if there is a flag to switch if it's monotonic or not.

Since time.clock() apparently can mean different things on different
platforms because of it's use of the C-API, we can't use that.
I'm not sure why time.time() would differ from time.realtime().
time.time() is per definition not monotonic, but

  time.time(monotonic=True)

is maybe a possibility?


//Lennart
//Lennart
___
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

[Terry Reedy]

On 3/14/2012 12:10 PM, VanL wrote:

On 3/14/2012 10:56 AM, Terry Reedy wrote:

Are you talking about 'install for all users' versus 'install for this
user only'? I have always done the former as I see no point to the
latter on my machine, even if another family member has an account.


Yes, but some people are on corporate machines that only allow "install
for this user" installations.


Ok. On such machines, system install (by vendor) == only 'base' install 
== only 'all user' install.



I am fine with keeping the distinction between

> base installs (no py_version)

I have no idea what this means. As far as I can remember, each
installation of Python x.y (back to 1.3 for me, on DOS) has gone into a
pythonxy (no dot) directory, with subdirectories much as Jim J.
described.


I am referring to the currently-existing install schemes 'nt' ('install
for all users') and 'nt-user' ('install for this user only'). The
*current* layouts are described at
http://hg.python.org/distutils2/file/2cec52b682a9/distutils2/_backport/sysconfig.cfg:

L57-65:
[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}


Is this from 2.x? Currently, in 3.x, Scripts is tucked inside Tools, so 
it seems to be scripts = {base}/Tools/Scripts


L86-93:
[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}

I am proposing that these 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}

[nt_user]
stdlib = {userbase}/python{py_version_short}
platstdlib = {userbase}/python{py_version_short}
purelib = {userbase}/python{py_version_short}/site-packages
platlib = {userbase}/python{py_version_short}/site-packages
include = {userbase}/python{py_version_short}/include
scripts = {userbase}/bin
data = {userbase}


OK, now I see where 'base' and 'userbase' come from. This is an area I 
have ignored, so I only have a user view of the result.



All the other diuectories that Jim talked about would not be affected by
this proposal.

Does this make it clearer?


Now that we are speaking the same language, yes. Thank you.
Lowercasing 'Include' is fine with me. The only question is how it 
affects tools in the field. Lowercasing 'Lib' would also be fine if 
'libs' were changed to 'libraries' or 'headers' or perhaps even better, 
'_libs', as normal users never have any reason to look therein. Just 
something more easily distinguished from 'lib'. Same comment about tools.


The present installed directory scheme is a hodgepodge of almost all 
caps, initial cap, and no cap. I would not mind more consistency. The 
only directory I regularly look in is Lib, so my main concern is that 
that be visually easy to find with my less than perfect vision.


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

[Python-Dev] Python install layout and the PATH on win32

[Jim J. Jewett]

In http://mail.python.org/pipermail/python-dev/2012-March/117617.html
van.lindberg at gmail.com posted:

> As noted earlier in the thread, I also change my proposal to maintain 
> the existing differences between system installs and user installs.

[Wanted lower case, which should be irrelevant; sysconfig.get_python_inc
already assumes lower case despite the configuration file.]

[Wanted "bin" instead of "Scripts", even though they aren't binaries.]

If there are to be any changes, I *am* tempted to at least harmonize
the two install types, but to use the less redundant system form.  If
the user is deliberately trying to hide that it is version 33 (or even
that it is python), then so be it; defaulting to redundant information
is not an improvement.

Set the base/userbase at install time, with defaults of

base = %SystemDrive%\{py_version_nodot}
userbase = %USERPROFILE%\Application Data\{py_version_nodot}

usedbase = base for system installs; userbase for per-user installs.

Then let the rest default to subdirectories; sysconfig.get_config_vars
on windows explicitly doesn't provide as many variables as unix, just
INCLUDEPY (which should default to {usedbase}/include) and
LIBDEST and BINLIBDEST (both of which should default to {usedbase}/lib).

And no, I'm not forgetting data or scripts.  As best I can tell,
sysconfig doesn't actually expose them, and there is no Scripts
directory on my machine (except inside Tools).  Perhaps some
installers create it when they install their own extensions?

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

[Lennart Regebro]

2012/3/14 Kristján Valur Jónsson :
>> - By default, it should fall back to time.time if a better source is
>>  not available, but there should be a flag that can disable this
>>  fallback for users who really *need* a monotonic/steady time source.
> As pointed out on a different thread, you don"t need this "flag" since the 
> code can easily enforce the monotonic property by maintaining a static value.

With this, I think time.steady() would be clear and nice.

//Lennart
___
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] SocketServer issues

[Kristján Valur Jónsson]

A different implementation, (e.g. one using windows IOCP), can do timeouts 
without using select (and must, select does not work with IOCP).   So will a 
gevent based implementation, it will timeout the accept on each socket 
individually, not by calling select on each of them.

The reason I'm fretting is latency.  There is only one thread accepting 
connections.  If it has to do an extra event loop dance for every socket that 
it accepts that adds to the delay in getting a response from the server.  
Accept() is indeed critical for socket server performance.

Maybe this is all just nonsense, still it seems odd to jump through extra hoops 
to emulate a functionality that is already supported by the socket spec, and 
can be done in the most appropriate way for each implementation.

K

-Original Message-
From: python-dev-bounces+kristjan=ccpgames@python.org 
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of 
Antoine Pitrou
Sent: 14. mars 2012 10:23
To: python-dev@python.org
Subject: Re: [Python-Dev] SocketServer issues

On Wed, 14 Mar 2012 16:59:47 +
Kristján Valur Jónsson  wrote:
> 
> It just seems odd to me that it was designed to use the "select" api 
> to do timeouts, > where timeouts are already part of the socket protocol and 
> can be implemented more efficiently there.

How is it more efficient if it uses the exact same system calls?
And why are you worrying exactly? I don't understand why accept() would be 
critical for performance.

Thanks

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] SocketServer issues

[Guido van Rossum]

2012/3/14 Kristján Valur Jónsson :
> Maybe this is all just nonsense, still it seems odd to jump through extra 
> hoops to emulate a functionality that is already supported by the socket 
> spec, and can be done in the most appropriate way for each implementation.

I thought I had already explained why setting the timeout on the
socket is not the same.

-- 
--Guido van Rossum (python.org/~guido)
___
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]

I also can live with steady, with strict for the flag.
___
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] 2012 Language Summit Report

[Georg Brandl]

On 14.03.2012 15:12, Brian Curtin wrote:

As with last year, I've put together a summary of the Python Language
Summit which took place last week at PyCon 2012. This was compiled
from my notes as well as those of Eric Snow and Senthil Kumaran, and I
think we got decent coverage of what was said throughout the day.

http://blog.python.org/2012/03/2012-language-summit-report.html

If you have questions or comments about discussions which occurred
there, please create a new thread for your topic.

Feel free to contact me directly if I've left anything out or
misprinted anything.


Thanks for the comprehensive report (I'm still reading).  May I request
for the future that you also paste a copy in the email to the group, for
purposes of archiving and ease of discussing?  (Just like we also post
PEPs to python-dev for discussion even when they are already online.)

cheers,
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] 2012 Language Summit Report

[Glenn Linderman]

On 3/14/2012 8:57 AM, Terry Reedy wrote:

On 3/14/2012 10:12 AM, Brian Curtin wrote:

As with last year, I've put together a summary of the Python Language
Summit which took place last week at PyCon 2012. This was compiled
from my notes as well as those of Eric Snow and Senthil Kumaran, and I
think we got decent coverage of what was said throughout the day.

http://blog.python.org/2012/03/2012-language-summit-report.html


Nicely done. Thank you.


Thanks. Almost feels like I was there!
___
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] 2012 Language Summit Report

[Brian Curtin]

On Wed, Mar 14, 2012 at 13:52, Georg Brandl  wrote:
> Thanks for the comprehensive report (I'm still reading).  May I request
> for the future that you also paste a copy in the email to the group, for
> purposes of archiving and ease of discussing?  (Just like we also post
> PEPs to python-dev for discussion even when they are already online.)

Certainly -- good idea. I have a few updates and corrections to make
this evening, then I'll get a copy of it posted.
___
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: PEP 417: Adding unittest.mock

[Georg Brandl]

On 14.03.2012 20:25, michael.foord wrote:

http://hg.python.org/cpython/rev/2fda048ee32a
changeset:   75632:2fda048ee32a
user:Michael Foord
date:Wed Mar 14 12:24:34 2012 -0700
summary:
   PEP 417: Adding unittest.mock

files:
   Lib/unittest/mock.py   |  2151 ++
   Lib/unittest/test/__init__.py  | 1 +
   Lib/unittest/test/testmock/__init__.py |17 +
   Lib/unittest/test/testmock/support.py  |23 +
   Lib/unittest/test/testmock/testcallable.py |   159 +
   Lib/unittest/test/testmock/testhelpers.py  |   835 +++
   Lib/unittest/test/testmock/testmagicmethods.py |   382 +
   Lib/unittest/test/testmock/testmock.py |  1258 +
   Lib/unittest/test/testmock/testpatch.py|  1652 +++
   Lib/unittest/test/testmock/testsentinel.py |28 +
   Lib/unittest/test/testmock/testwith.py |   176 +
   11 files changed, 6682 insertions(+), 0 deletions(-)


I hope we also get some Dock/ ;)

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] SocketServer issues

[Kristján Valur Jónsson]

Yes, setting a timeout and leaving it that way is not the same.  But setting 
the timeout for _accept only_ is the "same" except one approach requires the 
check of a bool return, the other the handling of a socket.timeout exeption.
My point is, if sockets already have nice and well defined timeout semantics, 
why not use them, or even improve them (perhaps with an optional timeout 
parameter to the accept call) rather than reimplement them with an explicit 
select.select() call?

Anyway, I'll take another look at the problem and possibly submit a patch 
suggestion.  Thanks.

K

-Original Message-
From: gvanros...@gmail.com [mailto:gvanros...@gmail.com] On Behalf Of Guido van 
Rossum
Sent: 14. mars 2012 11:44
To: Kristján Valur Jónsson
Cc: Antoine Pitrou; python-dev@python.org
Subject: Re: [Python-Dev] SocketServer issues

2012/3/14 Kristján Valur Jónsson :
> Maybe this is all just nonsense, still it seems odd to jump through extra 
> hoops to emulate a functionality that is already supported by the socket 
> spec, and can be done in the most appropriate way for each implementation.

I thought I had already explained why setting the timeout on the socket is not 
the same.

--
--Guido van Rossum (python.org/~guido)


___
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: PEP 417: Adding unittest.mock

[Łukasz Langa]

Wiadomość napisana przez Georg Brandl w dniu 14 mar 2012, o godz. 12:33:

> On 14.03.2012 20:25, michael.foord wrote:
>> http://hg.python.org/cpython/rev/2fda048ee32a
>> changeset:   75632:2fda048ee32a
>> user:Michael Foord
>> date:Wed Mar 14 12:24:34 2012 -0700
>> summary:
>>   PEP 417: Adding unittest.mock
>> 
>> files:
>>   Lib/unittest/mock.py   |  2151 ++
>>   Lib/unittest/test/__init__.py  | 1 +
>>   Lib/unittest/test/testmock/__init__.py |17 +
>>   Lib/unittest/test/testmock/support.py  |23 +
>>   Lib/unittest/test/testmock/testcallable.py |   159 +
>>   Lib/unittest/test/testmock/testhelpers.py  |   835 +++
>>   Lib/unittest/test/testmock/testmagicmethods.py |   382 +
>>   Lib/unittest/test/testmock/testmock.py |  1258 +
>>   Lib/unittest/test/testmock/testpatch.py|  1652 +++
>>   Lib/unittest/test/testmock/testsentinel.py |28 +
>>   Lib/unittest/test/testmock/testwith.py |   176 +
>>   11 files changed, 6682 insertions(+), 0 deletions(-)
> 
> I hope we also get some Dock/ ;)

Mock the doc!

-- 
Best regards,
Łukasz Langa
Senior Systems Architecture Engineer

IT Infrastructure Department
Grupa Allegro Sp. z o.o.

___
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: PEP 417: Adding unittest.mock

[Terry Reedy]

On 3/14/2012 3:25 PM, michael.foord wrote:

+# mock.py
+# Test tools for mocking and patching.


Should there be a note here about restrictions on editing this file?
I notice that there are things like

> +class OldStyleClass:
> +pass
> +ClassType = type(OldStyleClass)

which are only present for running under Py2 and which would normally be 
removed for Py3.


---
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] [Python-checkins] cpython: PEP 417: Adding unittest.mock

[Michael Foord]

On 14 Mar 2012, at 13:08, Terry Reedy wrote:

> On 3/14/2012 3:25 PM, michael.foord wrote:
>> +# mock.py
>> +# Test tools for mocking and patching.
> 
> Should there be a note here about restrictions on editing this file?
> I notice that there are things like
> 
> > +class OldStyleClass:
> > +pass
> > +ClassType = type(OldStyleClass)
> 
> which are only present for running under Py2 and which would normally be 
> removed for Py3.


Yeah, I removed as much of the Python 2 compatibility code and thought I'd got 
it all. Thanks for pointing it out.

I'm maintaining a "clean" (no Python 2 compatibility code) version in the 
standard library. I'll be maintaining mock, so I'd like to be assigned any 
issues on it and at least talked to before changes are made. I am maintaining a 
backport still, but the Python standard library version is the canonical 
version.

All the best,

Michael Foord

> 
> ---
> 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/fuzzyman%40voidspace.org.uk
> 


--
http://www.voidspace.org.uk/


May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing 
http://www.sqlite.org/different.html





___
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: PEP 417: Adding unittest.mock

[Michael Foord]

On 14 Mar 2012, at 12:33, Georg Brandl wrote:

> On 14.03.2012 20:25, michael.foord wrote:
>> http://hg.python.org/cpython/rev/2fda048ee32a
>> changeset:   75632:2fda048ee32a
>> user:Michael Foord
>> date:Wed Mar 14 12:24:34 2012 -0700
>> summary:
>>   PEP 417: Adding unittest.mock
>> 
>> files:
>>   Lib/unittest/mock.py   |  2151 ++
>>   Lib/unittest/test/__init__.py  | 1 +
>>   Lib/unittest/test/testmock/__init__.py |17 +
>>   Lib/unittest/test/testmock/support.py  |23 +
>>   Lib/unittest/test/testmock/testcallable.py |   159 +
>>   Lib/unittest/test/testmock/testhelpers.py  |   835 +++
>>   Lib/unittest/test/testmock/testmagicmethods.py |   382 +
>>   Lib/unittest/test/testmock/testmock.py |  1258 +
>>   Lib/unittest/test/testmock/testpatch.py|  1652 +++
>>   Lib/unittest/test/testmock/testsentinel.py |28 +
>>   Lib/unittest/test/testmock/testwith.py |   176 +
>>   11 files changed, 6682 insertions(+), 0 deletions(-)
> 
> I hope we also get some Dock/ ;)

I was thinking about providing documentation, but I thought maybe I'd leave it 
for you Georg. It's nice to get an outside perspective when documenting a new 
api 

I have issue 14295 to track adding mock and it won't be closed until the docs 
are completed. 

http://bugs.python.org/issue14295

On the topic of docs mock documentation is about eight pages long. My 
intention was to strip this down to just the api documentation, along with a 
link to the docs on my site for further examples and so on. I was encouraged 
here at the sprints to include the full documentation instead (minus the mock 
library comparison page and the front page can be cut down). So this is what I 
am now intending to include. It does mean the mock documentation will be 
"extensive".

All the best,

Michael


> 
> 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/fuzzyman%40voidspace.org.uk
> 


--
http://www.voidspace.org.uk/


May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing 
http://www.sqlite.org/different.html





___
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: PEP 417: Adding unittest.mock

[Benjamin Peterson]

2012/3/14 Michael Foord :
> On the topic of docs mock documentation is about eight pages long. My 
> intention was to strip this down to just the api documentation, along with a 
> link to the docs on my site for further examples and so on. I was encouraged 
> here at the sprints to include the full documentation instead

Yes, please do.

-- 
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] [Python-checkins] cpython: PEP 417: Adding unittest.mock

[Terry Reedy]

On 3/14/2012 4:22 PM, Michael Foord wrote:


On 14 Mar 2012, at 13:08, Terry Reedy wrote:


On 3/14/2012 3:25 PM, michael.foord wrote:

+# mock.py +# Test tools for mocking and patching.



Should there be a note here about restrictions on editing this
file? I notice that there are things like


+class OldStyleClass: +pass +ClassType = type(OldStyleClass)


which are only present for running under Py2 and which would
normally be removed for Py3.



Yeah, I removed as much of the Python 2 compatibility code and
thought I'd got it all. Thanks for pointing it out.


2000 lines is a lot to check through.


I'm maintaining a "clean" (no Python 2 compatibility code) version in
the standard library.


Great. Here is something else, which is why I thought otherwise ;-).

+def _instance_callable(obj):
+"""Given an object, return True if the object is callable.
+For classes, return True if instances would be callable."""
+if not isinstance(obj, type):
+# already an instance
+return getattr(obj, '__call__', None) is not None
+
+klass = obj
+# uses __bases__ instead of __mro__ so that we work with
>>>  old style classes
+if klass.__dict__.get('__call__') is not None:
+return True
+
+for base in klass.__bases__:
+if _instance_callable(base):
+return True
+return False

If you want to leave the code as is, remove or revise the comment.


I'll be maintaining mock, so I'd like to be
assigned any issues on it and at least talked to before changes are
made. I am maintaining a backport still, but the Python standard
library version is the canonical version.


Add unittest.mock to devguide/experts.rst and yourself with * appended.

---
Searching for 'old', I also found

+def _must_skip(spec, entry, is_type):
+if not isinstance(spec, type):
+if entry in getattr(spec, '__dict__', {}):
+# instance attribute - shouldn't skip
+return False
>>>+# can't use type because of old style classes
+spec = spec.__class__
+if not hasattr(spec, '__mro__'):
>>>+# old style class: can't have descriptors anyway
+return is_type

In testcallable.py
+def test_patch_spec_callable_class(self):
+class CallableX(X):
+def __call__(self):
+pass
+
+class Sub(CallableX):
+pass
+
+class Multi(SomeClass, Sub):
+pass
+
>>>+class OldStyle:
+def __call__(self):
+pass
+
>>>+class OldStyleSub(OldStyle):
+pass
+
+for arg in 'spec', 'spec_set':
>>>+for Klass in CallableX, Sub, Multi, OldStyle, OldStyleSub:

This is the last.

--
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] cpython: Issue #14200: Idle shell crash on printing non-BMP unicode character.

[Georg Brandl]

On 14.03.2012 21:46, andrew.svetlov wrote:


diff --git a/Lib/idlelib/rpc.py b/Lib/idlelib/rpc.py
--- a/Lib/idlelib/rpc.py
+++ b/Lib/idlelib/rpc.py
@@ -196,8 +196,12 @@
  return ("ERROR", "Unsupported message type: %s" % how)
  except SystemExit:
  raise
+except KeyboardInterrupt:
+raise
  except socket.error:
  raise
+except Exception as ex:
+return ("CALLEXC", ex)
  except:
  msg = "*** Internal Error: rpc.py:SocketIO.localcall()\n\n"\
" Object: %s \n Method: %s \n Args: %s\n"


It appears that this would be better written as

except socket.error:
raise
except Exception:
return ("CALLEXC", ex)
except:  # BaseException, i.e. SystemExit, KeyboardInterrupt, GeneratorExit
raise

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

[Nadeem Vawda]

+1 for time.steady(strict=False).


On Wed, Mar 14, 2012 at 7:09 PM, Kristján Valur Jónsson
 wrote:
>> - By default, it should fall back to time.time if a better source is
>>  not available, but there should be a flag that can disable this
>>  fallback for users who really *need* a monotonic/steady time source.
> As pointed out on a different thread, you don"t need this "flag" since the 
> code can easily enforce the monotonic property by maintaining a static value.
> This is how we worked around buggy implementations of QueryPerformanceCounter 
> on windows ().
> K

That's fine if you just need the clock to be monotonic, but it isn't
any help if you also want to prevent it from jumping forward.

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] [Python-checkins] cpython: PEP 417: Adding unittest.mock

[Michael Foord]

On 14 Mar 2012, at 13:46, Terry Reedy wrote:

> On 3/14/2012 4:22 PM, Michael Foord wrote:
>> 
>> On 14 Mar 2012, at 13:08, Terry Reedy wrote:
>> 
>>> On 3/14/2012 3:25 PM, michael.foord wrote:
 +# mock.py +# Test tools for mocking and patching.
> 
>>> Should there be a note here about restrictions on editing this
>>> file? I notice that there are things like
>>> 
 +class OldStyleClass: +pass +ClassType = type(OldStyleClass)
>>> 
>>> which are only present for running under Py2 and which would
>>> normally be removed for Py3.
>> 
>> 
>> Yeah, I removed as much of the Python 2 compatibility code and
>> thought I'd got it all. Thanks for pointing it out.
> 
> 2000 lines is a lot to check through.
>> 
>> I'm maintaining a "clean" (no Python 2 compatibility code) version in
>> the standard library.
> 
> Great. Here is something else, which is why I thought otherwise ;-).
> 
> +def _instance_callable(obj):
> +"""Given an object, return True if the object is callable.
> +For classes, return True if instances would be callable."""
> +if not isinstance(obj, type):
> +# already an instance
> +return getattr(obj, '__call__', None) is not None
> +
> +klass = obj
> +# uses __bases__ instead of __mro__ so that we work with
> >>>  old style classes
> +if klass.__dict__.get('__call__') is not None:
> +return True
> +
> +for base in klass.__bases__:
> +if _instance_callable(base):
> +return True
> +return False
> 
> If you want to leave the code as is, remove or revise the comment.

Thanks very much for finding these, I'm pretty sure I've fixed all the ones you 
reported - and one more case where try...except...finally can now be used.

All the best,

Michael Foord


> 
>> I'll be maintaining mock, so I'd like to be
>> assigned any issues on it and at least talked to before changes are
>> made. I am maintaining a backport still, but the Python standard
>> library version is the canonical version.
> 
> Add unittest.mock to devguide/experts.rst and yourself with * appended.
> 
> ---
> Searching for 'old', I also found
> 
> +def _must_skip(spec, entry, is_type):
> +if not isinstance(spec, type):
> +if entry in getattr(spec, '__dict__', {}):
> +# instance attribute - shouldn't skip
> +return False
> >>>+# can't use type because of old style classes
> +spec = spec.__class__
> +if not hasattr(spec, '__mro__'):
> >>>+# old style class: can't have descriptors anyway
> +return is_type
> 
> In testcallable.py
> +def test_patch_spec_callable_class(self):
> +class CallableX(X):
> +def __call__(self):
> +pass
> +
> +class Sub(CallableX):
> +pass
> +
> +class Multi(SomeClass, Sub):
> +pass
> +
> >>>+class OldStyle:
> +def __call__(self):
> +pass
> +
> >>>+class OldStyleSub(OldStyle):
> +pass
> +
> +for arg in 'spec', 'spec_set':
> >>>+for Klass in CallableX, Sub, Multi, OldStyle, OldStyleSub:
> 
> This is the last.
> 
> -- 
> 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/fuzzyman%40voidspace.org.uk
> 


--
http://www.voidspace.org.uk/


May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing 
http://www.sqlite.org/different.html





___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python install layout and the PATH on win32

[Mark Hammond]

On 15/03/2012 3:03 AM, Lindberg, Van wrote:

On 3/14/2012 1:32 AM, Mark Hammond wrote:

As per comments later in the thread, I'm -1 on including
"python{py_version_short}" in the lib directories for a number of
reasons; one further reason not outlined is that it would potentially
make running Python directly from a built tree difficult. For the same
reason, I'm also -1 on having that in the include dir.


A built tree would look the same as always - the directories would only
be moved (if at all) during installation. Thus, you will still be able
to run python directly from a built installation.


So long as the location of the "lib" dir doesn't change, that is 
probably true.  If lib was to change though, then PC/getpathp.c would 
need to change which is where my concern came from.



scripts = {base/userbase}/bin


We should note that this may cause pain for a number of projects - I've
seen quite a few projects that already assume "Scripts" on Windows - eg,
virtualenv and setuptools IIRC


If you look at these projects, though, they *special case* Windows to
account for the different layout. Removing this difference will allow
these projects to remove their special-casing code.


I don't think that is true.  One of the examples I offered was a .bat 
file - it wouldn't be possible to remove the .bat file with your 
proposal.  The other example was the Windows specific launcher.


Most things that need to locate the Python executable aren't actually 
Python code - once Python is running, locating the executable is as 
simple as sys.executable.  So by their very nature, tools needing to 
locate Python will tend to be platform specific in the first place.


Can you offer any examples of 3rd party tools which could unify code in 
this scheme, and particularly, where this scheme would cause them to 
have less code, not more?



- and also assume the executable is where
it currently lives - one example off the top of my head is the mozilla
"jetpack" project - see:

https://github.com/mozilla/addon-sdk/blob/master/bin/activate.bat#L117


This code actually reinforces my point:

First, this code would actually still work. The section ":FoundPython"
sets the PATH to "%VIRTUAL_ENV%\bin;%PYTHONINSTALL%;%PATH%" (L80), which
would still allow python.exe to be found and run.

Second, look at that line again. Mozilla actually has edited this code
so that the jetpack uses a cross-platform "bin" convention, just as I am
proposing.


I think you misunderstand the .bat file - there is no python executable 
in the bin directory.  The bat file is locating your already installed 
Python and attempting to use it.



Third, one element of this proposal is that there would be a key placed
in the registry that points directly to the location of the python
executable, making locating it trivial to locate programmatically on
Windows.


That sounds reasonable, but it still causes breakage, and still causes 
extra code for tools needing to support earlier versions.  Saying "hey, 
it's easy to fix" are just words to someone frustrated trying to get 
things working with a later version of Python.


Don't get me wrong - the scheme you propose is how it should have been 
done in the first place, no question.  My issue is the breakage this 
will cause versus the benefit.


My other questions still remain: who specifically will benefit from 
this, and what would be the cost to those beneficiaries of sticking with 
the existing scheme?  The only benefit I've seen suggested is 
aesthetics, and while that is laudable, I don't think it is enough to 
justify breakage.


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

[VanL]

On 3/14/2012 5:39 PM, Mark Hammond wrote:

Can you offer any examples of 3rd party tools which could unify code in
this scheme, and particularly, where this scheme would cause them to
have less code, not more?


How about virtualenv:

"""
def path_locations(home_dir):
  """Return the path locations for the environment (where libraries are,
  where scripts go, etc)"""
  # XXX: We'd use distutils.sysconfig.get_python_inc/lib but its
  # prefix arg is broken: http://bugs.python.org/issue3386
  if sys.platform == 'win32':
[snip a bit about spaces in the path]
lib_dir = join(home_dir, 'Lib')
inc_dir = join(home_dir, 'Include')
bin_dir = join(home_dir, 'Scripts')
  if is_jython:
lib_dir = join(home_dir, 'Lib')
inc_dir = join(home_dir, 'Include')
bin_dir = join(home_dir, 'bin')
  elif is_pypy:
lib_dir = home_dir
inc_dir = join(home_dir, 'include')
bin_dir = join(home_dir, 'bin')
  elif sys.platform != 'win32':
lib_dir = join(home_dir, 'lib', py_version)
inc_dir = join(home_dir, 'include', py_version + abiflags)
bin_dir = join(home_dir, 'bin')
  return home_dir, lib_dir, inc_dir, bin_dir
"""



I think you misunderstand the .bat file - there is no python executable
in the bin directory. The bat file is locating your already installed
Python and attempting to use it.


My only point here is that it would still find the already-installed 
Python (I think).



My other questions still remain: who specifically will benefit from
this, and what would be the cost to those beneficiaries of sticking with
the existing scheme?


I will benefit, for one. My use case is that I do cross-platform 
development and deployment, and I occasionally want to put an entire 
environment in source control. Currently the case changing and 
Scripts/bin distinction make this a distinct pain, such that I go in and 
edit my Windows python installation in the way that I am describing 
right now.


From my actual experience with this layout, pip, virtualenv, and pypm 
are the only three major packages that hard-code this logic and would 
need to be changed slightly.


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

[Mark Hammond]

[resending - original reply went only to Van]

On 15/03/2012 10:15 AM, Lindberg, Van wrote:
> On 3/14/2012 5:39 PM, Mark Hammond wrote:
>> Can you offer any examples of 3rd party tools which could unify code
>> in this scheme, and particularly, where this scheme would cause them
>> to have less code, not more?
>
> How about virtualenv:
>
> """
> def path_locations(home_dir):
> """Return the path locations for the environment (where libraries 
are,

> where scripts go, etc)"""
> # XXX: We'd use distutils.sysconfig.get_python_inc/lib but its
> # prefix arg is broken: http://bugs.python.org/issue3386
> if sys.platform == 'win32':
>   [snip a bit about spaces in the path]
>   lib_dir = join(home_dir, 'Lib')
>   inc_dir = join(home_dir, 'Include')
>   bin_dir = join(home_dir, 'Scripts')
> if is_jython:
>   lib_dir = join(home_dir, 'Lib')
>   inc_dir = join(home_dir, 'Include')
>   bin_dir = join(home_dir, 'bin')
> elif is_pypy:
>   lib_dir = home_dir
>   inc_dir = join(home_dir, 'include')
>   bin_dir = join(home_dir, 'bin')
> elif sys.platform != 'win32':
>   lib_dir = join(home_dir, 'lib', py_version)
>   inc_dir = join(home_dir, 'include', py_version + abiflags)
>   bin_dir = join(home_dir, 'bin')
> return home_dir, lib_dir, inc_dir, bin_dir
> """

So what would that look like in your scheme?  I'd expect you wind up with:

if sys.platform == 'win32' and sys.versioninfo < (3,4):
  ... existing layout
else:
  ... new layout.

So it actually ends up as slightly *more* code.

>
>
>> I think you misunderstand the .bat file - there is no python
>> executable in the bin directory. The bat file is locating your
>> already installed Python and attempting to use it.
>
> My only point here is that it would still find the already-installed
> Python (I think).

I'm fairly sure it would not - it doesn't look in %PYTHONINSTALL%\bin.

>
>> My other questions still remain: who specifically will benefit from
>> this, and what would be the cost to those beneficiaries of sticking
>> with the existing scheme?
>
> I will benefit, for one. My use case is that I do cross-platform
> development and deployment, and I occasionally want to put an entire
> environment in source control. Currently the case changing and
> Scripts/bin distinction make this a distinct pain, such that I go in 
> and edit my Windows python installation in the way that I am

> describing right now.
>
>   From my actual experience with this layout, pip, virtualenv, and
> pypm are the only three major packages that hard-code this logic and
> would need to be changed slightly.

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

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

[Cameron Simpson]

On 13Mar2012 17:27, Guido van Rossum  wrote:
| I think wallclock() is an awkward name; in other contexts I've seen
| "wall clock time" used to mean the time that a clock on the wall would
| show, i.e. local time. This matches definition #1 of
| http://www.catb.org/jargon/html/W/wall-time.html (while yours matches
| #2 :-).

I think this also. A "wallclock()" function that did not return real world
elapsed time seconds would be misleading or at least disconcerting.

| Maybe it could be called realtime()?

"elapsedtime()?" It is getting a bit long though.

Cheers,
-- 
Cameron Simpson  DoD#743
http://www.cskk.ezoshosting.com/cs/

"Shot my dog today."
"Was he mad?"
"Well, he weren't too damned pleased."
- Rick Tilson, rtil...@sun.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] sharing sockets among processes on windows

[Glyph Lefkowitz]

On Mar 13, 2012, at 5:27 PM, Kristján Valur Jónsson wrote:

> Hi,
> I´m interested in contributing a patch to duplicate sockets between processes 
> on windows.
> Tha api to do this is WSADuplicateSocket/WSASocket(), as already used by 
> dup() in the _socketmodule.c
> Here´s what I have:

Just in case anyone is interested, we also have a ticket for this in Twisted: 
. It would be great to share code as 
much as possible.

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

[Kristján Valur Jónsson]

What does "jumping forward" mean?  That's what happens with every clock at 
every time quantum.  The only effect here is that this clock will be slightly 
noisy, i.e. its precision becomes worse.  On average it is still correct.  Look 
at the use cases for this function
1) to enable timeouts for certaing operations, like acquiring locks:
Jumping backwards is bad, because that may cause infinite wait time.  
But jumping forwards is ok, it may just mean that your lock times out a bit 
early
2) performance measurements:
If you are running on a platform with a broken runtime clock, you are 
not likely to be running performance measurements.

Really, I urge you to skip the "strict" keyword.  It just adds confusion.  
Instead, lets just give the best monotonic clock we can do which doesn"t move 
backwards.
Let's just provide a "practical" real time clock with high resolution that is 
appropriate for providing timeout functionality and so won't jump backwards for 
the next 20 years.  Let's simply point out to people that it may not be 
appropriate for high precision timings on old and obsolete hardware and be done 
with it.

K

-Original Message-
From: python-dev-bounces+kristjan=ccpgames@python.org 
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of 
Nadeem Vawda
Sent: 14. mars 2012 14:18
To: Matt Joiner
Cc: Antoine Pitrou; Guido van Rossum; python-dev@python.org
Subject: Re: [Python-Dev] Drop the new time.wallclock() function?

+1 for time.steady(strict=False).


On Wed, Mar 14, 2012 at 7:09 PM, Kristján Valur Jónsson  
wrote:
>> - By default, it should fall back to time.time if a better source is
>>  not available, but there should be a flag that can disable this
>>  fallback for users who really *need* a monotonic/steady time source.
> As pointed out on a different thread, you don"t need this "flag" since the 
> code can easily enforce the monotonic property by maintaining a static value.
> This is how we worked around buggy implementations of QueryPerformanceCounter 
> on windows ().
> K

That's fine if you just need the clock to be monotonic, but it isn't any help 
if you also want to prevent it from jumping forward.

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/kristjan%40ccpgames.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] Drop the new time.wallclock() function?

[Victor Stinner]

On 14/03/2012 00:57, Victor Stinner wrote:

I added two functions to the time module in Python 3.3: wallclock()
and monotonic(). (...)


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.


I patched the queue and threading modules to use time.steady() instead 
of time.time().


The documentation may need clarification.
http://docs.python.org/dev/library/time.html#time.steady

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] sharing sockets among processes on windows

[Kristján Valur Jónsson]

Great.  I was about to write unittests for my patch, when I found out that I 
wanted to use multiprocessing to run them.
So, I decided that the tests rather belonged in there rather than 
test_socket.py.  This is where I stumbled upon code that multiprocessing uses 
to transfer sockets for unix.  I need to read that code and understand it and 
see if it can be persuaded to magically work on windows too.

K

From: Glyph Lefkowitz [mailto:gl...@twistedmatrix.com]
Sent: 14. mars 2012 17:22
To: Kristján Valur Jónsson
Cc: Python-Dev (python-dev@python.org)
Subject: Re: [Python-Dev] sharing sockets among processes on windows


On Mar 13, 2012, at 5:27 PM, Kristján Valur Jónsson wrote:


Hi,
I´m interested in contributing a patch to duplicate sockets between processes 
on windows.
Tha api to do this is WSADuplicateSocket/WSASocket(), as already used by dup() 
in the _socketmodule.c
Here´s what I have:

Just in case anyone is interested, we also have a ticket for this in Twisted: 
. It would be great to share code as 
much as possible.

-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] SocketServer issues

[Kristján Valur Jónsson]

Fyi:
http://bugs.python.org/issue14307


-Original Message-
From: python-dev-bounces+kristjan=ccpgames@python.org 
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of 
Kristján Valur Jónsson
Sent: 14. mars 2012 12:36
To: Guido van Rossum
Cc: Antoine Pitrou; python-dev@python.org
Subject: Re: [Python-Dev] SocketServer issues

Yes, setting a timeout and leaving it that way is not the same.  But setting 
the timeout for _accept only_ is the "same" except one approach requires the 
check of a bool return, the other the handling of a socket.timeout exeption.
My point is, if sockets already have nice and well defined timeout semantics, 
why not use them, or even improve them (perhaps with an optional timeout 
parameter to the accept call) rather than reimplement them with an explicit 
select.select() call?

Anyway, I'll take another look at the problem and possibly submit a patch 
suggestion.  Thanks.

K

-Original Message-
From: gvanros...@gmail.com [mailto:gvanros...@gmail.com] On Behalf Of Guido van 
Rossum
Sent: 14. mars 2012 11:44
To: Kristján Valur Jónsson
Cc: Antoine Pitrou; python-dev@python.org
Subject: Re: [Python-Dev] SocketServer issues

2012/3/14 Kristján Valur Jónsson :
> Maybe this is all just nonsense, still it seems odd to jump through extra 
> hoops to emulate a functionality that is already supported by the socket 
> spec, and can be done in the most appropriate way for each implementation.

I thought I had already explained why setting the timeout on the socket is not 
the same.

--
--Guido van Rossum (python.org/~guido)


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

[Victor Stinner]

> I merged the two functions into one function: time.steady(strict=False).

I opened the issue #14309 to deprecate time.clock():
http://bugs.python.org/issue14309

time.clock() is a different clock type depending on the OS (Windows vs
UNIX) and so is confusing. You should now decide between time.time()
and time.steady().

time.time():

 - known starting point, Epoch (1970.1.1)
 - may be update by the system (and so go backward or forward)

=> display time to the user, compare/set file modification time

time.steady():

 - unknown starting point
 - more accurate than time.time()
 - should be monotonic (use strict=True if you want to be sure ;-))

=> benchmark, timeout

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] [Python-checkins] cpython: PEP 417: Adding unittest.mock

[Kristján Valur Jónsson]

Fyi:
http://bugs.python.org/issue14310


-Original Message-
From: python-dev-bounces+kristjan=ccpgames@python.org 
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of 
Michael Foord
Sent: 14. mars 2012 14:42
To: Terry Reedy
Cc: python-dev@python.org
Subject: Re: [Python-Dev] [Python-checkins] cpython: PEP 417: Adding 
unittest.mock


On 14 Mar 2012, at 13:46, Terry Reedy wrote:

> On 3/14/2012 4:22 PM, Michael Foord wrote:
>> 
>> On 14 Mar 2012, at 13:08, Terry Reedy wrote:
>> 
>>> On 3/14/2012 3:25 PM, michael.foord wrote:
 +# mock.py +# Test tools for mocking and patching.
> 
>>> Should there be a note here about restrictions on editing this
>>> file? I notice that there are things like
>>> 
 +class OldStyleClass: +pass +ClassType = type(OldStyleClass)
>>> 
>>> which are only present for running under Py2 and which would
>>> normally be removed for Py3.
>> 
>> 
>> Yeah, I removed as much of the Python 2 compatibility code and
>> thought I'd got it all. Thanks for pointing it out.
> 
> 2000 lines is a lot to check through.
>> 
>> I'm maintaining a "clean" (no Python 2 compatibility code) version in
>> the standard library.
> 
> Great. Here is something else, which is why I thought otherwise ;-).
> 
> +def _instance_callable(obj):
> +"""Given an object, return True if the object is callable.
> +For classes, return True if instances would be callable."""
> +if not isinstance(obj, type):
> +# already an instance
> +return getattr(obj, '__call__', None) is not None
> +
> +klass = obj
> +# uses __bases__ instead of __mro__ so that we work with
> >>>  old style classes
> +if klass.__dict__.get('__call__') is not None:
> +return True
> +
> +for base in klass.__bases__:
> +if _instance_callable(base):
> +return True
> +return False
> 
> If you want to leave the code as is, remove or revise the comment.

Thanks very much for finding these, I'm pretty sure I've fixed all the ones you 
reported - and one more case where try...except...finally can now be used.

All the best,

Michael Foord


> 
>> I'll be maintaining mock, so I'd like to be
>> assigned any issues on it and at least talked to before changes are
>> made. I am maintaining a backport still, but the Python standard
>> library version is the canonical version.
> 
> Add unittest.mock to devguide/experts.rst and yourself with * appended.
> 
> ---
> Searching for 'old', I also found
> 
> +def _must_skip(spec, entry, is_type):
> +if not isinstance(spec, type):
> +if entry in getattr(spec, '__dict__', {}):
> +# instance attribute - shouldn't skip
> +return False
> >>>+# can't use type because of old style classes
> +spec = spec.__class__
> +if not hasattr(spec, '__mro__'):
> >>>+# old style class: can't have descriptors anyway
> +return is_type
> 
> In testcallable.py
> +def test_patch_spec_callable_class(self):
> +class CallableX(X):
> +def __call__(self):
> +pass
> +
> +class Sub(CallableX):
> +pass
> +
> +class Multi(SomeClass, Sub):
> +pass
> +
> >>>+class OldStyle:
> +def __call__(self):
> +pass
> +
> >>>+class OldStyleSub(OldStyle):
> +pass
> +
> +for arg in 'spec', 'spec_set':
> >>>+for Klass in CallableX, Sub, Multi, OldStyle, OldStyleSub:
> 
> This is the last.
> 
> -- 
> 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/fuzzyman%40voidspace.org.uk
> 


--
http://www.voidspace.org.uk/


May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing 
http://www.sqlite.org/different.html





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

[Matt Joiner]

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

Non monotonicity of this call should be considered a bug. Strict would be
used for profiling where forward leaps would disqualify the timing.
___
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] 2012 Language Summit Report (updated, included here)

[Brian Curtin]

After a few comments and corrections, including one to post the report
directly here...what follows below is the text of what was updated on
the previously linked blog post[0].

Much of the changes were to add more detail from a few people. One
correction lies in the importlib discussion, in that I previously
mentioned the effect on explicit relative imports. This was incorrect:
it should have said *implicit* relative imports.

[0] http://blog.python.org/2012/03/2012-language-summit-report.html


=
 2012 Language Summit Report
=

This year's Language Summit took place on Wednesday March 7 in Santa Clara,
CA before the start of `PyCon 2012`_. As with previous years, in attendance
were members of the various Python VMs, packagers from various Linux
distributions, and members of several community projects.

The Namespace PEPs
==

The summit began with a discussion on PEPs `382`_ and `402`_, with
Barry Warsaw leading much of the discussion. After some discussion, the
decision was ultimately deferred with what appeared to be a want for parts of
both PEPs.

As of Monday at the PyCon sprints, both PEPs have been rejected (see the
Rejection Notice at the top of each PEP). Martin von Loewis `posted to the
import-sig list`_ that a resolution has been found and Eric Smith will draft
a new PEP on the ideas agreed upon there. Effectively, PEP 382 has been
outright rejected, while portions of PEP 402 will be accepted.

``importlib`` Status


Brett Cannon announced that there is a completed and available branch of
CPython using importlib at
`http://hg.python.org/sandbox/bcannon/
`_.
See the ``bootstrap_importlib`` named branch.

Discussion began by outlining the only real existing issue, which lies in
``stat``'ing of directories. There's a minor backwards incompatibility issue
with time granularity. However, everyone agreed that it's so unlikely to
be of issue that it's not a showstopper and the work can move forward.
Additionally, there was an optimization made around the ``stat`` calls, which
was arrived at independently by each of Brett, Antoine Pitrou, and P.J. Eby.

The topic of performance came up and Brett explained that the current
pure-Python implementation is around 5% slower. Thomas Wouters exclaimed that
5% slower is actually really good, especially given some recent benchmark
work he was doing showing that changing compilers sometimes shows a 5%
difference in startup time. There was a shared feeling that 5% slower was not
something to hold up integration of the code, which pushed discussion
happily along.

Brett went on to explain what the bootstrapping actually looks like, even
asserting that the implementation finds what could be the first *real* use of
frozen modules! Guido's first response was, "you mean to tell me that after
20 years we finally found a use for freezing code?"

``importlib._bootstrap`` is a frozen module containing the
necessary builtins to operate, along with some re-implementations of a small
number of functions. Some of the libraries included in the frozen module are
``warnings``, ``_os`` (select code from ``posix``), and ``marshal``.

Another compatibility issue was brought up, but again, was decided to be an
issue unworthy of halting the progress on this issue. There's a negative
level count which is not supported in ``importlib``, used in implicit
relative imports, and it was agreed that it's acceptable to continue not
supporting it.

The future will likely result in a strip down of ``import.c``, as well as
the exposure of numerous hooks as well as exposure of much of the
``importlib`` API.

As for merging with the ``default`` branch, it was pretty universally agreed
upon that this should happen for 3.3 and it should happen soon in order to
get mileage on the implementation throughout the alpha and beta cycles.
Since this will be happening shortly, Brett is going to follow-up to
python-dev with some cleanup details and look for reviews.

Release Schedule PEPs
=

Discussion on PEPs `407`_ and `413`_ followed the ``importlib`` talk. Like
the namespace PEP discussion, several ideas were tossed around but the group
didn't arrive at any conclusion on acceptability of the PEPs.

Immediately, the idea of splitting out the standard library to be on its own
was resurrected, which could lend itself to both PEPs. Some questions
remain, namely in where would the test suite live. Additionally, there may
need to be some distinction between the tests which cover standard libraries
versus the tests which cover language features.

The topic of versioning came up, with three distinctions needing to be made.
We would seem to need a version of the language spec, a version of the
implementation, and a version of the standard library.

Many commenters mentioned that these PEPs make things too complicated.
Additionally, there was a question about whether t

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

[Lennart Regebro]

On Thu, Mar 15, 2012 at 02:58, Matt Joiner  wrote:
> Victor, I think that steady can always be monotonic, there are time sources
> enough to ensure this on the platforms I am aware of. Strict in this sense
> refers to not being adjusted forward, i.e. CLOCK_MONOTONIC vs
> CLOCK_MONOTONIC_RAW.
>
> Non monotonicity of this call should be considered a bug. Strict would be
> used for profiling where forward leaps would disqualify the timing.

This makes sense to me.

//Lennart
___
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