[issue39854] f-strings with format specifiers have wrong col_offset
Stéphane Blondon added the comment: I can reproduce it on python 3.8. I can't reproduce it on python 3.9 or 3.10. -- nosy: +sblondon ___ Python tracker <https://bugs.python.org/issue39854> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43196] logging.config.dictConfig shuts down socket for existing SysLogHandlers
Stéphane Blondon added the comment: I can reproduce the error on Debian/testing with: - Python 3.9.9 - Python 3.10.0 -- nosy: +sblondon status: pending -> open ___ Python tracker <https://bugs.python.org/issue43196> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42914] pprint numbers with underscore
Change by Stéphane Blondon : -- keywords: +patch pull_requests: +23624 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24864 ___ Python tracker <https://bugs.python.org/issue42914> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42914] pprint numbers with underscore
Stéphane Blondon added the comment:
Thank you Felipe for the news! :)
I have committed a PR about this issue.
Two remarks:
- I changed the proposed implementation from 'format(integer, '_d')' to
'{:_d}.format(integer)' because the first way raised an exception. (The
`format` function was not defined.)
- I thought about adding the same behavior for float too but I didn't add it
because the '_f' type uses a precision of 6 digits after the decimal point for
float. So it's possible some precision would be lost with the pprint() call. It
could mislead users more than helping them with the readability of the '_'. A
precision value can be added but I'm not sure it's a good idea. based on [1]
As requested, there is a new parameter to disable this new behavior
('underscore_numbers').
1:
https://docs.python.org/3/library/string.html#format-specification-mini-language
--
___
Python tracker
<https://bugs.python.org/issue42914>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42914] pprint numbers with underscore
Stéphane Blondon added the comment: I changed the default to be backward compatible (so underscore_numbers=False). I think it would be better with underscore_numbers enabled by default but I understand the need for stability. Perhaps such break could be done in the future (in version 3.12 or v.4)? -- ___ Python tracker <https://bugs.python.org/issue42914> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42589] doc: Wrong "from" keyword link in Exceptions doc
Change by Stéphane Blondon : -- pull_requests: +24445 stage: backport needed -> patch review pull_request: https://github.com/python/cpython/pull/25755 ___ Python tracker <https://bugs.python.org/issue42589> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41411] Improve and consolidate f-strings docs
Stéphane Blondon added the comment: It seems ezio-melotti hesitates to continue the modifications in the PR https://github.com/python/cpython/pull/21552#pullrequestreview-458400056 IMO, the PR improves enough the documentation, so it would be nice to merge it, even without the other changes. I'd like to help but I don't know how I could do that. @ezio.melotti, @amaajemyfren Are you still interested by this issue? How can I help you? -- nosy: +sblondon ___ Python tracker <https://bugs.python.org/issue41411> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15373] copy.copy() does not properly copy os.environment
Stéphane Blondon added the comment:
I think an asdict() method is not necessary. Instanciating a dict from
os.environ is enough:
>>> import os
>>> os.environ
environ({'SHELL': '/bin/bash', ...})
>>> dict(os.environ)
{'SHELL': '/bin/bash', ...})
With 'dict()', it's obvious there is no side effect.
I think os._Environ should not be pickable too because there is an ambiguity
too when it will be unpicked: should we set the unpickled data to a basic dict
(or another _Environ instance) or to the environment variables?
It seems there are more maintainers in favour of the removal. Removing the copy
is a breaking change so it should be done on several releases.
Are you interested by a PR which adds DeprecationWarning when
copy.copy(os.environ) or os.environ.copy() are called? It seems to be the first
step to implement.
--
nosy: +sblondon
versions: +Python 3.11 -Python 3.10
___
Python tracker
<https://bugs.python.org/issue15373>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45095] Easier loggers traversal tree with a logger.getChildren method
New submission from Stéphane Blondon :
Currently, logging.root.manager.loggerDict is usable to do a homemade traversal
of the loggers tree. However, it's not a public interface. Adding a
'logger.getChildren()' method would help to implement the traversal. The method
would return a set of loggers.
Usage example:
>>> import logging
>>> logging.basicConfig(level=logging.CRITICAL)
>>> root_logger = logging.getLogger()
>>> root_logger.getChildren()
set()
>>> a_logger = logging.getLogger("a")
>>> root_logger.getChildren()
{}
>>> logging.getLogger('a.b').setLevel(logging.DEBUG)
>>> _ = logging.getLogger('a.c')
>>> a_logger.getChildren()
{, }
With such method, traverse the tree will be obvious to write with a recursive
function.
Use cases:
- to check all the loggers are setted up correctly. I wrote a small function
to get all loggers, and log on every level to check the real behaviour.
- to draw the loggers tree like logging_tree library
(https://pypi.org/project/logging_tree/). I didn't ask to logging_tree's
maintainer but I don't think he would use such function because the library
works for huge range of python releases.
I plan to write a PR if someone thinks it's a good idea.
--
components: Library (Lib)
messages: 401006
nosy: sblondon
priority: normal
severity: normal
status: open
title: Easier loggers traversal tree with a logger.getChildren method
type: enhancement
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue45095>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42914] pprint numbers with underscore
Stéphane Blondon added the comment: Python 3.10 has now been released with the underscore_numbers parameter. I wonder which release could enable the parameter by default (so it would break the previous behavior): - the next release (3.11) is probably too short. - the safest strategy is to wait until 3.9 will be end-of-life (2025-10 according to [1]). In such case, it could be integrated in 3.14. Could it be accepted before (like 3.12 or 3.13)? If there is no reply, I will create a new issue and PR for 3.14 inclusion ( = safest strategy). 1: https://devguide.python.org/#status-of-python-branches -- ___ Python tracker <https://bugs.python.org/issue42914> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42914] pprint numbers with underscore
Stéphane Blondon added the comment: Ok, I will not send a PR to change the current behavior until python4 (in case it exists one day). -- ___ Python tracker <https://bugs.python.org/issue42914> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41724] SQLite returns "str" instead of "datetime.datetime" with aggregate queries.
Change by Stéphane Blondon : -- keywords: +patch nosy: +sblondon nosy_count: 5.0 -> 6.0 pull_requests: +22720 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23855 ___ Python tracker <https://bugs.python.org/issue41724> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42589] doc: Wrong "from" keyword link in Exceptions doc
Change by Stéphane Blondon : -- keywords: +patch nosy: +sblondon nosy_count: 2.0 -> 3.0 pull_requests: +22734 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23872 ___ Python tracker <https://bugs.python.org/issue42589> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18163] Add a 'key' attribute to KeyError
Stéphane Blondon added the comment: Orian: your patch formats the error message but the original suggested solution is to store the missing key in a new attribute. I don't know if you go in the good direction. Adding an attribute is also suggested by issue #614557. -- nosy: +sblondon versions: -Python 3.4 ___ Python tracker <https://bugs.python.org/issue18163> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37779] configparser: add documentation about several read() behaviour
Stéphane Blondon added the comment: Merged by Łukasz Langa in september 2020. (Thanks Łukasz) -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37779> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42643] http.server does not support HTTP range requests
Stéphane Blondon added the comment: RangeHTTPServer seems to support python3: there is a try-except clause to manage the different import of SimpleHTTPServer: https://github.com/danvk/RangeHTTPServer/blob/master/RangeHTTPServer/__main__.py#L13 The code is under Apache 2.0 licence. I don't know if it can be integrated in codebase under the PSF licence. Another question needs to be answered previously: does the maintainers want to add such feature to SimpleHTTPServer (which goal is to be very basic)? They could prefer to add a header refusing the Range header: Accept-Ranges: none https://tools.ietf.org/id/draft-ietf-httpbis-p5-range-09.html#header.accept-ranges -- nosy: +sblondon ___ Python tracker <https://bugs.python.org/issue42643> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18163] Add a 'key' attribute to KeyError
Stéphane Blondon added the comment: I'm interested by such feature. I see examples of versions of the message provided by KeyError: - sometimes with a message (for example `PyErr_SetString(PyExc_KeyError, "name too long");` at [1]) - sometimes with the missing key (for example `PyErr_SetObject(PyExc_KeyError, key);` at [2]) It explains why there is a difference in the messages in KeyError (as said in previous messages). PyErr_SetString(), PyErr_Format(), PyErr_FormatV() (implemented in Python/errors.c) don't have a parameter to set the missing key. So I think it would be easier to set the missing attribute before calling thoses functions. According to [3], the C PyExc_KeyError matches the Python KeyError exception. So I think to: - Add a 'missing_key' attribute to KeyError_str (in [4]) - Add the missing key to PyExc_KeyError instance before the call of PyErr_SetString(), PyErr_SetObject(), etc. Do you think such strategy is doable? What do you think about it? Is it the way you think about it? If not, do you have some hint? I already made some minor patches to cpython but only in the Python part, never in C one. 1: https://github.com/python/cpython/blob/master/Modules/unicodedata.c#L1398 2: https://github.com/python/cpython/blob/master/Python/hamt.c#L2767 3: https://docs.python.org/3/c-api/exceptions.html?highlight=pyerr_format#standard-exceptions 4: https://github.com/python/cpython/blob/master/Objects/exceptions.c#L1569 -- ___ Python tracker <https://bugs.python.org/issue18163> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42914] pprint numbers with underscore
Stéphane Blondon added the comment: I add the same idea but later than you, so I'm interested by such feature. Felipe: do you want to add a pull request to this issue (with Serhiy Storchaka implementation because it's the simplest one)? If not, I plan to write it. I will write it too if there is no reply in one month. -- nosy: +sblondon ___ Python tracker <https://bugs.python.org/issue42914> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37779] configparser: add documentation about several read() behaviour
New submission from Stéphane Blondon :
The documentation is not explicit about the behaviour if several files are read
by the same ConfigParser: the data are not reset between two read().
I suggest to add such information in the documentation. There is a draft:
=== start ===
When a `ConfigParser` instance make several calls of `read_file()`,
`read_string()` or `read_dict()` functions, the previous data will be overriden
by the new ones. Otherwise, the previous data is kept. This behaviour is
equivalent to a `read()` call with several files passed to `filenames`
parameter`.
Example:
config = configparser.ConfigParser()
s = """
[spam]
alpha=1
"""
config.read_string(s)
# dict(config["spam"]) == {'alpha': '1'}
config.read_string("")
# dict(config["spam"]) == {'alpha': '1'}
=== end ===
What do you think about it?
I can do a PR but I wonder where is the best location in the documentation to
insert it.
At the end of the 'Quick start paragraph'
(https://docs.python.org/3/library/configparser.html#quick-start)? Or perhaps a
new paragraph after 'Fallback Values'? Other location?
--
components: Library (Lib)
messages: 349133
nosy: sblondon
priority: normal
severity: normal
status: open
title: configparser: add documentation about several read() behaviour
type: enhancement
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue37779>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37779] configparser: add documentation about several read() behaviour
Change by Stéphane Blondon : -- keywords: +patch pull_requests: +14908 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/15177 ___ Python tracker <https://bugs.python.org/issue37779> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37779] configparser: add documentation about several read() behaviour
Stéphane Blondon added the comment: Thank you for the idea. :) I committed something else, based on the previous example of the 'Quick Start' section. What do you think about it? -- ___ Python tracker <https://bugs.python.org/issue37779> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32234] Add context management to mailbox.Mailbox
Stéphane Blondon added the comment: I don't know about something blocking the merge. I sent a message to Barry on Github the 3th january but perhaps it was a wrong timing (too soon after new year). -- ___ Python tracker <https://bugs.python.org/issue32234> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32234] Add context management to mailbox.Mailbox
Stéphane Blondon added the comment: The availability of context manager does not make it mandatory if it does not fit some needs. > In the last example on https://docs.python.org/3/ > library/mailbox.html#examples inbox is locked and unlocked multiple > times. The with statement couldn't be used here. > I agree with the idea: if the user code needs to manage a lock, using this context manager is a bad idea. By the way, this example does not need to manage the lock because 'inbox' is an instance of mailbox.Maildir so the .lock() and .unlock() calls do nothing for this class ( https://docs.python.org/3/library/mailbox.html#mailbox.Maildir.unlock). > > On https://pymotw.com/3/mailbox/ some examples use the idiom > > mbox = ... > mbox.lock() > try: > ... > finally: > mbox.unlock() > > and others use the idiom > > mbox = ... > mbox.lock() > try: > ... > finally: > mbox.flush() > mbox.close() > In the first example, there is a .flush() call at the end of the try block. In the second case, mbox.flush() is unnecessary because .close() call flush. So I see it like choosing between (.flush() and .unlock()) or .close(). It's what the context manager does. If there is no agreement, perhaps this proposal should be abandoned? -- ___ Python tracker <https://bugs.python.org/issue32234> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33183] Refactoring: replacing some assertTrue by assertIn
New submission from Stéphane Blondon :
In several cases, tests use ```self.assertTrue(a in b)```. Using
```self.assertIn(a, b)``` seems to be better.
For examples:
./Lib/test/test_inspect.py:
self.assertTrue('(po, pk' in repr(sig))
./Lib/test/test_configparser.py:
self.assertTrue('that_value' in cf['Spacey Bar'])
./Lib/test/test_collections.py:
self.assertTrue(elem in c)
There are some cases where ```self.assertTrue(a not in b)``` could be replaced
by ```self.assertNotIn(a, b)```
./Lib/tkinter/test/test_ttk/test_widgets.py:
self.assertTrue('.' not in value)
./Lib/test/mapping_tests.py:
self.assertTrue(not ('a' in d))
self.assertTrue('a' not in d)
$ find . -name "*.py" | xargs grep -r "assertTrue.* in "
finds 131 occurences but there are some false positives inside the output.
I can write a patch if you are interested.
--
components: Tests
messages: 314670
nosy: sblondon
priority: normal
severity: normal
status: open
title: Refactoring: replacing some assertTrue by assertIn
type: enhancement
___
Python tracker
<https://bugs.python.org/issue33183>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33256] module is not displayed by cgitb.html
New submission from Stéphane Blondon : The html produced by cgitb.html() does not display because the square brackets are interpreted as a html tag (see the picture in attachement). This bug occurs if the code is called directly in the module, not inside a function or a class. -- components: Library (Lib) files: traceback_cgi.gif messages: 315167 nosy: sblondon priority: normal severity: normal status: open title: module is not displayed by cgitb.html Added file: https://bugs.python.org/file47528/traceback_cgi.gif ___ Python tracker <https://bugs.python.org/issue33256> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33256] module is not displayed by cgitb.html
Change by Stéphane Blondon : -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue33256> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33256] module is not displayed by cgitb.html
Change by Stéphane Blondon : -- keywords: +patch pull_requests: +6138 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue33256> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33311] cgitb: remove parentheses when the error is in module
New submission from Stéphane Blondon : The cgitb module displays a traceback in text or html. When a module is called, there are no parameters (displayed as '()'). I think they are unnecessary and the parentheses should be removed. ### example for the text version ### $ python3 demo.py [...] /home/stephane/src/cgitest/demo.py in () 7 def func1(a, b): ^-- to be removed? [...] ### end of example ### It occurs in both text and html versions. -- components: Library (Lib) messages: 315459 nosy: sblondon priority: normal severity: normal status: open title: cgitb: remove parentheses when the error is in module type: enhancement ___ Python tracker <https://bugs.python.org/issue33311> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33311] cgitb: remove parentheses when the error is in module
Change by Stéphane Blondon : -- keywords: +patch pull_requests: +6215 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue33311> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3356] some tests fail with 'make EXTRA_CFLAGS="-DPy_DEBUG"' (test_distutils, test_set)
Change by Stéphane Blondon : -- pull_requests: +6216 ___ Python tracker <https://bugs.python.org/issue3356> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33311] cgitb: remove parentheses when the error is in module
Change by Stéphane Blondon : -- pull_requests: +6371 ___ Python tracker <https://bugs.python.org/issue33311> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33507] Improving the html rendered by cgitb.html
New submission from Stéphane Blondon : cgitb.html() returns HTML code viewable in a browser. It would be nice to improve the rendering to have something more readable (increase space between each call, increase contrast for the source code) and more modern. You can see the difference in the attached screenshot. -- components: Library (Lib) files: next.png messages: 316575 nosy: sblondon priority: normal severity: normal status: open title: Improving the html rendered by cgitb.html type: enhancement versions: Python 3.8 Added file: https://bugs.python.org/file47588/next.png ___ Python tracker <https://bugs.python.org/issue33507> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33507] Improving the html rendered by cgitb.html
Stéphane Blondon added the comment: current.png is a screenshot of the html shown in a browser with 3.8 branch next.png is a screenshot of the modified cgitb.html() function. -- Added file: https://bugs.python.org/file47589/current.png ___ Python tracker <https://bugs.python.org/issue33507> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33507] Improving the html rendered by cgitb.html
Change by Stéphane Blondon : -- keywords: +patch pull_requests: +6529 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue33507> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33507] Improving the html rendered by cgitb.html
Stéphane Blondon added the comment: > Instead of hardcoding colors, would it be better to use CSS instead. I agree with you. The current source code contains hardcoded colors. I could add an optional parameter to change the css for the cgitb.html() function: def html(einfo, context=5, css=_DEFAULT_CSS): ... _DEFAULT_CSS would be a string with the equivalent of the hardcoded style. For this change, I will modify the html code to replace some deprecated tags (like big or font) by supported tags. What do you think about it (new optional parameter and html update)? -- ___ Python tracker <https://bugs.python.org/issue33507> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33507] Improving the html rendered by cgitb.html
Stéphane Blondon added the comment: I added the optional parameter to cgitb.html() function and removed the hardcoded css from the html code. I think there are still several improvements to do: - add documentation for the new parameter of cgitb.html() - add the same parameter to cgitb.enable() (?) - remove the cgitb.grey() function because it's not used anymore (?) - perhaps minor improvements of html and css code What do you think about it? -- ___ Python tracker <https://bugs.python.org/issue33507> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
