[issue47231] TarFile.getmember cannot work on tar sourced directory over 100 characters
New submission from Chris Fernald : A fix was made to unify handling of the trailing slash in TarFile.getmember related to https://bugs.python.org/issue21987. This change fixed the <100 character case, but made it so directories over 100 character which come from a tar file can no longer be accessed through getmember, even if returned from getnames. This appears to be because internal to tarfile, member names still include the trailing slash on directories over 100 characters but getmember will always remove the trailing slash from the provided name so the comparison will always fail. A simple example of this is as follows using 3.10.4. 1. Download: https://developer.arm.com/-/media/Files/downloads/gnu-a/10.3-2021.07/binrel/gcc-arm-10.3-2021.07-x86_64-aarch64-none-linux-gnu.tar.xz 2. place attached python script in same directory 3. run on 3.8.2 -> fails to get stripped version of path (line 16) 4. run on 3.10.4 -> fails to get even unstripped version (line 12 & 16) -- components: Library (Lib) files: tarfile_repro.py messages: 416793 nosy: cfernald, serhiy.storchaka priority: normal severity: normal status: open title: TarFile.getmember cannot work on tar sourced directory over 100 characters type: behavior versions: Python 3.10, Python 3.11, Python 3.9 Added file: https://bugs.python.org/file50721/tarfile_repro.py ___ Python tracker <https://bugs.python.org/issue47231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27198] Adding an assertClose() method to unittest.TestCase
Chris Barker added the comment: Yes -- it was on me years ago to do this. Honestly, I haven't done it yet because I lost the momentum of PyCon, and I don't personally use unittest at all anyway. But I still think it's a good idea, and I'd like to keep it open with the understanding that if I don't get it done soon, it'll be closed (or someone else is welcome to do it, of course, if they want) is, say, three weeks soon enough? @Vedran Čačić wrote: "... and in the moment that you're deciding on this, you have the exact value expected right in front of you." Well, yes and no. First of all, not always a literal, though yes, most often it is. But: 1) If the "correct" value is, e.g. 1.2345678e23 -- the delta is not exactly "right there in front of you" -- yes, not that hard to figure out, but it takes a bit of thought, compared to "I want it to be close to this number within about 6 decimal places" (rel_tol=1e-6) 2) Sometimes you have a bunch of values that you are looping over in your tests, or doing parameterized tests -- it which case the relative tolerance could be constant, but the delta is not. 3) With that argument, why do we have the "decimal places" tolerance, rather than a delta always? Anyway, if I didn't consistently use pytest, I'd want this, so I'm happy to get it done. Thanks for the ping, @Irit Katriel -- ___ Python tracker <https://bugs.python.org/issue27198> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43333] utf8 in BytesGenerator
Chris added the comment: found this issue while googling the error. Also having the same problem with as_bytes() breaking on non-ascii characters. I've tried policy=policy.default.clone(utf8=True) but it gives the same error. My sample.py file attached contains a string sample email - which has a character \u200d (https://unicode-table.com/en/200D/) - Zero Width Joiner in the body. UnicodeEncodeError: 'ascii' codec can't encode character '\u200d' in position 70: ordinal not in range(128) Any assistance on what I can do to solve it would be great. It seems I can parse 99% of the emails I've tried but this one has me confused. -- nosy: +chrisstaunton1990 Added file: https://bugs.python.org/file50641/sample.py ___ Python tracker <https://bugs.python.org/issue4> ___ ___ 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.
Chris Jerdonek added the comment: For future reference, with Andrew's change merged above, the traceback for the example snippet in my message above: https://bugs.python.org/issue45390#msg403570 is now the following. Observe that (1) the call to sleep() continues to be present, but (2) without introducing two new intermediate CancelledErrors, which increase the verbosity of the traceback: Traceback (most recent call last): File "/home/andrew/projects/cpython/exc_traceback.py", line 14, in asyncio.run(main()) ^^^ File "/home/andrew/projects/cpython/Lib/asyncio/runners.py", line 44, in run return loop.run_until_complete(main) ^ File "/home/andrew/projects/cpython/Lib/asyncio/base_events.py", line 640, in run_until_complete return future.result() ^^^ File "/home/andrew/projects/cpython/exc_traceback.py", line 11, in main await task ^^ File "/home/andrew/projects/cpython/exc_traceback.py", line 5, in job await asyncio.sleep(5) ^^ File "/home/andrew/projects/cpython/Lib/asyncio/tasks.py", line 619, in sleep return await future asyncio.exceptions.CancelledError: cancel job (This is copied from Andrew's comment in the PR here: https://github.com/python/cpython/pull/31383#issuecomment-1046822899 ) Serhiy, can you provide a sample snippet for your case with output, like I did in my message linked above? -- ___ 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
[issue46829] Confusing CancelError message if multiple cancellations are scheduled
Chris Jerdonek added the comment: I don't really understand all the hate around the idea of a cancel message. One reason it's useful is that it provides a simple way to say *why* something is being cancelled or *what* is cancelling it. It provides additional context to the exception, in the same way that a normal exception's message can provide additional helpful context. Take for example this chunk of code: import asyncio import random async def job(): await asyncio.sleep(5) async def main(): task = asyncio.create_task(job()) await asyncio.sleep(1) r = random.random() if r < 0.5: task.cancel() else: task.cancel() await task if __name__=="__main__": asyncio.run(main()) Without passing a message, there's no way to tell which of the two lines called cancel, or why. The tracebacks are identical in both cases. This is even in the simplest case where only one cancellation is occurring. Passing a message lets one disambiguate the two call sites. And if there is truly a race condition where it's up in the air between two things cancelling it, I think it would be okay for the chosen message to be indeterminate, as either would have instigated the cancel in the absence of the other. -- ___ Python tracker <https://bugs.python.org/issue46829> ___ ___ 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.
Chris Jerdonek added the comment: Andrew, the approach I described would I feel be much better. It would result in more concise, less verbose tracebacks, as opposed to more verbose -- not just because the message won't be repeated, but also because it eliminates the unneeded creation of intermediate exceptions. It would also cause is checks to work, which is what we want since behaviorally it should be the same exception. -- ___ 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
[issue46771] Add some form of cancel scopes
Chris Jerdonek added the comment: > I'm not sure yet (if anything I'd need it for a task, not a future). (By future, I also meant task, as task inherits from future.) For now, I think it would be safer to get the message from the CancelledError, if possible, since how it gets there truly is an implementation detail. It would be okay to document that the msg argument gets passed to the CancelledError via the constructor, as that was always the intent. See also issue 45390 and the message I wrote there on how to make that API work better (given that the msg is only available from the leaf exception in the exception chain, and the current implementation creates intermediate exceptions, I believe unnecessarily): https://bugs.python.org/issue45390#msg403570 -- ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
Chris Jerdonek added the comment: > I note that there is no documented way to retrieve the cancel message Does retrieving it from the CancelledError that is bubbling up suffice? Or do you need to be able to obtain it from the future object? -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13305] datetime.strftime("%Y") not consistent for years < 1000
Chris Larson added the comment: Has there been any work/progress on this? Alternatively, what suggested work around/mitigations are suggested? -- nosy: +cklarson ___ Python tracker <https://bugs.python.org/issue13305> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46601] macOS installer "Install Certificates.command" fails if pip is not installed
Chris Drake added the comment: So it looks like a dependency error in the installer then? It obviously makes no sense for pip to required before the python installer can work - chicken-and-egg issue - the installer should install what it needs of course, which I guess includes pip if that's really needed at this stage... -- ___ Python tracker <https://bugs.python.org/issue46601> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46601] Instructions do not work
New submission from Chris Drake : See https://github.com/python/pythondotorg/issues/1774#issuecomment-1025250329 -- components: macOS messages: 412257 nosy: cryptophoto, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Instructions do not work versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46601> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Chris Satterlee added the comment: FYI, it appears that 8.6.11 works ok with MacOS 12.1 (released on 13-Dec-2021). 8.6.12 also works with MacOS 12.1. I have not tested either extensively, however. -- nosy: +csatt ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36225] [subinterpreters] Lingering subinterpreters should be implicitly cleared on shutdown
Change by Chris Roberts : -- nosy: +nasageek ___ Python tracker <https://bugs.python.org/issue36225> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1653457] Python misbehaves when installed in / (patch attached)
Change by Chris Webb : Removed file: https://bugs.python.org/file17945/paths.patch ___ Python tracker <https://bugs.python.org/issue1653457> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1653457] Python misbehaves when installed in / (patch attached)
Chris Webb added the comment: Irit Katriel added the comment: > getpath.c has been rewritten (see Issue45582). reduce is no longer there. Gosh, this is one I originally reported back in the late 1990s and then again mid-2000s! I've carried a patch in my distribution to make python work in /bin and /lib/python for over 25 years - it'll feel like end of an era to finally be able to drop that local patch. Thanks! (Presumably this will land in Python 11 rather than get backported?) Best wishes, Chris. -- ___ Python tracker <https://bugs.python.org/issue1653457> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45664] resolve_bases() and new_class() do not work with type alias of a built-in type
Change by Chris Wesseling : -- nosy: -CharString, CharString ___ Python tracker <https://bugs.python.org/issue45664> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45796] Using tab to cycle through tkinter widgets breaks foreground styling
Chris Eykamp added the comment: If we decide that this is a tkinter bug (and that the Python part is working properly), does that mean that we close this ticket and rely on the upstream provider to fix the problem? I don't know how jurisdiction works with core libraries shipped with Python. -- ___ Python tracker <https://bugs.python.org/issue45796> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45796] Using tab to cycle through tkinter widgets breaks foreground styling
Chris Eykamp added the comment: Thanks for the clarification. I don't want to belabor the point, but if you observe what happens as you hit tab and cycle through the widgets, the way the color changes cannot be intended behavior, and makes no sense from any rational UI perspective. I do accept that it may not be a Python bug (though I don't really know); I do not understand the relationship between Python and Tcl in terms of who is responsible for what. But regardless, I filed a bug report at the URL you provided. I don't know if they accept documentation of problems written in Python, and I cannot write the code in Tcl, but we'll find out in a day or two (I hope). Thanks again! On Tue, Nov 16, 2021, at 13:35, E. Paine wrote: > E. Paine added the comment: > >> please don't declare this "not a bug" until you've tested it on Windows > > Sorry, I didn't explain my reasoning for that resolution. I did test it > on Windows, but my trail of though went something like: "unexpected > behaviour doesn't necessarily mean it's a bug". You are right, though, > and a resolution of "third party" would be more suitable. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue45796> > ___ -- ___ Python tracker <https://bugs.python.org/issue45796> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45796] Using tab to cycle through tkinter widgets breaks foreground styling
Chris Eykamp added the comment: The behavior I described is definitely a bug, though it may be (and I suspect is) Windows specific. You may also be right that the problem is upstream, but please don't declare this "not a bug" until you've tested it on Windows. -- nosy: +watusimoto2 ___ Python tracker <https://bugs.python.org/issue45796> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45796] Using tab to cycle through tkinter widgets breaks foreground styling
New submission from Chris Eykamp :
Attached is a slightly modifed example of the code sample in Bryan Oakley's
response to:
https://stackoverflow.com/questions/30337351/how-can-i-ensure-my-ttk-entrys-invalid-state-isnt-cleared-when-it-loses-focus
I have modified it by changing the style.map to change the widget's foreground
color (rather than background), and by adding a button below the text input.
Typing a string containing "invalid" into the textbox causes it to fail
validation (its state is shown in the bottom label, updated every second). As
expected, the foreground changes to red.
However, if I use [tab] to toggle between the elements, the foreground of the
text entry gets changed to black, even if the item is invalid.
Adding
style.map("TEntry", selectforeground=[('invalid', "green")])
creates a new set of weirdness, where the invalid text becomes green when
tabbing through the widgets.
I'm running on Windows 10, Python 3.83.
--
components: Tkinter
files: simple.py
messages: 406242
nosy: watusimoto
priority: normal
severity: normal
status: open
title: Using tab to cycle through tkinter widgets breaks foreground styling
versions: Python 3.8
Added file: https://bugs.python.org/file50437/simple.py
___
Python tracker
<https://bugs.python.org/issue45796>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45796] Using tab to cycle through tkinter widgets breaks foreground styling
Chris Eykamp added the comment: I'll add that when the red text incorrectly turns black, on my display, I can see a very subtle red halo, as if the text is being printed first as red, then as black in a second pass. -- ___ Python tracker <https://bugs.python.org/issue45796> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33927] Allow json.tool to have identical infile and outfile
Change by Chris Wesseling : -- nosy: +CharString nosy_count: 6.0 -> 7.0 pull_requests: +27728 pull_request: https://github.com/python/cpython/pull/29478 ___ Python tracker <https://bugs.python.org/issue33927> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45644] Make json.tool soak up input before opening output for writing
Change by Chris Wesseling : -- pull_requests: +27729 pull_request: https://github.com/python/cpython/pull/29478 ___ Python tracker <https://bugs.python.org/issue45644> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45644] Make json.tool soak up input before opening output for writing
Chris Wesseling added the comment: @Remi I left the current behaviour for --json-lines untouched, on purpose. My reasoning was that the json-lines format is often seen in JSON streaming, and I didn't want to break the case where the input is an endless stream from stdin or a named pipe. And to keep the patch simple with minimal change to the exposed interface. Simplest fix for the case in this current code would be: iff infile equals outfile (minding their types), call list(objs) on the generator[1] to materialise it in one go. The only case where that would break would be when infile == outfile and is a named pipe, but I can't imagine why I would want to both read and write to the same FIFO, other than comedic effect. [1] https://github.com/python/cpython/blob/122ca4d73faba279a579aa2011fa34661ce537a2/Lib/json/tool.py#L65 -- ___ Python tracker <https://bugs.python.org/issue45644> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45718] asyncio: MultiLoopWatcher has a race condition (Proposed work-around)
Chris Jerdonek added the comment: Since issue 38323 is still open, I think you should just comment on that instead of creating a new issue. -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue45718> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45664] resolve_bases() and new_class() do not work with type alias of a built-in type
Change by Chris Wesseling : -- pull_requests: +27577 pull_request: https://github.com/python/cpython/pull/29273 ___ Python tracker <https://bugs.python.org/issue45664> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45664] resolve_bases() and new_class() do not work with type alias of a built-in type
Change by Chris Wesseling : -- nosy: +CharString, CharString nosy_count: 4.0 -> 5.0 pull_requests: +27569, 27570 pull_request: https://github.com/python/cpython/pull/29273 ___ Python tracker <https://bugs.python.org/issue45664> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45664] resolve_bases() and new_class() do not work with type alias of a built-in type
Change by Chris Wesseling : -- nosy: +CharString nosy_count: 4.0 -> 5.0 pull_requests: +27569 pull_request: https://github.com/python/cpython/pull/29273 ___ Python tracker <https://bugs.python.org/issue45664> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45644] Make json.tool soak up input before opening output for writing
Change by Chris Wesseling : -- pull_requests: +27537 pull_request: https://github.com/python/cpython/pull/29273 ___ Python tracker <https://bugs.python.org/issue45644> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45644] Make json.tool soak up input before opening output for writing
Change by Chris Wesseling : -- keywords: +patch pull_requests: +27532 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29269 ___ Python tracker <https://bugs.python.org/issue45644> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45644] Make json.tool soak up input before opening output for writing
New submission from Chris Wesseling : json.tool is very cute and handy for making json readable. But rewriting a file in place requires tools like sponge (on POSIX) or a tmpfile, because $ python -m json.tool foo.json foo.json results in an empty foo.json. I propose soaking up the infile before opening the outfile for writing, to prevent that. Much like sort -o does, but without the explicit flag. The patch I have prepared changes no behaviours, other than preventing an empty file... (still I see this as an enhancement and not a bug fix) -- messages: 405182 nosy: CharString priority: normal severity: normal status: open title: Make json.tool soak up input before opening output for writing type: enhancement ___ Python tracker <https://bugs.python.org/issue45644> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44665] asyncio.create_task() documentation should mention user needs to keep reference to the task
Chris Meyer added the comment:
Is there a way to reproduce this issue? I run the following code in Python 3.9
and it works as expected (prints "xyz" twice).
import asyncio
import gc
async def xyz():
print("xyz")
event_loop = asyncio.get_event_loop()
event_loop.create_task(xyz())
t = event_loop.create_task(xyz())
del t
gc.collect()
event_loop.stop()
event_loop.run_forever()
--
nosy: +cmeyer
___
Python tracker
<https://bugs.python.org/issue44665>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45454] Unable to explicitly subclass protocol when subclass has mixin requiring init
Chris Meyer added the comment: This looks like it a regression specific to Python 3.9.7 and has been fixed. https://bugs.python.org/issue45081 https://github.com/python/cpython/pull/28132. -- resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue45454> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45454] Unable to explicitly subclass protocol when subclass has mixin requiring init
New submission from Chris Meyer : If I make a explicit subclass of a protocol that also inherits from a mixin and calls super() in order to initialize the mixin, I get the "Protocols cannot be instantiated" exception. This case arises when having a hierarchy of both protocols and concrete classes that implement the protocols. A simple example is: import typing class P(typing.Protocol): def m1(self) -> None: ... class M: def __init__(self) -> None: super().__init__() self.o = True class C(M, P): def __init__(self) -> None: super().__init__() self.op = True def m1(self) -> None: pass c = C() I can resolve this in particular cases by not invoking super in the mixin or putting a special no-super class in the hierarchy. However, that is not a general solution and once the class hierarchy gets more complicated, it fails to work. Am I missing any known solution to this issue? -- components: Library (Lib) messages: 403782 nosy: cmeyer priority: normal severity: normal status: open title: Unable to explicitly subclass protocol when subclass has mixin requiring init type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue45454> ___ ___ 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.
Chris Jerdonek added the comment:
Here's a simplification of Marco's snippet to focus the discussion.
import asyncio
async def job():
# raise RuntimeError('error!')
await asyncio.sleep(5)
async def main():
task = asyncio.create_task(job())
await asyncio.sleep(1)
task.cancel('cancel job')
await task
if __name__=="__main__":
asyncio.run(main())
Running this pre-Python 3.9 gives something like this--
Traceback (most recent call last):
File "test.py", line 15, in
asyncio.run(main())
File "/.../python3.7/asyncio/runners.py", line 43, in run
return loop.run_until_complete(main)
File "/.../python3.7/asyncio/base_events.py", line 579, in run_until_complete
return future.result()
concurrent.futures._base.CancelledError
Running this with Python 3.9+ gives something like the following. The
difference is that the traceback now starts at the sleep() call:
Traceback (most recent call last):
File "/.../test.py", line 6, in job
await asyncio.sleep(5)
File "/.../python3.9/asyncio/tasks.py", line 654, in sleep
return await future
asyncio.exceptions.CancelledError: cancel job
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/.../test.py", line 12, in main
await task
asyncio.exceptions.CancelledError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/.../test.py", line 15, in
asyncio.run(main())
File "/.../python3.9/asyncio/runners.py", line 44, in run
return loop.run_until_complete(main)
File "/.../python3.9/asyncio/base_events.py", line 642, in run_until_complete
return future.result()
asyncio.exceptions.CancelledError
Uncommenting the RuntimeError turns it into this--
Traceback (most recent call last):
File "/.../test.py", line 15, in
asyncio.run(main())
File "/.../python3.9/asyncio/runners.py", line 44, in run
return loop.run_until_complete(main)
File "/.../python3.9/asyncio/base_events.py", line 642, in run_until_complete
return future.result()
File "/.../test.py", line 12, in main
await task
File "/.../test.py", line 5, in job
raise RuntimeError('error!')
RuntimeError: error!
I agree it would be a lot nicer if the original CancelledError('cancel job')
could bubble up just like the RuntimeError does, instead of creating a new
CancelledError at each await and chaining it to the previous CancelledError.
asyncio's creation of a new CancelledError at each stage predates the PR that
added the chaining, so this could be viewed as an evolution of the change that
added the chaining.
I haven't checked to be sure, but the difference in behavior between
CancelledError and other exceptions might be explained by the following lines:
https://github.com/python/cpython/blob/3d1ca867ed0e3ae343166806f8ddd9739e568ab4/Lib/asyncio/tasks.py#L242-L250
You can see that for exceptions other than CancelledError, the exception is
propagated by calling super().set_exception(exc), whereas with CancelledError,
it is propagated by calling super().cancel() again.
Maybe this would even be an easy change to make. Instead of asyncio creating a
new CancelledError and chaining it to the previous, asyncio can just raise the
existing one. For the pure Python implementation at least, it may be as simple
as making a change here, inside _make_cancelled_error():
https://github.com/python/cpython/blob/3d1ca867ed0e3ae343166806f8ddd9739e568ab4/Lib/asyncio/futures.py#L135-L142
--
___
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
[issue45390] asyncio.Task doesn't propagate CancelledError() exception correctly.
Chris Jerdonek added the comment: I still don't see you calling asyncio.Task.exception() in your new attachment... -- ___ 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
[issue45390] asyncio.Task doesn't propagate CancelledError() exception correctly.
Chris Jerdonek added the comment: > 2) Now: if I re-raise the asyncio.CancelledError as-is, I lose the message, if I call the `asyncio.Task.exception()` function. Re-raise asyncio.CancelledError where? (And what do you mean by "re-raise"?) Call asyncio.Task.exception() where? This isn't part of your example, so it's not clear what you mean exactly. -- ___ 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
[issue45390] asyncio.Task doesn't propagate CancelledError() exception correctly.
Chris Jerdonek added the comment: > But, once the asyncio.Task is cancelled, is impossible to retrieve that > original asyncio.CancelledError(msg) exception with the message, because it > seems that *a new* asyncio.CancelledError() [without the message] is raised > when asyncio.Task.result() or asyncio.Task.exception() methods are called. You say it's "impossible", but isn't the message accessible via the exception chain (and visible in the traceback)? One benefit of not duplicating the message on the internal call to cancel() is that it makes it easier to pinpoint which CancelledError object is associated with the user's call to cancel(), and which is associated with the call done by asyncio internals, which is a different cancellation. Another benefit is that it prevents info from being duplicated in the traceback. -- nosy: +chris.jerdonek ___ 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
[issue45374] sqlite3: Add configure option to set or auto-detect rpath to sqlite3 libs
New submission from Chris Hills : Similar to https://bugs.python.org/issue43466 for openssl, please add a configure option to set rpath for sqlite3. --with-sqlite-rpath= Ideally, when any dpeendency is discovered with pkg-config, the correct rpath should be set, but this would be a breaking change. -- assignee: docs@python components: Documentation, Installation messages: 403214 nosy: chaz6, docs@python priority: normal severity: normal status: open title: sqlite3: Add configure option to set or auto-detect rpath to sqlite3 libs versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue45374> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45371] distutil's runtime_library_dir (rpath) option doesn't work with clang
Chris Hills added the comment: I tested this both with and without LDFLAGS="-Wl,-rpath -Wl,/home/chaz/.local/local/python3.10.0/lib", and in both cases this patch works as expected. Thank you! -- nosy: +chaz6 ___ Python tracker <https://bugs.python.org/issue45371> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43466] ssl/hashlib: Add configure option to set or auto-detect rpath to OpenSSL libs
Chris Hills added the comment:
If I set LDFLAGS as with previous versions, it works as expected. I do not know
if it is related, but I noticed that by default rpath does not get set for the
files in DESTDIR/bin/* (e.g. python3.10 or pip3.10) hence the inclusion of
/home/chaz/.local/local/python-${PYTHON_VERSION}/lib in the rpath.
LDFLAGS="-Wl,-rpath,'/home/chaz/.local/local/openssl3/lib64:/home/chaz/.local/local/sqlite3/lib:/home/chaz/.local/local/python-'${PYTHON_VERSION}'/lib'
-Wl,--enable-new-dtags"
--
___
Python tracker
<https://bugs.python.org/issue43466>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43466] ssl/hashlib: Add configure option to set or auto-detect rpath to OpenSSL libs
Chris Hills added the comment:
The new behaviour seems broken on my system.
$ PYTHON_VERSION=3.10.0
$
PKG_CONFIG_PATH="/home/chaz/.local/local/sqlite3/lib/pkgconfig:/home/chaz/.local/local/openssl3/lib64/pkgconfig"
$ LLVM_PROFDATA=/home/chaz/.local/local/clang+llvm/bin/llvm-profdata CC=clang
CXX=clang++ ./configure
--prefix=/home/chaz/.local/local/python-${PYTHON_VERSION}
--enable-optimizations --enable-shared --enable-loadable-sqlite-extensions
--with-openssl-rpath=auto
[..]
building '_ssl' extension
clang -pthread -fPIC -Wno-unused-result -Wsign-compare -Wunreachable-code
-DNDEBUG -g -fwrapv -O3 -Wall -std=c99 -Wextra -Wno-unused-result
-Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes
-Werror=implicit-function-declaration -fvisibility=hidden
-fprofile-instr-use=code.profclangd -I./Include/internal
-I/home/chaz/.local/local/openssl-3.0.0/include -I./Include -I.
-I/usr/local/include -I/home/chaz/Downloads/Python-3.10.0/Include
-I/home/chaz/Downloads/Python-3.10.0 -c
/home/chaz/Downloads/Python-3.10.0/Modules/_ssl.c -o
build/temp.linux-x86_64-3.10/home/chaz/Downloads/Python-3.10.0/Modules/_ssl.o
warning: no profile data available for file "_ssl.c"
[-Wprofile-instr-unprofiled]
clang -pthread -shared
build/temp.linux-x86_64-3.10/home/chaz/Downloads/Python-3.10.0/Modules/_ssl.o
-L/home/chaz/.local/local/openssl-3.0.0/lib64 -L. -L/usr/local/lib
-R/home/chaz/.local/local/openssl-3.0.0/lib64 -lssl -lcrypto -o
build/lib.linux-x86_64-3.10/_ssl.cpython-310-x86_64-linux-gnu.so
clang -pthread -fPIC -Wno-unused-result -Wsign-compare -Wunreachable-code
-DNDEBUG -g -fwrapv -O3 -Wall -std=c99 -Wextra -Wno-unused-result
-Wno-unused-parameter -Wno-missing-field-initializers -Wstrict-prototypes
-Werror=implicit-function-declaration -fvisibility=hidden
-fprofile-instr-use=code.profclangd -I./Include/internal
-I/home/chaz/.local/local/openssl-3.0.0/include -I./Include -I.
-I/usr/local/include -I/home/chaz/Downloads/Python-3.10.0/Include
-I/home/chaz/Downloads/Python-3.10.0 -c
/home/chaz/Downloads/Python-3.10.0/Modules/_hashopenssl.c -o
build/temp.linux-x86_64-3.10/home/chaz/Downloads/Python-3.10.0/Modules/_hashopenssl.o
warning: no profile data available for file "_hashopenssl.c"
[-Wprofile-instr-unprofiled]
clang -pthread -shared
build/temp.linux-x86_64-3.10/home/chaz/Downloads/Python-3.10.0/Modules/_hashopenssl.o
-L/home/chaz/.local/local/openssl-3.0.0/lib64 -L. -L/usr/local/lib
-R/home/chaz/.local/local/openssl-3.0.0/lib64 -lssl -lcrypto -o
build/lib.linux-x86_64-3.10/_hashlib.cpython-310-x86_64-linux-gnu.so
*** WARNING: renaming "_ssl" since importing it failed: libssl.so.3: cannot
open shared object file: No such file or directory
*** WARNING: renaming "_hashlib" since importing it failed: libssl.so.3: cannot
open shared object file: No such file or directory
$ ldd
/home/chaz/Downloads/Python-3.10.0/build/lib.linux-x86_64-3.10/_ssl.cpython-310-x86_64-linux-gnu_failed.so
linux-vdso.so.1 => (0x7fffc99f4000)
libssl.so.3 => not found
libcrypto.so.3 => not found
libpthread.so.0 => /lib64/libpthread.so.0 (0x7faa70802000)
libc.so.6 => /lib64/libc.so.6 (0x7faa70434000)
/lib64/ld-linux-x86-64.so.2 (0x7faa70a1e000)
$ readelf -d
/home/chaz/Downloads/Python-3.10.0/build/lib.linux-x86_64-3.10/_ssl.cpython-310-x86_64-linux-gnu_failed.so
| grep PATH
It appears that RPATH/RUNPATH is not getting set.
--
nosy: +chaz6
___
Python tracker
<https://bugs.python.org/issue43466>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45075] confusion between frame and frame_summary in traceback module
Chris Jerdonek added the comment: Or frame_info (more readable), since FrameSummary is proposed to be "Information about a single frame from a traceback." -- ___ Python tracker <https://bugs.python.org/issue45075> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45075] confusion between frame and frame_summary in traceback module
Chris Jerdonek added the comment: I was suggesting keeping more similarity between FrameSummary and StackSummary in addition to differentiating frame from FrameSummary. Since stack is used for StackSummary, frame_sum is more similar than f_summary while still providing the differentiation. -- ___ Python tracker <https://bugs.python.org/issue45075> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45075] confusion between frame and frame_summary in traceback module
Chris Jerdonek added the comment: It might be good to have consistency with what will be used for StackSummary so two different approaches to naming aren't used. By the way, frame_sum is another possibility since I see frame_gen being used. -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue45075> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44938] Expose PyErr_ChainExceptions in the stable API
Chris Jerdonek added the comment: I agree with Serhiy that this API isn't necessarily the right one. It's just what happens to be there now. Also, we're still not clear on our stance towards cycles (see the issue25782 discussion). (Maybe the exposed version should result in an error if it would cause a cycle to be created.) Someone would need to think through what the API should be, though. -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue44938> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44895] refleak test failure in test_exceptions
Chris Jerdonek added the comment: FYI, I tried myself, and setting PYTHONHASHSEED didn't make the failures deterministic. -- ___ Python tracker <https://bugs.python.org/issue44895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44895] refleak test failure in test_exceptions
Chris Jerdonek added the comment: Last question: might trying different values of PYTHONHASHSEED help? -- ___ Python tracker <https://bugs.python.org/issue44895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44895] refleak test failure in test_exceptions
Chris Jerdonek added the comment: "How does this explain it not being non-deterministic on" -> "How does this explain it not being deterministic on" -- ___ Python tracker <https://bugs.python.org/issue44895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44895] refleak test failure in test_exceptions
Chris Jerdonek added the comment: > Maybe it's a very precise threshold which triggers the issue. Between Linux > and macOS, the site module executes different code paths which produce > different GC counters. > Sometimes, the GC must happen in a very precise line, one line later is too > late. How does this explain it not being non-deterministic on, say, macOS since the same lines of code will be executing each time? Is there a way to force things to happen in a deterministic fashion? (I interpreted the responses to mean that it's non-deterministic even when run on the same machine, so I'm not talking about, say, the differences from running macOS on different machines.) -- ___ Python tracker <https://bugs.python.org/issue44895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44895] refleak test failure in test_exceptions
Chris Jerdonek added the comment: Out of curiosity, is the failure deterministic in environments where it fails? If not, what is the source of the indeterminism -- some kind of race condition or something else? -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue44895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25782] CPython hangs on error __context__ set to the error itself
Chris Jerdonek added the comment: > Preventing creation of the loop will fix all other code that iterate the > __context__ chain. We can still do / discuss that following Irit's proposed change, which is an improvement, IMO. -- ___ Python tracker <https://bugs.python.org/issue25782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40696] Exception handling with "await" can hang in Python3.9.0b1
Chris Jerdonek added the comment: Okay, I'll close the issue and update it to reflect that it was restricted to the narrower, originally reported issue. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed title: exception chain cycles cause hangs (was "Exception handling with "await" can hang in Python3.9.0b1") -> Exception handling with "await" can hang in Python3.9.0b1 ___ Python tracker <https://bugs.python.org/issue40696> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25782] CPython hangs on error __context__ set to the error itself
Chris Jerdonek added the comment: > No, I meant C -> A -> B -> C -> A Oh, good. I support your reasoning and approach, by the way. -- ___ Python tracker <https://bugs.python.org/issue25782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25782] CPython hangs on error __context__ set to the error itself
Chris Jerdonek added the comment: > the result is C -> A -> B -> C Did you mean C -> A -> B? By the way, if you applied to this example your reasoning that PyErr_SetObject shouldn't try to fix user bugs, should this example instead be C -> A -> B -> C -> ... (leaving the cycle as is but just not hanging)? Is it not being changed then because the reasoning doesn't apply, or because we're restricted in what we can do by backwards compatibility? -- ___ Python tracker <https://bugs.python.org/issue25782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25782] CPython hangs on error __context__ set to the error itself
Chris Jerdonek added the comment: That's okay. I didn't mean to suggest I thought your patch needed to handle that case or that we needed to decide it before moving forward. I was just wondering what would happen with your patch with it, even if it means a hang. Or were you saying that example can't arise in the code path you're modifying? -- ___ Python tracker <https://bugs.python.org/issue25782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25782] CPython hangs on error __context__ set to the error itself
Chris Jerdonek added the comment: Yes, that seems like a good approach. And how about with Serhiy's example from above? > If there is a chain A -> B -> C -> D -> E, after assignment C.__context__ = A > ... -- ___ Python tracker <https://bugs.python.org/issue25782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25782] CPython hangs on error __context__ set to the error itself
Chris Jerdonek added the comment: Thanks, Irit. Can you show how your patch behaves using some representative examples (maybe using arrow examples from above)? And if it behaves differently from Dennis's patch, can you include an example showing that, too? -- ___ Python tracker <https://bugs.python.org/issue25782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44534] unittest.mock.Mock.unsafe doc is garbled
Chris Withers added the comment: New changeset abb08e3af6aa19928007a349592e95e6de38467f by Jack DeVries in branch 'main': bpo-44534: fix wording and docstring sync in unittest.Mock GH27000 https://github.com/python/cpython/commit/abb08e3af6aa19928007a349592e95e6de38467f -- nosy: +cjw296 ___ Python tracker <https://bugs.python.org/issue44534> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44485] TKinter docs page does not provide actual documentation
Chris Trent added the comment: To put it bluntly, having me submit patches to that section of the docs is just about the last thing you want. I know precious little about TKinter, which is precisely why I'm calling for something more than a half-assed tutorial. Regarding using the TCL/TK docs, not happening. I don't have the time nor patience to learn a dead scripting language just to read docs, if I wanted to do that, I'd learn Javascript. -- ___ Python tracker <https://bugs.python.org/issue44485> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44485] TKinter docs page does not provide actual documentation
Change by Chris Trent : -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue44485> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44485] TKinter docs page does not provide actual documentation
New submission from Chris Trent : The documentation pages for the tkinter module are not actually documentation. They are tutorials, which belong on the wiki. "Documentation" is not documentation if it does not provide at bare minimum a structured list of all names exposed by the module's public interface. Python's official docs should be the sole authoritative source for full, complete, useful documentation of everything one could need to know about a module, but instead, We're forced to go to 3rd party sites of dubious provenance and questionable accuracy, instead of being able to just go to the source, and find a page to, I don't know, find out what kinds of panels we have to work with. -- assignee: docs@python components: Documentation messages: 396313 nosy: arkevorkhat, docs@python priority: normal severity: normal status: open title: TKinter docs page does not provide actual documentation versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue44485> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44463] HTTP Cookiejar doesn't support samesite
New submission from Chris Wagner : In 3.8 the samesite attributes was added to http.cookies module. However it hasn't been added to http.cookiejar module. The method: _normalized_cookie_tuples seems to have a hardcoded list of allowable attributes. While the updated standard is still in draft stage (https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/) samesite is widely implemented and used (Chrome added support in 2017). -- components: Library (Lib) messages: 396153 nosy: jwag956 priority: normal severity: normal status: open title: HTTP Cookiejar doesn't support samesite type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue44463> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38323] asyncio: MultiLoopWatcher has a race condition (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)
Chris Jerdonek added the comment: > MultiLoopChildWatcher must ensures that the event loop is awaken when it > receives a signal by using signal.setwakeup(). This is done by > _UnixSelectorEventLoop.add_signal_handler(). Maybe MultiLoopChildWatcher > could reuse this function, This is the conclusion I came to, too. But changing MultiLoopChildWatcher to use loop.add_signal_handler() would contradict the class's documented purpose and make it the same as SafeChildWatcher. This is why I think a maintainer needs to weigh in. The class's purpose / design might fundamentally not be workable. If it can't be made to work, maybe it should be removed or be documented as susceptible to hangs. -- ___ Python tracker <https://bugs.python.org/issue38323> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38323] asyncio: MultiLoopWatcher has a race condition (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)
Chris Jerdonek added the comment: > This issue is not solved. Yes, nothing was changed. After diagnosing this issue and trying some things out in a draft PR, my conclusion is that an asyncio maintainer really needs to weigh in on what to do (especially Andrew who authored the class). The reason is that the hang is closely tied to MultiLoopChildWatcher's documented purpose. The only way I could see to fix MultiLoopChildWatcher would change its documented behavior and make it the same as SafeChildWatcher, which would defeat the purpose of having a separate class: https://github.com/python/cpython/pull/20142#issuecomment-712417912 Maybe there is a way to sidestep the hangs in the tests without fixing MultiLoopChildWatcher, but I didn't look into that. -- ___ Python tracker <https://bugs.python.org/issue38323> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44314] [doc] SSLContext.set_ciphers() link to OpenSSL cipher list format is outdated
New submission from Chris Mayo : Current link is: https://www.openssl.org/docs/manmaster/man1/ciphers.html Manual page entries without the 'openssl-' prefix have been deprecated, and this link is now directed to a generic page for openssl cmd. Suggest an update to: https://www.openssl.org/docs/manmaster/man1/openssl-ciphers.html#CIPHER-LIST-FORMAT Currently at: https://github.com/python/cpython/blame/main/Doc/library/ssl.rst#L1680 -- assignee: docs@python components: Documentation messages: 395108 nosy: cjmayo, docs@python priority: normal severity: normal status: open title: [doc] SSLContext.set_ciphers() link to OpenSSL cipher list format is outdated versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue44314> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44112] [buildbot] test_asyncio hangs (killed after 3 hours) on Refleak buildbots
Change by Chris Jerdonek : -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue44112> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44205] shutil.copystat can fail when copying to a file system with a smaller limit
Change by Chris Burr : -- keywords: +patch pull_requests: +24888 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26282 ___ Python tracker <https://bugs.python.org/issue44205> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44205] shutil.copystat can fail when copying to a file system with a smaller limit
New submission from Chris Burr :
When copying files between systems with different limits on the size of the
extended attributes that can be added to a file shutil.copystat can fail with:
/cvmfs/lhcb.cern.ch/lib/var/lib/LbEnv/2064/stable/linux-64/lib/python3.8/shutil.py
in copystat(src, dst, follow_symlinks)
377 # We must copy extended attributes before the file is (potentially)
378 # chmod()'ed read-only, otherwise setxattr() will error with
-EACCES.
--> 379 _copyxattr(src, dst, follow_symlinks=follow)
380 try:
381 lookup("chmod")(dst, mode, follow_symlinks=follow)
/cvmfs/lhcb.cern.ch/lib/var/lib/LbEnv/2064/stable/linux-64/lib/python3.8/shutil.py
in _copyxattr(src, dst, follow_symlinks)
327 try:
328 value = os.getxattr(src, name,
follow_symlinks=follow_symlinks)
--> 329 os.setxattr(dst, name, value,
follow_symlinks=follow_symlinks)
330 except OSError as e:
331 if e.errno not in (errno.EPERM, errno.ENOTSUP,
errno.ENODATA,
OSError: [Errno 28] No space left on device: '/tmp/lhcb'
This is caused by the destination filesystem having a smaller limit on the size
of the extended attributes. I think this behaviour is unexpected as other
failures are silently ignored (e.g. the destination doesn't support extended
attributes).
--
components: Library (Lib)
messages: 394118
nosy: chrisburr
priority: normal
severity: normal
status: open
title: shutil.copystat can fail when copying to a file system with a smaller
limit
type: crash
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python
3.9
___
Python tracker
<https://bugs.python.org/issue44205>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42627] urllib.request.getproxies() misparses Windows registry proxy settings
Chris Xiao added the comment: I found this problem too. expecting for fixing -- nosy: +chrisxiao ___ Python tracker <https://bugs.python.org/issue42627> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43837] Operator precedence documentation could be more clear
Chris Jerdonek added the comment: > So maybe we should change the terminology while we’re at it. When math is taught to elementary school students in the US, it's called "order of operations": https://en.wikipedia.org/wiki/Order_of_operations Since this was raised in the context of newcomers to coding, it might be worth mentioning that parallel. Being able to connect to the familiar concepts of "first" and "last" might help people not familiar with precedence and binding. -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue43837> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37712] Exception frames from unittest.TestCase.fail dependent on nesting
Chris Jerdonek added the comment: > I think this is the same as issue37712. This issue was first reported as issue24959. It would be better to close the newer issues as duplicates of the first one, instead of keeping all the duplicates open. Otherwise, the history and discussion gets fragmented across multiple locations. -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue37712> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43614] Search is not beginner friendly
Change by Chris Angelico : -- keywords: +patch nosy: +Rosuav nosy_count: 5.0 -> 6.0 pull_requests: +23797 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25045 ___ Python tracker <https://bugs.python.org/issue43614> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43433] xmlrpc.client ignores query in URI ("?action=xmlrpc2") since python-3.9
Chris Angelico added the comment: Can confirm. This changed in bpo-38038 and the fix isn't too difficult. Adding 3.10 in case it's decided that this shouldn't be patched onto 3.9. -- versions: +Python 3.10 ___ Python tracker <https://bugs.python.org/issue43433> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43433] xmlrpc.client ignores query in URI ("?action=xmlrpc2") since python-3.9
Change by Chris Angelico : -- keywords: +patch nosy: +Rosuav nosy_count: 3.0 -> 4.0 pull_requests: +23793 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25045 ___ Python tracker <https://bugs.python.org/issue43433> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43481] PyEval_EvalCode() namespace issue not observed in Python 2.7.
Chris Morton added the comment: Is this change in behavior considered to be by design or is this issue an unintended consequence? It seems inconsistent that comprehensions have no visibility of variable previously defined in the same scoping for this particular use-case. Is there a way to work around this other than reworking the comprehension? It seems odd that [ci for ci in c] does not produce the error but [c for i in [1]] does produce the error. -- ___ Python tracker <https://bugs.python.org/issue43481> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43481] PyEval_EvalCode() namespace issue not observed in Python 2.7.
Chris Morton added the comment:
Hi Terry, The reason why your code does not reproduce the issue is because you
first execute the code in a global context which then puts the definition of c
in that context. Subsequent calling in the local context then works. If you
remove the first exec call (no need for the Class lines either), you will now
see the issue in 3.8.
This issue is reproducible for other containers such as lists and sets, instead
of dictionary, in this case. Replacing range(len(c)) with range(4) also shows
the same error. The error relates to the use of the indexing operator []. The
same error is observed with other sequences such as:
c={1,2,3,4}
or
c='1234'
--
___
Python tracker
<https://bugs.python.org/issue43481>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43566] Docs say int('010', 0) is not legal, but it is
Chris Wilson added the comment: Actually, octal is not a legal literal in Python 3, sorry. -- resolution: -> rejected ___ Python tracker <https://bugs.python.org/issue43566> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43566] Docs say int('010', 0) is not legal, but it is
New submission from Chris Wilson :
The documentation for the int() builtin says:
Base 0 means to interpret exactly as a code literal, so that the actual base is
2, 8, 10, or 16, and so that int('010', 0) is not legal, while int('010') is,
as well as int('010', 8).
https://docs.python.org/3/library/functions.html#int
However 010 is a valid code literal, and int('010', 0) is legal (both are
correctly interpreted as octal).
--
assignee: docs@python
components: Documentation
messages: 389145
nosy: docs@python, wilscm
priority: normal
severity: normal
status: open
title: Docs say int('010', 0) is not legal, but it is
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue43566>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43534] turtle.textinput window is not transient
New submission from Chris Winkler : When `turtle.textinput` is called in Python 3.9.2, the resulting dialog window is not marked as transient. This is not a problem in 3.9.1. The offending change seems to come from bpo-42630. Specifically, `SimpleDialog.__init__` is being passed `parent=None`, and because of this `self.transient(parent)` is not being called. A minimal program to reproduce the bug is attached. I'm happy to submit a pull request or something if it would help, but I don't know whether it's more correct to replace `parent` with `master` in the aforementioned if statement or something else. -- components: Tkinter files: textinput_test.py messages: 388980 nosy: quid256 priority: normal severity: normal status: open title: turtle.textinput window is not transient type: behavior versions: Python 3.9 Added file: https://bugs.python.org/file49885/textinput_test.py ___ Python tracker <https://bugs.python.org/issue43534> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43481] PyEval_EvalCode() namespace issue not observed in Python 2.7.
Chris Morton added the comment: Root cause appears to be indexing c with [] operator. Replacing len(c) with 4 produces the same error. -- ___ Python tracker <https://bugs.python.org/issue43481> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43478] Disallow Mock spec arguments from being Mocks
Chris Withers added the comment: I agree that this should raise an exception. Can the two failing tests in mock's own suite be easily fixed? -- ___ Python tracker <https://bugs.python.org/issue43478> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43482] Py_AddPendingCall Inserted Function Never Called in 3.8, works in 3.6
Change by Chris Morton : -- title: Py_AddPendingCall Function Never Called in 3.8, works in 3.6 -> Py_AddPendingCall Inserted Function Never Called in 3.8, works in 3.6 ___ Python tracker <https://bugs.python.org/issue43482> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43482] Py_AddPendingCall Function Never Called in 3.8, works in 3.6
Chris Morton added the comment: I should add that Py_AddPendingCall returns 0 in both cases. -- title: PyAddPendingCall Function Never Called in 3.8, works in 3.6 -> Py_AddPendingCall Function Never Called in 3.8, works in 3.6 type: -> behavior ___ Python tracker <https://bugs.python.org/issue43482> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43482] PyAddPendingCall Function Never Called in 3.8, works in 3.6
New submission from Chris Morton :
Building code on Mac OSX or Linux Ubuntu 16.04
#include
#include
#include
#include
// MacOSX build:
// g++ stop.cpp -I /include/pythonX.X -L /lib
-lpythonX.X -o stop
// Linuxe requires addtional linkage:
// -lpthread
void RunPythonScript()
{
PyRun_SimpleString("# import sys \n"
"import time \n"
"# sys.setcheckinterval(-1) \n"
"while True: \n"
"print('Running!') \n"
"time.sleep(1) \n"
);
std::cout << "Terminating Python Interpreter." << std::endl;
}
int Stop(void *)
{
std::cout << "We threw an exception." <", line 6, in
RuntimeError: Stop Python Execution.
Terminating Python Interpreter.
Exiting Main Function.
The Stop function is never called with the same code linked against Python 3.8.
--
components: C API
messages: 388559
nosy: chrisgmorton
priority: normal
severity: normal
status: open
title: PyAddPendingCall Function Never Called in 3.8, works in 3.6
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue43482>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43481] PyEval_EvalCode() namespace issue not observed in Python 2.7.
New submission from Chris Morton :
Compiling (Window 10, MSVS 16):
#include
int main(int argc, char* argv[])
{
const char* code = "c=[1,2,3,4]\nd={'list': [c[i] for i in
range(len(c))]}\nprint(d)\n";
Py_Initialize();
PyObject* pycode = Py_CompileString(code, "", Py_file_input );
PyObject* main_module = PyImport_AddModule("__main__");
PyObject* global_dict = PyModule_GetDict(main_module);
PyObject* local_dict = PyDict_New();
PyEval_EvalCode(pycode, global_dict, local_dict); // (PyCodeObject*)
pycode in Python 2.7
Py_Finalize();
return 0;
and executing yields:
Traceback (most recent call last):
File "", line 2, in
File "", line 2, in
NameError: name 'c' is not defined
While not particularly clever python code, it is not clear why the reference c
is not in scope having previously been defined. Replacing the clumsy list
comprehension using range() with c[:] or [ci for ci in c] produces the expected
result:
{'list': [1, 2, 3, 4]}
This issue is not observed with Python 2.7 (.18).
--
components: C API
messages: 388557
nosy: chrisgmorton
priority: normal
severity: normal
status: open
title: PyEval_EvalCode() namespace issue not observed in Python 2.7.
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue43481>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43423] Subprocess IndexError possible in _communicate
Change by Chris Griffith : -- keywords: +patch pull_requests: +23542 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24777 ___ Python tracker <https://bugs.python.org/issue43423> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43423] Subprocess IndexError possible in _communicate
New submission from Chris Griffith : It is possible to run into an IndexError in the subprocess module's _communicate function. ``` return run( File "subprocess.py", line 491, in run File "subprocess.py", line 1024, in communicate File "subprocess.py", line 1418, in _communicate IndexError: list index out of range ``` The lines in question are: ``` if stdout is not None: stdout = stdout[0] if stderr is not None: stderr = stderr[0] ``` I believe this is due to the fact there is no safety checking to make sure that self._stdout_buff and self._stderr_buff have any content in them after being set to empty lists. The fix I suggest is to change the checks from `if stdout is not None` to simply `if stdout` to make sure it is a populated list. Example fixed code: ``` if stdout: stdout = stdout[0] if stderr: stderr = stderr[0] ``` If a more stringent check is required, we could expand that out to check type and length, such as `isinstance(stdout, list) and len(stdout) > 0:` but that is more then necessary currently. -- components: Library (Lib) messages: 388211 nosy: cdgriffith priority: normal severity: normal status: open title: Subprocess IndexError possible in _communicate type: crash versions: Python 3.10, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43423> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31212] datetime: min date (0001-01-01 00:00:00) can't be converted to local timestamp
Change by Chris Jerdonek : -- nosy: +chris.jerdonek ___ Python tracker <https://bugs.python.org/issue31212> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3722] print followed by exception eats print with doctest
Change by Chris Withers : -- keywords: -easy ___ Python tracker <https://bugs.python.org/issue3722> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3722] print followed by exception eats print with doctest
Chris Withers added the comment: @iritkatriel - if Tim thinks this is hard, it probably is hard ;-) -- ___ Python tracker <https://bugs.python.org/issue3722> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42674] __init_subclass__ only called for first subclass when class has multiple inheritance
Change by Chris Gahagan : -- files: SubClass.py nosy: ccgahagan priority: normal severity: normal status: open title: __init_subclass__ only called for first subclass when class has multiple inheritance type: behavior versions: Python 3.8 Added file: https://bugs.python.org/file49691/SubClass.py ___ Python tracker <https://bugs.python.org/issue42674> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42532] spec_arg's __bool__ is called while initializing NonCallableMock
Chris Withers added the comment: New changeset c598a04dd29b89ad072245ddaf738badcfb41ac7 by idanw206 in branch 'master': bpo-42532: Check if NonCallableMock's spec_arg is not None instead of call its __bool__ function (GH23613) https://github.com/python/cpython/commit/c598a04dd29b89ad072245ddaf738badcfb41ac7 -- ___ Python tracker <https://bugs.python.org/issue42532> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42472] security hole in eval()
Chris Drake added the comment: The specification specifically allows for the restriction of access to globals via the second argument to eval. While Christian and Victor make interesting, albeit suicidal, comments and references to other efforts, the fact remains that this is a violation of the standard, and is an exploitable security issue. It's worth noting that the 1980's are long over now - people take security seriously these days, even when it's inconvenient. The fix seems ridiculously trivial for what it's worth; introduce a flag that honors the intent of the second argument. -- ___ Python tracker <https://bugs.python.org/issue42472> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42472] security hole in eval()
New submission from Chris Drake :
This should not work:-
python3.7 -c
'print(eval("().__class__.__base__.__subclasses__()[-1].__init__.__globals__",{"__builtins__":
{}},{"__builtins__": {}}))'
and should be properly fixed.
--
messages: 381892
nosy: cryptophoto
priority: normal
severity: normal
status: open
title: security hole in eval()
type: security
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue42472>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42429] Behavior of general (%g, :g) formatting inconsistent for decimal.Decimal
New submission from Chris Warrick :
When formatting decimal.Decimal using old-style formatting (%g), the output is
as short as possible, as expected. When using new-style formatting (str.format
or f-strings), the output uses the input precision. Floats behave correctly
with new-style formatting.
Python 3.9.0 (default, Oct 27 2020, 14:15:17)
[Clang 12.0.0 (clang-1200.0.32.21)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import decimal
>>> d1 = decimal.Decimal("1.000")
>>> d2 = decimal.Decimal("1.500")
>>> f1 = 1.0
>>> f2 = 1.5
>>> f"{d1:g} {f1:g}"
'1.000 1'
>>> f"{d2:g} {f2:g}"
'1.500 1.5'
>>> "%g %g" % (d1, f1)
'1 1'
>>> "%g %g" % (d2, f2)
'1.5 1.5'
--
components: Library (Lib)
messages: 381578
nosy: Kwpolska
priority: normal
severity: normal
status: open
title: Behavior of general (%g, :g) formatting inconsistent for decimal.Decimal
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue42429>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42260] [C API] Add PyInterpreterState_SetConfig(): reconfigure an interpreter
Chris Meyer added the comment: >> I would like to request that this ability to dynamically load Python DLLs >> remains even with any new initialization mechanism. > I don't plan to remove any feature :-) I am glad to hear that. I'm somewhat nervous about it nevertheless. In particular, the implementation of Py_DECREF changed from 3.7 to 3.8 to 3.9. 3.7 worked entirely in a header; but 3.8 had a quirky definition of _Py_Dealloc which used _Py_Dealloc_inline but was defined out of order (used before defined). This was somewhat addressed in https://github.com/python/cpython/pull/18361/files; however 3.9 now has another mechanism that defines _Py_Dealloc in Objects/object.c. This isn't a major problem because it has the same implementation as before, but changes like this have the potential to make the launcher binary be version specific. Again, not a deal breaker, but it still makes me nervous. -- ___ Python tracker <https://bugs.python.org/issue42260> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42260] [C API] Add PyInterpreterState_SetConfig(): reconfigure an interpreter
Chris Meyer added the comment: > How do you configure sys.path currently? Do you parse a configuration file? > Do you use a registry key on Windows? We have several launch scenarios - but for the currently most common one, which is to launch using a separate, existing Python environment, we call Py_SetPythonHome and Py_SetPath with the home directory of the environment. Then, presumably, the more complete path gets set in either Py_Initialize or when we call PyImport_ImportModule(“sys”). I might have tracked the details down once, but I don't recall them. By the time our Python code starts running, sys.path is reasonably populated. However, in another scenario, we launch with an embedded Python environment, essentially a virtual environment. In that case, we have a config file to explicitly add lib, DLLs, and site packages. But something goes wrong [cannot find/load the unicode DLL IIRC] unless we call site.addsitedir for each directory already in sys.path near the start of our Python portion of code. My notes point to two issues to explain this: https://bugs.python.org/issue22213 and https://bugs.python.org/issue35706. -- ___ Python tracker <https://bugs.python.org/issue42260> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42260] [C API] Add PyInterpreterState_SetConfig(): reconfigure an interpreter
Chris Meyer added the comment: Responding to your request for feedback on Python-Dev: We embed Python dynamically by finding the libPython DLL, loading it, and looking up the required symbols. We make appropriate define's so that the Python headers (and NumPy headers) point to our functions which in turn point to the looked up symbols. Our launcher works on Linux, macOS, and Windows and works with many environments including standard Python and conda and brew. It also supports virtual environments in most cases. Also, a single executable [per platform] is able to work with Python versions 3.7 - 3.9 (3.6 was recently dropped, but only for external reasons). So my comment is not directly addressing the usefulness of configuring Python initialization - but I would like to request that this ability to dynamically load Python DLLs remains even with any new initialization mechanism. As another note, the main issues we run into are configuring the Python path to properly find packages and DLLs. A goal of ours is to be able to provide the base application as a drag-and-drop style installer with its own full embedded Python distribution (but still loaded dynamically) and then be able to supply additional plug-in packages (Python packages) by drag and drop. This is somewhat similar to conda packaging but without support for command line tools. -- nosy: +cmeyer ___ Python tracker <https://bugs.python.org/issue42260> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42153] doc: library imaplib a url not available
Chris Xiao added the comment: maybe，you can try to contact the webmaster of the University of Washington to get the correct url -- ___ Python tracker <https://bugs.python.org/issue42153> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
