06.10.13 02:37, Antoine Pitrou написав(ла):
It's only strange because you don't understand the main use case for
bytearrays. They may look like arrays of 8-bit integers but they are
really used for buffers, so optimizing for stuff like FIFO operation
makes sense.
Could you please provide severa
Am 06.10.2013 01:37, schrieb Antoine Pitrou:
> On Sun, 6 Oct 2013 09:32:30 +1000
> Nick Coghlan wrote:
>> On 6 Oct 2013 08:59, "Antoine Pitrou" wrote:
>> >
>> > On Sat, 5 Oct 2013 15:35:30 -0700
>> > Raymond Hettinger wrote:
>> > >
>> > > Making bytearray's efficiently pop from the left side is
On Sun, 6 Oct 2013 09:32:30 +1000
Nick Coghlan wrote:
> On 6 Oct 2013 08:59, "Antoine Pitrou" wrote:
> >
> > On Sat, 5 Oct 2013 15:35:30 -0700
> > Raymond Hettinger wrote:
> > >
> > > Making bytearray's efficiently pop from the left side is dubious.
> > > This isn't a common idiom, nor should it
On 6 Oct 2013 08:59, "Antoine Pitrou" wrote:
>
> On Sat, 5 Oct 2013 15:35:30 -0700
> Raymond Hettinger wrote:
> >
> > Making bytearray's efficiently pop from the left side is dubious.
> > This isn't a common idiom, nor should it be. Even if all the
> > other implementations could model this beha
Ethan,
I take your three points and apologise for not making it a pleasant
experience for any of us.
Regarding the rest:
Ethan Furman, 04.10.2013 16:30:
> starting a trouble ticket with accusations
... and, in fact, I didn't.
> that something was snuck in and done behind peoples' backs
Sorry
Sorry, I may have missed some earlier relevant parts of this discussion.
But you appear to be saying that you don't want to optimize something
because it would be hard to explain why it performed better.
Eh?? Have I misunderstood?
Rob Cliffe
On 05/10/2013 23:35, Raymond Hettinger wrote:
On O
On Sat, 5 Oct 2013 15:35:30 -0700
Raymond Hettinger wrote:
>
> Making bytearray's efficiently pop from the left side is dubious.
> This isn't a common idiom, nor should it be. Even if all the
> other implementations could model this behavior, it wouldn't
> be a good idea to have bytearrays have
On Oct 5, 2013, at 12:42 PM, Serhiy Storchaka wrote:
> Please remember me, what was common decision about CPython-only optimizations
> which change computation complexity?
IIRC, it is okay optimize C code for just about anything, but we don't
want to alter the pure python code after from idiom
06.10.13 00:06, Victor Stinner написав(ла):
The str type is immutable, bytearray is not. It's easier to justify
optimisations on mutable types, like overallocate lists for example.
We can resize str or bytes if its refcount is 1. And resize is cheap in
some circumstances. This optimization is
The str type is immutable, bytearray is not. It's easier to justify
optimisations on mutable types, like overallocate lists for example.
Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscr
06.10.13 00:08, Victor Stinner написав(ла):
2013/10/4 Raymond Hettinger >:
> This contrasts with other tools like OrderedDict, ChainMap,
> and namedtuple which started their lives outside the standard
> library where we we able observe their fitness for real problems
> being solved by real us
On Sun, 06 Oct 2013 00:02:14 +0300
Serhiy Storchaka wrote:
> 05.10.13 23:11, Georg Brandl написав(ла):
> > Am 05.10.2013 21:42, schrieb Serhiy Storchaka:
> >> Please remember me, what was common decision about CPython-only
> >> optimizations which change computation complexity? I.g. constant
> >>
2013/10/4 Raymond Hettinger >:
> Please do conduct your own API tests and report back.
I don't understand why there is a need to evaluate a "new" API:
TransformDict has the same API than dict. The only differences are that the
constructor takes an extra mandatory parameter and there is a new getit
05.10.13 23:11, Georg Brandl написав(ла):
Am 05.10.2013 21:42, schrieb Serhiy Storchaka:
Please remember me, what was common decision about CPython-only
optimizations which change computation complexity? I.g. constant
amortization time of += for byte objects and strings, or linear time of
sum()
On Sat, 05 Oct 2013 22:11:43 +0200
Georg Brandl wrote:
> Am 05.10.2013 21:42, schrieb Serhiy Storchaka:
> > Please remember me, what was common decision about CPython-only
> > optimizations which change computation complexity? I.g. constant
> > amortization time of += for byte objects and string
Am 05.10.2013 21:42, schrieb Serhiy Storchaka:
> Please remember me, what was common decision about CPython-only
> optimizations which change computation complexity? I.g. constant
> amortization time of += for byte objects and strings, or linear time of
> sum() for sequences?
This appears to be
Please remember me, what was common decision about CPython-only
optimizations which change computation complexity? I.g. constant
amortization time of += for byte objects and strings, or linear time of
sum() for sequences?
___
Python-Dev mailing list
On Sat, 5 Oct 2013 08:25:01 -0700
Guido van Rossum wrote:
>
> A good defense combines multiple techniques -- e.g. common sense about when
> and where you park your bike together with a mediocre lock might make the
> theft risk acceptably low.
(just remember to park it under a shed with an approp
On Thu, Oct 3, 2013 at 11:20 PM, Armin Rigo wrote:
> Hi Guido,
>
> On Thu, Oct 3, 2013 at 10:47 PM, Guido van Rossum
> wrote:
> > Sounds a bit like some security researchers drumming up business. If you
> can
> > run the binary, presumably you can also recover the seed by looking in
> > /proc, r
Am 05.10.13 01:27, schrieb Victor Stinner:
> Ok, but why should we invest time to fix this specific DoS wheras
> there are other DoS like XML bomb?
That is a question about the very mechanics of free software.
"We" don't need to invest time into anything (and you may have
noticed that I lately act
Eric Snow, 05.10.2013 07:18:
> After a few rounds on import-sig PEP 451 is really for general
> consumption. I also have a patch up now.
>
> HTML: http://www.python.org/dev/peps/pep-0451/
> implementation: http://bugs.python.org/issue18864
Thanks, I'm happy that this is moving forward.
> Your
On 10/05/2013 01:14 AM, Victor Stinner wrote:
And how do you retrieve the whole hash value from an HTTP page? You
may retrieve some bits using specific HTTP requests, but not directly
the whole hash value. I don't know any web page displaying directly
the hash value of a string coming from the
22 matches
Mail list logo
