[issue39960] Using typename.__setattr__ in extension type with Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)
Change by David Caro : -- nosy: +David Caro nosy_count: 5.0 -> 6.0 pull_requests: +20618 pull_request: https://github.com/python/cpython/pull/21473 ___ Python tracker <https://bugs.python.org/issue39960> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41295] CPython 3.8.4 regression on __setattr__ in multiinheritance with metaclasses
David Lord added the comment: It appears to be solved in Flask-SQLAlchemy's development version already, as the mixins now inherit from `type`. We caught the issue when we started applying flake8 (possibly through flake8-bugbear). -- nosy: +davidism ___ Python tracker <https://bugs.python.org/issue41295> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39959] Bug on multiprocessing.shared_memory
David Parks added the comment: Having a flag seems like a good solution to me. I've also encountered this issue and posted on stack overflow about it here: https://stackoverflow.com/questions/62748654/python-3-8-shared-memory-resource-tracker-producing-unexpected-warnings-at-appli -- nosy: +davidparks21 ___ Python tracker <https://bugs.python.org/issue39959> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41145] EmailMessage.as_string is altering the message state and actually fix bugs
R. David Murray added the comment: The as_strings docs say: "Flattening the message may trigger changes to the Message if defaults need to be filled in to complete the transformation to a string (for example, MIME boundaries may be generated or modified)." So, while this is indeed an API design bug, it isn't an actual bug in the code but rather is expected behavior, currently. The historical reason for this is that the generator code looks at the entire message to make sure the boundary string is unique. My long term plan for email included plans to rewrite the generator, and I was going to fix this issue at that point. My life got too busy to be able to continue with email development work, though, so that never happened. It has been *years* since I've looked at the code. Thinking about it now, I'm wondering if it would be possible to use a GUID technique to generate the boundary and thus do exactly as you say: have make_alternative (and anything else that causes a boundary to be needed) pre-create the boundary. That, I think, would mean we wouldn't need to change the generator, even though it would still be doing its (inefficient) check that the boundary was unique. I'm not sure if it would work, though; it's been too long since I've looked at the relevant code. -- type: resource usage -> behavior ___ Python tracker <https://bugs.python.org/issue41145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40360] Deprecate lib2to3 (and 2to3) for future removal
David Halter added the comment: I'm the maintainer of parso. Feel free to addd me to the Nosy List if we have these discussions in the future. Parso is indeed a lib2to3 fork with error recovery, round tripping and incremental parsing as its features. Most pgen2 code has been rewritten since for various reasons, but it's essentially still LL(1). We're currently trying to think how to proceed with Non-LL(1). For very simple cases a few hacks could suffice, but for larger stuff we will probably need to implement some form of PEG parsing. I'm mostly worried about incremental parsing breaking if we replace the PEG parser, not about writing the PEG parser. But I guess we'll find a way, because I don't want to abandon Jedi (which depends on parso). -- nosy: +davidhalter ___ Python tracker <https://bugs.python.org/issue40360> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41231] Type annotations lost when using wraps by default
David Caro added the comment: Elaborating on the last message, given the following code: ``` 1 #!/usr/bin/env python3 2 3 from functools import wraps 4 5 6 def return_string(wrapped): 7 @wraps(wrapped) 8 def wrapper(an_int: int) -> str: 9 return str(wrapped(an_int)) 10 11 return wrapper 12 13 14 @return_string 15 def identity(an_int: int) -> int: 16 return an_int 17 18 def print_bool(a_bool: bool) -> None: 19 print(a_bool) 20 21 def identity_nonwrapped(an_int: int) -> int: 22 return an_int 23 24 25 print_bool(a_bool=identity(7)) 26 print_bool(a_bool=identity_nonwrapped(7)) ``` mypy will complain only on the last line, being unable to check properly the line 25. I'll investigate a bit more on why mypy skips that. -- ___ Python tracker <https://bugs.python.org/issue41231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41231] Type annotations lost when using wraps by default
David Caro added the comment: As a note, mypy does not tpyecheck the wrapper functions, probably because it would not be possible with the current code (as the typing hints get lost): https://mypy.readthedocs.io/en/latest/generics.html?highlight=wrapper#declaring-decorators -- ___ Python tracker <https://bugs.python.org/issue41231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41231] Type annotations lost when using wraps by default
Change by David Caro : -- keywords: +patch pull_requests: +20538 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21392 ___ Python tracker <https://bugs.python.org/issue41231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8814] functools.WRAPPER_ASSIGNMENTS should include __annotations__
Change by David Caro : -- nosy: +David Caro nosy_count: 4.0 -> 5.0 pull_requests: +20539 pull_request: https://github.com/python/cpython/pull/21392 ___ Python tracker <https://bugs.python.org/issue8814> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41231] Type annotations lost when using wraps by default
David Caro added the comment: Hi Terry, That would not work in this case, as I'd want to override all annotations with the wrapper function ones if there's any, instead of merging them. The specific use case, is a type checker (part of TestSlide testing framework), to verify that if there's any type annotations, the parameters mocked and passed to it are the expected types. For example, the contextmanager decorator returns an actual ContextManager, wrapping whatever the wrapped function returned, so if the wrapped function annotations prevail, then there's no way if verifying that the returned type is correct. Thanks for the ChainMap pointer though, I'll use it for sure somewhere else. -- ___ Python tracker <https://bugs.python.org/issue41231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41206] behaviour change with EmailMessage.set_content
R. David Murray added the comment: I'm short of time, if someone could approve Mark's PR and merge it it would be great. There wasn't supposed to be any behavior change other than the one documented in #40597. -- ___ Python tracker <https://bugs.python.org/issue41206> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41231] Type annotations lost when using wraps by default
New submission from David Caro :
In version 3.2, bpo-8814 introduced copying the __annotations__ property from
the wrapped function to the wrapper by default.
That would be the desired behavior when your wrapper function has the same
signature than the function it wraps, but in some cases (for example, with the
contextlib.asynccontextmanager function) the return value is different, and
then the __annotations__ property will have invalid information:
In [2]: from contextlib import asynccontextmanager
In [3]: @asynccontextmanager
...: async def mytest() -> int:
...: return 1
...:
In [4]: mytest.__annotations__
Out[4]: {'return': int}
I propose changing the behavior of wraps, to only assign the __annotations__ by
default if there's no __annotations__ already in the wrapper function, that
would fit most default cases, but would allow to preserve the __annotations__
of the wrapper function when the types are explicitly specified, allowing now
to change the contextlib.asynccontextmanager function with the proper types
(returning now an AsyncContextManager) and keep the __annotation__ valid.
I'll try to get a POC and attach to the issue, but please comment with your
ideas too.
--
components: Library (Lib)
messages: 373233
nosy: David Caro
priority: normal
severity: normal
status: open
title: Type annotations lost when using wraps by default
type: behavior
versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python
3.9
___
Python tracker
<https://bugs.python.org/issue41231>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41215] AIX: build fails for xlc/xlC since new PEG parser
David Edelsohn added the comment: Maybe XLC was being overly aggressive with speculation and it now is fixed. I can't tell if Michael's earlier comment meant that it no longer crashes with XLC v16. -- ___ Python tracker <https://bugs.python.org/issue41215> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41215] AIX: build fails for xlc/xlC since new PEG parser
David Edelsohn added the comment: I don't believe that this is an XLC bug, but I suspect that it is undefined behavior / implementation-defined behavior. I suspect that this is tripping over AIX/XLC null behavior. AIX specifically and intentionally maps the first page of memory at address 0 to allow the compiler to speculate through NULL pointers. The compiler probably is speculating in this case and the second element is not defined. There is some option to disable this speculation in XLC. -- ___ Python tracker <https://bugs.python.org/issue41215> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41206] behaviour change with EmailMessage.set_content
New submission from David Bremner :
Works in 3.8.3, but not in 3.8.4rc1
from email.message import EmailMessage
msg = EmailMessage()
msg.set_content("")
Apparently now at least one newline is required.
--
components: email
messages: 372971
nosy: barry, bremner, r.david.murray
priority: normal
severity: normal
status: open
title: behaviour change with EmailMessage.set_content
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue41206>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41201] Long integer arithmetic
New submission from David Srebnick :
The following program is one way of computing the sum of digits in a number.
It works properly for the first case, but fails for the second one.
def digitsum(num):
digsum = 0
tnum = num
while tnum > 0:
print("tnum = %d, digsum = %d" % (tnum,digsum))
digsum += (tnum % 10)
tnum = int((tnum - (tnum % 10)) / 10)
return digsum
print(digitsum())
print(digitsum(9))
--
messages: 372925
nosy: David Srebnick
priority: normal
severity: normal
status: open
title: Long integer arithmetic
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue41201>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41067] Haiku build fix - posix module
Change by David CARLIER : -- components: Extension Modules nosy: devnexen priority: normal pull_requests: 20203 severity: normal status: open title: Haiku build fix - posix module type: compile error versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue41067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41023] smtplib does not handle Unicode characters
R. David Murray added the comment: If you use the 'sendmail' function for sending, then it is entirely your responsibility to turn the email into "wire format". Unicode is not wire format, but if you give sendmail a string that only has ascii in it it nicely converts it to binary for you. But given that the email RFCs specify specific ways to indicate how non-ascii is encoded in the message, there is no way for the smtp library to know now to do that correctly when passed an arbitrary unicode string, so it doesn't try. sendmail requires *you* do do the encoding to binary, indicating you at least think that you got the RFC parts right :) In python2, strings are binary by default, so in that case you are handing sendmail binary format data (with the same assumption that you got the RFC parts right)...if you passed the python2 function a unicode string it would probably complain as well, although not in the same way. If your raw email is RFC compliant, then you can do: sendmail(from, to, mymsg.encode()). I see from your example that you are trying to use the email package to construct the email, which is good. But, emails are *binary*, they are not unicode, so passing "message_from_string" a unicode string containing non-ascii isn't going to do what you are expecting, any more than passing unicode to the 'sendmail' function did. message_from_string is really only useful for doing certain sorts of debug and ought to be deprecated. Or produce a warning when handed a string containing non-ascii. (There are historical reasons why it doesn't :( And then you should use smtplib's 'sendmessage' function, which understands email package messages and will Do the Right Thing with them (including the extraction of the to and from addresses your code is currently doing). However, even if you encoded your raw message to binary and then passed it to message_from_bytes, your example message is *not* RFC compliant: without MIME headers, an email with non-ascii characters in the body is technically in violation of the RFC. Most email programs will handle that particular message despite that, but not all. You are better off using the email package to construct a properly RFC formatted email, using the new API (ex: msg = EmailMessage() (not Message), and then doing msg['from'] = address, etc, and msg.set_content(your unicode string body)). I can't really give you much advice here (nor should I, this being a bug tracker :) because I don't know how exactly how the data is coming in to your program in your real use case. Once you have a properly constructed EmailMessage object, you should use smtplib's 'sendmessage' function, which understands email package messages and will Do the Right Thing with them (including the extraction of the to and from addresses your code is currently doing, as well as properly handling BCC, which means deleting BCC headers from the message before sending it, which your code does not do and which 'sendmail' would not do.) SMTPUTF8 is about non-ascii in the email *headers*, and most SMTP servers these days do not yes support it[*]. Some of the big ones do, though (I believe gmail does). [*] although that doesn't explain why what you got was SMTPSenderRefused. You should have gotten SMTPNotSupportedError. -- resolution: -> works for me stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue41023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41008] multiprocessing.Connection.poll raises BrokenPipeError on Windows
New submission from David Adam : On Windows 10 (1909, build 18363.900) in 3.7.7 and 3.9.0b3, poll() on a multiprocessing.Connection object can produce an exception: -- import multiprocessing def run(output_socket): for i in range(10): output_socket.send(i) output_socket.close() def main(): recv, send = multiprocessing.Pipe(duplex=False) process = multiprocessing.Process(target=run, args=(send,)) process.start() send.close() while True: if not process._closed: if recv.poll(): try: print(recv.recv()) except EOFError: process.join() break if __name__ == "__main__": main() -- On Linux/macOS this prints 0-9 and exits successfully, but on Windows produces a backtrace as follows: File "mptest.py", line 17, in main if recv.poll(): File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.9_3.9.179.0_x64__qbz5n2kfra8p0\lib\multiprocessing\connection.py", line 262, in poll return self._poll(timeout) File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.9_3.9.179.0_x64__qbz5n2kfra8p0\lib\multiprocessing\connection.py", line 333, in _poll _winapi.PeekNamedPipe(self._handle)[0] != 0): BrokenPipeError: [WinError 109] The pipe has been ended -- messages: 371748 nosy: zanchey priority: normal severity: normal status: open title: multiprocessing.Connection.poll raises BrokenPipeError on Windows type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue41008> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40826] PyOS_InterruptOccurred() now requires to hold the GIL: PyOS_Readline() crash
David Bolen added the comment: So a script I use on the buildbot intended to prevent hanging on assertions was failing to work in this particular case, which I've corrected. That changes the failure mode for new Win10 buildbot runs. The test in question (test_close_stdin) still fails, but does so immediately (return code not 0, as the child process aborts) rather than timing out. If the assertion is expected, and something to be ignored, the test itself still needs to handle that. -- ___ Python tracker <https://bugs.python.org/issue40826> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40900] uuid module build fix on FreeBSD proposal
David CARLIER added the comment: This s about header picked up in a certain order. In case of FreeBSD, the uui_create case is taken which comes from the but ... is detected too. -- ___ Python tracker <https://bugs.python.org/issue40900> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40900] uuid module build fix on FreeBSD proposal
Change by David CARLIER : -- components: FreeBSD nosy: devnexen, koobs priority: normal pull_requests: 19908 severity: normal status: open title: uuid module build fix on FreeBSD proposal type: compile error versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue40900> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40826] PyOS_InterruptOccurred() now requires to hold the GIL: PyOS_Readline() crash
David Bolen added the comment: It appears the recent commit is causing a CRT exception dialog in test_close_stdin (test_repl.TestInteractiveInterpreter). The dialog can't get answered, which is what leads to the eventual timeout. The assertion is "_osfile(fh) & FOPEN" from osfinfo.cpp on line 258. It actually appears twice (if the first is ignored). If both are ignored the test passes. I was somewhat surprised to see the dialog, as I believe CRT exception dialogs are disabled during test runs (others are present in test logs). Perhaps the child interpreter used by test_repl doesn't inherit that behavior. If so, this was probably always a risk, there just weren't any assertions occurring before this in the child interpreter. -- ___ Python tracker <https://bugs.python.org/issue40826> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40826] PyOS_InterruptOccurred() now requires to hold the GIL: PyOS_Readline() crash
David Bolen added the comment: I haven't had a chance to look too deeply, but the final set of commits (starting with fa7ab6aa) appear to be the common thread with all branches now failing with timeout exceptions in test_repl on the Windows 10 buildbot. The first instance was in the 3.x branch (https://buildbot.python.org/all/#/builders/129/builds/1191) but they all seem similar. -- David -- nosy: +db3l ___ Python tracker <https://bugs.python.org/issue40826> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39040] Wrong attachement filename when mail mime header was too long
R. David Murray added the comment: New changeset 21017ed904f734be9f195ae1274eb81426a9e776 by Abhilash Raj in branch 'master': bpo-39040: Fix parsing of email mime headers with whitespace between encoded-words. (gh-17620) https://github.com/python/cpython/commit/21017ed904f734be9f195ae1274eb81426a9e776 -- ___ Python tracker <https://bugs.python.org/issue39040> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40780] str.format() handles trailing zeros inconsistently in “general” format
New submission from David Chambers :
According to
https://docs.python.org/3/library/string.html#format-specification-mini-language,
“insignificant trailing zeros are removed from the significand” when 'g' is
specified. I encountered a situation in which a trailing zero is not removed:
$ python3
Python 3.7.7 (default, Mar 10 2020, 15:43:03)
[Clang 11.0.0 (clang-1100.0.33.17)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> '{0:.3g}'.format(1504)
'1.5e+03'
>>> '{0:.3g}'.format(1505)
'1.50e+03'
>>> '{0:.3g}'.format(1506)
'1.51e+03'
Is this behaviour intentional? If so, why is the trailing zero in 1.50
considered significant for 1505 but insignificant for 1504?
--
messages: 369983
nosy: davidchambers
priority: normal
severity: normal
status: open
title: str.format() handles trailing zeros inconsistently in “general” format
type: behavior
___
Python tracker
<https://bugs.python.org/issue40780>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40726] ast.Call end_lineno is defined and returns None
David Strobach added the comment: > Actually, Xonsh tests show that keyword AST nodes are missing 'lineno' > attribute, but that could be our fault. Yes, our fault. Sorry for the noise. -- ___ Python tracker <https://bugs.python.org/issue40726> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40726] ast.Call end_lineno is defined and returns None
David Strobach added the comment: Actually, Xonsh (http://github.com/xonsh/xonsh) tests show that keyword AST nodes are missing 'lineno' attribute, but that could be our fault. -- ___ Python tracker <https://bugs.python.org/issue40726> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40726] ast.Call end_lineno is defined and returns None
David Strobach added the comment: The issue is not limited to ast.Call. Other AST nodes are also affected (e.g. ast.BinOp). It's also not limited to end_lineno attribute. The same applies to end_col_offset. -- ___ Python tracker <https://bugs.python.org/issue40726> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40726] ast.Call end_lineno is defined and returns None
Change by David Strobach : -- nosy: +laloch ___ Python tracker <https://bugs.python.org/issue40726> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40597] generated email message exceeds RFC-mandated limit of 998 characters
Change by R. David Murray : -- stage: backport needed -> resolved ___ Python tracker <https://bugs.python.org/issue40597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40597] generated email message exceeds RFC-mandated limit of 998 characters
R. David Murray added the comment: New changeset c1f1ddf30a595c2bfa3c06e54fb03fa212cd28b5 by Miss Islington (bot) in branch '3.8': bpo-40597: email: Use CTE if lines are longer than max_line_length consistently (gh-20038) (gh-20084) https://github.com/python/cpython/commit/c1f1ddf30a595c2bfa3c06e54fb03fa212cd28b5 -- ___ Python tracker <https://bugs.python.org/issue40597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36876] [subinterpreters] Global C variables are a problem
Change by David Bolen : -- nosy: -db3l ___ Python tracker <https://bugs.python.org/issue36876> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40597] generated email message exceeds RFC-mandated limit of 998 characters
R. David Murray added the comment: Thanks, Arkadiusz. -- resolution: -> fixed stage: patch review -> backport needed versions: -Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue40597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40597] generated email message exceeds RFC-mandated limit of 998 characters
R. David Murray added the comment: New changeset 6f2f475d5a2cd7675dce844f3af436ba919ef92b by Arkadiusz Hiler in branch 'master': bpo-40597: email: Use CTE if lines are longer than max_line_length consistently (gh-20038) https://github.com/python/cpython/commit/6f2f475d5a2cd7675dce844f3af436ba919ef92b -- ___ Python tracker <https://bugs.python.org/issue40597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40597] generated email message exceeds RFC-mandated limit of 998 characters
R. David Murray added the comment: The PR looks good to me, but I describe the change differently. I'm not sure how I missed this in the original implementation, since I obviously checked it for the 8bit case. Too long ago to remember :) -- ___ Python tracker <https://bugs.python.org/issue40597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40594] urljoin since 3.5 incorrectly filters out double slashes
New submission from David Bell :
In Python 3.5 the urljoin function was rewritten to be RFC 3986 compliant and
fix long standing issues. In the initial rewrite duplicate slashes were added
by accident, and so code was added to prevent that. The discussion is here:
https://bugs.python.org/issue22118
The code within urljoin is this:
# filter out elements that would cause redundant slashes on re-joining
# the resolved_path
segments[1:-1] = filter(None, segments[1:-1])
This seems sensible, you would not want double slashes in a URL, right? The
problem is: double slashes are perfectly legal in a URI/URL, and for reasons I
don't understand, they are in use in the wild. The code above was written to
remove them because urljoin accidentally introduced them, the problem is that
it also removes intentional double slashes:
>>> urljoin("http://www.example.com/";, "this//double/path")
'http://www.example.com/this/double/path'
Where as the expected result should be:
'http://www.example.com/this//double/path'
I suggest that the fix for this is to remove the aforementioned filter code,
e.g. remove this:
# filter out elements that would cause redundant slashes on re-joining
# the resolved_path
segments[1:-1] = filter(None, segments[1:-1])
...and remove this code too:
if base_parts[-1] != '':
# the last item is not a directory, so will not be taken into account
# in resolving the relative path
del base_parts[-1]
and instead simply add:
del base_parts[-1]
...because the last part of the split base URL should always be deleted. If the
last element of the list (the base URL split) is an empty string, then the URL
ended with a slash, and so we should remove the last element otherwise a double
slash will occur when we combine it with the second parameter to urljoin. If
the last element is not an empty string then the last part of the URL was not a
directory, and should be removed. Thus the last element should always be
removed.
By following this logic the "remove all double slashes" filter is not
necessary, because the cause of the accidental addition of double slashes is
removed.
--
components: Library (Lib)
messages: 368623
nosy: David Bell
priority: normal
severity: normal
status: open
title: urljoin since 3.5 incorrectly filters out double slashes
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue40594>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40569] Add optional weights to random.sample()
David Heiberg added the comment: Ahh I see, thanks for clearing that up! On Sun, May 10, 2020, 04:41 Raymond Hettinger wrote: > > Raymond Hettinger added the comment: > > Negative weights are undefined for choices() as well. Just like bisect() > and merge() don't verify their inputs are sorted. Usually, full scan > precondition checks are expensive in pure python and aren't worth > penalizing correct code. As Henk-Jaap points-out, negative weights are just > a special case of meaningless inputs. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue40569> > ___ > -- ___ Python tracker <https://bugs.python.org/issue40569> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40569] Add optional weights to random.sample()
David Heiberg added the comment: Just playing around with this and I think one thing to consider is how to handle negative weights. Should they even be allowed? One interesting behaviour I encountered with the current draft is the following: >>> r.sample(['katniss', 'prim', 'gale', 'peeta'] , weights=[-2,1,1,1], k=1) ['peeta'] This will always return ['peeta'], or whatever happens to be in the last index. I believe this is because in `choices`, the `cum_weights` list would be [-2, -1, 0, 1], causing it to only be able to select the last value in the population. Looking into random.choices, it suggests that the weights were designed with negative ones in mind. However they were not accounted for and end up influencing the weights of the indexes around it. Another example is this: >>> r.choices(['alice', 'bob', 'camile', 'david'], weights=[1, 1, -2, 1]) ['alice'] This will always return ['alice'], showing that the negative weight of 'camile' is affecting indexes around it. Is there something I am missing? Otherwise this seems like it may warrant its own bug. -- nosy: +dheiberg ___ Python tracker <https://bugs.python.org/issue40569> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40570] len(platform.uname()) has changed in Python 3.9
Change by David Tucker : -- keywords: +patch pull_requests: +19320 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20009 ___ Python tracker <https://bugs.python.org/issue40570> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40570] len(platform.uname()) has changed in Python 3.9
New submission from David Tucker : https://github.com/python/cpython/commit/518835f3354d6672e61c9f52348c1e4a2533ea00#diff-47c8e5750258a08a6dd9de3e9c3774acL741-R804 That diff changed len(platform.uname()) to 5 (from 6). I noticed because we have some code that checks for 6 strs (arguably unnecessary), but I can also think of contrived examples that would break (e.g. platform.uname()[-3]). Interestingly, platform.uname()[5] still works. Was this effect intentional? -- components: Library (Lib) messages: 368459 nosy: tucked priority: normal severity: normal status: open title: len(platform.uname()) has changed in Python 3.9 type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue40570> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40510] [regression] ZipFile fails to round trip on some files
New submission from David Naylor : With commit 18ee29d0b8 [1] a change was introduced that prevents a round-trip of some zip files (i.e. files generated by Microsoft Excel) due to the clobbering of `ZipInfo.flag_bits`[2] and `external_attr`[3]. For example: ```python[name=zip-round-trip.py] #!/usr/bin/env python3 import io import sys import zipfile compression = zipfile.ZIP_STORED source = sys.stdin dest = sys.stdout with io.BytesIO(source.buffer.read()) as source, io.BytesIO() as buffer: with zipfile.ZipFile(source, "r") as source_zip, zipfile.ZipFile(buffer, "w") as dest_zip: dest_zip.comment = source_zip.comment for info in source_zip.infolist(): content = source_zip.read(info) dest_zip.writestr(info, content, compression) buffer.seek(0) dest.buffer.write(buffer.read()) ``` ```shell > python3.5 zip-round-trip.py < Book1.zip > Python.zip > diff Book1.zip Python.zip > python3.6 zip-round-trip.py < Book1.zip > Python.zip > diff Book1.zip Python.zip Binary files Book1.zip and Python.zip differ ``` [1] https://github.com/python/cpython/commit/18ee29d0b870caddc0806916ca2c823254f1a1f9 [2] https://github.com/python/cpython/blob/f01d1be97d740ea0369379ca305646a26694236e/Lib/zipfile.py#L1579 [3] https://github.com/python/cpython/blob/f01d1be97d740ea0369379ca305646a26694236e/Lib/zipfile.py#L1586 -- components: Library (Lib) files: Book1.zip messages: 368130 nosy: DragonSA priority: normal severity: normal status: open title: [regression] ZipFile fails to round trip on some files type: behavior versions: Python 3.6 Added file: https://bugs.python.org/file49121/Book1.zip ___ Python tracker <https://bugs.python.org/issue40510> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40359] email.parse part.get_filename() fails to unwrap long attachment file names (legacy API)
R. David Murray added the comment: As far as I know you currently still have to specify the policy. It was, yes, intended that 'default' become the actual default. I could have sworn there was an open issue for doing this, but I can't find it. I remember having a conversation with someone who said they were going to work on getting it done, but unfortunately I don't remember who :( I'm not very active in the python community currently so I can't really drive it, but it should definitely happen. -- ___ Python tracker <https://bugs.python.org/issue40359> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40359] email.parse part.get_filename() fails to unwrap long attachment file names (legacy API)
R. David Murray added the comment: Yeah, that looks like a bug in the old API. If you try the new API, it does the right thing. To do that, import email.policy and make your message_as_string call: email.message_from_string(raw, policy=email.policy.default) Note, however, that you really ought to be using message_from_bytes. Serialized email messages are bytes, not unicode, and using message_from_string will get you in to other trouble. I don't know if it is worth fixing the old API. -- title: email.parse part.get_filename() fails to unwrap long attachment file names -> email.parse part.get_filename() fails to unwrap long attachment file names (legacy API) ___ Python tracker <https://bugs.python.org/issue40359> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40238] os.stat() on Windows succeeds for nonexistent paths with trailing spaces
David Strobach added the comment: Hi Eryk, thanks for your time and for the explanation. > The Windows file API normalizes paths to replace forward slashes with > backslashes; resolve relative paths and "." and ".." components; strip > trailing spaces and dots from the final component; and map reserved DOS > device names in the final component of non-UNC paths to device paths (e.g. > "C:/Temp/con " -> r"\\.\con"). OK, I understand. I know that Win32 documentation suggests to avoid using paths with trailing spaces and that the paths are subject to normalization. Then I'd say os.path.normpath() should perform the same (GetFullPathNameW?) normalization as os.stat() and friends do. Currently: >>> import os >>> path = r"c:\Program Files " >>> os.path.normpath(path) 'c:\\Program Files ' >>> os.path.realpath(path) 'C:\\Program Files' -- ___ Python tracker <https://bugs.python.org/issue40238> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40238] os.stat() on Windows succeeds for nonexistent paths with trailing spaces
New submission from David Strobach :
On Windows (Server 2012 R2 in my case) os.stat() seems to be striping
significant trailing spaces off the path argument:
>>> import os
>>> os.stat("c:\\Program Files ")
os.stat_result(st_mode=16749, st_ino=281474976710717, st_dev=173025906,
st_nlink=1, st_uid=0, st_gid=0, st_size=8192, st_atime=1586154685,
st_mtime=1586154685, st_ctime=1377178576)
>>> os.stat("c:\\Program Files\\ ")
os.stat_result(st_mode=16749, st_ino=281474976710717, st_dev=173025906,
st_nlink=1, st_uid=0, st_gid=0, st_size=8192, st_atime=1586154685,
st_mtime=1586154685, st_ctime=1377178576)
>>> # consequently
>>> os.path.isdir("c:\\Program Files\\ ")
True
>>> os.path.isdir("c:\\Program Files ")
True
>>> os.scandir("c:\\Program Files ")
Traceback (most recent call last):
File "", line 1, in
FileNotFoundError: [WinError 3] The system cannot find the path specified:
'c:\\Program Files '
The same also applies to regular files, not just directories.
--
components: Library (Lib), Windows
messages: 366054
nosy: David Strobach, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.stat() on Windows succeeds for nonexistent paths with trailing spaces
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue40238>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.
Change by David Bolen : -- nosy: -db3l ___ Python tracker <https://bugs.python.org/issue33608> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40139] mimetypes module racy
David K. Hess added the comment: I’m not sure I can shed any light on this particular bug, but I would say that based on my dealings with this module, it is definitely not thread-safe. That means that if you are going to have multiple threads accessing it simultaneously, you really should have a mutex around that access ensuring only one thread is running through the code in this module at a time. Now in reality, asyncio and other cooperatively scheduled multi-processing packages like gevent are not going to unpredictably yield control to another thread like true threads will. So, in this particular case, since the init code doesn’t use async or await, I don’t think there is a chance of an initialization race bug there. As to the bug witnessed, the only thing I can suggest is to add a considerable amount of debugging that logs the argument to guess_type and prints out the mimetype module’s internal state if and when this happens again. My best guess based on the amount of work that method does to inspect the passed in url, is that it has something to do with the url itself. -- ___ Python tracker <https://bugs.python.org/issue40139> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40069] Clear .lst files for AIX
David Edelsohn added the comment: Likely somewhere in the Python configuration process it is probing a command line option that emits a .lst file. -- ___ Python tracker <https://bugs.python.org/issue40069> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39073] email incorrect handling of crlf in Address objects.
Change by R. David Murray : -- stage: patch review -> backport needed ___ Python tracker <https://bugs.python.org/issue39073> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39073] email incorrect handling of crlf in Address objects.
R. David Murray added the comment: Thanks! -- ___ Python tracker <https://bugs.python.org/issue39073> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39073] email incorrect handling of crlf in Address objects.
R. David Murray added the comment: New changeset 614f17211c5fc0e5b828be1d3320661d1038fe8f by Ashwin Ramaswami in branch 'master': bpo-39073: validate Address parts to disallow CRLF (#19007) https://github.com/python/cpython/commit/614f17211c5fc0e5b828be1d3320661d1038fe8f -- ___ Python tracker <https://bugs.python.org/issue39073> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise exception
R. David Murray added the comment: My guess is that it isn't so much that __bool__ is special, as that the evaluation of values in a boolean context is special. What you have to do to make a mock behave "correctly" in the face that I'm not sure (I haven't investigated). And I might be wrong. -- ___ Python tracker <https://bugs.python.org/issue39966> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36085] Enable better DLL resolution
David Miguel Susano Pinto added the comment: I have just found out that commit 2438cdf0e93 which added the winmode argument and the documentation for it disagree. Documentation states that default is zero while the real default in code is None. I have opened PR 19167 on github to address it -- message_count: 60.0 -> 61.0 nosy: +carandraug nosy_count: 14.0 -> 15.0 pull_requests: +18563 pull_request: https://github.com/python/cpython/pull/19167 ___ Python tracker <https://bugs.python.org/issue36085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39073] email incorrect handling of crlf in Address objects.
R. David Murray added the comment: Thanks for the PR. I've made some review comments. -- ___ Python tracker <https://bugs.python.org/issue39073> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27793] Double underscore variables in module are mangled when used in class
R. David Murray added the comment: You are welcome to open a doc-enhancement issue for the global docs. For the other, as noted already if you want to advocate for a change to this behavior you need to start on python-ideas, but I don't think you will get any traction. Another possible enhancement you could propose (in a new issue) is to have the global statement check for variables that start with '__' and do something appropriate such as issue a warning...although I don't really know how hard that would be to implement. -- ___ Python tracker <https://bugs.python.org/issue27793> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39871] math.copysign raises SystemError with non-float x and custom y
David Vo added the comment: I'm currently rather busy with other work, but if this happens to still be open in a couple of months I might pick it up. -- ___ Python tracker <https://bugs.python.org/issue39871> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39871] math.copysign raises SystemError with non-float x and custom y
New submission from David Vo : If math.copysign(x, y) is passed an x that cannot be converted to a float and a y that implements __float__() in Python, math.copysign() will raise a SystemError from the TypeError resulting from the attempted float conversion of x. math.copysign() should probably return immediately if converting the first argument to a float raises an error. Example: >>> import math >>> from fractions import Fraction >>> float(Fraction(-1, 1)) # this is needed to avoid an AttributeError? -1.0 >>> math.copysign((-1) ** 0.5, Fraction(-1, 1)) TypeError: can't convert complex to float The above exception was the direct cause of the following exception: Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.8/numbers.py", line 291, in __float__ return self.numerator / self.denominator SystemError: PyEval_EvalFrameEx returned a result with an error set -- components: Extension Modules messages: 363477 nosy: auscompgeek priority: normal severity: normal status: open title: math.copysign raises SystemError with non-float x and custom y type: behavior ___ Python tracker <https://bugs.python.org/issue39871> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39773] Export symbols for vectorcall
David Hewitt added the comment: I had suspected that might be the case. We already use PyObject_Call but had been hoping to experiment with the Vectorcall optimizations. Without the symbols I might resort to reproducing the implementation of these functions on the Rust side. Shouldn't be too much code duplication. -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue39773> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39771] EmailMessage may need to support RFC-non-compliant MIME parameter encoding (encoded words in quotes) for output.
R. David Murray added the comment: I actually agree: if most (by market share) MUAs handle the RFC-incorrect parameter encoding style, and a significant portion does not handle the RFC correct style, then we should support the de-facto standard rather than the official standard as the default. I just wish Microsoft would write better software :) If on the other hand it is only microsoft out of the big market share players that is broken, I'm not sure I'd want it to be the default. But we could still support it optionally. So yeah, we could have a policy control that governs which one is actually used. So this is a feature request, and ideally should be supported by an investigation of what MUAs support what, by market share. And there's another question: does this only affect the filename parameter, or is it all MIME parameters? I would expect it to be the latter, but someone should check at least a few examples of that to be sure. -- stage: -> needs patch title: EmailMessage.add_header doesn't work -> EmailMessage may need to support RFC-non-compliant MIME parameter encoding (encoded words in quotes) for output. type: behavior -> enhancement ___ Python tracker <https://bugs.python.org/issue39771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39793] make_msgid fail on FreeBSD 12.1-RELEASE-p1 with different domains
R. David Murray added the comment: I don't object to this patch, but that sure looks like a broken system. -- ___ Python tracker <https://bugs.python.org/issue39793> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39757] EmailMessage bad encoding for international domain
R. David Murray added the comment: This is not actually a duplicate of 11783. Rereading (parts of) that issue, we decided we currently have no good way to do automatic conversion between unicode and internationalized domains, so the user of the library has to do it themselves. This means that the bug *here* is that the new email API is *wrongly* encoding the non-ascii in the domain by using an encoded word. I'm surprised at that; I thought I'd guarded against it. What should be happening here is that an error should be raised when that header is set (or possibly when it is accessed/serialized, but when set would be better I think) saying that there is non-ascii in the domain part. -- resolution: duplicate -> stage: resolved -> needs patch status: closed -> open superseder: email parseaddr and formataddr should be IDNA aware -> title: EmailMessage wrong encoding for international domain -> EmailMessage bad encoding for international domain ___ Python tracker <https://bugs.python.org/issue39757> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39771] EmailMessage.add_header doesn't work
R. David Murray added the comment: Since Outlook is one of the mailers that generates the non-RFC-compliant headers, it doesn't surprise me all that much that it can't interpret the RFC compliant headers correctly. I'm not sure there is anything we can do here. I suppose someone could do a survey of mail clients and document which ones can handle which style of parameter encoding. If it turns out more handle the "wrong" way than handle the "right" way, we could consider adopting to the de-facto standard, although I won't like it much :) (There is also a possibility there is a bug in our RFC compliance, but this is the first problem report I've seen.) -- ___ Python tracker <https://bugs.python.org/issue39771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39771] EmailMessage.add_header doesn't work
R. David Murray added the comment: The legacy API appears to be using an RFC-incorrect (but common) encoded-word encoding, while the new API is using the RFC-compliant MIME-parameter encoding (% encoding). Which email client are you using? -- ___ Python tracker <https://bugs.python.org/issue39771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39771] EmailMessage.add_header doesn't work
R. David Murray added the comment: Actually, given that the contentmanager does accept a charset parameter for text content, it does seem reasonable to treat this as a bug. But as I said fixing it may not be trivial. -- ___ Python tracker <https://bugs.python.org/issue39771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39771] EmailMessage.add_header doesn't work
R. David Murray added the comment: I think you are saying that you want the charset in the encoded filename to be GBK rather than utf-8? utf-8 should certainly display correctly in your email client, though, so if it is not there is something else going wrong. As far as the 3 tuple not working to set the charset...I believe what is happening there is that a header created by the application gets "refolded" on serialization, and refolding doesn't keep the existing charset, it converts everything to utf-8. This is an intentional part of the design: the library handles the gory details of MIME and uses utf-8 as the charset for application created content. It is actually an accident of the implementation that the tuple form of the filename is even accepted; you will note that it is *not* documented in the contentmanager docs. It wouldn't be crazy to ask for this as a feature, and it could even be treated as a bug that it doesn't work if we want to, but it may not be easy to "fix", because it goes against the design philosophy of the new API. -- ___ Python tracker <https://bugs.python.org/issue39771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39773] Export symbols for vectorcall
New submission from David Hewitt : I have been looking into using vectorcall in [pyo3](https://github.com/PyO3/pyo3) (Rust bindings to Python) against python3.8. It looks like the _PyObject_Vectorcall symbols are not included in the shared library. I've checked both Windows and Linux. I think the `static inline` definition of `PyObject_Vectorcall` and related functions in `abstract.h` means that they won't be exported as symbols in the final library? -- messages: 362789 nosy: David Hewitt priority: normal severity: normal status: open title: Export symbols for vectorcall versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39773> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39761] Python 3.9.0a4 fails to build when configured with --with-dtrace
Change by David CARLIER : -- keywords: +patch nosy: +devnexen nosy_count: 4.0 -> 5.0 pull_requests: +18029 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18672 ___ Python tracker <https://bugs.python.org/issue39761> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39761] Python 3.9.0a4 fails to build when configured with --with-dtrace
David Carlier added the comment: If it works for you, it might mean making a specific case for Linux systems in configure.ac as a proper fix. -- ___ Python tracker <https://bugs.python.org/issue39761> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39761] Python 3.9.0a4 fails to build when configured with --with-dtrace
David Carlier added the comment: ah sorry I meant DFLAGS=" " (with a space). -- ___ Python tracker <https://bugs.python.org/issue39761> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39761] Python 3.9.0a4 fails to build when configured with --with-dtrace
David Carlier added the comment: Weird I just tried on ubuntu/systemtap... -- ___ Python tracker <https://bugs.python.org/issue39761> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39761] Python 3.9.0a4 fails to build when configured with --with-dtrace
David Carlier added the comment: What about DFFLAGS=" " ? -- ___ Python tracker <https://bugs.python.org/issue39761> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39761] Python 3.9.0a4 fails to build when configured with --with-dtrace
David Carlier added the comment: Sorry for the inconveniences. I can reproduce on FreeBSD too if I do not set the DFLAGS env var (because FreeBSD needs architecture bits in addition). What happens when make distclean && export DFLAGS="" && ./configure --with-dtrace ? -- ___ Python tracker <https://bugs.python.org/issue39761> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39700] asyncio.selector_events._SelectorTransport: Add logging when sock.getpeername() fails
David added the comment: Hi asvetlov, Thank you for your reply. I'm currently trying to debug a network issue, but I cannot determine the root cause of it because of lack of logs. It would be extremely helpful for my debugging if we could log the error that was raised by getpeername. I noticed that in asyncio.proactor_events._set_socket_extra there *is* some logging of exceptions. ``` def _set_socket_extra(transport, sock): transport._extra['socket'] = trsock.TransportSocket(sock) try: transport._extra['sockname'] = sock.getsockname() except socket.error: if transport._loop.get_debug(): logger.warning( "getsockname() failed on %r", sock, exc_info=True) if 'peername' not in transport._extra: try: transport._extra['peername'] = sock.getpeername() except socket.error: # UDP sockets may not have a peer name transport._extra['peername'] = None ``` Although I see that there there's also a check `if transport._loop.get_debug()` so that it won't pollute the log. Would you like me to add that check to my patch too? Thanks! -- ___ Python tracker <https://bugs.python.org/issue39700> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39726] ctypes on pypi has fallen behind
David Harding added the comment: Hi ammar2, Your comment completely clears up my issue. I was just uninformed. As you have stated, no change needs to be made to the pypi version. To enforce a version of ctypes with venv/pip, I need only enforce a python version that is packaged with that version of ctypes. I have closed this issue report. Thank you again for your time! -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue39726> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39726] ctypes on pypi has fallen behind
New submission from David Harding : I wasn't sure where to report this. ctypes currently bundled with Ubuntu 16.04 and 18.04 is version 1.1.0. ctypes available through pypi is 1.0.2. https://pypi.org/project/ctypes/ This makes maintaining a reproducible environment with venv kind of tricky. It would be desirable to catch the pypi version up to 1.1.0. I don't really know who to bother about this, so I'm starting here. Thanks! -- components: ctypes messages: 362488 nosy: David Harding priority: normal severity: normal status: open title: ctypes on pypi has fallen behind type: enhancement versions: Python 3.5, Python 3.7 ___ Python tracker <https://bugs.python.org/issue39726> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39700] asyncio.selector_events._SelectorTransport: Add logging when sock.getpeername() fails
Change by David : -- keywords: +patch Added file: https://bugs.python.org/file48900/log-peername-and-sockname-errors.patch ___ Python tracker <https://bugs.python.org/issue39700> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39700] asyncio.selector_events._SelectorTransport: Add logging when sock.getpeername() fails
New submission from David : `sock.getpeername` can fail for multiple reasons (see https://pubs.opengroup.org/onlinepubs/7908799/xns/getpeername.html) but in `asyncio.selector_events._SelectorTransport` it's try/excepted without any logging of the error: ``` if 'peername' not in self._extra: try: self._extra['peername'] = sock.getpeername() except socket.error: self._extra['peername'] = None ``` This makes it very difficult to debug. Would it be OK if I added here a log with information on the error? Thanks! -- components: asyncio messages: 362317 nosy: asvetlov, dsternlicht, yselivanov priority: normal severity: normal status: open title: asyncio.selector_events._SelectorTransport: Add logging when sock.getpeername() fails versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue39700> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39582] ossaudiodev update helpers signature
Change by David CARLIER : -- nosy: devnexen priority: normal pull_requests: 17786 severity: normal status: open title: ossaudiodev update helpers signature versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39582> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38628] Issue with ctypes in AIX
David Edelsohn added the comment:
The bug report implies a different bug than what is being reported. The bug is
not related to calling a LIBC function with an argument list that does not
match the function signature.
The true issue is that a Python ctypes structure definition on AIX that
contains an array as in the example does not create an argument list that
matches the AIX ABI for argument passing. An example that directly uses libffi
seems to work, but invoking libffi via Python ctypes does not.
In other words, Python ctypes structures created with _fields_ equivalent to
struct {
const char *s;
unsigned long d;
size_t n;
}
should produce the same argument list as
struct {
const char *s;
unsigned long c_n[2];
}
but the version with the array does not.
libffi passes arrays as pointers, so Python ctypes converts arrays passed by
value as libffi structs. This occurs in cpython/Modules/_ctypes/stgdict.c .
It is likely that ctypes is not generating the correct libffi descriptor.
The memchr example visually demonstrates the incorrect argument list, but is
not intended to be correct, safe use of ctypes.
--
___
Python tracker
<https://bugs.python.org/issue38628>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38628] Issue with ctypes in AIX
David Edelsohn added the comment: Is this a legal use of Python ctypes? I don't see anything in the Python documentation that one can call a ctypes function with an argument list that does not match the function signature and expect it to work. Maybe this works on x86 by accident, but that doesn't mean that it is guaranteed to work everywhere and is permitted. -- ___ Python tracker <https://bugs.python.org/issue38628> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39384] Email parser creates a message object that can't be flattened as bytes.
R. David Murray added the comment: message_from_bytes -- ___ Python tracker <https://bugs.python.org/issue39384> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39384] Email parser creates a message object that can't be flattened as bytes.
R. David Murray added the comment: If we can get an actual reproducer using message_as_bytes I'd feel more comfortable with the fix. I worry that there is some other bug this is exposing that should be fixed instead. -- ___ Python tracker <https://bugs.python.org/issue39384> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38628] Issue with ctypes in AIX
David Edelsohn added the comment: How was Python compiled? With GCC? Which version of GCC? I assume that Python was built as a 64 bit application based on libc loading the 64 bit member shr_64.o. Does the testcase work in 32 bit mode? Does the testcase work if Python is compiled by XLC? This likely is an incompatibility in libffi with libffi loading the registers incorrectly for the call into libc.a(shr_64.o). It seems rather fragile to pass a struct that is supposed to have the same parameter layout as the function signature. -- ___ Python tracker <https://bugs.python.org/issue38628> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39502] test_zipfile fails on AIX due to time.localtime
David Edelsohn added the comment: I think that Victor means AIX kernel and filesystems are not prepared for Y2038. -- nosy: +David.Edelsohn ___ Python tracker <https://bugs.python.org/issue39502> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39525] math.remainder() give wrong answer on large integer
New submission from David Hwang : These two numbers are off by 1, and so should give different answer to >>> math.remainder(12345678901234567890,3) 1.0 >>> math.remainder(12345678901234567891,3) 1.0 -- components: Library (Lib) messages: 361211 nosy: David Hwang priority: normal severity: normal status: open title: math.remainder() give wrong answer on large integer type: behavior versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue39525> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38628] Issue with ctypes in AIX
Change by David Edelsohn : -- nosy: +David.Edelsohn, Michael.Felt ___ Python tracker <https://bugs.python.org/issue38628> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39460] test_zipfile: test_add_file_after_2107() sometimes fails on Fedora Rawhide 3.x
David Edelsohn added the comment: In utime_stat_localtime.py, "os.stat (sec)" is the result of os.utime. In utime_stat_localtime2.py "os.stat (sec int)" is the result of os.stat. -- ___ Python tracker <https://bugs.python.org/issue39460> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39460] test_zipfile: test_add_file_after_2107() sometimes fails on Fedora Rawhide 3.x
David Edelsohn added the comment:
[dje@rawhide ~]$ touch testfn
[dje@rawhide ~]$ python3 -c 'import os; os.utime("testfn", (4386268800,
4386268800))'
[dje@rawhide ~]$ stat testfn
File: testfn
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: fd00h/64768dInode: 17887487Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1001/ dje) Gid: ( 1001/ dje)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2038-01-18 22:14:07.0 -0500
Modify: 2038-01-18 22:14:07.0 -0500
Change: 2020-01-28 21:19:14.707112199 -0500
Birth: 2020-01-28 21:19:01.627112199 -0500
[dje@rawhide ~]$ python3 -c 'import os; st=os.stat("testfn"); print(st);
print(tuple(st)); print(st.st_mtime_ns)'
os.stat_result(st_mode=33204, st_ino=17887487, st_dev=64768, st_nlink=1,
st_uid=1001, st_gid=1001, st_size=0, st_atime=2147483647, st_mtime=2147483647,
st_ctime=1580264354)
(33204, 17887487, 64768, 1, 1001, 1001, 0, 2147483647, 2147483647, 1580264354)
21474836470
--
___
Python tracker
<https://bugs.python.org/issue39460>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39460] test_zipfile: test_add_file_after_2107() sometimes fails on Fedora Rawhide 3.x
David Edelsohn added the comment: Not -O3, but it's calling PyLong_FromLongLong on s390x as well 0x011ca524 <+28>:brasl %r14,0x10649b0 -- ___ Python tracker <https://bugs.python.org/issue39460> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39460] test_zipfile: test_add_file_after_2107() sometimes fails on Fedora Rawhide 3.x
David Edelsohn added the comment: $ ./python utime_stat_localtime2.py os.utime (sec): 4386268800 os.stat (sec int): 2147483647 os.stat (sec float): 2147483647.0 os.stat (ns): 21474836470 -- ___ Python tracker <https://bugs.python.org/issue39460> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39460] test_zipfile: test_add_file_after_2107() sometimes fails on Fedora Rawhide 3.x: time.localtime() limited to year 2038
David Edelsohn added the comment: $ ./python Python 3.9.0a3+ (heads/master:aabdeb766b, Jan 28 2020, 13:50:48) [GCC 10.0.1 20200121 (Red Hat 10.0.1-0.4)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> time.localtime(2**31) time.struct_time(tm_year=2038, tm_mon=1, tm_mday=18, tm_hour=22, tm_min=14, tm_sec=8, tm_wday=0, tm_yday=18, tm_isdst=0) >>> time.localtime(2**31-3600*24) time.struct_time(tm_year=2038, tm_mon=1, tm_mday=17, tm_hour=22, tm_min=14, tm_sec=8, tm_wday=6, tm_yday=17, tm_isdst=0) >>> time.localtime(2**32) time.struct_time(tm_year=2106, tm_mon=2, tm_mday=7, tm_hour=1, tm_min=28, tm_sec=16, tm_wday=6, tm_yday=38, tm_isdst=0) >>> time.localtime(2**33) time.struct_time(tm_year=2242, tm_mon=3, tm_mday=16, tm_hour=8, tm_min=56, tm_sec=32, tm_wday=2, tm_yday=75, tm_isdst=1) -- ___ Python tracker <https://bugs.python.org/issue39460> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39460] test_zipfile: test_add_file_after_2107() sometimes fails on Fedora Rawhide 3.x
David Edelsohn added the comment: Output on s390x Fedora Rawhide: $ ./python utime_stat_localtime.py os.utime (sec): 4386268800 os.stat (sec): 4386268800 os.stat (ns): 21474836470 stat==utime? False localtime: (2038, 1, 18, 22, 14, 7) -- ___ Python tracker <https://bugs.python.org/issue39460> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39460] test_zipfile: test_add_file_after_2107() fails on s390x Fedora Rawhide 3.x
David Edelsohn added the comment: Do you believe that a single GCC 10 issue is affecting PPC64LE, ARM, and s390x, but expressed in different manners on the different architectures OR is the PPC64LE issue separate and architecture-depdendent? -- ___ Python tracker <https://bugs.python.org/issue39460> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38980] Compile libpython with -fno-semantic-interposition
Change by David Filiatrault : -- nosy: +David Filiatrault ___ Python tracker <https://bugs.python.org/issue38980> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25702] Link Time Optimizations support for GCC and CLANG
Change by David Filiatrault : -- nosy: +David Filiatrault ___ Python tracker <https://bugs.python.org/issue25702> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39460] test_zipfile: test_add_file_after_2107() fails on s390x Fedora Rawhide 3.x
David Edelsohn added the comment: Sorry, posted the wrong output above. $ ./python -m test test_zipfile 0:00:00 load avg: 0.01 Run tests sequentially 0:00:00 load avg: 0.01 [1/1] test_zipfile test test_zipfile failed -- Traceback (most recent call last): File "/home/dje/src/cpython/Lib/test/test_zipfile.py", line 620, in test_add_file_after_2107 self.assertRaises(struct.error, zipfp.write, TESTFN) AssertionError: error not raised by write test_zipfile failed in 55.6 sec == Tests result: FAILURE == 1 test failed: test_zipfile Total duration: 55.6 sec Tests result: FAILURE -- ___ Python tracker <https://bugs.python.org/issue39460> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39460] test_zipfile: test_add_file_after_2107() fails on s390x Fedora Rawhide 3.x
David Edelsohn added the comment: $ ./python -m test tet_zipfile 0:00:00 load avg: 0.03 Run tests sequentially 0:00:00 load avg: 0.03 [1/1] tet_zipfile test tet_zipfile crashed -- Traceback (most recent call last): File "/home/dje/src/cpython/Lib/test/libregrtest/runtest.py", line 270, in _runtest_inner refleak = _runtest_inner2(ns, test_name) File "/home/dje/src/cpython/Lib/test/libregrtest/runtest.py", line 221, in _runtest_inner2 the_module = importlib.import_module(abstest) File "/home/dje/src/cpython/Lib/importlib/__init__.py", line 127, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "", line 1021, in _gcd_import File "", line 998, in _find_and_load File "", line 975, in _find_and_load_unlocked ModuleNotFoundError: No module named 'test.tet_zipfile' tet_zipfile failed == Tests result: FAILURE == 1 test failed: tet_zipfile Total duration: 76 ms Tests result: FAILURE -- ___ Python tracker <https://bugs.python.org/issue39460> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39248] test_distutils fails on PPC64 Fedora 3.x: /tmp/subprocess.py
David Edelsohn added the comment: The file was created and owned by another user. I have removed the file. I have reached out to the user to find out why he is creating it. -- ___ Python tracker <https://bugs.python.org/issue39248> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10740] sqlite3 module breaks transactions and potentially corrupts data
R. David Murray added the comment: Please open a new issue for this question. -- ___ Python tracker <https://bugs.python.org/issue10740> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
