On Wed, Nov 23, 2011 at 11:13 PM, Philip Jenvey wrote:
>
> On Nov 22, 2011, at 12:43 PM, Amaury Forgeot d'Arc wrote:
>
>> 2011/11/22 Philip Jenvey
>> One reason to target 3.2 for now is it's not a moving target. There's
>> overhead involved in managing modifications to the pure python standard l
On Thu, Nov 24, 2011 at 10:20 PM, Maciej Fijalkowski wrote:
> The problem is not with maintaining the modified directory. The
> problem was always things like changing interface between the C
> version and the Python version or introduction of new stuff that does
> not run on pypy because it relie
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have a question and I would rather have an answer instead of
actually trying and getting myself in a messy situation.
Let say we have the following scenario:
1. A programer clones hg.python.org.
2. Programer creates a named branch and start to deve
Hi,
> I have a question and I would rather have an answer instead of
> actually trying and getting myself in a messy situation.
Clones are cheap, trying is cheap!
> Let say we have the following scenario:
>
> 1. A programer clones hg.python.org.
> 2. Programer creates a named branch and start t
Hi there,
I was doing some experiments with the buffer interface of bytearray today,
for the purpose of quickly reading a file's contents into a bytearray which
I can then modify. I decided to do some benchmarking and ran into
surprising results. Here are the functions I was timing:
def justread(
On Thu, 24 Nov 2011 20:15:25 +0200
Eli Bendersky wrote:
>
> Oops, readinto takes the same time as copying. This is a real shame,
> because readinto in conjunction with the buffer interface was supposed to
> avoid the redundant copy.
>
> Is there a real performance regression here, is this a well
On Thu, Nov 24, 2011 at 20:29, Antoine Pitrou wrote:
> On Thu, 24 Nov 2011 20:15:25 +0200
> Eli Bendersky wrote:
> >
> > Oops, readinto takes the same time as copying. This is a real shame,
> > because readinto in conjunction with the buffer interface was supposed to
> > avoid the redundant copy
I've never been able to get the Create Patch button to work reliably with
my BitBucket repo, so I still just run "hg diff -r default" locally and
upload the patch directly.
It would be nice if I could just specify both the feature branch *and* the
branch to diff against rather than having to work
Am 24.11.2011 21:55, schrieb Nick Coghlan:
> I've never been able to get the Create Patch button to work reliably
> with my BitBucket repo, so I still just run "hg diff -r default" locally
> and upload the patch directly.
Please submit a bug report to the meta tracker.
> It would be nice if I cou
On 2011-11-24, at 21:55 , Nick Coghlan wrote:
> I've never been able to get the Create Patch button to work reliably with
> my BitBucket repo, so I still just run "hg diff -r default" locally and
> upload the patch directly.
Wouldn't it be simpler to just use MQ and upload the patch(es) from the se
What if you broke up the read and built the final string object up. I
always assumed this is where the real gain was with read_into.
On Nov 25, 2011 5:55 AM, "Eli Bendersky" wrote:
> On Thu, Nov 24, 2011 at 20:29, Antoine Pitrou wrote:
>
>> On Thu, 24 Nov 2011 20:15:25 +0200
>> Eli Bendersky wr
On Fri, Nov 25, 2011 at 00:02, Matt Joiner wrote:
> What if you broke up the read and built the final string object up. I
> always assumed this is where the real gain was with read_into.
>
Matt, I'm not sure what you mean by this - can you suggest the code?
Also, I'd be happy to know if anyone e
On Fri, Nov 25, 2011 at 7:23 AM, "Martin v. Löwis" wrote:
> Am 24.11.2011 21:55, schrieb Nick Coghlan:
>> I've never been able to get the Create Patch button to work reliably
>> with my BitBucket repo, so I still just run "hg diff -r default" locally
>> and upload the patch directly.
>
> Please su
On Fri, Nov 25, 2011 at 7:46 AM, Xavier Morel wrote:
> On 2011-11-24, at 21:55 , Nick Coghlan wrote:
>> I've never been able to get the Create Patch button to work reliably with
>> my BitBucket repo, so I still just run "hg diff -r default" locally and
>> upload the patch directly.
> Wouldn't it b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Trying to clear the licensing issues surrounding my DTrace work
(http://bugs.python.org/issue13405) I am contacting Sun/Oracle guys.
Checking documentation abut the contributor license agreement, I had
encounter a wrong HTML link in http://www.python.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
When mailing there, I get this error. Not sure where to report.
"""
Final-Recipient: rfc822; [email protected]
Original-Recipient: rfc822;[email protected]
Action: failed
Status: 5.1.1
Remote-MTA: dns; stefan.zinzdrees.de
Diagnostic-Code: smtp; 550
On Thu, 24 Nov 2011 20:53:30 +0200
Eli Bendersky wrote:
>
> Sure. Updated the default branch just now and built:
>
> $1 -m timeit -s'import fileread_bytearray' 'fileread_bytearray.justread()'
> 1000 loops, best of 3: 1.14 msec per loop
> $1 -m timeit -s'import fileread_bytearray'
> 'fileread_byt
On 11/24/2011 5:02 PM, Matt Joiner wrote:
What if you broke up the read and built the final string object up. I
always assumed this is where the real gain was with read_into.
If a pure read takes twice as long in 3.3 as in 3.2, that is a concern
regardless of whether there is a better way.
-
Eli,
Example coming shortly, the differences are quite significant.
On Fri, Nov 25, 2011 at 9:41 AM, Eli Bendersky wrote:
> On Fri, Nov 25, 2011 at 00:02, Matt Joiner wrote:
>>
>> What if you broke up the read and built the final string object up. I
>> always assumed this is where the real gain
It's my impression that the readinto method does not fully support the
buffer interface I was expecting. I've never had cause to use it until
now. I've created a question on SO that describes my confusion:
http://stackoverflow.com/q/8263899/149482
Also I saw some comments on "top-posting" am I gu
On Fri, 25 Nov 2011 12:02:17 +1100
Matt Joiner wrote:
> It's my impression that the readinto method does not fully support the
> buffer interface I was expecting. I've never had cause to use it until
> now. I've created a question on SO that describes my confusion:
>
> http://stackoverflow.com/q/
On 25/11/2011 00:20, Jesus Cea wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
When mailing there, I get this error. Not sure where to report.
The address works fine. It would be nice if someone fixed the annoying
bounce however. :-)
Michael
"""
Final-Recipient: rfc822; sdr...@sdrees
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 24/11/11 18:08, Éric Araujo wrote:
>> I have a question and I would rather have an answer instead of
>> actually trying and getting myself in a messy situation.
> Clones are cheap, trying is cheap!
I would need to publish another repository onlin
On Fri, Nov 25, 2011 at 12:07 PM, Antoine Pitrou wrote:
> On Fri, 25 Nov 2011 12:02:17 +1100
> Matt Joiner wrote:
>> It's my impression that the readinto method does not fully support the
>> buffer interface I was expecting. I've never had cause to use it until
>> now. I've created a question on
> On Thu, 24 Nov 2011 20:53:30 +0200
> Eli Bendersky wrote:
> >
> > Sure. Updated the default branch just now and built:
> >
> > $1 -m timeit -s'import fileread_bytearray'
> 'fileread_bytearray.justread()'
> > 1000 loops, best of 3: 1.14 msec per loop
> > $1 -m timeit -s'import fileread_bytearray'
>
> Eli, the use pattern I was referring to is when you read in chunks,
> and and append to a running buffer. Presumably if you know in advance
> the size of the data, you can readinto directly to a region of a
> bytearray. There by avoiding having to allocate a temporary buffer for
> the read, and
Nick Coghlan writes:
> I'll stick with named branches until MQ becomes a builtin Hg
> feature that better integrates with other tools.
AFAIK MQ *is* considered to be a *stable, standard* part of Hg
functionality that *happens* (for several reasons *not* including
"it's not ready for Prime Time"
27 matches
Mail list logo
