To quote:
"On Unix, return the current processor time as a floating point number
expressed in seconds. The precision, and in fact the very definition of the
meaning of "processor time", depends on that of the C function of the same
name,"
The problem is that it is defined to return "processor
On 14/03/2012 6:43 AM, VanL wrote:
Following up on conversations at PyCon, I want to bring up one of my
personal hobby horses for change in 3.3: Fix install layout on Windows,
with a side order of making the PATH work better.
Short version:
1) The layout for the python root directory for all pl
On Tue, Mar 13, 2012 at 6:10 PM, Nadeem Vawda wrote:
> On Wed, Mar 14, 2012 at 3:03 AM, Victor Stinner
> wrote:
>> I suppose that most libraries and programs will have to implement a
>> similar fallback.
>>
>> We may merge both functions with a flag to be able to disable the
>> fallback. Example:
Thanks for the suggestions.
On Mar 14, 2012 12:03 PM, "Eli Bendersky" 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 lang
On Tue, Mar 13, 2012 at 5:03 PM, Michael Foord
wrote:
>
> On 13 Mar 2012, at 16:57, Victor Stinner wrote:
>
>> Hi,
>>
>> I added two functions to the time module in Python 3.3: wallclock()
>> and monotonic(). I'm unable to explain the difference between these
>> two functions, even if I wrote them
On Wed, 14 Mar 2012 06:03:10 +0200, Eli Bendersky 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
The performancecounter is a thing that typically gets intercepted by
the VM infrastructure and does no longer work as a reliable timing
source. In PyPy there are tests which check certain assumptions
how much the performancecounter must advance at least between
a few opcodes, and that does not wor
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 a
> 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 patch
On Mar 14, 2012 5:27 AM, "Antoine Pitrou" wrote:
>
> On Tue, 13 Mar 2012 14:16:40 -0700
> Guido van Rossum wrote:
>
> > On Tue, Mar 13, 2012 at 12:49 PM, Terry Reedy wrote:
> > > Authors of separately maintained packages are, from our viewpoint, as
> > > eligible to help with tracker issues as a
On 3/13/2012 9:57 PM, VanL wrote:
On Mar 13, 2012, at 8:37 PM, "Martin v. Löwis"
wrote:
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 =
On Mar 13, 2012, at 8:37 PM, "Martin v. Löwis" wrote:
>> 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}/li
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/py
On Tue, Mar 13, 2012 at 6:03 PM, Victor Stinner
wrote:
>> I agree that it's better to have only one of these. I also think if we
>> offer it we should always have it -- if none of the implementations
>> are available, I guess you could fall back on returning time.time(),
>> with some suitable offs
Interesting thought.
Althougn I don't see how that could fail on windows, if the QPC function is
really just talking to a clock chip, surely that hasn't been virtualized.
Is there an actual example of windows hardware where this api fails (virtual or
not?) Perhaps there is no real need to have a
On Tue, Mar 13, 2012 at 5:29 PM, Victor Stinner
wrote:
> I suppose that you can use a manual fallback to time.time() if
> time.monotonic() failed. If time.monotonic() fails, it fails directly at the
> first call. Example of a fallback working with Python < 3.3:
>
> try:
> time.monotonic()
> exce
On Wed, Mar 14, 2012 at 3:03 AM, Victor Stinner
wrote:
> I suppose that most libraries and programs will have to implement a
> similar fallback.
>
> We may merge both functions with a flag to be able to disable the
> fallback. Example:
>
> - time.realtime(): best-effort monotonic, with a fallback
If we need to decide to which function should be kept - I vote for monotonic.
It's extremely useful (even essential) to track timeouts in various schedulers
implementations, for example. Quick search also shows the demand for it, as
there are questions on stackoverflow.com and few packages on PyP
On 3/13/12 5:45 PM, Kristján Valur Jónsson wrote:
The reason I originally suggested "wallclock" was because that term is often used to distinguish time
measurements (delta) that show real world time from those showing CPU or Kernel time. "number.crunch() took 2
seconds wallclock time but only
> I agree that it's better to have only one of these. I also think if we
> offer it we should always have it -- if none of the implementations
> are available, I guess you could fall back on returning time.time(),
> with some suitable offset so people don't think it is always the same.
> Maybe it c
The reason I originally suggested "wallclock" was because that term is often
used to distinguish time measurements (delta) that show real world time from
those showing CPU or Kernel time. "number.crunch() took 2 seconds wallclock
time but only 1 second CPU!". The original problem was that time
On 14/03/2012 01:18, Nadeem Vawda wrote:
So wallclock() falls back to a not-necessarily-monotonic time source
if necessary,
while monotonic() raises an exception in that case? ISTM that these
don't need to
be separate functions - rather, we can have one function that takes a
flag (called
require_
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:
1) Sockets have a method, duplicate(target_pid), that return a bytes
objec
On Tue, Mar 13, 2012 at 4:57 PM, Victor Stinner
wrote:
> I added two functions to the time module in Python 3.3: wallclock()
> and monotonic(). I'm unable to explain the difference between these
> two functions, even if I wrote them :-) wallclock() is suppose to be
> more accurate than time() but
So wallclock() falls back to a not-necessarily-monotonic time source
if necessary,
while monotonic() raises an exception in that case? ISTM that these
don't need to
be separate functions - rather, we can have one function that takes a
flag (called
require_monotonic, or something like that) telling
On 13 Mar 2012, at 16:57, Victor Stinner wrote:
> Hi,
>
> I added two functions to the time module in Python 3.3: wallclock()
> and monotonic(). I'm unable to explain the difference between these
> two functions, even if I wrote them :-) wallclock() is suppose to be
> more accurate than time() b
Hi,
I added two functions to the time module in Python 3.3: wallclock()
and monotonic(). I'm unable to explain the difference between these
two functions, even if I wrote them :-) wallclock() is suppose to be
more accurate than time() but has an unspecified starting point.
monotonic() is similar e
Brian Curtin wrote:
On Tue, Mar 13, 2012 at 14:13, Kenneth Reitz wrote:
I think the cheesehop trove classifiers would be the ideal way to
agnostically link to a page of packages related to the standard package in
question. No need for sort order.
Randomize the order for all I care. We still n
On 3/13/12 4:05 PM, Antoine Pitrou wrote:
On Tue, 13 Mar 2012 22:53:42 +
Kristján Valur Jónsson wrote:
http://bugs.python.org/issue14288
Raymond suggested that this patch should be discussed here, so here goes:
Sounds good on the principle.
Of course, the patch needs to be reviewed.
I a
On Tue, 13 Mar 2012 22:53:42 +
Kristján Valur Jónsson wrote:
> http://bugs.python.org/issue14288
>
> Raymond suggested that this patch should be discussed here, so here goes:
Sounds good on the principle.
Of course, the patch needs to be reviewed.
cheers
Antoine.
2012/3/13 Kristján Valur Jónsson :
> http://bugs.python.org/issue14288
> In my opinion, any objects that have simple and obvious pickle semantics
> should be picklable. Iterators are just regular objects with some state.
> They are not file pointers or sockets or database cursors. And again, I
>
http://bugs.python.org/issue14288
Raymond suggested that this patch should be discussed here, so here goes:
How this came about:
There are frameworks, such as the Nagare web framework,
(http://www.nagare.org/) that rely on suspending execution at some point and
resuming it again. Nagare does t
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
> opportunity to change the app to some other serialization format that
> is perhaps less general but more robus
On Tue, Mar 13, 2012 at 2:50 PM, Merlijn van Deen wrote:
> On 13 March 2012 22:13, Guido van Rossum wrote:
>> Well, since trying to migrate data between versions using pickle is
>> the "wrong" thing anyway, I think the status quo is just fine.
>> Developers doing the "right" thing don't use pickl
On 13 March 2012 22:13, Guido van Rossum wrote:
> Well, since trying to migrate data between versions using pickle is
> the "wrong" thing anyway, I think the status quo is just fine.
> Developers doing the "right" thing don't use pickle for this purpose.
I'm confused by this. "The pickle serializ
On 3/13/2012 3:11 PM, Brian Curtin wrote:
I'm familiar with the scripts/bin change. I take it the rest of that
stuff matches *nix? Text later on seems to support this, so I think
I'm on board with it.
Yes, that is correct.
Martin and I spoke on Friday and at least the bin/ folder and Path
st
On 3/13/2012 4:19 PM, Terry Reedy wrote:
What is {base/userbase} actually on a typical machine? It is fixed or
user choice?
It is based upon user choice and on whether it is a system-wide install
(base) or a single-user install (userbase). Typically, though, it is
just "where you installed P
On Tue, Mar 13, 2012 at 2:21 PM, Antoine Pitrou wrote:
> On Tue, 13 Mar 2012 14:16:40 -0700
> Guido van Rossum wrote:
>
>> On Tue, Mar 13, 2012 at 12:49 PM, Terry Reedy wrote:
>> > Authors of separately maintained packages are, from our viewpoint, as
>> > eligible to help with tracker issues as
On Tue, 13 Mar 2012 14:16:40 -0700
Guido van Rossum wrote:
> On Tue, Mar 13, 2012 at 12:49 PM, Terry Reedy wrote:
> > Authors of separately maintained packages are, from our viewpoint, as
> > eligible to help with tracker issues as anyone else, even while they
> > continue work on their external
On 3/13/2012 3:43 PM, VanL wrote:
Following up on conversations at PyCon, I want to bring up one of my
personal hobby horses for change in 3.3: Fix install layout on Windows,
with a side order of making the PATH work better.
Short version:
1) The layout for the python root directory for all pla
On Tue, Mar 13, 2012 at 12:49 PM, Terry Reedy wrote:
> Authors of separately maintained packages are, from our viewpoint, as
> eligible to help with tracker issues as anyone else, even while they
> continue work on their external package. Some of them are more likely than
> most contributors to ha
On Tue, Mar 13, 2012 at 12:42 PM, Michael Foord
wrote:
>
> On 13 Mar 2012, at 04:44, Merlijn van Deen wrote:
>
>> http://bugs.python.org/issue6784 ("byte/unicode pickle
>> incompatibilities between python2 and python3")
>>
>> Hello all,
>>
>> Currently, pickle unpickles python2 'str' objects as py
On Tue, Mar 13, 2012 at 14:43, VanL wrote:
> Following up on conversations at PyCon, I want to bring up one of my
> personal hobby horses for change in 3.3: Fix install layout on Windows, with
> a side order of making the PATH work better.
>
> Short version:
>
> 1) The layout for the python root d
On Tue, Mar 13, 2012 at 12:38, Brian Curtin wrote:
> On Tue, Mar 13, 2012 at 14:13, Kenneth Reitz wrote:
> > I think the cheesehop trove classifiers would be the ideal way to
> > agnostically link to a page of packages related to the standard package
> in
> > question. No need for sort order.
>
On 3/13/2012 12:40 AM, Guido van Rossum wrote:
On Mon, Mar 12, 2012 at 9:22 PM, Terry Reedy wrote:
I would rather we figure out how to encourage authors of advancing packages
to contribute better implementations of existing features and well-tested
new features back to the stdlib module.
I wo
Following up on conversations at PyCon, I want to bring up one of my
personal hobby horses for change in 3.3: Fix install layout on Windows,
with a side order of making the PATH work better.
Short version:
1) The layout for the python root directory for all platforms should be
as follows:
s
On 13 Mar 2012, at 04:44, Merlijn van Deen wrote:
> http://bugs.python.org/issue6784 ("byte/unicode pickle
> incompatibilities between python2 and python3")
>
> Hello all,
>
> Currently, pickle unpickles python2 'str' objects as python3 'str'
> objects, where the encoding to use is passed to th
On Tue, Mar 13, 2012 at 14:13, Kenneth Reitz wrote:
> I think the cheesehop trove classifiers would be the ideal way to
> agnostically link to a page of packages related to the standard package in
> question. No need for sort order.
Randomize the order for all I care. We still need to ensure we'r
I think the cheesehop trove classifiers would be the ideal way to agnostically
link to a page of packages related to the standard package in question. No need
for sort order.
The beauty of this solution is that packages that aren't maintained won't add
the appropriate classifier to their packag
On 3/13/2012 6:31 AM, Paul Moore wrote:
It can be very hard to separate the good from the indifferent (or even
bad) when browsing PyPI. I've found some very good packages recently
which I'd never have known about without some random comment on a
mailing list.
+1
However, I'm not keen on havin
Guido van Rossum wrote:
Mark, did you do anything with my reply?
Not yet.
I noticed the difference when developing my HotPy VM
(latest incarnation thereof) which substitutes a sequence of low-level
bytecodes for the high-level ones when tracing.
(A bit like PyPy but much more Python-specific a
Thanks a lot for your hard work and dedication on packaging !
On 3/13/12 9:37 AM, Éric Araujo wrote:
Hello,
On behalf of the distutils2 contributors, I am thrilled to announce the
release of Distutils2 1.0a4.
Distutils2 is the packaging library that supersedes Distutils. It
supports distribut
Hello,
On behalf of the distutils2 contributors, I am thrilled to announce the
release of Distutils2 1.0a4.
Distutils2 is the packaging library that supersedes Distutils. It
supports distributing, uploading, downloading, installing and removing
projects, and is also a support library for other pa
What would be a release email without errors? :) The wiki link I gave
doesn’t work, it should be
http://wiki.python.org/moin/Distutils2/Contributing
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Uns
Mark, did you do anything with my reply?
On Mon, Mar 5, 2012 at 10:41 AM, Guido van Rossum wrote:
> On Mon, Mar 5, 2012 at 4:41 AM, Mark Shannon wrote:
>> Comparing two objects (of the same type for simplicity)
>> involves a three stage lookup:
>> The class has the operator C.__eq__
>> It can be
On Mon, Mar 12, 2012 at 10:10 PM, Senthil Kumaran wrote:
> On Mon, Mar 12, 2012 at 07:23:11PM -0700, Andrey Petrov wrote:
>> I've had the pleasure of speaking with Guido at PyCon and it became evident
>> that some of Python's included batteries are significantly lagging behind the
>> rapidly-evolv
On 13 March 2012 13:34, Donald Stufft wrote:
> http://python-guide.org ?
Hmm, yes maybe. I had seen this before (it's where I found out about
requests, IIRC).
As it says, it "is mostly a skeleton at the moment". With some
fleshing out, then it's probably a good start. I have some problems
with
Guido, Brett,
I've tried to use the proposed signature object, however, I found that
the 'bind' method is incorrect, and came up with my own implementation
of the PEP: https://gist.github.com/2029032 (If needed, I can change
the licence to PSFL) I used my version to implement typechecking,
ar
On Tuesday, March 13, 2012 at 9:31 AM, Paul Moore wrote:
> On 13 March 2012 03:48, C. Titus Brown mailto:c...@msu.edu)>
> wrote:
> > I feel like there's a middle ground where stable, long-term go-to modules
> > could
> > be mentioned, though. I don't spend a lot of time browsing PyPI, but I
> >
On 13 March 2012 03:48, C. Titus Brown wrote:
> I feel like there's a middle ground where stable, long-term go-to modules
> could
> be mentioned, though. I don't spend a lot of time browsing PyPI, but I
> suspect
> almost everyone spends a certain amount of time in the Python docs (which is a
>
Oops. I should re-read my mails before I send them, not /after/ I send them.
On 13 March 2012 12:44, Merlijn van Deen wrote:
pickled = BytestrPickler(data, bytestr=True); unpickled =
BytestrUnpickler(data, bytestr=True)
should of course read
pickled = BytestrPickler(data); unpic
http://bugs.python.org/issue6784 ("byte/unicode pickle
incompatibilities between python2 and python3")
Hello all,
Currently, pickle unpickles python2 'str' objects as python3 'str'
objects, where the encoding to use is passed to the Unpickler.
However, there are cases where it makes more sense to
62 matches
Mail list logo
