[issue22670] wrong site-package installation even if correct libdir passed
New submission from Samuel: Today I compile try Python 3.4.2 on slackware-current in this way ./configure \ --prefix=/usr \ --libdir=/usr/lib64 \ --mandir=/usr/man \ --with-threads \ --enable-ipv6 \ --enable-shared \ make \ LIBDIR=/usr/lib64 \ SCRIPTDIR=/usr/lib64 make install like slackbuild say. But site package directory are under /usr/lib/python3.4/site-packages and not under /usr/lib64/python3.4/site-packages, which contanin only a README file with This directory exists so that 3rd party packages can be installed here. Read the source for site.py for more details. -- components: Cross-Build messages: 229675 nosy: Samuel88 priority: normal severity: normal status: open title: wrong site-package installation even if correct libdir passed type: compile error versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue22670> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22670] wrong site-package installation even if correct libdir passed
Samuel added the comment: I use an old slackbuild, with new http://slackbuilds.org/slackbuilds/14.1/python/python3/python3.SlackBuild wich have patch file which correct the lib64 path installation work fine -- ___ Python tracker <http://bugs.python.org/issue22670> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46078] `ast.unparse` fails on `class C: i: int`… convert broken from `ast.AnnAssign` to `ast.Assign`
New submission from Samuel Marks : astor fails with: ``` File "python3.8/site-packages/astor/code_gen.py", line 63, in to_source generator.visit(node) File "python3.8/site-packages/astor/node_util.py", line 143, in visit return visitor(node) File "python3.8/site-packages/astor/code_gen.py", line 878, in visit_Module self.write(*node.body) File "python3.8/site-packages/astor/code_gen.py", line 178, in write visit(item) File "python3.8/site-packages/astor/node_util.py", line 143, in visit return visitor(node) File "python3.8/site-packages/astor/code_gen.py", line 364, in visit_ClassDef self.body(node.body) File "python3.8/site-packages/astor/code_gen.py", line 226, in body self.write(*statements) File "python3.8/site-packages/astor/code_gen.py", line 178, in write visit(item) File "python3.8/site-packages/astor/node_util.py", line 143, in visit return visitor(node) File "python3.8/site-packages/astor/code_gen.py", line 293, in visit_Assign self.visit(node.value) File "python3.8/site-packages/astor/node_util.py", line 143, in visit return visitor(node) File "python3.8/site-packages/astor/node_util.py", line 137, in abort_visit raise AttributeError(msg % node.__class__.__name__) AttributeError: No defined handler for node of type NoneType ``` Whereas the now builtin to Python (3.9+) `ast.unparse` gives: ``` File "3.10/lib/python3.10/ast.py", line 1673, in unparse return unparser.visit(ast_obj) File "3.10/lib/python3.10/ast.py", line 807, in visit self.traverse(node) File "3.10/lib/python3.10/ast.py", line 798, in traverse super().visit(node) File "3.10/lib/python3.10/ast.py", line 410, in visit return visitor(node) File "3.10/lib/python3.10/ast.py", line 822, in visit_Module self._write_docstring_and_traverse_body(node) File "3.10/lib/python3.10/ast.py", line 815, in _write_docstring_and_traverse_body self.traverse(node.body) File "3.10/lib/python3.10/ast.py", line 796, in traverse self.traverse(item) File "3.10/lib/python3.10/ast.py", line 798, in traverse super().visit(node) File "3.10/lib/python3.10/ast.py", line 410, in visit return visitor(node) File "3.10/lib/python3.10/ast.py", line 1001, in visit_ClassDef self._write_docstring_and_traverse_body(node) File "3.10/lib/python3.10/ast.py", line 815, in _write_docstring_and_traverse_body self.traverse(node.body) File "3.10/lib/python3.10/ast.py", line 796, in traverse self.traverse(item) File "3.10/lib/python3.10/ast.py", line 798, in traverse super().visit(node) File "3.10/lib/python3.10/ast.py", line 410, in visit return visitor(node) File "3.10/lib/python3.10/ast.py", line 863, in visit_Assign self.traverse(node.value) File "3.10/lib/python3.10/ast.py", line 798, in traverse super().visit(node) File "3.10/lib/python3.10/ast.py", line 410, in visit return visitor(node) File "3.10/lib/python3.10/ast.py", line 414, in generic_visit for field, value in iter_fields(node): File "3.10/lib/python3.10/ast.py", line 252, in iter_fields for field in node._fields: AttributeError: 'NoneType' object has no attribute '_fields' ``` Found it when I tried to unparse previously parsed: ```py class C: i: int ``` Found in reality when trying to parse then emit: - https://github.com/tensorflow/tensorflow/blob/ba146843/tensorflow/compiler/xla/python/xla_client.py#L402-L413 Which is creating this: ``` ast.Assign(targets=[ast.Name(id="interior_padding")], type_comment="int", value=None) ``` (one thing my library does is convert betwixt `ast.Assign` and `ast.AnnAssign`… later I'll be doing more interesting variable type tracing to generate big `typing.Union` of all possible types each variable may have… but if it finds `None` then it will infer `typing.Optional`.) Here is my `ast.NodeTransformer` override for `visit_AnnAssign`: https://github.com/offscale/cdd-python/blob/968507e/cdd/doctrans_utils.py#L111-L131 Is there some way of rewriting an `ast.AnnAssign` to `ast.Assign` without losing type information? -- messages: 408580 nosy: samuelmarks priority: normal severity: normal status: open title: `ast.unparse` fails on `class C: i: int`… convert broken from `ast.AnnAssign` to `ast.Assign` versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46078> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46078] `ast.unparse` fails on `class C: i: int`… convert broken from `ast.AnnAssign` to `ast.Assign`
Samuel Marks added the comment: Just fixed the issue by using this value: ```py "```(None)```" if sys.version_info[:2] >= (3, 9) else "```None```" ``` -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46078> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8597] build out-of-line asm on Windows
Samuel Neves added the comment: I was unaware of patch #7456 when this was submitted. As far as I can tell, there is no difference and no reason to maintain both. -- nosy: +sneves ___ Python tracker <http://bugs.python.org/issue8597> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11593] Add encoding parameter to logging.basicConfig
New submission from Samuel Michaels : Yes, you could just make a custom logging.FileHandler object, but this way is much easier for those who are following the basic logging tutorial. -- components: Library (Lib) files: __init__.patch keywords: patch messages: 131314 nosy: Samuel.Michaels priority: normal severity: normal status: open title: Add encoding parameter to logging.basicConfig type: feature request versions: Python 3.2 Added file: http://bugs.python.org/file21275/__init__.patch ___ Python tracker <http://bugs.python.org/issue11593> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4357] frozen?set operations create incorrectly initialized instances of subclasses
New submission from Alex Samuel <[EMAIL PROTECTED]>: Methods of set and frozenset that return new set or frozenset instances return instances of subclasses, but these instances are not initialized correctly. In the attached code sample, z is an instance of MySet but MySet.__new__ and MySet.__init__ are never called on it. It seems to me that such a method should return a fully-initialized instance of the subclass. Barring that, it should just return a set or frozenset instance, not an instance of the subclass. -- assignee: theller components: ctypes files: fs.py messages: 76062 nosy: alexhsamuel, theller severity: normal status: open title: frozen?set operations create incorrectly initialized instances of subclasses type: behavior versions: Python 2.5, Python 3.0 Added file: http://bugs.python.org/file12062/fs.py ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4357> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4357] frozen?set operations create incorrectly initialized instances of subclasses
Alex Samuel <[EMAIL PROTECTED]> added the comment: In the sample code I attached, z is an instance of MySet under 3.0rc2. Is that expected? Thanks, Alex Mark Dickinson wrote: > Mark Dickinson <[EMAIL PROTECTED]> added the comment: > > The bug is that the set operations return instances of the subclass, > rather than instances of set. > > This is already fixed for 3.0: see issue 1721812. It was deemed too risky > to backport the change to 2.x. > > -- > assignee: theller -> > components: +Interpreter Core -ctypes > nosy: +marketdickinson > resolution: -> duplicate > status: open -> closed > > ___ > Python tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue4357> > ___ ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4357> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36871] Misleading error from unittest.mock's assert_has_calls
Samuel Freilich added the comment: This is still not totally fixed. This solves the underlying error with method specs, but not the bug that was causing the error-swallowing in assert_has_calls: https://github.com/python/cpython/blob/ee536b2020b1f0baad1286dbd4345e13870324af/Lib/unittest/mock.py#L2216 expected = [self._call_matcher(c) for c in calls] cause = expected if isinstance(expected, Exception) else None isinstance(expected, Exception) is never true, because expected is always a list. It should instead be: cause = next((e for e in expected if isinstance(e, Exception)), None) -- nosy: +sfreilich ___ Python tracker <https://bugs.python.org/issue36871> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36871] Misleading error from unittest.mock's assert_has_calls
Change by Samuel Freilich : -- pull_requests: +15630 pull_request: https://github.com/python/cpython/pull/16005 ___ Python tracker <https://bugs.python.org/issue36871> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36871] Misleading error from unittest.mock's assert_has_calls
Samuel Freilich added the comment: Sure, but the bug in error-handling should still be fixed. Currently, if _call_matcher returns an exception, that's ignored by assert_has_calls, and the error message generated as a result is extremely misleading! -- ___ Python tracker <https://bugs.python.org/issue36871> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36871] Misleading error from unittest.mock's assert_has_calls
Samuel Freilich added the comment: Check out my PR, which solves a much smaller issue: It fixes a bug in the exception raising logic in assert_has_calls (and _awaits) which makes complicated problems like the one you mention much harder to debug. Also it has tests! -- ___ Python tracker <https://bugs.python.org/issue36871> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38245] Why am I getting inconsistent results in this simple List assignment?
New submission from Srinivasan Samuel : Here is the my direct cut & paste from my Python 3.7.3 Shell >>> C = 2*[[]] >>> C [[], []] >>> >>> M = [[],[]] >>> M [[], []] >>> >>> C == M True >>> >>> M[0].append(5) >>> M [[5], []] >>> >>> C[0].append(5) >>> C [[5], [5]] >>> >>> C == M False >>> -- messages: 352945 nosy: pysolo priority: normal severity: normal status: open title: Why am I getting inconsistent results in this simple List assignment? type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue38245> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38245] Why am I getting inconsistent results in this simple List assignment?
Srinivasan Samuel added the comment: Thanks Ammar for your time, service and reply. It was really helpful. I learned some thing more.God Bless you.Srinivasan Samuel On Saturday, September 21, 2019, 10:50:32 PM GMT+5:30, Ammar Askar wrote: Ammar Askar added the comment: Check out this part of the FAQ: https://docs.python.org/3/faq/programming.html#how-do-i-create-a-multidimensional-list Essentially, when you did `C = 2*[[]]`, what happens is that the SAME empty list is placed into C[0] and C[1]. Whereas when you do `M = [[],[]]`, you're creating two different lists. You can confirm this using: >>> C = 2*[[]] >>> C[0] is C[1] True >>> M = [[],[]] >>> M[0] is M[1] False -- nosy: +ammar2 resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue38245> ___ -- ___ Python tracker <https://bugs.python.org/issue38245> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36871] Misleading error from unittest.mock's assert_has_calls
Change by Samuel Freilich : -- keywords: +patch pull_requests: +15942 stage: test needed -> patch review pull_request: https://github.com/python/cpython/pull/16361 ___ Python tracker <https://bugs.python.org/issue36871> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22240] argparse support for "python -m module" in help
Samuel Marks added the comment:
Until this is accepted, I've modified my codebase:
```
from argparse import ArgumentParser
ArgumentParser(
prog=None if globals().get('__spec__') is None else 'python -m
{}'.format(__spec__.name.partition('.')[0])
)
```
--
nosy: +samuelmarks
___
Python tracker
<https://bugs.python.org/issue22240>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22240] argparse support for "python -m module" in help
Samuel Marks added the comment: See https://bugs.python.org/msg353987 for manual test -- Added file: https://bugs.python.org/file48643/prog-module-name-handler.patch ___ Python tracker <https://bugs.python.org/issue22240> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38431] dataclasses.InitVar breaks with typing.Optional
New submission from Samuel Colvin :
The following code works fine with python 3.7 but breaks with 3.8:
```
import dataclasses
from typing import Optional
@dataclasses.dataclass
class TestingDataclass:
base_path: dataclasses.InitVar[Optional[str]] = None
```
Exception traceback:
```
Traceback (most recent call last):
File "test.py", line 6, in
class TestingDataclass:
File "/usr/local/lib/python3.8/dataclasses.py", line 995, in dataclass
return wrap(cls)
File "/usr/local/lib/python3.8/dataclasses.py", line 987, in wrap
return _process_class(cls, init, repr, eq, order, unsafe_hash, frozen)
File "/usr/local/lib/python3.8/dataclasses.py", line 967, in _process_class
str(inspect.signature(cls)).replace(' -> None', ''))
File "/usr/local/lib/python3.8/inspect.py", line 3050, in __str__
formatted = str(param)
File "/usr/local/lib/python3.8/inspect.py", line 2568, in __str__
formatannotation(self._annotation))
File "/usr/local/lib/python3.8/inspect.py", line 1202, in formatannotation
return repr(annotation)
File "/usr/local/lib/python3.8/dataclasses.py", line 213, in __repr__
return f'dataclasses.InitVar[{self.type.__name__}]'
File "/usr/local/lib/python3.8/typing.py", line 757, in __getattr__
raise AttributeError(attr)
AttributeError: __name__
```
The code runs fine with `str` instead of `Optional[str]`.
Tested locally with `Python 3.8.0rc1 (tags/v3.8.0rc1:34214de6ab, Oct 10 2019,
16:15:14)`. The same error can be seen (in a more involved context) on travis
[here](https://travis-ci.org/samuelcolvin/pydantic/jobs/596131963)
--
components: Library (Lib)
messages: 354388
nosy: samuelcolvin
priority: normal
severity: normal
status: open
title: dataclasses.InitVar breaks with typing.Optional
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue38431>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38431] dataclasses.InitVar breaks with typing.Optional
Samuel Colvin added the comment: This is a bug with the `__repr__` method on `InitVar`. I'm working on a PR now. -- ___ Python tracker <https://bugs.python.org/issue38431> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38431] dataclasses.InitVar breaks with typing.Optional
Change by Samuel Colvin : -- keywords: +patch pull_requests: +16286 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16700 ___ Python tracker <https://bugs.python.org/issue38431> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38431] dataclasses.InitVar breaks with typing.Optional
Change by Samuel Colvin : -- pull_requests: +16288 pull_request: https://github.com/python/cpython/pull/16702 ___ Python tracker <https://bugs.python.org/issue38431> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38561] multiprocessing.Queue fails intermittently with "Broken pipe"
New submission from Samuel Grayson : See [this SO post for more details](https://stackoverflow.com/q/51680479/1078199) -- components: Library (Lib) files: test.py messages: 355204 nosy: Samuel Grayson priority: normal severity: normal status: open title: multiprocessing.Queue fails intermittently with "Broken pipe" versions: Python 3.6, Python 3.7, Python 3.8 Added file: https://bugs.python.org/file48674/test.py ___ Python tracker <https://bugs.python.org/issue38561> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38681] 2to3 Conversion Result using BlankLine() can be Syntactically Incorrect
New submission from Samuel Tatasurya : Transformation performed by certain fixers (e.g. future, itertools_imports) that causes a statement to be replaced by a blank line will generate a Python file that contains syntax error. For example, assuming a Python file (foo.py) containing line below: try: from itertools import imap except ImportError: pass If we run "itertools_imports" fixer against it: 2to3 -f itertools_imports foo.py will result in the following: try: except ImportError: pass which is syntactically incorrect. Suggestion: Instead of always replacing such case with BlankLine(), a check should be performed beforehand if the statement to be replaced has any siblings. If no sibling is found, then replace that statement with a "pass" statement instead. By doing this, Python source files generated by 2to3 are more readily runnable right after the transformation. -- components: 2to3 (2.x to 3.x conversion tool) messages: 355926 nosy: Samuel Tatasurya priority: normal severity: normal status: open title: 2to3 Conversion Result using BlankLine() can be Syntactically Incorrect type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue38681> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43671] segfault when using tkinter + pygame for ~5 minutes
New submission from Samuel Kirwin : Per the attached file, when testing an adapted version of pygame's alien script as part of research. Python segfaulted. This has occured twice about 5 minutes in. I had console running all messages at the time if more logs needed. MacOS Big Sur 11.2.3 on MacBook Air (Retina, 13-inch, 2018) with 1.6 GHz Dual-Core Intel Core i5 & 8 GB 2133 MHz LPDDR3 Memory -- components: Tkinter files: segfault.rtf messages: 389827 nosy: Pycryptor10 priority: normal severity: normal status: open title: segfault when using tkinter + pygame for ~5 minutes type: crash versions: Python 3.9 Added file: https://bugs.python.org/file49919/segfault.rtf ___ Python tracker <https://bugs.python.org/issue43671> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31466] No easy way to change float formatting when subclassing encoder.JSONEncoder
Samuel Freilich added the comment: I think the less-minor issue, of which this is a small subset, is that JSONEncoder doesn't allow changing the behavior for default-serializable types at all. That means you can't choose to lose less information in round-trip serialization/deserialization, if that's what you want (e.g. there's no way to round-trip serialize a tuple with JSONEncoder, though it's trivial to do that for a set). -- nosy: +sfreilich ___ Python tracker <https://bugs.python.org/issue31466> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12657] Cannot override JSON encoding of basic type subclasses
Samuel Freilich added the comment:
> A modern solution for this is to define a singledispatch function (with
> implementations for your custom types) and pass it as the `default` parameter
> to the dump functions.
Does that work? I thought the default function only got called for
non-serializable types.
I'm running into the same issue with some code that would like to do round-trip
serialization of a datastructure (which doesn't need 100% generality of
supported values but would like to deal with the existing structure of types).
Dealing with set is easy, for example:
def default(obj): # pass to default parameter of json.dumps
if isinstance(obj, frozenset):
return {'_class': 'set', 'items': list(obj)}
...
def object_hook(obj): # pass to object_hook parameter of json.loads
if obj.get('_class') == 'set':
return set(decoded_dict['items'])
...
But you can't do the equivalent thing for tuple, even if you override
encode/iterencode. It seems like the JSON module is making performance versus
generality tradeoffs, it doesn't make a fresh call to encode/iterencode for
every dict key/value for example. Which is fine, but it would be nice if there
was a mode that allowed getting custom behavior for every type, taking the
performance cost.
--
nosy: +sfreilich
___
Python tracker
<https://bugs.python.org/issue12657>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12657] Cannot override JSON encoding of basic type subclasses
Samuel Freilich added the comment: A fully general solution for this might require a separate way to override the behavior for serializing dict keys (since those have to be serialized as strings). -- ___ Python tracker <https://bugs.python.org/issue12657> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43747] Can't create new interpreter in multi thread
Change by Samuel Thibault : -- nosy: +samuel-thibault ___ Python tracker <https://bugs.python.org/issue43747> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43793] [C API] Py_NewInterpreter() cannot be called from a thread which has no Python thread state
Change by Samuel Thibault : -- nosy: +samuel-thibault ___ Python tracker <https://bugs.python.org/issue43793> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43747] Can't create new interpreter in multi thread
Samuel Thibault added the comment: I don't see how to reopen this, we'd probably want to mark it as a duplicate of the newly-opened https://bugs.python.org/issue43793 , see https://mail.python.org/archives/list/capi-...@python.org/thread/7FI6V2KFBFZIXC6LZLKHY4Z7TUJ6YWTX/ -- ___ Python tracker <https://bugs.python.org/issue43747> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44321] os.EX_OK for Windows
New submission from Samuel Marks : Since Python 2.3 alpha 2 [19-Feb-2003] `EX_OK` has existed… but only for Unix. This adds support for Windows. -- components: Windows messages: 395203 nosy: paul.moore, samuelmarks, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: os.EX_OK for Windows type: enhancement ___ Python tracker <https://bugs.python.org/issue44321> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44321] os.EX_OK for Windows
Change by Samuel Marks : -- keywords: +patch pull_requests: +25147 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26559 ___ Python tracker <https://bugs.python.org/issue44321> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44321] os.EX_OK for Windows
Samuel Marks added the comment: `EXIT_SUCCESS` is defined in `stdlib.h`, as per https://docs.microsoft.com/en-us/cpp/c-runtime-library/exit-success-exit-failure (following the standard https://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdlib.h.html) There are also https://docs.microsoft.com/en-us/cpp/c-runtime-library/errno-constants which has many equivalents to the `` (in ``). Kinda related: https://bugs.python.org/issue24053 -- ___ Python tracker <https://bugs.python.org/issue44321> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44402] Python 3.9 and 3.10 fails to install in WINE
New submission from Samuel Marks :
What works:
- python-3.7.9.exe python-3.8.9.exe
What fails:
- python-3.10.0b2.exe python-3.9.5.exe
(I'm debugging some regressions on my test suite… macOS and Linux [incl. in
Docker] work, Windows fails)
How to reproduce (macOS):
0. Install WINE (crossover)
https://github.com/Gcenx/homebrew-wine#how-to-install-using-brew
1. wine python-.exe /quiet /passive /log c:/p.log
TargetDir=C:/python- InstallAllUsers=1 Include_doc=0 Include_debug=0
Include_dev=0 Include_exe=1 Include_launcher=0 Include_lib=1 Include_pip=1
Include_symbols=0 Include_tcltk=0 Include_test=0 Include_tools=0
2. curl https://bootstrap.pypa.io/get-pip.py -o http://get-pip.py
3. wine "C:\\python-\\python.exe" http://get-pip.py
(replacing ``; obviously)
Error:
```
000b:fixme:thread:create_user_shared_data_thread Creating user shared data
update thread.
000d:fixme:thread:create_user_shared_data_thread Creating user shared data
update thread.
0010:fixme:thread:create_user_shared_data_thread Creating user shared data
update thread.
0017:fixme:thread:create_user_shared_data_thread Creating user shared data
update thread.
001d:err:plugplay:process_IOService_Device object 0x9203
001d:err:plugplay:process_IOService_Device Unable to create plug in interface
for USB deviceobject 0x9207
001f:fixme:thread:create_user_shared_data_thread Creating user shared data
update thread.
0009:fixme:heap:RtlSetHeapInformation 0x0 1 0x0 0 stub
0025:fixme:thread:create_user_shared_data_thread Creating user shared data
update thread.
0009:fixme:ntdll:NtQueryInformationToken QueryInformationToken( ...,
TokenElevation, ...) semi-stub
0009:fixme:ntdll:NtQueryInformationToken QueryInformationToken( ...,
TokenElevation, ...) semi-stub
0009:fixme:advapi:DecryptFileW
(L"C:\\windows\\Temp\\{FDB2F91C-29EE-4A75-AAA5-39F402CF12ED}\\", ): stub
002b:fixme:heap:RtlSetHeapInformation 0x0 1 0x0 0 stub
002b:fixme:ntdll:NtQueryInformationToken QueryInformationToken( ...,
TokenElevation, ...) semi-stub
002b:fixme:ntdll:NtQueryInformationToken QueryInformationToken( ...,
TokenElevation, ...) semi-stub
002b:fixme:advapi:DecryptFileW
(L"C:\\windows\\Temp\\{3F224591-5EEC-4431-8291-2450B9ECC110}\\", ): stub
002e:fixme:shell:SHAutoComplete stub
002b:fixme:ver:GetCurrentPackageId (0x31fd04 0x0): stub
0009:fixme:ver:GetCurrentPackageId (0x31fd04 0x0): stub
```
Expected (`uniq` output of a successful install of 3.8):
```
000b:fixme:thread:create_user_shared_data_thread Creating user shared data
update thread.
000d:fixme:thread:create_user_shared_data_thread Creating user shared data
update thread.
0010:fixme:thread:create_user_shared_data_thread Creating user shared data
update thread.
0017:fixme:thread:create_user_shared_data_thread Creating user shared data
update thread.
001d:err:plugplay:process_IOService_Device object 0x6a03
001d:err:plugplay:process_IOService_Device Unable to create plug in interface
for USB deviceobject 0x6a07
001f:fixme:thread:create_user_shared_data_thread Creating user shared data
update thread.
0009:fixme:heap:RtlSetHeapInformation 0x0 1 0x0 0 stub
0025:fixme:thread:create_user_shared_data_thread Creating user shared data
update thread.
0009:fixme:ntdll:NtQueryInformationToken QueryInformationToken( ...,
TokenElevation, ...) semi-stub
0009:fixme:advapi:DecryptFileW
(L"C:\\windows\\Temp\\{86717C64-3933-4B4D-9283-CEA5CD0F5EBB}\\", ): stub
002b:fixme:heap:RtlSetHeapInformation 0x0 1 0x0 0 stub
002b:fixme:ntdll:NtQueryInformationToken QueryInformationToken( ...,
TokenElevation, ...) semi-stub
002b:fixme:advapi:DecryptFileW
(L"C:\\windows\\Temp\\{9A024DD0-BF6A-4DF1-A034-C61E89E6F711}\\", ): stub
002e:fixme:shell:SHAutoComplete stub
002b:fixme:advapi:DecryptFileW
(L"C:\\windows\\Temp\\{9A024DD0-BF6A-4DF1-A034-C61E89E6F711}\\", ): stub
002b:fixme:exec:SHELL_execute flags ignored: 0x0100
0030:fixme:heap:RtlSetHeapInformation 0x0 1 0x0 0 stub
0030:fixme:ntdll:NtQueryInformationToken QueryInformationToken( ...,
TokenElevation, ...) semi-stub
0030:fixme:ole:CoInitializeSecurity
(0031F458,-1,,,6,2,,12288,) - stub!
0030:fixme:wuapi:automatic_updates_Pause
0030:fixme:sfc:SRSetRestorePointW 0031F320 0031F530
0033:fixme:advapi:DecryptFileW (L"C:\\ProgramData\\Package
Cache\\{3854F8D0-6FA6-4227-8047-8DE95B0A7DE7}v3.8.9150.0\\core.msi", ):
stub
0030:fixme:ntdll:NtLockFile I/O completion on lock not implemented yet
0033:fixme:advapi:DecryptFileW (L"C:\\ProgramData\\Package
Cache\\{A3ED59F7-FC59-4793-AEBC-9D3813922BE1}v3.8.9150.0\\exe.msi", ):
stub
0030:fixme:ntdll:NtQuerySystemInformation info_class
SYSTEM_PERFORMANCE_INFORMATION
0030:err:mscoree:LoadLibraryShim error reading registry key for installroot
0033:fixme:advapi:DecryptFileW (L"C:\\ProgramData\\Package
Cache\\{D12B4386-129A-4C17-AB8D-45FD90C6EB0D}v3.8.9150.0\\li
[issue44470] 3.11 docs.python.org in Polish not English?
New submission from Samuel Marks : It's been too long since my family have been Polish! (see screenshot of https://docs.python.org/3.11/library/parser.html ) My computer is only configured for English. Running Firefox 90.0b9 (64-bit) on macOS 11.4 (20F71). -- assignee: docs@python components: Documentation files: Screen Shot 2021-06-21 at 4.49.27 pm.png messages: 396207 nosy: docs@python, samuelmarks priority: normal severity: normal status: open title: 3.11 docs.python.org in Polish not English? type: behavior versions: Python 3.11 Added file: https://bugs.python.org/file50122/Screen Shot 2021-06-21 at 4.49.27 pm.png ___ Python tracker <https://bugs.python.org/issue44470> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44470] 3.11 docs.python.org in Polish not English?
Samuel Marks added the comment: Yep exactly like my screenshot but now the Polish has turned Korean… my family was never Korean! -- ___ Python tracker <https://bugs.python.org/issue44470> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32732] LoggingAdapter ignores extra kwargs of Logger#log()
Samuel Henrique added the comment:
Hello Vinay Sajip,
I would like to kindly ask you to please reconsider and give your thoughts on
my description of the issue here.
Let me try to work based on your last reply:
> ...has been around since Jan 2008, and it seems that no one in that time has
> raised this as a must-have
This is a fair statement and it certainly shows that this is not a big enough
issue for enough people to complain about. I believe it falls into the
"papercut" category of issues and people just override the "process" method
when they hit it.
> 1. If you want to pass different kwargs in every time, use a logger.
> 2. If you want to pass particular contextual information in which fits the
> "extra" parameter approach, use a LoggerAdapter.
> 3. If that doesn't do it for you, subclass LoggerAdapter and implement what
> you need.
We could improve the logging library by removing the limitation #1 with no
apparent downsides, so please bear with me for my example below.
> You haven't really explained why you need this to work in this particular
> way, so I suspect it could be an XY problem.
So Steffen Schuldenzucker already provided an use case, I have one which is
very similar and hopefully easily recognizable as a common (or at least not
rare) usage pattern of logging:
As a logging user, I would like to have a set of extra keys in the formatter,
some required and some optional, such that I can make use of LoggerAdapter to
set the constant extra values only once, and still pass the dynamic extra
values on each "log" method.
Pseudo code:
# assume logger is a logger object with a formatter that allows for dynamic
extra keys (dynamic = optional extra keys)
adapted_logger = logging.LoggerAdapter(logger, extra={"invocation_id":
"invocation_id_value"})
adapted_logger.info("test", extra={"resource_owner": "resource_owner_value"})
In this example I expect the log entry to contain both extra keys:
"invocation_id" and "resource_owner". invocation_id is reused in every log
entry but resource_owner changes based on what's being processed.
For reference, this is an example of a Formatter which allows for dynamic extra
keys and formats log entries to json serialized strings:
class ExtraFormatter(logging.Formatter):
"""
Dynamically adds any extra key to a json-like output.
"""
def format(self, record: logging.LogRecord) -> str:
default_attrs = vars(
logging.LogRecord(None, None, None, None, None, None, None)
).keys()
extras = set(record.__dict__.keys()) - set(default_attrs)
log_items = {"message": "%(message)s"}
for attr in extras:
log_items[attr] = f"%({attr})s"
format_str = json.dumps(log_items)
self._style._fmt = format_str
return super().format(record)
The reason I believe this is a papercut type of issue is that I would expect
the Formatter to control whether or not to show the extra key, not the
LoggerAdapter. It is counter intuitive to me that the LoggerAdapter would
silently drop any extra keys provided to the log methods, and I would expect
that LoggerAdapter would at least not allow for the parameter to be passed then
(I don't like this alternative either, but it removes the feeling of being
tricked).
Again, this is a problem that can easily be workaround-ed by overriding the
"process" method. But there seems to be a very good opportunity to improve the
Adapter instead and avoid letting other people hit this issue. I'm curious
about your opinion on any downsides to this change as I couldn't come up with
anything.
There is also a problem with the current documentation, in which the
LoggerAdapter doc led me (and other people, when we had to debug this issue) to
believe the Adapter would not silently drop the extra parameters. The only
place where this behavior is mentioned is in the logging-cookbook, in the
following part:
"Of course, if you had passed an ‘extra’ keyword argument in the call to the
adapter, it will be silently overwritten."
The "Of course" part is a little bit weird cause it implies it's an obvious
behavior, whereas the sentence just before this one says: "The default
implementation of this method leaves the message alone, but inserts an ‘extra’
key in the keyword argument whose value is the dict-like object passed to the
constructor.". Note how it uses the word "inserts" instead of "overrides".
So the documentation has to be updated, either to mention this behavior in the
LoggerAdapter documentation or to remove the part about extra being silently
overwritten in the cookbook, the only place this is mentioned (if this gets
changed).
[issue44825] node.annotation is not a str in `ast`'s `class _Unparser(NodeVisitor)`
New submission from Samuel Marks :
I tried making `node.annotation` an `ast.Name("str", ast.Load())`, which worked
but when the AST was unparsed to a string it shows as `# type: `.
https://github.com/offscale/cdd-python/runs/3213864077
Replicate with:
```
unparse(Assign(annotation=None, simple=1, targets=[Name("foo", Store())],
value=Constant(value=5, kind=None), expr=None, expr_targe
...: t=None, expr_annotation=None, type_comment=Name('str', Load()),
lineno=None))
```
Checking what it expects, it does expect a str. E.g.,:
```
$ python3.9 -c 'import ast; tc=ast.parse("foo = 5 # type: int",
type_comments=True).body[0].type_comment; print("type_comment is a",
type(tc).__name__, "with value", tc)'
type_comment is a str with value int
```
But when I do make it a str and unparse it, I get:
```
File "/opt/python3.10/lib/python3.10/ast.py", line 1674, in unparse
return unparser.visit(ast_obj)
File "/opt/python3.10/lib/python3.10/ast.py", line 808, in visit
self.traverse(node)
File "/opt/python3.10/lib/python3.10/ast.py", line 799, in traverse
super().visit(node)
File "/opt/python3.10/lib/python3.10/ast.py", line 410, in visit
return visitor(node)
File "/opt/python3.10/lib/python3.10/ast.py", line 1005, in visit_FunctionDef
self._function_helper(node, "def")
File "/opt/python3.10/lib/python3.10/ast.py", line 1023, in _function_helper
self._write_docstring_and_traverse_body(node)
File "/opt/python3.10/lib/python3.10/ast.py", line 816, in
_write_docstring_and_traverse_body
self.traverse(node.body)
File "/opt/python3.10/lib/python3.10/ast.py", line 797, in traverse
self.traverse(item)
File "/opt/python3.10/lib/python3.10/ast.py", line 799, in traverse
super().visit(node)
File "/opt/python3.10/lib/python3.10/ast.py", line 410, in visit
return visitor(node)
File "/opt/python3.10/lib/python3.10/ast.py", line 879, in visit_AnnAssign
self.traverse(node.annotation)
File "/opt/python3.10/lib/python3.10/ast.py", line 799, in traverse
super().visit(node)
File "/opt/python3.10/lib/python3.10/ast.py", line 410, in visit
return visitor(node)
File "/opt/python3.10/lib/python3.10/ast.py", line 414, in generic_visit
for field, value in iter_fields(node):
File "/opt/python3.10/lib/python3.10/ast.py", line 252, in iter_fields
for field in node._fields:
AttributeError: 'str' object has no attribute '_fields'
```
--
messages: 398878
nosy: samuelmarks
priority: normal
severity: normal
status: open
title: node.annotation is not a str in `ast`'s `class _Unparser(NodeVisitor)`
versions: Python 3.10, Python 3.11, Python 3.9
___
Python tracker
<https://bugs.python.org/issue44825>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44825] node.annotation is not a str in `ast`'s `class _Unparser(NodeVisitor)`
Samuel Marks added the comment: Hmm, debugging my test and I was able to replicate it with this smaller one: ``` from ast import FunctionDef, arguments, Load, Name, AnnAssign, Store, BinOp, Add, unparse unparse(FunctionDef(args=arguments(args=[], defaults=[], kw_defaults=[], kwarg=None, kwonlyargs=[], posonlyargs=[], vararg=None), body=[AnnAssign(annotation='int', simple=1, target=Name(ctx=Store(), id='res'), value=BinOp(left=Name(ctx=Load(), id='a'), op=Add(), right=Name(ctx=Load(), id='b')))], decorator_list=[], name='sum', returns=None, lineno=None, type_comment=None)) ``` Which for some reason has made the `annotation` a `str` rather than `Name`. So I think it's my bug then? -- ___ Python tracker <https://bugs.python.org/issue44825> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44825] node.annotation is not a str in `ast`'s `class _Unparser(NodeVisitor)`
Samuel Marks added the comment: Fixed with https://github.com/offscale/cdd-python/commit/079dc28 -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue44825> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45108] frame.f_lasti points at DICT_MERGE instead of CALL_FUNCTION_EX in Windows only
Samuel Colvin added the comment: Perhaps worth adding that the tests don't fail on python 3.6, 3.7 or 3.8. -- nosy: +samuelcolvin ___ Python tracker <https://bugs.python.org/issue45108> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45544] Close 2to3 issues and list them here
Change by Samuel Tatasurya : -- keywords: +patch nosy: +samtatasurya nosy_count: 1.0 -> 2.0 pull_requests: +27381 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17096 ___ Python tracker <https://bugs.python.org/issue45544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38830] `A Qt GUI for logging` produces TypeError
New submission from Samuel Mathias : On the "logging cookbook" page: https://docs.python.org/3/howto/logging-cookbook.html#logging-cookbook The recipe "A Qt GUI for logging" produces the following error: `TypeError: update_status() missing 1 required positional argument: 'record'` -- assignee: docs@python components: Documentation messages: 356808 nosy: Samuel Mathias, docs@python priority: normal severity: normal status: open title: `A Qt GUI for logging` produces TypeError type: crash versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue38830> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42699] Use `.join(k for k in g)` instead of `.join([k for k in g])`
New submission from Samuel Marks : This is an extremely minor improvement. Rather than create a `list`—using a comprehension—then have it consumed by `.join`, one can skip the list construction entirely. (I remember this working from at least Python 2.7… probably earlier also) -- messages: 383474 nosy: samuelmarks priority: normal pull_requests: 22737 severity: normal status: open title: Use `.join(k for k in g)` instead of `.join([k for k in g])` type: performance versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42699> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42699] Use `.join(k for k in g)` instead of `.join([k for k in g])`
Samuel Marks added the comment: @eric.smith No benchmarks offhand, but I'd expect it to be a very minor improvement (if detectable). If this gets accepted I'll probably do a bunch of little changes like this, to improve things, e.g., replace '%' with '.format' (or f-strings, whatever you prefer), ensure `.iterkeys()`/`.iteritems()` validity, and collapse some obvious `.append` cases with list comprehensions. The idea I'm going off is that when one is debugging their Python code, and it goes across to the Python source, that that Python source code quality is better or equal to the one the higher-level Python developer is creating. Constructing unnecessary lists is one such code quality issue. -- ___ Python tracker <https://bugs.python.org/issue42699> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42699] Use `.join(k for k in g)` instead of `.join([k for k in g])`
Samuel Marks added the comment: Yeah I hear ya, was just trying for the most concise issue title. I tend to [over]use `map`, `filter`, `filterfalse` and other `itertools` and `operator` methods in my own codebase. Surprised with that result, that using an explicit list is actually faster. Seems like an obvious* micro-optimisation. *But don't want to say that unless I'm actually maintaining/contributing-to your C code. It's also surprising—last time I checked—that lists are faster to construct than tuples. When I create codebases or maintain other peoples, I try and: - remove all unnecessary mutability (incl. replacing lists with tuples); - flatten `.append` occurrences into generator comprehensions or map; - remove all indentation creating for-loops, replacing with comprehensions or map and functions or lambdas - combine generators rather than concatenate lists; The general idea here is to evaluate at the time of computation, and be lazy everywhere else. So searching the whole codebase for lists and other mutable structures is a good first step. But maybe with efficiency losses, like shown here, means that this would only aid [maybe] in readability, understandability, traceability & whatever other functional -ility; but not performance? :( -- ___ Python tracker <https://bugs.python.org/issue42699> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42699] Use `.join(k for k in g)` instead of `.join([k for k in g])`
Samuel Marks added the comment: Wait I don't understand why you wouldn't accept a wholesale replacement of all `%` and `format` with f-strings through the entire CPython codebase [master branch]? BTW: Kinda unrelated, but would be great to have perspective on this little project - https://github.com/SamuelMarks/doctrans - I'm interested in wholesale enforcement of code consistency and translating between constructs (e.g., dataclass to/fro argparse to/fro class method; ReST to/fro Google to/fro NumPy dostrings; inline types to/fro types in docstrings; with more planned) -- ___ Python tracker <https://bugs.python.org/issue42699> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42699] Use `.join(k for k in g)` instead of `.join([k for k in g])`
Samuel Marks added the comment: I suppose that's a good justification to never improve/upgrade the syntax and quality of the codebase. In terms of automatic upgrades of the codebase, one could always replicate the approach I use in doctrans—i.e., use of `ast` and/or `inspect`—to automatically upgrade syntax from `%` and `.format` to use f-strings. Would that be acceptable? -- ___ Python tracker <https://bugs.python.org/issue42699> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42699] Use `.join(k for k in g)` instead of `.join([k for k in g])`
Samuel Marks added the comment: EDIT: Just found https://github.com/ikamensh/flynt -- ___ Python tracker <https://bugs.python.org/issue42699> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42699] Use `.join(k for k in g)` instead of `.join([k for k in g])`
Samuel Marks added the comment: There were only 12k occurrences, I'm sure I could manually go through that in an afternoon. Would you accept it then? On Tue, 22 Dec 2020, 12:22 am Eric V. Smith, wrote: > > Eric V. Smith added the comment: > > See https://github.com/ikamensh/flynt#dangers-of-conversion for reasons. > > Would I like to see all string literal formatting done with f-strings? Yes! > > Would I accept the risk and hassle of doing it blindly? No. > > -- > > ___ > Python tracker > <https://bugs.python.org/issue42699> > ___ > -- nosy: +SamuelMarks ___ Python tracker <https://bugs.python.org/issue42699> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43203] Default value incorrectly read with unittests on Windows & macOS but not Linux
New submission from Samuel Marks : Had a couple of commits to try and fix it on GitHub Actions (as I was unable to replicate locally), ended up with this very easy fix for Windows: https://github.com/SamuelMarks/doctrans/commit/98203e9fee3e0a888ab1f4128011dde5fad98f63 To completely remove the default value. The only thing I can assume happened is that a different test in the same class—which set the default value to something else—changed the default value of the function. This was all very confusing, and I can only think it to be a bug on python, or in GitHub Actions deployment thereof. PS: The macOS builds are still failing with the previous issue :\ -- components: Windows, macOS messages: 386845 nosy: ned.deily, paul.moore, ronaldoussoren, samuelmarks, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Default value incorrectly read with unittests on Windows & macOS but not Linux versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43203> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43339] Could not build the ssl module! | macOS with `CPPFLAGS` and `LDFLAGS` set
New submission from Samuel Marks : I was on 3.10a4 on macOS 11.1 for ages, finally decided to upgrade to a5, building from source. With latest `brew install openssl zlib`. ``` $ export LDFLAGS='-L/usr/local/opt/openssl@1.1/lib -L/usr/local/opt/zlib/lib' $ export CPPFLAGS='-I/usr/local/opt/openssl@1.1/include -I/usr/local/opt/zlib/include' $ ./configure --enable-optimizations --prefix /opt/python3.10 ``` I suppose I could set this which I forgot, but I doubt it's the problem, unless pkg_config is how the CPython build system find OpenSSL? ``` export PKG_CONFIG_PATH='/usr/local/opt/openssl@1.1/lib/pkgconfig' ``` Error: ``` Python build finished successfully! The necessary bits to build these optional modules were not found: _hashlib _ssl ossaudiodev spwd To find the necessary bits, look in setup.py in detect_modules() for the module's name. The following modules found by detect_modules() in setup.py, have been built by the Makefile instead, as configured by the Setup files: _abc pwd time Could not build the ssl module! Python requires an OpenSSL 1.0.2 or 1.1 compatible libssl with X509_VERIFY_PARAM_set1_host(). LibreSSL 2.6.4 and earlier do not provide the necessary APIs, https://github.com/libressl-portable/portable/issues/381 ``` Happy to test alternative configurations -- components: Build messages: 38 nosy: samuelmarks priority: normal severity: normal status: open title: Could not build the ssl module! | macOS with `CPPFLAGS` and `LDFLAGS` set versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43339> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43339] Could not build the ssl module! | macOS with `CPPFLAGS` and `LDFLAGS` set
Samuel Marks added the comment: Nevermind it actually was that missing `PKG_CONFIG_PATH` line… -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue43339> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41114] "TypeError: unhashable type" could often be more clear
New submission from Samuel Freilich : Currently, if you (for example) put a dict as a value in a set or key in a dict, you get: TypeError: unhashable type: 'dict' I'm pretty sure this wording goes back a long time, but I've noticed that Python beginners tend to find this really confusing. It fits into a pattern of error messages where you have to explain why the error message is worded the way it is after you explain why the error message occurs at all. There are many instances of: https://stackoverflow.com/questions/13264511/typeerror-unhashable-type-dict It would be clearer if the message was something like: TypeError: 'dict' can not be used as a set value because it is an unhashable type. (Or "dict key" instead of "set value".) The exception is raised in PyObject_Hash, so that doesn't have some of the context about how/why hash was called. That's called in a lot of places. Possibly, PyObject_Hash and PyObject_HashNotImplemented could take the format string passed to PyErr_Format as an optional second argument, defaulting to the current behavior? Then certain callers (in particular, the set and dict constructor, set and dict methods that add set values or add/modify dict keys) could provide clearer error messages. -- messages: 372366 nosy: sfreilich priority: normal severity: normal status: open title: "TypeError: unhashable type" could often be more clear type: behavior ___ Python tracker <https://bugs.python.org/issue41114> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41819] Fix some compiler warnings
New submission from Samuel Marks : https://github.com/SamuelMarks/cpython/tree/3.9-compiler-fixes -- components: Build messages: 377205 nosy: samuelmarks priority: normal pull_requests: 21373 severity: normal status: open title: Fix some compiler warnings type: compile error versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue41819> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41819] Fix some compiler warnings
Samuel Marks added the comment:
Okay I'll redo it on master, here is my config, on macOS 10.15.6:
```
$ export PKG_CONFIG_PATH="/usr/local/opt/openssl@1.1/lib/pkgconfig"
$ export CPPFLAGS="-I/usr/local/opt/openssl@1.1/include"
$ export LDFLAGS="-L/usr/local/opt/openssl@1.1/lib"
$ export CPPFLAGS="-I/usr/local/opt/zlib/include $CPPFLAGS"
$ export LDFLAGS="-L/usr/local/opt/zlib/lib $LDFLAGS"
$ gcc --version && clang --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 12.0.0 (clang-1200.0.32.2)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
Apple clang version 12.0.0 (clang-1200.0.32.2)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
$ ./configure --enable-optimizations --prefix /opt/python3-master
$ ./configure --enable-optimizations --prefix /opt/python3-master
checking for git... found
checking build system type... x86_64-apple-darwin19.6.0
checking host system type... x86_64-apple-darwin19.6.0
checking for python3.10... no
checking for python3... python3
checking for --enable-universalsdk... no
checking for --with-universal-archs... no
checking MACHDEP... "darwin"
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
[… omitted for brevity]
$ make
```
With these warnings being addressed by this bug report and PR:
```
gcc -c -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-generate -I./Include/internal -I. -I./Include
-I/usr/local/opt/zlib/include -I/usr/local/opt/openssl@1.1/include
-I/usr/local/opt/zlib/include -I/usr/local/opt/openssl@1.1/include
-DPy_BUILD_CORE \
-DPLATLIBDIR='"lib"' \
-o Python/initconfig.o ./Python/initconfig.c
./Python/initconfig.c:2677:38: warning: format specifies type 'wint_t' (aka
'int') but the argument has type 'unsigned int' [-Wformat]
PySys_WriteStderr("%lc", ch);
~~~ ^~
%c
1 warning generated.
```
Looks like someone else has already picked up the other bug. So opened a new PR
for this.
--
___
Python tracker
<https://bugs.python.org/issue41819>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41819] Fix some compiler warnings
Change by Samuel Marks : -- keywords: +patch pull_requests: +21376 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22332 ___ Python tracker <https://bugs.python.org/issue41819> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41114] "TypeError: unhashable type" could often be more clear
Samuel Freilich added the comment: > The user already knows The example I link to in the initial description appears to be one case where the user does not in fact know. I do think context that this restriction applies to dict key in particular is very relevant. The line could use the same type for both the key and the value in a dict assignment, for example. > TypeError: unhashable type: 'dict'. Consider using an int, str, tuple, or > frozenset. That seems like a pretty reasonable wording, though I think mentioning "dictionary key" or "set item" specifically still helps. It could also link to the documentation directly: https://docs.python.org/3/glossary.html#term-hashable Though other error messages don't generally follow that pattern. > Saying it twice doesn't help. As the comment you were responding to noted, putting it in the type implies there might be additional information in documentation (or at least provides a place in documentation to put that information). TypeError is too general to say something about that specifically: https://docs.python.org/3/library/exceptions.html#TypeError -- ___ Python tracker <https://bugs.python.org/issue41114> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41114] "TypeError: unhashable type" could often be more clear
Samuel Freilich added the comment: > No minor tweak to the exception message will make this go away. For > understanding to occur, the only way to forward is to learn a bit about > hashability. That is a step that every beginner must take. This is a derisive and beginner-hostile response that ignores half of what's been said by other participants in this thread. > Also the error message itself is easily Googled Yeah, the first thing that comes up is ~4k Stack Overflow entries where people are really confused by the error message. -- ___ Python tracker <https://bugs.python.org/issue41114> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41114] "TypeError: unhashable type" could often be more clear
Samuel Freilich added the comment: > I think it's reasonable to discuss the problem on python-ideas rather than on > a bugs issue, when it's not obvious what the right solution is. I did start a thread there. Don't object to that, if that's a better forum for this sort of thing. -- ___ Python tracker <https://bugs.python.org/issue41114> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41114] "TypeError: unhashable type" could often be more clear
Samuel Freilich added the comment: python-ideas thread: https://mail.python.org/archives/list/python-id...@python.org/thread/B6OMGYIM47OVGOCZLEY3MEUJDFURJRDV/ The most minimal ideas from that seem to be: 1. Maybe link to the glossary from the error message (if links to documentation in error messages are permissible). 2. Add a glossary entry for "unhashable" for the sake of completeness (similar to how there are entries for both "immutable" and "mutable"). -- ___ Python tracker <https://bugs.python.org/issue41114> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42229] Fix SQLite warnings on macOS
New submission from Samuel Marks : Planned to fix all the compiler warnings on macOS. Ended up just fixing this SQLite one: ``` Python-3.9.0/Modules/_sqlite/connection.c:1066:9: warning: 'sqlite3_trace' is deprecated: first deprecated in macOS 10.12 [-Wdeprecated-declarations] sqlite3_trace(self->db, 0, (void*)0); ^ sqlite3_trace_v2 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sqlite3.h:3022:36: note: 'sqlite3_trace' has been explicitly marked deprecated here SQLITE_API SQLITE_DEPRECATED void *sqlite3_trace( ^ Python-3.9.0/Modules/_sqlite/connection.c:1069:9: warning: 'sqlite3_trace' is deprecated: first deprecated in macOS 10.12 [-Wdeprecated-declarations] sqlite3_trace(self->db, _trace_callback, trace_callback); ^ sqlite3_trace_v2 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sqlite3.h:3022:36: note: 'sqlite3_trace' has been explicitly marked deprecated here SQLITE_API SQLITE_DEPRECATED void *sqlite3_trace( ^ ``` Note that: `sqlite3_enable_shared_cache` should be removed from `Modules/_sqlite/module.c` also, as warning and guide says: https://www.sqlite.org/c3ref/enable_shared_cache.html ``` Python-3.9.0/Modules/_sqlite/module.c:147:10: warning: 'sqlite3_enable_shared_cache' is deprecated: first deprecated in macOS 10.7 - Not supported [-Wdeprecated-declarations] ``` But I think that would require a major version change, so let's keep that warning fix to one side. Same with the tk issues, as per https://bugs.python.org/issue41016 ; although I suspect there's a way to quiet the warnings here… -- components: Build messages: 380126 nosy: samuelmarks priority: normal pull_requests: 21992 severity: normal status: open title: Fix SQLite warnings on macOS type: compile error versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue42229> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42229] Fix SQLite warnings on macOS
Samuel Marks added the comment: Yes, this commit extends his changes to include macOS support (for some reason that SQLite version check doesn’t work properly on macOS; so this checks the macOS version, knowing AOT when SQLite trace v1 APIs were deprecated. Curious that `sqlite3_enable_shared_cache` is in the ‘wontfix’ category… why is this? -- ___ Python tracker <https://bugs.python.org/issue42229> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42229] Fix SQLite warnings on macOS
Samuel Marks added the comment: @erlendaasland Hmm… just double-checked, and this issue is present on Python 3.8.6 and 3.9.0 but not master [d3b4e068077dd26927ae7485bd0303e09d962c02] as you referenced. Should I close this issue—and PR—then? - Backport from master to these? -- ___ Python tracker <https://bugs.python.org/issue42229> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42229] Fix SQLite warnings on macOS
Samuel Marks added the comment: 👌 -- ___ Python tracker <https://bugs.python.org/issue42229> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42229] Fix SQLite warnings on macOS
Change by Samuel Marks : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue42229> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42241] Backport SQLite trace API v2
New submission from Samuel Marks : Backports https://github.com/python/cpython/pull/19581 https://bugs.python.org/issue40318 as per https://bugs.python.org/issue42229 -- components: Build messages: 380185 nosy: samuelmarks priority: normal pull_requests: 22011 severity: normal status: open title: Backport SQLite trace API v2 type: compile error versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue42241> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42242] Backport SQLite trace API v2
New submission from Samuel Marks : Backports https://github.com/python/cpython/pull/19581 https://bugs.python.org/issue40318 as per https://bugs.python.org/issue42229 See also 3.9 backporting: https://bugs.python.org/issue42241 [not sure if this is how you do backporting, a new issue and GH PR for each supported release tag?] -- components: Build messages: 380186 nosy: samuelmarks priority: normal pull_requests: 22013 severity: normal status: open title: Backport SQLite trace API v2 type: compile error versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue42242> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42229] Fix SQLite warnings on macOS
Samuel Marks added the comment: Opened two issues and two PRs for 3.8 and 3.8: - https://bugs.python.org/issue42241 - https://bugs.python.org/issue42242 -- ___ Python tracker <https://bugs.python.org/issue42229> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40318] Migrate to SQLite3 trace v2 API
Change by Samuel Marks : -- nosy: +samuelmarks nosy_count: 4.0 -> 5.0 pull_requests: +22019 pull_request: https://github.com/python/cpython/pull/23102 ___ Python tracker <https://bugs.python.org/issue40318> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40318] Migrate to SQLite3 trace v2 API
Change by Samuel Marks : -- pull_requests: +22020 pull_request: https://github.com/python/cpython/pull/23103 ___ Python tracker <https://bugs.python.org/issue40318> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42242] Backport SQLite trace API v2
Samuel Marks added the comment: Done, thanks for the how-to: - https://github.com/python/cpython/pull/23103 [3.8] - https://github.com/python/cpython/pull/23102 [3.9] -- ___ Python tracker <https://bugs.python.org/issue42242> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41810] Consider reintroducing `types.EllipsisType` for the sake of typing
Samuel Marks added the comment: Since we're bringing these back, would you accept a backport of these types? [I'm writing a bunch of parsers/emitters—and starting to maintain an old runtime type-checker—for 3.6+] -- nosy: +samuelmarks ___ Python tracker <https://bugs.python.org/issue41810> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13889] str(float) and round(float) issues with FPU precision
New submission from Samuel Iseli : We are using python as an embedded scripting environment in our ERP-product. Since upgrading to python2.7 we have serious issues with floats: >>> 28710.0 '2870:.0' >>> round(28710.0) 2870.0 We are embedding Python in a Delphi-application. The problem was already discussed in issue9980 and has to do with Delphi setting the FPU precision to 64bit (and relying on this setting) while the standard with Microsoft Tools is 53bits. The routines _Py_dg_dtoa and _Py_dg_strtod in dtoa.c rely on the FPU precision set to 53bits. Issue9980 was closed as "won't fix" but I propose to reconsider this decision for the following reasons: - Delphi is still an important development environment for native win32 applications and has excellent Python embedding support through PythonForDelphi (http://code.google.com/p/python4delphi). - Ensuring 53bit before calling python code is not practical in an embedded python environment with extensions in delphi (python may also call code that is implemented in delphi). - The changes needed in pythoncore are minimal. Tests documented in issue9980 found no measurable performance impact. - FPU precision switching is needed and already (partially) implemented for linx, where 64bit prec is standard. Fixing this issues is absolutely vital for us, so we needed to compile a custom version of pythoncore. I appended a .diff file detailling the patch. Changes are needed in 2 places: - pyport.h, defining the _PY_SET_53_BIT_PRECISION macros for MS visual c compiler - floatobject.c, insert precision switching macros in _Py_double_round function. In pystrtod.c the precision switching macros are already used. pystrtod.c and floatobject.c are the only places in CPython where the dtoa.c functions are called. The macros for visual-c are activated by defining HAVE_VC_FUNC_FOR_X87 preprocessor-symbol. Hoping for inclusion of this patch. Cheers Samuel -- components: Interpreter Core files: 120127_float_dtoa_fix_py2.7.2.diff keywords: patch messages: 152099 nosy: samuel.iseli priority: normal severity: normal status: open title: str(float) and round(float) issues with FPU precision versions: Python 2.7, Python 3.1 Added file: http://bugs.python.org/file24341/120127_float_dtoa_fix_py2.7.2.diff ___ Python tracker <http://bugs.python.org/issue13889> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13889] str(float) and round(float) issues with FPU precision
Samuel Iseli added the comment: Hi Marc, the changes to the pythoncore.vcproj Visual-Studio file define the HAVE_VC_FUNC_FOR_X87 symbol. I use this symbol to enable the precision-setting macros in pyport.h. I made this similar to the existing code for gcc (linux). You can change this but currently this symbol has to be defined somewhere for the macros to have an effect. -- ___ Python tracker <http://bugs.python.org/issue13889> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13889] str(float) and round(float) issues with FPU precision
Samuel Iseli added the comment: I would definitely classify this as a bug in Python 2.7 as it breaks backwards-compatibility for embedding environments that default to 64bit FPU precision (e.g. Delphi). Additionally the bug is very hard to detect and leads to wrong values with possibly disastrous effects. Appended a patch with a new implementation of the Py_SET_53BIT_PRECISION_* macros for win32: - precision is set only when needed - setting and restoring only the x87 controlword (using __control87_2 function). - macros are not used for WIN64 as there's no x87 there - there's no need for a custom symbol in the vc project anymore, as I'm using the predefined _WIN32 symbol. -- Added file: http://bugs.python.org/file24408/74745.patch ___ Python tracker <http://bugs.python.org/issue13889> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13889] str(float) and round(float) issues with FPU precision
Samuel Iseli added the comment: There's an excess space after a line continuation backslash in my last patch, so it doesn't compile (pyport.h, line 567). Here's an additional patch that removes the space. Didn't find out how to combine the 2 revisions in one patch-file... Sorry about that. -- Added file: http://bugs.python.org/file24409/74747.patch ___ Python tracker <http://bugs.python.org/issue13889> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13889] str(float) and round(float) issues with FPU precision
Samuel Iseli added the comment: I can run the tests on 32bit. Would be nice if somebody else could do this on 64bit (my VS2008 machine is currently on 32bit-Windows). -- ___ Python tracker <http://bugs.python.org/issue13889> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13955] email: RFC 2822 has been obsoleted by RFC 5322
New submission from Samuel Bronson : As you can see by looking at <http://tools.ietf.org/html/rfc2822> or <http://tools.ietf.org/html/rfc5322>, RFC 2822 has been obsoleted by RFC 5322. It would probably be a good idea to update the email package to support it, if in fact anything needs changing, and to mention/link to the new RFC in the documentation. (It would probably *not* be a good idea to stop mentioning RFC 2822, though, since that's rather more well known, and the number is a bit more memorable for those who've heard of RFC 822. I'm actually a bit surprised the new one didn't get numbered 5822...) -- components: Library (Lib) messages: 152772 nosy: SamB priority: normal severity: normal status: open title: email: RFC 2822 has been obsoleted by RFC 5322 versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue13955> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13957] parsedate_tz doesn't distinguish -0000 from +0000
New submission from Samuel Bronson :
This is what I'm seeing:
>>> import email.utils
>>> email.utils.parsedate_tz('Fri, 09 Nov 2001 01:08:47 +')
(2001, 11, 9, 1, 8, 47, 0, 1, -1, 0)
>>> email.utils.parsedate_tz('Fri, 09 Nov 2001 01:08:47 -')
(2001, 11, 9, 1, 8, 47, 0, 1, -1, 0)
But RFC 5322 says:
>minutes). The form "+" SHOULD be used to indicate a time zone at
>Universal Time. Though "-" also indicates Universal Time, it is
>used to indicate that the time was generated on a system that may be
>in a local time zone other than Universal Time and that the date-time
>contains no information about the local time zone.
(As does RFC 2822, which RFC 5322 obsoletes.)
And the documentation for email.utils.parsedate_tz is:
> Performs the same function as parsedate(), but returns either None or a
> 10-tuple; the first 9 elements make up a tuple that can be passed directly to
> time.mktime(), and the tenth is the offset of the date’s timezone from UTC
> (which is the official term for Greenwich Mean Time) [1]. If the input string
> has no timezone, the last element of the tuple returned is None. Note that
> indexes 6, 7, and 8 of the result tuple are not usable.
So it seems like I should have seen:
>>> email.utils.parsedate_tz('Fri, 09 Nov 2001 01:08:47 -')
(2001, 11, 9, 1, 8, 47, 0, 1, -1, None)
--
components: Library (Lib)
messages: 152774
nosy: SamB
priority: normal
severity: normal
status: open
title: parsedate_tz doesn't distinguish - from +
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue13957>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13889] str(float) and round(float) issues with FPU precision
Samuel Iseli added the comment: Completed the patch by adding the rounding-control bits to the mask (_MCW_RC) and making sure the macros only get defined for MS-VC compiler (#ifdef _MSC_VER). Ran the tests (python_d -m test.autotest) on win32. Seems OK. The tests that were skipped or failed don't seem to be connected to this patch: - test_repr failed on trying to import a very long package and module name - test_popen failed with SyntaxError: unexpected EOF while parsing. Here's the summary: 323 tests OK. 2 tests failed: test_popen test_repr 2 tests altered the execution environment: test_distutils test_site 62 tests skipped: test_aepack test_al test_applesingle test_bsddb test_bsddb185 test_bsddb3 test_bz2 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_commands test_crypt test_curses test_dbm test_dl test_epoll test_fcntl test_fork1 test_gdb test_gdbm test_gl test_grp test_imgfile test_ioctl test_kqueue test_largefile test_linuxaudiodev test_macos test_macostools test_mhlib test_nis test_openpty test_ossaudiodev test_pipes test_poll test_posix test_pty test_pwd test_py3kwarn test_readline test_resource test_scriptpackages test_smtpnet test_socketserver test_sqlite test_ssl test_sunaudiodev test_tcl test_threadsignals test_timeout test_tk test_ttk_guionly test_ttk_textonly test_urllib2net test_urllibnet test_wait3 test_wait4 test_zipfile64 10 skips unexpected on win32: test_bsddb test_bz2 test_gdb test_readline test_sqlite test_ssl test_tcl test_tk test_ttk_guionly test_ttk_textonly [43048 refs] -- Added file: http://bugs.python.org/file24441/120206_set_53bit_precision.patch ___ Python tracker <http://bugs.python.org/issue13889> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37744] thread native id support for GNU/Hurd
New submission from Samuel Thibault : Hello, Here is a patch to add thread native ID support for GNU/Hurd. Samuel -- components: Interpreter Core files: hurd_thread_native_id.diff keywords: patch messages: 348879 nosy: samuel-thibault priority: normal severity: normal status: open title: thread native id support for GNU/Hurd versions: Python 3.8 Added file: https://bugs.python.org/file48526/hurd_thread_native_id.diff ___ Python tracker <https://bugs.python.org/issue37744> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31241] ast col_offset wrong for list comprehensions, generators and tuples
New submission from Samuel Colvin:
With Python 3.5 and 3.6 list comprehensions, generators and tuples have the
col_offset for their ast nodes off by 1:
```
import ast
ast.parse('{a for a in range(3)}').body[0].value.col_offset
>> 0 # set comprehension correct
ast.parse('{a: 1 for a in range(3)}').body[0].value.col_offset
>> 0 # dict comprehension correct
ast.parse('[a for a in range(3)]').body[0].value.col_offset
>> 1 # list comprehension wrong!
ast.parse('(a for a in range(3))').body[0].value.col_offset
>> 1 # generator comprehension wrong!
ast.parse('[1, 2, 3]').body[0].value.col_offset
>> 0 # list correct
ast.parse('{1, 2, 3}').body[0].value.col_offset
>> 0 # set correct
ast.parse('{1: 1, 2: 2, 3: 3}').body[0].value.col_offset
>> 0 # dict correct
ast.parse('(1, 2, 3)').body[0].value.col_offset
>> 1 # tuple wrong!
```
I haven't tried 3.4, the issue could be there too.
There are some other related issues #16806 and #21295 but they don't seem quite
the same.
--
components: Interpreter Core
messages: 300606
nosy: samuelcolvin
priority: normal
severity: normal
status: open
title: ast col_offset wrong for list comprehensions, generators and tuples
versions: Python 3.5, Python 3.6
___
Python tracker
<http://bugs.python.org/issue31241>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35711] Print information about an unexpectedly pending error before crashing
New submission from Samuel Freilich : _PyObject_FastCallDict and _PyObject_FastCallKeywords assert that there is no pending exception before calling functions that might otherwise clobber the exception state. However, that doesn't produce very clear output for debugging, since the assert failure doesn't say anything about what the pending exception actually was. It would be better to print the pending exception first. -- messages: 333418 nosy: Samuel Freilich priority: normal severity: normal status: open title: Print information about an unexpectedly pending error before crashing ___ Python tracker <https://bugs.python.org/issue35711> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35762] subprocess.Popen with universal_newlines and nonblocking streams failes with "can't concat NoneType to bytes"
New submission from Samuel Bayer : This bug is probably related to issue 24560. This: >>> import subprocess, fcntl, os >>>> p = subprocess.Popen(["python", "-c", 'import time; time.sleep(5)'], stdin >>>> = subprocess.PIPE, stdout = subprocess.PIPE, stderr = subprocess.PIPE, >>>> universal_newlines= True) >>> fcntl.fcntl(p.stderr.fileno(), fcntl.F_SETFL, os.O_NONBLOCK | >>> fcntl.fcntl(p.stderr.fileno(), fcntl.F_GETFL)) >>> p.stderr.read() causes this: Traceback (most recent call last): File "", line 1, in File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/codecs.py", line 321, in decode data = self.buffer + input TypeError: can't concat NoneType to bytes I'm assuming the problem is that the underlying unbuffered stream returns None and the incremental byte decoder that's induced by universal_newlines = True isn't expecting it. -- components: IO messages: 333883 nosy: sambayer priority: normal severity: normal status: open title: subprocess.Popen with universal_newlines and nonblocking streams failes with "can't concat NoneType to bytes" type: crash versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue35762> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra kwargs, bytes and more
New submission from Samuel Colvin : smtpd.PureProxy.process_message and smtpd.MailmanProxy.process_message are defined to not receive the extra kwargs which they're called with. They both also expect "data" to be str when it's actually bytes. Thus they're completed broken at the moment. I'd like to submit a PR to fix these two bugs. There are a number of other issues/potential improvements to smtpd which are not critical but I guess should be fixed: * no support for starttls * use of print(..., file=DEBUGSTREAM) instead of logger.debug * no type hints * PureProxy's forwarding doesn't try starttls Should I create a new issue(s) for these problems or is there some agreement that only actual bugs will be fixed in little-used modules like this? -- components: email messages: 334083 nosy: barry, r.david.murray, samuelcolvin priority: normal severity: normal status: open title: smtpd.PureProxy and smtpd.MailmanProxy broken by extra kwargs, bytes and more type: crash versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue35788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra kwargs, bytes and more
Change by Samuel Colvin : -- keywords: +patch pull_requests: +11381 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra kwargs, bytes and more
Change by Samuel Colvin : -- keywords: +patch, patch, patch, patch pull_requests: +11381, 11382, 11383, 11384 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra kwargs, bytes and more
Change by Samuel Colvin : -- keywords: +patch, patch, patch pull_requests: +11381, 11382, 11383 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra kwargs, bytes and more
Change by Samuel Colvin : -- keywords: +patch, patch pull_requests: +11381, 11382 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra kwargs, bytes and more
Samuel Colvin added the comment: Thanks for the explanation David. It would be really useful if this was prominently noted in smtpd, it would have saved me spending my morning fixing these things. There's also (AFAIK) nothing about this being deprecated in the docs. More generally I understand the idea of deprecated code that doesn't get updated to conform to latest conventions, but surely if the code exists in the standard lib. it should at least work as it was originally intended or be removed? Since the PR is done and passing surely it would be better to merge it than leave PureProxy completely broken. By the way, aiosmtpd is not in good shape: 1. Its proxy handler is blocking https://github.com/aio-libs/aiosmtpd/blob/master/aiosmtpd/handlers.py#L119 2. Its proxy handler appears to be broken in some other way, I couldn't get it to forward emails which is why I resorted to using standard smtpd. 3. It's built in a very odd way, it appears to use threading not asyncio to run the main controller https://github.com/aio-libs/aiosmtpd/blob/master/aiosmtpd/controller.py#L54 -- ___ Python tracker <https://bugs.python.org/issue35788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra kwargs, bytes and more
Samuel Colvin added the comment: Thanks for the response. I've created issues on aiosmtpd for both these things. There are much better ways of running the controller than threading, but that's a discussion for https://github.com/aio-libs/aiosmtpd/issues/160. I'll try and work on aiosmtpd in the future. Regarding smtpd, please could you respond to: > More generally I understand the idea of deprecated code that doesn't get > updated to conform to latest conventions, but surely if the code exists in > the standard lib. it should at least work as it was originally intended or be > removed? Of course, I know part of this is my wish to get my PR merged into cpython, but I really don't see any argument for leaving completely broken code in the standard library. Surely either it should be removed before the next minor release or fixed? I would say PureProxy could still be useful and should be left in place while MailmanProxy should be removed. -- ___ Python tracker <https://bugs.python.org/issue35788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra kwargs, bytes and more
Samuel Colvin added the comment: Ok. Thanks for your explanation. Makes sense. -- ___ Python tracker <https://bugs.python.org/issue35788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35799] fix or remove smtpd.PureProxy
New submission from Samuel Colvin : smtpd.PureProxy.process_message is defined to not receive the extra kwargs which it is called with. It also expects "data" to be str when it's actually bytes. PureProxy should either be removed for fixed. Personally, I think it should be fixed as the fix is pretty simple and PureProxy can be very useful. Created from https://bugs.python.org/issue35788 Happy to create a PR if this is agreed. -- components: email messages: 334156 nosy: barry, r.david.murray, samuelcolvin priority: normal severity: normal status: open title: fix or remove smtpd.PureProxy type: crash versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue35799> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35800] remove smtpd.MailmanProxy
New submission from Samuel Colvin : smtpd.MailmanProxy is completely broken, it takes the wrong arguments but also assumes the existence of a "Mailman" module which doesn't exist. It should be removed in 3.8 or 3.9. Created from https://bugs.python.org/issue35788 Happy to create a PR if this is agreed. -- components: email messages: 334157 nosy: barry, r.david.murray, samuelcolvin priority: normal severity: normal status: open title: remove smtpd.MailmanProxy versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue35800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra kwargs, bytes and more
Samuel Colvin added the comment: Great, https://bugs.python.org/issue35799 and https://bugs.python.org/issue35800 created. -- ___ Python tracker <https://bugs.python.org/issue35788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35800] remove smtpd.MailmanProxy
Samuel Colvin added the comment: Ok, if I create a PR, should it just remove MailmanProxy completely or mark it as deprecated in the docs to be removed in 3.9? Personally, I think it should be ok to remove it completely since it hasn't been working at all for the last 4 minor versions. -- ___ Python tracker <https://bugs.python.org/issue35800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35800] remove smtpd.MailmanProxy
Change by Samuel Colvin : -- keywords: +patch pull_requests: +11494 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35800] remove smtpd.MailmanProxy
Change by Samuel Colvin : -- keywords: +patch, patch pull_requests: +11494, 11495 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35800] remove smtpd.MailmanProxy
Change by Samuel Colvin : -- keywords: +patch, patch, patch pull_requests: +11494, 11495, 11496 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
