Martin Panter added the comment:
I originally assumed it would be a text string from the existing documentation,
so changing the behaviour to match also seems reasonable
--
___
Python tracker
<http://bugs.python.org/issue21
Martin Panter added the comment:
Here is a patch addressing many of the points raised. Please have a look and
give any feedback. Beware I am not very familiar with the Restructured Text
markup and haven’t tried compiling it.
1. Mentioned bytes-to-bytes and text-to-text in general right at the
Martin Panter added the comment:
The “unicode-escape” and “utf-7” cases affect the more widely-used
TextIOWrapper interface:
>>> TextIOWrapper(BytesIO(br"\u2013" * 2000), "unicode-escape").read(1)
Traceback (most recent call last):
File "", line 1, i
Martin Panter added the comment:
I included the proposed doc fix in my patch for Issue 19548
--
nosy: +vadmium
___
Python tracker
<http://bugs.python.org/issue19
Martin Panter added the comment:
Here is the patch (against the default branch)
--
keywords: +patch
Added file: http://bugs.python.org/file37486/codecs-all.patch
___
Python tracker
<http://bugs.python.org/issue23
Martin Panter added the comment:
Patch looks sensible enough to me
--
___
Python tracker
<http://bugs.python.org/issue23062>
___
___
Python-bugs-list mailin
Martin Panter added the comment:
Here is a new patch based on John’s suggestion
--
Added file: http://bugs.python.org/file37487/issue21279.patch
___
Python tracker
<http://bugs.python.org/issue21
Martin Panter added the comment:
Here is a patch that changes over to a str() type.
Is it safe to assume PyUnicode_AsUTF8() is null-terminated (like
PyBytes_AS_STRING() is)? My documentation doesn’t say.
--
Added file: http://bugs.python.org/file37488/format-str.patch
Martin Panter added the comment:
Assuming it is intended to support byte strings, here is a patch that documents
them being allowed, and adds a test case
--
keywords: +patch
Added file: http://bugs.python.org/file37489/format-bytes.patch
___
Python
Martin Panter added the comment:
Here is another patch that removes the method instead, as suggested in the
review
--
Added file: http://bugs.python.org/file37490/doctype-remove.patch
___
Python tracker
<http://bugs.python.org/issue19
Martin Panter added the comment:
This patch includes a new test; although this kind of testing won’t detect when
someone adds a new API and forgets to add it to __all__.
--
Added file: http://bugs.python.org/file37491/codecs-all.patch
___
Python
Changes by Martin Panter :
--
nosy: +vadmium
___
Python tracker
<http://bugs.python.org/issue23001>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin Panter added the comment:
Here is a patch with a fix and a test
--
keywords: +patch
Added file: http://bugs.python.org/file37501/fail-close.patch
___
Python tracker
<http://bugs.python.org/issue22
New submission from Martin Panter:
As discussed in msg232863, and later confirmed in the code
--
assignee: docs@python
components: Documentation
files: utf8-null.patch
keywords: patch
messages: 232925
nosy: docs@python, vadmium
priority: normal
severity: normal
status: open
title
Martin Panter added the comment:
Here is a patch that fixes the binascii, zlib.crc32() and adler32()
documentation as I suggested.
I’m still interested why there are two ways to do a CRC-32, each equally
non-obvious as the other.
--
keywords: +patch
Added file: http://bugs.python.org
Martin Panter added the comment:
Updated my patch with a “version changed” notice
--
Added file: http://bugs.python.org/file37505/option-internal.patch
___
Python tracker
<http://bugs.python.org/issue9
Changes by Martin Panter :
--
nosy: +vadmium
___
Python tracker
<http://bugs.python.org/issue22896>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin Panter added the comment:
Here is a patch that substitutes an explanation if the repr() fails. Output now
looks like this, terminated with a newline:
=== BrokenObj ===
Exception ignored in:
Traceback (most recent call last):
File "", line 3, in __del__
Exception: in del
$ .
Changes by Martin Panter :
--
nosy: +vadmium
___
Python tracker
<http://bugs.python.org/issue5319>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin Panter added the comment:
Here is a patch that changes Py_Finalize() to return -1 on error, and then sets
the exit status to 1. It did not introduce any failures in the test suite for
me. However I suspect it deserves more consideration about backwards
compatibility etc, which is
Martin Panter added the comment:
The documentation was technically correct but too scanty. RawIOBase.read(-1)
does defer to readall(), but with a proper size passed, it defers to readinto()
instead. Here is a patch which hopefully clarifies this, and also explains
which methods have a usable
New submission from Martin Panter:
Patch to fix the underlying issue I mentioned in msg230955. After calling
detach() on one of the BufferedIOBase wrappers or a TextIOWrapper, most
operations will raise an exception. My patch ensures the following operations
are still usable, because they are
Changes by Martin Panter :
--
nosy: +vadmium
___
Python tracker
<http://bugs.python.org/issue1763>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin Panter added the comment:
Damn, detaching the intermediate buffered stream is a bit more awkward. The
difference between the “io” and “_pyio” implementations boils down to:
* io.BufferedReader/Writer/RWPair.name properties raise a ValueError if the
stream is detached
* _pyio
Changes by Martin Panter :
--
nosy: +vadmium
___
Python tracker
<http://bugs.python.org/issue12600>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Martin Panter :
--
nosy: +vadmium
___
Python tracker
<http://bugs.python.org/issue7897>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Martin Panter :
--
nosy: +vadmium
___
Python tracker
<http://bugs.python.org/issue22673>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Martin Panter :
--
nosy: +vadmium
___
Python tracker
<http://bugs.python.org/issue19051>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Martin Panter :
--
nosy: +vadmium
___
Python tracker
<http://bugs.python.org/issue12053>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin Panter added the comment:
Some of the docstrings already mention UnsupportedOperation. This patch updates
the rest of the documentation. Also adds some tests to verify this on all the
concrete classes I could think of. Some discoveries in the process:
* BufferedWriter.readable() and
Martin Panter added the comment:
Patch v4 with John’s doc string wording
--
Added file: http://bugs.python.org/file37522/issue21279.v4.patch
___
Python tracker
<http://bugs.python.org/issue21
Martin Panter added the comment:
Here is patch v2, which ignores any exception derived from the Exception base
class when reading the self.name etc properties. I’m interested what people
think of this approach.
--
Added file: http://bugs.python.org/file37523/detach-indep.v2.patch
Martin Panter added the comment:
Serhiy can you point out which bits are too verbose? Perhaps you prefer it
without the bullet list like in the earlier 2014-12-13 version of the patch.
Looking at the C API, I see a couple problems there:
* Omits mentioning that an ordinal can map to a
Martin Panter added the comment:
Not sure what the original method to cause this message is. I’m guessing some
code was trying to call a function that was set to None by the shutdown
process, causing the exception message, and that repr() was also failing,
causing the broken wording. Like
Martin Panter added the comment:
Patch v2 revises the unit tests so they are cleaner. Also now tests that the
placeholders are in the exception reports.
--
Added file: http://bugs.python.org/file37524/unraisable-continue.v2.patch
___
Python tracker
Martin Panter added the comment:
[Edit Error: 'utf8' codec can't decode byte 0xe2 in position 212: invalid
continuation byte]
Re-reading the suggested description, it struck me that for encoding, this is
redundant with the “backslashreplace” error handler:
>>> test
New submission from Martin Panter:
IOBase.close() doc says file operations raise ValueError, but it is not obvious
to me that reading back the “file” buffer is a file operation.
>>> with BytesIO() as b:
... b.write(b"123")
...
3
>>> b.getvalue()
Traceback (mo
Martin Panter added the comment:
Adding patch v2 after learning how to compile the docs and fixing my errors. I
also simplified the descriptions of the CodecInfo attributes by defering the
constructor signatures to where they are fully defined under “Codec base
classes”, and merged the list
Martin Panter added the comment:
The problem with mappings and sequences is that they both require len() and
iter() implementations, but str.translate() only requires __getitem__().
Perhaps a qualifier could work, like:
The table must implement the __getitem__() method of mappings and
Martin Panter added the comment:
Adding patch v2 with readinto1() as a “mixin method” and dropped many of my
earlier changes for better consistency with the introduction of the classes
(which I never really read before :P)
--
Added file: http://bugs.python.org/file37528/read
Martin Panter added the comment:
New patch version addressing many of the comments; thanks for reviewing! Also
adds and extends some unit tests to confirm some of the corner cases I am
documenting.
--
Added file: http://bugs.python.org/file37530/codecs-doc.v3.patch
Changes by Martin Panter :
--
nosy: +vadmium
___
Python tracker
<http://bugs.python.org/issue23135>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin Panter added the comment:
Issue 23136 looks like a duplicate, but has a potential patch
--
nosy: +vadmium
___
Python tracker
<http://bugs.python.org/issue23
Changes by Martin Panter :
--
nosy: +vadmium
___
Python tracker
<http://bugs.python.org/issue22680>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin Panter added the comment:
Assuming that FunctionTestCase inherits from TestCase, a fix for Issue 14534
would be useful here. That bug is about avoiding TestCase subclasses being
automatically run, which is useful for abstract base test classes
New submission from Martin Panter:
It is not clear how you are meant to use unittest.FunctionTestCase with
automatic test running. Unless a simple way to do this already exists, I wonder
if it would be okay to automatically discover and run predefined test
instances, such as the
Martin Panter added the comment:
You “forgot” to call close():
>>> parser.close()
Encountered some data : eggs
Perhaps this is a documentation bug, since there is a lot of example code
given, but none of the examples call close().
--
assignee: -> docs@pytho
Martin Panter added the comment:
See Issue 19167 for a patch to remove the xml.etree.XMLParser.doctype() method.
I’m happy for it to be removed, since the logic for generating the
DeprecationWarning is buggy.
--
nosy: +vadmium
___
Python tracker
Martin Panter added the comment:
Make that Issue 19176 for XMLParser.doctype()
--
___
Python tracker
<http://bugs.python.org/issue13248>
___
___
Python-bugs-list m
Martin Panter added the comment:
Just pointing out there is a patch for Issue 19548 for Python 3 which also adds
a pointer to the builtin open() function and updates the codecs.open() caveats.
That issue doesn’t touch Python 2 though.
--
nosy: +vadmium
Changes by Martin Panter :
--
nosy: +vadmium
___
Python tracker
<http://bugs.python.org/issue23161>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin Panter added the comment:
For what it’s worth, every now and then I have to stop and remember that I
can’t do this sort of thing:
unsupported_keys = config_dict.keys().difference(supported_list)
though it is not a big problem to rewrite it as
unsupported_keys = config_dict.keys
Martin Panter added the comment:
Another one to deal with one way or the other: html.parser.HTMLParser.unescape()
It is apparently due to be removed in 3.5. It was meant to be an undocumented
internal function, and there is now an public alternative. However I would be
inclined to leave it
Martin Panter added the comment:
If this goes ahead, it would be nice adding notes to the documentation saying
that bytearray() or whatever was previously not supported. There are APIs in
Python 2.6 that had similar treatment with no documentation updates, and I keep
being bitten by it
Martin Panter added the comment:
Adding patch v5, for the 3.4 branch. There is at least one reference that still
needs fixing in the default branch that is not applicable to the 3.4 branch.
Main changes from Nick’s patch:
* Removed sentence now redundant with introduction to open() and
Martin Panter added the comment:
Updated patch, to also document the BytesIO buffer is no longer available when
closed. The StringIO documentation actually already says this, but I rarely use
StringIO. :)
--
Added file:
http://bugs.python.org/file37611
Martin Panter added the comment:
Thanks Nick. Here is a small followup patch for the default (3.5) branch to
keep things consistent.
--
Added file: http://bugs.python.org/file37618/default-branch-followup.patch
___
Python tracker
<h
Martin Panter added the comment:
It turns out that GzipFile.read() etc is also susceptible to
decompression bombing. Here is a patch to test and fix that, making use of the
existing “max_length” parameter in the “zlib” module.
--
Added file: http://bugs.python.org/file37644/gzip
New submission from Martin Panter:
This simple patch documents that max_length has to be non-zero. The
implementation actually uses zero as a special value to indicate max_length was
not specified.
Also, I wonder what the point of the Decompressor.flush() method is. Reading
the module code
Martin Panter added the comment:
The processing of unconsumed_tail in flush() was introduced via Issue 16411.
Before that I suspect flush() was assumed to only be called when max_length was
not used.
The decompress() method changed from Z_NO_FLUSH to Z_SYNC_FLUSH in Feb 2001;
see revision
Martin Panter added the comment:
For what it’s worth, it would be better if compressed streams did limit the
amount of data they decompressed, so that they are not susceptible to
decompression bombs; see Issue 15955. But having a flexible-sized buffer could
be useful in other cases.
I
Martin Panter added the comment:
Is there anything left for this bug or could it be closed? I can confirm my
v3.4.2 docs say “size” instead of “n” :)
--
nosy: +vadmium
___
Python tracker
<http://bugs.python.org/issue17
Martin Panter added the comment:
Is the current documentation as accurate as it can be?
“The number of bytes returned may be less or more than requested”
To me this has always made this method practically useless. A valid
implementation could just always return b"". I noticed the BZ
New submission from Martin Panter:
I am trying to make LZMAFile (which implements BufferedIOBase) use a
BufferedReader in read mode. However this broke
test_lzma.FileTestCase.test_read1_multistream(), which calls read1() with the
default size argument. This is because BufferedReader.read1
Martin Panter added the comment:
I suspect this is not a bug but a misunderstanding of how communiate(), pipes,
daemon processes, etc, work. If communicate() didn’t wait for stderr to be
closed, then how would it know it had read all the data that was written into
the pipe?
I don’t have that
Martin Panter added the comment:
Here is a patch for the higher-level LZMAFile implementation to use Nikolaus’s
“max_length” parameter. It depends on Nikolaus’s patch also being applied.
I split out a _RawReader class that does the actual decompress() calls, and
then wrapped that in a
Martin Panter added the comment:
Here is a simple documentation patch to guarantee that at least one byte is
normally returned. This would make the method much more useful, and compatible
with the BZ2File and LZMAFile interfaces, allowing them to use BufferedReader,
as I propose to do in
Martin Panter added the comment:
I think the simplest thing to do here would be to update the documentation to
match the usage. This patch does so, saying that all write() methods, as well
as the BytesIO() constructor, have to accept bytes-like objects. It also
expands some tests to verify
Martin Panter added the comment:
Parts of the patch here actually do the same thing as my LZMAFile patch for
Issue 15955. I wish I had looked at the patch earlier! The difference is I used
a proposed max_length parameter for the decompressor rather than unlimited
decompression, and I used the
Changes by Martin Panter :
--
nosy: +vadmium
___
Python tracker
<http://bugs.python.org/issue21408>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin Panter added the comment:
There is a bit of analysis of the object.__ne__() implementation in Issue 4395.
If my understanding is correct, I think it is a bug that object.__ne__(self,
other) evaluates “not self == other”. It should evaluate “not
self.__eq__(other)” instead, so that
Martin Panter added the comment:
As far as I understand, Idle doesn’t interpret any terminal control codes apart
from a plain \n for a new line. I know it doesn’t do a carriage return for \r
either.
--
components: +IDLE
nosy: +vadmium
___
Python
Martin Panter added the comment:
Here is a patch that documents the default object.__ne__() implementation. It
also documents the subclass priority rules for the reflected comparison
methods, which is raised in Issue 22052.
I have made some more tests to verify the relationships exists from
Martin Panter added the comment:
I have included some rules about the priority for calling reflected operator
methods in my patch to Issue 4395
--
nosy: +vadmium
___
Python tracker
<http://bugs.python.org/issue22
Martin Panter added the comment:
This patch should fix the problem I think. Before the __ne__() implementation
was calling the “==” operator; now it calls the __eq__() method instead.
Also includes extra test for Issue 4395 to avoid having conficting patches.
--
keywords: +patch
Added
Martin Panter added the comment:
Looking at the test suite:
* read1() of LZMAFile and GzipFile (both implementing BufferedIOBase) are
asserted to return a non-zero result until EOF
* LZMAFile.read1(0) is asserted to return an empty string
* BufferedReader.read1(-1) is asserted to raise
Martin Panter added the comment:
We still need a patch for max_length in BZ2Decompressor, and to use it in
BZ2File. Also, I think my GzipFile patch should be considered as a bug fix
(rather than enhancement), e.g. the fix for Issue 16043 assumes
GzipFile.read() is limited.
I’m adding v4 of
Changes by Martin Panter :
--
nosy: +vadmium
___
Python tracker
<http://bugs.python.org/issue17239>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Martin Panter:
Noticed in a patch review around LZMModules/_lzmamodule.c:1055 that the C-level
LZMADecompressor object is being initialized in an __init__() method. It
crashes if you create the object with __new__() and never call __init__():
>>> from lz
Martin Panter added the comment:
Not a Python bug. The web site seems to be doing this based on the user agent;
if you change it, it works:
urlopen(Request("http://www.thomsonlocal.com/";, headers={"User-Agent":
"https://bugs.python.org/issue21896"}))
---
Martin Panter added the comment:
I haven’t done any tests, but my LZMAFile patch to Issue 15955 uses
BufferedReader, so it might satisfy this issue
--
nosy: +vadmium
___
Python tracker
<http://bugs.python.org/issue18
Changes by Martin Panter :
--
nosy: +vadmium
___
Python tracker
<http://bugs.python.org/issue22495>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin Panter added the comment:
Yeah it would be good to put related tests in the one place.
I was trying to find a good place to test how the comparison operators invoke
the __eq__(), __gt__() etc methods, and the existing tests seem to be spread
over test_compare.py and test_binop.py
Changes by Martin Panter :
--
nosy: +vadmium
___
Python tracker
<http://bugs.python.org/issue20285>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin Panter added the comment:
I tried in Python 2.7.9 on Linux, with env = "TERM=xterm", cmd = "date", and
couldn’t get any of those seven terminal settings to be turned off
--
nosy: +vadmium
___
Python tracker
<http://bug
Martin Panter added the comment:
Here’s a simple patch which should fix it, although I have not verified this
because I don’t have a Windows compiler (and MINGW cross compiling sounds too
tricky)
--
keywords: +patch
Added file: http://bugs.python.org/file37678/win-error-format.patch
Changes by Martin Panter :
--
nosy: +vadmium
___
Python tracker
<http://bugs.python.org/issue22286>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Martin Panter :
--
nosy: +vadmium
___
Python tracker
<http://bugs.python.org/issue15836>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Martin Panter :
--
nosy: +vadmium
___
Python tracker
<http://bugs.python.org/issue9587>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin Panter added the comment:
This patch includes a test case, based on Eryksun’s exception code
--
Added file: http://bugs.python.org/file37686/win-error-format-v2.patch
___
Python tracker
<http://bugs.python.org/issue22
Martin Panter added the comment:
A patch for this might conflict with the LZMA patch for Issue 15955, so it
would be simplest to wait for that issue to be resolved first
--
___
Python tracker
<http://bugs.python.org/issue23
Martin Panter added the comment:
Here is a new version of Kuchling’s patch. I restored some mapping files which
do not give any errors (including the mac_turkish codec, which is actually
documented), and removed both readme files.
--
components: +Unicode
nosy: +haypo, vadmium
versions
Changes by Martin Panter :
--
nosy: +vadmium
___
Python tracker
<http://bugs.python.org/issue20739>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Martin Panter:
As mentioned in Issue 20132, iterencode() and iterdecode() only work on
text-to-byte codecs, because they assume particular data types when finalizing
the incremental codecs. This patch changes the signature of the
IncrementalEncoder and IncrementalDecoder
Martin Panter added the comment:
Original patch has lots of whitespace changes, probably due to generated codec
code not being regenerated for a long time. This diff ignores the space
changes, so should be easier to review.
--
Added file: http://bugs.python.org/file37692/final-no
Changes by Martin Panter :
--
nosy: +vadmium
___
Python tracker
<http://bugs.python.org/issue23232>
___
___
Python-bugs-list mailing list
Unsubscribe:
Martin Panter added the comment:
This patch looks simple and uncontroversial. I think it could be merged.
--
nosy: +vadmium
versions: +Python 3.4
___
Python tracker
<http://bugs.python.org/issue12
Martin Panter added the comment:
See Issue 23231 for a proposal which should make the incremental codec API
compatible with a generic StreamReader/Writer class.
I discovered that many of the codec files are generated by gencodec.py, not
hand-written. However when I tried regenerating them, I
Martin Panter added the comment:
I don’t think this is appropriate. If you want to flush the underlying stream,
then call its flush() method after calling reset(). The docstring only says it
flushes the _codec’s_ buffers, not any buffers of the underlying stream, and it
should not be the
Changes by Martin Panter :
--
nosy: +vadmium
___
Python tracker
<http://bugs.python.org/issue23234>
___
___
Python-bugs-list mailing list
Unsubscribe:
1601 - 1700 of 4320 matches
Mail list logo
