On 15 March 2012 01:58, Matt Joiner anacro...@gmail.com wrote:
Victor, I think that steady can always be monotonic, there are time sources
enough to ensure this on the platforms I am aware of. Strict in this sense
refers to not being adjusted forward, i.e. CLOCK_MONOTONIC vs
2012/3/15 Matt Joiner anacro...@gmail.com:
Victor, I think that steady can always be monotonic, there are time sources
enough to ensure this on the platforms I am aware of. Strict in this sense
refers to not being adjusted forward, i.e. CLOCK_MONOTONIC vs
CLOCK_MONOTONIC_RAW.
I don't think
On Mar 15, 2012 4:23 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 15 March 2012 01:58, Matt Joiner anacro...@gmail.com wrote:
Victor, I think that steady can always be monotonic, there are time
sources
enough to ensure this on the platforms I am aware of. Strict in this
sense
refers to not
On Wed, 14 Mar 2012 23:27:24 +0100
matthias.klose python-check...@python.org wrote:
http://hg.python.org/cpython/rev/55ab7a272f0a
changeset: 75659:55ab7a272f0a
branch: 3.1
parent: 75199:df3b2b5db900
user:Matthias Klose d...@ubuntu.com
date:Wed Mar 14 23:10:15 2012
On 15 March 2012 10:06, Matt Joiner anacro...@gmail.com wrote:
I'm baffled as to how you even identify forward leaps. In relation
to what? A more accurate time source? I thought that by definition
this was the most accurate time source we have!
Monotonic clocks are not necessarily hardware
On Thu, Mar 15, 2012 at 1:10 PM, Paul Moore p.f.mo...@gmail.com wrote:
Monotonic clocks are not necessarily hardware based, and may be adjusted
forward by NTP.
I appreciate that. But I'm still unclear how you would tell that had
happened as part of the implementation. One call to the OS
On 15 March 2012 12:12, Nadeem Vawda nadeem.va...@gmail.com wrote:
On Thu, Mar 15, 2012 at 1:10 PM, Paul Moore p.f.mo...@gmail.com wrote:
I appreciate that. But I'm still unclear how you would tell that had
happened as part of the implementation. One call to the OS returns
12345. The next
On 15.03.2012 11:31, Antoine Pitrou wrote:
On Wed, 14 Mar 2012 23:27:24 +0100
matthias.klosepython-check...@python.org wrote:
http://hg.python.org/cpython/rev/55ab7a272f0a
changeset: 75659:55ab7a272f0a
branch: 3.1
parent: 75199:df3b2b5db900
user:Matthias
On 15.03.2012 17:33, Matthias Klose wrote:
On 15.03.2012 11:31, Antoine Pitrou wrote:
On Wed, 14 Mar 2012 23:27:24 +0100
matthias.klosepython-check...@python.org wrote:
http://hg.python.org/cpython/rev/55ab7a272f0a
changeset: 75659:55ab7a272f0a
branch: 3.1
parent:
2012/3/15 Georg Brandl g.bra...@gmx.net:
On 15.03.2012 17:33, Matthias Klose wrote:
On 15.03.2012 11:31, Antoine Pitrou wrote:
On Wed, 14 Mar 2012 23:27:24 +0100
matthias.klosepython-check...@python.org wrote:
http://hg.python.org/cpython/rev/55ab7a272f0a
changeset:
We use a lot of UnsignedLongLongs in our program (ids) and have been
parsing in PyArg_ParseTuple with 'K', which does not do error checking.
I am planning to add a new type to our local build of python for parsing
Unsigned Long Longs (64 bit numbers) that errrors if the number has more
than the
2012/3/15 Gil Colgate gcolg...@gmail.com:
We use a lot of UnsignedLongLongs in our program (ids) and have been parsing
in PyArg_ParseTuple with 'K', which does not do error checking.
I am planning to add a new type to our local build of python for parsing
Unsigned Long Longs (64 bit numbers)
2012/3/15 Gil Colgate gcolg...@gmail.com:
I must be using a different version of python, (3.2), I don't see that one
in use. Do you have a different suggestion?
It's not used in PyArg_Parse*, but it is for Py_BuildValue. Adding it
to PyArg_Parse could create confusion.
On Thu, Mar 15, 2012
The lzma module ran into a similar issue with 32-bit unsigned ints.
I worked around it by writing a custom converter function to use
with the O code.
You can find the converter definition here:
http://hg.python.org/cpython/file/default/Modules/_lzmamodule.c#l134
And an example usage here:
In article
efe3877620384242a686d52278b7ccd3362...@rkv-it-exch104.ccp.ad.local,
Kristján Valur Jónsson krist...@ccpgames.com wrote:
What does jumping forward mean? That's what happens with every clock at
every time quantum. The only effect here is that this clock will be slightly
noisy,
+1. I now prefer time.monotonic(), no flags. It attempts to be as high
precision as possible and guarantees never to jump backwards. Russell's
comment is right, the only steady sources are from hardware, and these are
too equipment and operating system specific. (For this call anyway).
On Mar 16,
How about 'G'? (Giant, or perhaps gynormous, integer?)
Then I could also map 'g' to the signed version (same as L) for consistency.
On Thu, Mar 15, 2012 at 11:49 AM, Benjamin Peterson benja...@python.orgwrote:
2012/3/15 Gil Colgate gcolg...@gmail.com:
We use a lot of UnsignedLongLongs in
2012/3/15 Gil Colgate gcolg...@gmail.com:
How about 'G'? (Giant, or perhaps gynormous, integer?)
Then I could also map 'g' to the signed version (same as L) for consistency.
Sounds okay to me.
--
Regards,
Benjamin
___
Python-Dev mailing list
15.03.12 21:59, Gil Colgate написав(ла):
How about 'G'? (Giant, or perhaps gynormous, integer?)
Then I could also map 'g' to the signed version (same as L) for consistency.
What about unsigned char, short, int, and long with overflow checking?
___
On Thu, Mar 15, 2012 at 3:55 PM, Matt Joiner anacro...@gmail.com wrote:
+1. I now prefer time.monotonic(), no flags.
Am I alone thinking that an adjective is an odd choice for a function
name? I think monotonic_clock or monotonic_time would be a better
option.
15.03.12 21:59, Gil Colgate написав(ла):
How about 'G'? (Giant, or perhaps gynormous, integer?)
Then I could also map 'g' to the signed version (same as L) for consistency.
For consistency 'g' must be `unsigned long` with overflow checking.
And how about 'M'? 'K', 'L', and 'M' are
A brief status update on PEP 405 (built-in virtualenv) and the open issues:
1. As mentioned in the updated version of the language summit notes,
Nick Coghlan has agreed to pronounce on the PEP.
2. Ned Deily discovered at the PyCon sprints that the current reference
implementation does not work
On 3/14/2012 6:30 PM, Mark Hammond wrote:
So why not just standardize on that new layout for virtualenvs?
That sounds like the worst of all worlds - keep all the existing special
cases, and add one.
The fact is that most code doesn't know about this, only installers or
virtual
On 03/15/2012 03:02 PM, Lindberg, Van wrote:
FYI, the location of the tcl/tk libraries does not appear to be set in
the virtualenv, even if tkinter is installed and working in the main
Python installation. As a result, tk-based apps will not run from a
virtualenv.
Thanks for the report!
On 3/15/2012 5:27 PM, Alexander Belopolsky wrote:
On Thu, Mar 15, 2012 at 3:55 PM, Matt Joineranacro...@gmail.com wrote:
+1. I now prefer time.monotonic(), no flags.
Am I alone thinking that an adjective is an odd choice for a function
name?
I would normally agree, but in this case, it is
Terry Reedy wrote:
On 3/15/2012 5:27 PM, Alexander Belopolsky wrote:
On Thu, Mar 15, 2012 at 3:55 PM, Matt Joineranacro...@gmail.com wrote:
+1. I now prefer time.monotonic(), no flags.
Am I alone thinking that an adjective is an odd choice for a function
name?
I would normally agree, but
On 16/03/2012 8:57 AM, VanL wrote:
On 3/14/2012 6:30 PM, Mark Hammond wrote:
So why not just standardize on that new layout for virtualenvs?
That sounds like the worst of all worlds - keep all the existing special
cases, and add one.
I'm not so sure. My concern is that this *will* break
On 03/15/2012 04:19 PM, Mark Hammond wrote:
On 16/03/2012 8:57 AM, VanL wrote:
On 3/14/2012 6:30 PM, Mark Hammond wrote:
So why not just standardize on that new layout for virtualenvs?
That sounds like the worst of all worlds - keep all the existing special
cases, and add one.
I'm not so
On 16/03/2012 10:48 AM, Carl Meyer wrote:
...
The implementation of virtualenv (and especially PEP 405 pyvenv) are
largely based around making sure that the internal layout of a
virtualenv is identical to the layout of an installed Python on that
same platform, to avoid any need to special-case
On 03/15/2012 05:10 PM, Mark Hammond wrote:
On 16/03/2012 10:48 AM, Carl Meyer wrote:
The implementation of virtualenv (and especially PEP 405 pyvenv) are
largely based around making sure that the internal layout of a
virtualenv is identical to the layout of an installed Python on that
same
Windows also has this albeit course grained and also 32 bit. I don't think
ticks reflects the reason why using the timer is desirable.
monotonic_time seems reasonable, there's no reason to persist short names
when users can import it how they like.
On Mar 16, 2012 7:20 AM, Steven Dapos;Aprano
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/13/2012 06:49 PM, Nick Coghlan wrote:
On Wed, Mar 14, 2012 at 8:08 AM, Guido van Rossum gu...@python.org
wrote:
If you can solve your problem with a suitably hacked Unpickler
subclass that's fine with me, but I would personally use this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/15/2012 05:43 PM, Carl Meyer wrote:
A brief status update on PEP 405 (built-in virtualenv) and the open
issues:
1. As mentioned in the updated version of the language summit notes,
Nick Coghlan has agreed to pronounce on the PEP.
2.
33 matches
Mail list logo
