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
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
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 :
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
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
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
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 think
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
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:
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
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:
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
Change by Géry :
--
versions: +Python 3.11 -Python 3.6
___
Python tracker
<https://bugs.python.org/issue672115>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Géry :
--
nosy: +maggyero
___
Python tracker
<https://bugs.python.org/issue672115>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
New submission from Géry :
## Expected outcome
```
>>> hasattr(complex(), '__complex__')
True
>>> hasattr(float(), '__complex__')
True
>>> hasattr(int(), '__complex__')
True
```
## Actual outcome
```
>>> hasattr(complex(), '__complex__')
False
>&
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
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
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
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 :
--
nosy: +maggyero
___
Python tracker
<https://bugs.python.org/issue35844>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
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 :
--
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 :
--
keywords: +patch
pull_requests: +29821
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/31701
___
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 :
--
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
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
___
Python tracker
<https://bugs.python.org/issue45274>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Change by Géry :
--
type: -> enhancement
___
Python tracker
<https://bugs.python.org/issue46851>
___
___
Python-bugs-list mailing list
Unsubscrib
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 :
--
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
Change by Géry :
--
type: -> enhancement
___
Python tracker
<https://bugs.python.org/issue46720>
___
___
Python-bugs-list mailing list
Unsubscrib
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
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
Change by Géry :
--
nosy: +maggyero
___
Python tracker
<https://bugs.python.org/issue38119>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
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 :
--
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
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
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
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:
> 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_
Change by Géry :
--
nosy: -docs@python
___
Python tracker
<https://bugs.python.org/issue46436>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
Géry added the comment:
Thanks for the review Serhiy.
--
___
Python tracker
<https://bugs.python.org/issue44024>
___
___
Python-bugs-list mailing list
Unsub
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 cl
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 prefer
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
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
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
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 :
--
keywords: +patch
pull_requests: +24544
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/25863
___
Python tracker
<https://bugs.python.org/issu
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)
Traceback (most recent c
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 signatu
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]]])
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
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: +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 :
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'
>>> A().x = 1
[…]
AttributeError:
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 :
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 mess
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 :
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
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
Géry added the comment:
@james.oldfield
> What that answer doesn't mention is that, even with even with
> isolation_mode=None, it's perfectly possible to start a transaction, which
> takes the SQLite engine out of autocommit mode.
Exactly, so since autocommit=True is e
Géry added the comment:
> If this ever gets implemented, "autocommit" would be a terrible name for it.
> That word has a very specific meaning in SQLite, which is essentially the
> same as "not in a transaction started with BEGIN ...".
Yes if you are talking abou
Change by Géry :
--
versions: +Python 3.9 -Python 3.7
___
Python tracker
<https://bugs.python.org/issue37203>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Géry :
--
resolution: not a bug -> fixed
___
Python tracker
<https://bugs.python.org/issue37203>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Géry :
--
pull_requests: +21866
pull_request: https://github.com/python/cpython/pull/22934
___
Python tracker
<https://bugs.python.org/issue37
Géry added the comment:
Thanks @barry for reviewing and merging PR 15190
> I haven't merged PR 10016, but I left some additional comments. Are you
> still interested in shepherding this PR?
Also thanks for helping me with @ericsnowcurrently advancing this last PR. Yes
I am still inte
Change by Géry :
--
nosy: +cheryl.sabella -eric.araujo, ezio.melotti, willingc
title: Correct a statement about sys.exc_info() values restoration -> Correct
the description of sys.exc_info() and add a code example
type: -> enhancement
versions: +Python 3.6, Python 3.8, Pyth
Géry added the comment:
Alright @rhettinger, here is the post:
https://discuss.python.org/t/add-missing-default-implementations-of-le-and-ge/5327
--
___
Python tracker
<https://bugs.python.org/issue39
New submission from Géry :
Nicholas, I have noticed that `runpy.run_path` alters `sys.path` as expected
for a file_path argument which is a valid `sys.path` entry (typically a
directory or zip file). That is to say it adds the file_path argument to the
beginning of `sys.path`, like `python
Géry added the comment:
I agree with you Terry. Another thing that bothers me: in the current document,
the __main__ module is reduced to its environment (aka context or dictionary),
whereas a module object has other important attributes such as its code.
So how about adding the following
Géry added the comment:
Thanks for your extended review Steven.
> You state that these two phrases are from the runpy documentation:
>
> * "run from the module namespace"
> * "run from the file system"
>
> but neither of those phrases appear in t
Géry added the comment:
More precisely:
The following relationships are always valid and therefore implemented by
default in Python (_except for the union relationships, which seems arbitrary
and is the reason of this Python issue_):
- 2 [complementary](https://en.wikipedia.org/wiki
Géry added the comment:
Note that other relationships are always valid _and already implemented by
default in the interpreter (through the `NotImplemented` return value
protocol)_: = is the
[converse](https://en.wikipedia.org/wiki/Binary_relation#Converse) of itself, ≠
is the converse
Géry added the comment:
Thanks for the reference @Raymond. I could not find any mention of the union
relationships for ≤ and ≥ though. Since they are always valid for Boolean
values, in the same way that ≠ is always the complement of = for Boolean values
and default implemented
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:
> - Remove the value None of the autocommit property and its deprecation
> warning.
Correction:
- Remove the value None of the autocommit property and its deprecation warning,
so that the old manual commit mode disa
Géry added the comment:
> - Remove the value None of the isolation_level property, so that the old
> manual commit mode disappears.
Correction:
- Remove the value None of the isolation_level property.
--
___
Python tracker
Géry added the comment:
@R. David Murray
> Please open a new issue for this request.
Done here: https://bugs.python.org/issue39457
--
___
Python tracker
<https://bugs.python.org/issu
Change by Géry :
--
title: Add an autocommit property to sqlite3.Connection with truly PEP 249
compliant manual commit mode and migrate -> Add an autocommit property to
sqlite3.Connection with a PEP 249 compliant manual commit mode and migr
New submission from Géry :
In non-autocommit mode (manual commit mode), the sqlite3 database driver
implicitly issues a BEGIN statement before each DML statement (INSERT, UPDATE,
DELETE, REPLACE) not already in a database transaction, BUT NOT before DDL
statements (CREATE, DROP) nor before
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
New submission from Géry :
This PR will apply the following changes on the [`__main__` module
documentation](https://docs.python.org/3.7/library/__main__.html):
- correct the phrase "run as script" by "run from the file system" (as used in
the [`runpy`](https://docs.
Géry added the comment:
With Berker Peksag's patch merged in 2016, in the default non auto-commit mode,
sqlite3 implicitly issues a BEGIN statement before any non SELECT statement not
already in a transaction, EXCEPT DDL statements, for backwards compatibility
reasons:
+/* For backwards
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
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: 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: 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 :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue39037>
___
___
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
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
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: +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 :
--
pull_requests: -17079
___
Python tracker
<https://bugs.python.org/issue27100>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 :
--
nosy: +maggyero
___
Python tracker
<https://bugs.python.org/issue38295>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
1 - 100 of 189 matches
Mail list logo
