Géry added the comment:
Thanks for the review Serhiy.
--
___
Python tracker
<https://bugs.python.org/issue44024>
___
___
Python-bugs-list mailing list
Unsub
New submission from Géry :
The API of [`http.server`](https://docs.python.org/3/library/http.server.html)
supports the `directory` optional parameter for `CGIHTTPRequestHandler` (which
is inherited from `SimpleHTTPRequestHandler`). The CLI of `http.server`
supports the corresponding `-d
Change by Géry :
--
nosy: -docs@python
___
Python tracker
<https://bugs.python.org/issue46436>
___
___
Python-bugs-list mailing list
Unsubscribe:
Géry added the comment:
> http.server.BaseHTTPRequestHandler end_headers() can reference _header_buffer
> array before it is assigned.
@grumblor I was about to open the same bug after reading the implementation of
http.server this morning and noticing that the attribute _headers_buf
Change by Géry :
--
versions: +Python 3.9
___
Python tracker
<https://bugs.python.org/issue46436>
___
___
Python-bugs-list mailing list
Unsubscribe:
Géry added the comment:
Thanks Hugo for opening this issue and Éric for inviting me.
As you guys pointed out, function test in module http.server expects a real
handler class argument (SimpleHTTPRequestHandler or CGIHTTPRequestHandler), not
a partial object partial(SimpleHTTPRequestHandler
Géry added the comment:
Thanks for mentioning this issue @merwok.
As you pointed out, function `test` in module
[`http.server`](https://github.com/python/cpython/blob/main/Lib/http/server.py)
expects a real request handler class argument (`SimpleHTTPRequestHandler` or
`CGIHTTPRequestHandler
Change by Géry :
--
keywords: +patch
pull_requests: +29181
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/30999
___
Python tracker
<https://bugs.python.org/issu
Change by Géry :
--
nosy: +maggyero
___
Python tracker
<https://bugs.python.org/issue34486>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Change by Géry :
--
nosy: +maggyero
___
Python tracker
<https://bugs.python.org/issue38119>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
New submission from Géry :
Any [path-like object](https://docs.python.org/3/glossary.html) can be passed
to `multiprocessing.set_executable`, i.e. objects with `str`, `bytes`, or
`os.PathLike` type.
For instance these work (tested on MacOS with all start methods: ‘spawn’,
‘fork’, and
Change by Géry :
--
keywords: +patch
pull_requests: +29439
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/31279
___
Python tracker
<https://bugs.python.org/issu
Change by Géry :
--
type: -> enhancement
___
Python tracker
<https://bugs.python.org/issue46720>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Géry :
--
title: Add support of path-like objects to multiprocessing.set_executable for
Windows to match Unix-like systems -> Add support for path-like objects to
multiprocessing.set_executable for Windows to be on a par with Unix-like syst
New submission from Géry :
I have just notice that the multiprocessing.set_forkserver_preload (which
originates from multiprocessing.forkserver.set_forkserver_preload) is not
documented:
https://github.com/python/cpython/blob/v3.10.2/Lib/multiprocessing/context.py#L180-L185
Change by Géry :
--
type: -> enhancement
___
Python tracker
<https://bugs.python.org/issue46851>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Géry :
--
nosy: +maggyero
___
Python tracker
<https://bugs.python.org/issue45274>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Change by Géry :
--
nosy: +maggyero
___
Python tracker
<https://bugs.python.org/issue29971>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Change by Géry :
--
nosy: +maggyero
nosy_count: 4.0 -> 5.0
pull_requests: +29809
pull_request: https://github.com/python/cpython/pull/31678
___
Python tracker
<https://bugs.python.org/issu
New submission from Géry :
The Python program:
```
import multiprocessing
import time
class Application:
def __init__(self):
self._event = multiprocessing.Event()
self._processes = [
multiprocessing.Process(target=self._worker)
for _ in range
Change by Géry :
--
keywords: +patch
pull_requests: +29821
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/31701
___
Python tracker
<https://bugs.python.org/issu
Change by Géry :
--
title: A started multiprocessing.Process instance cannot be serialised ->
Started multiprocessing.Process instances are unserialisable
___
Python tracker
<https://bugs.python.org/issu
Change by Géry :
--
nosy: +maggyero
___
Python tracker
<https://bugs.python.org/issue23882>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Change by Géry :
--
nosy: +maggyero
___
Python tracker
<https://bugs.python.org/issue35844>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
New submission from Géry :
A `BrokenPipeError` exception is raised when the queue thread of a
`multiprocessing.Queue` still sends enqueued items to the write end of the
queue pipe *after* the read end of the queue pipe has been [automatically
closed during its garbage
collection](https
Change by Géry :
--
keywords: +patch
pull_requests: +30006
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/31913
___
Python tracker
<https://bugs.python.org/issu
Géry added the comment:
I have attached the following patch: pass a reference to the reader end of the
queue pipe to the queue thread so that the reader end is not garbage collected
and closed before the queue thread has sent all the buffered data to the writer
end
Géry added the comment:
I forgot to include the output of the above program:
```
Traceback (most recent call last):
File
"/usr/local/Cellar/python@3.9/3.9.10/Frameworks/Python.framework/Versions/3.9/lib/python3.9/multiprocessing/queues.py",
line 251, in _feed
send_bytes(o
New submission from Géry :
## Expected outcome
```
>>> hasattr(complex(), '__complex__')
True
>>> hasattr(float(), '__complex__')
True
>>> hasattr(int(), '__complex__')
True
```
## Actual outcome
```
>>> hasattr(complex
Change by Géry :
--
nosy: +maggyero
___
Python tracker
<https://bugs.python.org/issue672115>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Change by Géry :
--
versions: +Python 3.11 -Python 3.6
___
Python tracker
<https://bugs.python.org/issue672115>
___
___
Python-bugs-list mailing list
Unsubscribe:
Géry added the comment:
Apologies for the long delay.
> Do we have any meaningful examples to show that this is desired and useful?
A use case of `super()` in a `classmethod` that comes to mind is for
parameterized factory methods. It is a variation of the classic factory method
des
New submission from Géry :
This pull request makes the following changes to the table of methods in the
[`collections.abc`
documentation](https://docs.python.org/3/library/collections.abc.html):
- `Reversible`: add `__iter__` abstract method;
- `Generator`: replace `__iter__` with inherited
Géry added the comment:
Thanks for the review.
@rhettinger
> And adding classmethod() support in super_descr_get() would create tight
> coupling where there should be separate concerns (no other descriptor call is
> classmethod specific).
The descriptors `super`, `property`, and
Géry added the comment:
> On StackOverflow, there has been some mild interest in the interactions
> between super() and classmethod():
>
> * https://stackoverflow.com/questions/64637174
> * https://stackoverflow.com/questions/1269217
> * https://stackoverflow.com/question
Géry added the comment:
> I think this may fine as-is. In general, virtiual classes only promise that
> an operation will work rather than promsing the presence of a particular
> method.
Okay, I just wanted to make sure that the absence of the `__complex__` method
was intended a
Géry added the comment:
By the way:
> I don't think we need two ways to do it.
So do you think we could drop the support for single-argument super?
Michele said in his article:
> There is a single use case for the single argument syntax of super that I am
> aware of, but I
Géry added the comment:
Alright, thanks. Raymond, any objections before I propose the removal of
one-argument super?
--
___
Python tracker
<https://bugs.python.org/issue44
New submission from Géry :
This P.R. will make the following changes to the `collections.abc` module:
- simplify the implementation with slicing in function `Sequence.index`.
- remove an unnecessary copy of `self` when a sequence extends itself in
function `MutableSequence.extend
New submission from Géry :
Registering `weakref.WeakSet` as a subtype of `_collections_abc.MutableSet`
implies that it is also a subtype of `_collections_abc.Set` since
`_collections_abc.MutableSet` is a subtype of `_collections_abc.Set` and the
subtype relation is transitive
Change by Géry :
--
nosy: +maggyero
___
Python tracker
<https://bugs.python.org/issue47206>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
New submission from Géry :
- Document the optional *callback* parameter of `weakref.WeakMethod`.
- Fix a few spelling mistakes.
- Improve wording.
--
components: Library (Lib)
messages: 416697
nosy: maggyero
priority: normal
pull_requests: 30376
severity: normal
status: open
title
Géry added the comment:
> Anthony Sottile provided this search to showing that at least a few popular
> projects are using the one argument form of super():
Thanks for the link. But it gives lots of false positives. Only two popular
projects (> 1k stars) use autosuper (urwid an
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 co
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
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
Change by Géry :
--
nosy: +maggyero
___
Python tracker
<https://bugs.python.org/issue9334>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
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.pyth
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
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 :
--
nosy: +rhettinger
___
Python tracker
<https://bugs.python.org/issue38336>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
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 :
Remove a duplicate comment and assignment following the usage of a name already
assigned in the http.client standard library.
--
components: Library (Lib)
messages: 388538
nosy: maggyero
priority: normal
pull_requests: 23597
severity: normal
status: open
New submission from Géry :
Currently, the `object.__setattr__` and `type.__setattr__` methods raise an
`AttributeError` during attribute *update* on an instance if its type has an
attribute which is a *data* descriptor without a `__set__` method. Likewise,
the `object.__delattr__` and `type
Change by Géry :
--
keywords: +patch
pull_requests: +23781
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25033
___
Python tracker
<https://bugs.python.org/issu
New submission from Géry :
When
```
TypeError: __weakref__ slot disallowed: either we already got one, or
__itemsize__ != 0
```
is raised, the second condition `base->tp_itemsize != 0` (i.e. the base is a
*variable-length* type, like `int`, `tuple` and `bytes`) in the error message
Change by Géry :
--
keywords: +patch
pull_requests: +24096
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25362
___
Python tracker
<https://bugs.python.org/issu
New submission from Géry :
Compare the `AttributeError` messages in this interactive Python session:
```python
>>> class A:
... y = 0
... __slots__ = ('z',)
...
>>> A().x
[…]
AttributeError: 'A' object has no attribute 'x'
>>>
Change by Géry :
--
keywords: +patch
pull_requests: +24158
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25424
___
Python tracker
<https://bugs.python.org/issu
New submission from Géry :
This PR updates the page [*Built-in
Functions*](https://docs.python.org/3.9/library/functions.html#super) of the
Python library documentation: `super` is not a `function` (`isinstance(super,
type(lambda: None))` is `False`), it is a `type` (`isinstance(super, type
Change by Géry :
--
keywords: +patch
pull_requests: +24212
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25489
___
Python tracker
<https://bugs.python.org/issu
Géry added the comment:
> Looking again, it seems to someone has already started applying class markup
> despite previous decisions not to do so.
Yes, and he forgot super:
class bool([x])
class bytearray([source[, encoding[, errors]]])
class bytes([source[, encoding[, errors]]])
Géry added the comment:
> Elsewhere in the docs, all the links to this entry use the markup,
> :func:`super` which looks nicer in the docs than the class reference.
I was suggesting only to update the block Sphinx directive “.. function::” to
“.. class::” for defining the signature (s
New submission from Géry :
Problem
---
Actual behaviour:
```python
>>> getattr('foobar', 123)
Traceback (most recent call last):
File "", line 1, in
TypeError: getattr(): attribute name must be string
>>> hasattr('foobar', 123)
Tracebac
Change by Géry :
--
keywords: +patch
pull_requests: +24544
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25863
___
Python tracker
<https://bugs.python.org/issu
Change by Géry :
--
title: Use common TypeError message for built-in functions getattr and hasattr
-> Improve the error message for non-string second arguments passed to the
built-in functions getattr and hasattr
___
Python tracker
<
Change by Géry :
--
title: Improve the error message for non-string second arguments passed to the
built-in functions getattr and hasattr -> Improve the TypeError message for
non-string second arguments passed to the built-in functions getattr and hasa
New submission from Géry :
A use case of one-argument `super` (aka unbound `super`) is Guido van Rossum’s
autosuper described in his 2002 article [*Unifying types and classes in Python
2.2*](https://www.python.org/download/releases/2.2.3/descrintro/#cooperation).
It works with functions, but
Change by Géry :
--
keywords: +patch
pull_requests: +24660
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26009
___
Python tracker
<https://bugs.python.org/issu
Géry added the comment:
@jack__d
Thanks for the rewrite! This is a great expansion. Unfortunately I didn’t have
the time to review it before the merge. If I find something to be improved I
will let you know.
@gvanrossum
> Your docs seem to promote the second, whereas I've usually p
Géry added the comment:
No worries, it was almost twenty years ago.
> But it's probably better to raise a dedicated exception in that case and
> catch it in main(), rather than just calling sys.exit() deep inside the other
> code.
Yes I agree, and I think you explained very
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&quo
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" loo
Géry added the comment:
Thanks paul j3 for the link. I am continuing the discussion there.
--
___
Python tracker
<https://bugs.python.org/issue38950>
___
___
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.
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
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 :
--
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: -17079
___
Python tracker
<https://bugs.python.org/issue27100>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 :
--
pull_requests: +17081
pull_request: https://github.com/python/cpython/pull/17609
___
Python tracker
<https://bugs.python.org/issue27
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
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
> level).
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
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
Change by Géry :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue39037>
___
___
Change by Géry :
--
title: Reorder __aenter__ & __aexit__ checks for async with statement ->
Change the lookup order of __aenter__ and __aexit__ for async with
___
Python tracker
<https://bugs.python.org/
Change by Géry :
--
title: Change the lookup order of __aenter__ and __aexit__ for async with ->
Look up __aenter__ before __aexit__ in async with
___
Python tracker
<https://bugs.python.org/issu
Change by Géry :
--
title: Fix the trial order of the __exit__ and __enter__ methods in the with
statement documentation -> Look up __enter__ before __exit__ in the with
statement documentation
___
Python tracker
<https://bugs.pyth
Change by Géry :
--
title: Look up __aenter__ before __aexit__ in async with -> Look up __aenter__
before __aexit__ in the async with statement
___
Python tracker
<https://bugs.python.org/issu
1 - 100 of 189 matches
Mail list logo
