Walter Dörwald added the comment:
Fixed in r57620
--
nosy: +doerwalter
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Walter Dörwald added the comment:
Because it's not clear whether b'\xa0' *is* whitespace or not. Bytes
have no meaning, characters do.
--
nosy: +doerwalter
__
Tracker <[EMAIL PROTECTED]>
<http://b
Walter Dörwald added the comment:
"xml-auto-detect" sounds OK to me, it even makes sense for the encoder,
because it normally detects the encoding to use for writing from the XML
declaration.
We could put "xml-auto-detect" into the alias mapping and keep xml as
the module na
Walter Dörwald added the comment:
OK, I've changed the name of the codec to xml_auto_detect and added
support for EBCDIC.
Added file: http://bugs.python.org/file8717/diff2.txt
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python
Walter Dörwald added the comment:
Fixed in r58942 (trunk) and r58943 (2.5). Closing the issue.
--
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Walter Dörwald added the comment:
jgsack wrote:
>
> If codec utf_8 or utf_8_sig were to accept input with or without the
> 3-byte BOM, and write it as currently specified without/with the BOM
> respectively, then _I_ can reread again with either utf_8 or utf_8_sig.
That's
Walter Dörwald added the comment:
> For utf16, (arguably) a missing BOM should merely assume machian
endianess.
> For utf_16_le, utf_16_be input, both should accept & discard a BOM.
> On output, I'm not sure; maybe all should write a BOM unless passed a flag
> signifying no
Walter Dörwald added the comment:
Checked in your change and the test as r59049 (trunk) and r59050 (2.5).
Thanks for the patch.
--
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Walter Dörwald added the comment:
Can you attach a (small) example that demonstrates the bug?
--
nosy: +doerwalter
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/
Walter Dörwald added the comment:
+1 on the documentation changes.
--
nosy: +doerwalter
___
Python tracker
<http://bugs.python.org/issue12171>
___
___
Python-bug
Walter Dörwald added the comment:
Does the following patch fix your problems?
--
keywords: +patch
nosy: +doerwalter
Added file: http://bugs.python.org/file19217/calendar.diff
___
Python tracker
<http://bugs.python.org/issue10
Walter Dörwald added the comment:
The following patch (against the release27-maint branch) seems to fix the
problem.
--
keywords: +patch
nosy: +doerwalter
Added file: http://bugs.python.org/file19468/json.diff
___
Python tracker
<h
New submission from Walter Dörwald :
It seems that on Python 3 (i.e. the py3k branch) trace.py can not handle source
that includes Unicode characters. Running the test suite with code coverage
info via
./python Lib/test/regrtest.py -T -N -uurlfetch,largefile,network,decimal
sometimes
Walter Dörwald added the comment:
Using the original encoding of the Python source file might be the politically
correct thing to do, but it complicates handling of the output of trace.py. For
each file you have to do the encoding detection dance again. It would be great
if I could specify
Walter Dörwald added the comment:
> STINNER Victor added the comment:
>
>> ... it complicates handling of the output of trace.py.
>> For each file you have to do the encoding detection dance again ...
>
> What? You just have to call one function! tokenize.open() :
New submission from Walter Dörwald :
Running regrtest.py with coverage option seems to be broken for the py3k branch
at the moment. Run the following commands on the shell:
wget http://svn.python.org/snapshots/python3k.tar.bz2
tar xjf python3k.tar.bz2
cd python
./configure --enable-unicode
Walter Dörwald added the comment:
OK, I reran the test with::
./python -mtest.regrtest -T -N test_urllib
and this does indeed produce coverage files (for _abcoll, _weakrefset, abc,
base64, codecs, collections, contextlib, functools, genericpath, hashlib,
locale, mimetypes, os, posixpath
Walter Dörwald <[EMAIL PROTECTED]> added the comment:
Fixed for 2.6 in r63899.
--
nosy: +doerwalter
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Walter Dörwald <[EMAIL PROTECTED]> added the comment:
Fixed for 3.0 in r63918
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1706460>
___
__
Walter Dörwald <[EMAIL PROTECTED]> added the comment:
AFAIK reload() is gone in 3.0 anyway, so I don't think this patch is
relevant any longer.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
New submission from Walter Dörwald <[EMAIL PROTECTED]>:
The encoder for the "unicode-internal" codec reports the wrong length:
Python 3.0b3+ (py3k, Aug 30 2008, 11:55:21)
[GCC 4.0.1 (Apple Inc. build 5484)] on darwin
Type "help", "copyright", "c
Walter Dörwald added the comment:
On 24.02.10 15:28, Eric Smith wrote:
> Eric Smith added the comment:
>
> Fixed:
>
> trunk: r78418
> release26-maint: r78419
>
> Still working on porting to py3k and release31-maint.
A much better solution would IMHO be to for
New submission from Walter Dörwald :
In the current py3k branch setting an attribute of an object with PyMemberDefs
raises an internal error:
$ ./python.exe
Python 3.2a0 (py3k:78419M, Feb 24 2010, 17:56:06)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright
Walter Dörwald added the comment:
After the patch the comment:
/* Implementation limitations: only support error handler that return
bytes, and only support up to four replacement bytes. */
no longer applies.
Also I would like to see a version of this patch where the length limitation
Walter Dörwald added the comment:
This is a common thinko. ;)
If i is negative then len(s) - i would be greater that len(s). However len(s) +
i is correct. Example:
foo[-1] is foo[len(foo) + (-1)] is foo[len(foo)-1]
--
nosy: +doerwalter
resolution: -> invalid
status: o
Walter Dörwald added the comment:
Yes, that's the posting I was referring to. I wonder why the link is gone.
--
___
Python tracker
<http://bugs.python.org/i
Walter Dörwald added the comment:
Fixed in r60618 (trunk) and r60619 (release25-maint)
--
nosy: +doerwalter
resolution: -> fixed
status: open -> closed
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Walter Dörwald added the comment:
setfirstweekday() isn't supposed to have any influence on calendar
objects created explicitely. The function setfirstweekday() is only for
the module level interface. The documentation is wrong here. However you
*can* change the first weekday wit
Walter Dörwald added the comment:
You're supposed to use firstweekday as a property instead of using the
getter method getfirstweekday(). Anyway this is fixed now in r60651
(trunk) and r60652 (release25-maint)
--
resolution: accepted -> fixed
status: open -
Walter Dörwald added the comment:
The doccumentation is
here:http://docs.python.org/dev/library/calendar.html#calendar.TextCalendar.formatmonth
(or in Doc/library/calendar.rst in the source).
Anyway the first of those documentation bugs is fixed now in r60649
(trunk) and r60650 (release25-maint
Walter Dörwald <[EMAIL PROTECTED]> added the comment:
There was resistance in python-dev against this patch (see the thread at
http://mail.python.org/pipermail/python-dev/2007-November/075138.html),
so this issue should probably closed as rejected.
However there was consensus,
Walter Dörwald <[EMAIL PROTECTED]> added the comment:
I don't see exactly what James is proposing.
> For my needs, I would like the decoding parts of the utf_8 module
> to treat an initial BOM as an optional signature and skip it if
> there is one (just like the utf_8_sig
Walter Dörwald <[EMAIL PROTECTED]> added the comment:
For a wide build, the code
if (x <= 0x)
*p++ = (Py_UNICODE) x;
else {
*p++ = (Py_UNIC0DE) x;
looks strange.
Furthermore with the patch applied Python no longer complains about
ill
Walter Dörwald <[EMAIL PROTECTED]> added the comment:
The patch looks goog to me now. Go ahead and check it in.
--
assignee: doerwalter -> amaury.forgeotdarc
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.py
Walter Dörwald <[EMAIL PROTECTED]> added the comment:
If you want to use UTF-8-sig for decoding and UTF-8 for encoding and
have this available as one codec you can define your owen codec for this:
import codecs
def search_function(name):
if name == "myutf8":
utf8
Walter Dörwald <[EMAIL PROTECTED]> added the comment:
Oops, that code was supposed to read:
import codecs
def search_function(name):
if name == "myutf8":
utf8 = codecs.lookup("utf-8")
utf8_sig = codecs.lookup("utf-8-sig")
retur
Walter Dörwald <[EMAIL PROTECTED]> added the comment:
I agree that the documentation should be fixed to read "encode/decode"
instead of "encoder/decoder".
___
Python tracker <[EMAIL PROTECTED]>
&
Walter Dörwald <[EMAIL PROTECTED]> added the comment:
Fixed in r67005 (trunk) and r67006 (pk3k).
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Walter Dörwald added the comment:
The patch looks fine to me. Tests pass.
I have no opinion about the name. Both "simplegeneric" and "generic" are
OK to me.
I wonder if being able to use register() directly instead of as a
decorator should be dropped.
Also IMHO the
Walter Dörwald added the comment:
It does indeed work with Python 2.6 (however not with 2.5). Closing.
--
resolution: -> out of date
status: open -> closed
___
Python tracker
<http://bugs.python.org/iss
Walter Dörwald added the comment:
The patch doesn't include any changes to the documentation.
--
nosy: +doerwalter
___
Python tracker
<http://bugs.python.org/i
Walter Dörwald added the comment:
The documentation might be unclear here. But the argument iterator of
iterdecode(iterator, encoding, errors='strict', **kwargs)
*is* supposed to be an iterable over bytes objects.
In fact iterencode() transforms an iterator over strings into a
Walter Dörwald added the comment:
codecs.iterencode()/iterdecode() are just shallow 10-line wrappers around
incremental codecs (which are used as the basis of io streams).
Note that the doc string for iterencode() contains:
Encodes the input strings from the iterator using an
Walter Dörwald added the comment:
The original specification (PEP 293) required that an error handler called for
encoding *must* return a replacement string (not bytes). This returned string
must then be encoded again. Only if this fails an exception must be raised.
Returning bytes from the
Walter Dörwald added the comment:
IMHO the names don't fit Pythons current naming scheme, so what about naming
them "lchop" and "rchop"?
--
nosy: +doerwalter
___
Python tracker
<https:
Walter Dörwald added the comment:
Shadowing the real modules `re` and `io` by
from typing import *
would indeed be bad, but that argument IMHO doesn't hold for the types `IO`,
`TextIO` and `BinaryIO`, yet they are not listed in `typing.__all__`. Is there
a reason for that? And i
Walter Dörwald added the comment:
Just a guess, but the buffer size might be so small that the text that you
expect gets passed via **two** calls to _char_data(). You should refactor your
code the simply collect all the text in _char_data() and act on it in the
_end_element() handler.
So
Walter Dörwald added the comment:
New changeset 85339f5c220a5e79c47c3a33c93f1dca5c59c52e by Srinivas Reddy
Thatiparthy (శ్రీనివాస్ రెడ్డి తాటిపర్తి) in branch 'master':
bpo-35078: Allow customization of CSS class name of a month in calendar module
(gh-10137)
https://github.
Change by Walter Dörwald :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Walter Dörwald added the comment:
UnicodeEncodeError and UnicodeDecodeError are used to report un(en|de)codedable
ranges in the source object, so it wouldn't make sense to use them for errors
that have nothing to do with problems in the source object. Their constructor
requires 5 argu
New submission from Walter Dörwald :
PEP 293 states the following:
"""
For stream readers/writers the errors attribute must be changeable to be able
to switch between different error handling methods during the lifetime of the
stream reader/writer. This is current
Walter Dörwald added the comment:
I guess that is good enough. "Being changeable" does not necessarily mean mean
"being changeable via attribute assignment".
Thanks for your research. Closing the issue as "not a bug".
--
resolution: -> not a bug
Walter Dörwald added the comment:
See this ancient posting about this problem:
http://mail.python.org/pipermail/python-dev/2002-August/027661.html
(see point 4.). So I guess somebody did finally complain! ;)
The error attributes are documented in PEP 293. The existence of the attributes
Walter Dörwald added the comment:
Can we at least get the __qualname__ in exception messages?
Currently enum.Enum.__new__() and enum.Enum._missing_() use:
raise ValueError("%r is not a valid %s" % (value, cls.__name__))
IMHO this should be:
raise ValueError("%r is
Change by Walter Dörwald :
--
pull_requests: +14603
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/14809
___
Python tracker
<https://bugs.python.org/issu
Changes by Walter Dörwald :
--
pull_requests: +2463
___
Python tracker
<http://bugs.python.org/issue30733>
___
___
Python-bugs-list mailing list
Unsubscribe:
Walter Dörwald added the comment:
New changeset f5c58c781aa0bb296885baf62f4f39100f2cd93d by Walter Dörwald in
branch 'master':
bpo-30733: Fix typos in "What's New" entry (GH-2414)
https://github.com/python/cpython/commit/f5c58c781aa0bb296885baf62f4f39100f2cd93d
---
Walter Dörwald added the comment:
Should be fixed now. Thanks for noticing it.
--
resolution: -> fixed
___
Python tracker
<http://bugs.python.org/issu
Changes by Walter Dörwald :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue30733>
___
___
Python-bugs-list
Change by Walter Dörwald :
--
pull_requests: +10390
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issue2661>
___
___
Python-
Walter Dörwald added the comment:
OK, I've created the pull request (11157).
--
___
Python tracker
<https://bugs.python.org/issue2661>
___
___
Python-bugs-l
Walter Dörwald added the comment:
This looks to me like a limited reimplementation of the codec machinery. Why
not use incremental codecs as a preprocessor? Would this be to slow?
--
___
Python tracker
<http://bugs.python.org/issue18
Walter Dörwald added the comment:
IMHO this could all be done by overwriting the relevant methods.
But this might be overkill.
I think a solution might be to move the CSS classes into class attributes of
HTMLCalendar. Customizing the CSS classes would then be done by subclassing
HTMLCalendar
Walter Dörwald added the comment:
OK, go ahead. I'm looking forward to what you come up with.
--
___
Python tracker
<http://bugs.python.org/issue30095>
___
___
Walter Dörwald added the comment:
The second link is a 404.
For the v1 patch:
The variable names are a bit inconsistent: The first uses "classes" all others
use "styles". This should be consistent within itself and with the existing
code, i.e. "classes" sh
Walter Dörwald added the comment:
See comments on Github
--
___
Python tracker
<http://bugs.python.org/issue30095>
___
___
Python-bugs-list mailing list
Unsub
Walter Dörwald added the comment:
See my comments on the pull request: https://github.com/python/cpython/pull/1439
After you address those, IMHO this is ready to be merged.
--
___
Python tracker
<http://bugs.python.org/issue30
Walter Dörwald added the comment:
See comments on the pull request. Also it seems that currently the pull request
can't be merged because of merge conflicts.
--
___
Python tracker
<http://bugs.python.org/is
Walter Dörwald added the comment:
New changeset 8b7a4cc40e9b2f34da94efb75b158da762624015 by Walter Dörwald (Oz N
Tiram) in branch 'master':
bpo-30095: Make CSS classes used by calendar.HTMLCalendar customizable (GH-1439)
https://github.com/python/cpyt
Walter Dörwald added the comment:
Closing the issue. The patch has been merged.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Walter Dörwald added the comment:
The problem here is that StreamArray lies about the length of the iterator.
This confuses json.encoder._make_iterencode._iterencode_list(), (which is
called by json.dump()), because it first does a check for "if not lst" and then
assumes in the lo
New submission from Walter Dörwald :
When I call a function decorated with functools.singledispatch without an
argument, I get the following:
$ python
Python 3.6.5 (default, Jun 17 2018, 12:13:06)
[GCC 4.2.1 Compatible Apple LLVM 9.1.0 (clang-902.0.39.2)] on darwin
Type "help",
New submission from Walter Dörwald :
The __repr__ output of an enum class should use __qualname__ instead of
__name__. The following example shows the problem:
import enum
class X:
class I:
pass
class Y:
class I(enum.Enum):
pass
print(X.I)
print(Y.I)
This prints:
I
Change by Walter Dörwald :
--
keywords: +easy
___
Python tracker
<https://bugs.python.org/issue34443>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Walter Dörwald :
The following code issues a misleading exception message:
>>> b'\xed\xa0\xbd\xed\xb3\x9e'.decode("utf-8")
Traceback (most recent call last):
File "", line 1, in
UnicodeDecodeError: 'utf-8' codec can't
Walter Dörwald added the comment:
OK, I see, http://www.unicode.org/versions/Unicode5.2.0/ch03.pdf (Table 3-7 on
page 93) states that the only valid 3-bytes UTF-8 sequences starting with the
byte 0xED have a value for the second byte in the range 0x80 to 0x9F. 0xA0 is
just beyond that range
Walter Dörwald added the comment:
An alternative would be to use an incremental encoder instead of a
StreamWriter. (Which is what TextIOWrapper does internally).
--
nosy: +doerwalter
___
Python tracker
<http://bugs.python.org/issue1470
New submission from Walter Dörwald :
The attached script behaves differently on Python 2.7.2 and Python 3.2.3.
With Python 2.7 the script runs for ca. 30 seconds and then I get back my
prompt.
With Python 3.2 the script runs in the background, I get back my prompt
immediately and can type
Walter Dörwald added the comment:
So is this simply a documentation issue, or can we close the bug as "won't fix"?
--
___
Python tracker
<http://bugs.pyt
Walter Dörwald added the comment:
> >>> codecs.utf_8_decode('\u20ac'.encode('utf8')[:2])
> ('', 0)
>
> Oh... codecs.CODEC_decode are incremental decoders? I misunderstood completly
> this.
No, those function are not decoders, the
Walter Dörwald added the comment:
The cronjob that produces this information has been deactivated, because it
currently produces broken output. The code for that job is available from here:
https://pypi.python.org/pypi/pycoco
It would be great to have up to date coverage info for Python again
Walter Dörwald added the comment:
True, the second test uses the wrong error handler.
And yes, you're correct, bytes are now immutable. And even if I try to decode a
bytearray, what the callback gets to see is still an immutable bytes object::
import codecs
def mutating(exc):
Walter Dörwald added the comment:
And returning bytes is documented in PEP 383, as an extension to the PEP 293
machinery:
"""To convert non-decodable bytes, a new error handler ([2]) "surrogateescape"
is introduced, which produces these surrogates. On encoding, the er
Walter Dörwald added the comment:
I'd like to have this feature too. However the code should use
d if d is not None else {}
instead of
d or {}
For example I might want to use a subclass of dict (lowerdict) that converts
all keys to lowercase. When I use an empty lowerdict in new_
New submission from Walter Dörwald:
This patch adds frame annotations, i.e. it adds an attribute f_annotation to
frame objects, a decorator to set this attribute on exceptions and extensions
to the traceback machinery that display the annotation in the traceback.
--
components
Walter Dörwald added the comment:
See http://bugs.python.org/issue18861 and the discussion started here:
https://mail.python.org/pipermail/python-dev/2013-November/130155.html.
Basically it allows to add context information to a traceback without changing
the type of the exception.
In the
Walter Dörwald added the comment:
Here is a new version of the patch. The annotation is done on the code object
instead of on the frame object. This avoids two problems: There is no runtime
overhead, as the decorator returns the original function and no additional
frames show up in the
Walter Dörwald added the comment:
Do you have an example where code objects are shared? We could attach the
annotation formatter to the function object, but unfortunately the function
object is now accessible in the traceback.
Note the co_annotation is not the annotation string, rather it is
New submission from Walter Dörwald:
Exception objects that have been pickled with Python 2 can not be unpickled
with Python 3, even when fix_imports=True is specified:
$ python2.7
Python 2.7.2 (default, Aug 30 2011, 11:04:13)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
Type "
Walter Dörwald added the comment:
OK, here is a patch. Instead of mapping the exceptions module to builtins, it
does the mapping for each exception class separately. I've excluded
StandardError, because I think there's no appropriate equivalent in Python 3.
--
keywords: +p
Walter Dörwald added the comment:
Here's an updated version of the patch, addressing most of Alexandre's comments.
--
Added file: http://bugs.python.org/file32918/python-2-exception-pickling-2.diff
___
Python tracker
<http://bu
Changes by Walter Dörwald :
--
resolution: -> fixed
___
Python tracker
<http://bugs.python.org/issue19834>
___
___
Python-bugs-list mailing list
Unsubscrib
Walter Dörwald added the comment:
The requirement that getstate() returns a (buffer, int) tuple has to do with
the fact that for text streams seek() and tell() somehow have to take the state
of the codec into account. See
_pyio.TextIOWrapper.(seek|tell|_pack_cookie|_unpack_cookie).
However I
Walter Dörwald added the comment:
Here is a patch that implements suggestion 2 and 3.
--
keywords: +patch
Added file: http://bugs.python.org/file35800/mapping-tests.diff
___
Python tracker
<http://bugs.python.org/issue2
Walter Dörwald added the comment:
I don't know anything about SMTP, but would it make sense to use an incremental
decoder for decoding UTF-8?
--
nosy: +doerwalter
___
Python tracker
<http://bugs.python.org/is
Walter Dörwald added the comment:
The problem seems to be in that line:
except imaplib.IMAP4_SSL.abort, imaplib.IMAP4.abort:
This does *not* catch both exception classes, but catches only IMAP4_SSL.abort
and stores the exception object in imaplib.IMAP4.abort.
What you want is:
except
Walter Dörwald added the comment:
This is not the fault of pprint. IMHO it doesn't make sense to fix anything
here, at least not for pprint specifically. print() has the same "problem":
$ LANG= ./python -c
Walter Dörwald added the comment:
sys.displayhook doesn't fail, because it uses the backslashreplace error
handler, and for sys.displayhook that's OK, because it's only used for screen
output and there some output is better than no output. However print and
pprint.pprint mi
Walter Dörwald added the comment:
The best solution IMHO would be to implement real incremental codecs for all of
those.
Maybe iterencode() with an empty iterator should never call encode()? (But IMHO
it would be better to document that iterencode()/iterdecode() should only be
used with
Walter Dörwald added the comment:
The stream part of the codecs isn't used that much in Python 3 any more, so I'm
not sure if this is worth fixing.
--
___
Python tracker
<http://bugs.python.o
1 - 100 of 169 matches
Mail list logo
