-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.
>
>
-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
> wrote:
>> If you can solve your problem with a suitably hacked Unpickler
>> subclass that's fine with me, but I would personally use this
>> opportunit
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 D'Aprano" wrote
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
>
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 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.
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 ex
Terry Reedy wrote:
On 3/15/2012 5:27 PM, Alexander Belopolsky wrote:
On Thu, Mar 15, 2012 at 3:55 PM, Matt Joiner 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
On 3/15/2012 5:27 PM, Alexander Belopolsky wrote:
On Thu, Mar 15, 2012 at 3:55 PM, Matt Joiner 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 a function of a modu
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/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 environments
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 wi
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 neighborin
On Thu, Mar 15, 2012 at 3:55 PM, Matt Joiner 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.
___
Pytho
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?
___
2012/3/15 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.
Sounds okay to me.
--
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.
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 wrote:
> 2012/3/15 Gil Colgate :
> > We use a lot of UnsignedLongLongs in our program (ids) and have been
> par
+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, 2
In article
,
Kristján Valur Jónsson 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, i.e. its precision becomes worse. On average it is still correct.
> Look at the
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:
2012/3/15 Gil Colgate :
> 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 at 11:49 AM, Ben
2012/3/15 Gil Colgate :
> 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
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 cor
2012/3/15 Georg Brandl :
> 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.klose wrote:
http://hg.python.org/cpython/rev/55ab7a272f0a
changeset: 75659:55ab7a272f0a
branch
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.klose wrote:
http://hg.python.org/cpython/rev/55ab7a272f0a
changeset: 75659:55ab7a272f0a
branch: 3.1
parent: 75199:df3b2b5db900
user:Mat
On 15.03.2012 11:31, Antoine Pitrou wrote:
On Wed, 14 Mar 2012 23:27:24 +0100
matthias.klose wrote:
http://hg.python.org/cpython/rev/55ab7a272f0a
changeset: 75659:55ab7a272f0a
branch: 3.1
parent: 75199:df3b2b5db900
user:Matthias Klose
date:Wed Mar 14 23:10:15 2012 +0
On 15 March 2012 12:12, Nadeem Vawda wrote:
> On Thu, Mar 15, 2012 at 1:10 PM, Paul Moore 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 returns 13345. Is that because 100 tick
On Thu, Mar 15, 2012 at 1:10 PM, Paul Moore 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 returns
> 12345. T
On 15 March 2012 10:06, Matt Joiner 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 based, and m
On Wed, 14 Mar 2012 23:27:24 +0100
matthias.klose wrote:
> http://hg.python.org/cpython/rev/55ab7a272f0a
> changeset: 75659:55ab7a272f0a
> branch: 3.1
> parent: 75199:df3b2b5db900
> user:Matthias Klose
> date:Wed Mar 14 23:10:15 2012 +0100
> summary:
> - rename confi
On Mar 15, 2012 4:23 PM, "Paul Moore" wrote:
>
> On 15 March 2012 01: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.
2012/3/15 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.
I don't think that CLOCK_MONOTON
On 15 March 2012 01: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.
I agree - Kr
33 matches
Mail list logo
