Martin v. Löwis mar...@v.loewis.de added the comment:
Serhiy: what's the status of your contributor form? Note that you can also fax
it, or scan it and send it by email.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14339
STINNER Victor victor.stin...@gmail.com added the comment:
You may call assert(_PyUnicode_CheckConsistency(v, 1)) to ensure
that the newly created string is consistent (see the function
for the details).
Done in the following changeset:
changeset: 76560:3bdcf0cab164
parent:
Serhiy Storchaka storch...@gmail.com added the comment:
I sent the signed form. Martin, sorry for the delay. Mark, sorry, that
involuntarily let you down.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14339
Mark Dickinson dicki...@gmail.com added the comment:
Serhiy: thanks for submitting the form! No need to apologise: it was my bad
for making the commit prematurely.
And now that I see that all-important asterisk next to your name, I'll reclose
the issue. :-)
--
status: open - closed
STINNER Victor victor.stin...@gmail.com added the comment:
2.100 -v = PyUnicode_DecodeASCII(p, buffer[sz] - p, NULL);
...
2.104 +assert(p == PyUnicode_1BYTE_DATA(v));
2.105 return v;
2.106 }
You may call assert(_PyUnicode_CheckConsistency(v, 1)) to ensure that the newly
Serhiy Storchaka storch...@gmail.com added the comment:
I can only do this tomorrow.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14339
___
Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset dcd3344b6d5b by Mark Dickinson in branch 'default':
Issue #14339: Improve speed of bin, oct and hex builtins. Patch by Serhiy
Storchaka (with minor modifications).
http://hg.python.org/cpython/rev/dcd3344b6d5b
Mark Dickinson dicki...@gmail.com added the comment:
Thanks for the patch. I made some minor changes, notably moving the overflow
check closer to where it's needed, moving some comments around, and removing a
(possibly inappropriate) PyErr_NoMemory call.
--
resolution: - fixed
Martin v. Löwis mar...@v.loewis.de added the comment:
This should have waited until Serhiy submits a contributor form. Serhiy, can
you please do this soon? Else I'll have to revert the change.
--
status: closed - open
___
Python tracker
Mark Dickinson dicki...@gmail.com added the comment:
Aargh. Sorry, yes. Serhiy, can you do this? The form can be found at:
http://www.python.org/psf/contrib/contrib-form-python/
--
___
Python tracker rep...@bugs.python.org
Mark Dickinson dicki...@gmail.com added the comment:
Whoops; that looks like a slightly older version of the form. I think the
correct one is:
http://www.python.org/psf/contrib/contrib-form/
--
___
Python tracker rep...@bugs.python.org
Changes by Mark Dickinson dicki...@gmail.com:
--
assignee: - mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14339
___
___
Mark Dickinson dicki...@gmail.com added the comment:
Thanks for the updates.
The same assumption is used above in long_to_decimal_string(). I added
the same assert and changed maxchar to 'f'.
I think 'x' would be more appropriate. :-)
--
___
Serhiy Storchaka storch...@gmail.com added the comment:
I think 'x' would be more appropriate. :-)
Oops. You are right, of cause.
--
Added file: http://bugs.python.org/file25234/long_to_binary_base_3.patch
___
Python tracker rep...@bugs.python.org
Martin v. Löwis mar...@v.loewis.de added the comment:
(1) The patch appears to assume that a Unicode string created with
PyUnicode_New(size, 127) will have 'kind' PyUnicode_1BYTE_KIND.
While this might be true in the current implementation, I don't know
whether this is guaranteed in general.
Mark Dickinson dicki...@gmail.com added the comment:
There is a guarantee that the shortest form must always be used.
Okay, sounds good. Thanks.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14339
Mark Dickinson dicki...@gmail.com added the comment:
A few comments:
(1) The patch appears to assume that a Unicode string created with
PyUnicode_New(size, 127) will have 'kind' PyUnicode_1BYTE_KIND. While this
might be true in the current implementation, I don't know whether this is
Serhiy Storchaka storch...@gmail.com added the comment:
(1) The patch appears to assume that a Unicode string created with
PyUnicode_New(size, 127) will have 'kind' PyUnicode_1BYTE_KIND. While this
might be true in the current implementation, I don't know whether this is
guaranteed in
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +ezio.melotti
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14339
___
___
Serhiy Storchaka storch...@gmail.com 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
Antoine Pitrou pit...@free.fr added the comment:
While optimizing stuff is nice, I'm not sure there's a use case here. Does it
significantly speed up a real-world workload you're having?
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
New submission from Serhiy Storchaka storch...@gmail.com:
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:
$
Changes by Antoine Pitrou pit...@free.fr:
--
components: +Interpreter Core -Library (Lib)
nosy: +mark.dickinson, skrah
stage: - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14339
Changes by Eric V. Smith e...@trueblade.com:
--
nosy: +eric.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14339
___
___
Python-bugs-list
24 matches
Mail list logo
