Change by Serhiy Storchaka :
--
title: Spped up comparison of bytes and bytearray object with objects of
different types -> Speed up comparison of bytes and bytearray object with
objects of different types
___
Python tracker
<
Change by Serhiy Storchaka :
--
keywords: +patch
pull_requests: +22353
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/23461
___
Python tracker
<https://bugs.python.org/issu
Serhiy Storchaka added the comment:
New changeset 313467efdc23a1ec8662b77d2001642be598f80a by Serhiy Storchaka in
branch 'master':
bpo-42435: Speed up comparison of bytes and bytearray object (GH--23461)
https://github.com/python/cpython/commit/313467efdc23a1ec8662b77d200164
Serhiy Storchaka added the comment:
I concur with Steven. We usually reject pure cosmetic changes. And I do not see
any advantages of the new code.
--
nosy: +serhiy.storchaka
resolution: -> rejected
stage: patch review -> resolved
status: open -&g
Change by Serhiy Storchaka :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Serhiy Storchaka added the comment:
New changeset dd844a2916fb3a8f481ec7c732802c13c3375691 by Serhiy Storchaka in
branch 'master':
bpo-42328: Fix tkinter.ttk.Style.map(). (GH-23300)
https://github.com/python/cpython/commit/dd844a2916fb3a8f481ec7c732802c
Serhiy Storchaka added the comment:
Could not object replace Any?
--
___
Python tracker
<https://bugs.python.org/issue42102>
___
___
Python-bugs-list mailin
Change by Serhiy Storchaka :
--
nosy: +serhiy.storchaka
nosy_count: 20.0 -> 21.0
pull_requests: +22365
pull_request: https://github.com/python/cpython/pull/23443
___
Python tracker
<https://bugs.python.org/issue1
Change by Serhiy Storchaka :
--
nosy: +serhiy.storchaka, serhiy.storchaka
nosy_count: 20.0 -> 21.0
pull_requests: +22365, 22366
pull_request: https://github.com/python/cpython/pull/23443
___
Python tracker
<https://bugs.python.org/issue1
Change by Serhiy Storchaka :
--
nosy: +serhiy.storchaka
nosy_count: 10.0 -> 11.0
pull_requests: +22364
pull_request: https://github.com/python/cpython/pull/23443
___
Python tracker
<https://bugs.python.org/issu
Change by Serhiy Storchaka :
--
pull_requests: +22367
pull_request: https://github.com/python/cpython/pull/23474
___
Python tracker
<https://bugs.python.org/issue42
Change by Serhiy Storchaka :
--
nosy: +serhiy.storchaka
___
Python tracker
<https://bugs.python.org/issue42376>
___
___
Python-bugs-list mailing list
Unsub
Serhiy Storchaka added the comment:
It looks correct to me. Of course, the result is different, because they are
different functions. re.match() and re.search() return a match object (or
None), and re.findall returns a list. What result did you expect?
--
nosy: +serhiy.storchaka
Serhiy Storchaka added the comment:
It looks like you imported the functools module twice and have two different
classes functools.partial. When you try to import one of them, you found the
other one.
--
nosy: +serhiy.storchaka
___
Python tracker
Serhiy Storchaka added the comment:
Please don't use PyDict_GetItemString(), it will be deprecated. You can use
_PyDict_GetItemStringWithError().
Also always check the raised exception type before overwriting the exception,
so you will not swallow MemoryError or other unexpected
Change by Serhiy Storchaka :
--
pull_requests: +22376
pull_request: https://github.com/python/cpython/pull/23488
___
Python tracker
<https://bugs.python.org/issue42
Change by Serhiy Storchaka :
--
keywords: +patch
nosy: +serhiy.storchaka
nosy_count: 1.0 -> 2.0
pull_requests: +22378
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/23474
___
Python tracker
<https://bugs.p
Change by Serhiy Storchaka :
--
pull_requests: +22380
pull_request: https://github.com/python/cpython/pull/23491
___
Python tracker
<https://bugs.python.org/issue42
Serhiy Storchaka added the comment:
PR 23491 does not fix the failure, but it adds new checks which can provide
additional information in case of failure.
--
___
Python tracker
<https://bugs.python.org/issue42
Serhiy Storchaka added the comment:
New changeset 14d81dcaf827f6b66bda45e8f5689d07d7d5735c by Serhiy Storchaka in
branch 'master':
bpo-42260: Improve error handling in _PyConfig_FromDict (GH-23488)
https://github.com/python/cpython/commit/14d81dcaf827f6b66bda45e8f5689d
Serhiy Storchaka added the comment:
New changeset b0b428510cfd604a8eef1f245f039331e671ea4a by Serhiy Storchaka in
branch 'master':
bpo-42370: Check element before making mouse click in ttk tests (GH-23491)
https://github.com/python/cpython/commit/b0b428510cfd604a8eef1f245f0393
Serhiy Storchaka added the comment:
I am writing a code (it is not trivial to emit correct warning) and I have a
question. What to do if the loop was set by set_event_loop()? Currently
get_event_loop() can return a loop without creating a new loop while
get_running_loop() raises an error
Serhiy Storchaka added the comment:
Why use a special value AT_FDCWD instead of None? It is not Pythonish. Clearly,
when it is used in C, but in dynamically typed Python we are not limited to
only one C-type.
Such a large number of new functions littering the namespace. Why not just add
Serhiy Storchaka added the comment:
Perhaps it is better not export these functions in the `os` module, leaving
them in `posix`?
In addition, `stat` and `lstat` is not very thin wrappers (especially on
Windows) given that they are working with `bytes` and with `str
Serhiy Storchaka added the comment:
> On Unix, doing os.stat
> on the directory, then looking on st_nlink, will tell you whether
> the directory is empty (st_nlink is 2 on an empty directory).
Directory with st_nlink==2 can contains any number of non-directory files. And
one subdir
New submission from Serhiy Storchaka :
This patch slightly optimize conversion int to string with base 2, 8 or 16 by
calculating exactly number of digits and avoiding unnecessary memory
allocation. The code is similar to used for decimal conversion.
Without patch:
$ ./python -m timeit -s
Serhiy Storchaka added the comment:
This is print from *other* _decodeExtra call. Add print('start') at start of
_decodeExtra and you will see it.
start
b'\xfe\xca\x00\x00'
51966 0
b''
start
start
b'\x00'
--
nosy: +storchaka
__
Serhiy Storchaka added the comment:
This is padding. Other implimentations just ignore it and Python must.
--
keywords: +patch
Added file: http://bugs.python.org/file24902/fix_zipfile_extra.patch
___
Python tracker
<http://bugs.python.
New submission from Serhiy Storchaka :
ZIP files specification supports new compression algorithms since 2006. Since
bzip2 and lzma now contained in Python standart library, it would be nice to
add support for these methods in zipfile. This will allow to process more
foreign zip files and
Serhiy Storchaka added the comment:
This is not completed patch yet, without tests and documentation. I would like
to receive feedback before the end of polishing. It might be worth transfer a
portion of code in _lzmamodule.c for better use of capacity of LZMA API (used
in zip format
Changes by Serhiy Storchaka :
Added file: http://bugs.python.org/file24932/sample-bzip2.zip
___
Python tracker
<http://bugs.python.org/issue14366>
___
___
Python-bug
Changes by Serhiy Storchaka :
Added file: http://bugs.python.org/file24933/sample-lzma.zip
___
Python tracker
<http://bugs.python.org/issue14366>
___
___
Python-bug
Serhiy Storchaka added the comment:
Thank you, Martin, for review and advices.
Lzma in zip format: 2-bytes version (LZMA SDK version, it has not relations
with version of XZ Utils used by lzma module), 2-bytes properties size (I have
not seen a value other than 5), N-bytes (N=5) property
Serhiy Storchaka added the comment:
Has anyone tested wcswidth on FreeBSD, old Solaris? With non-utf8 locales?
--
nosy: +storchaka
___
Python tracker
<http://bugs.python.org/issue12
New submission from Serhiy Storchaka :
ZIP File Format Specification
(http://www.pkware.com/documents/casestudies/APPNOTE.TXT) supports bzip2
compression since at least 2003. Since bzip2 contained in Python standart
library, it would be nice to add support for these method in zipfile. This
Serhiy Storchaka added the comment:
Issue #14371: Add support for bzip2 compression to the zipfile module.
--
___
Python tracker
<http://bugs.python.org/issue14
Serhiy Storchaka added the comment:
What if add more hacking? If long integer already used for buffering and
checking, let use it for swapping and splitting too.
With my patch (attached) codecs.utf_16_be_decode runs 5% faster (on 32-bit
Linux, I was not tested 64-bit). And of cause no
Serhiy Storchaka added the comment:
Heh. This was in previous version of my patch. I have removed '& 0xu' and
parents for simplicity. GCC produces same binaries for both sources. But you
can return it back. It has effect only on plathforms with non-16-bit short, but
Changes by Serhiy Storchaka :
Added file: http://bugs.python.org/file24960/utf16_decoder_shift_2.patch
___
Python tracker
<http://bugs.python.org/issue14249>
___
___
Pytho
Serhiy Storchaka added the comment:
"(unsigned short)(long >> 32)" returns the 16 bits (32..48) if short is 16-bit.
I agree that this variant is more strict and reliable (and this was my original
version) and if you do not find it verbose and redundant, so be it. The
di
Serhiy Storchaka added the comment:
I am working on this. Should I add tests to test_zipfile.py or create new
test_zipfile_bzip2.py?
It would add a note that the bzip2 compression can understand not all programs
(and do not understand the older versions of Python), but understands the
Info
Changes by Serhiy Storchaka :
--
nosy: +storchaka
___
Python tracker
<http://bugs.python.org/issue9720>
___
___
Python-bugs-list mailing list
Unsubscribe:
Serhiy Storchaka added the comment:
I am afraid that the problem is more complicated. With the option
allowZip64=True all files need to write with this extension, because size of
local file header may change and there will be after compression just go back
and rewrite it.
Now it appears
Serhiy Storchaka added the comment:
-if long_xml or text or len(elem):
+if text or len(elem) or long_xml:
Use alternatives in order of decreasing probability.
--
nosy: +storchaka
___
Python tracker
<http://bugs.python.
Serhiy Storchaka added the comment:
Thanks to the tests, I found the error. Since the bzip2 is block algorithm,
decompressor need to eat a certain amount of data, so it began to return data.
Now when reading small chunks turns out premature end of data. I'm working on a
Changes by Serhiy Storchaka :
Added file: http://bugs.python.org/file24982/bzip2_in_zip_tests.patch
___
Python tracker
<http://bugs.python.org/issue14371>
___
___
Pytho
Serhiy Storchaka added the comment:
Does it not decrease the performance?
Falling out integral floating point numbers in the mathematical floating point
calculations seems unlikely. I suggest interning integral floats only in
conversions str -> float and int -> float. Exception can b
Serhiy Storchaka added the comment:
Try moving your changes from PyFloat_FromDouble to PyFloat_FromString. Look at
memory and perfomance.
--
___
Python tracker
<http://bugs.python.org/issue14
Serhiy Storchaka added the comment:
All errors are fixed. All tests are passed. Unfortunately, the patch was more
than expected. This is necessary for correct and effective work with large
bzip2 buffers (for other codecs can also be a profit).
--
Added file: http://bugs.python.org
Serhiy Storchaka added the comment:
PyBench contains a lot of different tests and executes them not too long.
Random fluctuations of a few percent are possible. We need a more stable
realistic test working with floats.
$ ./python -m timeit 'x,y,d=1,0,0.01
for i in range(628):
x,y=x-d*
Serhiy Storchaka added the comment:
> The existing code uses the b"".join() idiom for linear-
> time concatenation, but the patch replaces it with a version that does
> "buf += data" after each read.
You made a mess. The existing code uses ``buf += data``, but I
Serhiy Storchaka added the comment:
Fixed regeression in decompression.
Nadeem Vawda, we both were wrong. `buf += data` is noticeably faster
`b''.join()` in CPython.
--
Added file: http://bugs.python.org/file25006/bzip2_in_zip_3.patch
Changes by Serhiy Storchaka :
Added file: http://bugs.python.org/file25007/bzip2_and_lzma_in_zip_3.patch
___
Python tracker
<http://bugs.python.org/issue14366>
___
___
Serhiy Storchaka added the comment:
> For EOS, please re-read the specification.
Well, nothing prevents the setting of this bit. Lzma raw compressor already
appends EOS.
--
___
Python tracker
<http://bugs.python.org/issu
Serhiy Storchaka added the comment:
> Regarding changes to lzma; exactly what is being proposed?
Yes, it's just additional functions for encoding and decoding of filter specs.
But this is not necessary, the current implementation uses own functions (need
the support of
only LZMA
New submission from Serhiy Storchaka :
The proposed patch accelerates ascii decoding in a particular case, when the
alignment of the input data coincides with the alignment of data in
PyASCIIObject. This is a common case on 32-bit platforms. I did not check
whether the patch have any effect
Serhiy Storchaka added the comment:
I would like to have someone tested it on a 64-bit platform. May be worth a
copy smaller blocks, not sizeof(long) but sizeof(void *)? This guaranteed the
alignment of the destination (and very likely the source
Serhiy Storchaka added the comment:
> +if (((size_t) p & LONG_PTR_MASK) == ((size_t) q & LONG_PTR_MASK)) {
> This test looks. I think that it should be replaced by:
> if (!((size_t) q & LONG_PTR_MASK)) {
"if (!((size_t) p & LONG_PTR_MASK)) {" if
Changes by Serhiy Storchaka :
Added file: http://bugs.python.org/file25034/decode_ascii_2.patch
___
Python tracker
<http://bugs.python.org/issue14419>
___
___
Python-bug
Serhiy Storchaka added the comment:
> +#if SIZEOF_LONG <= SIZEOF_VOID_P
> +if (!((size_t) p & LONG_PTR_MASK)) {
>
> I wrote "q", not "p". You have to check p and q alignement to be able
> to dereference p and q pointers.
Initial q (desti
Serhiy Storchaka added the comment:
> q is not the address of the Unicode string, but the address of the
> data following the Unicode structure in memory. Strings created by
> PyUnicode_New() are composed on one unique memory block: {structure,
> data}.
I know all th
Serhiy Storchaka added the comment:
The bug only occurs for non-empty archives.
There are two ways of fixing this bug -- very simple and no so simple. Patches
are attached.
--
keywords: +patch
nosy: +storchaka
Added file: http://bugs.python.org/file25038
Changes by Serhiy Storchaka :
Added file: http://bugs.python.org/file25039/fix_zipfile_comment_complex.patch
___
Python tracker
<http://bugs.python.org/issue14
Serhiy Storchaka added the comment:
> New tests. I'm not conviced by the patch: it slows down the decoder for
> "short" strings. I don't understand which kind of ASCII encoded strings
> (specific length or content?) are optimized by the patch.
May be you forgot
Serhiy Storchaka added the comment:
This is the second advantage. The first one is that nothing is to be written
when zipfile opened in a mode "a", if we don't change anything.
--
___
Python tracker
<http://bugs.pyt
Serhiy Storchaka added the comment:
Fixed patch with tests attached.
--
Added file: http://bugs.python.org/file25043/fix_zipfile_comment_2.patch
___
Python tracker
<http://bugs.python.org/issue14
Serhiy Storchaka added the comment:
My fault.
--
Added file: http://bugs.python.org/file25047/fix_zipfile_comment_3.patch
___
Python tracker
<http://bugs.python.org/issue14
Serhiy Storchaka added the comment:
Python script too rough tool to measure decoding performance on short strings.
To do this I used C.
The benchmark scheme is as follows. Taken a big enough chunk of memory to
reduce effect of processor cache. This area is splitted into many pieces with
the
Serhiy Storchaka added the comment:
As you can see, the unpatched code does not depend on the alignment. With
patches aligned data (which constitute the vast majority, if not all) decoded
much faster and non-aligned data decoded sometimes slightly slower. Time of
decoding 2-10-bytes
Serhiy Storchaka added the comment:
I'm sorry. Here is the corrected patch for big-endian plathform.
--
Added file: http://bugs.python.org/file25072/utf16_decoder_shift_3.patch
___
Python tracker
<http://bugs.python.org/is
Serhiy Storchaka added the comment:
This patch is for Python 2. New features are accepted only for Python 3.3+. I
ported the patch, but since I have no Mac, I can't check.
To date code was specified incorrectly.
The length of integers was calculated incorrectly. To convert integers, yo
Changes by Serhiy Storchaka :
--
nosy: +storchaka
___
Python tracker
<http://bugs.python.org/issue4653>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Serhiy Storchaka :
--
nosy: +storchaka
___
Python tracker
<http://bugs.python.org/issue9246>
___
___
Python-bugs-list mailing list
Unsubscribe:
Serhiy Storchaka added the comment:
No, I do not think that any application will significantly speeded up.
In fact, it is not optimization, and getting rid of the apparent pessimization.
In addition to increasing the speed, memory fragmentation is reduced.
The patch has a minimum size, the
Serhiy Storchaka added the comment:
''.join(c if ord(c) < 0x1 else escape(c) for c in s)
--
nosy: +storchaka
___
Python tracker
<http://bugs.pytho
Serhiy Storchaka added the comment:
For "**" globbing see http://ant.apache.org/manual/dirtasks.html#patterns .
If we extend pattern syntax of templates, why not implement Perl, Tcl or Bash
extensions?
--
nosy: +storchaka
___
Python trac
New submission from Serhiy Storchaka :
"Other resources" links in the Python 3 documentation refer to the Python 2.7
online documentation. It is also strange that http://python.org/doc (for
example from issue tracker sidebar) refer to the Python 2.7 documentation.
--
assi
Serhiy Storchaka added the comment:
I think that it would be appropriate to start redirect (HTTP 302)
http://docs.python.org/something/ to the http://docs.python.org/2.7/something/.
Today, the situation is Vice versa.
--
___
Python tracker
<h
Serhiy Storchaka added the comment:
It would be better if you provide a working script that demonstrates the issue.
I have completed your example (attached).
I ran the example on Python 3.1 and received:
0.24046326
9.8737308979
0.587980985641
Then I ran on Python 3.3
Serhiy Storchaka added the comment:
Hmm. I came across this error yesterday in the tests, when broke utf-16
decoder. The error was introduced in the module atexit. Until it all tests
passed successfully, and this branch will not run.
A simple search
find -name '*.py' -exec egre
New submission from Serhiy Storchaka :
I was very surprised to find in Python source code files that are not
compatible with Python3. It turns out that this is not an exception, such files
very much (see scanner script in attachment). Surely for many years no one had
reached his hands run
Serhiy Storchaka added the comment:
See also issues 14490, 14491, and 14492.
--
___
Python tracker
<http://bugs.python.org/issue14497>
___
___
Python-bugs-list m
Changes by Serhiy Storchaka :
Added file: http://bugs.python.org/file25125/invalid.txt
___
Python tracker
<http://bugs.python.org/issue14497>
___
___
Python-bugs-list m
Serhiy Storchaka added the comment:
Indeed, somehow I have in the source tree were many Python2 files. After `rm -r
*` and `hg revert -a ` number of invalid files decreased to a reasonable limit.
Sorry for the false alarm.
--
___
Python tracker
Serhiy Storchaka added the comment:
Because of some error in my source tree was a lot of Python2 files, which gave
a false result (see issue 14497). After cleaning, old-style raise was only in
Mac/BuildScript/build-installer.py and Tools/msi
Serhiy Storchaka added the comment:
What compiler are you using? With gcc 4.4 on 32-bit Linux netbook I get:
unpatched union shift
utf-16le " "*1 129 126109
utf-16le "\u263A"*1208 203160
utf-16be " &qu
Serhiy Storchaka added the comment:
> I just replaced expressions in calls to Py_MAX by variables: Py_MAX is a
> macro and it may have to compute each expression twice.
gcc computes those values only once. It even caches them for use in
PyUnicode_WRITE. But other compilers may not be so
Serhiy Storchaka added the comment:
> > I recommend that __hash__ should use functools.lru_cache for caching.
> Why would you do such a thing? A hash value is a single 64-bit slot, no need
> to add the memory consumption of a whole dictionary and the runtime cost of a
> LRU
Changes by Serhiy Storchaka :
--
nosy: +storchaka
___
Python tracker
<http://bugs.python.org/issue13621>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Serhiy Storchaka :
--
nosy: +storchaka
___
Python tracker
<http://bugs.python.org/issue13031>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Serhiy Storchaka :
--
nosy: +storchaka
___
Python tracker
<http://bugs.python.org/issue10408>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Serhiy Storchaka :
--
nosy: +storchaka
___
Python tracker
<http://bugs.python.org/issue13126>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Serhiy Storchaka :
--
nosy: +storchaka
___
Python tracker
<http://bugs.python.org/issue12805>
___
___
Python-bugs-list mailing list
Unsubscribe:
Serhiy Storchaka added the comment:
> uuids = set()
> for u in [uuid.uuid4() for i in range(1000)]:
> uuids.add(u)
uuids = {uuid.uuid4() for i in range(1000)}
However, I'm not sure of the legitimacy of replacement suitable for
cryptographic u
Changes by Serhiy Storchaka :
--
nosy: +storchaka
___
Python tracker
<http://bugs.python.org/issue11981>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Serhiy Storchaka :
--
nosy: +storchaka
___
Python tracker
<http://bugs.python.org/issue10376>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Serhiy Storchaka :
--
nosy: +storchaka
___
Python tracker
<http://bugs.python.org/issue6972>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Serhiy Storchaka :
--
nosy: +storchaka
___
Python tracker
<http://bugs.python.org/issue2824>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Serhiy Storchaka :
--
nosy: +storchaka
___
Python tracker
<http://bugs.python.org/issue6839>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Serhiy Storchaka :
--
nosy: +storchaka
___
Python tracker
<http://bugs.python.org/issue4844>
___
___
Python-bugs-list mailing list
Unsubscribe:
4201 - 4300 of 25874 matches
Mail list logo
