[issue39201] Threading.timer leaks memory in 3.8.0/3.8.1
New submission from Mathias : Hi, I think there is an issue with memory allocating with threading.Timer in 3.8.0/3.8.1. When I run the attached code in Python 3.7.3 I get a memory consumption of approx. 10 MB. If I run the same code with python 3.8.0 or 3.8.1, it keeps consuming memory (several hundreds of MB). I've attached 3 images where I run the attached script under mprof. By inspect of the output from tracemalloc, I can see that /usr/lib/python3.8/threading.py:908 keeps allocating memory. I have tested this with python 3.8.0 from ubuntu 16.04 repository and python 3.8.1 from source. Both versions suffers from the memory consumption issue. -- components: Library (Lib) files: images_code.tar messages: 359239 nosy: mneerup priority: normal severity: normal status: open title: Threading.timer leaks memory in 3.8.0/3.8.1 versions: Python 3.8 Added file: https://bugs.python.org/file48825/images_code.tar ___ Python tracker <https://bugs.python.org/issue39201> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12064] unexpected behavior with exception variable
New submission from Mathias Svensson : Current behavior: In the very simple attached example an existing variable-name is used as the target in the except-part of a try-statement. The existing variable is deleted if an exception is throw. Excepted behavior: The only reasonable behaviors are keeping the original variable or keeping the exception. The current behavior is very unintuitive. -- components: Interpreter Core files: test.py messages: 135845 nosy: Mathias.Svensson priority: normal severity: normal status: open title: unexpected behavior with exception variable type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file21984/test.py ___ Python tracker <http://bugs.python.org/issue12064> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Mathias Behrle <[EMAIL PROTECTED]> added the comment: Just supporting, that proxy support over https is widely used and important. I am wondering, why this request is open for more than 2 years. Mathias -- nosy: +matb ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1424152> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7949] idle does not handle dark gtk color schemes
Mathias Panzenböck added the comment: I just noticed that the debugger also suffers from this problem. Doing a quick grep over the source reveals even more places that might cause problems (where only the bg or only the fg color is set). I think in ScrolledList.py the background="white" should just be removed. This and setting the fg color to black when the bg color is set to yellow (Debugger.py) makes the debugger usable. Checkboxes and radiobuttons seem to be messed up in general (forced white bg but using system fg color (white on white on my system); not idles but Tkinters or TKs fault). -- ___ Python tracker <http://bugs.python.org/issue7949> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18309] Make python slightly more relocatable
Mathias Fröhlich added the comment:
Hey,
Shakeeb Alireza is right, the original problem was an application that links
and embeds against libpython*{so,dll,dynlib} and should more easily find
components like /*/lib*/python*.*/site.py and most probably now it needs to
find getpath.py as well.
While I am no longer working on that application where I wanted to have that
feature, I still believe it would be worthwhile to find the *.py files in the
file system relative to the location of the libpython*{so,dll,dynlib} file.
Thanks for taking care.
Mathias
--
___
Python tracker
<https://bugs.python.org/issue18309>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18309] Make python slightly more relocatable
Mathias Fröhlich added the comment: Hi, Nice to see some progress. Still, I checked todays https://github.com/python/cpython.git master and 3.8 branch (is that the current cpython development code?). Neither of them contain a call to dladdr beside the macos code path mentioned in msg191994 by Ronald Oussoren which does this already for a long time. By the lack of dladdr, I conclude that the code idea of my request here is not solved. May be to rephrase that. The basic idea behind that request was to make pythons default way to setup the paths required to find the python modules based on the place where the python library resides instead of the python executable program. I do not mean the compile time prefix but the actual location of the shared object in the file system. That would help to build applications that embed cpython, ship and unpack the whole application tree including the python modules to a custom location, while still preserving the subtree structure containing the python shared library and the python modules, not known at compile time. Note that this patch contained code to make that work from within python without custom code in the embedding application. Doing that on the embedding and calling application side was always possible and still is possible - but that was not the point. best Mathias -- resolution: fixed -> status: closed -> open ___ Python tracker <https://bugs.python.org/issue18309> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18309] Make python slightly more relocatable
Mathias Fröhlich added the comment: Yes. msg191944 from Nick Coghlan, made me think that with all the initialization rework that appeared to be underway you want to incorporate that presented idea of basing the default onto the location of the libpython.so or the pythonX.X.dll instead of the location of python/python.exe. And as mentioned by Ronald Oussoren that would even align the methods used across the architectures to something common with a fallback to the current way that takes the path of the interpreter executable. At least that is what the provided patch implemented in the old code structure. And this does not even change the default for the common case where the default is plain useful. It is just changing the way how the default is determined so that the default for the case of an embedded interpreter is more meaningful. As stated somewhere above. The you can do that with application code when setting up the embedded interpreter, but it would be nice if that just works out of the box and by that helps applications not thinking of that solution. best Mathias -- ___ Python tracker <https://bugs.python.org/issue18309> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18309] Make python slightly more relocatable
Mathias Fröhlich added the comment: Ok, so far. But what shall I do now? It would be nice that python is a bit smarter in finding its increasing important module files when being embedded into an application. Anybody out there who wants to look at that contribution? best Mathias -- ___ Python tracker <https://bugs.python.org/issue18309> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38830] `A Qt GUI for logging` produces TypeError
New submission from Samuel Mathias : On the "logging cookbook" page: https://docs.python.org/3/howto/logging-cookbook.html#logging-cookbook The recipe "A Qt GUI for logging" produces the following error: `TypeError: update_status() missing 1 required positional argument: 'record'` -- assignee: docs@python components: Documentation messages: 356808 nosy: Samuel Mathias, docs@python priority: normal severity: normal status: open title: `A Qt GUI for logging` produces TypeError type: crash versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue38830> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40030] Error with math.fsum() regarding float-point error
New submission from Mathias Talbo : An issue occurs when running the following code. import math math.fsum([0.1, 0.2]), math.fsum([0.1, 0.7]) This should output 0.3, 0.8 respectively. Instead, it output 0.30004, 0.7999 The very floating-point error it is trying to stop from occurring. Thank you for your time. -- components: Extension Modules messages: 364730 nosy: Mathias Talbo priority: normal severity: normal status: open title: Error with math.fsum() regarding float-point error type: behavior versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue40030> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35328] Set a environment variable for venv prompt
Mathias Fredriksson added the comment: I believe GH-21587 does not fully address this issue because VIRTUAL_ENV_PROMPT is being conditionally set only if VIRTUAL_ENV_DISABLE_PROMPT is unset. Shell prompts must set VIRTUAL_ENV_DISABLE_PROMPT to non-empty to prevent venv from hijacking PS1. I'm one of the maintainers of the Pure prompt for zsh, and it would be great if VIRTUAL_ENV_PROMPT could always be set, just as VIRTUAL_ENV is too. -- nosy: +mafredri ___ Python tracker <https://bugs.python.org/issue35328> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35328] Set a environment variable for venv prompt
Change by Mathias Fredriksson : -- pull_requests: +21368 pull_request: https://github.com/python/cpython/pull/22324 ___ Python tracker <https://bugs.python.org/issue35328> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42364] Typo in french doc translation
New submission from Mathias MICHEL : In https://docs.python.org/fr/3/tutorial/inputoutput.html, § 7.1.3. Formatage de chaînes à la main After the code block the sentence between () should replace `donc` by `dont`: (Remarquez que l'espace séparant les colonnes vient de la manière dont print() fonctionne : il ajoute toujours des espaces entre ses arguments.) -- assignee: docs@python components: Documentation messages: 381043 nosy: docs@python, matm priority: normal severity: normal status: open title: Typo in french doc translation type: compile error versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue42364> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29298] argparse fails with required subparsers, un-named dest, and empty argv
Mathias Ettinger added the comment:
I was just hit by the very same issue and added the following test into
`_get_action_name` to work around it:
elif isinstance(argument, _SubParsersAction):
return '{%s}' % ','.join(map(str, argument.choices))
I checked #9253 as referenced by paul j3 and like the `argument.name()`
approach as well as it's less specific.
Any chance this can be addressed one way or another?
--
nosy: +Mathias Ettinger
___
Python tracker
<https://bugs.python.org/issue29298>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29974] typing.TYPE_CHECKING doc example is incorrect
New submission from Mathias Rav:
The documentation of typing.TYPE_CHECKING has an example (introduced in issue
#26141) that would lead to NameError at runtime. The example shows how to limit
the import of "expensive_mod" to type checkers, but then goes on to use
"expensive_mod.some_type" in a type annotation that is evaluated at runtime
("local_var: expensive_mod.some_type"). The use case of TYPE_CHECKING is
probably meant for type annotations placed in comments, e.g. "local_var #
type: expensive_mod.some_type".
--
assignee: docs@python
components: Documentation
messages: 291085
nosy: docs@python, rav
priority: normal
severity: normal
status: open
title: typing.TYPE_CHECKING doc example is incorrect
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7
___
Python tracker
<http://bugs.python.org/issue29974>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29974] typing.TYPE_CHECKING doc example is incorrect
Changes by Mathias Rav : -- pull_requests: +1155 ___ Python tracker <http://bugs.python.org/issue29974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29974] Change typing.TYPE_CHECKING doc example
Changes by Mathias Rav : -- title: typing.TYPE_CHECKING doc example is incorrect -> Change typing.TYPE_CHECKING doc example ___ Python tracker <http://bugs.python.org/issue29974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29974] Change typing.TYPE_CHECKING doc example
Mathias Rav added the comment: I have updated the patch after feedback from Jelle Zijlstra and Ivan Levkevskyi. Indeed the example was correct; the patch now adds wording from PEP 484 and PEP 526 to clarify why a function parameter annotation needs to be in quotes and a local variable annotation does not. -- ___ Python tracker <http://bugs.python.org/issue29974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29974] Change typing.TYPE_CHECKING doc example
Mathias Rav added the comment: Sorry for making a typo in your last name, Ivan Levkivskyi! I should know better and use copy-and-paste. -- ___ Python tracker <http://bugs.python.org/issue29974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18309] Make python slightly more relocatable
New submission from Mathias Fröhlich:
Hi all,
I want to move python a bit closer to be relocatable.
One problem to solve is where python finds its modules.
The usual lookup mechanism is to compile in a configure time
determined prefix that is used as a last resort path if the
paths are not set otherwise during application/interpreter startup.
The most commonly known way to change the module path at startup time
are probably the environment variables PYTHONPATH and PYTHONHOME.
The python interpreter itself already tries to interpret argv[0] to get to this
point, but it would be nice if an application embedded interpreter also finds
its module path without providing this argv[0] directly to the python library.
This should even work if being moved or being installed at a different path
than the configure time prefix path.
The proposal is to add an additional attempt to find the python modules
just before we resort to the compiled in prefix by looking at the path
to the python27.{so,dll}. Relative to this shared object python library
file the python modules are searched in the usual way. If there are
no python modules found relative to the python library file, the very
last resort compiled in prefix is used as usual.
For architectures where we cannot determine the path of the shared
library file, nothing changes.
I have attached a patch that tries to implement this.
It should serve as a base for discussions.
This change is tested on linux and behaves like expected. The windows code for
this is copied over from an other project where I have this actively running.
But this python code variant is not even compile tested on windows.
thanks in advance
Mathias
--
components: Installation
files: python-relative-path-lookup.diff
keywords: patch
messages: 191909
nosy: mathias
priority: normal
severity: normal
status: open
title: Make python slightly more relocatable
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python
3.4, Python 3.5
Added file: http://bugs.python.org/file30706/python-relative-path-lookup.diff
___
Python tracker
<http://bugs.python.org/issue18309>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18309] Make python slightly more relocatable
Mathias Fröhlich added the comment: Hi Eric, Thanks for looking at that ticket so fast! Reassigning this to 3.4 is great. In general, yes I can already do what I need more or less. This is the reason why I can be fine with about every python version. The point I bring up this change that I believe I am doing this at an unappropriate place as I need to know some internals of python when I do so and that I think that other can probably also benefit from this idea/change. What I currently do is to write an application that just uses python*.so as an embedded interpreter and this precompiled application might be relocated to about everywhere - just where it is unpacked. We are currently using the same sort of code to find out where the python*so file is and we use Py_SetPythonHome to set is to the directory where the so file resides. Why are we doing this? So, it takes the idea that is currently in the standard python interpreter. This one tries to be relocatable (means: pack the installation directory and unpack that somewhere else and be still able to run) by looking at argv[0] and dereferencing symbolic links until it arrives at a real file. Now suppose you want to embed python, then you do no longer use the standard python interpreter program. You may also use a different installation layout for basic things like bin and lib. So you end up with an application that is no longer able to find its provided python modules by looking at the applications path. But instead of starting from the path of the interpreter (which is not used in this case) or the application itself you could start from the python library path and look for your python installation relative to that. So as long as you stick with the relative file layout of everything that is python related (and only what is python related, the python.so and the modules) when you pack and unpack your precompiled application this would just work. So, put that in short: Instead of dynamically finding the the python module path relative to .../bin/python try to find the python relative to .../lib/libpython34.so. The benefit of that would be that every application that embeds python and needs to be relocatable will just work in the way that today only the standard python interpreter works. I try to get all of the PEP you pointed me to. As I am seeing this longer document the first time, I am not sure if I missed something there, but in that framework of this my proposal would probably influence the initial setting of sys.prefix (?) if this is not already provided from the embedding application. And yes I am perfectly fine with a different or more general approach. The initially attached patch is something that tried to integrate into the current checked in code as I understood it. Greetings Mathias -- ___ Python tracker <http://bugs.python.org/issue18309> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18309] Make python slightly more relocatable
Mathias Fröhlich added the comment: Hi Ronald, Eric, Nick, Looking up the symbol name of the current function should work also. And I am free to rename these functions to whatever you like. Attached is version 2 of the patch with the suggested changes. The windows implementation is still untested. It would be interesting to know if this kind of lookup scheme can be included into PEP 432. Provided the spirit of this PEP, I can imagine to provide several functions to build up the pythonpath starting from something. So say, have a 'get python path from argv[0]', a 'get python path from shared python library' and a 'get python path from prefix' function (I may miss a variant). Also a 'build python path from python home root entry point' function would be useful and could be used by the above functions. An application embedding python can then call those functions that are sensible for its own use and installation scheme to set the module path in the PyConfig struct. The Py_ReadConfig function will internally use the above suggested functions to build up the default configuration if not already provided. Greetings Mathias -- Added file: http://bugs.python.org/file30768/python-relative-path-lookup-v2.diff ___ Python tracker <http://bugs.python.org/issue18309> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16423] urllib data URL recipe
New submission from Mathias Panzenböck: I think it would be really helpful if urllib would support data URLs. However, I was told on the python-ideas mailing list that it would probably only added as recipe in the documentation. The attached patch adds such an recipe to the urllib.request documentation. I've never written a doc patch (or any patch) for python before, so I don't know if I added it at the right place in the right format. -- assignee: docs@python components: Documentation files: doc-urllib.request-data-url-recipe.patch hgrepos: 160 keywords: patch messages: 175041 nosy: docs@python, panzi priority: normal severity: normal status: open title: urllib data URL recipe versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file27914/doc-urllib.request-data-url-recipe.patch ___ Python tracker <http://bugs.python.org/issue16423> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9156] socket._fileobject: read raises AttributeError when closed in another thread
Mathias Panzenböck added the comment: The problem is that the other thread is blocked, waiting for new client connections. A common pattern for very simple server applications (like you write during exercises at universities) is: 2 threads: 1. A server thread waiting for clients, maybe spawning even more threads for each connection. 2. A small shell thread reading commands from stdin. When "quit" is read it closes the server socket, which shuts down the server (the server thread just notices that the socket was closed and shuts down properly). This pattern we used all the time when writing exercises in Java. However, it seems to work quite differently in Python 3. I have to check if this problem still exists. -- ___ Python tracker <http://bugs.python.org/issue9156> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9156] socket._fileobject: read raises AttributeError when closed in another thread
Mathias Panzenböck added the comment: Yeah, I don't remember anymore. It was so long ago. -- ___ Python tracker <http://bugs.python.org/issue9156> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16423] urllib data URL recipe
Mathias Panzenböck added the comment: New patch. Instead of adding the data URL support to the doc as a recipe I added it to urllib.request directly. I think this is better and justified, because the old legacy URLopener had (some kind) of support for data URLs. OT: I think that the legacy URLopener has bugs. It only unquotes the data if it's base64 encoded, but it should be unquoted in any case. Also it returns a StringIO and decodes the content as latin-1. This is wrong, the content is a binary string. It could be text encoded in any kind of charset or not text at all (e.g. an image). -- Added file: http://bugs.python.org/file27994/urllib.request-data-url.patch ___ Python tracker <http://bugs.python.org/issue16423> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16423] urllib data URL
Changes by Mathias Panzenböck : -- components: +Library (Lib) -Documentation title: urllib data URL recipe -> urllib data URL type: -> enhancement ___ Python tracker <http://bugs.python.org/issue16423> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16423] urllib data URL
Mathias Panzenböck added the comment: On 11/18/2012 12:36 AM, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > A couple of comments: > > - the patch needs a test (and docs too) Will do (when I have time). > - are you sure ignoring POSTed data is the right thing to do? Shouldn't we > forbid it instead? > - I think it would be nice to reference the RFC number somewhere > - not sure why you raise IOError on a bad URL; I would say ValueError is the > right exception here > I did that because that's what the old URLopener code does (ignoring POSTed data and raising an IOError). The comment is actually a 1:1 copy of the old code. > +1 on the general idea, by the way. > > -- > nosy: +pitrou > > ___ > Python tracker > <http://bugs.python.org/issue16423> > ___ > -- ___ Python tracker <http://bugs.python.org/issue16423> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16423] urllib data URL
Mathias Panzenböck added the comment: On 11/18/2012 12:36 AM, Antoine Pitrou wrote: > > - the patch needs a test (and docs too) > - are you sure ignoring POSTed data is the right thing to do? Shouldn't we > forbid it instead? Btw.: The file:// protocol handler also just ignores posted data, so I think the data url handler shouldn't deviate from that. Either both raise an error when data is posted or none. -- ___ Python tracker <http://bugs.python.org/issue16423> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16423] urllib data URL
Mathias Panzenböck added the comment: Ok, I've added a documentation and some tests. Is it ok this way? More tests? More/other documentation? -- Added file: http://bugs.python.org/file28017/urllib.request-data-url.patch ___ Python tracker <http://bugs.python.org/issue16423> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16423] urllib data URL
Changes by Mathias Panzenböck : Removed file: http://bugs.python.org/file28017/urllib.request-data-url.patch ___ Python tracker <http://bugs.python.org/issue16423> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16423] urllib data URL
Changes by Mathias Panzenböck : Added file: http://bugs.python.org/file28018/urllib.request-data-url.patch ___ Python tracker <http://bugs.python.org/issue16423> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16423] urllib data URL
Changes by Mathias Panzenböck : Removed file: http://bugs.python.org/file27994/urllib.request-data-url.patch ___ Python tracker <http://bugs.python.org/issue16423> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16423] urllib data URL
Mathias Panzenböck added the comment: Great! Feels awesome to have my first bit of code contributed to the Python project. :) -- ___ Python tracker <http://bugs.python.org/issue16423> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16423] urllib data URL
Mathias Panzenböck added the comment: Will do (later today). -- ___ Python tracker <http://bugs.python.org/issue16423> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16423] urllib data URL
Mathias Panzenböck added the comment: Hmm, which of the two initial licenses should I choose? Which one do you rather want me to choose? -- ___ Python tracker <http://bugs.python.org/issue16423> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9156] socket._fileobject: read raises AttributeError when closed in another thread
New submission from Mathias Panzenböck :
When you open a socket._fileobject through sock.makefile('rb') or similar and
you read blocking in one thread and close the file object from another thread
the reading thread gets an AttributeError. This is because the close method
sets the underlying fileobject._sock member to None and the read/readline/...
methods call recv on this member without checking if its None. I think the
_sock member should not be set to None at all but a flag should be set that
this file object is closed.
For the time being I use the "bugfix" I attached and therefore do not call
sock.makefile('rb') but FileObject(sock, 'rb'). FileObject is a subtype of
socket._fileobject that overrides the close method and closed property.
I don't know if this bug persists in 2.7 or 3.x. I still use Fedora 12 and that
comes with Python 2.6.2.
--
components: Library (Lib)
files: FileObject.py
messages: 109281
nosy: panzi
priority: normal
severity: normal
status: open
title: socket._fileobject: read raises AttributeError when closed in another
thread
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file17860/FileObject.py
___
Python tracker
<http://bugs.python.org/issue9156>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29701] Add close method to queue.Queue
New submission from Mathias Fröjdman: queue.Queue should have a close() method. The result of calling the method would be to raise a new exception - queue.Closed, for any subsequent calls to Queue.put, and after the queue is empty, also for Queue.get. Why: To allow producers (callers of Queue.put) to signal there will be no more items, and consumers may stop asking for more by calling Queue.get. Currently the opposite (ie. waiting until all produced items/"tasks" have been consumed and handled) is possible with Queue.task_done() and Queue.join(). This functionality is useful in both application and library code. For example in AMQP, a server may push new messages over a TCP connection to a consumer, which translates into the library calling Queue.put for received messages, and the application using the library calling Queue.get to receive any new messages. The consumer may however be cancelled at any time, or the TCP connection closed and the Queue.get caller signaled that there will be no more messages. With Queue.close() that is easy - without it one needs to wrap the Queue.get calls). In an application context where a KeyboardInterrupt should lead to closing the application cleanly, being able to call Queue.close(), catching the Closed exception in any consumers (some of which may be in other threads) and exiting cleanly makes the job that much easier. A common pattern in working around this issue is to call Queue.put(None), and treat a None from Queue.get() as a signal to clean up. This works well when one knows there is at most one consumer. In the case of many consumers, one needs to wrap the Queue and for example add another None to the queue in consumers to not leave any remaining get() call waiting indefinitely. This pattern occurs even in the standard library: https://github.com/python/cpython/blob/7b90e3674be86479c51faf872d0b9367c9fc2f96/Lib/concurrent/futures/thread.py#L141 If accepting this proposal, a corresponding change should be made to asyncio.Queue. I have a tentative implementation (no tests or doc outside the module) in https://github.com/mwfrojdman/cpython/blob/closeable_queue/Lib/queue.py The Queue.close() method has an optional argument clear (default False), which clears the queue of items if set to true. This is useful for example when exiting an application, and one doesn't want consumers to get any more items before being raised a Closed exception. The changes are backwards compatible for users of the class, ie. if Queue.close() is not called, the behavior stays intact. Because of the clear argument, there is a new private method Queue._clear(), which does the actual clearing of the queue representation. Subclasses for which self.queue.clear() doesn't cut it, need to override it before .close(True) works. Background: https://github.com/python/asyncio/pull/415#issuecomment-263658986 -- components: Library (Lib) messages: 288828 nosy: mwf priority: normal severity: normal status: open title: Add close method to queue.Queue type: enhancement versions: Python 3.7 ___ Python tracker <http://bugs.python.org/issue29701> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24795] Make event loops with statement context managers
New submission from Mathias Fröjdman: Since asyncio event loops have to be closed nowadays, it would be pretty convenient and pythonic to make BaseEventLoop a context manager that calls self.close() in __exit__ the same way as contextlib.closing() does it. Example: import asyncio with asyncio.get_event_loop() as loop: loop.run_until_complete(func()) instead of import asyncio from contextlib import closing with closing(asyncio.get_event_loop()) as loop: loop.run_until_complete(func()) or event the bulkier import asyncio loop = asyncio.get_event_loop() try: loop.run_until_complete(func()) finally: loop.close() The attached patch applies to Python 3.5b4's asyncio/base_events.py -- components: asyncio files: patch messages: 248032 nosy: Mathias Fröjdman, gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: Make event loops with statement context managers type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file40129/patch ___ Python tracker <http://bugs.python.org/issue24795> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24795] Make event loops with statement context managers
Mathias Fröjdman added the comment: (Just noticed http://bugs.python.org/issue19860, which I originally failed to notice when just searching for "asyncio loop" and not context manager) Anyway, in recent Python/asyncio versions, failing to close the event loop before exiting whole the process can cause problems, so I think the case is valid now. -- ___ Python tracker <http://bugs.python.org/issue24795> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26923] asyncio.gather drops cancellation
Changes by Mathias Arens : -- nosy: +tatellos ___ Python tracker <http://bugs.python.org/issue26923> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23837] read pipe transport tries to resume reading after loop is gone
New submission from Mathias Fröjdman:
Script attached which reproduces the issue.
Steps to reproduce:
0) Use python 3.4.3 on Linux. Does not repro with 3.4.0 or 3.4.2.
1) Create a child process with asyncio.create_child_exec and stdout=PIPE
2) loop yield from child.read(n) (i used n=2048, any other positive value <
StreamRead._limit ought to work too)
3) Write >= StreamRead._limit * 2 + 1 (by default 2**17+1) bytes from child
process and exit
File referenced below: asyncio/streams.py
feed_data is called when data arrives from the child process. Having more than
2 * self._limit bytes in self._buffer will lead to StreamReader pausing reading
on line 372.
feed_eof sets self._eof to True, but that value is not checked in relevant
sections later.
Child process exits, which will lead to self._loop = None being set apparently
on line 405 of _UnixReadPipeTransport._call_connection_lost in
asyncio/unix_events.py (could not find any other location where it would be set
to None).
After a number of read()s, self._maybe_resume_transport() is called when
len(self._buffer) <= self._limit (ie. <= 64k left in buffer). self._paused will
evaluate true too, so self._transport.resume_reading() is called on line 349.
That will call self._loop.add_reader(self._fileno, self._read_ready) on line
364 of asyncio/unix_events.py. self._loop is None, so and AttributeError is
raised when None has no add_reader attribute:
Traceback (most recent call last):
File "child_reader.py", line 29, in
print('read {} bytes from child'.format(loop.run_until_complete(fail(
File "/home/frojma/python-3.4.3/lib/python3.4/asyncio/base_events.py", line
316, in run_until_complete
return future.result()
File "/home/frojma/python-3.4.3/lib/python3.4/asyncio/futures.py", line 275,
in result
raise self._exception
File "/home/frojma/python-3.4.3/lib/python3.4/asyncio/tasks.py", line 238, in
_step
result = next(coro)
File "child_reader.py", line 15, in fail
chunk = yield from child.stdout.read(2048)
File "/home/frojma/python-3.4.3/lib/python3.4/asyncio/streams.py", line 478,
in read
self._maybe_resume_transport()
File "/home/frojma/python-3.4.3/lib/python3.4/asyncio/streams.py", line 354,
in _maybe_resume_transport
self._transport.resume_reading()
File "/home/frojma/python-3.4.3/lib/python3.4/asyncio/unix_events.py", line
364, in resume_reading
self._loop.add_reader(self._fileno, self._read_ready)
--
components: asyncio
files: child_reader.py
messages: 239779
nosy: gvanrossum, haypo, mwf, yselivanov
priority: normal
severity: normal
status: open
title: read pipe transport tries to resume reading after loop is gone
type: crash
versions: Python 3.4
Added file: http://bugs.python.org/file38778/child_reader.py
___
Python tracker
<http://bugs.python.org/issue23837>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
