Change by Nikolaus Rath :
--
nosy: -nikratio
___
Python tracker
<https://bugs.python.org/issue17681>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Nikolaus Rath :
--
nosy: -nikratio
___
Python tracker
<https://bugs.python.org/issue17852>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Nikolaus Rath :
--
nosy: -nikratio
___
Python tracker
<https://bugs.python.org/issue34624>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nikolaus Rath added the comment:
Is there a good reason to not explicitly initialize them nevertheless? Valgrind
is a common tool, and this false positive will affect everyone attempting to
run it on a Python extension module.
--
___
Python
Nikolaus Rath added the comment:
Sorry, no. I have long lost context and interest in this.
--
___
Python tracker
<https://bugs.python.org/issue20177>
___
___
Nikolaus Rath added the comment:
$ ./configure CFLAGS="-O0 -g" --with-valgrind && make -j8
still gives
==13281== Memcheck, a memory error detector
==13281== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==13281== Using Valgrind-3.12.0.SVN and Lib
Nikolaus Rath added the comment:
Same error with 3.7.1 and 3.6.7 (though line numbers differ slightly).
--
___
Python tracker
<https://bugs.python.org/issue35
New submission from Nikolaus Rath :
With current git master, configured --with-valgrind --with-pydebug, I get:
==31074== Command: /home/nikratio/clones/cpython/python
/home/nikratio/in-progress/pyfuse3/test/../examples/hello.py
/tmp/pytest-of-nikratio/pytest-11/test_hello_hello_py_0
==31074
Change by Nikolaus Rath :
--
nosy: +nikratio
title: -W option does not accept module regexes -> -W option and PYTHONWARNINGS
env variable does not accept module regexes
___
Python tracker
<https://bugs.python.org/issu
Nikolaus Rath added the comment:
yes, this is a duplicate.
--
___
Python tracker
<https://bugs.python.org/issue34920>
___
___
Python-bugs-list mailing list
Unsub
New submission from Nikolaus Rath :
According to
https://docs.python.org/3/library/warnings.html#describing-warning-filters:
"The meaning of each of these fields [of PYTHONWARNINGS] is as described in
."
The description of the "The Warnings filter" says
"modu
Change by Nikolaus Rath :
--
nosy: -nikratio
___
Python tracker
<https://bugs.python.org/issue1230540>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nikolaus Rath <nikol...@rath.org> added the comment:
Given the apparent difficulties getting this right, how about not attempting to
implicitly flush buffers in the finalizer at all? This means scripts relying on
this will break, but in contrast to the current behavior they will
Nikolaus Rath added the comment:
Regarding "atrocious connection": I wish I knew, but I have no control of the
connection. All I can tell is that there are frequent disconnects, occasional
latency spikes, my remote ip address seems to change frequently (while the
apparent local
New submission from Nikolaus Rath:
With a particularly atrocious network connection, I often get the following
exception:
File "/usr/lib/python3/dist-packages/dugong/__init__.py", line 503, in connect
self._sock = self.ssl_context.wrap_socket(self._sock,
server_hostname=serve
Nikolaus Rath added the comment:
Would you be willing to review a patch to incorporate the handling into the SSL
module?
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Nikolaus Rath added the comment:
Stefan, sorry for ignoring your earlier reply. I somehow missed the question at
the end.
I believe that users of the Python module are *not* expected to make use of the
WANT_READ, WANT_WRITE flags. Firstly because the documentation (of Python's ssl
module
Nikolaus Rath added the comment:
This just happened again to someone else, also using Python 3.4:
https://bitbucket.org/nikratio/s3ql/issues/87
Is there anything the affected people can do to help debugging this?
--
___
Python tracker <
Nikolaus Rath added the comment:
The first thing that would come to my mind when reading Nick's proposed
document (without first reading this bug report) is So why the heck is this
not the default?.
It would probably save a lot of people a lot of anger if there was also a brief
explanation
Nikolaus Rath added the comment:
I believe Martin's patch (v8) is ready for a core committer review. At least I
can't find anything to criticize anymore :-).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23529
Nikolaus Rath added the comment:
Except for the pointless 'myfileobj' stuff in gzip.py, rev 8 of the patch looks
good to me.
(Btw, I'm not actually in favor of e.g. the seekable() change. The previous
patch was intended as a proof-of-concept to see what would be necessary to
inherit more
Nikolaus Rath added the comment:
As discussed in Rietveld, here's an attempt to reuse more DecompressReader for
GzipFile. There is still an unexplained test failure (test_read_truncated).
--
Added file: http://bugs.python.org/file38674/LZMAFile-etc.v7.patch
Nikolaus Rath added the comment:
If you want to add support for buffer_size=0 in a separate patch/issue I think
that's fine. But in that case I would not add a buffer_size parameter now at
all. IMO, not having it is better as having it but not supporting zero (even if
it's documented that's
Nikolaus Rath added the comment:
On Mar 06 2015, Martin Panter rep...@bugs.python.org wrote:
Still to do: Need to find a better home for the _DecompressReader and
_BaseStream classes. Currently it lives in “lzma”, but apparently it
is possible for any of the gzip, bz2, lzma modules
Nikolaus Rath added the comment:
On Feb 27 2015, Martin Panter rep...@bugs.python.org wrote:
In the code review, Nikolaus raised the idea of allowing a custom
“buffer_size” parameter for the BufferedReader. I think this would
need a bit of consideration about how it should work:
1. Should
Nikolaus Rath added the comment:
Especially now that this is only going to go into 3.5, I think it makes more
sense to handle GzipFile, LZMAFile and BZ2File all in one go. Looking at the
code, otherwise there's going to be a lot of duplication.
How about introducing a base class
Nikolaus Rath added the comment:
Martin, I'll try to review your GzipFile patch. But maybe it would make sense
to open a separate issue for this?
I think the LZMAFile patch has not yet been reviewed or committed, and we
probably want a patch for BZ2File too. The review page is already pretty
Nikolaus Rath added the comment:
Updated patch attached.
--
Added file: http://bugs.python.org/file38206/issue15955_bz2_rev2.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15955
Nikolaus Rath added the comment:
Attached is a patch for the bz2 module.
--
Added file: http://bugs.python.org/file38194/issue15955_bz2.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15955
Nikolaus Rath added the comment:
I've started to work on the bzip module. I'll attach I work-in-progress patch
if I get stuck or run out of time.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15955
Nikolaus Rath added the comment:
Yes, I still plan to do it, but I haven't started yet.
That said, I certainly won't be offended if someone else implements the feature
either. Please just let me know when you start working on this (I'll do the
same), so there's no duplication of efforts
Nikolaus Rath added the comment:
On a more practical note:
I believe Nadeem at one point said that the bz2 module is not exactly an
example for good stdlib coding, while the lzma module's implementation is quite
clean. Therefore
Therefore, one idea I had for the bz2 module was to port
Nikolaus Rath added the comment:
Serhiy, did you add me to Cc just for information, or is there anything I
should be doing (having written the patch that introduced this bug)?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Nikolaus Rath added the comment:
Martin Panter rep...@bugs.python.org writes:
We still need a patch for max_length in BZ2Decompressor, and to use it
in BZ2File.
I'm still quite interested to do this. The only reason I haven't done it
yet is that I'm waiting for the LZMA patch to be reviewed
Nikolaus Rath added the comment:
*ping*. It's been another 8 months. It would be nice if someone could review
the patch.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15955
Nikolaus Rath added the comment:
This will probably be too radial, but I think it should at least be mentioned
as a possible option.
We could just not attempt to implicitly flush buffers in the finalizer at all.
This means scripts relying on this will break, but in contrast to the current
Changes by Nikolaus Rath nikol...@rath.org:
--
nosy: +nikratio
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17852
___
___
Python-bugs-list
Nikolaus Rath added the comment:
Serhiy, I believe this still happens in Python 3.4, but it is harder to
reproduce. I couldn't get Armin's script to produce the problem either, but I'm
pretty sure that this is what causes e.g.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771452#60
New submission from Nikolaus Rath:
I received a bugreport due to a crash when calling SSLObject.send(). The
traceback ends with:
[...]
File
/usr/local/lib/python3.4/dist-packages/dugong-3.2-py3.4.egg/dugong/__init__.py,
line 584, in _co_send
len_ = self._sock.send(buf)
File /usr/lib
Nikolaus Rath added the comment:
*ping*
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15955
___
___
Python-bugs-list mailing list
Unsubscribe
Nikolaus Rath added the comment:
R. David Murray rep...@bugs.python.org writes:
R. David Murray added the comment:
Nikolaus: while I agree that Raymond's comments were a bit strongly
worded, it doesn't read to me as if the thread you link to is on point
for this issue. The thread
Nikolaus Rath added the comment:
On 06/17/2014 01:28 PM, R. David Murray wrote:
Well, but we think it's pretty clear.
This wasn't the impression that I had from the thread on python-devel,
but I'll accept your judgement on that. I'll be more restrained when
being asked for suggestions
Nikolaus Rath added the comment:
On 06/15/2014 06:26 PM, Raymond Hettinger wrote:
Before creating more tracker items, please take time to learn about how
Python's history,
[...]
It'd be nice if you would have at least followed the link to
http://article.gmane.org/gmane.comp.python.devel
Nikolaus Rath added the comment:
As discussed on python-devel, I'm attaching a new patch that uses
memoryview.cast to ensure that the pure-Python readinto() now works with any
object implementing the buffer protocol.
--
Added file: http://bugs.python.org/file35647/issue20578_r5.diff
Nikolaus Rath added the comment:
On 06/15/2014 08:29 AM, R. David Murray wrote:
I don't think that's true, though. file like pretty much means has the
file attributes that I actually use. That is, it is context dependent (duck
typing).
Well, but when you pass your file-like object
Nikolaus Rath added the comment:
(refreshed patch, no changes)
--
Added file: http://bugs.python.org/file35648/issue20578_r6.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20578
Nikolaus Rath added the comment:
Maybe I'm missing some important point here, but I think that the documentation
ought to tell me how I have to design a file-like object such that it fulfills
all expectations of the standard library.
Yes, you can get away with less than that in many
Nikolaus Rath added the comment:
Nadeem, did you get a chance to look at this?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15955
Nikolaus Rath added the comment:
Raymond, it would be nice if you could respond to my last comment...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19414
New submission from Nikolaus Rath:
It is currently not perfectly clear what Python (and the standard library)
assumes about file-like objects (see e.g.
http://article.gmane.org/gmane.comp.python.devel/148199).
The attached doc patch tries to improve the current situation by stating
New submission from Nikolaus Rath:
CPython's io.IOBase.__del__ calls self.close(), but this isn't documented
anywhere (and may be surprised for derived classes).
The attached patch extends the documentation.
--
assignee: docs@python
components: Documentation
files: iobase2.diff
Changes by Nikolaus Rath nikol...@rath.org:
Removed file: http://bugs.python.org/file35637/iobase2.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21764
Changes by Nikolaus Rath nikol...@rath.org:
Added file: http://bugs.python.org/file35638/iobase2.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21764
Nikolaus Rath added the comment:
Thanks for taking the time, and apologies about the test failure. I was
probably too eager and ran only the test_io suite instead of everything.
I looked at the failure, and the problem is that the default Python
BufferedIOBase.readinto implementation is semi
Nikolaus Rath added the comment:
I used the wrong interpreter when cutting and pasting the example above, here's
the correct version to avoid confusion with the traceback:
import _pyio
from array import array
buf = array('b', b'x' * 10)
_pyio.open('/dev/zero', 'rb').readinto(buf)
10
buf
Changes by Nikolaus Rath nikol...@rath.org:
--
nosy: +nikratio
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17277
___
___
Python-bugs-list
Nikolaus Rath added the comment:
Tal, I was referring to this mail:
https://mail.python.org/pipermail/python-dev/2014-January/132066.html
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20177
Changes by Nikolaus Rath nikol...@rath.org:
--
nosy: +nikratio
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21555
___
___
Python-bugs-list
Nikolaus Rath added the comment:
On 05/13/2014 12:41 PM, Serhiy Storchaka wrote:
Note that this is not work with the punycode encoding (and may be some
third-party encodings).
I do not understand. Could you elaborate?
--
___
Python tracker rep
Nikolaus Rath added the comment:
Cybjit rep...@bugs.python.org writes:
Cybjit added the comment:
On 2014-05-10 00:23, nikratio wrote:
Is pip maybe doing its own certificate check, and relying on
HTTPSConnection.host to contain the final hostname rather than the proxy?
I think the culprit
Nikolaus Rath added the comment:
On 05/09/2014 02:02 PM, Cybjit wrote:
C:\Python34\Scriptspip -v install simplejson
Downloading/unpacking simplejson
Could not fetch URL https://pypi.python.org/simple/simplejson/: connection
err
or: hostname 'openwrt.lan' doesn't match either
Nikolaus Rath added the comment:
Raymond, I think your patch does not really address the issue reported here.
The dict documentation still guarantees that mutating a dict during iteration
will raise a RuntimeError or may skip elements. The OrderedDict documentation
still does not point out
Nikolaus Rath added the comment:
Maybe. I have 1.0.1g. Could you maybe post the output of the failed test? I'd
like to understand how the patch broke the test (looking at your patch alone
didn't tell me much).
--
___
Python tracker rep
Changes by Nikolaus Rath nikol...@rath.org:
Added file: http://bugs.python.org/file35123/issue_21377_r4.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21377
Changes by Nikolaus Rath nikol...@rath.org:
Added file: http://bugs.python.org/file35100/issue_21377_r3.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21377
Nikolaus Rath added the comment:
Antoine, are you sure this was a problem related to this patch?
The test seems to work just fine for me:
$ hg update -C -r b0f6983d63df
$ make clean
$ ./configure --with-pydebug make -j1
$ ./python -m test -u network,urlfetch -j 8 test_poplib
[1/1] test_poplib
Changes by Nikolaus Rath nikol...@rath.org:
Added file: http://bugs.python.org/file35082/issue20951_r3.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20951
Changes by Nikolaus Rath nikol...@rath.org:
Added file: http://bugs.python.org/file35083/issue_21057_r3.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21057
Nikolaus Rath added the comment:
Tentative patch attached. The test suite still passes, but I'm not sure if it
actually exerts the new code path. Is there a standard way to test the C api?
--
keywords: +patch
Added file: http://bugs.python.org/file35084/issue_21377.diff
Changes by Nikolaus Rath nikol...@rath.org:
Added file: http://bugs.python.org/file35085/issue_21377_r2.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21377
Nikolaus Rath added the comment:
As discussed on python-dev, here is a patch that changes the behavior of send()
and sendall() to raise SSLWant* exceptions instead of returning zero.
--
Added file: http://bugs.python.org/file35062/issue20951_r2.diff
Nikolaus Rath added the comment:
This issue can be closed. The testcases have been added in 39ee3286d187.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10983
Nikolaus Rath added the comment:
Attached is an updated patch that
- removes the code duplication in _pyio.BufferedIOBase
- adds an internal _readinto helper method to _pyio.BufferedReader that makes
the implementation similar to io.BufferedReader.
- implements _pyio.BuffereadReader
Changes by Nikolaus Rath nikol...@rath.org:
Added file: http://bugs.python.org/file34864/benchmark_r3.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20578
Nikolaus Rath added the comment:
Updated patch to acknowledge original authors in Misc/ACKS.
--
Added file: http://bugs.python.org/file34801/issue1738_r3.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1738
Nikolaus Rath added the comment:
Refreshed patch.
--
Added file: http://bugs.python.org/file34802/issue7776_r7_Py3.4.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7776
Changes by Nikolaus Rath nikol...@rath.org:
Added file: http://bugs.python.org/file34803/issue7776_r7_Py3.5.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7776
Nikolaus Rath added the comment:
The patch applies cleanly to 3.4 and 3.5, not sure why the review link does not
show up. I'm attaching the file again, maybe that helps.
--
Added file: http://bugs.python.org/file34804/issue19414_r2.diff
___
Python
Nikolaus Rath added the comment:
Here's a little script to estimate the performance difference between using
read1 and readinto1 to read large amounts of data. On my system, I get:
C readinto1: 4.960e-01 seconds
C read1: 4.055e-01 seconds
Python readinto1: 1.066e+00 seconds
Python read1
Nikolaus Rath added the comment:
(Rietveld is giving me errors, so I'm replying here)
On 2014/04/13 02:22:23, loewis wrote:
Again, why a separate implementation here?
For performance reasons. Relying on the default implementation
would fall back to using read1(), which means a new bytes
Nikolaus Rath added the comment:
Can you please extend your benchmark to also measure read and readinto?
Yes - but I don't quite understand why it matters (if you need read1/readinto1,
you cannot just use read/readinto instead).
C readinto1: 4.638e-01 seconds
C read1: 4.026e-01 seconds
C
Changes by Nikolaus Rath nikol...@rath.org:
Added file: http://bugs.python.org/file34792/issue15955_r3.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15955
Nikolaus Rath added the comment:
Seems as if no one has an opinion on this at all:
https://mail.python.org/pipermail/python-dev/2014-April/133739.html
What next?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20578
Nikolaus Rath added the comment:
My usecase is that I have a binary stream class that internally uses
memoryviews. I would like to read text data from this stream and thus
encapsulate it in a TextIOWrapper. Currently, TextIOWrapper (correctly) expects
read() to return bytes and fails
Nikolaus Rath added the comment:
Thanks for the review! Attached is a new patch. I was actually pretty careful
to avoid any code duplication.. are you refering to the readinto1()
implementations for BytesIO and BufferedReader in Lib/_pyio.py?
--
Added file: http://bugs.python.org
Nikolaus Rath added the comment:
I've attached the second iteration of the patch. I've factored out a new
function decompress_buf, and added two new (C only) instance variables
input_buffer and input_buffer_size.
I've tested the patch by enabling Py_USING_MEMORY_DEBUGGER in
Objects
Nikolaus Rath added the comment:
Thanks for the commit!
My intention is to fix the behavior itself for 3.5 (see issue 9521), so I think
adding testcases for the old behavior in the meantime isn't necessary.
--
___
Python tracker rep
Changes by Nikolaus Rath nikol...@rath.org:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20375
___
___
Python-bugs-list
Nikolaus Rath added the comment:
Thanks for your feedback! I've attached an updated patch.
--
Added file: http://bugs.python.org/file34708/issue20375.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20375
Changes by Nikolaus Rath nikol...@rath.org:
Added file: http://bugs.python.org/file34709/issue20375.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20375
Nikolaus Rath added the comment:
Yes, the new testcases were deliberately included. I submitted the patch prior
to the 3.4 release, am I right that at that point this wouldn't have been a
problem?
I have attached a new patch containing just the doc changes. I hope that's
still acceptable
Nikolaus Rath added the comment:
Thanks for the feedback! I have attached an updated patch.
I did not include any testcase because the patch did not create any new code
paths, so I was assuming it'd be covered by the existing test case. But of
course I was wrong. In the revised patch, I added
Nikolaus Rath added the comment:
I'm attaching a patch that enables TextIOWrapper to work with bytes-like
objects from the underlying file descriptor.
The code changes are pretty small, without introducing any significant
additional complexity.
For streams providing bytes objects, this patch
Changes by Nikolaus Rath nikol...@rath.org:
Removed file: http://bugs.python.org/file34645/issue21057.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21057
Changes by Nikolaus Rath nikol...@rath.org:
Added file: http://bugs.python.org/file34646/issue21057.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21057
Nikolaus Rath added the comment:
On 03/26/2014 03:43 AM, STINNER Victor wrote:
class MyByteStream(BytesIO):
def read1(self, len_):
return memoryview(super().read(len_))
bs = MyByteStream(b'some data in ascii\n')
I guess that you are trying to implement a zero-copy I/O
Nikolaus Rath added the comment:
I have attached a patch that adds readinto1() to BufferedReader and
BufferedRWPair.
An example use case for this method is receiving a large stream over a protocol
like HTTP. You want to use a buffered reader so you can efficiently parse the
header, but after
Changes by Nikolaus Rath nikol...@rath.org:
--
nosy: +benjamin.peterson, hynek, stutzbach
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20578
Nikolaus Rath added the comment:
As an alternative, I have attached a pure docpatch that just documents the
future behavior.
Someone with commit privileges: please take your pick :-).
--
Added file: http://bugs.python.org/file34633/docpatch.diff
Nikolaus Rath added the comment:
On 03/25/2014 01:39 PM, Serhiy Storchaka wrote:
read1() should return bytes. MyByteStream doesn't implement the
io.BufferedIOBase interface.
Indeed, this is what this issue is about :-).
The question is: is there a good reason to require io.BufferedIOBase
1 - 100 of 300 matches
Mail list logo
