On Tue, Jan 31, 2012 at 9:31 AM, Victor Stinner
wrote:
> Hi,
>
> In issues #13882 and #11457, I propose to add an argument to functions
> returning timestamps to choose the timestamp format. Python uses float
> in most cases whereas float is not enough to store a timestamp with a
> resolution of 1
Am 30.01.2012 20:06, schrieb stefan brunthaler:
>> Do you have a public repository for the code, so we can take a look?
>>
> I have created a patch (as Benjamin wanted) and put all of the
> resources (i.e., benchmark results and the patch itself) on my home
> page:
> http://www.ics.uci.edu/~sbrunt
stefan brunthaler, 30.01.2012 20:18:
>> Well, you're aware that Python already uses threaded code where
>> available? Or are you testing against Python 2?
>>
> Yes, and I am building on that.
I assume "yes" here means "yes, I'm aware" and not "yes, I'm using Python
2", right? And you're building o
Am 31.01.2012 00:50, schrieb Matt Joiner:
> Sounds good, but I also prefer Alexander's method. The type information is
> already encoded in the class object. This way you don't need to maintain a
> mapping of strings to classes, and other functions/third party can join in the
> fun without needing
On Tue, Jan 31, 2012 at 10:51 AM, Stephen J. Turnbull
wrote:
> Nick Coghlan writes:
>
> > 1. Draft ReStructuredText documentation for inclusion in the stdlib
> docs
> >
> > (still needed)
>
> No wonder people (not directly involved in development of the module)
> think that the proponents
Nick Coghlan writes:
> 1. Draft ReStructuredText documentation for inclusion in the stdlib docs
>
> (still needed)
No wonder people (not directly involved in development of the module)
think that the proponents don't care! What good is a battery if the
odds are even that you will hook it
Sounds good, but I also prefer Alexander's method. The type information is
already encoded in the class object. This way you don't need to maintain a
mapping of strings to classes, and other functions/third party can join in
the fun without needing access to the latest canonical mapping. Lastly
the
Hi,
In issues #13882 and #11457, I propose to add an argument to functions
returning timestamps to choose the timestamp format. Python uses float
in most cases whereas float is not enough to store a timestamp with a
resolution of 1 nanosecond. I added recently time.clock_gettime() to
Python 3.3 wh
2012/1/30 Nick Coghlan :
> On Tue, Jan 31, 2012 at 8:11 AM, Matt Joiner wrote:
>> It's also potentially lossy if you incremented and decremented until integer
>> precision is lost. My vote is for an int type check. No casting.
>
> operator.index() is built for that purpose (it's what we use these
On Mon, Jan 30, 2012 at 2:11 PM, Matt Joiner wrote:
> It's also potentially lossy if you incremented and decremented until integer
> precision is lost. My vote is for an int type check. No casting.
+1. Anything else is insane scope creep for something called "Semaphore".
--
--Guido van Rossum (
On Tue, Jan 31, 2012 at 8:11 AM, Matt Joiner wrote:
> It's also potentially lossy if you incremented and decremented until integer
> precision is lost. My vote is for an int type check. No casting.
operator.index() is built for that purpose (it's what we use these
days to restrict slicing to inte
It's also potentially lossy if you incremented and decremented until
integer precision is lost. My vote is for an int type check. No casting.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On 2012-01-30 20:52, Guido van Rossum wrote:
TB, what's your use case for passing a float to a semaphore?
Semaphores are conceptually tied to integers. You've kept arguing a
few times now that the workaround you need are clumsy, but you've not
explained why you're passing floats in the first plac
On Tue, Jan 31, 2012 at 7:52 AM, Peter Moody wrote:
> Note, http://pypi.python.org/pypi/ipaddr is actually the same module,
> but down a few versions. I'm not sure if your concern is about the
> same library having such a different api or if you had thought they
> were completely different librari
On Tue, Jan 31, 2012 at 4:59 AM, Antoine Pitrou wrote:
> It would be nice if that pronouncement or decision could outline the
> steps required to include an "experimental" module in the stdlib, and
> the steps required to move it from "experimental" to "stable".
Actually, that's a good idea - Eli
On Mon, Jan 30, 2012 at 1:44 PM, Nick Coghlan wrote:
> On Tue, Jan 31, 2012 at 4:19 AM, Scott Dial
> wrote:
>> PEP 3144 wasn't pronounced upon because there were significant
>> disagreements about the design of the API proposed in the PEP. As it
>> stands, I believe the authorship of ipaddr eithe
On Tue, Jan 31, 2012 at 4:19 AM, Scott Dial
wrote:
> PEP 3144 wasn't pronounced upon because there were significant
> disagreements about the design of the API proposed in the PEP. As it
> stands, I believe the authorship of ipaddr either decided that they were
> not going to compromise their modu
On Mon, 30 Jan 2012 16:26:30 -0500
Brett Cannon wrote:
> Should this end up being used in importlib through _os?
Yes, probably. I hadn't thought about that.
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/ma
Should this end up being used in importlib through _os?
On Mon, Jan 30, 2012 at 16:11, antoine.pitrou wrote:
> http://hg.python.org/cpython/rev/80ddbd87
> changeset: 74689:80ddbd87
> user:Antoine Pitrou
> date:Mon Jan 30 22:08:52 2012 +0100
> summary:
> Issue #8828: Ad
On Tue, Jan 31, 2012 at 3:03 AM, Brett Cannon wrote:
> I think that would be good. And I would even argue we remove support for
> turning it off to force people to no longer lean on dict ordering as a
> crutch (in 3.3 obviously).
On-by-default should be enough to cover that. Just as we allow peo
> Well, you're aware that Python already uses threaded code where
> available? Or are you testing against Python 2?
>
Yes, and I am building on that.
--stefan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pytho
Hello,
> Well, you can implement threaded code on any machine that support
> indirect branch instructions. Fortunately, GCC supports the
> "label-as-values" feature, which makes it available on any machine
> that supports GCC. My optimizations themselves are portable, and I
> tested them on a Pow
Hello,
> Could you try benchmarking with the "standard" benchmarks:
> http://hg.python.org/benchmarks/
> and see what sort of performance gains you get?
>
Yeah, of course. I already did. Refere to the page listed below for
details. I did not look into the results yet, though.
> How portable is t
On Sun, 29 Jan 2012 16:42:28 +1000
Nick Coghlan wrote:
> On Sun, Jan 29, 2012 at 1:29 PM, Guido van Rossum wrote:
> > On Sat, Jan 28, 2012 at 5:33 PM, Nick Coghlan wrote:
> >> I'm willing to go along with that (especially given your report of
> >> AppEngine's experience with the "labs" namespace
TB, what's your use case for passing a float to a semaphore?
Semaphores are conceptually tied to integers. You've kept arguing a
few times now that the workaround you need are clumsy, but you've not
explained why you're passing floats in the first place. A "fractional
resource" just doesn't sound l
On 2012-01-30 01:46, Victor Stinner wrote:
But why would you want to pass a float? It seems like API abuse to me.
If something should be changed, Semaphore(arg) should raise a
TypeError if arg is not an integer.
Short version:
I propose the the change to be
-while self._value == 0:
Maybe that's another example of waiting too long for the perfect
decision though. In the last ~12 months, ipaddr was downloaded at
least 11,000 times from its home
(http://code.google.com/p/ipaddr-py/downloads/list). There's been a
fair amount of changes over that time and a new release was put out
On 1/29/2012 4:39 PM, Gregory P. Smith wrote:
> An example of this working: ipaddr is ready to go in. It got the
> eyeballs and API modifications while still a pypi library as a result
> of the discussion around the time it was originally suggested as being
> added. I or any other committers have
On Jan 30, 2012, at 12:03 PM, Brett Cannon wrote:
>I think that would be good. And I would even argue we remove support for
>turning it off to force people to no longer lean on dict ordering as a
>crutch (in 3.3 obviously).
Yes, please!
-Barry
___
Pyt
On Fri, Jan 27, 2012 at 21:33, Benjamin Peterson wrote:
> 2012/1/27 Steven D'Aprano :
> > Benjamin Peterson wrote:
> >>
> >> Hello everyone,
> >> In effort to get a fix out before Perl 6 goes mainstream, Barry and I
> >> have decided to pronounce on what we want for our stable releases.
> >> What
On Mon, Jan 30, 2012 at 7:51 PM, Ivano wrote:
> Hello everyone.
> I'm writing to ask if Python uses a "fixed" release
> time or if it depends strongly on something else.
> In example, Blender does and since I'm diving
> into Python because I would like to extend it, I
> would like to know if my wo
Hello everyone.
I'm writing to ask if Python uses a "fixed" release
time or if it depends strongly on something else.
In example, Blender does and since I'm diving
into Python because I would like to extend it, I
would like to know if my work will have a default
lifetime or not.
By the way, Python
32 matches
Mail list logo
