Change by Géry :
--
pull_requests: +6829
___
Python tracker
<https://bugs.python.org/issue31639>
___
___
Python-bugs-list mailing list
Unsubscribe:
Géry added the comment:
Thanks @xtreak and @vinay.sajip for the fix.
--
___
Python tracker
<https://bugs.python.org/issue33978>
___
___
Python-bugs-list mailin
New submission from Géry :
Calling logging.config.dictConfig several times with a file handler in the same
Python process leaks resources.
INPUT:
$ python3 -Wall <
self.common_logger_config(root, config, incremental)
--
components: Library (Lib)
messages: 320560
nosy: maggy
Géry added the comment:
It looks like Barry Warsaw has not been fully updated the documentation after
making the __spec__.loader attribute match with the __loader__ attribute, and
the __spec__.file attribute match with the __file__ attribute for namespace
packages.
Here is a pull request
Change by Géry :
--
keywords: +patch
pull_requests: +9677
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35181>
___
___
Python-
Change by Géry :
--
pull_requests: +9678
___
Python tracker
<https://bugs.python.org/issue35181>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Géry :
--
keywords: +patch, patch, patch
pull_requests: +11386, 11387, 11388
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Géry :
--
keywords: +patch
pull_requests: +11386
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35790>
___
___
Python-
Change by Géry :
--
keywords: +patch, patch
pull_requests: +11386, 11387
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35790>
___
_
New submission from Géry :
In the documentation of the try statement
(https://docs.python.org/3/reference/compound_stmts.html#the-try-statement), I
think that the sentence:
"sys.exc_info() values are restored to their previous values (before the call)
when returning from a fun
Géry added the comment:
Guido, could we add those missing __subclasshook__ for consistency?
--
nosy: +gvanrossum, maggyero
___
Python tracker
<https://bugs.python.org/issue23
Change by Géry :
--
nosy: +eric.smith
___
Python tracker
<https://bugs.python.org/issue35181>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Géry added the comment:
@barry You gave 2 reasons for changing __spec__.origin and __file__ for
namespace packages.
Your 1st reason:
> I don't particularly like that its origin is "namespace". That's an odd
> special case that's unhelpful to test against (what if you
New submission from Géry :
How to reproduce:
Assign the __spec__.has_location attribute of any module.
Observed result:
__spec__.has_location is a writable.
Expected result:
__spec__.has_location should be read-only, as defined in PEP 451:
https://www.python.org/dev/peps/pep-0451/#attributes
New submission from Géry :
How to reproduce:
In Python:
> import _frozen_importlib
> print(_frozen_importlib.__spec__.origin)
Observed result:
The __spec__.origin attribute of the _frozen_importlib module is None.
Expected result:
The __spec__.origin attribute of the _frozen_importlib
Change by Géry :
--
nosy: -maggyero
___
Python tracker
<https://bugs.python.org/issue35320>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Change by Géry :
--
nosy: +maggyero
___
Python tracker
<https://bugs.python.org/issue35320>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
New submission from Géry :
In the logging package, the parameter disable_existing_loggers used in
logging.config.dictConfig and logging.config.fileConfig does not apply to the
root logger. More precisely, its disabled attribute remains unchanged (while it
is set to True for non-root loggers
Change by Géry :
--
nosy: +maggyero, mdk, xtreak
versions: +Python 3.7
___
Python tracker
<https://bugs.python.org/issue35640>
___
___
Python-bugs-list mailin
Change by Géry :
--
resolution: -> rejected
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Géry added the comment:
> A bit late for that now
Okay, so disabled is a private attribute so it should never be used anyway. And
as it not documented anywhere in the official Python documentation, I think the
current situation is fine. Thank you for the explanation, I am closing this
is
New submission from Géry :
Use consistent case for HTTP header fields, according to [RFC
7231](https://tools.ietf.org/html/rfc7231).
--
components: Library (Lib)
messages: 335870
nosy: brett.cannon, eric.araujo, ezio.melotti, maggyero, mdk, ncoghlan, willingc
priority: normal
severity
Change by Géry :
--
keywords: +patch
pull_requests: +11949
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36029>
___
___
Python-
Géry added the comment:
Please see the changes and my reply in the PR.
--
title: Use consistent case for HTTP header fields -> Use title-case HTTP header
fields
___
Python tracker
<https://bugs.python.org/issu
New submission from Géry :
In the logging Python library, one can completely disable logging (for all
levels) for a particular logger either by setting its `disabled` attribute to
`True`, or by adding to it a `lambda record: False` filter, or by adding to it
a `logging.NullHandler()` handler
Change by Géry :
--
keywords: +patch
pull_requests: +12334
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36318>
___
___
Python-
Géry added the comment:
> It would be better to set the level of those loggers to e.g. ERROR or
> CRITICAL rather than disabling them altogether - presumably if something bad
> happens in those packages, one would want to know!
What if the user doesn't care anyway? Why assuming what
Géry added the comment:
Actually people do this all the time, to deactivate the logging of some
third-party libraries (me included). For instance:
*
https://stackoverflow.com/questions/24344045/how-can-i-completely-remove-any-logging-from-requests-module-in-python
*
https
Géry added the comment:
Yes, closed.
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue35321>
___
__
New submission from Géry :
Could we allow arbitrary expressions in the @expression syntax for applying
decorators to functions/classes? The current grammar restriction to:
decorator: '@' dotted_name [ '(' [arglist] ')' ] NEWLINE
is very surprising and I don't understand the real
Géry added the comment:
@Steven D'Aprano
> What matters is the __mro__ attribute of the first argument. It matters
because that is how the MRO actually is searched.
By the way, if it was true (it is not), then what did you think was the purpose
of the second parameter of super(type,
Géry added the comment:
@Christian Heimes
> The reasons are explained at:
Yes I read that. But I am wondering if after 15 years Guido still has this "gut
feeling". Because my gut feeling as a Python *user* who has discovered
decorators and stumbled on this restricti
Géry added the comment:
@Guido van Rossum
> What you want to write is as unreadable as it ever was.
How is @g(f()()) more readable than @f()()? Yet the former is allowed.
--
resolution: wont fix ->
status: closed -> open
___
Pytho
Géry added the comment:
@Jeroen Demeyer
> I'm sorry to say that you're wrong here. super() looks at the MRO of the type
> of the object (the second argument) (*).
Exactly! It is funny because I was about to open the same issue this weekend.
The documentation of super() is wron
New submission from Géry :
With the current Python equivalent `ClassMethod` implementation of
`classmethod` given in Raymond Hettinger's _Descriptor HowTo Guide_, the
following code snippet:
```
class A:
@ClassMethod
def f(cls, *, x): pass
print(A.f)
A.f(x=3)
```
prints:
> .newf
Géry added the comment:
@Steven D'Aprano
> But neither can it *only* look at the MRO of the second class, because that
> would restart the search at the top of the hierarchy; also if type(second
> argument) was the only thing that mattered, that would make the first
> argume
Géry added the comment:
@Raymond Hettinger
> Though less accurate, the current version communicates better
I agree that types.MethodType is more accurate but may be less understandable.
But in this case I think that the Function class for emulating instance methods
should not
Géry added the comment:
George Xie found the root cause of this issue (a bug in the function
method_reduce in cpython/Objects/classobject.c):
https://stackoverflow.com/questions/56609847/why-do-concurrent-futures-processpoolexecutor-and-multiprocessing-pool-pool-fail/56614748#56614748
and he
Change by Géry :
--
nosy: +brett.cannon, pitrou, rhettinger, serhiy.storchaka
___
Python tracker
<https://bugs.python.org/issue37297>
___
___
Python-bugs-list m
Géry added the comment:
As you stated on Stackoverflow, the fact that the function `A.f` becomes the
function `B.f` after a pickling-unpickling sequence creates an infinite
recursive call of `B.f` in worker processes started with
`multiprocessing.pool.Pool().apply(super().f
New submission from Géry :
The following code hangs forever instead of printing "called" 10 times:
from concurrent.futures import ProcessPoolExecutor
class A:
def f(self):
print("called")
class B(A):
def f(self):
Change by Géry :
--
nosy: +gvanrossum
___
Python tracker
<https://bugs.python.org/issue37294>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Géry added the comment:
@Raymond Hettinger
> The goal in the descriptor how-to is to give an understanding of how
> descriptors work.
Okay. So I don't know if that was clear in my last message but that also means
replacing the current "Function" implementation:
class
Géry added the comment:
Initial post: https://stackoverflow.com/q/56587166/2326961
--
___
Python tracker
<https://bugs.python.org/issue37276>
___
___
Python-bug
Géry added the comment:
@Ned Deily
Okay, I did not know if I had to list the potentially interested people
(according to their Github contribution on the module for instance) or let them
do it themselves. Thank you for clarifying.
@Carol Willing
The number of RUNNING futures is always
New submission from Géry :
In the `concurrent.futures` standard module, the number of running calls in a
`ProcessPoolExecutor` is `max_workers + 1` (unexpected) instead of
`max_workers` (expected) like in a `ThreadingPoolExecutor`.
The following code snippet which submits 8 calls to 2 workers
Géry added the comment:
@George Xie
There is an issue with the Python workaround
`multiprocessing.reduction.register(types.MethodType, my_reduce)` that you
proposed. If you then instantiate a `multiprocessing.Manager()` you get this
exception:
> python
Python 3.7.3 (v3.7.3:ef4ec6ed12,
Géry added the comment:
The previous `_pickle.PicklingError` seems to only affect Windows.
--
___
Python tracker
<https://bugs.python.org/issue37297>
___
___
Géry added the comment:
I am having the same blocked signal issue on Windows when using Thread.join.
This program does not print "interrupted" after pressing Ctrl+C:
import threading
import time
def f():
while True:
print("processing")
time.sl
Géry added the comment:
@Julien, @Barry
Now that the PRs are merged, I think that we can close this issue.
--
___
Python tracker
<https://bugs.python.org/issue35
Géry added the comment:
Oops, sorry, only one of the two PRs has been merged.
--
___
Python tracker
<https://bugs.python.org/issue35181>
___
___
Python-bug
Géry added the comment:
And like the `concurrent.futures` module for
`concurrent.futures.ProcessPoolExecutor` but not for
`concurrent.futures.ThreadPoolExecutor` (see above), the `multiprocessing.pool`
module seems also affected by a similar problem for `multiprocessing.pool.Pool`
(process
Géry added the comment:
@Andrew Svetlov
Well this was just an example for illustrating the issue. In real code I need
this to create `ThreadPoolMixin` and `ProcessPoolMixin` classes (similar to the
`socketserver.ThreadingMixIn` and `socketserver.ForkingMixIn` classes in the
standard library
Change by Géry :
--
nosy: +asvetlov, christian.heimes, vstinner
___
Python tracker
<https://bugs.python.org/issue37297>
___
___
Python-bugs-list mailing list
Unsub
Géry added the comment:
@Pablo Galindo Salgado
Thank you for the debugging information. I would have expected 8 "Adding a new
item to the call_queue" instead of 3, since I submitted 8 calls to the process
pool.
The concurrent.futures._base module defines 5 future states:
> _
Géry added the comment:
@Andrew Svetlov
> Adding a new state for "not running and not pending but something in between"
> is useless
I have not suggested that. I have just reported that when the number of
submitted calls is strictly greater than the number of pool
New submission from Géry :
Analysis
In the next two sections showing the module attributes and corresponding spec
attributes of imported modules and run modules, we notice the following rule
(which is in accordance with this `PEP 451 section
<https://www.python.org/dev/peps/pep-0
Géry added the comment:
@Brett Cannon
> PEPs actually become historical documents once they are implemented
Actually the inconsistency of the values of the 3 module attributes
(``__file__``, ``__cached__`` and ``__package__``) is with respect to the other
values within the curr
Change by Géry :
--
nosy: +eric.snow -eric.smith
___
Python tracker
<https://bugs.python.org/issue37519>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Géry :
I have just read PEP 7 and noticed that its line-breaking recommandation in
presence of binary operations seems to contradict its analogue in PEP 8 which
follows Knuth's rule.
PEP 7 (https://www.python.org/dev/peps/pep-0007/#code-lay-out):
> When you break a l
Change by Géry :
--
nosy: +maggyero
___
Python tracker
<https://bugs.python.org/issue1152248>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Change by Géry :
--
nosy: +maggyero
___
Python tracker
<https://bugs.python.org/issue17083>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
New submission from Géry :
The Python library documentation of the `urllib.parse.urlunparse
<https://docs.python.org/3/library/urllib.parse.html#urllib.parse.urlunparse>`_
and `urllib.parse.urlunsplit
<https://docs.python.org/3/library/urllib.parse.html#urllib.parse.urlunsplit>`
Change by Géry :
--
keywords: +patch
pull_requests: +15308
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/15642
___
Python tracker
<https://bugs.python.org/issu
Géry added the comment:
@nicktimko Thanks for the historical track.
Here is a patch that solves this issue by updating the `urlsplit` and
`urlunsplit` functions of the `urllib.parse` module to keep the '?' and '#'
delimiters in URIs if present, even if their associated component is empty
Change by Géry :
--
title: urllib.parse functions reporting false equivalent URIs -> Correct
urllib.parse functions dropping the delimiters of empty URI components
___
Python tracker
<https://bugs.python.org/issu
Change by Géry :
--
pull_requests: +14922
pull_request: https://github.com/python/cpython/pull/15190
___
Python tracker
<https://bugs.python.org/issue35
New submission from Géry :
The page https://docs.python.org/3/ lists these two parts:
- Library Reference
- Language Reference
So both parts are "references".
However in the cpython GitHub repository, the Doc/ directory contains these two
directories:
- library/
- refe
Change by Géry :
--
type: -> enhancement
___
Python tracker
<https://bugs.python.org/issue37799>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Géry :
--
assignee: docs@python
components: Documentation
nosy: docs@python, eric.snow, maggyero
priority: normal
pull_requests: 14923
severity: normal
status: open
title: Clean up the documentation on module attributes
type: enhancement
versions: Python 3.7
Change by Géry :
--
nosy: +rhettinger
___
Python tracker
<https://bugs.python.org/issue38336>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Géry added the comment:
I have opened a PR here: https://github.com/python/cpython/pull/16520
--
___
Python tracker
<https://bugs.python.org/issue38336>
___
___
New submission from Géry :
The [language
documentation](https://docs.python.org/3/reference/datamodel.html#invoking-descriptors)
states:
> Data descriptors with __set__() and __get__() defined always override a
> redefinition in an instance dictionary. In contrast, non-data descripto
Change by Géry :
--
keywords: +patch
pull_requests: +16112
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/16520
___
Python tracker
<https://bugs.python.org/issu
Change by Géry :
--
nosy: +maggyero
___
Python tracker
<https://bugs.python.org/issue9334>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Change by Géry :
--
nosy: +maggyero
___
Python tracker
<https://bugs.python.org/issue37297>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Géry added the comment:
Thanks paul j3 for the link. I am continuing the discussion there.
--
___
Python tracker
<https://bugs.python.org/issue38950>
___
___
Géry added the comment:
I have just run into the same issue here: https://bugs.python.org/issue38950
- I prefer Terry J. Reedy's "keyword arguments" as it is clear and consistent
with "positional arguments".
- But Steven Bethard 's "flag arguments" looks fine si
Géry added the comment:
Thanks @mark.dickinson for the link. Can I open a documentation PR for this?
--
___
Python tracker
<https://bugs.python.org/issue39
Change by Géry :
--
nosy: +maggyero
___
Python tracker
<https://bugs.python.org/issue27100>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
New submission from Géry :
>>> class A: pass
...
>>> with A(): pass
...
Traceback (most recent call last):
File "", line 1, in
AttributeError: __enter__
I expected `AttributeError: __exit__`, since PEP 343 states
(https://www.
Change by Géry :
--
nosy: +maggyero
___
Python tracker
<https://bugs.python.org/issue38295>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Change by Géry :
--
pull_requests: +17079
pull_request: https://github.com/python/cpython/pull/17609
___
Python tracker
<https://bugs.python.org/issue27
Change by Géry :
--
pull_requests: +17081
pull_request: https://github.com/python/cpython/pull/17609
___
Python tracker
<https://bugs.python.org/issue27
New submission from Géry :
Following https://bugs.python.org/issue27100 which did it for the with
statement, what was left to do was to reorder the __aenter__ and __aexit__
method checks for the async with statement.
I have opened a PR for this here: https://github.com/python/cpython/pull
Change by Géry :
--
title: Reorder the __aenter__ and __aexit__ checks for async with -> bpo-39048:
Reorder the __aenter__ and __aexit__ method checks for the async with statement
___
Python tracker
<https://bugs.python.org/issu
Change by Géry :
--
title: bpo-39048: Reorder the __aenter__ and __aexit__ method checks for the
async with statement -> Reorder the __aenter__ and __aexit__ method checks for
the async with statement
___
Python tracker
<https://bugs.pyth
Change by Géry :
--
pull_requests: -17079
___
Python tracker
<https://bugs.python.org/issue27100>
___
___
Python-bugs-list mailing list
Unsubscribe:
Géry added the comment:
@ncoghlan
> Reviewing the discussion, I assume this was left open to cover reordering the
> __aenter__ and __aexit__ checks for async with, but that can just as easily
> be handled as a separate issue (which would also be clearer at the NEWS
> l
Géry added the comment:
Thanks @ncoghlan, it perfectly answered my question on Stack Overflow:
https://stackoverflow.com/questions/59322585/what-is-the-exact-try-statement-equivalent-of-the-with-statement-in-python
--
___
Python tracker
<ht
Géry added the comment:
@gvanrossum
By the way, is there any particular reason why the ``try`` statement
implementation equivalent to the ``with`` statement given in PEP 343 puts the
finally clause in an outer ``try`` statement instead of in the inner ``try``
statement? (cf.
https
Change by Géry :
--
keywords: +patch
pull_requests: +17078
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17608
___
Python tracker
<https://bugs.python.org/issu
Géry added the comment:
Done @brett.cannon, would you like to review it?
https://github.com/python/cpython/pull/17608
--
___
Python tracker
<https://bugs.python.org/issue39
Change by Géry :
--
title: Wrong trial order of __exit__ and __enter__ in the with statement -> Fix
the trial order of the __exit__ and __enter__ methods in the with statement
documentation
___
Python tracker
<https://bugs.python.org/issu
Change by Géry :
--
versions: +Python 3.8 -Python 3.7
___
Python tracker
<https://bugs.python.org/issue38336>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Géry :
The argparse module incorrectly uses the terms "optional arguments" for keyword
arguments.
For instance this argument parser takes a required keyword argument and an
optional positional argument, but classifies the former as an "optional
argument&
New submission from Géry :
The description of `super()` uses the word "method" instead of the more general
word "attribute".
> super([type[, object-or-type]])
> Return a proxy object that delegates method calls to a parent or sibling
> class of *type*. This is u
Géry added the comment:
Alright, I am fine with @rhettinger's alternative PR too. I am closing this.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
New submission from Géry :
Mathematically, the [binary
relation](https://en.wikipedia.org/wiki/Binary_relation) ≤ is the
[union](https://en.wikipedia.org/wiki/Binary_relation#Union) of the binary
relations < and =, while the binary relation ≥ is the union of the binary
relations > and
Géry added the comment:
@Aymeric Augustin
> While you're there, it would be cool to provide "connection.autocommit =
> True" as an API to enable autocommit, because "connection.isolation_level =
> None" isn't a good API at all -- it's very obscure and has no
1 - 100 of 189 matches
Mail list logo
