Re: [Python-Dev] Make str/bytes hash algorithm pluggable?

2013-10-05 Thread Larry Hastings 

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 user request!?


Armin Rigo handwaves his way through an approach here:

   http://bugs.python.org/issue14621#msg173455

You use a "timing attack" to get the algorithm to "leak" a bit at a 
time.  I have no idea how that actually works, I don't have a background 
in security, nor a sufficiently devious mindset to work it out for myself.



//arry/
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 451: ModuleSpec

2013-10-05 Thread Stefan Behnel 
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 comments would be appreciated.

As a quick remark, reading the word "name" made me think a couple of times
whether it's the simple name of the module or the fully qualified name. I
think it's the FQMN in pretty much all cases, but it would be good to make
that clear, maybe by stating it somewhere near the beginning of the PEP
(and then doing a quick search+reread to make sure it's really the case
throughout the document).

Stefan


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Make str/bytes hash algorithm pluggable?

2013-10-05 Thread Martin v. Löwis 
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 actually don't :-) If you think this is
a waste of time, just sit back and watch it evolve - it's Christian's
time that may get wasted (and the time of anybody who choses to
respond). He is writing a PEP, and the same question can be asked
about any feature that goes into Python: Why this feature, and not
a different one? FWIW, I personally think that a lot of effort was
wasted in micro-optimizing the Unicode implementation :-)

If you actually think that changing this aspect of Python is a
bad idea, then you do need to get involved actively opposing
the PEP. I personally think that this "pluggable hash function"
stuff is a bad idea. Changing the hash function is ok as long
as it doesn't get dramatically slower.

> Why not setting a limit on the CPU
> time in your favorite web framework instead?

Because that is not implementable, in general, and might harm the
service. If you disagree about the non-implementability, please
propose a specific technology to limit the CPU consumption *per
HTTP request*. It might harm the service because /some/ requests
might be eligible to high CPU cost. So put in your sandbox technology
a mechanism to white-list specific URLs, or to have the CPU limit
depend on the URL that is being requested.

> Popular DDoS attack are usually the simplest, like flooding the server
> with ping requests, flooding the DNS server, flooding with HTTP
> requests which take a lot of time ot process, etc. Using a botnet, you
> don't care of using an inefficient DoS attack, because your power is
> the number of zombi.
> 
> I have no idea of the price of renting a botnet, it's probably
> expensive (and illegal as well).

Talking about actual attackers, I think the concern here are
script kiddies: people who don't want to invest a lot of money into
some illegal activity, but who just learned that they can kill
service XYZ if they run this-or-that script - and want to try out
whether this actually works. I believe that profesional criminals
aren't too interested in DDoS; they buy the botnets to distribute
spam.

Regards,
Martin

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Make str/bytes hash algorithm pluggable?

2013-10-05 Thread Guido van Rossum 
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, right? Or use ctypes or something. This demonstration seems of
> > academic interest only.
>
> I'll not try to defend the opposite point of view very actively, but
> let me just say that, in my opinion, your objection is not valid.  It
> is broken the same way as a different objection, which would claim
> that Python can be made sandbox-safe without caring about the numerous
> segfault cases.  They are all very obscure for sure; I tried at some
> point to list them in Lib/test/crashers.  I gave up when people
> started deleting the files because they no longer crashed on newer
> versions, just because details changed --- but not because the general
> crash they explained was in any way fixed...  Anyway, my point is that
> most segfaults can, given enough effort, be transformed into a single,
> well-documented tool to conduct a large class of attacks.
>
> The hash issue is similar.  It should be IMHO either ignored (which is
> fine for a huge fraction of users), or seriously fixed by people with
> the correctly pessimistic approach.  The current hash randomization is
> simply not preventing anything; someone posted long ago a way to
> recover bit-by-bit the hash randomized used by a remote web program in
> Python running on a server.  The only benefit of this hash
> randomization option (-R) was to say to the press that Python fixed
> very quickly the problem when it was mediatized :-/
>
> This kind of security issues should never be classified as "academic
> interest only".  Instead they can be classified as "it will take weeks
> / months / years before some crazy man manages to put together a
> general attack script, but likely, someone will eventually".
>
> From this point of view I'm saluting Christian's effort, even if I
> prefer to stay far away from this kind of issues myself :-)
>

I don't want to defend my position too actively either: I'm fine with a new
hash function as long as it's either faster, or safer and not slower, and I
think that being able to change it at compile time is good enough.

However, I do want to object to the view (common among security "purists")
that any vulnerability, no matter how hard to exploit (or fix) needs to be
treated the same. I consider security work as a race of arms, where the
effort spent on defense must be commensurate with the risk of attack. Just
because your bike lock can still be busted by a professional bike thief (or
picked by an ingenuous MIT student) that doesn't mean it's worthless --
especially if the unpickable lock might be worth (or weigh!) more than the
bike.

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.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Make str/bytes hash algorithm pluggable?

2013-10-05 Thread Antoine Pitrou 
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 appropriate colour)

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Optimization

2013-10-05 Thread 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?


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Optimization

2013-10-05 Thread 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() for sequences?

This appears to be about changeset 499a96611baa:

  Issue #19087: Improve bytearray allocation in order to allow cheap popping of
data at the front (slice deletion).

I think the best way to describe the CPython strategy is that we don't like to
optimize things that both have an idiomatic solution already (see str.join) and
can't be replicated easily in other implementations.

cheers,
Georg

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Optimization

2013-10-05 Thread Antoine Pitrou 
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 strings, or linear time of 
> > sum() for sequences?
> 
> This appears to be about changeset 499a96611baa:
> 
>   Issue #19087: Improve bytearray allocation in order to allow cheap popping 
> of
> data at the front (slice deletion).
> 
> I think the best way to describe the CPython strategy is that we don't like to
> optimize things that both have an idiomatic solution already (see str.join) 
> and
> can't be replicated easily in other implementations.

Agreed with this. I'll also point out that algorithmic complexity is
only an aspect of performance.

For example, providing a fast C implementation of decimal is a game
changer even though algorithmic complexity may have remained identical.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Optimization

2013-10-05 Thread Serhiy Storchaka 

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() for sequences?


This appears to be about changeset 499a96611baa:

   Issue #19087: Improve bytearray allocation in order to allow cheap popping of
data at the front (slice deletion).


I just need something to which I can refer in similar situations (there 
was several similar rejected proposition last months).


I'm not sure issue #19087 is in same category as constant time += for 
strings. But the converse was not proven.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 455: TransformDict

2013-10-05 Thread Victor Stinner 
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 getitem()
method. All other methods are the same: len(dict), key in dict,
dict.get(key), dict[key]=value, etc.

> This is necessary for a new class like TransformDict
> that was constructed from scratch and proposed for
> direct admission to the standard library.

The class is not "new": it is based on the API of dict, and existing
specialized implementations already used in the wild.

But I didn't compare TransformDict to existing specialized
implementations... Antoine: do you know if your API is different? Maybe in
some minor(?) details like storing the first key or last key.

> 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 users.

Why do you say that TransformDict has no real use case, whereas similar
containers are already used since many years in the Python standard
library? Extract of the PEP:

"Several modules in the standard library use identity lookups for object
memoization, for example pickle, json, copy, cProfile, doctest and
_threading_local."

I didn't check this whole list, but it looks like some modules can directly
use TransformDict(id), see for example the copy module.

And "case insenstive" dictionaries are also used in various projects
according to the PEP. Or do you mean that there are too few projects or
they are not popular enough?

In Python, email.Message uses a case-insensitive container preserving the
original case, except that it does also transform the value. email.Message
is used in http.client to parse HTTP headers. Twisted has its own
InsensitiveDict type for that (which does not transform the value).
http://twistedmatrix.com/documents/current/api/twisted.python.util.InsensitiveDict.html

> In short, we need to know whether the API will make sense to people,
> whether their code will be more readable with a TransformDict,
> and whether the zoo of dict variants should continue to grow.

Maybe Antoine can provide us a patch on the Python standard library to
reuse TransformDict(id) where it is possible. So we can compare the code
before/after to see if it's more readable or not.

> “… in order to get things merged you need to solve not only just your own
> problem but also realize that the world is bigger than your company and
try
> to solve things in a way where it makes sense for other people, even if
> primarily it is for your own situation.” -- Linus Torvalds
>
http://www.extremeta.com/2013/09/linus-torvalds-said-linuxcon-kernel-developer-panel/390

Existing implementations are specific (id() or str.lower()), whereas
Antoine's container is generic (transform function). Or do you mean that
it's not enough generic? It should do something on the value?

Victor
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Optimization

2013-10-05 Thread Antoine Pitrou 
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
> >> amortization time of += for byte objects and strings, or linear time of
> >> sum() for sequences?
> >
> > This appears to be about changeset 499a96611baa:
> >
> >Issue #19087: Improve bytearray allocation in order to allow cheap 
> > popping of
> > data at the front (slice deletion).
> 
> I just need something to which I can refer in similar situations (there 
> was several similar rejected proposition last months).

Sometimes there are no hard rules, and several factors can combine into
a decision. Complexity of implementation and existing alternatives are
useful guidelines, IMHO.

Optimized "+=" for strings has been re-enabled after PEP 393, IIRC.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 455: TransformDict

2013-10-05 Thread Serhiy Storchaka 

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 users.

Why do you say that TransformDict has no real use case, whereas similar
containers are already used since many years in the Python standard
library? Extract of the PEP:

"Several modules in the standard library use identity lookups for object
memoization, for example pickle, json, copy, cProfile, doctest and
_threading_local."

I didn't check this whole list, but it looks like some modules can
directly use TransformDict(id), see for example the copy module.


Unfortunately the pickle and the copy modules can't use 
TransformDict(id) because they expose their mappings (with integer id 
keys) in public API. At least until Python 4.0.


There are no so much use cases for IdentityDict in stdlib now, and even 
less for CaseInsensityDict. And a workaround is simple. I don't know 
about usage of TransformDict with other transfom function.



___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Optimization

2013-10-05 Thread Victor Stinner 
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
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Optimization

2013-10-05 Thread Serhiy Storchaka 

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 CPython-only.



___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Optimization

2013-10-05 Thread Raymond Hettinger 

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 idiomatic solutions that
work on all of the implementations.

For example, there is a string concatenation optimization
in the C code, but we still use and advocate str.join()
and try not to write code that relies on the optimization.
That said, it is nice that less informed users are sometimes
saved from an accidental performance trap.

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 different performance
characteristics than strings.   Right now, it is not too hard to
roughly explain the performance characteristics of the various
container objects, but that would be imperiled a bit by having
bytearrays differing from strings in ways other than their size.


Raymond___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Optimization

2013-10-05 Thread Antoine Pitrou 
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 different performance
> characteristics than strings.

Bytearrays are mutable and strings are immutable, so evidently they
will have different performance characteristics.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Optimization

2013-10-05 Thread Rob Cliffe 

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 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 idiomatic solutions that
work on all of the implementations.

For example, there is a string concatenation optimization
in the C code, but we still use and advocate str.join()
and try not to write code that relies on the optimization.
That said, it is nice that less informed users are sometimes
saved from an accidental performance trap.

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 different performance
characteristics than strings.   Right now, it is not too hard to
roughly explain the performance characteristics of the various
container objects, but that would be imperiled a bit by having
bytearrays differing from strings in ways other than their size.


Raymond


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/rob.cliffe%40btinternet.com


No virus found in this message.
Checked by AVG - www.avg.com 
Version: 2012.0.2242 / Virus Database: 3222/6225 - Release Date: 10/05/13



___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] project culture: take responsibility for your commits

2013-10-05 Thread Stefan Behnel 
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 for the snotty comment, but at least I explicitly wrapped this in
"..." to indicate that I wasn't entirely serious about it.


> offensive, as are continual accusations that those you are working with
> simply don't understand.
> Add to that constant complaints about writing patches yourself...

1) I was far from being the one who *wanted* the feature in question, but

2) I actually contributed 5 patches over the course of the ticket, none of
which was really commented on. That's certainly not a very pleasant
experience, nor an indication that people *do* understand.

At least, that's my side of the story.

Stefan


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Optimization

2013-10-05 Thread Nick Coghlan 
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 behavior, it wouldn't
> > be a good idea to have bytearrays have different performance
> > characteristics than strings.
>
> Bytearrays are mutable and strings are immutable, so evidently they
> will have different performance characteristics.

I suspect "list" may have been the intended comparison there. "array.array"
is another appropriate comparison.

Having bytearray operations differ in algorithmic complexity from those two
types would be very strange and surprising (particularly if it was CPython
specific).

Cheers,
Nick.

>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Optimization

2013-10-05 Thread 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 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 different performance
> > > characteristics than strings.
> >
> > Bytearrays are mutable and strings are immutable, so evidently they
> > will have different performance characteristics.
> 
> I suspect "list" may have been the intended comparison there. "array.array"
> is another appropriate comparison.
> 
> Having bytearray operations differ in algorithmic complexity from those two
> types would be very strange and surprising (particularly if it was CPython
> specific).

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.

Regards

Antoine.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Optimization

2013-10-05 Thread Georg Brandl 
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 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 different performance
>> > > characteristics than strings.
>> >
>> > Bytearrays are mutable and strings are immutable, so evidently they
>> > will have different performance characteristics.
>> 
>> I suspect "list" may have been the intended comparison there. "array.array"
>> is another appropriate comparison.
>> 
>> Having bytearray operations differ in algorithmic complexity from those two
>> types would be very strange and surprising (particularly if it was CPython
>> specific).
> 
> 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.

I agree, that is also what came to my mind when I read the commit message.

Georg

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Optimization

2013-10-05 Thread Serhiy Storchaka 

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 several examples of "the main use case for
bytearrays"?


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com