[issue46473] importlib.metadata does not honor .egg-link files
New submission from Ben : When installing a package using --editable, pip creates a .egg-link file in your site-packages dir that points to the .egg-info metadata that by default exists along side the source that it was installed from. This worked just fine with the older pkg_resources package. However, the newer importlib.metadata does not seem to be aware of .egg-link files at all. The only solution is to include the source dir that contains the .egg-info metadata into your PYTHONPATH, which sort of defeats the purpose of having the .egg-link pointer in the first place. -- components: Distutils, Library (Lib) messages: 411262 nosy: dstufft, eric.araujo, onlinespending priority: normal severity: normal status: open title: importlib.metadata does not honor .egg-link files type: behavior versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46473> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46473] importlib.metadata does not honor .egg-link files
Ben added the comment: I should also add that the easy-install.pth file, which similarly contains a link to the source dir containing the .egg-info metadata, is also not processed to locate the necessary metadata. -- ___ Python tracker <https://bugs.python.org/issue46473> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46473] importlib.metadata does not honor .egg-link files
Ben added the comment: yes, the latest version of pip creates an .egg-info metadata dir at the level of the package src dir and .egg-link and easy-install.pth stubs in the site-packages dir (the contents of which are paths to the package src dir). The intent is that these links would be followed to find the necessary metadata for the package. However, importlib.metadata does not follow either one of these links. These links are what makes editable installs possible, so I'm not sure how they can be ignored all together, unless there's some different facility that provides this functionality. -- ___ Python tracker <https://bugs.python.org/issue46473> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46473] importlib.metadata does not honor .egg-link files
Ben added the comment: https://github.com/python/importlib_metadata/issues/364 -- resolution: -> works for me stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46473> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45274] Race condition in Thread._wait_for_tstate_lock()
Change by Ben : -- nosy: +bjs nosy_count: 6.0 -> 7.0 pull_requests: +29450 pull_request: https://github.com/python/cpython/pull/31290 ___ Python tracker <https://bugs.python.org/issue45274> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46726] Thread spuriously marked dead after interrupting a join call
Ben added the comment: This is a duplicate of https://bugs.python.org/issue45274 but the patch there did not fix it I've just added a PR there (or should it go here?) that (i think) fixes this. The issue is that the lock.locked() call just checks that *someone* has the lock, not that the previous acquire() is what got the lock. If it's just that the tstate lock is held because the thread is still running, then it's premature to release() the lock. -- nosy: +bjs ___ Python tracker <https://bugs.python.org/issue46726> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46726] Thread spuriously marked dead after interrupting a join call
Change by Ben : -- nosy: +vstinner ___ Python tracker <https://bugs.python.org/issue46726> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46726] Thread spuriously marked dead after interrupting a join call
Ben added the comment: You are right, What one really needs here is a way to know *who* owns the lock, but threading.Lock does not provide that. The race on := is much smaller than the original race and I suspect in practice will be very hard to hit. As the original bpo notes, it may not be possible to write a complete fix for this in pure Python, after all there may always be another interrupt between the `except` and the second attempted `release`. The issue with the solution was that it turned a relatively hard-to-hit race condition into a really easy-to-hit one, but perhaps the outcome is slightly less worse? -- ___ Python tracker <https://bugs.python.org/issue46726> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46726] Thread spuriously marked dead after interrupting a join call
Change by Ben : -- nosy: +serhiy.storchaka ___ Python tracker <https://bugs.python.org/issue46726> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12967] AttributeError distutils\log.py
New submission from ben : AttributeErrors on log.py in the distutils directory import sys stream = sys.stdout if stream.errors == 'strict': pass'=> this will raise an AttributeError' -- assignee: tarek components: Distutils files: log.py messages: 143949 nosy: Ben.thelen, eric.araujo, tarek priority: normal severity: normal status: open title: AttributeError distutils\log.py type: compile error versions: Python 3.2 Added file: http://bugs.python.org/file23136/log.py ___ Python tracker <http://bugs.python.org/issue12967> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12967] AttributeError distutils\log.py
ben added the comment: Error had been raised when installing the distribute package, but it could be raised on any other usage as sys.stdout does not have an 'error' attribute. From: Éric Araujo To: thelen_...@yahoo.com Sent: Tuesday, 13 September 2011 8:54 PM Subject: [issue12967] AttributeError distutils\log.py Éric Araujo added the comment: When will it raise an AttributeError? -- ___ Python tracker <http://bugs.python.org/issue12967> ___ -- Added file: http://bugs.python.org/file23147/unnamed ___ Python tracker <http://bugs.python.org/issue12967> ___Error had been raised when installing the distribute package, but it could be raised on any other usage as sys.stdout does not have an 'error' attribute. From: Ãric Araujo <rep...@bugs.python.org>To: thelen_...@yahoo.comSent: Tuesday, 13 September 2011 8:54 PMSubject: [issue12967] AttributeError distutils\log.pyÃric Araujo <mailto:mer...@netwok.org"; ymailto="mailto:mer...@netwok.org";>mer...@netwok.org> added the comment:When will it raise an AttributeError?--___Python tracker <mailto:rep...@bugs.python.org"; ymailto="mailto:rep...@bugs.python.org";>rep...@bugs.python.org><http://bugs.python.org/issue12967"; target=_blank>http://bugs.python.org/issue12967>__ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12967] AttributeError distutils\log.py
ben added the comment: Hi Eric, I'm not suggesting that python does not test the applications. just reporting what I experience. The python version installed is r32:88445 What I did, I opened the setup file (in IDLE) from the distribute 0.6.21 and run this. On my python 3.2 version (clean without extentions). when I type in (on the command line) >>>import sys >>>sys.stdout.error 'strict' However on the IDLE when I do the same. a AttributeError is being raised. Not sure why the difference between the two (I thought these were the same). Ben From: Éric Araujo To: thelen_...@yahoo.com Sent: Thursday, 15 September 2011 10:54 PM Subject: [issue12967] AttributeError distutils\log.py Éric Araujo added the comment: How? Please tell exactly what command you ran with what Python version. It does, in 3.x. Do you think Python has no tests or no users? :) -- assignee: tarek -> eric.araujo ___ Python tracker <http://bugs.python.org/issue12967> ___ -- Added file: http://bugs.python.org/file23170/unnamed ___ Python tracker <http://bugs.python.org/issue12967> ___Hi Eric, I'm not suggesting that python does not test the applications. just reporting what I experience. The python version installed is r32:88445 What I did, I opened the setup file (in IDLE) from the distribute 0.6.21 and run this. On my python 3.2 version (clean without extentions). when I type in (on the command line) >>>import sys >>>sys.stdout.error 'strict' However on the IDLE when I do the same. a AttributeError is being raised. Not sure why the difference between the two (I thought these were the same). Ben From: Ãric Araujo <rep...@bugs.python.org>To: thelen_...@yahoo.comSent: Thursday, 15 September 2011 10:54 PMSubject: [issue12967] AttributeError distutils\log.pyÃric Araujo <mailto:mer...@netwok.org"; ymailto="mailto:mer...@netwok.org";>mer...@netwok.org> added the comment:> when installing the distribute packageHow? Please tell exactly what command you ran with what Python version.> it could be raised on any other usage as sys.stdout does not have> an 'error' attribute.It does, in 3.x. Do you think Python has no tests or no users? :)--assignee: tarek -> eric.araujo___Python tracker <mailto:rep...@bugs.python.org"; ymailto="mailto:rep...@bugs.python.org";>rep...@bugs.python.org><http://bugs.python.org/issue12967"; target=_blank>http://bugs.python.org/issue12967>__ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12967] AttributeError distutils\log.py
ben added the comment: Hi Ned, Not sure if I fully understand the IDLE issue, I'm still learning Python (abt. 6 months). Nevertheless I've installed the distributes through the command line. if you want to reassign this issue to IDLE, please do so. Best regards, Ben Thelen From: Ned Deily To: thelen_...@yahoo.com Sent: Saturday, 17 September 2011 4:43 AM Subject: [issue12967] AttributeError distutils\log.py Ned Deily added the comment: That won't work in IDLE because IDLE replaces the standard sys.stdout file object with a special proxy object to capture stdout across its processes and the proxy object does not currently support all of the attributes of a io.TextTIOWrapper object, like errors. If that is the only problem, perhaps this issue should be reassigned to IDLE to support errors and any other relevant new attributes. -- nosy: +ned.deily ___ Python tracker <http://bugs.python.org/issue12967> ___ -- Added file: http://bugs.python.org/file23181/unnamed ___ Python tracker <http://bugs.python.org/issue12967> ___Hi Ned, Not sure if I fully understand the IDLE issue, I'm still learning Python (abt. 6 months). Nevertheless I've installed the distributes through the command line. if you want to reassign this issue to IDLE, please do so. Best regards, Ben Thelen From: Ned Deily <rep...@bugs.python.org>To: thelen_...@yahoo.comSent: Saturday, 17 September 2011 4:43 AMSubject: [issue12967] AttributeError distutils\log.pyNed Deily <mailto:n...@acm.org"; ymailto="mailto:n...@acm.org";>n...@acm.org> added the comment:That won't work in IDLE because IDLE replaces the standard sys.stdout file object with a special proxy object to capture stdout across its processes and the proxy object does not currently support all of the attributes of a io.TextTIOWrapper object, like errors.>>> sys.stdout<idlelib.rpc.RPCProxy object at 0x1282b30>If that is the only problem, perhaps this issue should be reassigned to IDLE to support errors and any other relevant new attributes.--nosy: +ned.deily___Python tracker <mailto:rep...@bugs.python.org"; ymailto="mailto:rep...@bugs.python.org";>rep...@bugs.python.org><http://bugs.python.org/issue12967"; target=_blank>http://bugs.python.org/issue12967>__ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13220] print function unable while multiprocessing.Process is being run
New submission from ben :
print function unable while multiprocessing.Process is being run
Not sure if this really is a bug, but the multiprocessing.Process (or Pool)
does not allow to print during multiprocessing tasks.
I've copied the example from The Python V3.2.2 documentation, library
reference, multiprocessing (3rd example).
My systems details are: MS windows xp or Windows 7, IDLE, Python 3.2.2 [MSC
v.1500 32 bit (Intel)] on win32
from multiprocessing import Process
import os
def info(title):
print(title)
print('module name:', __name__)
print('parent process:', os.getppid())
print('process id:', os.getpid())
def f(name):
info('function f')
print('hello', name)
if __name__ == '__main__':
info('main line')
p = Process(target=f, args=('bob',))
p.start()
p.join()
#return
#main line
#module name: __main__
#parent process: 1588
#process id: 3700
#but function f doesn't get printed.
--
components: Library (Lib)
files: mp.py
messages: 145913
nosy: Ben.thelen
priority: normal
severity: normal
status: open
title: print function unable while multiprocessing.Process is being run
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file23463/mp.py
___
Python tracker
<http://bugs.python.org/issue13220>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13220] print function unable while multiprocessing.Process is being run
ben added the comment: Thanks Terry, That does solve the problem, so the bug is really with IDLE (I got a previous Issue (12967) reported which also was connected to the stdout). I changed the component to IDLE as the lib. is working as it should do. -- components: +IDLE -Library (Lib) ___ Python tracker <http://bugs.python.org/issue13220> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1982] Feature: extend strftime to accept milliseconds
Ben added the comment: Sorry to chime in on an old issue. Whilst it is good to have the ability to format the string up to microsecond precision, it would be better to be able to control the precision used. For instance, the ISO8601 specification states that there is no strictly defined precision to be used, and that any such precision should be agreed between parties exchanging ISO8601 datetimes. Would it be possible to state the precision when formatting ISO8601 datetimes - e.g. %3f to only print up to millisecond precision? presumable %f would keep the original functionality of printing right up to the microseconds. -- nosy: +magicbadger ___ Python tracker <http://bugs.python.org/issue1982> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44962] asyncio.create_task weakrefset race condition
Ben added the comment: I can reproduce on 3.9.6 A little digging and it seems asyncio imports Task from _asyncio and _asyncio's implementation (in asynciomodule.c) of Task has an __init__ which adds the task to the `all_tasks` weakref.WeakSet which appears to be implemented in Python (in Lib/_weakrefset.py) weakref.WeakSet is not thread-safe, which means concurrent create_task's in different threads (even on separate event loops) is not safe. -- nosy: +bjs ___ Python tracker <https://bugs.python.org/issue44962> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45278] RuntimeError on race on weakset concurrent iteration
New submission from Ben : This is a very subtle race WeakSet uses _weakrefset.py's _IterationGuard structure to protect against the case where the elements the WeakSet refers to get cleaned up while a thread is iterating over the WeakSet. It defers the actual removal of any elements which get gc'd during iteration until the end of the iteration. the WeakSet keeps track of all the iterators, and waits until there are no more threads iterating over the set before it does the removal: https://github.com/python/cpython/blob/main/Lib/_weakrefset.py#L30 However there is a race, if another thread begins iterating after the `if s:` check but before the _commit_removals call has ended, that iteration can get a RuntimeError. attached is an example script that can generate such RuntimeError's, although the race window here is very small and so to observe yourself you may have to tweak the magic constants around. As far as I'm aware nobody has reported seeing this bug happen in production, but some libraries (e.g. asyncio) do currently rely on concurrently iterating a weakset, so it's not implausible. -- files: weakset_concurrent_iter_runtimeerror.py messages: 402553 nosy: bjs priority: normal severity: normal status: open title: RuntimeError on race on weakset concurrent iteration type: behavior Added file: https://bugs.python.org/file50302/weakset_concurrent_iter_runtimeerror.py ___ Python tracker <https://bugs.python.org/issue45278> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45390] asyncio.Task doesn't propagate CancelledError() exception correctly.
Ben added the comment: This seems to be present in both the Python implementation as well as the accelerated C _asyncio module. It looks like that when a Task awaits a cancelled future, the task itself is cancelled but the cancellation message is not propagated to the task. https://github.com/python/cpython/blob/main/Lib/asyncio/tasks.py#L242 -- nosy: +bjs ___ Python tracker <https://bugs.python.org/issue45390> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45435] delete misleading faq entry about atomic operations
Ben added the comment:
The problem with the FAQs is that it's over-simplifying things to the point
where it can sometimes mislead.
Notably, it says the GIL protects these operations; but as Antoine points out,
many operations on datatypes drop back into Python (including potential decrefs)
Concerns about non-atomic evaluation of the composition of operations in these
statements is mostly due to the way the FAQ is presented, it should be made
clearer *which* operations it's describing to be atomic.
(Otherwise you get questions like "is x = L[x] atomic?")
graingert said the following might be useful, so:
Going through each of the points of the FAQ...
The following seem relatively straight-forward and non-controversial(?):
x = L[i]
x = L.pop()
x = y
L.append(x)
L1.extend(L2)
I'm not even sure what it *means* when it says the following:
D.keys()
The following probably have some caveats:
D[x] = y
These appear to be the suspect ones:
D1.update(D2)
L.sort()
L[i:j] = L2
x.field = y
Exploring each in more detail...
dict.keys is just a mystery to me, maybe this mattered in Python 2 but these
are view objects now, or maybe I am missing something?
dict.__setitem__ needs clarification really, surely the actual setting of the
item is "atomic" in that other threads will either see the dict with or without
the item and not halfway through some resizing operation or something, but in
doing the setting it may trigger many __eq__ calls on the other keys
(either during the resize itself, or just during probing).
The dict.update case seems like it should hold if both dicts have keys made of
only other builtin types so that the GIL can continue to protect. If the keys
of either are custom objects with their own __eq__ then the "atomicity" of the
operation is in question
as the __eq__ can happen "during" the update.
Imagine two update()s to the same dict, if the keys have custom __eq__'s then
the (concurrent) composition of the two may give some mix of the two
dictionaries overlapping keys.
(Note that the __hash__ doesn't matter as it is not recomputed on an update)
For list.sort it's more subtle,
there is built-in protection to make it somewhat atomic
which means that append()s and extend()s shouldn't be lost
but concurrent threads might suddenly see the list be emptied and concurrent
len()/L.pop() see sequentially inconsistent results.
For list.__setitem__ it's clear it's non-atomic in the case that the elements
of the list are custom objects with their own __del__, and the FAQ does infact
mention this case (at the bottom).
Attribute assignment is odd, I can't see how that can be described as "atomic"
for arbitrary objects. There is no way the FAQ really means that x and y are
instances of `object`.
There are questions about operations that are potentially missing(?) from the
list:
len(L)
D1.copy()
L1 += L2 (or does "extend" cover this too?)
... etc, and other datatypes (tuples are an obvious question here)
It's not clear why the FAQ picked these exact operations out specifically.
Fundamentally this FAQ tries to be both a language definition ("You can rely on
these operations being atomic") but also somewhat of an
implementation-dependent description ("this is what is true in CPython").
Perhaps the best long-term solution would be to remove this "FAQ" and either
move more detailed discussion about atomicity guarantees for various operations
to the actual docs for the built-in data structures or to relax the guarantees
the language gives -- asking people to use mutexes/async libraries more and
only guaranteeing enough to make those cases work.
--
nosy: +bjs
___
Python tracker
<https://bugs.python.org/issue45435>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45951] Debugger cannot be resolved
New submission from Ben : First, I am not a programmer by any stretch of the imagination, and I am just trying to get this error solved. I attempted to highlight and comment out a section of code, maybe 20 lines, and the program froze, greyed out, and gave me a spinning wheel mouse. I closed & reopened program, attempted with one line of code and it worked, attempted again with 5 lines and same issue occurred. I have attached a screenshot of the error message and didn't seen how the associated error related. https://bugs.python.org/issue1180193 The screen was greyed out yes, but I didn't change anything or close the program. I left the night before and when I attempted it this morning it started behaving in this manner. -- files: Python error.png messages: 407473 nosy: boett1 priority: normal severity: normal status: open title: Debugger cannot be resolved versions: Python 3.7 Added file: https://bugs.python.org/file50468/Python error.png ___ Python tracker <https://bugs.python.org/issue45951> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45951] Debugger cannot be resolved
Change by Ben : -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue45951> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40815] Multiprocessing docs don't describe thread-safety
New submission from Ben : The Multiprocessing docs specifically say that Queue is process- and thread- safe: https://docs.python.org/3/library/multiprocessing.html#exchanging-objects-between-processes. But this information is not given for the various synchronisation primitives and such (Lock, Semaphore, Event, etc) Are they thread-safe? Should the docs say whether they are or are not? -- assignee: docs@python components: Documentation messages: 370310 nosy: bjs, docs@python priority: normal severity: normal status: open title: Multiprocessing docs don't describe thread-safety ___ Python tracker <https://bugs.python.org/issue40815> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41423] `multiprocessing.Array` and `multiprocessing.managers.SyncManager.Array` APIs are similar but not the same
Change by Ben : -- nosy: +bjs ___ Python tracker <https://bugs.python.org/issue41423> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41676] asyncio.Event.wait broken link from asyncio.Event
Change by Ben : -- nosy: +bjs, vstinner ___ Python tracker <https://bugs.python.org/issue41676> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41676] asyncio.Event.wait broken link from asyncio.Event
Ben added the comment: looking at the source https://raw.githubusercontent.com/python/cpython/3.8/Doc/library/asyncio-sync.rst it says :meth:`wait` just like the surrounding methods and surrounding types, which all work. Maybe :meth:`Event.wait` would fix? But why :meth:`wait` didn't work is not obvious to me? -- ___ Python tracker <https://bugs.python.org/issue41676> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41893] remove() method is not working as expected(Hard to explain)
Ben added the comment: See the note in https://docs.python.org/3.7/reference/compound_stmts.html#the-for-statement "There is a subtlety when the sequence is being modified by the loop ..." Since your code is mutating the all_fields list as you iterate it, you get the " next item will be skipped " behaviour, which is why the loop is skipping over "password". remove() was never called to remove "password". There is an open issue https://bugs.python.org/issue32767 to clarify the docs about this, but it is not a bug in Python. -- nosy: +bjs ___ Python tracker <https://bugs.python.org/issue41893> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37652] Multiprocessing shared_memory ValueError on race with ShareableList
New submission from Ben : When running the attached on 3.8 and 3.9 (master) I get the following: Process Process-3: Traceback (most recent call last): File "/home/bjs/.pyenv/versions/3.9-dev/lib/python3.9/multiprocessing/process.py", line 313, in _bootstrap self.run() File "/home/bjs/.pyenv/versions/3.9-dev/lib/python3.9/multiprocessing/process.py", line 108, in run self._target(*self._args, **self._kwargs) File "/home/bjs/Downloads/e4671450a50df5a0648c6dda0c7b642a-3db67c29d8d9e6a6d629c2c016f5853ec22000ed/test.py", line 14, in g X[0] File "/home/bjs/.pyenv/versions/3.9-dev/lib/python3.9/multiprocessing/shared_memory.py", line 413, in __getitem__ (v,) = struct.unpack_from( ValueError: not enough values to unpack (expected 1, got 0) (Tested on Windows and Linux) Either this is a documentation error, and the docs for shared_memory should state that the ShareableList does not have atomic operations and so this is unsafe, or this is a suspicious behaviour. I'm not sure which. I could also just be using the library totally incorrectly. -- files: test.py messages: 348299 nosy: bjs priority: normal severity: normal status: open title: Multiprocessing shared_memory ValueError on race with ShareableList type: behavior versions: Python 3.8, Python 3.9 Added file: https://bugs.python.org/file48496/test.py ___ Python tracker <https://bugs.python.org/issue37652> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37652] Multiprocessing shared_memory ValueError on race with ShareableList
Ben added the comment: It would be nice to get davin to clarify the API for this module. What are the use cases for SharedMemory and ShareableList? Are you supposed to ever use a raw SharedMemory buffer directly? What atomicity guarantees are there for ShareableList operations and read/write to the SharedMemory buffer? -- ___ Python tracker <https://bugs.python.org/issue37652> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25144] 3.5 Win install fails with "TARGETDIR"
Ben added the comment: Still a problem with python-2.7.10.amd64.msi. A bit surprising that this has not been addressed since 2015.05.23... -- nosy: +cbj4074 ___ Python tracker <http://bugs.python.org/issue25144> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46070] broken subinterpreters
Ben Steffensmeier added the comment: We have been seeing intermittent crashes on jep that we tracked down to the same change (d0d29655ff). I have created a sample program using _testcapi that crashes about 50% of the time when run on Windows with Python 3.9.9. We have not been able to reproduce problems on any other OS. See also: https://github.com/ninia/jep/issues/366 -- nosy: +bsteffensmeier Added file: https://bugs.python.org/file50494/win_py399_crash_reproducer.py ___ Python tracker <https://bugs.python.org/issue46070> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46307] string.Template should allow inspection of identifiers
New submission from Ben Kehoe :
Currently, the only thing that can be done with a string.Template instance and
a mapping is either attempt to substitute with substitute() and catch a
KeyError if some identifier has not been provided in the mapping, or substitute
with safe_substitute() and not know whether all identifiers were provided.
I propose adding a method that returns the identifiers in the template. Because
the template string and pattern are exposed, this is already possible as a
separate function:
def get_identifiers(template):
return list(
set(
filter(
lambda v: v is not None,
(mo.group('named') or mo.group('braced')
for mo in template.pattern.finditer(template.template))
)
)
)
However, this function is not easy for a user of string.Template to construct
without learning how the template pattern works (which is documented but
intended to be learned only when subclassing or modifying id patterns).
As a method on string.Template, this would enable use cases like more
comprehensive error handling (e.g., finding all missing mapping keys at once)
or interactive prompting.
--
components: Library (Lib)
messages: 410112
nosy: ben11kehoe
priority: normal
severity: normal
status: open
title: string.Template should allow inspection of identifiers
type: enhancement
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue46307>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46307] string.Template should allow inspection of identifiers
Ben Kehoe added the comment: Happy to make a PR! In my mind I had been thinking it would be the get_identifiers() method with the implementation above, returning a list. As for __iter__, I'm less clear on what that would look like: t = string.Template(...) for identifier in t: # what would I do here? # would it include repeats if they appear more than once in the template? I guess there are two ways to think about it: one is "what identifiers are in this template?" which I think should return a list with no repeats, which I can then iterate over or check if a value is in it. The other is, "what are the contents of the template?" in the style of string.Formatter.parse(). Given that string.Template is supposed to be the "simple, no-frills" thing in comparison to string.Formatter, I see less use for the latter option. -- ___ Python tracker <https://bugs.python.org/issue46307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46307] string.Template should allow inspection of identifiers
Change by Ben Kehoe : -- keywords: +patch pull_requests: +28698 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30493 ___ Python tracker <https://bugs.python.org/issue46307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46307] string.Template should allow inspection of identifiers
Ben Kehoe added the comment: I opened a PR. By default, it raises an exception if there's an invalid identifier; there's a keyword argument raise_on_invalid to control that. The implementation I have adds them to a set first, which means the order is not guaranteed. I'm of two minds about this: if there's a big template, you want to gather the identifiers in a set so uniqueness is checked immediately and O(1) and without duplication. On the other hand, if templates are never very big, you could build a list (in order) and check it, O(N) style, or build a duplicate list and set in parallel. Or build a big list and check it at the end. I kind of think ordering doesn't matter? What would someone do with that information? -- ___ Python tracker <https://bugs.python.org/issue46307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46307] string.Template should allow inspection of identifiers
Ben Kehoe added the comment: Having slept on it, I realized that if I was presenting interactive prompts for a template, I would expect the prompts to be in order that the identifiers appear in the template. Accordingly, I've updated the PR to maintain ordering. -- ___ Python tracker <https://bugs.python.org/issue46307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46307] string.Template should allow inspection of identifiers
Ben Kehoe added the comment: The point is to be able to programmatically determine what is needed for a successful substitute() call. A basic use case for this is better error messages; calling substitute() with an incomplete mapping will tell you only the first missing identifier it encounters; if you know all the identifiers you can raise an error about all the missing identifiers. Another error handling use case is checking whether the template is valid, without needing to provide a complete mapping. A use case unrelated to error handling that I’ve encountered a few times is interactive prompting for template values, which you can only do if you can get a list of the identifiers in the template. -- ___ Python tracker <https://bugs.python.org/issue46307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46307] string.Template should allow inspection of identifiers
Ben Kehoe added the comment: That doesn’t really seem like a Pythonic way of extracting that information? Nor does it seem like it would be an obvious trick for the average developer to come up with. A method that provides the information directly seems useful. -- ___ Python tracker <https://bugs.python.org/issue46307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46376] PyMapping_Check returns 1 for list
Ben Avrahami added the comment: IMHO, I don't think any alternative to aviramha's solution addresses the issue, And I don't think the need is niche enough to be ignored. PyType_HasFeature excludes strings, bytes, and other esoteric types. PyMapping_Check includes mappings like dict and MappingProxyType. PySequence_Check includes non-dict mappings like MappingProxyType. The only possible solutions right now are: a. Import the "collections.abc.Sequence" class into C and run "PyObject_IsInstance" on it. This would be the correct solution, but it would be slower than aviramha's propsal. b. Perform's aviramha's proposal manually: first check the "Py_TPFLAGS_SEQUENCE" feature flag, and fallback for instance checking strings, bytecodes, and other esoteric types individually. This would be correct and fast, but is cumbersome to perform, and users are bound to forget some types. A question as simple as "would isinstance(X, ) returns true?" should be easier to answer for low-level developer, one only needs to look at the finagling numpy, among others, has to perform to parse a sequence (the relevant function in numpy is called "PyArray_FromAny"). A simple implementation of a new function for non-CPython alternatives will be to do implement solution a: import "collections.abc.Sequence", and check for instance. For CPYTHON, this can be optimized by implementing solution b. There is already a precedence for ABI functions that only exist because its trivial implementation can be optimized with CPython specific behaviour. I don't understand the reluctance to add this one. -- nosy: +avrahami.ben ___ Python tracker <https://bugs.python.org/issue46376> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41962] Make threading._register_atexit public?
Ben Darnell added the comment: > To be clear, by "cancel" you are not talking about Future.cancel(). Rather, > your handler causes all running tasks to finish (by sending a special message > on the socket corresponding to each running task). Is that right? Correct. My tasks here are calls to functions from the `select` module (one select call per executor task), and cancelling them means writing a byte to a pipe set up for this purpose. The select calls could be given a timeout so there is never an infinite task, but that's not ideal - a timeout that's too low has a performance cost as calls timeout and restart even when the system is "at rest", and a too-long timeout is still going to be perceived as a hanging application. > * it does not make sure the task associated with the socket finishes (no way > of knowing?) > * so if a task hangs while trying to stop then the running thread in the > ThreadPoolExecutor would block shutdown forever > * similarly, if a task is stuck handling a request then it will never receive > the special message on the socket, either blocking the send() in your handler > or causing ThreadPoolExecutor shutdown/atexit to wait forever Correct. If the task were buggy it could still cause a deadlock. In my case the task is simple enough (a single selector call) that this is not a risk. > * it vaguely implies a 1-to-1 relationship between sockets and *running* tasks > * likewise that pending (queued) tasks do not have an associated socket > (until started) Each task is associated with a selector object (managing a set of sockets), not a single socket. There is only ever one task at a time; a task is enqueued only after the previous one finishes. (This thread pool is not used for any other purpose) > * so once your handler finishes, any tasks pending in the ThreadPoolExecutor > queue will eventually get started but never get stopped by your handler; thus > you're back to the deadlock situation In my case this one-at-a-time rule means that the queue is always empty. But yes, in a more general solution you'd need some sort of interlock between cancelling existing tasks and starting new ones. > Alternately, perhaps ThreadPoolExecutor isn't the right fit here, as implied > by the route you ended up going. Yes, this is my conclusion as well. I filed this issue because I was frustrated that Python 3.9 broke previously-working code, but I'm willing to chalk this up to Hyrum's law and I'm not sure that this is something that ThreadPoolExecutor should be modified to support. -- ___ Python tracker <https://bugs.python.org/issue41962> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39860] configparser - no support for cascading defaults (as defined by MySQL)
Ben Griffin added the comment: This is still being ignored. It's a bug, because it prevents the ini file from being used by other clients. -- versions: +Python 3.10, Python 3.11, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue39860> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1141] reading large files
Ben Beasley added the comment:
I ran Richard Christen's script from msg55784 on Ubuntu Feisty Fawn
(64-bit) with both Python 2.5.1 and Python 3.0a1 (for the latter, I had
to change xrange to range).
(2, 5, 1, 'final', 0)
2007-09-11 11:39:08
(500, 7.3925600051879883)
(1000, 15.068881034851074)
(1500, 22.870260953903198)
(2000, 30.588511943817139)
(2500, 37.977153062820435)
(3000, 45.393024921417236)
(3500, 57.039968013763428)
(4000, 71.122976064682007)
(4500, 85.065402984619141)
(5000, 97.03105092048645)
(5500, 108.22125887870789)
(6000, 122.95617389678955)
(6500, 130.45936799049377)
(7000, 141.0406129360199)
(7500, 150.5293460083)
(8000, 158.0419979095459)
(8500, 168.4651789665)
('total lines written ', 85014960)
(85014960, 168.48725986480713)
**
(500, 11.699964046478271)
(1000, 18.510161876678467)
(1500, 27.110308885574341)
(2000, 35.410284996032715)
(2500, 41.88045597076416)
(3000, 48.734965085983276)
(3500, 56.416620016098022)
(4000, 65.14509105682373)
(4500, 73.711935043334961)
(5000, 82.278150081634521)
(5500, 90.984658002853394)
(6000, 99.987648963928223)
(6500, 104.64127588272095)
(7000, 109.73277306556702)
(7500, 114.78491401672363)
(8000, 120.38562488555908)
(8500, 126.08317303657532)
('total lines read ', 85014960)
294.583214998
(3, 0, 0, 'alpha', 1)
2007-09-11 12:20:53
500 117.375117064
1000 238.183109045
1500 357.397506952
2000 476.816791058
2500 597.198447943
3000 717.393661976
3500 837.278333902
4000 956.919227839
4500 1077.25333095
5000 1196.60731292
5500 1316.08601999
6000 1434.81360602
6500 1554.1584239
7000 1673.04580498
7500 1792.35387397
8000 1912.65659904
8500 2032.99598598
total lines written 85014960
85014960 2033.35042787
**
500 89.7920100689
1000 180.910079002
1500 272.628970146
2000 364.904497147
2500 457.229861021
3000 549.14190793
3500 641.054435968
4000 733.30577898
4500 826.058191061
5000 917.997677088
5500 1010.20616603
6000 1102.142905
6500 1194.16728902
7000 1286.54789495
7500 1378.50006604
8000 1470.37746692
8500 1562.25738001
total lines read 85014960
3595.88338494
--
nosy: +music
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1141>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1141] reading large files
Ben Beasley added the comment: See the BDFL's comment in msg55828. "I know Py3k text I/O is very slow; it's written in Python and uses UTF-8 as the default encoding. We've got a summer of code student working on an accelerating this. (And if he doesn't finish we have another year to work on it before 3.0final is released.)" __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1141> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1281] type in docutmentatio section 14.3.3.4
New submission from Ben Sherman:
"""
If, a little later on, "-tracks=4" is seen, it does:
options.tracks.append(int("4"))
"""
That should read --tracks=4, not -tracks=4
Found at
http://docs.python.org/lib/optparse-standard-option-actions.html
--
components: Documentation
messages: 56460
nosy: bsherman
severity: normal
status: open
title: type in docutmentatio section 14.3.3.4
versions: Python 2.5
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1281>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1281] type in docutmentation - lib ref section 14.3.3.4
Ben Sherman added the comment: Typos corrected. -- title: type in docutmentatio section 14.3.3.4 -> type in docutmentation - lib ref section 14.3.3.4 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1281> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1281] typo in documentation - lib ref section 14.3.3.4
Ben Sherman added the comment: There were typos in my original bug report - the typo in the documentation is still a bug. Ugh, someone must have brewed decaf. -- title: type in docutmentation - lib ref section 14.3.3.4 -> typo in documentation - lib ref section 14.3.3.4 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1281> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13055] Distutils tries to handle null versions but fails
New submission from Ben Gamari : The distutils.LooseVersion constructor currently only calls parse if vstring has a value. Unfortunately, this means that a user passing in vstring="" or vstring=None gets a version object with self.vstring and self.version unset. This wreaks havoc later when the user tries to do anything with their object. I've attached two possible solutions. The first attempts to fix the issue by raising an exception when an invalid vstring is given. This seems like the most reasonable treatment of this case as there is no reasonable way to fully initialize the object. The second works around the issue, initializing the uninitialized fields with "" in the event of an invalid vstring. -- files: distutils-fix.patch keywords: patch messages: 144575 nosy: bgamari priority: normal severity: normal status: open title: Distutils tries to handle null versions but fails Added file: http://bugs.python.org/file23252/distutils-fix.patch ___ Python tracker <http://bugs.python.org/issue13055> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13055] Distutils tries to handle null versions but fails
Changes by Ben Gamari : Added file: http://bugs.python.org/file23253/distutils-workaround.patch ___ Python tracker <http://bugs.python.org/issue13055> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13055] Distutils tries to handle null versions but fails
Changes by Ben Gamari : -- assignee: -> tarek components: +Distutils nosy: +eric.araujo, tarek type: -> crash versions: +Python 2.7 ___ Python tracker <http://bugs.python.org/issue13055> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13073] message_body argument of HTTPConnection.endheaders is undocumented
Ben Hayden added the comment: I added in docs for the method from the actual method docstring from the http.client module. -- keywords: +patch nosy: +beardedp Added file: http://bugs.python.org/file23290/issue13073.patch ___ Python tracker <http://bugs.python.org/issue13073> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13120] Default nosigint optionto pdb.Pdb() prevents use in non-main thread
New submission from Ben Bass :
The new SIGINT behaviour of pdb.Pdb prevents use of pdb within a non-main
thread without explicitly setting nosigint=True. Specifically the 'continue'
command causes a traceback as follows:
{{{
...
File
"/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/pdb.py", line
959, in do_continue
signal.signal(signal.SIGINT, self.sigint_handler)
ValueError: signal only works in main thread
}}}
Since the new behaviour seems to be to gain an enhancement rather than anything
fundamentally necessary to pdb, wouldn't it be better if the default was
reversed, so the same code would work identically on Python 3.1 (and
potentially earlier, i.e. Python2) and Python 3.2?
At the moment in my codebase (rpcpdb) I'm using inspect.getargspec sniffing for
nosigint on pdb.Pdb.__init__ to determine whether to include a nosigint=True
parameter, which clearly isn't ideal!
--
components: Library (Lib)
messages: 145040
nosy: bpb
priority: normal
severity: normal
status: open
title: Default nosigint optionto pdb.Pdb() prevents use in non-main thread
type: behavior
versions: Python 3.2
___
Python tracker
<http://bugs.python.org/issue13120>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13120] Default nosigint option to pdb.Pdb() prevents use in non-main thread
Changes by Ben Bass : -- title: Default nosigint optionto pdb.Pdb() prevents use in non-main thread -> Default nosigint option to pdb.Pdb() prevents use in non-main thread ___ Python tracker <http://bugs.python.org/issue13120> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13055] Distutils tries to handle null versions but fails
Ben Gamari added the comment: The bug was encountered while trying to install a package. As it turns out, a dependency was incorrectly installed, resulting in a null version being passed around which quickly caused a crash in setup.py. While this is definitely not a normal circumstance, the fact that this bug existed made finding the issue substantially more time consuming. If the constructor of the LooseVersion can accept None, then so should its other members. -- ___ Python tracker <http://bugs.python.org/issue13055> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13055] Distutils tries to handle null versions but fails
Ben Gamari added the comment: Sorry, no log is available. -- ___ Python tracker <http://bugs.python.org/issue13055> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12014] str.format parses replacement field incorrectly
Ben Wolfson added the comment: I just noticed that the patch labelled strformat-as-document is actually the same as the other one, owing to my incompetence. Anyway, as far as I can tell the patches would have to be reworked in the light of recent changes anyway. I am willing to do this if there's actually interest. Otherwise, is there anything else I can do here? Is it necessary to write a PEP or take this to python-ideas or something? -- ___ Python tracker <http://bugs.python.org/issue12014> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12014] str.format parses replacement field incorrectly
Ben Wolfson added the comment: "All three patches look different to me." Yeah, I verified that later; I'm not sure what made me think otherwise except that I eyeballed them sloppily. (It's still true that they'd need to target a different file for 3.3 now.) -- ___ Python tracker <http://bugs.python.org/issue12014> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13747] ssl_version documentation error
New submission from Ben Darnell : The ssl module docs claim that the default ssl_version for client-side operation is SSLv3, but it is actually SSLv23. The exact behavior depends on the version of openssl: starting in 1.0 the connection is limited by default to SSLv3 or TLSv1 (as documented in the note below the compatibility table), but in older versions of openssl SSLv2 is allowed by default. This is just a documentation error if you've got a recent version of openssl, but it's also a security problem with older versions, since people may have been unknowingly using the weaker SSLv2 protocol. (I don't know how widespread pre-1.0 versions of openssl are these days, but OSX Lion still ships with 0.9.8) It would be nice if the default mode were SSLv23 with SSL_OP_NO_SSLv2 set so the defaults would be safe even with older versions of openssl (there's no way to set this configuration from python code before py3.2) Also, the compatibility table claims that an SSLv3 client can talk to an SSLv2 server, which is incorrect. SSLv23 clients can talk to SSLv3 and TLSv1 servers if openssl is at least version 1.0 and SSLv2 ciphers are not explicitly enabled. -- messages: 150963 nosy: Ben.Darnell priority: normal severity: normal status: open title: ssl_version documentation error versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue13747> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13747] ssl_version documentation error
Ben Darnell added the comment: Not necessarily. If I want to run python 2.7 or 3.x on an older linux distribution (e.g. Ubuntu 10.04 LTS, which has python 2.6 and openssl 0.9.8), I need to build from source, but I wouldn't think to update/rebuild all the dependencies from the ground up. -- ___ Python tracker <http://bugs.python.org/issue13747> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12014] str.format parses replacement field incorrectly
Ben Wolfson added the comment:
Hm. As I interpret this:
The str.format() function will have
a minimalist parser which only attempts to figure out when it is
"done" with an identifier (by finding a '.' or a ']', or '}',
etc.).
The present implementation is at variance with both the documentation *and* the
PEP, since the present implementation does not in fact figure out when it's
"done" with an identifier that way. However, this statement is actually a very
thin reed on which to make any decisions: a real authority shouldn't say "etc."
like that! And, of course, we have to add an implicit "depending on what it's
currently looking at" to the parenthetical, because the two strings "{0[a.b]}"
and "{0[a].b}" are, and should be, treated differently. In particular, although
one could "find" a '.' in the element_index in the former string, the
"minimalist parser" should not (and does not) conclude that it's done with the
identifier *there*:
>>> "{0[a.b]}".format({"a.b":1})
'1'
Instead it treats the '.' as just another character with no particular
syntactic significance, the same way it does 'a' and 'b'. It's a shame that the
PEP doesn't go into more detail than it does about this sort of thing.
The same should go for '}', when we're looking at an element_index field. It
should be treated as just another character with no particular syntactic
significance. At present that is not the case:
>>> "{0[a}b]}".format({"a}b":1})
Traceback (most recent call last):
File "", line 1, in
ValueError: Missing ']' in format string
If the attached patch were used, the above expression would evaluate to '1'
just as did the first one. Now, given the fact that the PEP actually says quite
little about how this sort of thing is to be handled, and given (as
demonstrated above with the case of the '.' character) that we can't take the
little list it gives as indicating when it's done with an identifier regardless
of context, I don't think this change would constitute a change *to the
specification*; it does, admittedly, constitute an interpretation of the
specification, but then, so does the present implementation, and the present
implementation is at variance with the PEP *anyway*, as regards the characters
':' and '!'.
The paragraph prior to the one quoted by R. David Murray reads:
Because keys are not quote-delimited, it is not possible to
specify arbitrary dictionary keys (e.g., the strings "10" or
":-]") from within a format string.
I take it that this means (in the first place) that, because a sequence of
digits is interpreted as a number, the following will fail:
'{0[10]}'.format({"10":4})
And indeed it does. The second example is rather unfortunate, though: is the
reason one can't use that key because it contains a colon? Or because it
contains a right square bracket? Even if the present patch is accepted one
couldn't use a right square bracket, since a parser that could figure out where
to draw the lines in something like this:
'{0[foo ] bar]}'
would not be very minimalist. However, as I have noted previously, there is no
reason to rule out colons and exclamation points in the element_index field.
The PEP doesn't actually take up this question in detail. (It hardly does so at
all.) However, according to what I think the most reasonable interpretation of
the PEP is, the present implementation is at variance with the PEP. The present
implementation is certainly at variance with the documentation, which
represents to some extent an interpretation and specification of the PEP.
Consequently, to the extent that changing a specification requires discussion
on python-dev, it seems to me that the present implementation is already a de
facto change to the specification, while accepting the attached patch would
bring the implementation into *greater* accord with the specification---so that
(to conclude cheekily) *not* accepting the patch is what should require
discussion on python-dev. However, if it is thought necessary, I'll be happy to
start the discussion.
--
___
Python tracker
<http://bugs.python.org/issue12014>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12014] str.format parses replacement field incorrectly
Ben Wolfson added the comment:
"""
PEP 3101 defines format strings as intermingled character data and markup.
Markup defines replacement fields and is delimited by braces. Only after markup
is extracted does the PEP talk about interpreting the contents of the markup.
So, given "{0[a}b]}" the parser first parses out the character data and the
markup. The first piece of markup is "{0[a}". That gives a syntax error because
it's missing a right bracket.
"""
The intermingling of character data and markup is irrelevant; character data is
defined as "data which is transferred unchanged from the format string to the
output string", and nothing in "{0[a]}" is transferred unchanged.
Two parts of the PEP suggest that the markup in the above should be "{0[a}"
rather than "{0[a}]}":
Brace characters ('curly braces') are used to indicate a
replacement field within the string:
[...]
Braces can be escaped by doubling:
and
Note that the doubled '}' at the end, which would normally be
escaped, is not escaped in this case. The reason is because
the '{{' and '}}' syntax for escapes is only applied when used
*outside* of a format field. Within a format field, the brace
characters always have their normal meaning.
The first statement obviously doesn't mean that the exclusive use of braces in
a format string is to indicate replacement fields, since it's immediately
acknowledged that sometimes braces can occur without indicating a replacement
field, when they're escaped. The second occurs specifically in the context of
talking about escaping braces, so the following interpretation remains
available: within a format field, a brace is a brace is a brace---that is, a
pair of braces is a pair of braces, not an escape for a single brace.
In fact, though the following argument may appear Jesuitical, it does, I think,
hold water: The second quotation above mentions braces within a *format field*.
What is a format field? Well, we know that "The element with the braces is
called a 'field'", but "format field" is more specific; the whole thing between
braces isn't (necessarily!) the format field. And we know that
Fields consist
of a 'field name', which can either be simple or compound, and an
optional 'format specifier'.
So, perhaps a format field is the part of the broader field where the format
specifier lives. And lo, it's in the part of the PEP talking about "Format
Specifiers" that we get the second quotation above.
Each field can also specify an optional set of 'format
specifiers' which can be used to adjust the format of that field.
Format specifiers follow the field name, with a colon (':')
character separating the two:
So even if you think that the claim that "within a format field, the brace
characters always have their normal meaning" means not "the brace characters
aren't escaped" but "the brace characters indicate a replacement field", that
statement could just mean that they only have this significance in *part* of
the *replacement* field---the part having to do with the formatting of the
replacement text---and not the whole replacement field. So that, for instance,
the following does what you'd expect:
>>> "{0[{4}]}".format({"{4}":3})
'3'
And it *does* do what you'd expect, in the *current* implementation---that is,
the braces here don't have the meaning of introducing a replacement field
[they're kinda-sorta parsed as if they were introduced a replacement field but
that is obviously not their semantics], but are instead just treated as braces.
They also aren't escaped:
>>> "{0[{{4}}]}".format({"{{4}}":3})
'3'
--
___
Python tracker
<http://bugs.python.org/issue12014>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12014] str.format parses replacement field incorrectly
Ben Wolfson added the comment:
str.format doesn't intermingle character data and markup. The PEP is quite
clear about the terms in this case, at least: the *argument* to str.format
consists of character data (passed through unchanged) and markup (processed).
That's what it means to say that "Character data is data which is transferred
unchanged from the format string to the output string". In "My name is {0}",
"My name is " is transferred unchanged from the format string to the output
string when the string is formatted. We're talking about how the *markup* is
defined.
"""
The current implementation of str.format() finds matched pairs of braces and
call what's inside "markup", then parse that markup.
"""
This is false, as I demonstrated.
>>> d = {"{0}": "spam"}
>>> # a matched pair of braces. What's inside is considered markup.
...
>>> "{0}".format(d)
"{'{0}': 'spam'}"
>>> # a matched pair of braces. Inside is a matched pair of braces, and what's
>>> inside of that is not considered markup.
...
>>> "{0[{0}]}".format(d)
'spam'
>>>
"""
It's also true that other interpretations of the PEP are possible. I'm just not
sure the benefit to be gained justifies changing all of the extant str.format()
implementations, in addition to explaining the different behavior.
"""
Well, the beauty of it is, you wouldn't have to explain the different behavior,
because the patch makes it the case that the explanation already in the
documentation is correct. It is currently not correct. That's why I found out
about this current state of affairs: I read the documentation's explanation and
believed it, and only after digging into the code did I understand the actual
behavior.
It is also not a difficult change to make, would be backwards-compatible
(anyway I rather doubt anyone was relying on a "{0[:]}".format(whatever)
raising an exception [1]), and relaxes a restriction that is not well motivated
by the text of the PEP, is not consistently applied in the implementation (see
above), and is confusing and limits the usefulness of the format method. It is
true that I don't know where else, beyond the implementation in
string_format.h, modifications would need to be made, but I'd be willing to
undertake the task.
[1] and given that the present implementation does that, it's already
noncompliant with the PEP, regardless of what one makes of curly braces.
--
___
Python tracker
<http://bugs.python.org/issue12014>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12014] str.format parses replacement field incorrectly
Ben Wolfson added the comment:
"""
>From the PEP: "Format strings consist of intermingled character data and
>markup."
"""
I know. Here is an example of a format string:
"hello, {0}"
Here is the character data from that format string:
"hello, "
Here is the markup:
"{0}"
This follows *directly* from the definition of "character data", which I've
quoted several times now. In the following expression:
"{0}".format(1)
there is NO character data, because there is NOTHING which is "which is
transferred unchanged from the format string to the output string".
The "{0}" doesn't appear in the output string at all. And the 1 isn't
transferred unchanged: it has str() called on it. Since there is nothing which
meets the definition of character data, there is nothing which *is* character
data in the string, regarded as a format string. It is pure markup---it
consists solely of a replacement field delimited by curly braces. I really
don't see why this matters at all, but, nevertheless, I apologize if I'm
explaining it poorly.
"""
Again, I'm not sure what you're getting at. The inner "{0}" is not interpreted
(per the PEP). So the entire string is replaced by d['{0}'], or 'spam'.
Let me try to explain it again. str.format() parses the string, looking for
matched sets of braces. In your last example above, the very first character
'{' is matched to the very last character '}'. They match, in sense that all of
the nested ones inside match. Once the markup is separated from the character
data, the interpretation of what's inside the markup is then done. In this
example, there is no character data.
"""
Yes, there is no character data. And I understand perfectly what is happening.
Here's the problem: your description of what the implementation does is
incorrect. You say that
"""
The current implementation of str.format() finds matched pairs of braces and
call what's inside "markup", then parse that markup.
"""
Now, the only reason for thinking that this:
"{0[}]}"
should be treated differently from this:
"{0[a]}"
is that inside square brackets curly brackets indicate replacement fields. If
you want to justify what the current implementation does as an implementation
of the PEP and an interpretation of what the PEP says, you *have* to think
that. But if you think that, then the current implementation should *not* treat
this:
"{0[{0}]}"
the way it does, because it does *not* treat the interior curly braces as
indications of a replacement field---or rather, it does at one point in the
source (in MarkupIterator_next) and it doesn't at another (in
FieldNameIterator). I agree that what the current implementation does in the
last example is in fact correct. But if it's correct in the one case, it's
incorrect in the other, and vice versa. There is no justification, in terms of
the PEP, for the present behavior.
--
___
Python tracker
<http://bugs.python.org/issue12014>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12376] unittest.TextTestResult.__init__ breaks under complex __mro__
New submission from Ben Ranker : TextTestResult.__init__(...) calls super(TextTestResult, self).__init__() with no args. If a custom TextTestResult descendant has a complex inheritance hierarchy that puts another class between TextTestResult and TestResult in the __mro__, then that class doesn't receive the common stream, descriptions, and verbosity args. If it needs them to function then the __init__ chain explodes. See attached breakunit.py for an example of this. -- components: Library (Lib) files: breakunit.py messages: 138744 nosy: branker priority: normal severity: normal status: open title: unittest.TextTestResult.__init__ breaks under complex __mro__ type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file22418/breakunit.py ___ Python tracker <http://bugs.python.org/issue12376> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12376] unittest.TextTestResult.__init__ does not pass on its init arguments in super call
Ben Ranker added the comment: Sorry for any confusion caused by my imprecise use of the word "explodes." -- ___ Python tracker <http://bugs.python.org/issue12376> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12014] str.format parses replacement field incorrectly
Ben Wolfson added the comment: This patch differs from the previous one; its goal is to bring the actual behavior of the interpreter into line with the documentation (with the exception of using only decimal integers, rather than any integers, wherever the documentation for str.format currently has "integer": this does, however, conform with current behavior). -- Added file: http://bugs.python.org/file22598/strformat-as-documented.diff ___ Python tracker <http://bugs.python.org/issue12014> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12014] str.format parses replacement field incorrectly
Ben Wolfson added the comment:
And here is a patch for Greg Ewing's proposal:
http://mail.python.org/pipermail/python-dev/2011-June/111934.html
Again, decimal integers rather than any kind of integers are used.
Both patches alter the exceptions expected in various places in test_unicode's
test_format:
"{0.}".format() raises a ValueError (because the format string is invalid)
rather than an IndexError (because there is no argument)
"{0[}".format(), likewise.
"{0]}".format() raises a ValueError (because the format string is invalid)
rather than a KeyError (because "0]" is taken to be the name of a keyword
argument---meaning that the test suite was testing the actual behavior of the
implementation rather than the documented behavior).
"{c]}".format(), likewise.
In this patch, "{0[{1}]}".format('abcdef', 4) raises a ValueError rather than a
TypeError, because "{1}", being neither a decimalinteger nor an identifier,
invalidates the replacement field.
Both patches also add tests for constructions like this:
"{[0]}".format([3]) --> '3'
"{.__class__}".format(3) --> ""
This conforms with the documentation (and current behavior), since in it
arg_name is defined to be optional, but it is not currently covered in
test_format, that I could tell, anyway.
--
Added file:
http://bugs.python.org/file22599/strformat-just-identifiers-please.diff
___
Python tracker
<http://bugs.python.org/issue12014>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12014] str.format parses replacement field incorrectly
Ben Wolfson added the comment: undo integer -> decimalinteger in docs -- Added file: http://bugs.python.org/file22601/strformat-as-documented.diff ___ Python tracker <http://bugs.python.org/issue12014> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12014] str.format parses replacement field incorrectly
Changes by Ben Wolfson : Removed file: http://bugs.python.org/file22598/strformat-as-documented.diff ___ Python tracker <http://bugs.python.org/issue12014> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12014] str.format parses replacement field incorrectly
Ben Wolfson added the comment: (same as previous) -- Added file: http://bugs.python.org/file22602/strformat-just-identifiers-please.diff ___ Python tracker <http://bugs.python.org/issue12014> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12014] str.format parses replacement field incorrectly
Changes by Ben Wolfson : Removed file: http://bugs.python.org/file22599/strformat-just-identifiers-please.diff ___ Python tracker <http://bugs.python.org/issue12014> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12529] cgi.parse_header fails on double quotes and semicolons
New submission from Ben Darnell :
cgi.parse_header doesn't work on headers that contain combinations of double
quotes and semicolons (although it works with either type of character
individually).
>>> cgi.parse_header('form-data; name="files"; filename="fo\\"o;bar"')
('form-data', {'name': 'files', 'filename': '"fo\\"o'})
This issue is present in python 2.7 and 3.2. One solution is to change
_parseparam as follows (same as email.message._parseparam):
def _parseparam(s):
while s[:1] == ';':
s = s[1:]
end = s.find(';')
while end > 0 and (s.count('"', 0, end) - s.count('\\"', 0, end)) % 2:
end = s.find(';', end + 1)
if end < 0:
end = len(s)
f = s[:end]
yield f.strip()
s = s[end:]
--
messages: 140091
nosy: Ben.Darnell
priority: normal
severity: normal
status: open
title: cgi.parse_header fails on double quotes and semicolons
___
Python tracker
<http://bugs.python.org/issue12529>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11657] multiprocessing_{send,recv}fd fail with fds > 256
Ben Darnell added the comment: These functions are used when passing a socket object across a multiprocessing.Queue. -- ___ Python tracker <http://bugs.python.org/issue11657> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12725] Docs: Odd phrase "floating seconds" in socket.html
Ben Hayden added the comment: I made the suggested second change - both in the docs & the socketmodule.c file. If there's a different way to patch documentation, someone let me know. :D -- keywords: +patch nosy: +beardedp Added file: http://bugs.python.org/file22896/issue12725.patch ___ Python tracker <http://bugs.python.org/issue12725> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12750] datetime.datetime timezone problems
Changes by Ben Finney : -- nosy: +bignose ___ Python tracker <http://bugs.python.org/issue12750> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12756] datetime.datetime.utcnow should return a UTC timestamp
New submission from Ben Finney :
=
$ date -u +'%F %T %s %z'
2011-08-16 06:42:12 1313476932 +
$ python -c 'import sys, datetime; now = datetime.datetime.utcnow();
sys.stdout.write(now.strftime("%F %T %s %z"))'
2011-08-16 06:42:12 1313440932
=
The documentation for ‘datetime.datetime.utcnow’ says “Return a new datetime
representing UTC day and time.” The resulting object should be in the UTC
timezone, not a naive no-timezone value.
This results in programs specifically requesting UTC time with ‘utcnow’, but
then Python treating the return value as representing local time since it is
not marked with the UTC timezone.
--
components: Library (Lib)
messages: 142164
nosy: Daniel.O'Connor, bignose, r.david.murray
priority: normal
severity: normal
status: open
title: datetime.datetime.utcnow should return a UTC timestamp
type: feature request
versions: Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/issue12756>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12786] subprocess wait() hangs when stdin is closed
Ben Wolfson added the comment: "The guys at #python-dev confirmed the same happens on 2.7 but not on 3.x." Really? This is on gentoo, not debian, admittedly: coelacanth ~ 11:12:36 $ python3 Python 3.1.3 (r313:86834, May 1 2011, 09:41:48) [GCC 4.4.4] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import subprocess >>> proc1 = subprocess.Popen(['cat'], stdin=subprocess.PIPE) >>> proc2 = subprocess.Popen(['cat'], stdin=subprocess.PIPE) >>> proc2.stdin.close() >>> proc2.wait() 0 >>> coelacanth ~ 11:12:13 $ python3.1 Python 3.1.3 (r313:86834, May 1 2011, 09:41:48) [GCC 4.4.4] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import subprocess >>> proc1 = subprocess.Popen(['cat'], stdin=subprocess.PIPE) >>> proc2 = subprocess.Popen(['cat'], stdin=subprocess.PIPE) >>> proc1.stdin.close() >>> proc1.wait() [hangs] -- nosy: +Ben.Wolfson ___ Python tracker <http://bugs.python.org/issue12786> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3710] Reference leak in thread._local
Ben Cottrell added the comment: The latest patch over in #1868 is working fine for my company in production, and solves #3710 as well. I think the only thing left to do on that patch is to make it special case "__dict__". -- ___ Python tracker <http://bugs.python.org/issue3710> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9665] Buid issues on Cygwin - _curses, _curses_panel, and _io
Ben Walker added the comment: I have been using the following patch to fix the issue locally for a few weeks now (in addition to something equivalent to what Brian submitted for the _curses issue). These two patches combined give me a working python 2.7 on cygwin 1.7. I originally used something identical to Roumen's patch, but later started using the patch below after reading up on __declspec. Note that line 740 is also a candidate to be changed to dllexport, but I don't have the setup to test that. Index: Include/pyport.h === --- Include/pyport.h(revision 84288) +++ Include/pyport.h(working copy) @@ -739,7 +739,7 @@ # if !defined(__CYGWIN__) # define PyAPI_FUNC(RTYPE) __declspec(dllimport) RTYPE # endif /* !__CYGWIN__ */ -# define PyAPI_DATA(RTYPE) extern __declspec(dllimport) RTYPE +# define PyAPI_DATA(RTYPE) extern __declspec(dllexport) RTYPE /* module init functions outside the core must be exported */ # if defined(__cplusplus) # define PyMODINIT_FUNC extern "C" __declspec(dllexport) void -- nosy: +bwalker ___ Python tracker <http://bugs.python.org/issue9665> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9694] argparse: Default Help Message Lists Required Args As Optional
New submission from Ben Schmaus :
The argparse module lists required args as optional in the default help message.
If you run the following program (also attached) you'll get the output listed
below.
#!/usr/bin/env python
import argparse
parser = argparse.ArgumentParser(
description = 'Do something'
)
parser.add_argument('--reqarg', '-r', help = 'This is required', required =
True)
parser.add_argument('--optarg','-o', help = "This is optional", required =
False)
args = parser.parse_args()
$ python argparse-help-says-required-args-are-optional.py -h
usage: argparse-help-says-required-args-are-optional.py [-h] --reqarg REQARG
[--optarg OPTARG]
Do something
optional arguments:
-h, --helpshow this help message and exit
--reqarg REQARG, -r REQARG
This is required
--optarg OPTARG, -o OPTARG
This is optional
$
--
components: Library (Lib)
files: argparse-help-says-required-args-are-optional.py
messages: 115017
nosy: benschmaus
priority: normal
severity: normal
status: open
title: argparse: Default Help Message Lists Required Args As Optional
type: behavior
versions: Python 2.7
Added file:
http://bugs.python.org/file18654/argparse-help-says-required-args-are-optional.py
___
Python tracker
<http://bugs.python.org/issue9694>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9694] argparse: Default Help Message Lists Required Args As Optional
Ben Schmaus added the comment: FWIW, I like the idea of just using the label "options". -- ___ Python tracker <http://bugs.python.org/issue9694> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1351020] PythonD DJGPP-specific patch set for porting to DOS.
Ben Decker added the comment: Closed then. The next patch will posted at http://www.caddit.net/pythond/when we get around to doing a version 3 port. Frankly, as the current v2 binary meets most remaining requirements on this legacy platform, we are left with modern syntax compatibility as primary (only) impetus for further patches. -- ___ Python tracker <http://bugs.python.org/issue1351020> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9090] Error code 10035 calling socket.recv() on a socket with a timeout (WSAEWOULDBLOCK - A non-blocking socket operation could not be completed immediately)
Ben Smith added the comment: I also see this issue on occasion on windows XP SP 3, using python 2.6.5 to fetch large files via http. The error is infrequent, but it is happening in my situation without a VM. -- nosy: +Ben.Smith ___ Python tracker <http://bugs.python.org/issue9090> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5131] pprint doesn't know how to print a defaultdict
Ben Bass added the comment: Same applies to collections.deque, which seems closely related (being another collections class). Can this get addressed here or should I open another issue? (just been pprinting defaultdict(deque) objects, which clearly fails :) -- nosy: +bpb ___ Python tracker <http://bugs.python.org/issue5131> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10345] fcntl.ioctl always fails claiming an invalid fd
New submission from Ben Gamari :
Even the simple example included below fails in the following manner,
$ sudo python3.1 hi.py
3
Traceback (most recent call last):
File "hi.py", line 13, in
ioctl(a, EVIOCGID, buf, True)
TypeError: ioctl requires a file or file descriptor, an integer and optionally
an integer or buffer argument
As the debugging output demonstrates, the fileno() is in fact a valid fd.
#!/usr/bin/python
from fcntl import ioctl
EVIOCGID = 1
f = open('/dev/input/mouse0', 'w')
buf = bytes([0]*128)
a = (f.fileno(),)
print(a.__class__, a)
ioctl(a, EVIOCGID, buf, True)
print(buf)
--
components: Extension Modules
messages: 120657
nosy: bgamari
priority: normal
severity: normal
status: open
title: fcntl.ioctl always fails claiming an invalid fd
versions: Python 3.1
___
Python tracker
<http://bugs.python.org/issue10345>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10345] fcntl.ioctl always fails claiming an invalid fd
Changes by Ben Gamari : -- type: -> behavior ___ Python tracker <http://bugs.python.org/issue10345> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10345] fcntl.ioctl always fails claiming an invalid fd
Ben Gamari added the comment: The problem seems to have been that I tried passing mutate_flag. Things seem to work fine when the last parameter is omitted. -- ___ Python tracker <http://bugs.python.org/issue10345> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11550] Fix ResourceWarning in test_pulldom
New submission from Ben Hayden : When running the test_pulldom test with a latest checkout of cpython from hg.python.org on Ubuntu 10.10 x64, the following ResourceWarning is thrown: test_parse (test.test_pulldom.PullDOMTestCase) Minimal test of DOMEventStream.parse() ... /home/benhayden/Documents/cpython/Lib/test/test_pulldom.py:35: ResourceWarning: unclosed file <_io.TextIOWrapper name='/home/benhayden/Documents/cpython/Lib/test/xmltestdata/test.xml' mode='r' encoding='UTF-8'> list(pulldom.parse(tstfile)) ok This is because pulldom.parse returns an open file object if the argument it is passed is a string & not a file object. Attached is a patch that makes sure that file is closed. -- components: Tests files: test_pulldom_resource_warning.patch keywords: patch messages: 130956 nosy: beardedp priority: normal severity: normal status: open title: Fix ResourceWarning in test_pulldom type: resource usage versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file21203/test_pulldom_resource_warning.patch ___ Python tracker <http://bugs.python.org/issue11550> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11550] Fix ResourceWarning in test_pulldom
Changes by Ben Hayden : Removed file: http://bugs.python.org/file21203/test_pulldom_resource_warning.patch ___ Python tracker <http://bugs.python.org/issue11550> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11550] Fix ResourceWarning in test_pulldom
Changes by Ben Hayden : -- versions: -Python 3.3, Python 3.4 Added file: http://bugs.python.org/file21205/test_pulldom_resource_warning.patch ___ Python tracker <http://bugs.python.org/issue11550> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11550] Fix ResourceWarning in test_pulldom
Ben Hayden added the comment: I was unclear as to why the list() calls were there. I thought it would just change the iterator into a list - I didn't know that actually was needed for the test - my mistake. I'll change it back to the list() - but I'll need to loop over the first list to make sure and close the stream. -- ___ Python tracker <http://bugs.python.org/issue11550> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11453] asyncore.file_wrapper should implement __del__ and call close there to prevent resource leaks and behave like socket.socket does.
Ben Hayden added the comment: Adding a patch that adds an __exit__ function much like the one that socket.socket implements. Passes the test_asyncore & also doesn't raise a resource warning when I explicitly comment out some close() calls on file wrapper objects in the test. -- keywords: +patch nosy: +beardedp Added file: http://bugs.python.org/file21236/issue11453.patch ___ Python tracker <http://bugs.python.org/issue11453> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11657] multiprocessing_{send,recv}fd fail with fds > 256
New submission from Ben Darnell :
Line 125 of multiprocessing.c is "*CMSG_DATA(cmsg) = fd;". CMSG_DATA returns
an unsigned char*, while fd is an int, so this code does not support file
descriptors > 256 (additionally, I'm not sure if the buffer is guaranteed to be
initialized with zeros). recvfd has an analogous problem at line 168. Both
of these need to be changed to copy the entire integer, e.g. by casting the
result of CMSG_DATA to an int*.
http://hg.python.org/cpython/file/5deb2094f033/Modules/_multiprocessing/multiprocessing.c
--
messages: 131947
nosy: Ben.Darnell
priority: normal
severity: normal
status: open
title: multiprocessing_{send,recv}fd fail with fds > 256
type: behavior
___
Python tracker
<http://bugs.python.org/issue11657>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11659] Fix ResourceWarning in test_subprocess
New submission from Ben Hayden : Adding in a cleanup to close Popen stdout in the function test_select_unbuffered in test_subprocess file in Lib/test dir. There are several tickets about different resource warnings mentioning test_subprocess - but I couldn't find any patches that fix this specific issue. -- components: Tests files: test_subprocess_resource_warning.patch keywords: patch messages: 131960 nosy: beardedp priority: normal severity: normal status: open title: Fix ResourceWarning in test_subprocess type: resource usage versions: Python 3.3 Added file: http://bugs.python.org/file21366/test_subprocess_resource_warning.patch ___ Python tracker <http://bugs.python.org/issue11659> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1692335] Fix exception pickling: Move initial args assignment to BaseException.__new__
Ben Bass added the comment:
Perhaps this should be addressed separately, but subprocess.CalledProcessError
is subject to this problem (can't be unpickled) (it has separate returncode and
cmd attributes, but no args).
It's straightforward to conform user-defined Exceptions to including .args and
having reasonable __init__ functions, but not possible in the case of stdlib
exceptions.
>>> import subprocess, pickle
>>> try:
... subprocess.check_call('/bin/false')
... except Exception as e:
... pickle.loads(pickle.dumps(e))
...
Traceback (most recent call last):
File "", line 2, in
File "/usr/lib/python3.1/subprocess.py", line 435, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '/bin/false' returned non-zero exit
status 1
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "", line 4, in
File "/usr/lib/python3.1/pickle.py", line 1363, in loads
encoding=encoding, errors=errors).load()
TypeError: __init__() takes at least 3 positional arguments (1 given)
--
nosy: +bpb
___
Python tracker
<http://bugs.python.org/issue1692335>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11914] pydoc modules/help('modules') crash in dirs with unreadable subdirs
New submission from Ben Okopnik :
Long-standing problem (happens in every Python version I've tested). The usual
situation is when invoking Python (and then "help('modules')") or "pydoc
modules" in /tmp, but also happens when located anywhere with unreadable
subdirs:
ben@Jotunheim:~$ mkdir /tmp/foo; cd /tmp/foo
ben@Jotunheim:/tmp/foo$ mkdir bar; sudo chmod 000 bar
[sudo] password for ben:
ben@Jotunheim:/tmp/foo$ pydoc modules
Please wait a moment while I gather a list of all available modules...
Traceback (most recent call last):
File "/usr/bin/pydoc2.6", line 5, in
pydoc.cli()
File "/usr/lib/python2.6/pydoc.py", line 2309, in cli
help.help(arg)
File "/usr/lib/python2.6/pydoc.py", line 1765, in help
elif request == 'modules': self.listmodules()
File "/usr/lib/python2.6/pydoc.py", line 1886, in listmodules
ModuleScanner().run(callback, onerror=onerror)
File "/usr/lib/python2.6/pydoc.py", line 1937, in run
for importer, modname, ispkg in pkgutil.walk_packages(onerror=onerror):
File "/usr/lib/python2.6/pkgutil.py", line 105, in walk_packages
for importer, name, ispkg in iter_modules(path, prefix):
File "/usr/lib/python2.6/pkgutil.py", line 147, in iter_modules
for name, ispkg in iter_importer_modules(i, prefix):
File "/usr/lib/python2.6/pkgutil.py", line 211, in iter_modules
for fn in os.listdir(path):
OSError: [Errno 13] Permission denied: './bar'
Proposed patch:
Seems like an easy fix. In Python 3.1.2, change line 206 in
/usr/lib/python3.1/pkgutil.py from
if not modname and os.path.isdir(path) and '.' not in fn:
to
if not modname and os.path.isdir(path) and '.' not in fn and os.access(path,
os.R_OK):
Other versions much the same (although the specified line number will probably
be different.)
Best regards,
Ben Okopnik
--
components: Demos and Tools
messages: 134323
nosy: okopnik
priority: normal
severity: normal
status: open
title: pydoc modules/help('modules') crash in dirs with unreadable subdirs
type: crash
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python
3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/issue11914>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11914] pydoc modules/help('modules') crash in dirs with unreadable subdirs
Ben Okopnik added the comment: Here's a test that should exercise every version of "pydoc" installed on the system: mkdir -p /tmp/foo/bar; cd /tmp/foo; chmod 0 bar for n in `whereis -b pydoc`; do echo " $n "; $n modules; done Tested under Ubuntu with bash and sh; should work fine with any Bourne-derived shell that supports 'whereis'. Please see attached file. -- Added file: http://bugs.python.org/file21803/pydoc_crash_test ___ Python tracker <http://bugs.python.org/issue11914> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11914] pydoc modules/help('modules') crash in dirs with unreadable subdirs
Ben Okopnik added the comment:
Trivial fix: please see attached. As to test_pydoc.py, I don't know the system
well enough to fiddle with it, but something like this should work (untested):
def test_unreadable_dir(self):
''' pydoc should handle unreadable subdirs gracefully '''
@contextmanager
def mk_unreadable_dir():
top_level_dir = tempfile.mkdtemp()
bad_dir = tempfile.mkdtemp(dir=top_level_dir)
os.chmod(bad_dir, 0)
os.chdir(top_level_dir)
yield
os.removedirs(top_level_dir)
with mk_unreadable_dir():
doc = pydoc.render_doc('modules')
self.assertTrue("modules" in doc)
--
Added file: http://bugs.python.org/file21807/pydoc_crash_test
___
Python tracker
<http://bugs.python.org/issue11914>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11914] pydoc modules/help('modules') crash in dirs with unreadable subdirs
Ben Okopnik added the comment: Whoops... with all of that, I just realized that this bug should be filed against pkgutil, not pydoc (pydoc, of course, calls pkgutil to do the path resolution, which is where this crash occurs.) My bad. >>> import pkgutil >>> inst = pkgutil.ImpImporter(path='/tmp') >>> list(inst.iter_modules()) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.1/pkgutil.py", line 209, in iter_modules for fn in os.listdir(path): OSError: [Errno 13] Permission denied: '/tmp/orbit-gdm' -- ___ Python tracker <http://bugs.python.org/issue11914> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12004] PyZipFile.writepy gives internal error on syntax errors
New submission from Ben Morgan : PyZipFile.writepy gives internal error on syntax errors in files it processes. For example, in the attached test case: Traceback (most recent call last): File "C:\tfs\SDKS\python\Python32\lib\py_compile.py", line 119, in compile optimize=optimize) File "test_zipfile_error_bad_syntax.py", line 1 syntax error ^ SyntaxError: invalid syntax During handling of the above exception, another exception occurred: Traceback (most recent call last): File "C:\tfs\SDKS\python\Python32\lib\zipfile.py", line 1393, in _compile py_compile.compile(file, doraise=True, optimize=optimize) File "C:\tfs\SDKS\python\Python32\lib\py_compile.py", line 123, in compile raise py_exc py_compile.PyCompileError: File "test_zipfile_error_bad_syntax.py", line 1 syntax error ^ SyntaxError: invalid syntax During handling of the above exception, another exception occurred: Traceback (most recent call last): File "test_zipfile_error.py", line 7, in pzf.writepy(PYFILE) File "C:\tfs\SDKS\python\Python32\lib\zipfile.py", line 1376, in writepy fname, arcname = self._get_codename(pathname[0:-3], basename) File "C:\tfs\SDKS\python\Python32\lib\zipfile.py", line 1428, in _get_codename if _compile(file_py): File "C:\tfs\SDKS\python\Python32\lib\zipfile.py", line 1395, in _compile print(err.msg) NameError: global name 'err' is not defined Around zipfile.py:1395 in PyZipFile._get_codename _compile try: py_compile.compile(file, doraise=True, optimize=optimize) except py_compile.PyCompileError as error: print(err.msg) return False The print should be printing error.msg not err.msg -- files: test_zipfile_error.py messages: 135170 nosy: Ben.Morgan priority: normal severity: normal status: open title: PyZipFile.writepy gives internal error on syntax errors type: behavior Added file: http://bugs.python.org/file21888/test_zipfile_error.py ___ Python tracker <http://bugs.python.org/issue12004> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12004] PyZipFile.writepy gives internal error on syntax errors
Changes by Ben Morgan : -- keywords: +patch Added file: http://bugs.python.org/file21889/pyzipfile-error.patch ___ Python tracker <http://bugs.python.org/issue12004> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
