[issue46726] Thread spuriously marked dead after interrupting a join call
Change by James Gerity : -- nosy: +SnoopJeDi ___ Python tracker <https://bugs.python.org/issue46726> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46690] create_autospec() doesn't respect configure_mock style kwargs
New submission from James Marchant :
When using `create_autospec()` to create a mock object, it doesn't respect
values passed through in the style described for passing mock configurations in
the Mock constructor
(https://docs.python.org/3.8/library/unittest.mock.html#unittest.mock.Mock.configure_mock).
Instead, they seem to get discarded somewhere here
(https://github.com/python/cpython/blob/77bab59c8a1f04922bb975cc4f11e5323d1d379d/Lib/unittest/mock.py#L2693-L2741).
Here's a simple test case:
```
from unittest.mock import create_autospec
class Test:
def test_method(self):
pass
autospec_mock = create_autospec(Test, instance=True,
**{"test_method.side_effect": ValueError})
# Should throw a ValueError exception
autospec_mock.test_method()
# Assign manually
autospec_mock.test_method.side_effect = ValueError
# Throws as expected
autospec_mock.test_method()
```
--
components: Tests
messages: 412898
nosy: marchant.jm
priority: normal
severity: normal
status: open
title: create_autospec() doesn't respect configure_mock style kwargs
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue46690>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46555] Unicode-mangled names refer inconsistently to constants
James Gerity added the comment: > Why was it decided to not raise a syntax error... I'm not sure if such a decision was even ever made, the error happens before normalization is applied. I.e. the parser is doing two things here: (1) validating the syntax against the grammar and (2) building the AST. Normalization happens after (1), and `핋핣핦핖 = 0` is valid syntax because the grammar is NOT defined in terms of normalized identifiers, it's describing the valid (but confusing!) assignment that Carl described. I agree that this doesn't seem like bug, but it IS my new favorite quirk of identifier normalization. -- ___ Python tracker <https://bugs.python.org/issue46555> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46555] Unicode-mangled names refer inconsistently to constants
Change by James Gerity : -- nosy: +SnoopJeDi ___ Python tracker <https://bugs.python.org/issue46555> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46282] return value of builtins is not clearly indicated
James Gerity added the comment: My thought was to add something like this to the top of functions.rst: ``` Note that some of the functions listed here have the :ref:`default return value of ``None``. ``` For reference, the builtins this applies to are: * breakpoint() * delattr() * exec() * help() * print() * setattr() Which makes me wonder if the hint is even worth having, since it's so few of them. Note that of these, exec() does what this ticket originally proposed for print() - i.e. it explicitly says that the function returns None. -- ___ Python tracker <https://bugs.python.org/issue46282> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46282] return value of builtins is not clearly indicated
James Gerity added the comment:
> advertising that all functions default to returning None
This is already communicated in § 4.7 ("Defining Functions") of the official
tutorial.
I think it would be a good idea to revise that section so that this property of
functions is a little more clear, but that isn't the scope of this ticket.
The title change reflects my intent to submit a PR that adds a hint to the
builtins doc.
--
___
Python tracker
<https://bugs.python.org/issue46282>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46282] return value of builtins is not clearly indicated
Change by James Gerity : -- title: print() docs do not indicate its return value -> return value of builtins is not clearly indicated ___ Python tracker <https://bugs.python.org/issue46282> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46292] Add microseconds to logging.LogRecord
Change by James Casbon : -- components: +Library (Lib) type: -> enhancement ___ Python tracker <https://bugs.python.org/issue46292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46292] Add microseconds to logging.LogRecord
New submission from James Casbon : LogRecord makes microseconds available via the msecs attribute. This patch adds microseconds via usecs attribute. Some regulators (eg MIFID II) require accuracy greater than 1ms in some industries. This patch calls time_ns rather than time so that the usecs and msecs are calculated from int types and then gets the original ct attribute via division. -- files: usecs.patch keywords: patch messages: 409963 nosy: jamescasbon priority: normal severity: normal status: open title: Add microseconds to logging.LogRecord Added file: https://bugs.python.org/file50546/usecs.patch ___ Python tracker <https://bugs.python.org/issue46292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46282] print() docs do not indicate its return value
James Gerity added the comment: The original question was closer to the related issue of "indicate return types for all built-ins," conversation log follows (UTC-5): ``` 09:33:50 ringo__ | is there a stdlib api docs which actually has *full* functions signature? 09:34:27 ringo__ | for example, https://docs.python.org/3/library/functions.html, function | abs(x), it returns what, int? I need to read the whole sentence to figure | out the return value of a function? 09:34:48 ringo__ | (or argument for that matter) 09:35:51 bjs | ringo__: well like it says it doesn't just support int 09:36:00 bjs | int, float, or any type that supports it 09:37:01 bjs | in general you can find actual type annotations for the functions in the | typeshed | https://github.com/python/typeshed/blob/master/stdlib/builtins.pyi 09:37:32 bjs | I wonder if it would be useful to include the typeshed annotation in the | docs, or whether it would be more confusing 09:37:49 ringo__ | Thanks bjs ! I'll bookmark this typeshed 09:38:13 SnoopJ | abs() will do whatever __abs__() on the type does, which can be different | for any given type. You'd expect T -> T but it's not guaranteed. 09:38:18 ringo__ | I used abs() as an example. In fact I was wondering what does print() | return. I *guessed* it returns None, but the docs won't say 09:39:05 ringo__ | I could do a try-it-yourself approach but I was puzzled why the docs | simply won't give you full fn signature, ie print(..) -> None 09:39:17 SnoopJ | that one is just an omission :) ``` -- ___ Python tracker <https://bugs.python.org/issue46282> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46282] print() docs do not indicate its return value
James Gerity added the comment: I opened this ticket on behalf of a user who asked about print() specifically in #python on the Libera IRC network, who I assume does not find this obvious. I don't think it would be tenable to add this note to every built-in, but that's not the intended scope of this issue. I do think it's worth mentioning for print(), though. -- ___ Python tracker <https://bugs.python.org/issue46282> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46282] print() docs do not indicate its return value
Change by James Gerity : -- keywords: +patch pull_requests: +28642 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30435 ___ Python tracker <https://bugs.python.org/issue46282> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46282] print() docs do not indicate its return value
Change by James Gerity : -- assignee: docs@python components: Documentation nosy: SnoopJeDi, docs@python priority: normal severity: normal status: open title: print() docs do not indicate its return value versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46282> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46116] _asyncio_backend.py datagram_received doesn't handle Future cancelled, throws Exception
New submission from James Lawrie : The datagram_received: def datagram_received(self, data, addr): if self.recvfrom: self.recvfrom.set_result((data, addr)) self.recvfrom = None Throws an exception if self.recvfrom is a Future Cancelled: Exception in callback _SelectorDatagramTransport._read_ready() handle: Traceback (most recent call last): File "/usr/lib/python3.8/asyncio/events.py", line 81, in _run self._context.run(self._callback, *self._args) File "/usr/lib/python3.8/asyncio/selector_events.py", line 1021, in _read_ready self._protocol.datagram_received(data, addr) File "/usr/local/lib/python3.8/dist-packages/dns/_asyncio_backend.py", line 30, in datagram_received self.recvfrom.set_result((data, addr)) asyncio.exceptions.InvalidStateError: invalid state In my test code (attached), this wasn't caught in a try: catch: -- components: asyncio files: asynctest.py messages: 408778 nosy: asvetlov, james2, yselivanov priority: normal severity: normal status: open title: _asyncio_backend.py datagram_received doesn't handle Future cancelled, throws Exception versions: Python 3.8 Added file: https://bugs.python.org/file50500/asynctest.py ___ Python tracker <https://bugs.python.org/issue46116> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46001] JSON module documentation mentions OverflowError for case that raises RecursionError
James Gerity added the comment: Correction: the bug whose resolution adds the OverflowError mentioned above is bpo-24522, not bpo-43255 -- ___ Python tracker <https://bugs.python.org/issue46001> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46001] JSON module documentation mentions OverflowError for case that raises RecursionError
Change by James Gerity : -- keywords: +patch pull_requests: +28168 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29943 ___ Python tracker <https://bugs.python.org/issue46001> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46001] JSON module documentation mentions OverflowError for case that raises RecursionError
New submission from James Gerity : The docstrings for `json.JSONEncoder, json.dump(), json.dumps()` all refer to `OverflowError` when describing the behavior of the `check_circular` parameter, but the module's test of this parameter catches a `RecursionError` and the documentation does make reference to recursion. Since the fix for bpo-43225 (7b78d43) the string-escaping machinery in `_json.c` is capable of raising OverflowError, but the reference in the documentation predates this addition by quite a long time. -- assignee: docs@python components: Documentation messages: 407837 nosy: SnoopJeDi, docs@python priority: normal severity: normal status: open title: JSON module documentation mentions OverflowError for case that raises RecursionError versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46001> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42130] AsyncIO's wait_for can hide cancellation in a rare race condition
James Ferguson added the comment: Echoing nmatravolgyi's comments - I got here after hitting this bug and I too am amazed it's been around so long and hasn't been addressed. It makes cancellation in my application very unreliable, and the reason I need well-controlled cancellation semantics is to allow emergency stop of physical movement. -- nosy: +jamesf ___ Python tracker <https://bugs.python.org/issue42130> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34820] binascii.c:1578:1: error: the control flow of function ‘binascii_crc32’ does not match its profile data (counter ‘arcs’)
James Gerity added the comment: The Makefile issue was fixed in bpo-37725 (GitHub: https://github.com/python/cpython/commit/c6bbcd258302b4b9b3d4f3c39bb5f7ff0120ec67), but the change wasn't ported to the 3.7, 3.8 branches. Those versions are now security-only, so this issue can probably just be closed. If anybody comes to this issue with the same problem, you can `make profile-removal` or `make clobber` to get GNU Make to clean up the PGO data, or you can remove the files yourself with the `find` invocation. -- nosy: +SnoopJeDi ___ Python tracker <https://bugs.python.org/issue34820> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45705] |= set update scoping
James Bowery added the comment: My mistake. Disregard. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue45705> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45705] |= set update scoping
New submission from James Bowery :
Comment out the |= line and it prints "{'b':2}" as expected.
$ cat t.py
scoped_dict = {'b':2}
def scoped_def():
print(scoped_dict)
scoped_dict |= {'a',1}
scoped_def()
$ p t.py
Traceback (most recent call last):
File "/home/jabowery/dev/t.py", line 5, in
scoped_def()
File "/home/jabowery/dev/t.py", line 3, in scoped_def
print(scoped_dict)
UnboundLocalError: local variable 'scoped_dict' referenced before assignment
$ python --version
Python 3.10.0
--
components: Parser
messages: 405643
nosy: jabowery2, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: |= set update scoping
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue45705>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45683] dns.asyncresolver ignores nameserver parameter
James Lawrie added the comment: Sorry. This was a pebkac error, I was setting nameserver instead of nameservers -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue45683> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45683] dns.asyncresolver ignores nameserver parameter
New submission from James Lawrie : The DNS async resolver allows you to specify a list of nameservers to use, but they are ignored and the system nameservers are used instead. Test code below demonstrating the issue: # cat test.py import dns.asyncresolver import asyncio from pprint import pprint async def main(domains): results = await get_ips_bulk(domains) results = [item for sublist in results for item in sublist] pprint(results) async def get_ips_bulk(domains): output = [get_ips(domain) for domain in domains] return await asyncio.gather(*output, return_exceptions=True) async def get_ips(domain): res = dns.asyncresolver.Resolver() res.nameserver = ["1.1.1.1"] results = [] try: ipv4 = await res.resolve(domain, 'A') for result in ipv4: results.append(['A', domain, result.to_text()]) except: results.append(['A', domain, 'n/a']) try: ipv6 = await res.resolve(domain, '') results.append(['', domain, result.to_text()]) except: results.append(['', domain, 'n/a']) return results domains = ['python.org'] asyncio.run(main(domains)) It should use 1.1.1.1 as the nameserver but watching tcpdump it's using 8.8.8.8 per /etc/resolv.conf: # tcpdump -n port 53 & [1] 16751 listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes # python3 test.py 19:05:02.750458 IP x.x.x.x.44173 > 8.8.8.8.53: 46143+ A? python.org. (28) 19:05:02.756265 IP 8.8.8.8.53 > x.x.x.x.44173: 46143 1/0/0 A 138.197.63.241 (44) 19:05:02.757392 IP x.x.x.x.37827 > 8.8.8.8.53: 17493+ ? python.org. (28) 19:05:02.765797 IP 8.8.8.8.53 > x.x.x.x.37827: 17493 0/1/0 (115) [['A', 'python.org', '138.197.63.241'], ['', 'python.org', 'n/a']] # fg tcpdump -n port 53 ^C # grep -P "^nameserver" /etc/resolv.conf nameserver 8.8.8.8 -- components: asyncio messages: 405460 nosy: asvetlov, james2, yselivanov priority: normal severity: normal status: open title: dns.asyncresolver ignores nameserver parameter type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue45683> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14527] How to link with a non-system libffi?
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue14527> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45598] setup.py grep_headers_for() is broken by design
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue45598> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45350] configure incorrectly ignores pkg-config information for libffi and Tcl/Tk in 3.10
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue45350> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45643] SIGSTKFLT is missing from the signals module on Linux
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue45643> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45256] Remove the usage of the C stack in Python to Python calls
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue45256> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44525] Implement CALL_FUNCTION adaptive interpreter optimizations
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue44525> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45484] test_pickle segfault on s390x RHEL7 LTO 3.x
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue45484> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45668] Some PGO tests are failing when building with --enable-optimizations --disable-test-modules
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue45668> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45448] PIP package installation failure for multiple packages
Zayden Micheal James added the comment: Oh so the problem will resolve itself when they, support Python 3.10 PIP 21.2.4. Sorry for the inconvenience. Can't wait for the libraries to be resolved and optimized -- ___ Python tracker <https://bugs.python.org/issue45448> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45448] PIP package installation failure for multiple packages
Zayden Micheal James added the comment: I am using Python 3.10 and PIP 21.2.4. All installations worked fine with Python 3.9. I tried combinations such as: ["pip", "pip3", "python3 -m pip", "python -m pip3", "python -m pip","python3 -m pip3"] So far documented modules with problems are: ["numpy", "pandas", "tensorflow", "matplotlib"] It is impossible for all of these libraries to be broken all at once with Python 3.10, PIP 21.2.4 and not be a problem with Python/PIP. -- ___ Python tracker <https://bugs.python.org/issue45448> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45448] PIP package installation failure for multiple packages
Zayden Micheal James added the comment: This issue is still persisting with other libraries aswell such as matplotlib and the above mentioned. -- nosy: -eric.smith resolution: third party -> status: closed -> open type: compile error -> behavior ___ Python tracker <https://bugs.python.org/issue45448> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45448] PIP package installation failure for multiple packages
New submission from Zayden Micheal James : When I try to install numpy using python version 3.10, pip version 21.2.4 it gives me a PEP517 error, with a bunch of other exceptions. When I try to install tensorflow using python version 3.10, pip version 21.2.4 it gives me an error saying that there is no such package. I've tried multiple pip and python combo's for installation... Aswell as inside and outside a virtual enviroment. -- components: Installation messages: 403740 nosy: zayvelleman priority: normal severity: normal status: open title: PIP package installation failure for multiple packages type: compile error versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue45448> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45433] libpython should not be linked with libcrypt
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue45433> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44751] crypt.h should be in _cryptmodule.c, not in public header
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue44751> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44414] from __future__ import annotations breaks profiler's handling of dataclasses
New submission from James Wilcox :
This program behaves differently when run under the profiler (either profile or
cProfile) versus when run normally.
```
from __future__ import annotations # ***
import dataclasses
@dataclasses.dataclass
class C:
x: dataclasses.InitVar[int]
def __post_init__(self, x):
print(f'hello {x}')
C(0)
```
Save this as foo.py. Then
python foo.py
prints
hello 0
but
python -m profile foo.py
results in the traceback
```
Traceback (most recent call last):
File "/Users/jrw12/.pyenv/versions/3.9.5/lib/python3.9/runpy.py", line 197,
in _run_module_as_main
return _run_code(code, main_globals, None,
File "/Users/jrw12/.pyenv/versions/3.9.5/lib/python3.9/runpy.py", line 87, in
_run_code
exec(code, run_globals)
File "/Users/jrw12/.pyenv/versions/3.9.5/lib/python3.9/profile.py", line 610,
in
main()
File "/Users/jrw12/.pyenv/versions/3.9.5/lib/python3.9/profile.py", line 599,
in main
runctx(code, globs, None, options.outfile, options.sort)
File "/Users/jrw12/.pyenv/versions/3.9.5/lib/python3.9/profile.py", line 99,
in runctx
return _Utils(Profile).runctx(statement, globals, locals, filename, sort)
File "/Users/jrw12/.pyenv/versions/3.9.5/lib/python3.9/profile.py", line 62,
in runctx
prof.runctx(statement, globals, locals)
File "/Users/jrw12/.pyenv/versions/3.9.5/lib/python3.9/profile.py", line 422,
in runctx
exec(cmd, globals, locals)
File "foo.py", line 11, in
C(0)
File "", line 4, in __init__
TypeError: __post_init__() missing 1 required positional argument: 'x'
```
A similar traceback occurs if using `-m cProfile` instead of `-m profile`.
No such traceback occurs if the `from future import __annotations__` is removed
from the file.
Possibly related to #39442.
--
components: Library (Lib)
messages: 395762
nosy: wilcoxjay
priority: normal
severity: normal
status: open
title: from __future__ import annotations breaks profiler's handling of
dataclasses
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue44414>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40199] Invalid escape sequence DeprecationWarnings don't trigger by default
James Gerity added the comment: The cause of DeprecationWarning sometimes [1] not being issued is I believe because in string_parser.c [2] the module is explicitly set to NULL and the filename will be '' or '' or somesuch, which eventually that ends up being normalized to something that isn't '__main__'. Not sure if this is stating the obvious and I don't see any general solution short of adding a filter for the special filenames, but I caught wind of this in #python on Libera, got curious, and thought I'd share what I learned here. I've also attached a gdb session showing how changing the filename affects this behavior. Reproducing this in debug/dev contexts is definitely fraught, since the warning behavior is different. [1] The given compile() sample, at the REPL, when using -c, or when piping input via stdin are the ones I know about [2] https://github.com/python/cpython/blob/f3fa63ec75fdbb4a08a10957a5c631bf0c4a5970/Parser/string_parser.c#L19-L20 -- nosy: +SnoopJeDi2 Added file: https://bugs.python.org/file50091/gdb_deprecationwarning_session.txt ___ Python tracker <https://bugs.python.org/issue40199> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44070] Regression with relative paths in sys.path in python 3.8.10
James Saryerwinnie added the comment: > What's the actual scenario that this broke? I only noticed this because a project that I work on (https://github.com/aws/chalice/) started failing CI for seemingly unrelated changes. A specific test run is here: https://github.com/jamesls/chalice/runs/2529906754. This didn't actually break the framework itself, just the tests for the framework. Chalice imports your application to figure out what resources to deploy to AWS, so the functional tests need to setup/teardown misc. applications and re-import them fresh for each test. Turns out the GitHub action I was using switched their Python 3.8 from 3.8.9 to 3.8.10 so I started looking into why this failed. My takeaway from this is to stop using relative imports in sys.path (I don't recall us having a specific reason to do this other than it worked). I figured I'd file an issue as I'm not actually sure if this consequence was intentional (I only saw bpo-43105 mentioned in the changelog), and was surprised this behavior changed in a patch release. -- ___ Python tracker <https://bugs.python.org/issue44070> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44070] Regression with relative paths in sys.path in python 3.8.10
New submission from James Saryerwinnie :
There was a change in behavior in Python 3.8.10 when using relative paths in
sys.path. It appears that the paths are now converted to absolute paths that
are cached and can cause import errors in some cases.
Repro:
$ cat repro.sh
#!/bin/bash
python --version
mkdir -p /tmp/repro/{A,B}/testproject
echo "msg = 'from A'" > /tmp/repro/A/testproject/app.py
echo "msg = 'from B'" > /tmp/repro/B/testproject/app.py
python -c "
import sys, os, shutil
os.chdir('/tmp/repro/A')
sys.path.append('testproject')
import app
print(app)
print(app.msg)
os.chdir('/tmp/repro/B')
shutil.rmtree('/tmp/repro/A')
del sys.modules['app']
import app
print(app)
print(app.msg)
"
rm -rf /tmp/repro
On Python 3.8.9 I get:
$ ./repro.sh
Python 3.8.9
from A
from B
On Python 3.8.10 I get:
$ ./repro.sh
Python 3.8.10
from A
Traceback (most recent call last):
File "", line 12, in
ModuleNotFoundError: No module named 'app'
I haven't confirmed this (I can't work out the frozen bootstrap stuff), but
this might be caused by https://bugs.python.org/issue43105, whose patch does
seem to be converting paths to absolute paths.
--
components: Library (Lib)
messages: 393212
nosy: James.Saryerwinnie
priority: normal
severity: normal
status: open
title: Regression with relative paths in sys.path in python 3.8.10
type: behavior
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue44070>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43300] "bisect" module should support reverse-sorted sequences
New submission from James Murphy : Currently, the bisect module's functions all assume the user is maintaining a sorted list/sequence in increasing order. From the docs: "This module provides support for maintaining a list in sorted order without having to sort the list after each insertion" However, bisection is not limited to this use case, nor is it limited to increasing sequences. Many algorithms involve bisecting a sequence derived from (potentially immutable) user input, such as the standard longest-increasing-subsequence algorithm. Sometimes these derived sequences are naturally reverse-sorted, as they would be in the longest-decreasing-subsequence algorithm. (I have personally had to work around bisect not working with decreasing sequences in this case). There are other natural reasons for a reverse-sorted list to appear that one might want to bisect. Of course, a monotone decreasing function applied to a sorted list would result in a reverse-sorted one. One may want to use bisect as a root-finding algorithm for a decreasing function that may not be differentiable (or even continuous). Or a user may simply have chosen to reverse-sort using sorted(a, reverse=True). In my mind, the bisect module's purpose should be to support common use cases of bisection, not specifically to maintain a sorted list. So then the question arises, how to support reverse-sorted sequences? I see a few possible routes. 1. Add a "decreasing" parameter to bisect_left, bisect_right, (and perhaps insort_left, insort_right as well). 2. Add dedicated functions bisect_left_decreasing, bisect_right_decreasing, (and perhaps insort_left_decreasing, insort_right_decreasing as well) that operate on reverse-sorted sequences. 3. Add a more general bisect_first_false(a, pred, lo, hi) (equivalent to C++'s std::partition_point) that assumes the sequence to be partitioned with respect to the predicate function and returns the first index such that the predicate is falsey, or hi if no falsey elements are found. Then reverse-sorted lists can be bisected with something like bisect_first_false(a, lambda y: y > x). This way may be too general, but it becomes very obvious what operators will be called on the values and what the post-condition of the function is, similar to the condition of a while loop. 4. Add a "cmp" parameter to bisect_left, bisect_right, (and perhaps insort_left, insort_right as well) that keys are meant to be compared with, so one would pass bisect_left(a, x, cmp=operator.gt). It could be used in conjuction with "key", i.e. "cmp" is not meant to be a replacement for "key" as it was with sorted. 5. Do nothing. People who _really_ want to bisect reverse-sorted lists will write their own bisect_*_decreasing or figure out that if "a" is reverse-sorted, the following monstrosity does the job, making ab(use) of the new "key" parameter in 3.10 and due to the fact that False < True: a = ... # reverse-sorted x = ... # bisect left on reverse-sorted pred = lambda y: not (x < y) idx = bisect_left(a, x, key=pred) # bisect right on reverse-sorted pred = lambda y: y < x idx = bisect_right(a, x, key=pred) Commentary on the choices. 1 or 4 are the most convenient from a user perspective, no extra imports and discoverable behavior. 4 also has the benefit that the element/key class does not need to define a __lt__, which can be useful in cases where the element/key has many comparable attributes and it does not make sense to pick one to be used to define a __lt__. 3 would have the most generality and usefulness to library writers, who would probably be the primary users in need of a reverse-sorted bisection implementation. 2 suffers from combinatorial explosion (many new functions) and extra importing needed, but allows the implementation of existing functions to be unchanged, as well as mildly discouraging users from using it unless they _really_ want to use it. 5 will lead to many incorrect home-grown bisection searches or other hacks being used in the wild. Personally, I am somewhat indifferent between 1 and 4, perhaps slightly learning towards 4 as it makes explicit exactly how elements/keys will be compared. I would like to see 3 implemented as well, but admit that it is likely too general a solution for the proposed issue "support reverse-sorted lists". -- components: Library (Lib) messages: 387523 nosy: mCoding priority: normal severity: normal status: open title: "bisect" module should support reverse-sorted sequences type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43300> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25166] Windows AllUsers installation places uninstaller in user profile
James Russell added the comment: I have been reviewing the Install process as we need to start installing / patching Python and I have seen the same issue as mentioned below however the difference for me is I am running the install on a Silent command line. I cannot seem to override "AllUsers" Property using the command line as WiX logs the following: "Ignoring attempt to set non-overridable variable: 'AllUsers'." If this parameter was made overridable I believe this would then allow the Bootstrapper to be listed under all users Uninstall area rather than the current user (or in my case it gets written to HKEY_USERS\.Default\... (which is really unhelpful) as the installer is being run under the system context). -- nosy: +beefy80 versions: +Python 3.8 ___ Python tracker <https://bugs.python.org/issue25166> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39457] Add an autocommit property to sqlite3.Connection with a PEP 249 compliant manual commit mode and migrate
James Oldfield added the comment:
There's some confusion here over what autocommit=True would do. I believe the
last three comments give three different interpretations! Géry said
conn.autocommit would change to False when I start a transaction with
execute("BEGIN"), Mike said it wouldn't (because it represents the driver's
state, not the engine's, by analogy with other DB API drivers), and Marc-Andre
says execute("BEGIN") wouldn't be allowed in the first place (or at least it
would issue a warning).
To reiterate, the ability to control transactions manually is already supported
in the sqlite3 driver, in the form of isolation_mode=None. My first request is
simply that **this ability continues to exist**. This functionality was
implemented deliberately - the original author of pysqlite recommended this
usage, and care has been taken over the years not to break it. Please do not
point out that this is not DB API compliant; I know that, and I just don't
care! So long as DB API compliant usage is _also_ supported, even the default,
that doesn't prevent this other mode from existing too. Many others are using
the mode, even if they are not commenters here, so I don't believe it is
feasible to break or remove this functionality, even if you're not a fan.
My second request was: feel free to rename this option from
"isolation_mode=None" to something else if you wish, but please don't call it
"autocommit=True" because that's just too confusing. I feel like the confusion
in the comments above justifies this point of view.
As I see it, that leaves two options:
Option 1: Suck it up and use autocommit=True as the option name. It's
confusing, but there's so much precedent that it has to be so. This is Mike
Bayer's suggestion (except he didn't say it was confusing, that's just my
commentary). I think that this option is only feasible if conn.autocommit only
refer's the driver's state, not the underlying engine's state, confusing though
that is i.e. once set to true it would *always* be true, even if a transaction
is started.
Option 2: Reserve autocommit=True for the underlying SQLite engine autocommit
mode. That means detecting when there's an attempt to use execute("BEGIN") or
similar, and then issuing a warning or error. It also means supplying some
other, third, option for what I'm asking (like today's isolation_mode=None).
Although option 2 is closer to what I originally requested, I do worry it means
that the non-DBAPI mode will appear unsupported and fall into neglect. If the
API for accessing it is to set autocommit=None, to mean legacy behaviour, and
then also isolation_mode=None to mean the type of legacy behaviour, then it
doesn't look like the most recommended API ever. And yet, for those that don't
care about DB API (which I imagine is most users of the sqlite3 driver), this
is probably the best API to use.
So I reluctantly agree that option 1, using autocommit=True, is actually best
overall. I would ask that there is at least a note in the documentation so that
it's clear this is allowed to work. Something like this:
If autocommit=True then the sqlite3 module will never automatically start
transactions. The underlying SQLite database engine operates in autocommit mode
whenever no transactions are active, so the net effect of this is to use
SQLite's autocommit mode [1].
Note that, when autocommit=True, the sqlite3 module will not intercept and
stop a statement to explicitly start a transaction, such as with
execute("BEGIN"). In that case, a transaction is started and the underlying
SQLite engine is no longer in autocommit mode. (The sqlite3 Connection object
will still report autocommit=True; this does not indicate that the SQLite
engine is autocommit mode, just that the sqlite3 module is not going to
implicitly start any transactions.)
The connection commit() and rollback() methods may be used for transactions
started explictly when autocommit=True, and the connection may be used as a
context manager, just as it can be when autocommit=False. If no transaction is
currently active then those methods silent pass with no effect.
[1]
https://sqlite.org/lang_transaction.html#implicit_versus_explicit_transactions
Side note: When I started down this rabbit hole several weeks ago, I repeatedly
came across the extremely confusing phrase "SQLite operates in autocommit mode
by default". It took me a while to realise that autocommit is not a flag that
it is possible to turn off on a connection *when you open it*. The text I used
above, "The underlying SQLite database engine operates in autocommit mode
whenever no transactions are active" was carefully chosen and I consider it to
be much clearer, regardless of whatever else ends up happening.
--
___
Python tracker
<https://bugs.python.org/issue39457>
[issue39457] Add an autocommit property to sqlite3.Connection with a PEP 249 compliant manual commit mode and migrate
James Oldfield added the comment:
> Yes if you are talking about SQLite, the database ENGINE
I sure was! In this comment I will stick to saying either "SQLite engine" or
"sqlite3 driver" as appropriate, hopefully that will be clearer.
> But here I am talking about SQLite3, the Python database DRIVER
Yep, I was aware of that. I was trying to say, please don't use the word
"autocommit" in the sqlite3 driver when that word has a related but different
meaning in the SQLite engine.
> You do not issue BEGIN statements with database DRIVERS, they are issued
> implicitly, so that the manual mode is the default mode for database DRIVERS.
This sentence isn't literally true for several reasons (you say "you do not"
but I certainly do, you use of "with database drivers" is dubious, and you seem
to have causality in the wrong direction). I think there might be a bit of a
language barrier here, so I hope you don't mind if I leave this to one side.
> Cf. this Stack Overflow answer for more details:
> https://stackoverflow.com/a/48391535/2326961
I am fully, and painfully, aware of when the sqlite3 driver code will
automatically issue BEGIN statements to the engine. I have no need to read
StackOverflow answers about it, I have read the C source code to sqlite3 (and
pysqlite) directly. I spent more time than I care to admit recently doing that!
In fact that happened as a result of reading several confusing StackOverflow
answers about transactions (maybe I'll write my own and add to the confusion...)
What that answer doesn't mention is that, even with even with
isolation_mode=None, it's perfectly possible to start a transaction, which
takes the SQLite engine out of autocommit mode. This is fully and intentionally
supported by the sqlite3 driver, and the original author has said so and even
recommended. For example, let's look at this code:
conn = sqlite3.connect(path, isolation_mode=None)
conn.execute("INSERT INTO test (i) VALUES (?)", (1,)) # stmt 1
foo = conn.execute("SELECT * FROM test").fetchall()# stmt 2
conn.execute("BEGIN") # stmt 3
conn.execute("INSERT INTO test (i) VALUES (?)", (4,)) # stmt 4
bar = conn.execute("SELECT * FROM test").fetchall()# stmt 5
conn.execute("COMMIT") # stmt 6
Statement 1 and statement 2 execute using the SQLite engine's autocommit mode.
Statements 3 through to 5 execute in a single transaction and do *not* use the
SQLite engine's autocommit mode. (Technically statement 6 actually does use
autocommit because COMMIT uses the autocommit mechanism under the hood ... but
let's forget about that!)
Under your proposal, the first line would be changed to say "autocommit=True",
even though not all the code below is in autocommit mode (according to the
SQLite engine's definition). What's more, I could insert this line of code
between statements 3 and 6:
print("Autocommit mode?", conn.autocommit)
And it would print True even though autocommit mode is off!
Now, maybe your reaction is that "autocommit mode *in the driver*" can have a
different meaning from "autocommit mode *in the engine*". Yes, it can, but that
doesn't mean it should! Please, just pick a different name! For example, say
"manual mode" (instead of autocommit=True) or "auto-start-transaction mode"
(instead of autocommit=False).
> No, you do not want that at the database DRIVER level. Because like Mike
> Bayer explained in issue #9924, this is not what other database DRIVERS do,
> and this is not PEP 249 compliant
The "that" you are referring to here was when I said that I prefer to set
isolation_level = None, like the above code snippet. Do not tell me that it is
not what I want; it certainly IS what I want! I do not want the sqlite3 driver
getting in the way between me and the SQLite engine. Many future users of the
sqlite3 driver are likely to feel the same way, and the API should allow that
to happen clearly.
--
___
Python tracker
<https://bugs.python.org/issue39457>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39457] Add an autocommit property to sqlite3.Connection with a PEP 249 compliant manual commit mode and migrate
James Oldfield added the comment:
If this ever gets implemented, "autocommit" would be a terrible name for it.
That word has a very specific meaning in SQLite, which is essentially the same
as "not in a transaction started with BEGIN ...". At the moment, if you want to
explicitly control when transactions start (a good idea considering how
confusing the current behaviour is) then you would set isolation_mode to None
and manually start a transaction with `execute("BEGIN")` - at which point you
are NOT in autocommit mode, until you commit or rollback. According to this
proposal, if I want manual control over transactions, I would set
`conn.autocommit = True`, even though I *don't* want autocommit mode (according
to SQLite's definition)!
--
nosy: +james.oldfield
___
Python tracker
<https://bugs.python.org/issue39457>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42709] I
New submission from James B Wilkinson : > On Dec 21, 2020, at 11:11 PM, Raymond Hettinger > wrote: > > > Change by Raymond Hettinger : > > > -- > stage: -> resolved > status: open -> closed I see that this has been marked “resolved” and closed with no hint as to what the problem is. Did I do something wrong by submitting this? If so I apologize. thanks James B. Wilkinson Professor Emeritus Department of Computer Science The College of Charleston the@twc.com -- ___ Python tracker <https://bugs.python.org/issue42709> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42709] I
Change by James B Wilkinson : -- nosy: the.doc priority: normal severity: normal status: open title: I ___ Python tracker <https://bugs.python.org/issue42709> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42504] Failure to build with MACOSX_DEPLOYMENT_TARGET=11 on Big Sur
Change by James Guillochon : -- components: +macOS nosy: +ned.deily, ronaldoussoren ___ Python tracker <https://bugs.python.org/issue42504> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42505] MACOSX_DEPLOYMENT_TARGET should accept non-decimal (int) value versions
James Guillochon added the comment: Closing in favor of https://bugs.python.org/issue42504 which has more details -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue42505> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42505] MACOSX_DEPLOYMENT_TARGET should accept non-decimal (int) value versions
New submission from James Guillochon : See the discussion here https://github.com/Homebrew/homebrew-core/pull/65866#issuecomment-735366297, but this is currently a blocker for compilation via home-brew on Apple Silicon. Current workaround is to set the deployment target to "11.0" (rather than the "11" currently passed into it, which should be valid). -- components: macOS messages: 382072 nosy: guillochon, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: MACOSX_DEPLOYMENT_TARGET should accept non-decimal (int) value versions type: compile error versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue42505> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42485] Full grammar specification should link to PEP 617
Change by James Gerity : -- keywords: +patch nosy: +SnoopJeDi2 nosy_count: 2.0 -> 3.0 pull_requests: +22414 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23532 ___ Python tracker <https://bugs.python.org/issue42485> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42485] Full grammar specification should link to PEP 617
New submission from James Gerity : Now that CPython uses the new PEG parser, it would be helpful to include a reference to the guiding PEP (617) on the docs page (https://docs.python.org/3/reference/grammar.html) that gives the grammar. -- assignee: docs@python components: Documentation messages: 381954 nosy: docs@python, snoopjedi priority: normal severity: normal status: open title: Full grammar specification should link to PEP 617 versions: Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42485> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18857] urlencode of a None value uses the string 'None'
James Addison added the comment: Thanks Senthil; please take your time. This isn't urgent, and would likely benefit from further standardization of the URL query string and/or form-encoded data formats (outside the Python project) to achieve consensus. A fully-considered answer at a later date would probably sit more comfortably with me than one that has any sense of time pressure. -- ___ Python tracker <https://bugs.python.org/issue18857> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18857] urlencode of a None value uses the string 'None'
James Addison added the comment: No problem, and thanks for the heads-up Tal! I'll raise this as a topic on python-dev if it still seems worth pursuing, after collecting some more thoughts about it. -- ___ Python tracker <https://bugs.python.org/issue18857> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40782] AbstactEventLoop.run_in_executor is listed as an async method, but should actually return a Future
James Barrett added the comment: https://github.com/python/cpython/pull/21852 -- ___ Python tracker <https://bugs.python.org/issue40782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40782] AbstactEventLoop.run_in_executor is listed as an async method, but should actually return a Futrue
Change by James Barrett : -- keywords: +patch pull_requests: +20979 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21852 ___ Python tracker <https://bugs.python.org/issue40782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40553] Python 3.8.2 Mac freezing/not responding when saving new programs
James Franks added the comment: Hope this helps: I'm running Python Shell 3.8.5 on MacOSx 10.15.6 (Catalina). I can reproduce this hang easily. Open any existing module or create a new one. Can save the existing module or a new one just fine under the same name. (File menu - Save) Using "Save as..." from File dropdown menu, Windows appears, change the name, hit Save button and IDLE hangs. After approximately a minute the window becomes active again, but when hitting any button (Cancel or Save) it hangs again. No way to get out of this but force quit IDLE. My files are in iCloud documents folder. Did the same test with a Mac running Mojave (10.14.6) Also with Python Shell 3.8.5. Works fine. Seems to be something with Catalina as some have mentioned. Please help. This is extremely frustrating for someone like me just trying to learn Python. I will switch over to the machine running Mojave. Thanks for helping! -- nosy: +franksj ___ Python tracker <https://bugs.python.org/issue40553> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36207] robotsparser deny all with some rules
James Gray added the comment: Bonjour, je vois que nous ne sommes pas les seuls dans ce cas, nous avons besoin que les robots indexent nos pages html mais qu'elles n'indexent pas celles en /*.php$ ainsi que les ressources PC en PDF. Nous avons tenté en vain plusieurs solutions en passant par le robots.txt à la racine de notre domaine https://demolinux.org/ mais sans succès. Le RobotsParser ne prends pas ces règles en compte, merci. -- nosy: +Jmgray47 ___ Python tracker <https://bugs.python.org/issue36207> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9625] argparse: Problem with defaults for variable nargs when using choices
James Corbett added the comment:
I would love to get this issue resolved; it seems like everyone agrees that
it's a bug. It came up for me recently: https://bugs.python.org/issue41047.
Judging from the comments above, the consensus is that the relevant line,
`self._check_value(action, value)` should either be replaced with something
like `if isinstance(value, collections.abc.Sequence): for v in value:
self._check_value(action, v)` or be removed entirely.
I think the line should just be removed. I think it's fair to assume that users
of `argparse` know what they're doing, so I think they should be allowed to
pass default values that conflict with `choices`. Also, removing the line makes
the behavior consistent with the optionals, which don't check whether default
values are in `choices`. See the below script:
```
import argparse
def main():
parser = argparse.ArgumentParser()
parser.add_argument("--foo", nargs="+", default=[-1], choices=range(10))
parser.add_argument("--bar", nargs="*", default=-1, choices=range(10))
parser.add_argument("pos", nargs="?", default=-1, choices=range(10))
args = parser.parse_args()
print(args)
if __name__ == '__main__':
main()
```
Which yields:
```
$ python argparse_test.py
Namespace(foo=[-1], bar=-1, pos=-1)
```
--
nosy: +jameshcorbett
___
Python tracker
<https://bugs.python.org/issue9625>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41436] BUG a simple "and" and "or"
James Corbett added the comment:
I think this would have been a better fit for a StackOverflow issue:
https://stackoverflow.com/questions/tagged/python. Also, it's not a compilation
error and it doesn't have anything to do with CPython's testing framework.
Anyway, I don't think this is a bug. For a string `ch`, it is always true that
either `ch != 'n'` or `ch != 'N'`---no string is equal to both `'N'` and `'n'`.
Therefore your `while` condition will always be true and the loop will always
continue.
As you already noted, your loop will terminate properly if you used `and`. You
could also rewrite it as `while ch not in ('n', 'N'):` which I think is clearer.
--
nosy: +jameshcorbett, xtreak
type: compile error -> behavior
___
Python tracker
<https://bugs.python.org/issue41436>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41430] Document C docstring behavior
Change by James Corbett : -- keywords: +patch pull_requests: +20816 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21673 ___ Python tracker <https://bugs.python.org/issue41430> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41430] Document C docstring behavior
New submission from James Corbett : As described in https://stackoverflow.com/questions/25847035/what-are-signature-and-text-signature-used-for-in-python-3-4, https://bugs.python.org/issue20586, and https://stackoverflow.com/questions/50537407/add-a-signature-with-annotations-to-extension-methods, it is possible to embed a signature in docstrings for C functions, so that `help` and `inspect.signature` work properly on them. However, this functionality isn't documented anywhere. I think something should be added to the "extending and embedding the Python interpreter" tutorial. -- assignee: docs@python components: Documentation messages: 374547 nosy: docs@python, jameshcorbett priority: normal severity: normal status: open title: Document C docstring behavior type: enhancement ___ Python tracker <https://bugs.python.org/issue41430> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41046] unittest: make skipTest a classmethod
James Corbett added the comment: I was careless in my example, it would need to be `cls.skipTest(reason)`. However, that really doesn't have anything to do with why it should be a `classmethod` instead of an instance method: it's so that you can call `skipTest` from `classmethods`, namely `setUpClass` which is called by the `unittest` framework. You can currently call `skipTest` from `setUpClass` only with something ugly like `cls.skipTest(None, reason)` (i.e. passing `None` for the `self` parameter, which works because `self` isn't used). -- ___ Python tracker <https://bugs.python.org/issue41046> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41423] `multiprocessing.Array` and `multiprocessing.managers.SyncManager.Array` APIs are similar but not the same
New submission from James Thistlewood : I stumbled across this by trying to implement a call to the latter, while reading the docs for the former. I think this is quite confusing and unnecessary that the APIs between these two definitions should differ. The same goes for `multiprocessing.Value` and `multiprocessing.managers.SyncManager.Value`. This is especially exacerbated by the fact that the docs _are incorrect_. On this page [1], under 'Server process', a link to 'Array' is made. If it were correct, it would link to `multiprocessing.managers.SyncManager.Array`, since it's talking about a manager object - the kind returned by `Manager()`. But it links to `multiprocessing.Array`. Of course, the simple solution would be to change the link to link to the correct place, but I think this shows an unnecessary inconsistency in the API itself. I don't have a PR for this yet, nor have I fully investigated, but should it be feasible I would like to implement it myself. I'm interested to hear what people think. [1] https://docs.python.org/3/library/multiprocessing.html#sharing-state-between-processes -- components: Library (Lib) messages: 374519 nosy: jthistle priority: normal severity: normal status: open title: `multiprocessing.Array` and `multiprocessing.managers.SyncManager.Array` APIs are similar but not the same type: behavior versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue41423> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41414] AST for arguments shows extra element
New submission from James Foster :
https://docs.python.org/3.8/library/ast.html shows seven elements:
arguments = (arg* posonlyargs, arg* args, arg? vararg, arg* kwonlyargs,
expr* kw_defaults, arg? kwarg, expr* defaults)
https://docs.python.org/3.7/library/ast.html shows six elements:
arguments = (arg* args, arg? vararg, arg* kwonlyargs, expr* kw_defaults,
arg? kwarg, expr* defaults)
based on ast.c:1479 I believe that six is the proper number and that the first
element ("arg* posonlyargs, ") is a duplicate of the second element ("arg*
args, ") and should be removed.
--
assignee: docs@python
components: Documentation
messages: 374425
nosy: docs@python, jgfoster
priority: normal
severity: normal
status: open
title: AST for arguments shows extra element
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue41414>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38863] Improve is_cgi() in http.server
Change by Rhodri James : -- nosy: -Rhodri James ___ Python tracker <https://bugs.python.org/issue38863> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24764] cgi.FieldStorage can't parse multipart part headers with Content-Length and no filename in Content-Disposition
Change by Rhodri James : -- nosy: -Rhodri James ___ Python tracker <https://bugs.python.org/issue24764> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21705] cgi.py: Multipart with more than one file is misparsed
Change by Rhodri James : -- nosy: -Rhodri James ___ Python tracker <https://bugs.python.org/issue21705> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1047397] cgitb failures
Change by Rhodri James : -- nosy: -Rhodri James ___ Python tracker <https://bugs.python.org/issue1047397> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39727] cgi.parse() fatally attempts str.decode when handling multipart/form-data
Change by Rhodri James : -- nosy: -Rhodri James ___ Python tracker <https://bugs.python.org/issue39727> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10879] cgi memory usage
Change by Rhodri James : -- nosy: -Rhodri James ___ Python tracker <https://bugs.python.org/issue10879> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9968] Let cgi.FieldStorage have named uploaded file
Change by Rhodri James : -- nosy: -Rhodri James ___ Python tracker <https://bugs.python.org/issue9968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41140] cgitb uses the locale encoding for log files
Change by Rhodri James : -- nosy: -Rhodri James ___ Python tracker <https://bugs.python.org/issue41140> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41139] cgi uses the locale encoding for log files
Change by Rhodri James : -- nosy: -Rhodri James ___ Python tracker <https://bugs.python.org/issue41139> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27777] cgi.FieldStorage can't parse simple body with Content-Length and no Content-Disposition
Change by Rhodri James : -- nosy: -Rhodri James ___ Python tracker <https://bugs.python.org/issue2> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41209] Scripts Folder is Empty
New submission from James McCorkindale : The Scripts folder is empty and I'm not sure what's wrong. I'm trying to install modules and looked it up on the internet and I think I need this folder not to be empty. How should i fix this? Thanks, James -- components: Windows messages: 373007 nosy: Jamesss04, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Scripts Folder is Empty type: behavior versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue41209> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40782] AbstactEventLoop.run_in_executor is listed as an async method, but should actually return a Futrue
James Barrett added the comment: Is there any further movement on this? -- ___ Python tracker <https://bugs.python.org/issue40782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41047] argparse: misbehavior when combining positionals and choices
Change by James Corbett : -- keywords: +patch pull_requests: +20172 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20997 ___ Python tracker <https://bugs.python.org/issue41047> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41047] argparse: misbehavior when combining positionals and choices
New submission from James Corbett :
The `argparse.ArgumentParser` sometimes rejects positional arguments with no
arguments when `choices` is set and `nargs="*"`.
When there are no arguments and `nargs` is `"*"`, the default value is chosen,
or `[]` if there is no default value. This value is then checked against
`choices` and an error message is printed if the value is not in `choices`.
However, sometimes the value is intentionally not in `choices`, and this leads
to problems. An example will explain this much better, and show that the issue
only occurs with the particular combination of positionals, `nargs="*"`, and
`choices`:
```
>>> import argparse
>>> parser = argparse.ArgumentParser()
>>> parser.add_argument("foo", choices=["a", "b", "c"], nargs="*")
>>> parser.add_argument("--bar", choices=["d", "e", "f"], nargs="*")
>>> parser.add_argument('--baz', type=int, choices=range(5, 10), default="20")
>>> parser.parse_args("a --bar".split())
Namespace(foo=['a'], bar=[], baz=20)
>>> parser.parse_args(["a"])
Namespace(foo=['a'], bar=None, baz=20)
>>> parser.parse_args([])
usage: [-h] [--bar [{d,e,f} ...]] [--baz {5,6,7,8,9}] [{a,b,c} ...]
: error: argument foo: invalid choice: [] (choose from 'a', 'b', 'c')
```
In this case I could have got around the last error by adding `[]` to choices,
but that pollutes the help and usage messages.
--
components: Library (Lib)
messages: 371915
nosy: jameshcorbett
priority: normal
severity: normal
status: open
title: argparse: misbehavior when combining positionals and choices
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue41047>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41046] unittest: make skipTest a classmethod
Change by James Corbett : -- keywords: +patch pull_requests: +20171 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20996 ___ Python tracker <https://bugs.python.org/issue41046> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41046] unittest: make skipTest a classmethod
New submission from James Corbett : The `unittest.TestCase.skipTest` method, used to skip the current test, is currently an instance method. There's nothing to stop it from being a `classmethod` or a `staticmethod` though---it doesn't use its reference to `self` since it's just a wrapper around the `SkipTest` exception. Making it a `classmethod` or `staticmethod` would allow calling the method from `setUpClass`. Here's an example: ``` import unittest class MyTestCase(unittest.TestCase): @classmethod def ready_for_tests(cls): pass @classmethod def setUpClass(cls): if not cls.ready_for_tests(): cls.skipTest() ``` -- components: Library (Lib) messages: 371914 nosy: jameshcorbett priority: normal severity: normal status: open title: unittest: make skipTest a classmethod type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue41046> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40782] AbstactEventLoop.run_in_executor is listed as an async method, but should actually return a Futrue
New submission from James Barrett : As discussed in < https://github.com/python/typeshed/issues/3999#issuecomment-634097968 > the type of `AbstractEventLoop.run_in_executor` is defined at < https://github.com/python/cpython/blob/master/Lib/asyncio/events.py#L286 > as follows: ``` async def run_in_executor(self, executor, func, *args): raise NotImplementedError ``` However all concrete implementations of this method are actually not async methods but rather synchronous methods which return a Future object. Logically this appears to make sense: at base `run_in_executor` is not a coroutine, since it doesn't create an object representing code which will be executed when the object is awaited, rather it returns an object representing code which is running asynchronously elsewhere (on another thread) and which can be awaited to wait for that other thread to complete its task. Which seems to be a perfect match to what a Future object is supposed to be. As such it seems that the current definition of the method as a coroutine is possibly a mistake. Alternatively if some feel that it is important to allow concrete implementations to implement it as a coroutine if they need to then perhaps it could be specified to be a method returning an Awaitable, since that would cover both options? -- components: Library (Lib) messages: 370005 nosy: jamesba priority: normal severity: normal status: open title: AbstactEventLoop.run_in_executor is listed as an async method, but should actually return a Futrue type: behavior versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue40782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18857] urlencode of a None value uses the string 'None'
James Addison added the comment: NB: There appears to be some relevant discussion in https://github.com/whatwg/url/issues/469 -- ___ Python tracker <https://bugs.python.org/issue18857> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18857] urlencode of a None value uses the string 'None'
James Addison added the comment:
The pair of pull requests below implement None-preserving urlencode and
parse_qs* via a default-disabled flag 'standalone_keys'.
- https://bugs.python.org/pull_request19259
- https://bugs.python.org/pull_request19264
(they're also already linked with this issue, thanks to the neat GitHub/BPO
integration)
A benefit of the proposed serialization changes is that developers can opt-in
to a scheme in which "{'a': None}" and "{'a': ''}" do not collide to the same
encoded representation.
Would it be possible to re-open this issue for discussion?
--
___
Python tracker
<https://bugs.python.org/issue18857>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18857] urlencode of a None value uses the string 'None'
Change by James Addison : -- pull_requests: +19264 pull_request: https://github.com/python/cpython/pull/19949 ___ Python tracker <https://bugs.python.org/issue18857> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18857] urlencode of a None value uses the string 'None'
Change by James Addison : -- pull_requests: +19259 pull_request: https://github.com/python/cpython/pull/19945 ___ Python tracker <https://bugs.python.org/issue18857> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18857] urlencode of a None value uses the string 'None'
James Addison added the comment: Chiming in here to add that I'd appreciate the ability to render 'standalone' (i.e. no '=') query-string keys in order to distinguish between absence-of-value and empty-string situations. The backwards-compatibility concerns in here are genuine, so perhaps this could be introduced as an argument to urlencode with a disabled default value, allowing developers to opt-in. >> Unless someone can point to a "real" web server that does something >> different with "" than with "=", there is no reason to make a change >> to Python. There's a popular nodejs library that makes this serialization distinction explicit: https://github.com/sindresorhus/query-string#falsy-values I've developed a Python 3.7-based set of commits[1] to address this issue. I haven't yet opened this as a pull request since I see that Python 3.7 is in maintenance/bugfix mode[2]. In case a new urlencode flag would fall under the category of feature, I'll aim to develop a subsequent set of commits against the master development branch soon. [1] - https://github.com/jayaddison/cpython/compare/3.7..9555467 [2] - https://devguide.python.org/#status-of-python-branches -- nosy: +jayaddison ___ Python tracker <https://bugs.python.org/issue18857> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39918] random.Random(False) weird error
New submission from Jerry James : Python 3.8: >>> import random >>> r = random.Random(False) >>> r Python 3.9 alpha 4: >>> import random >>> r = random.Random(False) Traceback (most recent call last): File "", line 1, in File "/usr/lib64/python3.9/random.py", line 100, in __init__ self.seed(x) File "/usr/lib64/python3.9/random.py", line 163, in seed super().seed(a) TypeError: descriptor '__abs__' of 'int' object needs an argument This arose in the context of Fedora builds with python 3.9. The networkx project reversed two arguments, resulting in False being passed to random.Random instead of the intended seed value. I'm glad we noticed the problem with 3.9 so the intended value will now be used, but that TypeError message doesn't really indicate the nature of the problem. Could you arrange for a better message? -- components: Library (Lib) messages: 363766 nosy: loganjerry priority: normal severity: normal status: open title: random.Random(False) weird error type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39918> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39727] cgi.parse() fatally attempts str.decode when handling multipart/form-data
James Edington added the comment: Here is a file to try it out in an instant. (lines 11–28 are not necessary; they are just "luxuries" allowing easier testing of the issue in a web browser) -- Added file: https://bugs.python.org/file48903/demo.py ___ Python tracker <https://bugs.python.org/issue39727> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39727] cgi.parse() fatally attempts str.decode when handling multipart/form-data
New submission from James Edington : It appears that cgi.parse() in Python 3.7.6 [GCC 9.2.1 20190827 (Red Hat 9.2.1-1)] fatally chokes on POST requests with multipart/form-data due to some internal processing still relying on assumptions from when str and bytes were the same object. I'll attach as the first comment the "try-it-at-home" file to demonstrate this error. -- components: Library (Lib) files: curlLogs.txt messages: 362490 nosy: James Edington priority: normal severity: normal status: open title: cgi.parse() fatally attempts str.decode when handling multipart/form-data type: behavior versions: Python 3.7 Added file: https://bugs.python.org/file48902/curlLogs.txt ___ Python tracker <https://bugs.python.org/issue39727> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39407] Bitfield Union does not work for bit widths greater than 8 bits
New submission from James :
Creating a Bitfield from a ctypes union and structure results in unexpected
behaviour. It seems when you set the bit-width of a structure field to be
greater than 8 bits it results in the subsequent bits being set to zero.
class BitFieldStruct(ctypes.LittleEndianStructure):
_fields_ = [
("long_field", C_UINT32, 29),
("short_field_0", C_UINT8, 1),
("short_field_1", C_UINT8, 1),
("short_field_2", C_UINT8, 1),
]
class BitField(ctypes.Union):
_anonymous_ = ("fields",)
_fields_ = [
("fields", BitFieldStruct),
("as32bit", C_UINT32)
]
def test_bit_field_union():
f = BitField()
f.as32bit = int.from_bytes([255, 255, 255, 255], byteorder='little')
assert f.long_field == int.from_bytes([255, 255, 255, 31],
byteorder='little')
assert f.short_field_0 == 1
assert f.short_field_1 == 1
assert f.short_field_2 == 1
test_bit_field_union() # this call will fail with an assertion error
Equivalent C which does not fail https://rextester.com/FWV78514
I'm running on Ubuntu 16.04 with python3.6 but I have tested on 3.5, 3.7 and on
repl.it with the same behaviour.
It seems as though setting any of the struct fields to be greater than 8 bit
width results in any of the following fields being set to zero.
--
components: ctypes
files: python_struct_union_bug.py
messages: 360372
nosy: jschulte
priority: normal
severity: normal
status: open
title: Bitfield Union does not work for bit widths greater than 8 bits
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7
Added file: https://bugs.python.org/file48856/python_struct_union_bug.py
___
Python tracker
<https://bugs.python.org/issue39407>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27657] urlparse fails if the path is numeric
James Brown added the comment: This is a surprising change to put in a minor release. This change totally changes the semantics of parsing scheme-less URLs with ports in them and ended up breaking a significant amount of my software. It turns out that urls like `example.com:80` are more common than one might hope, and a lot of software has always assumed that `example.com:80` would get parsed as the netloc and the software can guess the scheme based on the port... -- nosy: +James Brown2 ___ Python tracker <https://bugs.python.org/issue27657> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39170] Sqlite3 row_factory for attribute access: NamedRow
Change by Clinton James : -- keywords: +patch pull_requests: +17204 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17768 ___ Python tracker <https://bugs.python.org/issue39170> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39170] Sqlite3 row_factory for attribute access: NamedRow
New submission from Clinton James :
Currently, sqlite3 returns rows by tuple or sqlite3.Row for dict-style, index
access. I constantly find myself wanting attribute access like namedtuple for
rows. I find attribute access cleaner
without the brackets and quoting field names. However, unlike previous
discussions (https://bugs.python.org/issue13299), I don't want to use the
namedtuple object. I appreciate the simple API and minimal memory consumption
of sqlite3.Row and used it as my guide in creating sqlite3.NamedRow to allow
access by index and attribute.
A pull request is ready
Why a new object instead of adding attribute access to the existing sqlite3.Row?
There is an existing member method `keys` and any table with the field "keys"
would cause a hard to debug, easily avoidable, collision.
Features:
+ Optimized in C, so it will be faster than any python implementation.
+ Access columns by attribute for all valid names and by index for all names.
+ Iterate over fields by name/value pairs.
+ Works with standard functions `len` and `contains`.
+ Identical memory consumption to sqlite3.Row with two references: the data
tuple and the cursor description.
+ Identical speed to sqlite3.Row if not faster. Timing usually has it slightly
faster for index by name or attribute, but it is almost identical.
Examples:
>>> import sqlite3
>>> c = sqlite3.Connection(":memory:").cursor()
>>> c.row_factory = sqlite3.NamedRow
>>> named_row = c.execute("SELECT 'A' AS letter, '.-' AS morse, 65 AS
ord").fetchone()
>>> len(named_row)
3
>>> 'letter' in named_row
true
>>> named_row == named_row
true
>>> hash(named_row)
5512444875192833987
Index by number and range.
>>> named_row[0]
'A'
>>> named_row[1:]
('.-', 65)
Index by column name.
>>> named_row["ord"]
65
Access by attribute.
>>> named_row.morse
'.-'
Iterate row for name/value pairs.
>>> dict(named_row)
{'letter': 'A', 'morse': '.-', 'ord': 65}
>>> tuple(named_row)
(('letter', 'A'), ('morse', '.-'), ('ord', 65))
How sqlite3.NamedRow differs from sqlite3.Row
--
The class only has class dunder methods to allow any valid field name. When the
field name would be an invalid attribute name, you have two options: either use
the SQL `AS` in the select statement or index by name.
To get the field names use the iterator `[x[0] for x in row]` or do the same
from the
`cursor.description`.
```python
titles = [x[0] for x in row]
titles = [x[0] for x in cursor.description]
titles = dict(row).keys()
```
Attribute and dict access are no longer case-insensitive. There are three
reasons for this.
1. Case-insensitive comparison only works well for ASCII characters. In a
Unicode world, case-insensitive edge cases create unnecessary errors. Looking
at a several existing codebases,
this feature of Row is almost never used and I believe is not needed in
NamedRow.
2. Case-insensitivity is not allowed for attribute access. This "feature"
would treat attribute access differently from the rest of Python and "special
cases aren't special enough to break the rules". Where `row.name`, `row.Name`,
and `row.NAME` are all the same it gives off the faint code smell of something
wrong. When case-insensitively is needed and the query SELECT can not be
modified, sqlite3.Row is still there.
3. Code is simpler and easier to maintain.
4. It is faster.
Timing Results
--
NamedRow is faster than sqlite3.Row for index-by-name access.
I have published a graph and the methodology of my testing. In the worst-case
scenario, it is just as fast as sqlite3.Row without any extra memory. In most
cases, it is faster.
For more information, see the post at
http://jidn.com/2019/10/namedrow-better-python-sqlite3-row-factory/
--
components: Library (Lib)
messages: 359104
nosy: jidn
priority: normal
severity: normal
status: open
title: Sqlite3 row_factory for attribute access: NamedRow
type: enhancement
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue39170>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26730] SpooledTemporaryFile doesn't correctly preserve data for text (non-binary) SpooledTemporaryFile objects when Unicode characters are written
James Hennessy added the comment: The quickest fix for the data corruption problem is to delete the line newfile.seek(file.tell(), 0) from the rollover() method. This doesn't fix the inconsistency of tell() and seek(), but it's very low risk. It's technically a change to the API, that rollover() no longer preserves the seek position, but unless the user was writing only characters from the ISO-8859-1 character set, it wasn't working properly before anyway. -- ___ Python tracker <https://bugs.python.org/issue26730> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26730] SpooledTemporaryFile doesn't correctly preserve data for text (non-binary) SpooledTemporaryFile objects when Unicode characters are written
James Hennessy added the comment: I don't like the idea of using a TemporaryFile right from the beginning in text mode. You might as well remove text mode support altogether if that's the approach you want to take, since it undoes any potential performance benefit of using SpooledTemporaryFile in the first place. -- ___ Python tracker <https://bugs.python.org/issue26730> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26730] SpooledTemporaryFile doesn't correctly preserve data for text (non-binary) SpooledTemporaryFile objects when Unicode characters are written
James Hennessy added the comment: I have to disagree with the idea that SpooledTemporaryFile is not useful. Although on some systems, the file system may appear as fast as memory, that cannot be assumed to be universally true. I think the idea behind SpooledTemporaryFile is completely valid. -- ___ Python tracker <https://bugs.python.org/issue26730> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38566] Description of '\w' behavior is vague in `re` documentation
James Gerity added the comment: Cheers for the additional context. My recommendation would be to change the language to avoid confusion with the consortium's formal specifications. Describing what SRE does should be fine: > Matches any alphanumeric Unicode character, as well as '_'. If the ASCII flag > is used, only [a-zA-Z0-9_] is matched. I think it'd also be nice for the term "alphanumeric Unicode character" to link to the documentation for `str.isalnum()`, which provides enough clarity for the user to work out exactly what Unicode category properties will end up qualifying as a match. -- ___ Python tracker <https://bugs.python.org/issue38566> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
