On Fri, Mar 23, 2012 at 4:25 PM, Victor Stinner
wrote:
> Hi,
>
> time.steady(strict=True) looks to be confusing for most people, some
> of them don't understand the purpose of the flag and others don't like
> a flag changing the behaviour of the function.
>
> I propose to replace time.steady(stric
PJ Eby wrote:
Weird - I have the exact *opposite* problem, where I have to resize my
window because somebody *didn't* set their text max-width sanely (to a
reasonable value based on ems instead of pixels), and I have nearly 1920
pixels of raw text spanning my screen.
If you don't want 1920-p
On Fri, Mar 23, 2012 at 18:38, Yury Selivanov wrote:
> On 2012-03-23, at 7:28 PM, Brian Curtin wrote:
>> This seems like it should have been a PEP, or maybe should become a PEP.
>
> Why? AFAIK Victor just proposes to add two new functions: monotonic() and
> steady().
We just previously had "Drop
On Mar 23, 2012 10:21 PM, "PJ Eby" wrote:
>
>
> On Mar 23, 2012 4:19 PM, "VanL" wrote:
> >
> > Three notes. FIrst, distutils.cfg doesn't always work because it is
centered around the idea of set paths that are the same each time - which
doesn't always work with virtualenvs.
>
> And the virtualenv
On Mar 23, 2012 9:16 PM, "Greg Ewing" wrote:
>
> Glyph Lefkowitz wrote:
>
>> "do I have to resize my browser every time I visit a new site to get a
decent width for reading".
>
>
> If all sites left the width to the browser, then I would
> be able to make my browser window a width that is comforta
On Mar 23, 2012 3:53 PM, "Carl Meyer" wrote:
>
> Hi PJ,
>
> On 03/23/2012 12:35 PM, PJ Eby wrote:
> > AFAICT, virtualenvs are overkill for most development anyway. If you're
> > not using distutils except to install dependencies, then configure
> > distutils to install scripts and libraries to th
On Mar 23, 2012 4:19 PM, "VanL" wrote:
>
> Three notes. FIrst, distutils.cfg doesn't always work because it is
centered around the idea of set paths that are the same each time - which
doesn't always work with virtualenvs.
And the virtualenv doesn't contain its own copy of distutils.cfg?
> Secon
In http://mail.python.org/pipermail/python-dev/2012-March/118024.html
Steven D'Aprano wrote:
> What makes this "steady", given that it can be adjusted
> and it can go backwards?
It is best-effort for steady, but putting "best" in the name would
be an attractive nuisance.
> Is steady() merely a
Victor Stinner wrote:
- time.clock(): monotonic clock on Windows, CPU time on UNIX
Actually, I think that is not correct. Or at least *was* not correct in
2006.
http://bytes.com/topic/python/answers/527849-time-clock-going-backwards
Oh, I was not aware of this issue. Do you suggest to not us
On 3/23/2012 7:25 PM, Victor Stinner wrote:
[snip]
- time.monotonic(): monotonic clock, its speed may or may not be
adjusted by NTP but it only goes forward, may raise an OSError
- time.steady(): monotonic clock or the realtime clock, depending on
what is available on the platform (use monotonic
Victor Stinner wrote:
Is steady() merely a convenience function to avoid the user having
to write something like this?
steady() remembers if the last call to monotonic failed or not. The
real implementation is closer to something like:
def steady():
if not steady.has_monotonic:
return t
Glyph Lefkowitz wrote:
"do I have to resize my browser every time I visit a new site to get a
decent width for reading".
If all sites left the width to the browser, then I would
be able to make my browser window a width that is comfortable
for me with my chosen font size and leave it that way.
>> - time.clock(): monotonic clock on Windows, CPU time on UNIX
>
>
> Actually, I think that is not correct. Or at least *was* not correct in
> 2006.
>
> http://bytes.com/topic/python/answers/527849-time-clock-going-backwards
Oh, I was not aware of this issue. Do you suggest to not use
QueryPerfor
> Question: under what circumstances will monotonic() exist but raise OSError?
On Windows, OSError is raised if QueryPerformanceFrequency fails.
Extract of Microsoft doc:
"If the function fails, the return value is zero. To get extended
error information, call GetLastError. For example, if the in
Victor Stinner wrote:
- time.clock(): monotonic clock on Windows, CPU time on UNIX
Actually, I think that is not correct. Or at least *was* not correct in 2006.
http://bytes.com/topic/python/answers/527849-time-clock-going-backwards
--
Steven
_
Victor Stinner wrote:
[...]
So we will have:
- time.time(): realtime, can be adjusted by the system administrator
(manually) or automatically by NTP
- time.clock(): monotonic clock on Windows, CPU time on UNIX
- time.monotonic(): monotonic clock, its speed may or may not be
adjusted by NTP but i
>> time.steady() is something like:
>>
>> try:
>> return time.monotonic()
>> except (NotImplementError, OSError):
>> return time.time()
>
> Is the use of weak monotonic time so wide-spread in the stdlib that we
> need the 'steady()' function? If it's just two modules then it's not
> worth adding
On 2012-03-23, at 7:25 PM, Victor Stinner wrote:
> - time.steady(): monotonic clock or the realtime clock, depending on
> what is available on the platform (use monotonic in priority). may be
> adjusted by NTP or the system administrator, may go backward.
>
> time.steady() is something like:
>
>
On 2012-03-23, at 7:28 PM, Brian Curtin wrote:
> This seems like it should have been a PEP, or maybe should become a PEP.
Why? AFAIK Victor just proposes to add two new functions: monotonic() and
steady().
time() and clock() do already exist and won't be changed.
-
Yury
> This seems like it should have been a PEP, or maybe should become a PEP.
I replaced time.wallclock() by time.steady(strict=False) and
time.monotonic() by time.steady(strict=True). This change solved the
naming issue of time.wallclock(), but it was a bad idea to merge
monotonic() feature into tim
On Mar 23, 2012 6:25 PM, "Victor Stinner" wrote:
>
> Hi,
>
> time.steady(strict=True) looks to be confusing for most people, some
> of them don't understand the purpose of the flag and others don't like
> a flag changing the behaviour of the function.
>
> I propose to replace time.steady(strict=Tr
Hi,
time.steady(strict=True) looks to be confusing for most people, some
of them don't understand the purpose of the flag and others don't like
a flag changing the behaviour of the function.
I propose to replace time.steady(strict=True) by time.monotonic().
That would avoid the need of an ugly No
On 2012-03-23, at 7:07 PM, Victor Stinner wrote:
> 2012/3/23 Yury Selivanov :
>> Why can't I use select & threads? You mean that if a platform does not
>> support monotonic clocks it also does not support threads and select sys
>> call?
>
> Python 3.3 now uses time.steady(strict=False) in the th
2012/3/23 Yury Selivanov :
> Why can't I use select & threads? You mean that if a platform does not
> support monotonic clocks it also does not support threads and select sys
> call?
Python 3.3 now uses time.steady(strict=False) in the threading and
queue modules. If we replace it by time.steady(
Yes, call it what it is. monotonic or monotonic_time, because that's why
I'm using it. No flags.
I've followed this thread throughout, and I'm still not sure if "steady"
gives the real guarantees it claims. It's trying to be too much. Existing
bugs complain about backward jumps and demand a clock
On 2012-03-23, at 1:27 PM, Victor Stinner wrote:
>> I want time.steady(strict=True), and I'm glad you're providing it and
>> I'm willing to use it this way, although it is slightly annoying
>> because "time.steady(strict=True)" really means
>> "time.steady(i_really_mean_it=True)". Else, I would ha
On 2012-03-23, at 4:40 PM, Glyph wrote:
> (I still object to the "time.steady" naming, because this is what people in
> the make-believe land of C++ call it. The people who live in the real world
> of C and POSIX all refer to it as "monotonic". And even the C++ purists slip
> up sometimes, c.f
On Fri, Mar 23, 2012 at 3:46 PM, Glyph wrote:
> On Mar 23, 2012, at 1:26 PM, Brad Allen wrote:
>
> Thanks, Glyph. In that case maybe the Python subprocess docs need not
> single out SystemRoot, but instead plaster a big warning around the
> use of the 'env' parameter.
>
>
> I agree. I'm glad that
On 23 March 2012 20:40, Glyph wrote:
> I am increasingly thinking that the first order of business here should be
> to expose the platform-specific mechanisms directly, then try to come up
> with a unifying abstraction in the time module later.
+1.
Paul
__
On Mar 23, 2012, at 1:26 PM, Brad Allen wrote:
> Thanks, Glyph. In that case maybe the Python subprocess docs need not
> single out SystemRoot, but instead plaster a big warning around the
> use of the 'env' parameter.
I agree. I'm glad that my bitter experience here might be useful to someone i
On Mar 23, 2012, at 12:55 PM, Zooko Wilcox-O'Hearn wrote:
>> I merged the two functions into one function: time.steady(strict=False).
>>
>> time.steady() should be monotonic most of the time, but may use a fallback.
>>
>> time.steady(strict=True) fails with OSError or NotImplementedError if
>>
Jim J. Jewett wrote:
> Passing strict as an argument seems like overkill since it will always
> be meaningless on some (most?) platforms.
A keyword argument that gets passed as a constant in the caller is
usually poor API. Why not have two different functions?
Neil
__
On Friday, March 23, 2012 at 1:35 PM, PJ Eby wrote:
> Tool developers are going "meh" about your proposal because it doesn't
> actually solve any problems for them: they still have to support the old
> layout, and if their code already uses distutils' facilities for obtaining
> paths, there's
Hi PJ,
On 03/23/2012 12:35 PM, PJ Eby wrote:
> AFAICT, virtualenvs are overkill for most development anyway. If you're
> not using distutils except to install dependencies, then configure
> distutils to install scripts and libraries to the same directory, and
> then do all your development in tha
On Mar 23, 2012 1:37 PM, "VanL" wrote:
>
> On Friday, March 23, 2012 at 11:39 AM, PJ Eby wrote:
>>
>> Even if you are using tools that don't use distutils' configuration
settings for these directories, why not simply fix those tools so that they
do?
>
>
> Thats what I do currently - I set things t
What does this verify?
My assumption from the name (test_quick_connect) and the context (an
asynchronous server) is that it is verifying the server can handle a
certain level of load. Refusing the sockets should then be a failure,
or at least a skipped test.
Would the below fail even if asyncore
On Fri, Mar 23, 2012 at 2:37 PM, Paul Moore wrote:
> Another problem case: cx_Freeze. This currently breaks when installed
> in a viretualenv, as it locates the "Scripts" directory by appending
> "Scripts" to the directory of the python executable.
>
> So the proposed change *will* break cx_Freez
On Friday, March 23, 2012 at 11:39 AM, PJ Eby wrote:
> Even if you are using tools that don't use distutils' configuration settings
> for these directories, why not simply fix those tools so that they do?
Thats what I do currently - I set things to bin and patch Python and the tools
so that th
On Thu, Mar 22, 2012 at 2:35 PM, Glyph Lefkowitz
wrote:
> Also, in order to execute in any installation environment where libraries are
> found in non-default locations, you will need to set LD_LIBRARY_PATH. Oh,
> and you will also need to set $PATH on UNIX so that libraries can find their
>
> I want time.steady(strict=True), and I'm glad you're providing it and
> I'm willing to use it this way, although it is slightly annoying
> because "time.steady(strict=True)" really means
> "time.steady(i_really_mean_it=True)". Else, I would have used
> "time.time()".
>
> I am aware of a large num
ACTIVITY SUMMARY (2012-03-16 - 2012-03-23)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open3346 ( +9)
closed 22829 (+50)
total 26175 (+59)
Open issues wit
> 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 avail
On Mar 22, 2012 2:57 PM, "VanL" wrote:
> That said, while I think that the above is a good idea, my personal
ambitions are more modest: If the names of the top-level directories only
were changed to 'bin', 'lib', and 'include' - never mind differences under
'lib' - I would be happy. In fact, even
On 22 March 2012 23:15, VanL wrote:
> Another use case was just pointed out to me: making things consistent with
> buildout. Given a similar use
> case (create repeatable cross platform environments), they create and use a
> 'bin' directory for executable files.
Another problem case: cx_Freeze.
Antoine Pitrou wrote:
> > On the web side, there seems to be a huge interest in speeding up database
> > accesses, so let me evangelize again: Database applications using decimal
> > will run 12x faster in 3.3.
>
> Are you sure it isn't 12.5x ?
Well, that was marketing for 3.3.
Stefan Krah
_
On Fri, 23 Mar 2012 13:48:30 +1000
Nick Coghlan wrote:
> I'm looking into getting a RHEL6 system set up to add to the buildbot
> fleet. The info already on the wiki [1] is pretty helpful, but does
> anyone have any suggestions on appropriate CPU/memory/disk
> allocations?
One or two cores is enou
On Thu, 22 Mar 2012 17:13:27 -0400
Terry Reedy wrote:
> My impression is that the original reason for PendingDeprecationWarning
> versus DeprecationWarning was to be off by default until the last
> release before removal. But having DeprecationWarnings on by default was
> found to be too obnoxi
On Fri, 23 Mar 2012 10:22:55 +0100
Stefan Krah wrote:
> Georg Brandl wrote:
> > >>> Issue #7652: Integrate the decimal floating point libmpdec library to
> > >>> speed
> > >>> up the decimal module. Performance gains of the new C implementation are
> > >>> between 12x and 80x, depending on the
On 23/03/2012 7:10 PM, Paul Moore wrote:
On 23 March 2012 03:20, Brian Curtin wrote:
Breakage of existing tools: Mark Hammond, Paul Moore, and Tim Golden have
all expressed that they have existing tools that would break and would need
to be adjusted to match the new location of the python.exe,
VanL wrote:
> As this has been brought up a couple times in this subthread, I figured that
> I would lay out the
> rationale here.
>
> There are two proposals on the table: 1) Regularize the install layout, and
> 2) move the python
> binary to the binaries directory. This email will deal with
Victor Stinner wrote:
> By the way, how much faster is cdecimal? 72x or 80x?
> http://docs.python.org/dev/whatsnew/3.3.html#decimal
It really depends on the precision. Also, the performance of decimal.py
depends on many other things in the Python tree, so it easily changes
+-10%. Currently, decim
Hello,
PEP 411 -- Provisional packages in the Python standard library
Has been updated with all accumulated feedback from list discussions.
Here it is: http://www.python.org/dev/peps/pep-0411/ (the text is also
pasted in the bottom of this email).
The PEP received mostly positive feedback. The o
Amaury Forgeot d'Arc wrote:
> > Seconded. ?This is the kind of stuff that will make 3.3 the most awesomest
> > 3.x release ever (and hopefully convince people that it does make sense to
> > port)...
>
> On the other hand, porting PyPy to 3.3 will be more work ;-)
We've got to keep you on your to
By the way, how much faster is cdecimal? 72x or 80x?
http://docs.python.org/dev/whatsnew/3.3.html#decimal
Victor
2012/3/23 Stefan Krah :
> Georg Brandl wrote:
>> >>> Issue #7652: Integrate the decimal floating point libmpdec library to
>> >>> speed
>> >>> up the decimal module. Performance gai
Georg Brandl wrote:
> >>> Issue #7652: Integrate the decimal floating point libmpdec library to
> >>> speed
> >>> up the decimal module. Performance gains of the new C implementation are
> >>> between 12x and 80x, depending on the application.
> >
> > Congrats Stefan! And thanks for the huge ch
On Fri, Mar 23, 2012 at 09:26, Stefan Krah wrote:
> I'll add the --with-system-libmpdec option with the caveat that
> changes will probably make it first into the libmpdec shipped
> with Python, see also:
>
> http://bugs.python.org/issue7652#msg155744
Sounds good, thanks!
Cheers,
Dirkjan
__
Dirkjan Ochtman wrote:
> As a packager, is the libmpdec library used elsewhere? For Gentoo, we
> generally prefer to package libraries separately and have Python
> depend on them. From the site, it seems like you more or less wrote
> libmpdec for usage in Python, but if it's general-purpose and ac
On 23 March 2012 03:20, Brian Curtin wrote:
>> Breakage of existing tools: Mark Hammond, Paul Moore, and Tim Golden have
>> all expressed that they have existing tools that would break and would need
>> to be adjusted to match the new location of the python.exe, because that
>> location is assumed
Nick Coghlan wrote:
> I'm looking into getting a RHEL6 system set up to add to the buildbot
> fleet. The info already on the wiki [1] is pretty helpful, but does
> anyone have any suggestions on appropriate CPU/memory/disk
> allocations?
The Fedora bot has been running ultra-stable under qemu wit
59 matches
Mail list logo
