[issue46050] [pathlib] Option so that OSError does not block glob in pathlib library
New submission from matt :
Hi there,
ISSUE DESCRIPTION
when I browse starting from the linux root ('/')
path = pathlib.Path('/')
_glob = '**/*'
for p in path.glob(_glob):
The program stops on my machine because of OSError.
File "/usr/lib/python3.8/pathlib.py", line 535, in _select_from
entries = list(scandir_it)
OSError: [Errno 22] Invalid argument: '/proc/5916/task/5916/net'
Entering post mortem debugging...
> /usr/lib/python3.8/pathlib.py(535)_select_from()
533 try:
534 with scandir(parent_path) as scandir_it:
--> 535 entries = list(scandir_it)
536 for entry in entries:
537 if self.dironly:
I also another case is if a cloud drive is disconnected.
QUICK SOLUTION
I solved both issues for me by adding an adding an except OSError: return at
the end of the two function below:
class _WildcardSelector(_Selector):
def _select_from(self, parent_path, is_dir, exists, scandir):
(...)
except OSError:
return
class _RecursiveWildcardSelector(_Selector):
def _iterate_directories(self, parent_path, is_dir, scandir):
(...)
except OSError:
return
FEATURE REQUEST
I don't know the consequences of those 2 modifications so perhaps they could
follow an option when calling glob with an optional parameter ignoreOSerror =
false by default?!
--
components: Library (Lib)
messages: 408314
nosy: matt32106
priority: normal
severity: normal
status: open
title: [pathlib] Option so that OSError does not block glob in pathlib library
type: enhancement
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue46050>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38231] Documentation search results focus on tutorials and not language specifications
New submission from Matt : * Problem: Documentation search results favor tutorials and over language specifications * How to reproduce: I often forget simple syntax. For example, say I want to raise an exception. Clearly, I need to search for "raise". 1. Go to https://docs.python.org/3.6/search.html 2. Type in "raise" * Expected result: A clearly understandable link to the "raise" documentation or something closely related, such as link to the "Built-in Exceptions" documentation * Actual result: The documentation for the "raise" keyword is given in search result number... at first, second, and third glance, I don't even know if a page describing the "raise" command is returned. The first result is a 2to3 conversion tutorial. The second result is for urllib.error. The third result is a unittest.mock tutorial The fourth result is an optparse tutorial The fifth result is a tutorial for "simple statements" The sixth result is a tutorial for "Errors and exceptions". The seventh result is a for "exception handling" After much poking around, it turns out that the documentation for "raise" is in the "Simple statements" tutorial. Knowing to select the correct link requires knowing that "raise" is a statement, as the only indication that this is the correct link is that "raise_stmt" occurs in its preview snippet. Searching for related terms, such as "exceptions" or "errors", returns similarly indirect results, such as tutorials for "Extending Python with C or C++" and "API Reference". The experience is the same, regardless of the Python version searched. * Proposed solution: I'm not sure how I can help with this, but I would like to. For example, is there some kind of tagging I could do while meandering through the morass of Python documentation? -- assignee: docs@python components: Documentation messages: 352846 nosy: docs@python, excalamus priority: normal severity: normal status: open title: Documentation search results focus on tutorials and not language specifications type: behavior versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue38231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38231] Documentation search results focus on tutorials and not language specifications
Matt added the comment: I will close this issue and post in one of the two places you linked. Thank you for your prompt reply and affirmation of my observations. I feel my language was colored by frustration, yet you focused instead on my willingness to help. I appreciate that and find your response encouraging. Somewhat related, I am responding to this through the bugs.python.org interface. If I reply directly to the email the tracker sent me, will my reply be properly routed to this thread? It's not clear from the send address what would happen if I replied via email. -- ___ Python tracker <https://bugs.python.org/issue38231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39021] multiprocessing is_alive() between children processes
New submission from Matt :
I'm trying to evaluate process' state between two "sibling" processes
(processes created by the same parent process); using the .is_alive() and
exitcode to evaluate whether a process has been init'd, started, finished
successfully or unsuccessfully.
The reference to one process is passed to the other and I'd like to call
.is_alive(). This raises the following assertion error:
Process C-2:
Traceback (most recent call last):
File "/usr/lib/python3.7/multiprocessing/process.py", line 297, in _bootstrap
self.run()
File "/home/timms/.PyCharm2019.2/config/scratches/is_alive_method.py", line
59, in run
print("brother - ",self.brother.state)
File "/home/timms/.PyCharm2019.2/config/scratches/is_alive_method.py", line
16, in state
if self.is_alive():
File "/usr/lib/python3.7/multiprocessing/process.py", line 151, in is_alive
assert self._parent_pid == os.getpid(), 'can only test a child process'
AssertionError: can only test a child process
It's obvious that the assertion fails given the family structure of the
processes. Overwriting the is_alive() method in my own process class appears to
produce my desired output behaviour - with assertion and discarding self
removed (see attachment).
Is there something fundamental to how process' operate that I should be weary
of? I understand that is_alive also joins itself if possible; is that the sole
reason for the assertion? Could a method that mirrors is_alive() without the
assertion and discard method work with the desired intention I've described
above?
--
files: is_alive_method.py
messages: 358232
nosy: matttimms
priority: normal
severity: normal
status: open
title: multiprocessing is_alive() between children processes
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48770/is_alive_method.py
___
Python tracker
<https://bugs.python.org/issue39021>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6392] IDLE 3.1 will not open
New submission from Matt :
IDLE will not open; it does not give an error or even appear on the
process list.
I am using Windows XP on an IBM Thinkpad. I tried the prescribed
solution on Issue 4049, and it returned this message:
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\Matt>cd \python31
C:\Python31>python.exe Lib\idlelib\idle.py
Traceback (most recent call last):
File "Lib\idlelib\idle.py", line 11, in
idlelib.PyShell.main()
File "C:\Python31\Lib\idlelib\PyShell.py", line 1374, in main
root = Tk(className="Idle")
File "C:\Python31\Lib\tkinter\__init__.py", line 1632, in __init__
self.tk = _tkinter.create(screenName, baseName, className,
interactive, want
objects, useTk, sync, use)
_tkinter.TclError: Can't find a usable init.tcl in the following
directories:
{C:\IBMTOOLS\Python22\tcl\tcl8.4} C:/IBMTOOLS/Python22/tcl/tcl8.5
C:/Python3
1/lib/tcl8.5 C:/lib/tcl8.5 C:/lib/tcl8.5 C:/library C:/library
C:/tcl8.5.2/libra
ry C:/tcl8.5.2/library
C:/IBMTOOLS/Python22/tcl/tcl8.4/init.tcl: version conflict for
package "Tcl": ha
ve 8.5.2, need exactly 8.4
version conflict for package "Tcl": have 8.5.2, need exactly 8.4
while executing
"package require -exact Tcl 8.4"
(file "C:/IBMTOOLS/Python22/tcl/tcl8.4/init.tcl" line 19)
invoked from within
"source C:/IBMTOOLS/Python22/tcl/tcl8.4/init.tcl"
("uplevel" body line 1)
invoked from within
"uplevel #0 [list source $tclfile]"
This probably means that Tcl wasn't installed properly.
C:\Python31>
I am very new to Python (and programming in general), and I have no
idea how to fix this.
By the way, I did install the program for all users.
--
components: IDLE
messages: 89962
nosy: matthall
severity: normal
status: open
title: IDLE 3.1 will not open
type: behavior
versions: Python 3.1
___
Python tracker
<http://bugs.python.org/issue6392>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14102] argparse: add ability to create a man page
Changes by Matt : -- nosy: +matthewjohn ___ Python tracker <http://bugs.python.org/issue14102> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17369] Message.get_filename produces exception if the RFC2231 encoding is ill-formed
Changes by Matt : -- components: +Library (Lib) -email versions: +Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue17369> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17369] Message.get_filename produces exception if the RFC2231 encoding is ill-formed
Changes by Matt : -- versions: -Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue17369> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17369] Message.get_filename produces exception if the RFC2231 encoding is ill-formed
Changes by Matt : -- components: +email -Library (Lib) versions: -Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue17369> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34798] pprint ignores the compact parameter for dicts
Matt Bogosian added the comment: Please consider highlighting that dicts are not included in the documentation. While *technically* true, this ... > compact impacts the way that long sequences (lists, tuples, sets, etc) are > formatted. If compact is false (the default) then each item of a sequence > will be formatted on a separate line. If compact is true, as many items as > will fit within the width will be formatted on each output line. ... has several problems. First, sequence is a term of art that also has a common meaning. This creates a potential ambiguity in the understanding of the reader. Resolving that ambiguity in this context requires that readers have already internalized that dicts are not Python sequences. Those new to Python may not understand the (to them, subtle) differences between Python's iterables and sequences. Second, the "etc" only expands that ambiguity and invites confusion. Third, the term "items" is strongly associated with dicts and is used several times throughout the paragraph. This ... > According to https://docs.python.org/3/library/pprint.html compact impacts > the way that sequences are displayed, and a dict is not a sequence. ... is unhelpfully pedantic, and ignorant of the needs of the newcomer (a key demographic of documentation). Documentation is a core product surface with a diverse audience. Rather than focus on technical correctness, documentation authors should focus on accessibility. Redundancy is a feature, not a bug. You can't predict how your reader got to that slice of the documentation. Imagine this as an opportunity to educate or reinforce concepts for readers, not as an opportunity to argue from a position of technical superiority. The fact that there are now four developers who have taken their time to file patches, bugs, and comments is pretty strong signal that confusion exists among the audience and that the documentation is insufficient. -- nosy: +posita ___ Python tracker <https://bugs.python.org/issue34798> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46133] Unclear whether one can (or how to) provide source to exec-generated code
New submission from Matt B :
Unless I missed it, looking at
https://github.com/python/cpython/blob/main/Lib/pdb.py,
https://github.com/python/cpython/blob/main/Lib/inspect.py, and
https://docs.python.org/3/library/pdb.html doesn't give much of a clue how to
provide sources to exec-generated code.
I may have misread, but pdb *seems* to lean on inspect.findsource which
eventually excludes sources that match `^<.*>$` (like ``).
Running attached test_case.py:
% python test_case.py
> (4)foo()
(Pdb) l
[EOF]
(Pdb) c
inspect.getfile():
calling inspect.findsource() ...
Traceback (most recent call last):
File "/Users/matt/Documents/dev/numerary/test_case.py", line 12, in
foo()
File
"/Library/Frameworks/MacPorts-20200907/Python.framework/Versions/3.9/lib/python3.9/inspect.py",
line 835, in findsource
raise OSError('could not get source code')
OSError: could not get source code
--
files: test_case.py
messages: 408910
nosy: posita
priority: normal
severity: normal
status: open
title: Unclear whether one can (or how to) provide source to exec-generated code
Added file: https://bugs.python.org/file50502/test_case.py
___
Python tracker
<https://bugs.python.org/issue46133>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46133] Unclear whether one can (or how to) provide source to exec-generated code
Change by Matt B : -- components: +Library (Lib) type: -> behavior versions: +Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46260] Misleading SyntaxError on f-string
New submission from Matt Delengowski :
Example code
```
foo = 1
f"blank (open paren {foo )"
```
Error report
File "", line 1
f"blank (open paren {foo )"
^
SyntaxError: f-string: unmatched ')'
The problem is due to unmatched '}' however.
--
components: Parser
messages: 409709
nosy: Delengowski, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Misleading SyntaxError on f-string
type: behavior
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue46260>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46260] Misleading SyntaxError on f-string
Matt Delengowski added the comment: Hi Eric, I see what are you referring to. Like you said unintuitive but still correct. Do you think it would be worthwhile to change the order of the checking such that '}' is always first? Or could the same edge case still appear but just the other way around? Either way, thanks for looking into this and sorry for the trouble. -- ___ Python tracker <https://bugs.python.org/issue46260> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46133] Feature request: allow mechanism for creator of exec-generated code to provide source to pdb
Change by Matt B : -- status: closed -> open title: Unclear whether one can (or how to) provide source to exec-generated code -> Feature request: allow mechanism for creator of exec-generated code to provide source to pdb type: behavior -> enhancement ___ Python tracker <https://bugs.python.org/issue46133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46133] Feature request: allow mechanism for creator of exec-generated code to provide source to pdb
Change by Matt B : -- resolution: not a bug -> ___ Python tracker <https://bugs.python.org/issue46133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46133] Feature request: allow mechanism for creator of exec-generated code to provide source to pdb
Matt B added the comment: Please treat this as a feature request to add the ability for pdb (and internals) to ingest sources for exec-generated code. -- ___ Python tracker <https://bugs.python.org/issue46133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()
Matt Wozniski added the comment: I agree with Brett. Adding `allow_z` (or perhaps `compact` or `use_utc_designator` if we're bikeshedding) as an optional keyword only argument to `.isoformat()` would allow us to keep the explanation that what `.fromisoformat()` can parse is exactly what `.isoformat()` can produce, while giving a feature to `.fromisoformat()` that many have asked for and that would have minimal overhead in terms of code complexity or runtime performance. Would you accept a PR that implements that, Paul? -- nosy: +godlygeek ___ Python tracker <https://bugs.python.org/issue35829> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42343] threading.local documentation should be on the net...
Matt B added the comment: @rhettinger, the docstring[1] alluded to in the docs is quite lengthy. Are you suggesting copying it straight across to the standard library documentation? If not, can you give (or link to) some documentation standards or other guidance on constructing a viable PR? Also, for newcomer friendly issues, it is helpful to link to instructions on how to construct and submit a PR for review. That will increase the likelihood of a community-provided fix. [1]: https://github.com/python/cpython/blob/main/Lib/_threading_local.py -- nosy: +posita ___ Python tracker <https://bugs.python.org/issue42343> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42343] threading.local documentation should be on the net...
Matt B added the comment: @ztane, if you are interested in trying your hand at a PR, these will be generally useful: * https://devguide.python.org/ * https://devguide.python.org/documenting/ -- ___ Python tracker <https://bugs.python.org/issue42343> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46581] _typevar_types and _paramspec_tvars are missing from _GenericAlias.copy_with
New submission from Matt B : c55ff1b352f8b82184f80d9dea220e832691acfc was submitted to fix #44098 and added the _typevar_types and _paramspec_tvars properties to _GenericAlias. However, those properties continue to be omitted from _GenericAlias.copy_with[1]. Further, typing.py is fairly intricate, which makes it hard to understand if that is the only place those properties are absent. A more careful review/audit may be in order. [1]: https://github.com/python/cpython/blob/8b1b27f1939cc4060531d198fdb09242f247ca7c/Lib/typing.py#L1069-L1070 -- components: Library (Lib) messages: 412144 nosy: posita priority: normal severity: normal status: open title: _typevar_types and _paramspec_tvars are missing from _GenericAlias.copy_with versions: Python 3.10, Python 3.11 ___ Python tracker <https://bugs.python.org/issue46581> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46581] _typevar_types and _paramspec_tvars are missing from _GenericAlias.copy_with
Matt B added the comment: Filed by request: https://github.com/python/cpython/pull/26091#issuecomment-1024900261 -- ___ Python tracker <https://bugs.python.org/issue46581> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46581] _typevar_types and _paramspec_tvars are missing from _GenericAlias.copy_with
Matt B added the comment: I am happy to attempt a patch, but I don't understand what's going on with _ConcatenateGenericAlias. Or rather, I don't fully understand the various copy_with semantics. This code is *very* hard to follow. Patching _GenericAlias.copy_with seems relatively straightforward: def copy_with(self, params): -return self.__class__(self.__origin__, params, name=self._name, inst=self._inst) +return self.__class__(self.__origin__, params, name=self._name, inst=self._inst, + _typevar_types=self._typevar_types, + _paramspec_tvars=self._paramspec_tvars) _ConcatenateGenericAlias.copy_with, on the other hand, appears to return a tuple rather than a type until it falls back to the parent implementation. What does one do with that? Also, what about _AnnotatedAlias, _SpecialGenericAlias, _UnionGenericAlias, or _strip_annotations? Do any of those need to be modified? I can't find any tests that deal with copy_with directly, so I'm assuming its use is stressed via higher level code paths, but it's not clear what use cases that method is supposed to serve. The good news is that its use is confined to typing.py. The bad news is that file gives little insight to those who aren't already experts in that territory. In short, I will do my best, but I suspect I will need patience and guidance in arriving something acceptable. -- ___ Python tracker <https://bugs.python.org/issue46581> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46581] _typevar_types and _paramspec_tvars are missing from _GenericAlias.copy_with
Matt B added the comment: Thanks, @kj! Fantastic education and insight! I'm sad that I needed you as an interpreter but very grateful you were around to provide the interpretation. Working on a patch now…. -- ___ Python tracker <https://bugs.python.org/issue46581> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46581] _typevar_types and _paramspec_tvars are missing from _GenericAlias.copy_with
Change by Matt Bogosian : -- keywords: +patch nosy: +mbogosian nosy_count: 4.0 -> 5.0 pull_requests: +29243 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31061 ___ Python tracker <https://bugs.python.org/issue46581> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46614] Add option to output UTC datetimes as "Z" in `.isoformat()`
Matt Wozniski added the comment:
> I feel like "If the offset is 00:00, use Z" is the wrong rule to use
> conceptually
This is a really good point that I hadn't considered: `+00:00` and `Z` are
semantically different, and just because a datetime has a UTC offset of 0
doesn't mean it should get a `Z`; `Z` is reserved specifically for UTC.
It seems like the most semantically correct thing would be to only use `Z` if
`tzname()` returns exactly "UTC". That would do the right thing for your London
example for every major timezone library I'm aware of:
>>> datetime.datetime.now(zoneinfo.ZoneInfo("Europe/London")).tzname()
'GMT'
>>> datetime.datetime.now(zoneinfo.ZoneInfo("UTC")).tzname()
'UTC'
>>> datetime.datetime.now(datetime.timezone.utc).tzname()
'UTC'
>>> datetime.datetime.now(dateutil.tz.gettz("Europe/London")).tzname()
'GMT'
>>> datetime.datetime.now(dateutil.tz.UTC).tzname()
'UTC'
>>> datetime.datetime.now(pytz.timezone("Europe/London")).tzname()
'GMT'
>>> datetime.datetime.now(pytz.UTC).tzname()
'UTC'
I think the right rule to use conceptually is "if `use_utc_designator` is true
and the timezone name is 'UTC' then use Z". We could also check the offset, but
I'm not convinced we need to.
--
nosy: +godlygeek
___
Python tracker
<https://bugs.python.org/issue46614>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46892] Async Call-Stack Reconstruction
New submission from Matt Page : Profiling tools that use the call-stack (i.e. all of them) paint an incomplete picture of what’s really going on in async-heavy codebases. They can only show the stack of the currently executing task; they miss the chain of awaitables that are transitively waiting on the current task. To remedy this, we have added support in Cinder to expose the async call-stack. This consists of the call stack for the currently executing task, followed by the chain of awaitables that are transitively reachable from the currently executing task. See below for a clarifying example. ``` async def f1(): return await f2() async def f2(): return await asyncio.ensure_future(f3()) async def f3(): return await f4() async def f4(): await asyncio.sleep(10) return 42 ``` When retrieved from f4, the two different stacks (top-of-stack last) are: sync - [f3, f4] async - [f1, f2, f3, f4] We’d like to merge our implementation into CPython so that other heavy users of asyncio can benefit. This will consist of a few parts: 1. A new limited C-API to set and retrieve the “awaiter” of an awaitable object. 2. Additions to PyAsyncMethods to store function pointers for setting and retrieving the awaiter on instances. 3. An API in managed code to retrieve the async call stack as a list of fully qualified names (i.e. :.). -- components: Interpreter Core, asyncio messages: 414301 nosy: asvetlov, dino.viehland, itamaro, mpage, yselivanov priority: normal severity: normal status: open title: Async Call-Stack Reconstruction type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46892> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46895] Type-Modified Callbacks
New submission from Matt Page : CPython extensions providing optimized execution of Python bytecode (e.g. the Cinder JIT), or even CPython itself (e.g. the faster-cpython project) may wish to cache access to lookups in the class hierarchy (e.g. when resolving the target of a method call). Extensions that perform these optimizations need to know when to invalidate the cached values. CPython already has a mechanism to invalidate its internal state (e.g. the global method cache) when a type is modified: _PyType_Modified. We propose adding an API to allow extensions to set a callback that will be invoked by _PyType_Modified whenever a type, or any ancestor of the type in the class hierarchy, changes. Proposed API: ``` // A callback to be invoked with the modified type and optionally the name of // the attribute that was modified. typedef void(*PyType_ModifiedCallback)(PyTypeObject* type, PyObject* attr); // Set or get the callback. The callback may be cleared by supplying a NULL callback. void PyType_SetModifiedCallback(PyType_ModifiedCallback callback); PyType_ModifiedCallback PyType_GetModifiedCallback(); ``` -- components: C API, Interpreter Core messages: 414305 nosy: carljm, dino.viehland, itamaro, mpage priority: normal severity: normal status: open title: Type-Modified Callbacks type: enhancement ___ Python tracker <https://bugs.python.org/issue46895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46895] Allow extensions to set a callback to be invoked when a type is modified
Change by Matt Page : -- title: Type-Modified Callbacks -> Allow extensions to set a callback to be invoked when a type is modified ___ Python tracker <https://bugs.python.org/issue46895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46897] Add API to allow extensions to set callback function on creation, modification, and destruction of PyFunctionObject
New submission from Matt Page :
CPython extensions providing optimized execution of Python bytecode (e.g. the
Cinder JIT) may need to hook into the lifecycle of function objects to
determine what to optimize, invalidate previously-optimized functions, or free
resources allocated for functions that no longer exist. For example, when
inlining a function, the Cinder JIT will use the bytecode of the inlined
function that was known at compile-time. If the bytecode for the inlined
function changes at runtime (i.e. if __code__ was reassigned) the JIT needs to
invalidate any code into which the function was inlined. We propose adding an
API to allow extensions to set callbacks that will be invoked whenever
functions are created, modified, or destroyed.
Proposed API:
```
typedef enum {
PYFUNC_LCEVT_CREATED,
PYFUNC_LCEVT_MODIFIED,
PYFUNC_LCEVT_DESTROYED
} PyFunction_LifecycleEvent;
typedef enum {
PYFUNC_ATTR_CODE,
PYFUNC_ATTR_GLOBALS,
PYFUNC_ATTR_DEFAULTS,
PYFUNC_ATTR_KWDEFAULTS,
PYFUNC_ATTR_CLOSURE,
PYFUNC_ATTR_NOT_APPLICABLE,
} PyFunction_AttrId;
// A callback to be called in response to events in a function's lifecycle.
//
// The callback is invoked after a function is created and before the function
// is modified or destroyed.
//
// On modification the third argument indicates which attribute was modified
// and the fourth argument is the new value.
// Otherwise the third argument is PYFUNC_ATTR_NOT_APPLICABLE and the fourth
// argument is NULL.
typedef void(*PyFunction_LifecycleCallback)(
PyFunction_LifecycleEvent event,
PyFunctionObject* func,
PyFunction_AttrId attr,
PyObject* new_value);
void PyFunction_SetLifecycleCallback(PyFunction_LifecycleCallback callback);
PyFunction_LifecycleCallback PyFunction_GetLifecycleCallback();
```
--
components: C API
messages: 414308
nosy: carljm, dino.viehland, itamaro, mpage
priority: normal
severity: normal
status: open
title: Add API to allow extensions to set callback function on creation,
modification, and destruction of PyFunctionObject
type: enhancement
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue46897>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46898] Add API to allow extensions to set callback function on creation and destruction of PyCodeObject
New submission from Matt Page :
CPython extensions providing optimized execution of Python bytecode (e.g. the
Cinder JIT) may need to hook into the lifecycle of code objects to determine
what to optimize or to free resources allocated for code objects that no longer
exist. We propose adding an API to allow extensions to set callbacks that will
be invoked whenever code objects are created or destroyed.
Proposed API:
```
typedef enum {
PYCODE_LCEVT_CREATED,
PYCODE_LCEVT_DESTROYED
} PyCode_LifecycleEvent;
// A callback to be called when a code object is created or about to be
destroyed.
typedef void(*PyCode_LifecycleCallback)(
PyCode_LifecycleEvent event,
PyCodeObject* code);
void PyCode_SetLifecycleCallback(PyCode_LifecycleCallback callback);
PyCode_LifecycleCallback PyCode_GetLifecycleCallback();
```
--
components: C API
messages: 414309
nosy: carljm, dino.viehland, itamaro, mpage
priority: normal
severity: normal
status: open
title: Add API to allow extensions to set callback function on creation and
destruction of PyCodeObject
type: enhancement
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue46898>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46895] Allow extensions to set a callback to be invoked when a type is modified
Change by Matt Page : -- versions: +Python 3.11 ___ Python tracker <https://bugs.python.org/issue46895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12986] Using getrandbits() in uuid.uuid4() is faster and more readable
New submission from Matt Chaput : Currently the 'uuid' module uses os.urandom (in the absence of a system UUID generation function) to generate random UUIDs in the uuid.uudi4() function. This patch changes the implementation of uuid4() to use random.getrandbits() as the source of randomness instead, for the following reasons: * In my quick tests, using getrandbits() is much faster on Windows and Linux. Some applications do need to generate UUIDs quickly. >>> setup = "import uuid, os, random" >>> ur = "uuid.UUID(bytes=os.urandom(16), version=4)" >>> grb = "uuid.UUID(int=random.getrandbits(128), version=4)" >>> # Windows >>> timeit.Timer(ur, setup).timeit() 22.861042160383903 >>> timeit.Timer(grb, setup).timeit() 3.8689128309085135 >>> # Linux >>> timeit.Timer(ur, setup).timeit() 29.32686185836792 >> timeit.Timer(grb, setup).timeit() 3.7429409027099609 * The patched code is cleaner. It avoids the try...finally required by the possibly unavailable os.urandom function, and the fallback to generating random bytes. -- components: Library (Lib) files: fastuuid4.patch keywords: patch messages: 144087 nosy: mattchaput priority: normal severity: normal status: open title: Using getrandbits() in uuid.uuid4() is faster and more readable type: performance Added file: http://bugs.python.org/file23163/fastuuid4.patch ___ Python tracker <http://bugs.python.org/issue12986> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Adding a new regex module (compatible with re)
Matt Chaput added the comment: Not sure if this is better as a separate feature request or a comment here, but... the new version of .NET includes an option to specify a time limit on evaluation of regexes (not sure if this is a feature in other regex libs). This would be useful especially when you're executing regexes configured by the user and you don't know if/when they might go exponential. Something like this maybe: # Raises an re.Timeout if not complete within 60 seconds match = myregex.match(mystring, maxseconds=60.0) -- nosy: +mattchaput ___ Python tracker <http://bugs.python.org/issue2636> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12986] Using getrandbits() in uuid.uuid4() is faster and more readable
Matt Chaput added the comment: Passed all tests OK. -- ___ Python tracker <http://bugs.python.org/issue12986> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1887] distutils doesn't support out-of-source builds
Changes by Matt Joiner : -- nosy: +anacrolix ___ Python tracker <http://bugs.python.org/issue1887> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13128] httplib debuglevel on CONNECT doesn't print response headers
New submission from Matt Spear : httplib with a debuglevel prints out the response headers, but does not do so with CONNECT requests (when set_tunnel is used). Attached is a small patch to print the reply when the CONNECT request returns something other than 200 OK. I'm not sure if it is worth printing the headers when a 200 OK is given. If it seems useful I can update the patch. Thanks!!! -- components: Library (Lib) files: httplib.py.patch keywords: patch messages: 145157 nosy: Matt.Spear priority: normal severity: normal status: open title: httplib debuglevel on CONNECT doesn't print response headers type: feature request versions: Python 2.7 Added file: http://bugs.python.org/file23342/httplib.py.patch ___ Python tracker <http://bugs.python.org/issue13128> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13321] fstat doesn't accept an object with "fileno" method
New submission from Matt Joiner : os.fstat doesn't not accept an object with the fileno() method. Probably a bunch of other similar functions will not either. In some parts of the standard library it's common practice to call PyObject_AsFileDescriptor on fd-wrapping arguments. http://hg.python.org/cpython/file/d877d7f3b679/Modules/posixmodule.c#l7319 http://hg.python.org/cpython/file/d877d7f3b679/Objects/fileobject.c#l196 -- components: Library (Lib) messages: 146823 nosy: anacrolix priority: normal severity: normal status: open title: fstat doesn't accept an object with "fileno" method type: behavior versions: Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue13321> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12684] profile does not dump stats on exception like cProfile does
Matt Joiner added the comment: Also affects 3.3. -- versions: +Python 3.3 ___ Python tracker <http://bugs.python.org/issue12684> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12684] profile does not dump stats on exception like cProfile does
Changes by Matt Joiner : -- resolution: -> works for me status: open -> languishing ___ Python tracker <http://bugs.python.org/issue12684> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12822] NewGIL should use CLOCK_MONOTONIC if possible.
Changes by Matt Joiner : -- nosy: +anacrolix ___ Python tracker <http://bugs.python.org/issue12822> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Matt Mackall added the comment: The underlying cause of Python's write exceptions with cp65001 is: The ANSI C write() function as implemented by the Windows console returns the number of _characters_ written rather than the number of _bytes_, which Python reasonably interprets as a "short write error". It then consults errno, which gives the effectively random error message seen. This can be bypassed by using os.write(sys.stdout.fileno(), utf8str), which will a) succeed and b) return a count <= len(utf8str). With os.write() and an appropriate font, the Windows console will correctly display a large number of characters. Possible workaround: clear errno before calling write, check for non-zero errno after. The vast majority of (non-Python) applications never check the return value of write, so don't encounter this problem. -- nosy: +Matt.Mackall ___ Python tracker <http://bugs.python.org/issue1602> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13549] Incorrect nested list comprehension documentation
New submission from Matt Long : The description of nesting list comprehensions in section 5.1.5 of the main Python tutorial (http://docs.python.org/tutorial/datastructures.html#nested-list-comprehensions) is misleading at best and arguably incorrect. Where it says "To avoid apprehension when nesting list comprehensions, read from right to left." This is incorrect and conflicts directly with the comment at the bottom of PEP 202 (http://www.python.org/dev/peps/pep-0202/), which says the last index varies fastest. Take the following example: matrix = [[1,2],[3,4],[5,6]] my_list = [] for row in matrix: for number in row my_list.append(number) The current documentation would suggest I do the following to achieve the same result with list comprehensions since the for statements should be read from right to left: matrix = [[1,2],[3,4],[5,6]] my_list = [number for number in row for row in matrix] Running this code will result in an error. The correct form is: matrix = [[1,2],[3,4],[5,6]] [number for row in matrix for number in row] Clearly the nesting order only matters when the inner loop depends on the outer loop as in my example above. There is no such dependency in the documentation's example, which is why it is does not result in an Error. -- assignee: docs@python components: Documentation messages: 148994 nosy: docs@python, mattlong priority: normal severity: normal status: open title: Incorrect nested list comprehension documentation type: behavior versions: Python 2.6, Python 2.7 ___ Python tracker <http://bugs.python.org/issue13549> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13694] asynchronous connect in asyncore.dispatcher does not set addr
New submission from Matt Joiner : Patch attached -- components: Library (Lib) files: dispatcher_connect_addr.patch keywords: patch messages: 150449 nosy: anacrolix priority: normal severity: normal status: open title: asynchronous connect in asyncore.dispatcher does not set addr type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file24124/dispatcher_connect_addr.patch ___ Python tracker <http://bugs.python.org/issue13694> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13694] asynchronous connect in asyncore.dispatcher does not set addr
Matt Joiner added the comment: I don't believe it is. dispatcher.addr is only set if the connection is immediately established. It's set explicitly in dispatcher.__init__ if a socket is provided that is already connected. It's *not* set after a connection completes. There are 2 solutions as I see it: 1) Set addr after a successful call to socket.connect indicates that a connection is being established. Currently this only occurs if the connection is not delayed. 2) Set the addr when a connect event completes. This would require making getpeername calls like in dispatcher.__init__ and would be significantly more expensive. My patch implements method 1. This conforms to existing addr-setting behaviour in dispatcher.bind. -- ___ Python tracker <http://bugs.python.org/issue13694> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9674] make install DESTDIR=/home/blah fails when the prefix specified is /
Matt Joiner added the comment: Just ran into this bug myself with 3.2. Apparently this patch works: http://groups.google.com/group/comp.lang.python/msg/bd8818ab9d4af8d7 -- nosy: +anacrolix ___ Python tracker <http://bugs.python.org/issue9674> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9674] make install DESTDIR=/home/blah fails when the prefix specified is /
Matt Joiner added the comment: Attached a patch that fixes it, only the line numbers have changed from Martin v. Loewis's patch. Used on 3.2. -- Added file: http://bugs.python.org/file22360/fix-root-prefix.patch ___ Python tracker <http://bugs.python.org/issue9674> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9674] make install DESTDIR=/home/blah fails when the prefix specified is /
Changes by Matt Joiner : -- components: +Build, Library (Lib) nosy: +alexis type: behavior -> compile error ___ Python tracker <http://bugs.python.org/issue9674> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12437] _ctypes.dlopen does not include errno in OSError
New submission from Matt Joiner : _ctypes.dlopen is not including the errno when it raises OSError. This occurs when attempting to load a library that doesn't exist, the error string given is clearly generated from an ENOENT. joiner@dbssyd800:~$ python3 dlopen_raise.py None somelib.so: cannot open shared object file: No such file or directory -- components: ctypes files: dlopen_raise.py messages: 139382 nosy: anacrolix priority: normal severity: normal status: open title: _ctypes.dlopen does not include errno in OSError type: behavior versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file22512/dlopen_raise.py ___ Python tracker <http://bugs.python.org/issue12437> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12447] ~True is not False
New submission from Matt Joiner : Given there is no ! operator in Python, I next tried ~ (despite that I'm after a logical not). This came as a surprise: >>> bool(~True) True >>> bool(~False) True >>> bool(~~False) False >>> ~True, ~~True, ~False, ~~False (-2, 1, -1, 0) Is there any consideration to "fixing" this? Is int(True) 1 due to C? Why is it preferred over -1? It seems more appropriate to me that True have: def __invert__(self): return False def __int__(self): return 1 # or even -1 This also "fixes" this case too: >>> -True -1 -- components: Interpreter Core messages: 139458 nosy: anacrolix priority: normal severity: normal status: open title: ~True is not False type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue12447> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12448] smtplib's __main__ doesn't flush when prompting
New submission from Matt Joiner : The smptlib module's __main__ doesn't flush stdout when prompting: sys.stdout.write(prompt + ": ") return sys.stdin.readline().strip() stdout is usually line buffered, and so running python3 smptlib.py doesn't actually prompt the user. The line `sys.stdout.flush()` needs to be added. -- components: Library (Lib) messages: 139461 nosy: anacrolix priority: normal severity: normal status: open title: smtplib's __main__ doesn't flush when prompting type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue12448> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4768] email.generator.Generator object bytes/str crash - b64encode() bug?
Changes by Matt Joiner : -- nosy: +anacrolix ___ Python tracker <http://bugs.python.org/issue4768> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10278] add time.wallclock() method
Matt Joiner added the comment: What's the status of this bug? This is a very useful feature, I've had to use and add bindings to monotonic times for numerous applications. Can it make it into 3.3? -- ___ Python tracker <http://bugs.python.org/issue10278> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3565] array documentation, method names not 3.x-compliant
Matt Giuca added the comment: There are still some inconsistencies in the documentation (in particular, incorrectly using the word "string" to refer to a bytes object, which made sense in Python 2 but not 3), which I fixed in my doc-only.patch file that's coming up to its third birthday. Most of it has been fixed with the previous change which added 'tobytes' and 'frombytes' and made tostring and fromstring aliases. But there are some places which don't make sense: array: "If given a list or string" needs to be "If given a list, bytes or string" (since a bytes is not a string). frombytes: "Appends items from the string" needs to be "Appends items from the bytes object", since this does not work if you give it a string. Less importantly, I also recommended renaming "unicode string" to just "string", since in Python 3 there is no such thing as a non-unicode string. For instance, there is an example that uses a variable named "unicodestring" that could be renamed to just "string". > Indeed, not only it would bring little benefit, but may also confuse > users porting from 2.x (since the from/tostring methods would then > have a totally different meaning). Well, by that logic, you shouldn't have renamed "unicode" to "str" since that would also confuse users porting from 2.x. It generally seems like a good idea in Python 3 to rename all mentions of "string" to "bytes" and all mentions of "unicode" to "string", so as to be consistent with the new names of the types (it is better to be internally consistent than consistent with the previous version). Though I do agree that it would be chaos to rename array.from/tounicode to from/tostring now, given that array.from/tostring already has a different meaning in Python 3. -- ___ Python tracker <http://bugs.python.org/issue3565> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5505] sys.stdin.read() doesn't return after first EOF on Windows
Matt Joiner added the comment: I get this on Linux with ^D -- nosy: +anacrolix ___ Python tracker <http://bugs.python.org/issue5505> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5505] sys.stdin.read() doesn't return after first EOF on Windows
Matt Joiner added the comment: Feel like a total noob: Where do I get the latest source? I can't find any pre-release tarballs for 3.3, and the suggested py3k checkout doesn't work: $ hg clone http://hg.python.org/cpython#py3k py3k abort: unknown revision 'py3k'! -- ___ Python tracker <http://bugs.python.org/issue5505> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5505] sys.stdin.read() doesn't return after first EOF on Windows
Matt Joiner added the comment: This version is fixed for me: $ ./python Python 3.3.0a0 (default:7520f1bf0a81, Jul 18 2011, 17:12:12) [GCC 4.1.2 20070115 (SUSE Linux)] on linux2 -- versions: +Python 3.2 ___ Python tracker <http://bugs.python.org/issue5505> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12591] configparser can't read_file the output of subprocess.Popen
New submission from Matt Joiner : >>> a = subprocess.Popen(['cat', '/path/to/text.ini'], stdout=subprocess.PIPE, >>> universal_newlines=True) >>> b = configparser.ConfigParser() >>> b.read_file(a.stdout) Traceback (most recent call last): File "", line 1, in File "/hostname/sig/local/lib/python3.2/configparser.py", line 708, in read_file self._read(f, source) File "/hostname/sig/local/lib/python3.2/configparser.py", line 994, in _read for lineno, line in enumerate(fp, start=1): AttributeError: '_io.FileIO' object has no attribute 'read1' Also this fails without universal_readlines, which is not so bad except that the name 'read_file' doesn't exactly indicate this. I found one mildly related bug: http://bugs.python.org/issue11670 -- components: IO, Interpreter Core, Library (Lib) messages: 140720 nosy: anacrolix priority: normal severity: normal status: open title: configparser can't read_file the output of subprocess.Popen versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue12591> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Matt Basta added the comment: The number of problems produced by this bug can be greatly reduced by adding a relatively small check to the parser. Currently,
[issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Matt Basta added the comment: > So I think the example is invalid (should escape the <), and that HTMLParser > is not buggy. On the other hand, the HTML5 spec clearly dictates otherwise: http://www.w3.org/TR/html5/syntax.html#cdata-rcdata-restrictions The text in raw text and RCDATA elements must not contain any occurrences of the string "), or U+002F SOLIDUS (/). Additionally, no browsers (perhaps unless they are in quirks mode) currently obey the HTML4 variant of the rule. This is due largely in part to the need to include strings such as "" within a script tag itself. This behavior can be observed firsthand by loading this snippet in a browser: <span></span>This should not be visible. -- ___ Python tracker <http://bugs.python.org/issue670664> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Matt Basta added the comment: > Yes, but we don't claim to support HTML5 yet. There's also no claim in the docs or the source that HTMLParser specifically adheres to HTML4, either. Ideally, the parser should strive for parity with the functionality of major web browsers, as they are the de-facto standard for HTML parser behavior. All of the browsers on my machine, for instance, will even parse the following snippet with the behavior described in the HTML5 spec: http://www.w3.org/TR/html4/strict.dtd";> <span></span>This should not be visible. Even in pre-HTML5 browsers, this is the way that HTML gets parsed. For the heck of it, I downloaded an old copy of Firefox 2.0 and ran the above snippet. The behavior is consistent. While I would otherwise agree that keeping to the HTML4 spec is the right thing to do, this is a quirk of the spec that is not only ignored by browsers (as can be seen in FX2) and changed in a future version of the spec, but is causing problems for a good number of developers. It could be argued that the patch is a far more elegant solution for Beautiful Soup developers than the workaround in msg88864. -- ___ Python tracker <http://bugs.python.org/issue670664> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Matt Basta added the comment: Seeing as everyone seems pretty satisfied with the 2.7 version, I'd be happy to put together a patch for 3 as well. To confirm, though, this fix is NOT going behind the strict parameter, correct? -- ___ Python tracker <http://bugs.python.org/issue670664> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12679] ThreadError is not in threading.__all__
New submission from Matt Joiner : >>> from threading import * >>> ThreadError Traceback (most recent call last): File "", line 1, in NameError: name 'ThreadError' is not defined -- components: Library (Lib) files: export-thread-error.patch keywords: patch messages: 141546 nosy: anacrolix priority: normal severity: normal status: open title: ThreadError is not in threading.__all__ versions: Python 3.2 Added file: http://bugs.python.org/file22827/export-thread-error.patch ___ Python tracker <http://bugs.python.org/issue12679> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12684] profile does not dump stats on exception like cProfile does
New submission from Matt Joiner : Here's a patch that fixes it. -- components: Library (Lib) files: exception-in-profile.patch keywords: patch messages: 141591 nosy: anacrolix priority: normal severity: normal status: open title: profile does not dump stats on exception like cProfile does type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file22829/exception-in-profile.patch ___ Python tracker <http://bugs.python.org/issue12684> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12437] _ctypes.dlopen does not include errno in OSError
Matt Joiner added the comment: Should I just submit a patch for this myself? Can someone confirm the behaviour is incorrect so I don't waste time fixing it? -- ___ Python tracker <http://bugs.python.org/issue12437> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12437] _ctypes.dlopen does not include errno in OSError
Matt Joiner added the comment: I didn't notice there was no use of errno. It's quite possible that dlopen might be used without the C library present, so perhaps this is why it wasn't included. The error strings however are very C-like, which made me think of this in the first place. Thanks all. -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue12437> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8713] multiprocessing needs option to eschew fork() under Linux
Changes by Matt M : -- nosy: +numbernine ___ Python tracker <http://bugs.python.org/issue8713> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9723] Add shlex.quote
Matt Joiner added the comment: Why can't pipes.quote can't be moved to shlex.quote verbatim as I originally proposed? Is there justification to also change it as part of the relocation? I think any changes to its behaviour should be a separate issue. -- ___ Python tracker <http://bugs.python.org/issue9723> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12813] uuid4 is not tested if a uuid4 system routine isn't present
New submission from Matt Joiner : The uuid.uuid4 function is not tested if a C system routine is not present, despite that uuid4 has several fallback clauses. This patch will test at least the first fallback. -- components: Library (Lib) files: uuid4-test-no-system-routine-fallback.patch keywords: patch messages: 142688 nosy: anacrolix priority: normal severity: normal status: open title: uuid4 is not tested if a uuid4 system routine isn't present type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file22993/uuid4-test-no-system-routine-fallback.patch ___ Python tracker <http://bugs.python.org/issue12813> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12870] Regex object should have introspection methods
New submission from Matt Chaput : Several times in the recent past I've wished for the following methods on the regular expression object. These would allow me to speed up search and parsing code, by limiting the number of regex matches I need to try. literal_prefix(): Returns any literal string at the start of the pattern (before any "special" parts). E.g., for the pattern "ab(c|d)ef" the method would return "ab". For the pattern "abc|def" the method would return "". When matching a regex against keys in a btree, this would let me limit the search to just the range of keys with the prefix. first_chars(): Returns a string/list/set/whatever of the possible first characters that could appear at the start of a matching string. E.g. for the pattern "ab(c|d)ef" the method would return "a". For the pattern "[a-d]ef" the method would return "abcd". When parsing a string with regexes, this would let me only have to test the regexes that could match at the current character. As long as you're making a new regex package, I thought I'd put in a request for these :) -- components: Regular Expressions messages: 143266 nosy: mattchaput priority: normal severity: normal status: open title: Regex object should have introspection methods type: feature request versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue12870> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12870] Regex object should have introspection methods
Matt Chaput added the comment: Ezio, no offense, but I think it's safe to say you've completely misunderstood this bug. It is not about "explaining what a regex matches" or optimizing the regex. Read the last sentences of the two paragraphs explaining the proposed methods for the use cases. This is about allowing MY CODE to programmatically get certain information about a regex object to allow it to limit the number of times it has to call regex.match(). AFAIK there's no good way to get this information about a regex object without adding these methods or building my own pure-Python regex interpreter, which would be both Herculean and pointless. -- ___ Python tracker <http://bugs.python.org/issue12870> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12870] Regex object should have introspection methods
Matt Chaput added the comment: Yes, it's an optimization of my code, not the regex, as I said. Believe me, it's not premature. I've listed two general use cases for the two methods. To me it seems obvious that having to test a large number of regexes against a string, and having to test a single regex against a large number of strings, are two very common programming tasks, and they could both be speeded up quite a bit using these methods. As of now my parsing code and other code such as PyParsing are resorting to hacks like requiring the user to manually specify the possible first chars of a regex at configuration. With the hacks, the code can be hundreds of times faster. But the hacks are error-prone and should be unnecessary. The PCRE library implements at least the "first char" functionality, and a lot more regex introspection that would be useful, through its pcre_fullinfo() function. -- ___ Python tracker <http://bugs.python.org/issue12870> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9621] Graphviz output for 2to3 fixer patterns
New submission from Matt Bond : As part of my GSoC project working on 2to3, I've created a script which will allow compiled fixer patterns to be visualized using graphviz. This would be useful for debugging and understanding exactly how patterns are matched. I've written using the 2to3 sandbox as my base. The script is named pat2dot and is found in the scripts directory. The script currently relies on an external graphviz library (I provided bindings for the GvGen library with this patch), they are separated enough from the rest of the code that it would be trivial to create a class that would work using a different graphviz library. Additionally, since the code is never called within 2to3 proper, this dependency will only appear if you wish to use pat2dot, and will not affect any other usages of lib2to3. Usage of the script is `python pat2dot.py fixername` where fixername is any fixer provided in 2to3, as named by 2to3's -l option. -- components: 2to3 (2.x to 3.0 conversion tool) files: 2to3-graph.diff keywords: patch messages: 114049 nosy: facundobatista, gmattbond, loewis priority: normal severity: normal status: open title: Graphviz output for 2to3 fixer patterns versions: Python 2.6 Added file: http://bugs.python.org/file18544/2to3-graph.diff ___ Python tracker <http://bugs.python.org/issue9621> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9664] Make gzip module not require that underlying file object support seek
Matt Kraai added the comment: I don't know the gzip format well enough, but I was hoping that it would be possible to iterate through the lines of a gzip-compressed stream without having to use any of the functions that would require seeking. -- nosy: +kraai ___ Python tracker <http://bugs.python.org/issue9664> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9621] Graphviz output for 2to3 fixer patterns
Matt Bond added the comment: Éric, When I was working with 2to3 this summer I was running it via python3, so I think the patch should work - however, if I've submitted it to the wrong place or the wrong branch, where should I be looking at to ensure my code does work on 3.2 and is submitted to the right place? In regard to the import gvgraph, I wasn't sure what to do with it - for my distribution gvgraph wasn't available as a package, and it was only one file so I just dumped it in the same directory as the script. I'm open to suggestions as to how that import should be handled better. Alexander - I'll attach a sample image as soon as I get back to my development machine, which should be later this week. -- ___ Python tracker <http://bugs.python.org/issue9621> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9621] Graphviz output for 2to3 fixer patterns
Matt Bond added the comment: As requested, attached is the output for the fix_buffer fixer, as an example of the kind of output this patch can produce. -- Added file: http://bugs.python.org/file18968/fix_buf_pytree_1.png ___ Python tracker <http://bugs.python.org/issue9621> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9621] Graphviz output for 2to3 fixer patterns
Matt Bond added the comment: Huh. I must have diffed the wrong version of my code - how embarrassing! I'll update the attached patch later this week. Thanks for catching that. -- ___ Python tracker <http://bugs.python.org/issue9621> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3482] re.split, re.sub and re.subn should support flags
Matt Keeler added the comment: Python 2.7 docs say this was added in 2.7.3.1 Python 3.1 docs say this was added in 3.1 The problem with calling 're.split(pattern, string, re.I)' is that you are using positional arguments only. If you were to do 're.split(pattern, string, flags=re.I)', that should produce the desired result. -- nosy: +mjkeeler7 ___ Python tracker <http://bugs.python.org/issue3482> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11306] mailbox should test for errno.EROFS
New submission from Matt Johnston : When opening mailboxes the module checks for errno.EACCES. This doesn't help if the location is mounted read-only. Something like the following (against Python 2.6) would fix it, there are a few other checks in mailbox.py for EACCES too. --- mailbox.py.orig 2011-02-24 15:02:22.0 +0800 +++ mailbox.py 2011-02-24 15:02:05.0 +0800 @@ -512,7 +512,7 @@ class _singlefileMailbox(Mailbox): f = open(self._path, 'wb+') else: raise NoSuchMailboxError(self._path) -elif e.errno == errno.EACCES: +elif e.errno == errno.EACCES or e.errno == errno.EROFS: f = open(self._path, 'rb') else: raise -- components: Library (Lib) messages: 129252 nosy: matt priority: normal severity: normal status: open title: mailbox should test for errno.EROFS type: behavior versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue11306> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5421] Irritating error message by socket's sendto method
Changes by Matt Joiner : -- nosy: +anacrolix ___ Python tracker <http://bugs.python.org/issue5421> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5421] Irritating error message by socket's sendto method
Matt Joiner added the comment: This bug is very misleading in Py3, as the TypeError makes one think that a string is being passed rather than bytes (how else do you get a 2 argument function call wrong?). Very difficult to determine that this is not in fact the bug in a dynamically typed language :P -- ___ Python tracker <http://bugs.python.org/issue5421> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3136] [PATCH] logging.config.fileConfig() compulsivly disable all existing loggers
Changes by Matt Joiner : -- nosy: +anacrolix ___ Python tracker <http://bugs.python.org/issue3136> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3831] Multiprocessing: Expose underlying pipe in queues
Changes by Matt Joiner : -- nosy: +anacrolix ___ Python tracker <http://bugs.python.org/issue3831> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3831] Multiprocessing: Expose underlying pipe in queues
Matt Joiner added the comment:
I look forward to this, or something similar. Inspiration can be taken from
Golangs's select behaviour on channels.
select {
case i1 = <-c1:
print("received ", i1, " from c1\n")
case c2 <- i2:
print("sent ", i2, " to c2\n")
default:
print("no communication\n")
}
--
___
Python tracker
<http://bugs.python.org/issue3831>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8426] multiprocessing.Queue fails to get() very large objects
Matt Goodman added the comment: You can not pickle individual objects larger than 2**31. This failure is not handled cleanly in the core module, and I suspect masked by above processes. Try piping "a"*(2**31) through you pipe, or pickling it to disk . . . -- nosy: +Matt.Goodman ___ Python tracker <http://bugs.python.org/issue8426> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9621] Graphviz output for 2to3 fixer patterns
Matt Bond added the comment: Sorry for the delay in responding, and for getting this patch cleaned up and submitted. While I was going through my code to submit it, I found a couple of additional issues with it. Then I ended up becoming very busy with my grad courses. As a result, I haven't had a chance to do anything with it. Currently, my plan is to rework it over the winter break to fix the issues, make it work correctly with python 3, and remove the dependence on the external graphviz package (which should resolve the import issue as well). -- ___ Python tracker <http://bugs.python.org/issue9621> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4761] create Python wrappers for openat() and others
Changes by Matt Joiner : -- nosy: +anacrolix ___ Python tracker <http://bugs.python.org/issue4761> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9742] Python 2.7: math module fails to build on Solaris 9
Changes by Matt Selsky : -- nosy: +Matt.Selsky ___ Python tracker <http://bugs.python.org/issue9742> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8821] Range check on unicode repr
Matt Giuca added the comment: > I think that we have good reasons to not remove the NUL character. Please note: Nobody is suggesting that we remove the NUL character. I was merely suggesting that we don't rely on it where it is unnecessary. Returning to my original patch: If the code was using the NUL character as a terminator, then it wouldn't be a bug. What the repr code does is it uses the length, and does not explicitly search for a NUL character. However, there is a *bug* where it reads one too many characters in certain cases. As I said in the first place, it just happens to *not* be catastrophic due to the presence of the NUL character. But that does not mean this isn't a bug -- at the very least, the code is very confusing to read because it does not do what it is trying to do. Anyway the important issue is what Marc-Andre raised about buffers. Since we are in agreement that there is a potential problem here, and I have a patch which seems correct and doesn't break any test cases (note my above post responding to test case breakages), can it be applied? -- ___ Python tracker <http://bugs.python.org/issue8821> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1172711] long long support for array module
Matt Chaput added the comment: This is an important feature to me. Now I get to redo a bunch of code to have two completely different code paths to do the same thing because nobody could be bothered to keep array up-to-date. -- nosy: +mattchaput ___ Python tracker <http://bugs.python.org/issue1172711> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10278] add time.wallclock() method
Matt Joiner added the comment: This is sorely needed. IMO the current behaviour of time.clock works for Windows, and clock_gettime(CLOCK_MONOTONIC) on POSIX or clock_gettime(CLOCK_MONOTONIC_RAW) on Linux>=2.6.28. There are some related discussions on StackOverflow that may contain useful ideas also: http://stackoverflow.com/questions/1205722/how-do-i-get-monotonic-time-durations-in-python http://stackoverflow.com/questions/4687408/retrieve-wall-time-in-python-using-the-standard-library -- nosy: +anacrolix ___ Python tracker <http://bugs.python.org/issue10278> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2987] RFC2732 support for urlparse (IPv6 addresses)
Changes by Matt Joiner : -- nosy: +anacrolix ___ Python tracker <http://bugs.python.org/issue2987> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9723] pipes.quote() needs to be documented
Matt Joiner added the comment: I agree, I discovered this function (pipes.quote) only through recommendation here: http://stackoverflow.com/questions/4748344/whats-the-reverse-of-shlex-split I suggest that it be added to shlex, perhaps as shlex.quote. While the quoting style it performs, and the module it's found in are specific to Unix tools, the shlex module is available on non-Unix platforms. To this end, adding the function to shlex would make it available elsewhere, as well as be appropriately shell-related. -- nosy: +anacrolix ___ Python tracker <http://bugs.python.org/issue9723> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9723] pipes.quote() needs to be documented
Matt Joiner added the comment: Two reasons: The pipes module is Unix only, but pipes.quote is useful on all platforms. Secondly pipes.quote pertains to shell command-lines, this is also the domain of shlex which already cross platform. In pipes, an import shlex.quote would more than sufficient. If this belongs in another separate bug I shall submit one. Please advise. -- ___ Python tracker <http://bugs.python.org/issue9723> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10882] Add os.sendfile()
Matt Joiner added the comment: I notice Linux is described as not taking count=0 to mean to send until the end of "in" is reached. Is it possible to pass (size_t)-1 to this field if None is given, or do a loop on non-zero counts from sendfile to emulate this? I poked around the linux source for 2.6.32, and it appears sendfile() is emulated on top of splice(), but this doesn't provide undocumented count=0 handling as I was hoping. -- nosy: +anacrolix ___ Python tracker <http://bugs.python.org/issue10882> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10882] Add os.sendfile()
Matt Joiner added the comment: I have a few problems with these parts of the latest patch: + The second case may be used on Mac OS X and FreeBSD where *headers* + and *trailers* are arbitrary sequences of buffers that are written before and + after the data from *in* is written. It returns the same as the first case. Why special case these? Why can't Mac OS X and FreeBSD write those manually into the output file descriptor. It's presumptious but I don't see why something so easy to do explicitly is mashed into the interface here, just pretend it doesn't exist. For the sake of simplicity (and sendfile might become very popular in future code), just drop this "feature". for h in headers: out.write(h) os.sendfile(out, in, offset, count) for t in trailers: out.write(t) + On Mac OS X and FreeBSD, a value of 0 for *count* specifies to send until + the end of *in* is reached. Again this should be emulated where it's not available, as it's very common, and a logical feature to have. However as indicated earlier, if os.sendfile is a minimal syscall wrapper, some thought needs to be given to a "higher-level" function, that also includes my other suggestions. + On Solaris, *out* may be the file descriptor of a regular file or the file + descriptor of a socket. On all other platforms, *out* must be the file + descriptor of an open socket I'm pretty sure that Solaris isn't the only platform that supports non-socket file descriptors here, Linux (the platform I'm using), is one such case. As a general rule, we want to allow any file descriptors, and not restrict to sockets (except for awful platforms like Windows). -- ___ Python tracker <http://bugs.python.org/issue10882> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10882] Add os.sendfile()
Matt Joiner added the comment: Thanks for catching that: Presently (Linux 2.6.9): in_fd, must correspond to a file which sup‐ ports mmap(2)-like operations (i.e., it cannot be a socket); and out_fd must refer to a socket. Despite the fact the manpage hasn't changed since 2004, sendfile still only works for sockets. :( -- ___ Python tracker <http://bugs.python.org/issue10882> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5803] email/quoprimime: encode and decode are very slow on large messages
Matt Cain added the comment: I re-wrote encode() to be simpler and faster. My version runs about 10 times faster on a 30KB message. I have tested it somewhat but not rigorously see attached patch -- keywords: +patch nosy: +cainmatt Added file: http://bugs.python.org/file20635/quoprimime.py.diff ___ Python tracker <http://bugs.python.org/issue5803> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11240] Running unit tests in a command line tool leads to infinite loop with multiprocessing on Windows
New submission from Matt Chaput : If you start unit tests with a command line such as "python setup.py test" or "nosetests", if the tested code starts a multiprocessing.Process on Windows, each new process will act as if it was started as "python setup.py test"/"nosetests", leading to an infinite explosion of processes that eventually locks up the entire machine. -- components: Windows messages: 128768 nosy: mattchaput priority: normal severity: normal status: open title: Running unit tests in a command line tool leads to infinite loop with multiprocessing on Windows type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue11240> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11240] Running unit tests in a command line tool leads to infinite loop with multiprocessing on Windows
Matt Chaput added the comment: Thank you, I understand all that, but I don't think you understand the issue. My code is not __main__. I am not starting the test suite. It's the distutils/nose code that's doing that. It seems as if the multiprocessing module is starting new Windows processes by duplicating the command line of the original process. That doesn't seem to work very well, given the example of running test suites, hence the bug. -- ___ Python tracker <http://bugs.python.org/issue11240> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
