[issue19087] bytearray front-slicing not optimized

Antoine Pitrou added the comment: > Could you please show concrete code in which you are going to use this > optimization? There's no need to "use" this optimization. Any networking code that has to find message boundaries and split on them will benefit. If you don't understand that, I'm not

[issue19087] bytearray front-slicing not optimized

Serhiy Storchaka added the comment: Deleting a slice at the front of a bytearray have linear complexity from the size of a bytearray (in any case del b[:1] is a little faster than b[:1] = b''). I doubt than any performance critical code do it instead of increasing an index in constant time. -

[issue19087] bytearray front-slicing not optimized

Antoine Pitrou added the comment: > Deleting a slice at the front of a bytearray have linear complexity > from the size of a bytearray (in any case del b[:1] is a little faster > than b[:1] = b''). I doubt than any performance critical code do it > instead of increasing an index in constant time.

[issue19087] bytearray front-slicing not optimized

Serhiy Storchaka added the comment: The same is true with your patch. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsu

[issue19087] bytearray front-slicing not optimized

Antoine Pitrou added the comment: > The same is true with your patch. I don't understand. What is "true with my patch"? -- ___ Python tracker ___ ___

[issue19087] bytearray front-slicing not optimized

Serhiy Storchaka added the comment: You increase internal index in a bytearray. A bytearray with small visible length can consume much hidden memory. -- ___ Python tracker ___ _

[issue19087] bytearray front-slicing not optimized

Antoine Pitrou added the comment: > You increase internal index in a bytearray. A bytearray with small > visible length can consume much hidden memory. No, because PyByteArray_Resize() is always called afterwards to ensure that the buffer is resized when it gets below 50% usage. -- ___

[issue19087] bytearray front-slicing not optimized

Serhiy Storchaka added the comment: > No, because PyByteArray_Resize() is always called afterwards to ensure > that the buffer is resized when it gets below 50% usage. > I.e. the bytearray is compacted from time to time. -- ___ Python tracker

[issue17326] Windows build docs still referring to VS 2008 in 3.3

Changes by Berker Peksag : -- resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> PCbuild/readme.txt not up-to-date ___ Python tracker

[issue19087] bytearray front-slicing not optimized

STINNER Victor added the comment: @Serhiy: "I doubt than any performance critical code do it instead of increasing an index in constant time." Sorry, I don't get your point. It's not become Python is inefficient that developers must develop workarounds. Antoine's patch is simple, elegant, and

[issue19087] bytearray front-slicing not optimized

Antoine Pitrou added the comment: > > No, because PyByteArray_Resize() is always called afterwards to ensure > > that the buffer is resized when it gets below 50% usage. > > I.e. the bytearray is compacted from time to time. Is there a problem with that? -- ___

[issue16079] list duplicate test names with patchcheck

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python

[issue19087] bytearray front-slicing not optimized

Serhiy Storchaka added the comment: > Is there a problem with that? No more than with msg198657. > Sorry, I don't get your point. It's not become Python is inefficient that > developers must develop workarounds. I'm not sure that "workarounds" are much worst than using this optimization. At

[issue19104] pprint produces invalid output for long strings

Serhiy Storchaka added the comment: The whole point of pprint() is formatted output of containers such as list or dict. Before 3.4 it does not wrap long strings at all. Of course I don't think this alternative is good. But at least it is better than producing illegal output. -- _

[issue19104] pprint produces invalid output for long strings

Antoine Pitrou added the comment: > The whole point of pprint() is formatted output of containers such as > list or dict. Well, the whole point of pprint is pretty-printing. Being restricted to containers is a bug, not a feature... -- ___ Python trac

[issue19104] pprint produces invalid output for long strings

Serhiy Storchaka added the comment: I doubt we are able to fix it in maintained releases. -- ___ Python tracker ___ ___ Python-bugs-li

[issue19087] bytearray front-slicing not optimized

Antoine Pitrou added the comment: > One of most used cases for bytearrays is accumulating. > And the patch slow down this case. I see no difference here. You are seeing a 10% slowdown, which is possibly a measurement glitch. The bottom line is that the performance remains approximately the sam

[issue19087] bytearray front-slicing not optimized

STINNER Victor added the comment: > One of most used cases for bytearrays is accumulating. And the patch slow > down this case. Please don't use the raw timeit command for micro-benchmarks, it is not reliable. For example, I'm unable to reproduce your "slow down" (7% on a microbenchmark is no

[issue19087] bytearray front-slicing not optimized

STINNER Victor added the comment: Oh, by the way: > $ ./python -m timeit "b = bytearray(); a = b'x'" "for i in range(1): b > += a" "bytes(b)" I'm not sure that it is what you expected: bytearray() is only initialized once ("setup" of timeit). You probably want to reinitialize at each l

[issue19072] classmethod doesn't honour descriptor protocol of wrapped callable

Changes by Raymond Hettinger : -- assignee: -> rhettinger nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue19072] classmethod doesn't honour descriptor protocol of wrapped callable

Raymond Hettinger added the comment: I don't think it was ever intended that decorators be chained together. The whole point is to control binding behavior during dotted look-up (when __getattribute__ is called) and not in other circumstances (such as a direct lookup in a class dictionary).

[issue19119] duplicate test name in Lib/test/test_heapq.py

Changes by Raymond Hettinger : -- assignee: -> rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue18594] C accelerator for collections.Counter is slow

Changes by Raymond Hettinger : -- assignee: -> rhettinger priority: high -> normal ___ Python tracker ___ ___ Python-bugs-list mailin

[issue19072] classmethod doesn't honour descriptor protocol of wrapped callable

Graham Dumpleton added the comment: The classmethod __get__() method does: static PyObject * cm_descr_get(PyObject *self, PyObject *obj, PyObject *type) { classmethod *cm = (classmethod *)self; if (cm->cm_callable == NULL) { PyErr_SetString(PyExc_RuntimeError,

[issue19017] selectors: towards uniform EBADF handling

Guido van Rossum added the comment: Charles-Francois, sorry to add you back to the bug, but (a) I thought you had agreed to a compromise patch that restarts signals in most cases but not for select(), poll() etc.; (b) I may have found a flaw in the idea. The flaw (if it is one) is related to P

[issue18594] C accelerator for collections.Counter is slow

Raymond Hettinger added the comment: A C-accelerator should ALWAYS be able to beat a pure python version if it does the same steps but without the overhead of the eval-loop. And in special cases such as type(self)==Counter, it can do much better. To resolve this report, the C accelerator need

[issue10042] functools.total_ordering fails to handle NotImplemented correctly

Raymond Hettinger added the comment: Nick, the latest version of the patch looks like a correct solution. Before applying, please add a block comment showing why these shenanigans are necessary (i.e. the use self.__lt__ instead of the less-than operator because the former doesn't fall into rec

[issue19086] Make fsum usable incrementally.

Raymond Hettinger added the comment: Conceptually, I support the idea of having some way to avoid information loss by returning uncollapsed partial sums. As you say, it would provide an essential primitive for parallel fsums and for cumulative subtotals. If something along those lines were to

[issue10042] functools.total_ordering fails to handle NotImplemented correctly

Raymond Hettinger added the comment: One other thought: The OrderedEnum example should not use the total ordering decorator. To the extent that the docs are trying to teach how to use Enum, they should focus on that task and not make a side-trip into the world of class decorators. And to

[issue19072] classmethod doesn't honour descriptor protocol of wrapped callable

Raymond Hettinger added the comment: I'll take a look at this in more detail in the next week or so. -- ___ Python tracker ___ ___ Pyt

[issue19078] Allow reversed(memoryview), like memoryview

Raymond Hettinger added the comment: Claudiu's patch looks correct. -- nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list m

<    1   2