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.
>
> No
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
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
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: [P
> 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.ti
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-
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
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.stead
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 ce
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
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 (whil
[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 co
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 location
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 Pyth
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 restric
+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
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
+
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
+
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
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
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:
> > +
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
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
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
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 | 215
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
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
thin
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 th
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
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
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 fret
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 n
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;
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 so
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=
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/archiv
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
+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 sh
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
>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 ex
> - 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 easi
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:
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.
>
>
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
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 c
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 dis
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
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
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 po
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-d
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
> 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 pa
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
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
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 imperfe
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
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
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
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 sea
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
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
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
s
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_s
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 differ
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 socketserv
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
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/user
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/2
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*,
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 t
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
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 (w
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 emphas
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 li
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 re
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 poin
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
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 d
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/py
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
> NotImplementedE
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 belie
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 ThreadingM
82 matches
Mail list logo
