Alexander Belopolsky added the comment:
r82301 appears to be a blind merge of r82120 from the trunk. It is fairly
obvious that it was not intentional.
--
___
Python tracker
<http://bugs.python.org/issue4
Changes by Alexander Belopolsky :
--
nosy: +akuchling
___
Python tracker
<http://bugs.python.org/issue4153>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Alexander Belopolsky :
--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file19633/issue7828.diff
___
Python tracker
<http://bugs.python.org/iss
Alexander Belopolsky added the comment:
Committed in r86526 (3.2) and r86527 (3.1).
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Alexander Belopolsky added the comment:
On Thu, Nov 18, 2010 at 2:41 PM, Terry J. Reedy wrote:
..
> I visually parse 0-1,114,111 as 0-1, 114, 111. So I think either the commas
> should be removed or extra spaces are needed: 0-1114111 or 0 - 1,114,111.
What about "0 through 1,114,1
Alexander Belopolsky added the comment:
On Thu, Nov 18, 2010 at 3:00 PM, Alexander Belopolsky
wrote:
..
>> I really think of them as hex or hexadecimal digits, just as 0-9 are
>> decimal, not base 10 digits.
>>
>
> I am fine with "hexadecimal" here. I did n
Alexander Belopolsky added the comment:
On Thu, Nov 18, 2010 at 2:37 AM, Ron Adam wrote:
..
> I'll try reading and writing directly to the socket and working up some tests
> from that.
> I don't suppose there's something like that already in the test suite I can
&g
Alexander Belopolsky added the comment:
issue2001_b.diff patch includes changes to urllib. Is this intentional? Is it
a bug fix, a feature? There is no mention in the NEWS file. If these changes
are needed for pydoc enhancements, I would like to separate them in its own
issue and commit
Alexander Belopolsky added the comment:
issue2001_c.diff is the same as issue2001_b.diff, but without urlparse changes
and with minor modifications to pydoc.rst resolving a conflict with a recent
commit. I have also uploaded the same patch to rietveld:
http://codereview.appspot.com/3187042
Alexander Belopolsky added the comment:
There is an ongoing discussion about deprecating undocumented
PyUnicode_AppendAndDel(). See Marc-Andre's comment in msg121371:
"""
+.. c:function:: void PyUnicode_Append(PyObject **pleft, PyObject *right)
+
+ Concat two strings a
Alexander Belopolsky added the comment:
Committed in revision 86530. Thanks Terry and Raymond for your comments. I
would like to keep this issue open (at a low priority) because the question in
the titles is still relevant. There are many new 3.x features that are not
covered such as
Alexander Belopolsky added the comment:
+1
BTW, I've updated examples in Unicode HOWTO to use with.
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/is
Alexander Belopolsky added the comment:
I don't understand Victor's argument in msg115889. According to UTF-8 RFC,
<http://www.ietf.org/rfc/rfc2279.txt>:
- US-ASCII values do not appear otherwise in a UTF-8 encoded
character stream. This provides compatibility w
Alexander Belopolsky added the comment:
On Fri, Nov 19, 2010 at 3:06 PM, STINNER Victor wrote:
> .. Whereas PyUnicode_FromFormatV() converts the format string
> (bytes) to unicode (characters). If you would like a comparaison in C, it's
> like printf()+mbstowcs() in the same func
Alexander Belopolsky added the comment:
On Fri, Nov 19, 2010 at 7:15 PM, STINNER Victor wrote:
..
>
> Why should we do that? ASCII format is just fine. Remember that
> PyUnicode_FromFormatV() is part of the C API. I don't think that anyone would
> use non-ASCII format in C.
Alexander Belopolsky added the comment:
Committed in revision 86594.
--
resolution: -> accepted
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Alexander Belopolsky added the comment:
FWIW, I find the "with" variant much easier to read than
>>> words = re.findall('\w+', open('hamlet.txt').read().lower())
Too many operations in one line. It would be even better with
>>
Changes by Alexander Belopolsky :
--
Removed message: http://bugs.python.org/msg121711
___
Python tracker
<http://bugs.python.org/issue10461>
___
___
Python-bug
Changes by Alexander Belopolsky :
--
status: pending -> closed
___
Python tracker
<http://bugs.python.org/issue1646068>
___
___
Python-bugs-list mailing list
Un
Alexander Belopolsky added the comment:
LGTM
--
___
Python tracker
<http://bugs.python.org/issue9305>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Alexander Belopolsky :
--
assignee: d...@python -> belopolsky
stage: needs patch -> commit review
___
Python tracker
<http://bugs.python.org/
Alexander Belopolsky added the comment:
On the second reading, I have a few issues with the patch.
1. Please run makepatcheck. There are whitespace issues in datetime.rst.
2. In docstrings, you remove the information about the sign. I would not mind
leaving docstrings the way they are
Alexander Belopolsky added the comment:
SilentGhost,
Benjamin's fix only affect the optimized path when the argument is int or bool.
Exotic comparison rules are handled in the else clause.
--
nosy: +belopolsky
___
Python tracker
Changes by Alexander Belopolsky :
--
resolution: -> duplicate
status: open -> closed
superseder: -> Document unicode C-API in reST
___
Python tracker
<http://bugs.python.o
Changes by Alexander Belopolsky :
--
resolution: -> duplicate
status: open -> closed
superseder: -> Document unicode C-API in reST
___
Python tracker
<http://bugs.python.o
Changes by Alexander Belopolsky :
--
resolution: -> duplicate
superseder: -> Document unicode C-API in reST
___
Python tracker
<http://bugs.python.org/
Alexander Belopolsky added the comment:
On Sun, Nov 21, 2010 at 1:24 PM, Rodrigo Bernardo Pimentel
wrote:
..
> I was writing tests for this issue, when something struck me: ok,
> datetime(year, month, day, 24) is valid.
> But is datetime(year, month, day, 24, 1) valid? Or datetime(ye
Alexander Belopolsky added the comment:
On Sun, Nov 21, 2010 at 3:48 PM, Mark Dickinson wrote:
..
> Well, if all that's wanted is for hour==24 to be legal on input, with the
> datetime object
> itself being automatically normalized at creation time, then the choices seem
>
Alexander Belopolsky added the comment:
AssertionError: strftime does not support standard '%d' format (day of month as
number (00-31))
Sounds pretty self-explainatory. I kind of doubt, however, that OpenIndiana's
strftime is that broken. Jesús,
Alexander Belopolsky added the comment:
+0
Not "+1" because Georg suggested that this demo be removed. See
http://mail.python.org/pipermail/python-ideas/2010-October/008416.html
On the patch, I would define a "usage" variable near the top of the program
instead of repe
Alexander Belopolsky added the comment:
The following passes tests in elp_8525.patch, but is much simpler:
===
--- Lib/pydoc.py(revision 86600)
+++ Lib/pydoc.py(working copy)
@@ -1139,6 +1139,15
Changes by Alexander Belopolsky :
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue10138>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Alexander Belopolsky :
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue10087>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
See also #10087.
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue10498>
___
___
Python-bugs-list m
Alexander Belopolsky added the comment:
The patch makes sense. I wonder if i10n of programs using argparse should be
mentioned in docs. Providing a sample translation file somewhere may not be a
bad idea at least for testing.
--
nosy: +belopolsky
Alexander Belopolsky added the comment:
Fixed in revision 86669.
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Alexander Belopolsky added the comment:
It may be acceptable, but your patch elides the line breaks in output. Can you
add unit tests?
--
___
Python tracker
<http://bugs.python.org/issue10
Alexander Belopolsky added the comment:
On Mon, Nov 22, 2010 at 9:48 AM, Chris Lambacher wrote:
..
> I don't understand what you mean by "elides the line breaks in output".
It is actually not that bad:
$ ./python.exe -m calendar -t html| wc -l
121
$ python2.7 -m calen
Alexander Belopolsky added the comment:
On Mon, Nov 22, 2010 at 11:55 AM, Chris Lambacher
wrote:
..
> 1. Any suggestions about how to test the output of the console program (the
> case that this bug affects)
> would be appreciated.
For month displays, a doctest may be most appropr
Alexander Belopolsky added the comment:
On Wed, Nov 17, 2010 at 5:20 PM, Marc-Andre Lemburg
wrote:
..
> -/* Encodes a Unicode object and returns the result as Python string
> +/* Encodes a Unicode object and returns the result as Python bytes
> object. */
>
>
> PyUnico
Alexander Belopolsky added the comment:
Committed in r86697 (3.2) and r86698 (3.1).
@Éric: I tried to minimize whitespace changes in the commit, but if you see
indentation that can be improved, let me know and I'll fix it separately.
@SilentGhost: Yes, the problem is real. For ex
Changes by Alexander Belopolsky :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Alexander Belopolsky added the comment:
I wonder: do we really need "encoding" option to the calendar output? It is
really not the job of the calendar module to deal with encodings. The calendar
module should produce text calendars as unicode strings and HTML calendars as
UTF-8
Alexander Belopolsky added the comment:
The proposal is to display builtin subclasses as for example:
>>> help(ArithmeticError)
class ArithmeticError(Exception)
| Base class for arithmetic errors.
|
| Method resolution order:
| ArithmeticError
|
New submission from Alexander Belopolsky :
>>> 'xyz'.center(20, '\U00100140')
Traceback (most recent call last):
File "", line 1, in
TypeError: The fill character must be exactly one character long
str.ljust and str.rjust are similarly affected.
Alexander Belopolsky added the comment:
On Wed, Nov 24, 2010 at 10:33 AM, Antoine Pitrou wrote:
..
> The question is, what should it do with such an input?
I think the rule for such functions should be that if
input.encode('utf-8') is the same on wide and narrow builds, then the
Alexander Belopolsky added the comment:
On Wed, Nov 24, 2010 at 3:37 PM, Marc-Andre Lemburg
wrote:
..
> I don't think we should change that for the formatting methods.
That's a reasonable position. What about
'Lo'
>>> '\N{OLD ITALIC LETTER A}'.is
Alexander Belopolsky added the comment:
On Wed, Nov 24, 2010 at 3:37 PM, Marc-Andre Lemburg
wrote:
..
> I don't think we should change that for the formatting methods.
That's a reasonable position. What about
>>> unicodedata.category('\N{OLD ITALIC LETTER A}'
Changes by Alexander Belopolsky :
--
Removed message: http://bugs.python.org/msg122313
___
Python tracker
<http://bugs.python.org/issue10521>
___
___
Python-bug
Alexander Belopolsky added the comment:
Here is another str method not ready for non-BMP chars:
>>> u = '\U00010140'
>>> u.translate({ord(u):ord('A')})
'𐅀'
(expected 'A')
>>> u = 'B'
>>> u.translate({ord
Alexander Belopolsky added the comment:
Here is another proof of concept patch for the isalpha issue that introduces a
higher level abstraction macro - Py_UNICODE_NEXT. It should be possible to
reuse this macro in all isxyz methods and other places where surrogates are
currently processed
New submission from Alexander Belopolsky :
As discussed in issue 10521 and the sprawling "len(chr(i)) = 2?" thread [1] on
python-dev, many functions in python library behave differently on narrow and
wide builds. While there are unavoidable differences such as the length of
string
Alexander Belopolsky added the comment:
AFAICT, all ctype methods (isalpha, isdigit, etc.) have the same problem. I
posted a patch at issue10542 that introduces a Py_UNICODE_NEXT() macro that can
help fixing all these methods. I am adding #10542 as a dependency and if there
are no
Changes by Alexander Belopolsky :
--
nosy: +haypo, loewis
___
Python tracker
<http://bugs.python.org/issue10542>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
On Fri, Nov 26, 2010 at 6:37 PM, Terry J. Reedy wrote:
>
> Terry J. Reedy added the comment:
>
> As a practical matter, I think that for at least the next decade, people are
> at least as likely to
> want to fill with a composed, m
Alexander Belopolsky added the comment:
On Fri, Nov 26, 2010 at 7:27 PM, Eric Smith wrote:
..
>
> In addition to the proposed Py_UNICODE_NEXT and Py_UNICODE_PUT_NEXT,
> > str.__format__ would also need a function that tells it how many Py_UNICODEs
> are needed to store a give
Alexander Belopolsky added the comment:
On Fri, Nov 26, 2010 at 7:45 PM, Eric Smith wrote:
..
> For my use I'd really need it to take the result of Py_UNICODE_NEXT.
> Something like:
> Py_ssize_t
> Py_UNICODE_NUM_NEEDED(Py_UCS4 c)
> and it would always return 1 or 2. Alway
Alexander Belopolsky added the comment:
Attached patch fixes isprintable and other ctype-like methods. I left
isspace() out for now because I could not find a test character outside of BMP
to test with, but I think we should fix that for completeness as well.
At this point the goal is
Alexander Belopolsky added the comment:
On Fri, Nov 26, 2010 at 8:41 PM, STINNER Victor wrote:
..
> I don't like macro having a result and using multiple instructions using the
> evil
> magic trick (the ","). It's harder to maintain the code and harder to debug
Alexander Belopolsky added the comment:
On Fri, Nov 26, 2010 at 9:22 PM, Eric Smith wrote:
..
> But I definitely agree that we should get the abstraction right first and
> worry about
> the implementation later.
I am fairly happy with Py_UNICODE_NEXT() abstraction. It's seman
Alexander Belopolsky added the comment:
Raymond,
I wonder if you would like to comment on the iterator analogy and/or on adding
public names to C API.
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue10
Alexander Belopolsky added the comment:
Apparently something in the test changes the cwd.
Both of the following invocations work:
$ ./python.exe `pwd`/Lib/test/regrtest.py -T -N test_urllib
$ ./python.exe -m test.regrtest -T -N test_urllib
I would suggest changing the coverage target in the
Alexander Belopolsky added the comment:
Confirmed in py3k.
--
assignee: -> belopolsky
nosy: +belopolsky
stage: -> needs patch
type: -> behavior
___
Python tracker
<http://bugs.python.or
Alexander Belopolsky added the comment:
The fix is simple:
--- Lib/pydoc.py(revision 86824)
+++ Lib/pydoc.py(working copy)
@@ -1110,7 +1110,7 @@
result = result + self.section('FILE', file)
return result
-def docclass(self, object, name=None
Alexander Belopolsky added the comment:
I would like to investigate this some more. In theory, regrtest should restore
cwd before coverage results are written.
--
status: pending -> open
___
Python tracker
<http://bugs.python.org/issu
New submission from Alexander Belopolsky :
$ ../../python.exe gencodec.py MAPPINGS/VENDORS/MISC/ build/
converting APL-ISO-IR-68.TXT to build/apl_iso_ir_68.py and
build/apl_iso_ir_68.mapping
converting ATARIST.TXT to build/atarist.py and build/atarist.mapping
converting CP1006.TXT to build
Changes by Alexander Belopolsky :
--
dependencies: +Tools/unicode/gencodec.py error
___
Python tracker
<http://bugs.python.org/issue7962>
___
___
Python-bug
Alexander Belopolsky added the comment:
Attached patch addresses the issue by using -1 instead of None for missing
codes. Comparison of generated encoding files to those in Lib/encodings shows
only whitespace changes except one which appears to be a change on the
unicode.org side:
diff -b
Alexander Belopolsky added the comment:
On Sat, Nov 27, 2010 at 5:03 PM, Marc-Andre Lemburg
wrote:
.. [I'll respond to skipped when I update the patch]
> In any case, we should clearly document where these macros are used and
> warn about the implications of using them in the w
Alexander Belopolsky added the comment:
On Sat, Nov 27, 2010 at 5:03 PM, Marc-Andre Lemburg
wrote:
..
> * same for the Py_UNICODE_NEXT() macro, i.e. Py_UCS4_NEXT()
>
> * in order to make the macro easier to understand, please rename it to
> Py_UCS4_READ_CODE_POINT(); that
Alexander Belopolsky added the comment:
Attached patch uses MISSING_CODE as Mark suggested. There are still errors
apparently because parsecodes() may return either an int or a tuple. I think
only mac encodings are affected, so I would like to commit the current patch
before tackling this
Alexander Belopolsky added the comment:
Please ignore Makefile changes in the patch.
--
___
Python tracker
<http://bugs.python.org/issue10552>
___
___
Python-bug
Alexander Belopolsky added the comment:
On Sat, Nov 27, 2010 at 5:41 PM, Ezio Melotti wrote:
>
> Ezio Melotti added the comment:
>
>> * the Py_UNICODE_JOIN_SURROGATES() macro should use Py_UCS4 as prefix since
>> it returns Py_UCS4 values, i.e. Py_UCS4_JOIN_SURROGATE
Alexander Belopolsky added the comment:
I am attaching a patch that defines Py_UNICODE_PUT_NEXT() macro (tentative
name) and uses it to fix str.upper method. The implementation of
surrogate-aware str.upper shows that NEXT/PUT_NEXT abstractions may lead to
somewhat inefficient code for &qu
New submission from Alexander Belopolsky :
>>> float('½')
Traceback (most recent call last):
File "", line 1, in
ValueError: could not convert string to float: �
>>> float('42½')
Traceback (most recent call last):
File "", line 1,
Alexander Belopolsky added the comment:
-#!/usr/bin/env python
+#!/usr/bin/env python3
# -*- coding: UTF-8 -*-
Not strictly related to this issue, but do we want to recommend
redundant encoding cookie in the docs?
--
___
Python tracker
Alexander Belopolsky added the comment:
On Sun, Nov 28, 2010 at 11:37 AM, Mark Dickinson wrote:
>
> Mark Dickinson added the comment:
>
>> I am not sure, whether support for non-ascii digits in float()
>> constructor is worth maintaining.
>
> I'd be very hap
Alexander Belopolsky added the comment:
On Sun, Nov 28, 2010 at 12:00 PM, Mark Dickinson wrote:
>
> Mark Dickinson added the comment:
>
> About Alexander's solution: might it make more sense to have
> PyUnicode_EncodeDecimal raise
> for inputs like this?
No, I thin
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue10567>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
The category of U-200B was changed in Unicode 4.0.1:
"""
The main new features in Unicode 4.0.1 are the following:
...
* Changed: general category of U+200B ZERO WIDTH SPACE
""" http://unicode.org/versions/Unicod
Alexander Belopolsky added the comment:
Issue #10567 demonstrated the problem of relying on the Unicode
database in Python builtins. Apparently, Unicode does not guarantee
stability of the character categories. On the other hand, we are
already tied to UCD for the language definition. Maybe
Alexander Belopolsky added the comment:
On Sun, Nov 28, 2010 at 2:07 PM, Marc-Andre Lemburg
wrote:
..
> The tables were never manually maintained, but we also did not update
> Python for each new Unicode version:
>
> Python 1.6: Unicode 3.0
> Python 2.0: Unicode 3.0
> Pytho
Alexander Belopolsky added the comment:
On Sun, Nov 28, 2010 at 2:40 PM, Marc-Andre Lemburg
wrote:
..
> Going back further shows the change:
>
> 3.0.1: 200B;ZERO WIDTH SPACE;Zs;0;BN;N;
> 3.2.0: 200B;ZERO WIDTH SPACE;Zs;0;BN;N;
> 4.0.1: 200B;ZERO WIDTH SPAC
New submission from Alexander Belopolsky :
Two recently reported issues brought into light the fact that Python
language definition is closely tied to character properties maintained
by the Unicode Consortium. [1,2] For example, when Python switches to
Unicode 6.0.0 (planned for the upcoming
Alexander Belopolsky added the comment:
On Sun, Nov 28, 2010 at 3:09 PM, Stefan Krah wrote:
..
> Decimal point: U+066B
Well, not so fast:
Traceback (most recent call last):
File "", line 1, in
UnicodeEncodeError: 'decimal' codec can't encode character &#x
Alexander Belopolsky added the comment:
This was meant as python-dev post, not an issue. (Sent to wrong address by
mistake.)
--
nosy: +belopolsky
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Alexander Belopolsky added the comment:
On Sun, Nov 28, 2010 at 3:30 PM, Stefan Krah wrote:
..
>> UnicodeEncodeError: 'decimal' codec can't encode character '\u066b'
>
> Hmm, looks like a bug? I think U+066B is correct.
>
Really? What about
Traceback
Alexander Belopolsky added the comment:
Sending this by e-mail was not a good idea ...
On Sun, Nov 28, 2010 at 3:30 PM, Stefan Krah wrote:
..
>> UnicodeEncodeError: 'decimal' codec can't encode character '\u066b'
>
> Hmm, looks like a bug? I think U+0
Changes by Alexander Belopolsky :
--
Removed message: http://bugs.python.org/msg122725
___
Python tracker
<http://bugs.python.org/issue10557>
___
___
Python-bug
Alexander Belopolsky added the comment:
Why not allow complex('1i')?
(Tongue in cheek: I am really looking for arguments against lax parsing in
number builtins. See issue 10557.)
--
nosy: +belopolsky
___
Python tracker
<http://bu
Alexander Belopolsky added the comment:
On Sun, Nov 28, 2010 at 3:58 PM, Mark Dickinson wrote:
..
> I'd expect to allow complex('3 + 4i') as well.
And with spaces surrounding '+' too.
--
___
Python tracker
<ht
Alexander Belopolsky added the comment:
This looks like a bug in the underlying platform. POSIX requires [1] that the
output of ctime() fits in a 26-character buffer. Note that a change has been
recently made to time.asctime() to reject year > . See r85137 and
issue6608. I think
Changes by Alexander Belopolsky :
--
assignee: -> belopolsky
stage: unit test needed -> needs patch
type: -> feature request
versions: +Python 3.2 -Python 2.6, Python 2.7, Python 3.1
___
Python tracker
<http://bugs.python.or
Changes by Alexander Belopolsky :
--
nosy: +belopolsky
___
Python tracker
<http://bugs.python.org/issue10544>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
Isn't this the same issue as #3267?
--
___
Python tracker
<http://bugs.python.org/issue10544>
___
___
Python-bugs-l
Alexander Belopolsky added the comment:
After a bit of svn archeology, it does appear that Arabic-Indic digits' support
was deliberate at least in the sense that the feature was tested for when the
code was first committed. See r15000.
The test migrated from file to file over the la
Alexander Belopolsky added the comment:
On Mon, Nov 29, 2010 at 4:41 AM, Marc-Andre Lemburg
wrote:
..
> It would be better to copy and iterate over the Unicode string first,
> replacing any decimal code points with ASCII ones and then call the
> UTF-8 encoder.
>
Good idea.
>
Alexander Belopolsky added the comment:
+0, and I think we should hear from the maintainers of the affected packages
first. For packages that are also externally maintained moving tests out may
cause inconvenience to the maintainer.
--
nosy: +barry, belopolsky, brett.cannon
Changes by Alexander Belopolsky :
--
nosy: +gpolo
___
Python tracker
<http://bugs.python.org/issue10572>
___
___
Python-bugs-list mailing list
Unsubscribe:
Alexander Belopolsky added the comment:
I am adding #10552 as a dependency because I think we should fix unicode data
generation in 3.x before adding new features to the scripts.
I am also not sure whether this is a bug or a feature request. Martin?
--
dependencies: +Tools/unicode
501 - 600 of 3596 matches
Mail list logo
