ANN: EmPy 4.0.1
r` instead of "fully buffered files"; cleaned up environment variables; "repr" markup replaced with emoji markup; remove literal markups `@)`, `@]`, `@}`; context line markup `@!...` no longer pre-adjusts line; custom markup `@<...>` now parsed more sensibly; filter shortcuts removed; context now track column and character count; auxiliary classes moved to `emlib` module; use `argv` instead of `argc` for interpreter arguments. See [Full list of changes between EmPy 3._x_ and 4.0](http://www.alcyone.com/software/empy/ANNOUNCE.html#full-list-of-changes-between-empy-3-x-and-4-0) for a more comprehensive list. -- Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/ San Jose, CA, USA && 37 18 N 121 57 W && Skype erikmaxfrancis To be refutable is not the least charm of a theory. -- Friedrich Nietzsche -- https://mail.python.org/mailman/listinfo/python-list
Re: Passing info to function used in re.sub
On 3 Sep 2023, at 18:10, Jan Erik Moström via Python-list wrote: > I'm looking for some advice for how to write this in a clean way Thanks for all the suggestion, I realize that I haven't written Python code in a while. I should have remembered this myself !!! Thanks for reminding me. = jem -- https://mail.python.org/mailman/listinfo/python-list
Re: Passing info to function used in re.sub
On 3 Sep 2023, at 19:13, MRAB via Python-list wrote: > You could use pass an anonymous function (a lambda) to re.sub: Of course !! Thanks. = jem -- https://mail.python.org/mailman/listinfo/python-list
Passing info to function used in re.sub
I'm looking for some advice for how to write this in a clean way I want to replace some text using a regex-pattern, but before creating replacement text I need to some file checking/copying etc. My code right now look something like this: def fix_stuff(m): # Do various things that involves for info # that what's available in m replacement_text = m.group(1) + global_var1 + global_var2 return replacement_text and the call comes here global_var1 = "bla bla" global_var2 = "pff" new_text = re.sub(im_pattern,fix_stuff,md_text) The "problem" is that I've currently written some code that works but it uses global variables ... and I don't like global variables. I assume there is a better way to write this, but how? = jem -- https://mail.python.org/mailman/listinfo/python-list
ImportError: No module named spambayes.resources (line 12 of setup_all.py)
Is anyone here familiar with SpamBayes? I am working with legacy 2.4.x Python code (I'm not a programmer, more of a power user) and I'm attempting to build the windows binary from the SpamBayes source. I'm running into an error when attempting to run "setup_all.py", the py2exe setup script, and I get the following: "ImportError: No module named spambayes.resources (line 12 of setup_all.py)" I'm able to run Spambayes from these source files in Outlook and have the correct python version, pywin32, as well as py2exe (2.4.x). Any idea on how to resolve this module import error? I can provide files and/or more details as well. Thank you all for the help! Take care, Erik Brown -- https://mail.python.org/mailman/listinfo/python-list
[issue47174] Define behavior of descriptor-typed fields on dataclasses
New submission from Erik De Bonte : Recent discussions about PEP 681 (dataclass_transform) have focused on support for descriptor-typed fields. See the email thread here: https://mail.python.org/archives/list/typing-...@python.org/thread/BW6CB6URC4BCN54QSG2STINU2M7V4TQQ/ Initially we were thinking that dataclass_transform needed a new parameter to switch between two modes. In one mode, it would use the default behavior of dataclass. In the other mode, it would be smarter about how descriptor-typed fields are handled. For example, __init__ would pass the value for a descriptor-typed field to the descriptor's __set__ method. However, Carl Meyer found that dataclass already has the desired behavior at runtime! We missed this because mypy and Pyright do not correctly mirror this runtime behavior. Although this is the current behavior of dataclass, I haven't found it documented anywhere and the behavior is not covered by unit tests. Since dataclass_transform wants to rely on this behavior and the behavior seems desirable for dataclass as well, I'm proposing that we add additional dataclass unit tests to ensure that this behavior does not change in the future. Specifically, we would like to document (and add unit tests for) the following behavior given a field whose default value is a descriptor: 1. The value passed to __init__ for that field is passed to the descriptor’s __set__ method, rather than overwriting the descriptor object. 2. Getting/setting the value of that field goes through __get__/__set__, rather than getting/overwriting the descriptor object. Here's an example: class Descriptor(Generic[T]): def __get__(self, __obj: object | None, __owner: Any) -> T: return getattr(__obj, "_x") def __set__(self, __obj: object | None, __value: T) -> None: setattr(__obj, "_x", __value) @dataclass class InventoryItem: quantity_on_hand: Descriptor[int] = Descriptor[int]() i = InventoryItem(13) # calls __set__ with 13 print(i.quantity_on_hand) # 13 -- obtained via call to __get__ i.quantity_on_hand = 29 # calls __set__ with 29 print(i.quantity_on_hand) # 29 -- obtained via call to __get__ I took a first stab at unit tests here: https://github.com/debonte/cpython/commit/c583e7c91c78c4aef65a1ac69241fc06ad95d436 We are aware of two other descriptor-related behaviors that may also be worth documenting: First, if a field is annotated with a descriptor type but is *not* assigned a descriptor object as its default value, it acts like a non-descriptor field. Here's an example: @dataclass class InventoryItem: quantity_on_hand: Descriptor[int] # No default value i = InventoryItem(13) # Sets quantity_on_hand to 13 -- No call to Descriptor.__set__ print(i.quantity_on_hand) # 13 -- No call to Descriptor.__get__ And second, when a field with a descriptor object as its default value is initialized (when the code for the dataclass is initially executed), __get__ is called with a None instance and the return value is used as the field's default value. See the example below. Note that if __get__ doesn't handle this None instance case (for example, in the initial definition of Descriptor above), a call to InventoryItem() fails with "TypeError: InventoryItem.__init__() missing 1 required positional argument: 'quantity_on_hand'". I'm less sure about documenting this second behavior, since I'm not sure what causes it to work, and therefore I'm not sure how intentional it is. class Descriptor(Generic[T]): def __init__(self, *, default: T): self._default = default def __get__(self, __obj: object | None, __owner: Any) -> T: if __obj is None: return self._default return getattr(__obj, "_x") def __set__(self, __obj: object | None, __value: T) -> None: if __obj is not None: setattr(__obj, "_x", __value) # When this code is executed, __get__ is called with __obj=None and the # returned value is used as the default value of quantity_on_hand. @dataclass class InventoryItem: quantity_on_hand: Descriptor[int] = Descriptor[int](default=100) i = InventoryItem() # calls __set__ with 100 print(i.quantity_on_hand) # 100 -- obtained via call to __get__ -- components: Library (Lib) messages: 416392 nosy: JelleZijlstra, debonte, eric.smith priority: normal severity: normal status: open title: Define behavior of descriptor-typed fields on dataclasses type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue47174> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47071] asyncio proactor udp transport stops responding after send to port that isn't listening
Erik Soma added the comment: Certainly: https://github.com/python/cpython/pull/32011 -- ___ Python tracker <https://bugs.python.org/issue47071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47071] asyncio proactor udp transport stops responding after send to port that isn't listening
Change by Erik Soma : -- keywords: +patch pull_requests: +30099 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32011 ___ Python tracker <https://bugs.python.org/issue47071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47071] asyncio proactor udp transport stops responding after send to port that isn't listening
Erik Soma added the comment: Uploading my hack to `asyncio.windows_events.py` -- this is based off 3.10.2's distribution. -- Added file: https://bugs.python.org/file50692/windows_events.py ___ Python tracker <https://bugs.python.org/issue47071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47071] asyncio proactor udp transport stops responding after send to port that isn't listening
New submission from Erik Soma : Reproducer attached. Change `USE_PROACTOR` to `False` to use the `SelectorEventLoop` instead, which doesn't exhibit this behavior. The output on my machine when using the proactor loop is: ``` datagram received b'ping 1' datagram received b'ping 2' ``` And the selector loop (which is the behavior I would expect): ``` datagram received b'ping 1' datagram received b'ping 2' datagram received b'ping 3' ``` At a high level, after sending data to an address that isn't listening the asyncio protocol will no longer receive messages. Digging deeper, `_ProactorDatagramTransport._loop_reading` encounters the windows error 1234 (ERROR_PORT_UNREACHABLE) after the "bad send". It appears this a (undocumented/buggy?) behavior of `WSARecvFrom` where the next call to it after an unreachable `WSASendTo` in UDP mode will return the ICMP unreachable message. The actual error is returned from `GetOverlappedResult`. I've hacked together a fix that retries `IocpProactor.recvfrom` if the result is ERROR_PORT_UNREACHABLE. It fixes the issue for the reproducer and my actual use case, but it's probably not ideal. My solution for the moment is just to use the SelectorEventLoop instead. -- components: Windows, asyncio files: udpbug2.py messages: 415611 nosy: asvetlov, esoma, paul.moore, steve.dower, tim.golden, yselivanov, zach.ware priority: normal severity: normal status: open title: asyncio proactor udp transport stops responding after send to port that isn't listening versions: Python 3.10 Added file: https://bugs.python.org/file50691/udpbug2.py ___ Python tracker <https://bugs.python.org/issue47071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46755] QueueHandler logs stack_info twice
Change by Erik Montnemery : -- keywords: +patch nosy: +emontnemery nosy_count: 1.0 -> 2.0 pull_requests: +29504 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31355 ___ Python tracker <https://bugs.python.org/issue46755> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31084] QueueHandler not formatting messages
Change by Erik Montnemery : -- nosy: +emontnemery nosy_count: 2.0 -> 3.0 pull_requests: +29505 pull_request: https://github.com/python/cpython/pull/31355 ___ Python tracker <https://bugs.python.org/issue31084> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46755] QueueHandler logs stack_info twice
New submission from Erik Montnemery :
logging.handlers.QueueHandler logs stack twice when stack_info=True:
>>> import logging
>>> from logging.handlers import QueueHandler, QueueListener
>>> from queue import Queue
>>> q = Queue()
>>> logging.getLogger().addHandler(QueueHandler(q))
>>> listener = QueueListener(q, logging.StreamHandler())
>>> listener.start()
>>> _LOGGER.error("Hello", stack_info=True)
Hello
Stack (most recent call last):
File "", line 1, in
Stack (most recent call last):
File "", line 1, in
Reproduced on CPython 3.9.9, but the code is unchanged in 3.10 and 3.11, so the
issue should exist there too.
Patching QueueHandler.prepare() to set stack_info to None seems to fix this:
diff --git a/Lib/logging/handlers.py b/Lib/logging/handlers.py
index d42c48de5f..7cd5646d85 100644
--- a/Lib/logging/handlers.py
+++ b/Lib/logging/handlers.py
@@ -1452,6 +1452,7 @@ def prepare(self, record):
record.args = None
record.exc_info = None
record.exc_text = None
+record.stack_info = None
return record
def emit(self, record):
Related issue: Issue34334, with patch
https://github.com/python/cpython/pull/9537
--
components: Library (Lib)
messages: 413278
nosy: erik.montnemery
priority: normal
severity: normal
status: open
title: QueueHandler logs stack_info twice
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue46755>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38401] Make dataclass attribute docstrings accessible
Erik Gebeshuber added the comment: There is some confusion in the answers that I want to clear up: "Attribute docstrings" were suggested in PEP 224 in August 2000 and rejected March 2001: https://www.python.org/dev/peps/pep-0224/ taleinat mentioned already PEP 258 from May 2001, which also contained "attribute docstrings" and was as well rejected. At the same time - May 2001 - the well-known PEP 257 about docstring conventions came up and was accepted. It also mentions "attribute docstrings", but in a kind of restricted way (highlighting *** by me): > String literals occurring elsewhere in Python code ***may also act as > documentation***. They are ***not recognized*** by the Python bytecode > compiler and are ***not accessible*** as runtime object attributes (i.e. not > assigned to __doc__), ... > Please see PEP 258, "Docutils Design Specification" [2], for a detailed > description of attribute and additional docstrings. The reference to the rejected PEP 258 does in my opinion not make the concept of "attribute docstrings" invalid, but indeed the restrictive wording (highlighted *** in the quote) defines their status, and it helps to explain the situation: * Attribute docstrings are not supported by Python itself (no __doc__ etc.) -> that's why it is hard to add support for dataclass documentation in `help` as John Parejko suggested. * It is totally fine to use attribute docstrings, since PEP 257 explicitly mentions them. Various tools support them. * There is - as far as I can see it - no clear notion to differentiate between "official" docstrings and "inofficial" ones (attribute docstrings, additional docstrings). All of them are docstrings in the broader sense, though most times only the "official" ones are meant, and many don't even know about the "inofficial" ones. -- nosy: +egebes ___ Python tracker <https://bugs.python.org/issue38401> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45972] typing.NamedTuple with default arguments without type annotations is falsy
Erik Montnemery added the comment:
Maybe something like this:
diff --git a/Doc/library/typing.rst b/Doc/library/typing.rst
index 735d477db4..8de913d8db 100644
--- a/Doc/library/typing.rst
+++ b/Doc/library/typing.rst
@@ -1291,7 +1291,8 @@ These are not used in annotations. They are building
blocks for declaring types.
.. class:: NamedTuple
- Typed version of :func:`collections.namedtuple`.
+ Typed version of :func:`collections.namedtuple`, annotated fields are passed
+ to an underlying `collections.namedtuple`.
Usage::
@@ -1311,9 +1312,20 @@ These are not used in annotations. They are building
blocks for declaring types.
employee = Employee('Guido')
assert employee.id == 3
+ assert employee == ('Guido', 3)
Fields with a default value must come after any fields without a default.
+ Non-annotated fields will not be part of the `collections.namedtuple`::
+
+ class Employee(NamedTuple):
+ name = 'Guido'
+ id = 3
+
+ employee = Employee()
+ assert employee.id == 3
+ assert not employee # Passes because the collections.namedtuple is empty
+
The resulting class has an extra attribute ``__annotations__`` giving a
dict that maps the field names to the field types. (The field names are in
--
___
Python tracker
<https://bugs.python.org/issue45972>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45972] typing.NamedTuple with default arguments without type annotations is falsy
Erik Montnemery added the comment: I think elaborating in the documentation that only annotated attributes make it to the underlying namedtuple() would be helpful, it's not obvious that they are instead just class attributes. -- ___ Python tracker <https://bugs.python.org/issue45972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45972] typing.NamedTuple with default arguments without type annotations is falsy
New submission from Erik Montnemery : typing.NamedTuple behaves in surprising ways when it has default arguments which lack type annotations: >>> from typing import NamedTuple >>> class MyTuple(NamedTuple): ... a = 1000 ... >>> tmp = MyTuple() >>> tmp.a 1000 >>> len(tmp) 0 >>> bool(tmp) False Tested in Python 3.8 and 3.9 -- messages: 407570 nosy: emontnemery priority: normal severity: normal status: open title: typing.NamedTuple with default arguments without type annotations is falsy type: behavior versions: Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31842] pathlib: "Incorrect function" during resolve()
Erik Aronesty added the comment:
bug is worse than that:
perfectly valid redirected paths (winfsp ram drives for example) now break in
python 3.9.6 (maybe fixed in later version?)
>>> import pathlib
>>> p=pathlib.Path('C:\\Users\\erik\\Atakama')
>>> p.resolve()
Traceback (most recent call last):
File "", line 1, in
File "c:\users\erik\.pyenv\pyenv-win\versions\3.9.6\Lib\pathlib.py", line
1205, in resolve
s = self._flavour.resolve(self, strict=strict)
File "c:\users\erik\.pyenv\pyenv-win\versions\3.9.6\Lib\pathlib.py", line
206, in resolve
s = self._ext_to_normal(_getfinalpathname(s))
OSError: [WinError 1005] The volume does not contain a recognized file system.
... yet
dir 'C:\\Users\\erik\\Atakama'
Desktop.ini Personal\ Files Vault
mounted via winfsp
--
nosy: +earonesty
versions: +Python 3.9 -Python 3.8
___
Python tracker
<https://bugs.python.org/issue31842>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45537] Cygwin is unsupported - close all open issues and list them here.
Change by Erik Bray : -- pull_requests: +27359 pull_request: https://github.com/python/cpython/pull/4149 ___ Python tracker <https://bugs.python.org/issue45537> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45537] Cygwin is unsupported - close all open issues and list them here.
Change by Erik Bray : -- keywords: +patch nosy: +erik.bray nosy_count: 1.0 -> 2.0 pull_requests: +27357 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14013 ___ Python tracker <https://bugs.python.org/issue45537> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31882] Cygwin: asyncio and asyncore test suites hang indefinitely due to bug in Cygwin
Erik Bray added the comment: To my knowledge this issue is *not* fixed upstream. However, my PR no doubt needs rebasing. -- ___ Python tracker <https://bugs.python.org/issue31882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31885] Cygwin: socket test suites hang indefinitely due to bug in Cygwin
Erik Bray added the comment: That person was me--I have the keys to a cygwin buildbot, but it's currently not running. I lost the urgency to make cygwin fully supported, though it's come a long way. In particular the deprecation of distutils should help nix some of the long-standing issues. -- ___ Python tracker <https://bugs.python.org/issue31885> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31885] Cygwin: socket test suites hang indefinitely due to bug in Cygwin
Erik Bray added the comment: Thanks for asking. Indeed the fix to that issue was included in https://cygwin.com/git/?p=newlib-cygwin.git;a=commit;h=5ca28a0cd71436a84797d5d66831790004e0 and as Cygwin obsoletes old releases rather quickly I see no reason to keep this issue open. -- resolution: -> out of date stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue31885> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34553] Python Crashes when trying to access any date related fields in MailItem
Erik Janssens added the comment: At least for us, the issue seems to be related to the MSVC runtime. We compiled python with mingw using the mingw runtime, and the issue was gone. On Tue, 2021-10-19 at 09:02 +, Irit Katriel wrote: > Irit Katriel added the comment: > It doesn't look like there's anything we can do here on the python > side. > If nobody will object I will close this ticket. > --nosy: +iritkatrielstatus: open -> pending > ___Python tracker > < > https://bugs.python.org/issue34553>___ -- status: pending -> open ___ Python tracker <https://bugs.python.org/issue34553> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[Python-announce]ANN: Astropy v4.3 and v4.0.6 released
Dear colleagues, We are very happy to announce the v4.3 release of the Astropy package, a core Python package for Astronomy: http://www.astropy.org Astropy is a community-driven Python package intended to contain much of the core functionality and common tools needed for astronomy and astrophysics. It is part of the Astropy Project, which aims to foster an ecosystem of interoperable astronomy packages for Python. New and improved major functionality in this release includes: * Transformations to AltAz are now much more precise (and faster) * Improvements in making Astropy thread-safe * Performance improvements to sigma clipping * Changes in the Time and IERS leap second handling * Support for multidimensional and object columns in ECSV * Support for reading and writing tables to QDP format * Append table to existing FITS file * General masked class for Quantity and other ndarray subclasses * Configuration file improvements * Support for different solvers and bracket option in z_at_value In addition, hundreds of smaller improvements and fixes have been made. An overview of the changes is provided at: http://docs.astropy.org/en/stable/whatsnew/4.3.html Instructions for installing Astropy are provided on our website, and extensive documentation can be found at: http://docs.astropy.org If you usually use pip/vanilla Python, you can do: pip install astropy --upgrade Note that this will yield astropy v4.3.1 instead of 4.3, which is expected - a significant bug reported between the 4.3 release and this announcement means that the correct version is indeed 4.3.1. If you make use of the Anaconda Python Distribution, soon you will be able update to Astropy v4.3.1 with: conda update astropy Or if you cannot wait for Anaconda to update their default version, you can use the conda-forge channel: conda update -c conda-forge astropy Please report any issues, or request new features via our GitHub repository: https://github.com/astropy/astropy/issues Over 400 people have contributed code to Astropy so far, and you can find out more about the team behind Astropy here: https://www.astropy.org/team.html The LTS (Long Term Support) version of Astropy at the time of v4.3's release is v4.0 - this version will be maintained until the next LTS release (v5.0, scheduled for Fall 2021). v4.0.6 is the latest version, also just released. Additionally, note that the Astropy 4.x series only supports Python 3. Python 2 users can continue to use the 2.x series but it is no longer supported (as Python 2 itself is no longer supported). For assistance converting Python 2 code to Python 3, see the Python 3 for scientists conversion guide. If you use Astropy directly for your work, or as a dependency to another package, please remember to acknowledge it by citing the appropriate Astropy paper. For the most up-to-date suggestions, see the acknowledgement page, but as of this release the recommendation is: This research made use of Astropy, a community-developed core Python package for Astronomy (Astropy Collaboration, 2013, 2018). We hope that you enjoy using Astropy as much as we enjoyed developing it! Erik Tollerud v4.3 Release Coordinator on behalf of The Astropy Project https://www.astropy.org/announcements/release-4.3.html ___ Python-announce-list mailing list -- python-announce-list@python.org To unsubscribe send an email to python-announce-list-le...@python.org https://mail.python.org/mailman3/lists/python-announce-list.python.org/ Member address: arch...@mail-archive.com
[issue44552] incomplete documentation of __main__.py
Erik Carstensen added the comment: thanks for the pointer and sorry for the noise! I'll review your text. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue44552> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44552] incomplete documentation of __main__.py
New submission from Erik Carstensen : I can find partial information on how Python treats __main__.py here: https://docs.python.org/3/library/__main__.html However, it is not documented how python handles __main__.py when passing the Python package to the interpreter without -m. If I have a program defined by /tmp/foo/bar.py and a file /tmp/foo/__main__.py, and I run python /tmp/foo ... then Python will run __main__.py, with /tmp/foo prepended to sys.path. I find this behaviour unfortunate; to me it would make more sense to prepend /tmp to sys.path, because then "python /tmp/foo" would be equivalent to "PYTHONPATH=/tmp python -m foo". With the current behaviour, if __main__.py wants to import bar.py, then it must write 'import bar' or 'import foo.bar' depending on whether the interpreter was invoked with -m. Unfortunately, by Hyrum's Law, you can find people describing and encouraging reliance upon the current undocumented behaviour, e.g.: https://www.geeksforgeeks.org/usage-of-__main__-py-in-python/ so perhaps the behaviour can't be changed that easily. Therefore, my request is to document how it works. -- assignee: docs@python components: Documentation messages: 396865 nosy: docs@python, mandolaerik priority: normal severity: normal status: open title: incomplete documentation of __main__.py type: behavior versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44552> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44487] Regression in pathlib.path.read_text
Erik Faye-Lund added the comment: After digging some more, I no longer suspect that this commit is to blame, but instead some logic in Meson that effectively disabled the problematic code under in our use-case before we upgraded our Visual Studio version. The reason is that I was able to reproduce this using Python 3.9, and as far as I can tell that doesn't contain this change. So, sorry for the noise. I'll close this, and rather reopen if I find out I'm wrong. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue44487> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44487] Regression in pathlib.path.read_text
Change by Erik Faye-Lund : -- title: Regression -> Regression in pathlib.path.read_text ___ Python tracker <https://bugs.python.org/issue44487> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44487] Regression
New submission from Erik Faye-Lund : This commit lead to a regression when using Meson on Windows to build the Mesa project: https://github.com/python/cpython/commit/4827483f47906fecee6b5d9097df2a69a293a85c The reason is that pathlib.read_text now uses the locale as the encoding when reading files when there's no encoding explicitly passed in. That means that C++ source files are attempted read as CP1252 on Windows, which throws exceptions when source files contain UTF-8 code-points. -- components: Library (Lib) messages: 396318 nosy: kusma priority: normal severity: normal status: open title: Regression versions: Python 3.10, Python 3.11 ___ Python tracker <https://bugs.python.org/issue44487> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44344] Documentation for pow() should include the possibility of complex numbers as a return type
Erik Y. Adams added the comment: I still think the most important aspect of this is that pow() will return complex numbers, contrary to what is implied by the statement I quoted at the beginning of this thread. Perhaps we should just borrow from the documentation for the power operator, which says: Raising 0.0 to a negative power results in a ZeroDivisionError. Raising a negative number to a fractional power results in a complex number. (In earlier versions it raised a ValueError.) https://docs.python.org/3/reference/expressions.html#the-power-operator -- ___ Python tracker <https://bugs.python.org/issue44344> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Recommendation for drawing graphs and creating tables, saving as PDF
I'm doing something that I've never done before and need some advise for suitable libraries. I want to a) create diagrams similar to this one https://www.dropbox.com/s/kyh7rxbcogvecs1/graph.png?dl=0 (but with more nodes) and save them as PDFs or some format that can easily be converted to PDFs b) generate documents that contains text, lists, and tables with some styling. Here my idea was to save the info as markdown and create PDFs from those files, but if there is some other tools that gives me better control over the tables I'm interested in knowing about them. I looked around around but could only find two types of libraries for a) libraries for creating histograms, bar charts, etc, b) very basic drawing tools that requires me to figure out the layout etc. I would prefer a library that would allow me to state "connect A to B", "connect C to B", "connect B to D", and the library would do the whole layout. The closest I've found it to use markdown and mermaid or graphviz but ... PDFs (perhaps I should just forget about PDFs, then it should be enough to send people to a web page) (and yes, I could obviously use LaTeX ...) = jem -- https://mail.python.org/mailman/listinfo/python-list
[issue44344] Documentation for pow() should include the possibility of complex numbers as a return type
New submission from Erik Y. Adams : https://docs.python.org/3/library/functions.html#pow The built-in pow() function will return a complex number if the base is negative and the exponent is a float between 0 and 1. For example, the value returned by `pow(-1, 1.0/3)` is `(1.0002+1.7320508075688772j)` The answer is mathematically correct, but `-2.0` is also mathematically correct. There is nothing in the documentation currently to suggest that a complex number might be returned; in fact, given the statement "[with] mixed operand types, the coercion rules for binary arithmetic operators apply", one might reasonably expect `-2.0` as the answer. I suggest the following sentences be added to the end of the second paragraph: "If `base` is negative and the `exp` is a `float` between 0 and 1, a complex number will be returned. For example, `pow(-8, 1.0/3)` will return `(1.0002+1.7320508075688772j)`, and not `-2.0.`" -- assignee: docs@python components: Documentation messages: 395305 nosy: docs@python, eyadams priority: normal severity: normal status: open title: Documentation for pow() should include the possibility of complex numbers as a return type type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue44344> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44225] stop() on a stopped loop inhibits the next run_forever
New submission from Erik Carstensen : If you call stop() on an already stopped event loop, then the next call to run_forever will terminate after one loop iteration. I would expect the stop to either be a nop, or to be invalid in this state (and raise an exception). Example: import asyncio async def coro(x): print(x) if x < 10: asyncio.create_task(coro(x+1)) loop = asyncio.get_event_loop() loop.create_task(coro(0)) loop.stop() loop.run_forever() -- components: asyncio messages: 394250 nosy: asvetlov, mandolaerik, yselivanov priority: normal severity: normal status: open title: stop() on a stopped loop inhibits the next run_forever type: behavior versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44225> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43905] dataclasses.astuple does deepcopy on all fields
Erik Carstensen added the comment: Would it make sense to make dataclasses iterable, like so? def __iter__(self): return (getattr(self, field.name) for field in fields(self)) With that in place, deprecating astuple would maybe be less disruptive? -- ___ Python tracker <https://bugs.python.org/issue43905> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43918] anext builtin docstring has no signature text or info about default argument
Erik Welch added the comment: Thanks for taking a look Terry. I saw that error as well. It is separate from this issue, and I don't think it is a bug. No other builtin functions or methods that raise this error with this text have such a notice in their docstring, so it doesn't seem appropriate to me to add it to the docstring at this point in time. Search for "" to find other functions and methods that have the same issue. `dict.pop` is one such example. `inspect.signature(anext)` and `inspect.signature(next)` both raise ValueError. The text for `next` is what one may hope to see (and why you raise a fair point): `"ValueError: no signature found for builtin "`. The difference between `anext` and `next` in this regard is that `anext` uses the argument clinic. It is the argument clinic that converts `NULL` to `""` in the signature text that inspect tries (and fails) to parse to get the AST of. I actually did poke around a bit at having the the Argument Clinic and `inspect` module more intelligently pick up this case to give a better error. I think this is doable, but should not be part of this bug report. -- ___ Python tracker <https://bugs.python.org/issue43918> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43918] anext builtin docstring has no signature text or info about default argument
Change by Erik Welch : -- keywords: +patch pull_requests: +24271 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25551 ___ Python tracker <https://bugs.python.org/issue43918> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43918] anext builtin docstring has no signature text or info about default argument
New submission from Erik Welch : The new builtin `anext` does not have a signature (from `inspect.signature(anext)`). This is expected, because `inspect` does not yet support signatures with C NULL default value. However, `anext` also doesn't have text in its docstring that describes its signature as is typical for builtins. This means `help(anext)` in the Python REPL gives no indication how to call the function. It should. This is clearly an oversight. See comment here: https://github.com/python/cpython/pull/23847#commitcomment-45318696 Also, the "default" argument is not described in the docstring. Related issue: https://bugs.python.org/issue31861 (PR forthcoming) -- components: Interpreter Core messages: 391650 nosy: eriknw, pablogsal priority: normal severity: normal status: open title: anext builtin docstring has no signature text or info about default argument type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43918> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43905] dataclasses.astuple does deepcopy on all fields
New submission from Erik Carstensen :
It seems that the 'dataclass.astuple' function does a deepcopy of all fields.
This is not documented. Two problems:
1. Dictionary keys that rely on object identity are ruined:
import dataclasses
@dataclasses.dataclass
class Foo:
key: object
key = object()
lut = {key: 5}
(y,) = dataclasses.astuple(Foo(x))
# KeyError
lut[y]
2. dataclasses can only be converted to a tuple if all fields are serializable:
import dataclasses
@dataclasses.dataclass
class Foo:
f: object
foo = Foo(open('test.py'))
dataclasses.astuple(foo)
->
TypeError: cannot pickle '_io.TextIOWrapper' object
In my use case, I just want a list of all fields. I can do the following as a
workaround:
(getattr(foo, field.name) for field in dataclasses.fields(foo))
Tested on Python 3.8.7 and 3.7.9.
--
components: Library (Lib)
messages: 391516
nosy: mandolaerik
priority: normal
severity: normal
status: open
title: dataclasses.astuple does deepcopy on all fields
versions: Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue43905>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43310] Method __del__ with callable
Erik Soma added the comment: You can wrap your callable in a regular function: ``` def hack_c(): c = C() def _(*args, **kwargs): return c(*args, **kwargs) return _ A.__del__ = hack_c() ``` Or (untested) make your callable an extension type with Py_TPFLAGS_METHOD_DESCRIPTOR. Or instead of monkey-patching __del__ make __del__ call it: ``` class A: my_del = lambda *args, **kwargs: None def __del__(self): self.my_del(self) A.my_del = C() ``` This doesn't just apply to __del__, other dunders exhibit this behavior as well. It is unintuitive, but I'm pretty sure it's not a bug. -- nosy: +esoma ___ Python tracker <https://bugs.python.org/issue43310> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42840] `type` takes **kwargs for __init_subclass__
Erik Soma added the comment: The CPython PR has gone stale waiting for core review, pinging this per the dev guide. -- ___ Python tracker <https://bugs.python.org/issue42840> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42840] `type` takes **kwargs for __init_subclass__
Erik Soma added the comment: Seems I misframed the issue a bit. I didn't realize keyword arguments besides 'metaclass' were introduced with PEP 3115 with Python 3.0. In any case I've posted a PR to update the docs and typeshed. Typeshed PR for reference: https://github.com/python/typeshed/pull/4918 -- ___ Python tracker <https://bugs.python.org/issue42840> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42840] `type` takes **kwargs for __init_subclass__
Change by Erik Soma : -- keywords: +patch pull_requests: +23000 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24173 ___ Python tracker <https://bugs.python.org/issue42840> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42840] `type` takes **kwargs for __init_subclass__
Erik Soma added the comment: Can do. I have found a blurb in the 3.6 What's New that confirms it was purposeful (https://docs.python.org/3/whatsnew/3.6.html#index-37). -- ___ Python tracker <https://bugs.python.org/issue42840> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42840] `type` takes **kwargs for __init_subclass__
New submission from Erik Soma :
The documentation (https://docs.python.org/3/library/functions.html#type) shows
type's signature as:
class type(object)
class type(name, bases, dict)
But the "actual" 2nd signature in CPython 3.6+ is:
class type(name, bases, dict, **kwargs)
**kwargs here gets passed to __init_subclass__ in the same way that keywords in
a class statement do so that:
type("Bar", (Foo,), {}, spam='ham')
is equivalent to
class Bar(Foo, spam='ham'): pass
It's not clear to me whether this is behavior to rely on. I started using this
intuitively, but found that my type checker reasonably complained.
Looking through the commit that implemented PEP 487 (d78448e9), it seems this
may have been incidental. Additionally I haven't found mention of this in PEP
487 or the documentation and I can't seem to find any tests for it.
--
messages: 384506
nosy: esoma
priority: normal
severity: normal
status: open
title: `type` takes **kwargs for __init_subclass__
type: behavior
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue42840>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42687] tokenize module does not recognize Barry as FLUFL
Change by Erik Soma : -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue42687> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42687] tokenize module does not recognize Barry as FLUFL
Change by Erik Soma : -- keywords: +patch pull_requests: +22722 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23857 ___ Python tracker <https://bugs.python.org/issue42687> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42687] tokenize module does not recognize Barry as FLUFL
New submission from Erik Soma : '<>' is not recognized by the tokenize module as a single token, instead it is two tokens. ``` $ python -c "import tokenize; import io; import pprint; pprint.pprint(list(tokenize.tokenize(io.BytesIO(b'<>').readline)))" [TokenInfo(type=62 (ENCODING), string='utf-8', start=(0, 0), end=(0, 0), line=''), TokenInfo(type=54 (OP), string='<', start=(1, 0), end=(1, 1), line='<>'), TokenInfo(type=54 (OP), string='>', start=(1, 1), end=(1, 2), line='<>'), TokenInfo(type=4 (NEWLINE), string='', start=(1, 2), end=(1, 3), line=''), TokenInfo(type=0 (ENDMARKER), string='', start=(2, 0), end=(2, 0), line='')] ``` I would expect: ``` [TokenInfo(type=62 (ENCODING), string='utf-8', start=(0, 0), end=(0, 0), line=''), TokenInfo(type=54 (OP), string='<>', start=(1, 0), end=(1, 2), line='<>'), TokenInfo(type=4 (NEWLINE), string='', start=(1, 2), end=(1, 3), line=''), TokenInfo(type=0 (ENDMARKER), string='', start=(2, 0), end=(2, 0), line='')] ``` This is the behavior of the CPython tokenizer which the tokenizer module tries "to match the working of". -- messages: 383384 nosy: esoma priority: normal severity: normal status: open title: tokenize module does not recognize Barry as FLUFL versions: Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42687> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Library for text substitutions with calculations?
I want to do some text substitutions but a bit more advanced than what string.Template class can do. I addition to plain text substitution I would like to be able to do some calculations: $value+1 - If value is 16 this would insert 17 in the text. I would also like to subtract. $value+1w - In this case value would be a date, this would add a week to that date, similar for year, month, hours. Also subtract. The exact syntax isn't important. In other words I would like to define example1 = 12 example2 = 2020-12-15 and then some text: Hello world $example1+10 and a date $example+1w would result in Hello world 22 and a date 2020-12-22 Is there some library that can do something like this? I probably searching using the wrong keywords because I can't find anything. = jem -- https://mail.python.org/mailman/listinfo/python-list
[issue42609] Eval with too high string multiplication crashes newer Python versions
Change by Erik Lamers : -- title: Eval with two high string multiplication crashes newer Python versions -> Eval with too high string multiplication crashes newer Python versions ___ Python tracker <https://bugs.python.org/issue42609> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42609] Eval with two high string multiplication crashes newer Python versions
Change by Erik Lamers : -- versions: +Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42609> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42609] Eval with two high string multiplication crashes newer Python versions
New submission from Erik Lamers :
For Python version 3.7 and above the following statement will end up in a
segfault.
eval("1 + 100"*100)
Whereas Python versions 3.6 and below would tread this as a Recursion error.
--
components: Interpreter Core
messages: 382791
nosy: Erik-Lamers1
priority: normal
severity: normal
status: open
title: Eval with two high string multiplication crashes newer Python versions
type: crash
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue42609>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42094] isoformat() / fromisoformat() for datetime.timedelta
Erik Cederstrand added the comment: There are two conflicting interests: ISO 8601 that allows non-precise durations, and timedelta that assumes precise durations. For me, the non-precise durations only make sense in date arithmetic - to a human, it's pretty clear what adding 3 months or a year will do to the date. There may be edge cases when crossing DST, but normal arithmetic with timezone also have those cases. Regarding ISO weeks, I'm pretty sure that they are only special in regards to calculating week numbers and the weekday they start. They still have a duration of 7 days. Apart from being able to parse ISO durations coming from other systems, the non-precise durations would be useful e.g. when implementing recurring events. Calculating a series of dates for something that happens on the 12th day of every 2nd month is doable in Python, but not with the aid of timedelta. I see four options here: 1) expand timedelta to allow month and year, with the implication that e.g. total_seconds() would fail or be ambiguous for these timedeltas 2) implement only the parts of ISO 8601 that can safely be represented by the current timedelta 3) add a new relativetimedelta class that allows representing non-precise durations 4) do nothing and leave it to 3rd party packages to implement this -- ___ Python tracker <https://bugs.python.org/issue42094> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
ANN: Astropy v4.1 released
Dear colleagues, We are very happy to announce the v4.1 release of the Astropy package, a core Python package for Astronomy: http://www.astropy.org Astropy is a community-driven Python package intended to contain much of the core functionality and common tools needed for astronomy and astrophysics. It is part of the Astropy Project, which aims to foster an ecosystem of interoperable astronomy packages for Python. New and improved major functionality in this release includes: * A new SpectralCoord class for representing and transforming spectral quantities * Support for writing Dask arrays to FITS files * Added True Equator Mean Equinox (TEME) frame for satellite two-line ephemeris data * Support for in-place setting of array-valued SkyCoord and frame objects * Change in the definition of equality comparison for coordinate classes * Support use of SkyCoord in table vstack, dstack, and insert_row * Support for table cross-match join with SkyCoord or N-d columns * Support for custom attributes in Table subclasses * Added a new Time subformat unix_tai * Added support for the -TAB convention in FITS WCS * Support for replacing submodels in CompoundModel * Support for units on otherwise unitless models via the Model.coerce_units method. * Support for ASDF serialization of models In addition, hundreds of smaller improvements and fixes have been made. An overview of the changes is provided at: http://docs.astropy.org/en/stable/whatsnew/4.1.html Instructions for installing Astropy are provided on our website, and extensive documentation can be found at: http://docs.astropy.org If you usually use pip/vanilla Python, you can do: pip install astropy --upgrade If you make use of the Anaconda Python Distribution, soon you will be able update to Astropy v4.1 with: conda update astropy Or if you cannot wait for Anaconda to update their default version, you can use the astropy channel: conda update -c astropy astropy Please report any issues, or request new features via our GitHub repository: https://github.com/astropy/astropy/issues Nearly 400 developers have contributed code to Astropy so far, and you can find out more about the team behind Astropy here: https://www.astropy.org/team.html The LTS (Long Term Support) version of Astropy at the time of v4.1's release is v4.0 - this version will be maintained until next LTS release (v5.0, scheduled for Fall 2021). Additionally, note that the Astropy 4.x series only supports Python 3. Python 2 users can continue to use the 2.x series but it is no longer supported (as Python 2 itself is no longer supported). For assistance converting Python 2 code to Python 3, see the Python 3 for scientists conversion guide. If you use Astropy directly for your work, or as a dependency to another package, please remember to acknowledge it by citing the appropriate Astropy paper. For the most up-to-date suggestions, see the acknowledgement page, but as of this release the recommendation is: This research made use of Astropy, a community-developed core Python package for Astronomy (Astropy Collaboration, 2018). We hope that you enjoy using Astropy as much as we enjoyed developing it! Erik Tollerud v4.1 Release Coordinator on behalf of The Astropy Project https://www.astropy.org/announcements/release-4.1.html ___ Python-announce-list mailing list -- python-announce-list@python.org To unsubscribe send an email to python-announce-list-le...@python.org https://mail.python.org/mailman3/lists/python-announce-list.python.org/ Member address: arch...@mail-archive.com
[issue42094] isoformat() / fromisoformat() for datetime.timedelta
Erik Cederstrand added the comment: Among other things, ISO 8601 duration strings are commonly used to communicate offset values in timezone definitions. -- ___ Python tracker <https://bugs.python.org/issue42094> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42094] isoformat() / fromisoformat() for datetime.timedelta
New submission from Erik Cederstrand : Python 3.7 gained support for parsing ISO 8601 formatted time, date and datetime strings via the fromisoformat() methods. Python has seen improved support for ISO 8601 in general; ISO calendar format codes were added in Python 3.6, and fromisocalendar() was added in Python 3.8. ISO 8601 also has a standard for durations: https://en.wikipedia.org/wiki/ISO_8601#Durations For consistency with the other objects in the datetime module, I suggest adding isoformat()/fromisoformat() methods for datetime.timedelta that implement ISO 8601 durations. ISO 8601 durations support years and months that are not valid timedelta arguments because they are non-precise durations. I suggest throwing an exception if the conversion to or from timedelta cannot be done safely. https://pypi.org/project/isodate/ implements a parse_duration() method that could be used for inspiration. -- components: Library (Lib) messages: 379091 nosy: Erik Cederstrand priority: normal severity: normal status: open title: isoformat() / fromisoformat() for datetime.timedelta versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42094> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31878] Cygwin: _socket module does not compile due to missing ioctl declaration
Change by Erik Bray : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue31878> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42073] classmethod does not pass "type/owner" when invoking wrapped __get__
Change by Erik Welch : -- keywords: +patch pull_requests: +21720 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22757 ___ Python tracker <https://bugs.python.org/issue42073> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19072] classmethod doesn't honour descriptor protocol of wrapped callable
Change by Erik Welch : -- nosy: +eriknw nosy_count: 8.0 -> 9.0 pull_requests: +21721 pull_request: https://github.com/python/cpython/pull/22757 ___ Python tracker <https://bugs.python.org/issue19072> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42073] classmethod does not pass "type/owner" when invoking wrapped __get__
New submission from Erik Welch :
The following is new to Python 3.9, and I consider the implementation
incomplete. I have code that works for Python 3.8 and before, but not for
Python 3.9:
"Class methods can now wrap other :term:`descriptors ` such as
:func:`property`."
https://github.com/python/cpython/pull/8405
https://bugs.python.org/issue19072
As implemented, `classmethod` does not correctly wrap descriptors that mimic
classmethod. Previously, __get__of wrapped objects wasn't invoked by
classmethod, so it was safe to have an object with both __call__ and __get__
behave like a classmethod. Now, classmethod calling __get__ first gives
incorrect results.
Here is a minimal example:
```
from types import MethodType
class myclassmethod:
def __init__(self, func):
self.func = func
def __call__(self, cls):
return self.func(cls)
def __get__(self, instance, owner=None):
if owner is None:
owner = type(instance)
return MethodType(self, owner)
class A:
@myclassmethod
def f1(cls):
return cls
@classmethod
@myclassmethod
def f2(cls):
return cls
assert A.f1() is A
assert A.f2() is A # <-- fails in 3.9, works in 3.8 and before
```
This pattern would typically be used to do something extra in __call__.
For the sake of discussion, let's call the two arguments to __get__ "instance"
and "owner". Typically, "instance" is an instance of "owner", or,
equivalently, "owner" is the type of "instance". If "owner" is None, it is
generally assumed to be the type of "instance".
In bpo19072 (and gh8405), classmethod was changed to call `obj.__get__(owner)`
if the wrapped object "obj" has __get__. Notice that only the "instance"
argument is provided. Moreover, the type `owner` is passed as the "instance"
argument. This means that the "owner" argument (which is None) will be assumed
to be the type of the "instance" argument, which is the type of the `owner`
type. This is wrong. The "owner" argument should be `owner`.
I believe it would be better for classmethod to call `obj.__get__(owner,
owner)` if "obj" has __get__.
This is kind of difficult to explain. I will make a PR with more informative
tests shortly. Here is the simple diff to make the above example pass:
```
diff --git a/Objects/funcobject.c b/Objects/funcobject.c
index bd24f67b97..74f9167566 100644
--- a/Objects/funcobject.c
+++ b/Objects/funcobject.c
@@ -739,7 +739,7 @@ cm_descr_get(PyObject *self, PyObject *obj, PyObject *type)
type = (PyObject *)(Py_TYPE(obj));
if (Py_TYPE(cm->cm_callable)->tp_descr_get != NULL) {
return Py_TYPE(cm->cm_callable)->tp_descr_get(cm->cm_callable, type,
- NULL);
+ type);
}
return PyMethod_New(cm->cm_callable, type);
}
```
Since I consider the new behavior to have introduced a regression, I think this
change should be applied to both 3.9 and 3.10.
Cheers!
--
components: Interpreter Core
messages: 378893
nosy: berker.peksag, eriknw, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: classmethod does not pass "type/owner" when invoking wrapped __get__
type: behavior
versions: Python 3.10, Python 3.9
___
Python tracker
<https://bugs.python.org/issue42073>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39671] Mention in docs that asyncio.FIRST_COMPLETED does not guarantee the completion of no more than one task
Change by Erik Bray : -- keywords: +patch nosy: +erik.bray nosy_count: 4.0 -> 5.0 pull_requests: +21125 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21918 ___ Python tracker <https://bugs.python.org/issue39671> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41599] get/set_payload deprecated, but get_set_content do not provide full replacement functionality
New submission from Erik Quaeghebeur : >From Python 3.6 onwards, get/set_payload methods are deprecated on the basic >email message class, email.message.EmailMessage (changed from >email.message.Message). The get/set_content methods are suggested instead. >However, with get/set_payload one can ‘transplant’ whole MIME subtrees, while >get/set_content cannot deal with multipart parts. I would like to suggest to not remove get/set_payload until its functionality is present in other methods. Perhaps they should even be un-deprecated. -- components: email messages: 375696 nosy: barry, equaeghe, r.david.murray priority: normal severity: normal status: open title: get/set_payload deprecated, but get_set_content do not provide full replacement functionality type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue41599> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41585] policy.max_line_length is incorrectly assumed to never be None
Erik Quaeghebeur added the comment: The script that triggered the issue can be found at https://github.com/equaeghe/mailfilters/blob/master/html2alternative.py You'll have to remove ", cte='8bit'" on line 68 to expose the bug (that was added as a workaround for this bug). I was consistently able to trigger the bug when applying it to a mail with a multipart/alternative with text and html parts already present. It should replace that html part by a (nested) multipart/alternative part, but it crashes unless you keep the workaround. -- ___ Python tracker <https://bugs.python.org/issue41585> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41585] policy.max_line_length is incorrectly assumed to never be None
New submission from Erik Quaeghebeur :
I got the following error (Python 3.7.8):
Traceback (most recent call last):
File "/home/equaeghe/.local/bin/html2alternative.py", line 68, in
replaceable.add_alternative(plain)
File "/usr/lib/python3.7/email/message.py", line 1153, in add_alternative
self._add_multipart('alternative', *args, **kw)
File "/usr/lib/python3.7/email/message.py", line 1144, in _add_multipart
part.set_content(*args, **kw)
File "/usr/lib/python3.7/email/message.py", line 1171, in set_content
super().set_content(*args, **kw)
File "/usr/lib/python3.7/email/message.py", line 1101, in set_content
content_manager.set_content(self, *args, **kw)
File "/usr/lib/python3.7/email/contentmanager.py", line 37, in set_content
handler(msg, obj, *args, **kw)
File "/usr/lib/python3.7/email/contentmanager.py", line 185, in
set_text_content
cte, payload = _encode_text(string, charset, cte, msg.policy)
File "/usr/lib/python3.7/email/contentmanager.py", line 154, in _encode_text
max(len(x) for x in lines) <= policy.max_line_length):
TypeError: '<=' not supported between instances of 'int' and 'NoneType'
This is triggered because it is incorrectly assumed that policy.max_line_length
cannot be None. This issue is still present in current master:
https://github.com/python/cpython/blob/c3dd7e45cc5d36bbe2295c2840faabb5c75d83e4/Lib/email/contentmanager.py#L149
--
components: email
messages: 375625
nosy: barry, equaeghe, r.david.murray
priority: normal
severity: normal
status: open
title: policy.max_line_length is incorrectly assumed to never be None
type: behavior
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue41585>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41553] encoded-word abused for header line folding causes RFC 2047 violation
Erik Quaeghebeur added the comment: We also shouldn't forget Resent-Message-Id. So in the header registry <https://github.com/python/cpython/blob/2a9f709ba23c8f6aa2bed821aacc4e7baecde383/Lib/email/headerregistry.py#L562>, 'message-id': MessageIDHeader, should be replaced by 'message-id': UniqueSingleMessageIDHeader, 'resent-message-id': SingleMessageIDHeader, 'in-reply-to': UniqueMessageIDHeader, 'references': UniqueMessageIDHeader, with Unique/Single used as for the other Headers. -- ___ Python tracker <https://bugs.python.org/issue41553> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41553] encoded-word abused for header line folding causes RFC 2047 violation
Erik Quaeghebeur added the comment: Note that In-Reply-To can also contain multiple message ids: <https://tools.ietf.org/html/rfc5322#section-3.6.4>. It should be treated the same as References. When you say that a message_id parser exists, then that means it is not applied to the Message-Id header by default yet, because my example shows that the Message-Id header gets mangled. Applying encoded-word encoding to (unknown) unstructured fields may break workflows. These are often X-… headers and one cannot assume that the application generating and consuming them apply decoding. (Just as with message ids.) The most reliable approach would be to not encode them, but apply white-space folding and then leave them to go beyond the limit set (78 characters, typically). As headers, the increased line length is not that big of a problem. (The 78 limit is for visual reasons.) In case the lines still go beyond 998 characters, an error should be raised, as that is an RFC violation. Tools generating such headers are severely broken and should not get a free pass. Users could get the option to allow such lines and take their chances when the message is submitted and transported. -- ___ Python tracker <https://bugs.python.org/issue41553> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41553] encoded-word abused for header line folding causes RFC 2047 violation
New submission from Erik Quaeghebeur :
Encoded-word is apparently used for header line folding sometimes. This appears
to me as an abuse of this encoding technique. However, that is not the main
issue: it also causes a violation of RFC 2074, as it also encodes message id's:
https://tools.ietf.org/html/rfc2047#section-5 says “An
'encoded-word' MUST NOT appear in any portion of an
'addr-spec'.” and
https://tools.ietf.org/html/rfc5322#section-3.6.4 says
“The message identifier (msg-id) syntax is a limited
version of the addr-spec construct enclosed in the angle
bracket characters, "<" and ">".”
This causes actual problems. Namely, email clients cannot parse the message id
and so have trouble with generation of In-Reply-To and References headers or
problems with thread reconstruction using these headers containing encoded-word
versions of message ids.
Minimal example:
---
>>> import email
>>> import email.policy
>>> msg = email.message_from_string("""From: t...@example.com
To: t...@example.org
Subject: Test
Date: Mon, 10 Aug 2020 22:52:53 +
Message-ID:
X-Some-Blobby-Custom-Header:
DIZEglcw6TIh1uC2UrnNjWYqe8l/bYo0oxKG7mBX38s1urzvCwQD30Q07DDJFgTVZWKbThu6hVjR53MTYAHYClHPt8UvyFPkAUIc8Ps1/R+HuSQ8gbR1R03sKoFAgPZKO+FKJ9bNbBb60THl81zSCsZiALwi4LLOqnf9ZIB111G4/shFuWxRlPcsPJt72sn+tTHZqK9fRAyoK1OZCZMJmjQGysovicz1Xc6nOXHMQr2+suRwOJwSUqvsfkj8EEtzJGj7ICQ2GbgBaOjcof1AML4RCFy/vD5bG0Y8HQ2KET3SraTki4dPo+xMYSZVFEy/va4rYeynOXPfxXfHSyIFwB6gnH74Ws/XPk8ZxhAQ2wSy7Hvgg3tZ7HOmlLWg4A/vUGN+8RJlgn+hHtuCXnglv+fIKEhW36wcFotngSrcXULbTlqdE5zjuV5O7wNfgIShZnNhnPdLipslmZJGaa6RQpIonZbwUWCM8g9DZmSwo8g0On0l20IVS9s6bUCddwRZ5erHx4eUZ4DGh4YyR2fgm0WsNVW8pVsAdFMClfAJYqyPEqrDN91djfPYRZPMvzYWTAm8MAip6vDa1ZvzywDpGJYD3VwapLfgFy+AR0S/q/V1HHRmSXx1oNLEedhAt0OkIxWxO8FvqNeEfMLVhxTk1g==
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="utf-8"
BODY
""")
>>> print(msg.as_bytes(policy=email.policy.SMTPUTF8).decode())
From: t...@example.com
To: t...@example.org
Subject: Test
Date: Mon, 10 Aug 2020 22:52:53 +
Message-ID: =?utf-8?q?=3CVI1PR09MB41911D8371E899C1FE78EE48FA440=40abcdefghij?=
=?utf-8?q?klm=2Enmopqrst=2Euvwx=2Eexample=2Ecom=3E?=
X-Some-Blobby-Custom-Header: =?utf-8?q?DIZEglcw6TIh1uC2UrnNjWYqe8l/bYo0oxKG7?=
=?utf-8?q?mBX38s1urzvCwQD30Q07DDJFgTVZWKbThu6hVjR53MTYAHYClHPt8UvyFPkAUIc8P?=
=?utf-8?q?s1/R+HuSQ8gbR1R03sKoFAgPZKO+FKJ9bNbBb60THl81zSCsZiALwi4LLOqnf9ZIB?=
=?utf-8?q?111G4/shFuWxRlPcsPJt72sn+tTHZqK9fRAyoK1OZCZMJmjQGysovicz1Xc6nOXHM?=
=?utf-8?q?Qr2+suRwOJwSUqvsfkj8EEtzJGj7ICQ2GbgBaOjcof1AML4RCFy/vD5bG0Y8HQ2KE?=
=?utf-8?q?T3SraTki4dPo+xMYSZVFEy/va4rYeynOXPfxXfHSyIFwB6gnH74Ws/XPk8ZxhAQ2w?=
=?utf-8?q?Sy7Hvgg3tZ7HOmlLWg4A/vUGN+8RJlgn+hHtuCXnglv+fIKEhW36wcFotngSrcXUL?=
=?utf-8?q?bTlqdE5zjuV5O7wNfgIShZnNhnPdLipslmZJGaa6RQpIonZbwUWCM8g9DZmSwo8g0?=
=?utf-8?q?On0l20IVS9s6bUCddwRZ5erHx4eUZ4DGh4YyR2fgm0WsNVW8pVsAdFMClfAJYqyPE?=
=?utf-8?q?qrDN91djfPYRZPMvzYWTAm8MAip6vDa1ZvzywDpGJYD3VwapLfgFy+AR0S/q/V1HH?=
=?utf-8?q?RmSXx1oNLEedhAt0OkIxWxO8FvqNeEfMLVhxTk1g=3D=3D?=
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="utf-8"
BODY
---
--
components: email
messages: 375397
nosy: barry, equaeghe, r.david.murray
priority: normal
severity: normal
status: open
title: encoded-word abused for header line folding causes RFC 2047 violation
type: behavior
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue41553>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18876] Problems with files opened in append mode with io module
Erik Bray added the comment: Indeed, this can be closed. -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue18876> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20082] Misbehavior of BufferedRandom.write with raw file in append mode
Change by Erik Bray : -- pull_requests: +20873 pull_request: https://github.com/python/cpython/pull/21729 ___ Python tracker <https://bugs.python.org/issue20082> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35003] Provide an option to venv to put files in a bin/ directory on Windows
Erik Aronesty added the comment: > The Scripts/bin thing is not specific to venv - for whatever reason, the > original Windows implementation chose to use "Scripts" rather than "bin" That's irrelevant to the PR, which solves the problem in a compatible way. There's no compatibility issues if a link is made to the activate script, rather than moving the directory at all. > My guess is you would need to propose a PEP to move *everything* over from > "Scripts" to "bin" in the Windows Python world Certainly not. That would break everything and would be a bad idea. > This issue was already rejected before you added your PR so I'm not sure why > you went to the trouble of creating a PR. Because the issue was rejected due to come conflating logic and confusion as to what the underlying problem and issue is. The venv system produces files specifically for activation on Windows which must and should reside in the Scripts directory. The venv system also produces files for activation in a bash (or similar) shell. This *should* reside in the bin directory (there is no o/s dependency here), and it should *also* reside in the Scripts directory ... for compatibility. Expressed that way, it's clear what the solution is. Hence the PR. -- ___ Python tracker <https://bugs.python.org/issue35003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35003] Provide an option to venv to put files in a bin/ directory on Windows
Erik Aronesty added the comment: See https://github.com/python/cpython/pull/18083 for an example of a 'simple copy' for shell script compatibility ... rather than trying to make Scripts move around (which it can't trivially). -- ___ Python tracker <https://bugs.python.org/issue35003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35003] Provide an option to venv to put files in a bin/ directory on Windows
Change by Erik Aronesty : -- pull_requests: +17474 pull_request: https://github.com/python/cpython/pull/18083 ___ Python tracker <https://bugs.python.org/issue35003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35003] Provide an option to venv to put files in a bin/ directory on Windows
Erik Aronesty added the comment: the single Scripts/activate tool should be simply copied to bin/activate ... this is what you have to do to write a bash script for python now: source bin/activate || source Scripts/activate we should not assume that all windows users use things like CMD and PowerShell, and instead just make support for "shell activation" be cross-platform -- nosy: +earonesty ___ Python tracker <https://bugs.python.org/issue35003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
ANN: Astropy v4.0 released
Dear colleagues, We are very happy to announce the v4.0 release of the Astropy package, a core Python package for Astronomy: http://www.astropy.org Astropy is a community-driven Python package intended to contain much of the core functionality and common tools needed for astronomy and astrophysics. It is part of the Astropy Project, which aims to foster an ecosystem of interoperable astronomy packages for Python. New and improved major functionality in this release includes: * Support for Planck 2018 Cosmological Parameters * Improved Consistency of Physical Constants and Units * Scientific enhancements to the Galactocentric Frame * New ymdhms Time Format * New Context Manager for plotting time values * Dynamic and improved handling of leap second * Major Improvements in Compatibility of Quantity Objects with NumPy Functions * Multiple interface improvements to WCSAxes * Fitting of WCS to Pairs of Pixel/World Coordinates * Support for WCS Transformations between Pixel and Time Values * Improvements to Folding for Time Series * New Table Methods and significant performance improvements for Tables * Improved downloading and caching of remote files In addition, hundreds of smaller improvements and fixes have been made. An overview of the changes is provided at: http://docs.astropy.org/en/stable/whatsnew/4.0.html The Astropy v4.0.x series now replaces v2.0.x as the long term support release, and will be supported until the end of 2021. Also note that the Astropy 4.x series only supports Python 3. Python 2 users can continue to use the 2.x series but as of now it is no longer supported (as Python 2 itself is no longer supported). For assistance converting Python 2 code to Python 3, see the Python 3 for scientists conversion guide. Instructions for installing Astropy are provided on our website, and extensive documentation can be found at: http://docs.astropy.org If you make use of the Anaconda Python Distribution, you can update to Astropy v4.0 with: conda update astropy Whereas if you usually use pip, you can do: pip install astropy --upgrade Please report any issues, or request new features via our GitHub repository: https://github.com/astropy/astropy/issues Over 350 developers have contributed code to Astropy so far, and you can find out more about the team behind Astropy here: http://www.astropy.org/team.html If you use Astropy directly for your work, or as a dependency to another package, please remember to acknowledgment it by citing the appropriate Astropy paper. For the most up-to-date suggestions, see the acknowledgement page, but as of this release the recommendation is: This research made use of Astropy, a community-developed core Python package for Astronomy (Astropy Collaboration, 2018). Special thanks to the coordinator for this release: Brigitta Sipocz. We hope that you enjoy using Astropy as much as we enjoyed developing it! Erik Tollerud, Tom Robitaille, Kelle Cruz, and Tom Aldcroft on behalf of The Astropy Collaboration https://www.astropy.org/announcements/release-4.0.html -- Python-announce-list mailing list -- python-announce-list@python.org To unsubscribe send an email to python-announce-list-le...@python.org https://mail.python.org/mailman3/lists/python-announce-list.python.org/ Support the Python Software Foundation: http://www.python.org/psf/donations/
[issue38964] Output of syntax error in f-string contains wrong filename
Erik Cederstrand added the comment: Additionally, the output in the 2nd example does not contain the helpful text printing the context and location of the code containing the syntax error. -- ___ Python tracker <https://bugs.python.org/issue38964> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38964] Output of syntax error in f-string contains wrong filename
New submission from Erik Cederstrand :
When I have a normal syntax error in a file, Python reports the filename in the
exception output:
$ cat syntax_error.py
0x=5
$ python3.8 syntax_error.py
File "syntax_error.py", line 1
0x=5
^
SyntaxError: invalid hexadecimal literal
But if the syntax error is inside an f-string, Python reports 'File
""' instead of the actual filename in the exception output.
$ cat syntax_error_in_fstring.py
f'This is a syntax error: {0x=5}'
$ python3.8 syntax_error_in_fstring.py
File "", line 1
SyntaxError: invalid hexadecimal literal
--
messages: 35
nosy: Erik Cederstrand
priority: normal
severity: normal
status: open
title: Output of syntax error in f-string contains wrong filename
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue38964>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22107] tempfile module misinterprets access denied error on Windows
Erik Aronesty added the comment: This is the fist of what I'm using: https://gist.github.com/earonesty/a052ce176e99d5a659472d0dab6ea361 Seems OK for my use cases. There's probably issues with relying on __del__ this way. But it solves the Windows close/reopen problem, too. -- ___ Python tracker <https://bugs.python.org/issue22107> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: nonlocal fails ?
On 14 Nov 2019, at 15:15, R.Wieser wrote: Too bad though, it means that procedures that want to share/use its callers variables using nonlocal can never be called from main. And that a caller of a procedure using nonlocal cannot have the variable declared as global (just tested it). So what you want to do is dynamic scope? https://www.geeksforgeeks.org/static-and-dynamic-scoping/ = jem -- https://mail.python.org/mailman/listinfo/python-list
Re: nonlocal fails ?
On 14 Nov 2019, at 14:06, R.Wieser wrote: I've also tried moving "MyVar = 7" to the first line, but that doesn't change anything. Using "global MyVar" works.. Try def outer(): MyVar = 10 def Proc1(): nonlocal MyVar MyVar = 5 Proc1() MyVar = 7 outer() print(MyVar) From the documentation The nonlocal statement causes the listed identifiers to refer to previously bound variables in the nearest **enclosing scope excluding globals**. This is important because the default behavior for binding is to search the local namespace first. The statement allows encapsulated code to rebind variables outside of the local scope besides the global (module) scope. Names listed in a nonlocal statement, unlike those listed in a global statement, must refer to pre-existing bindings in an enclosing scope (the scope in which a new binding should be created cannot be determined unambiguously). Names listed in a nonlocal statement must not collide with pre-existing bindings in the local scope. -- https://mail.python.org/mailman/listinfo/python-list
[issue38736] argparse: wrong type from get_default when type is set
Erik Ahlén added the comment:
So, not a bug since you can just do `default = Path('file.txt')`?
--
___
Python tracker
<https://bugs.python.org/issue38736>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38736] argparse: wrong type from get_default when type is set
New submission from Erik Ahlén : The type of the object returned by get_default isn't converted to the specified type supplied to add_argument. I would expect the type to be the same. -- components: Library (Lib) files: test.py messages: 356194 nosy: Erik Ahlén priority: normal severity: normal status: open title: argparse: wrong type from get_default when type is set type: enhancement versions: Python 3.7 Added file: https://bugs.python.org/file48700/test.py ___ Python tracker <https://bugs.python.org/issue38736> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30548] typo in documentation for create_autospec
Erik Byström added the comment: Yes, you're right. I do think the docs are a bit misleading. Maybe something like this would make it more clear? "If a class is used as a spec then the returned object will be a mock of that class. When the constructor of the returned mock class is invoked an instance object is returned that has the same spec as a normal instance object would have. By passing instance=True you can directly create a mock instance of the class." If not, feel free to close this issue. -- ___ Python tracker <https://bugs.python.org/issue30548> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22107] tempfile module misinterprets access denied error on Windows
Erik Aronesty added the comment: i would like to point out that the primary reason any of this nonsense exists is because of short filename restrictions. i've replaces nearly all of my temp file creation code in all of my project to `return os.urandom(32).hex()` ... which is reliable secure, fast, and doesn't require any fileops sure, it doesn't work on 8.3 limited systems, but maybe the NamedTemp code should check that *first* and *if* it's OK to use long names... just use them, otherwise revert to existing behavior -- ___ Python tracker <https://bugs.python.org/issue22107> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37801] Compilation on MINGW64 fails (CODESET,wcstok,...)
Erik Janssens added the comment: fyi 1 : this issue pops up in multiple places, cfr : * bpo-35890 * bpo-20596 the selection of the wcstok function is based on MS_WINDOWS being defined, rather than eg. an autoconf check on which function is available. fyi 2 : I've been able to cross compile 3.8 with mingw64 (gcc 7.3), but with a custom meson script instead of autoconf -- nosy: +erikjanss ___ Python tracker <https://bugs.python.org/issue37801> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: bool(Enum) should raise ValueError
class Status: valid = 1 invalid = 2 unknown = 3 On Fri, Jul 26, 2019, 3:37 PM Chris Angelico wrote: > On Sat, Jul 27, 2019 at 5:16 AM Erik Aronesty wrote: > > > > I just spend a while tracking down and killing all "if Enum" and "if not > > Enum" bugs in my code. I was frankly shocked that this didn't raise a > > ValueError to begin with. > > > > Apparently all enums are true/false depending on whether the underlying > > value is truthy or falsy. > > > > Which breaks the abstraction Enum's are trying to achieve because now the > > user of an Enum has to know "stuff" about the underlying value and how it > > behaves. > > If you want to abstract away the underlying value, just don't have one? > > >>> from enum import Enum, auto > >>> class Color(Enum): > ... red = auto() > ... green = auto() > ... blue = auto() > ... > >>> bool(Color.red) > True > >>> bool(Color.green) > True > >>> bool(Color.blue) > True > > They happen to have the values 1, 2, and 3, but that doesn't matter. > > When an enum has to correspond to a real underlying value, it behaves > as similarly to that value as possible: > > >>> http.HTTPStatus.METHOD_NOT_ALLOWED == 405 > True > > Thus it should also inherit its truthiness from that value. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
bool(Enum) should raise ValueError
I just spend a while tracking down and killing all "if Enum" and "if not Enum" bugs in my code. I was frankly shocked that this didn't raise a ValueError to begin with. Apparently all enums are true/false depending on whether the underlying value is truthy or falsy. Which breaks the abstraction Enum's are trying to achieve because now the user of an Enum has to know "stuff" about the underlying value and how it behaves. -- https://mail.python.org/mailman/listinfo/python-list
[issue22107] tempfile module misinterprets access denied error on Windows
Erik Aronesty added the comment:
Series of operations needed to answer the questions os.access is not answering
on windows:
bool CanAccessFolder( LPCTSTR folderName, DWORD genericAccessRights )
{
bool bRet = false;
DWORD length = 0;
if (!::GetFileSecurity( folderName, OWNER_SECURITY_INFORMATION |
GROUP_SECURITY_INFORMATION
| DACL_SECURITY_INFORMATION, NULL, NULL, ) &&
ERROR_INSUFFICIENT_BUFFER == ::GetLastError()) {
PSECURITY_DESCRIPTOR security = static_cast< PSECURITY_DESCRIPTOR >(
::malloc( length ) );
if (security && ::GetFileSecurity( folderName,
OWNER_SECURITY_INFORMATION | GROUP_SECURITY_INFORMATION
| DACL_SECURITY_INFORMATION, security, length,
)) {
HANDLE hToken = NULL;
if (::OpenProcessToken( ::GetCurrentProcess(), TOKEN_IMPERSONATE |
TOKEN_QUERY |
TOKEN_DUPLICATE | STANDARD_RIGHTS_READ, )) {
HANDLE hImpersonatedToken = NULL;
if (::DuplicateToken( hToken, SecurityImpersonation,
)) {
GENERIC_MAPPING mapping = { 0x };
PRIVILEGE_SET privileges = { 0 };
DWORD grantedAccess = 0, privilegesLength = sizeof(
privileges );
BOOL result = FALSE;
mapping.GenericRead = FILE_GENERIC_READ;
mapping.GenericWrite = FILE_GENERIC_WRITE;
mapping.GenericExecute = FILE_GENERIC_EXECUTE;
mapping.GenericAll = FILE_ALL_ACCESS;
::MapGenericMask( , );
if (::AccessCheck( security, hImpersonatedToken,
genericAccessRights,
, , ,
, )) {
bRet = (result == TRUE);
}
::CloseHandle( hImpersonatedToken );
}
::CloseHandle( hToken );
}
::free( security );
}
}
return bRet;
}
--
nosy: +earonesty
___
Python tracker
<https://bugs.python.org/issue22107>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37477] NamedTemporaryFile can hang on windows
Erik Aronesty added the comment: yes, duplicate of https://bugs.python.org/issue22107 ... tried looking first, sry. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37477> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37477] NamedTemporaryFile can hang on windows
Change by Erik Aronesty : -- type: -> crash ___ Python tracker <https://bugs.python.org/issue37477> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37477] NamedTemporaryFile can hang on windows
New submission from Erik Aronesty : Depending on the user's permissions, this code can hang, instead of raising an exception: from tempfile import NamedTemporaryFile NamedTemporaryFile(dir="/") The problamatic code is in tempfile.py: When encountering a "[Errno 13] Permission denied: '/tmpmcupmo_g'", the current code uses _os.access(dir, _os.W_OK) in two places to check if access is allowed to write to the directory. On windows, _os.access does not check if the user has permission to write to the folder, it only checks if the folder is read-only (and it doesn't even do a good job at that). So the temp file creator loops for a rather long time, and consumes a massive amount of system resources, because os.TMP_MAX on modern windows versions is 2147483647. This article explains how to check if a directory can-write without trying to write to it: http://blog.aaronballman.com/2011/08/how-to-check-access-rights/ Alternatively, a more careful check of the winerror return value from the open call *might* be sufficient. -- messages: 347073 nosy: earonesty priority: normal severity: normal status: open title: NamedTemporaryFile can hang on windows versions: Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue37477> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
ANN: Astropy v3.2 released
Dear colleagues, We are very happy to announce the v3.2 release of the Astropy package, a core Python package for Astronomy: http://www.astropy.org Astropy is a community-driven Python package intended to contain much of the core functionality and common tools needed for astronomy and astrophysics. It is part of the Astropy Project, which aims to foster an ecosystem of interoperable astronomy packages for Python. New and improved major functionality in this release includes: * New Sub-package for Time Series * New SI/CODATA 2018 Constants * Additions and changes to Ecliptic Transformations * Table performance improvements and change in metadata handling * Table I/O integration of pandas I/O functions for ASCII tables * Improved help on Table read() and write() methods In addition, hundreds of smaller improvements and fixes have been made. An overview of the changes is provided at: http://docs.astropy.org/en/stable/whatsnew/3.2.html Note that the Astropy 3.x series only supports Python 3. Python 2 users can continue to use the 2.x (LTS) series (but without new features). Instructions for installing Astropy are provided on our website, and extensive documentation can be found at: http://docs.astropy.org If you make use of the Anaconda Python Distribution, you can update to Astropy v3.2 with: conda update astropy Whereas if you usually use pip, you can do: pip install astropy --upgrade Please report any issues, or request new features via our GitHub repository: https://github.com/astropy/astropy/issues Over 300 developers have contributed code to Astropy so far, and you can find out more about the team behind Astropy here: http://www.astropy.org/team.html As a reminder, Astropy v2.0 (our long term support release) will continue to be supported with bug fixes (but no new features) until the end of 2019, so if you need to use Astropy in a very stable environment, you may want to consider staying on the v2.0.x set of releases (for which we have recently released v2.0.13). If you use Astropy directly for your work, or as a dependency to another package, please remember to acknowledgment it by citing the appropriate Astropy paper. For the most up-to-date suggestions, see the acknowledgement page, but as of this release the recommendation is: This research made use of Astropy, a community-developed core Python package for Astronomy (Astropy Collaboration, 2018). where (Astropy Collaboration, 2018) is a reference to https://doi.org/10.3847/1538-3881/aabc4f Special thanks to the coordinator for this release: Brigitta Sipocz. We hope that you enjoy using Astropy as much as we enjoyed developing it! Erik Tollerud, Tom Robitaille, Kelle Cruz, and Tom Aldcroft on behalf of The Astropy Collaboration -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()
Erik Bray added the comment:
FWIW (unsurprisingly) the new test added here is broken on Cygwin, whose libc's
(newlib) behavior in this undefined case. So I get:
>>> from datetime import date
>>> t = date(2005, 1, 1)
>>> t.strftime("%Y") # ok
'2005'
>>> t.strftime("%%") # ok
'%'
>>> t.strftime("%") # undefined behavior
''
>>> t.strftime("%Y %") # undefined behavior; discards the whole format string
''
>>> t.strftime("%Y%Q") # undefined format; discards the whole format string
''
This behavior is user-hostile I think; it should raise a ValueError instead of
just return an empty string. I would have suggested the same for the trailing
'%' case, though I understand the goal of this issue was consistency.
Also worth noting that both before and after this patch:
>>> import time
>>> time.strftime('%')
''
So the question of consistency between the interfaces, which was the main point
of this issue, was already resolved in this case, and the *inconsistency*
observed was dependent on system-dependent behavior.
For now I might propose doing away with this test in its current form, and just
test
assert t.strftime('%') == time.strftime('%')
or something like that.
I agree with Victor that trying to make the strftime experience consistent
across system-dependent quirks is a worthy goal, but that goes deeper than just
this trailing '%' case.
--
nosy: +erik.bray
___
Python tracker
<https://bugs.python.org/issue35066>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28459] _pyio module broken on Cygwin / setmode not usable
Change by Erik Bray : -- pull_requests: +13877 pull_request: https://github.com/python/cpython/pull/14013 ___ Python tracker <https://bugs.python.org/issue28459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9665] Buid issues on Cygwin - _curses, _curses_panel, and _io
Erik Bray added the comment: I think this issue can probably be closed. It refers to a very old version of Cygwin as well as old versions of Python. I don't have any problem building the _curses or _io modules on recent versions of Cygwin (>=2.9) and with current cpython master (3.9.0a0). -- nosy: +erik.bray ___ Python tracker <https://bugs.python.org/issue9665> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32628] Add configurable DirectoryIndex to http.server
Erik Paulson added the comment: I think my use case was Sharepoint and static site generators - Sharepoint can serve a tree of .aspx files as raw HTML, but maddeningly not .html files. The site generator we used spit out a fairly complicated site where the internal links point at directories counting on the fact that it is served correctly by the directoryindex handler. The site generator spits out .aspx but http.server can't serve them. A directory full of .xhtml files would have similar problems, which certainly still exist in the wild. The example in the test was named index.test because it's creating files on the disk in the test, shared by other parts of the test, and I wanted to be clear about what it was. It was not intended to be an example use case. -- ___ Python tracker <https://bugs.python.org/issue32628> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21536] extension built with a shared python cannot be loaded with a static python
Erik Bray added the comment: Thanks everyone. And FWIW I agree the original change is positive overall, if a bit presumptuous about different linkers' behaviors :) -- ___ Python tracker <https://bugs.python.org/issue21536> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21536] extension built with a shared python cannot be loaded with a static python
Change by Erik Bray : -- pull_requests: +13463 ___ Python tracker <https://bugs.python.org/issue21536> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21536] extension built with a shared python cannot be loaded with a static python
Change by Erik Bray : -- pull_requests: +13461 ___ Python tracker <https://bugs.python.org/issue21536> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21536] extension built with a shared python cannot be loaded with a static python
Erik Bray added the comment: I vaguely recall seeing some discussion about this on python-dev or elsewhere and wish I had chimed in sooner, as I didn't realize action was going to be taken on this so soon. This completely breaks building extension modules on Windows-based platforms like Cygwin and MinGW, where it is necessary when building even shared libraries for all global symbols to resolvable at link time. I'm not actually sure this use case can even be achieved on these platforms. I tried several hacks but nothing works. I'll open a follow-up issue... -- nosy: +erik.bray ___ Python tracker <https://bugs.python.org/issue21536> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36965] use of STATUS_CONTROL_C_EXIT in Modules/main.c breaks compilation with non MSC compilers
Change by Erik Janssens : -- pull_requests: +13401 ___ Python tracker <https://bugs.python.org/issue36965> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
