[Python-Dev] Re: Retiring this mailing list ?
On 11/14/2023 1:21 PM, Steve Holden wrote: On Mon, 13 Nov 2023 at 10:18, Marc-Andre Lemburg wrote: [...] Question: Should we retire and archive this mailing list ? (I'm asking as one of the maintainers of the ML) [...] Hi Marc-Andre, Maybe just require senders to be members of the python.org <http://python.org> domain, and retain the release announcements? I think the python-announce list serves that purpose. Any time there's an announcement here, I also see a separate copy of it on python-announce (where I'm a moderator). Eric ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/SHV5KJIBK67IYSCPTFDO5HEQV6YKM76O/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: please consider changing --enable-unicode default to ucs4
Sent from my iPhone ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/TA3MZ2TSDGVAJ7NTTR5F37V7AVRM7ELR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Feature Suggestion: "repeat" statement in loops
Why would "if not A" also be true when you repeat the current iteration? What keeps this from becoming an endless loop? Jan 26, 2023, 11:45 by thomasratzk...@outlook.de: > Hi all, > > i would like to suggest the following Python feature. It naturally happens > that one want's to repeat the current iteration of a for loop for example > after an error happened. For this purpose, I usually set a flag and put a > while loop inside my for loop. A simple "repeat" statement just like > "continue" or "break" would make the code much more readable. > > > This is my solution at the moment with A being checked: > > for _ in range(n): > flag = True > while flag: > ... > if A: > flag = False # go to next iteration > > > I would suggest the repeat statement in the following sense > > for _ in range(n): > ... > if not A: > repeat # repeat current iteration > > Notice the "not" in the if clause. I am really looking forwars to hear your > opinions. > > Best regards > Thomas > > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/LNER4MH6IT6HBFKFVTUOJ225PTCZSRRC/ > Code of Conduct: http://python.org/psf/codeofconduct/ > _______ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/S74XCQ6RWBZRO3F5GNAPT4DKKMFVAV2M/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Switching to Discourse
> This does not solve the problem of engaging actively in a discussion, of course I just submitted a proposal to create a Discourse plugin to improve the accuracy of their inbound email parsing, which is something that several people have complained about in this thread. This would enable two things: - Folks who prefer to live in their inbox could continue to do so and contribute by just replying to emails. Discourse currently has reply-by-email, but it often mangles formatting and/or entirely deletes text. Once these issues are fixed, folks who like the current experience would be able to just pretend the forum doesn't exist and continue having the same experience as they currently have with GNU Mailman. - Right now importing the archives from GNU Mailman into Discourse isn't realistic for the same reasons; some messages will import correctly, but others will be mangled or missing text. This means you would still need to maintain the Malman archive as the canonical source of truth. Once fixed, not only would the [Python-Dev] archives be searchable within Discourse, but they should also rank better in search than they do in their current archive. If this is something you care about (positively or negatively), here is the exploratory proposal: https://meta.discourse.org/t/proposed-plugin-to-improve-reply-by-email-accuracy/252944 Any feedback and/or testing would be much appreciated! Right now Discourse recognizes that this is a problem and is interested in solving it, but getting it prioritized will require folks to A) speak up saying they want it done B) test the underlying API to verify that it actually solves the problem. Alex On Sun, Dec 11, 2022 at 1:54 PM Tiziano Zito wrote: > > On Sat 10 Dec, 17:47 +0100, Baptiste Carvello < > devel2...@baptiste-carvello.net> wrote: > >There is a small catch though: unless I'm mistaken, Discourse won't let > >you subscribe to just a set of categories, so any filtering has to > >happen on the Mailman side. > > Well, it is actually possible to achieve what you want. > > I have set up Discourse in mailing-list mode [1]. > > By default muted categories are not included in the emails you get in > mailing list mode. > > So, you just need to mute all categories you don't care about. It is a bit > of work, but it needs to be done only once. To have an almost complete > equivalent of the topics that were once discussed on python-dev, you can > just mute every thing except the "Core Development" category. This is the > setting I am using since a while and I am quite happy with it. You may want > to unmute the "PEPs" category as well. > > Threading info is kept quite nicely, so I read the discourse mail > notifications as if it were a mailing list and I almost do not see any > difference. Text is sometimes a bit messy if people heavily use the > discourse formatting capabilities, but this kind of posts are quite rare in > my experience. > > This does not solve the problem of engaging actively in a discussion, of > course, but at least for me it is OK to login to discourse if I have to > post, given that 99.99% of the time I just want to read posts in my mail > client. > > Ciao! > Tiziano > > [1] You can do this while editing your profile preferences, under the > "Emails" menu > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/7ZJWPADSL7BGBZ5Y6BRHP2LDTHQFZ7UV/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Alex Krupp Cell: (607) 351 2671 Read my Email: www.fwdeveryone.com/u/alex3917 Subscribe to my blog: https://alexkrupp.typepad.com/ My homepage: www.alexkrupp.com ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/Y3BO5TBIM2YQXWCQ4D4RPOBBIDVHNXAL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 701 – Syntactic formalization of f-strings
Great stuff! Rob Cliffe On 19/12/2022 17:59, Pablo Galindo Salgado wrote: Hi everyone, I am very excited to share with you a PEP thatBatuhan Taskaya, Lysandros Nikolaou and myself have been working on recently:PEP 701 - PEP 701 – Syntactic formalization of f-strings <https://peps.python.org/pep-0701/>. We believe this will be a great improvement in both the maintainability of CPython and the usability of f-strings. We look forward to hearing what you think about this and to get your feedback! *Here is a TLDR for your convenience:* * The PEP proposes a formalized grammar for f-strings in Python by adding f-strings directly into the Grammar instead of using a two-pass hand-written parser. * This would lift some existing restrictions for f-strings that (we believe) will improve the user experience with f-strings. * Other benefits include: o Reduced maintenance costs for f-string parsing code as well as improved usability for users and library developers. o Better error messages involving f-strings by leveraging the PEG parser machinery. o The proposed changes would improve the overall consistency of the language and provide a way for alternative implementations to accurately implement f-strings. *** IMPORTANT: direct all discussions to the discussion thread on discourse: https://discuss.python.org/t/pep-701-syntactic-formalization-of-f-strings/22046 *** Thanks a lot, everyone for your time! Regards from rainy London, Pablo Galindo Salgado ___ Python-Dev mailing list --python-dev@python.org To unsubscribe send an email topython-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived athttps://mail.python.org/archives/list/python-dev@python.org/message/IU4O3GFGWJ4FWXXC2TVB4CNPZI3KFBQM/ Code of Conduct:http://python.org/psf/codeofconduct/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/S2S2OQNDDSYCC23LBINQZZUCNVYOAEAC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: A proposal to modify `None` so that it hashes to a constant
You are absolutely right, of course. It was a wild idea, and a bad one.
I find myself moving towards supporting the OP. I can't see anything
terrible about the hash of None always being 0, or perhaps better some
other arbitrary constant.
Rob
On 04/12/2022 03:20, Steven D'Aprano wrote:
On Thu, Dec 01, 2022 at 10:18:49PM +, Rob Cliffe via Python-Dev wrote:
Wild suggestion:
Make None.__hash__ writable.
E.g.
None.__hash__ = lambda : 0 # Currently raises AttributeError:
'NoneType' object attribute '__hash__' is read-only
You would have to write to `type(None).__hash__` because of the way
dunders work.
Now imagine that you have twenty different libraries or functions or
classes, each the `__hash__` method to a different function. Chaos.
You can simulate that chaos with this:
```
import random
class ChangingHash:
def __repr__(self):
return "MyNone"
def __hash__(self):
# Simulate the effect of many different callers changing
# the hash value returned at unpredictable times.
return random.randint(1, 9)
MyNone = ChangingHash()
data = {MyNone: 100}
print(MyNone in data) # 8 in 9 chance of printing False
data[MyNone] = 200
print(data) # 8 in 9 chance of {MyNone: 100, MyNone: 200}
print(MyNone in data) # now 7 in 9 chance of printing False
```
_______
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/NKXS4JKYMOTAIMS7D5YY5FSQPBPWZHPA/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: A proposal to modify `None` so that it hashes to a constant
You're right of course. Oh well, it *was* a wild idea.
Rob Cliffe
On 04/12/2
On 04/12/2022 18:16, Chris Angelico wrote:
On Mon, 5 Dec 2022 at 05:11, Rob Cliffe via Python-Dev
wrote:
Wild suggestion:
Make None.__hash__ writable.
E.g.
None.__hash__ = lambda : 0 # Currently raises AttributeError:
'NoneType' object attribute '__hash__' is read-only
Hashes have to be stable. If you change the hash of None after it's
been inserted into a dictionary, you'll get all kinds of entertaining
problems.
class X:
... def __init__(self): self.hash = 0
... def __hash__(self): return self.hash
...
x = X()
d = {x: "This is x"}
x.hash = 1
for key in d: print(key, key in d)
...
<__main__.X object at 0x7f2d07c6f1c0> False
ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/OVVIKTG7CBN6BII4OBGIXWQJJXYCEO3I/
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/L7JDJFPJKYNHIA7QVYGC74SYAVODM2IX/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: A proposal to modify `None` so that it hashes to a constant
Wild suggestion: Make None.__hash__ writable. E.g. None.__hash__ = lambda : 0 # Currently raises AttributeError: 'NoneType' object attribute '__hash__' is read-only Best wishes Rob Cliffe On 01/12/2022 11:02, Oscar Benjamin wrote: On Thu, 1 Dec 2022 at 06:56, Chris Angelico wrote: On Thu, 1 Dec 2022 at 17:26, Yoni Lavi wrote: So it's not like it's even possible to require this generally for all objects. Well, I mean, in theory you could require that objects whose hash isn't otherwise defined get given the hash of zero. That doesn't violate any of the actual rules of hashes, but it does make those hashes quite suboptimal :) It's interesting how id() and hash() have opposite requirements (id must return a unique number among concurrently-existing objects, hash must return the same number among comparing-equal objects), yet a hash can be built on an id. This also demonstrates a significant reason why None is special: it's a singleton that only compares equal to itself. The reason for using id for hash in other cases is to make different instances have different hashes but there is only ever one instance of None. A singleton class can have a hash function that matches identity based equality without using id: any constant hash function will do. -- Oscar ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/MTTJJN2HHP3A264DN3CAWSXITHRMLLUW/ Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/XRASAGN52DAM7EAKJOYSWHJEKFAP2JPT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: A proposal to modify `None` so that it hashes to a constant
Thank you for this very clear analysis, Oscar.
It seems to me that this strengthens the OP's case. I am curious as to
whether others agree.
Best wishes
Rob Cliffe
On 30/11/2022 13:35, Oscar Benjamin wrote:
On Tue, 29 Nov 2022 at 23:46, Steven D'Aprano wrote:
On Tue, Nov 29, 2022 at 08:51:09PM -, Yoni Lavi wrote:
It does make your argument invalid though, since it's based on this
assumption that I was asking for a requirement on iteration order
(e.g. like dict's iteration order = insertion order guarantee), which
is not the case.
Yoni, I think this answer is disingenious.
I don't think it is disingenuous. There are just a lot of people
talking past each other and not quite understanding what each person
means because there is confusion about even the intended meaning of
terms like "deterministic". I will expand here with enough detail that
we should hopefully be able to avoid misunderstanding each other.
There are probably other places where you could find mentions of this
in the docs but I just took a quick look in the Python 3.5 docs
(before hash randomisation) to find this mention of dictionary
iteration order:
https://docs.python.org/3.5/library/stdtypes.html#dictionary-view-objects
What it says is
"""
Keys and values are iterated over in an arbitrary order which is
non-random, varies across Python implementations, and depends on the
dictionary’s history of insertions and deletions.
"""
The key point is the use of the term "non-random" which here is
intended to mean that although no particular ordering is guaranteed
you can expect to rerun the same program and get the same result
deterministically. A different version or implementation of Python
might give a different order but rerunning the same program twice
without changing anything should give the same result even if that
result depends in some way on the iteration order of some
dictionaries. I can't immediately find a similar statement about sets
but in practice the same behaviour applied to sets as well. Note
carefully that it is this *narrow* form of determinism that Yoni is
interested in.
Of course there are some caveats to this and the obvious one is that
this statement does not apply if there are some objects that use
identity based hashing so this is not deterministic:
class A:
def __init__(self, data):
self.data = data
def __repr__(self):
return 'A(%s)' % self.data
a1 = A(1)
a2 = A(2)
for a in {a1, a2}:
print(a)
Running this gives:
$ python3.5 t.py
A(2)
A(1)
$ python3.5 t.py
A(1)
A(2)
On the other hand if all of the hashes themselves are deterministic
then the program as a whole will be as well so this is deterministic:
class A:
def __init__(self, data):
self.data = data
def __repr__(self):
return 'A(%s)' % self.data
def __hash__(self):
return hash(self.data)
def __eq__(self):
return self.data == other.data
a1 = A(1)
a2 = A(2)
for a in {a1, a2}:
print(a)
$ python3.5 t.py
A(1)
A(2)
$ python3.5 t.py
A(1)
A(2)
So we have two classes of hashable objects:
1. Those with deterministic hash
2. Those with non-deterministic hash
A program that avoids depending on the iteration order of sets or
dicts containing objects with non-deterministic hash could be
deterministic. It is not the case that the program would depend on the
iteration order for its *correctness* but just that the behaviour of
the program is *reproducible* which is useful in various ways e.g.:
- You could say to someone else "run this code with CPython 3.5 and
you should be able to reproduce exactly what I see when I run the
program". It is common practice e.g. in scientific programming to
record things like random seeds so that someone else can precisely
reproduce the results shown in a paper or some other work and this in
general requires that it is at least possible to make everything
deterministic.
- When debugging it is useful to be able to reproduce an error
condition precisely. Debugging non-deterministic failures can be
extremely difficult. In the same way that you might want to reproduce
correctly functioning code it is also very useful to be able to
reproduce bugs.
I can list more examples but really it shouldn't be necessary to
justify from first principles why determinism in programming is
usually a good thing. There can be reasons sometimes why determinism
is undesired or cannot or should not be guaranteed. It should not be
controversial though to say that all things being equal determinism is
usually a desirable feature and should be preferred by default. I
don't think that the 3.5 docs I quoted above used the words
"non-random" casually: it was an intended feature and people were
aware that breaking that behaviour would be problematic in many
situations.
Of course in Python 3.6 this determinism was broken with the
introduction of hash randomisation for strings. It was
[Python-Dev] Re: [CVE-2022-37454] SHA3 vulnerability and upcoming Python patches for 3.7 - 3.10
Thank you all for your responses! Best, Mark ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/WWVXPV5BOFOHE6ENRNSLZAQAP22E5ZLK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] [CVE-2022-37454] SHA3 vulnerability and upcoming Python patches for 3.7 - 3.10
I’m looking for help understanding how Python will release fixes related to the SHA3 critical security vulnerability (CVE-2022-37454). I’ve tried to figure this out myself, but I’m far from a Python expert and I’m not sure where else I should look. Apologies in advance if this is the wrong place to ask - if it is, a redirect to the correct place would be most appreciated. Here’s what I’ve found so far: * Python versions 3.6 through 3.10 appear to be affected * 3.6 is end of life, so no fix is expected * A code fix appears to have been applied to 3.7 through 3.10 https://github.com/python/cpython/issues/98517 * 3.9 and 3.10 by default use OpenSSL1.1.1+ if it’s available, appearing to default to the builtin, vulnerable SHA3 implementation if OpenSSL is not found (if there’s an exception) * 3.9 introduced this change via bpo-37630 in release 3.9.0 beta1 * 3.10 appears to have had this functionality since it was originally released * 3.11 uses tiny_sha3 and AFAICT was never affected by the CVE But what I’m having trouble figuring out is when/how these fixes will become generally available and ready for users of Python to download. * When will patched releases for Python 3.7-3.10 be released? * If pending releases are not in the release pipeline, what other patching opportunities exist? Ultimately I’m trying to set patching expectations for my company’s engineering teams who are still running vulnerable versions of Python. More notes around what i’ve found, in case it helps clarify my questions: From the Python project GitHub I can see gh-98517 to fix the buffer overflow in Python’s internal _sha3 module (CVE-2022-37454) has been committed to the Python 3.7 - 3.10 branches. I understand that for Python releases 3.9 and 3.10 if one is using the OpenSSL 1.1.1+ sha3 modules instead of the internal _sha3 module that is already a mitigation. I also understand that Python 3.11 and later has switched to using tiny_sha3, and no longer relies on the vulnerable _sha3 module. Any information you could point me at would be most helpful. If there is a more ideal forum to raise this question, please redirect me there. Thank you in advance ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/K7IYZUGOOLCGKZOLCZ27RSWZ7OWIP575/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Annotating pure functions to improve inline caching/optimization
You should bring this up on discuss.python.org. It's not going to see much if any discussion here. Eric On 9/14/2022 10:05 AM, Philipp Burch wrote: Hello everyone, the docs on the upcoming 3.11 release state > This [specializing adaptive interpreter] also brings in another concept called inline caching, where Python caches the results of expensive operations directly in the bytecode. I wonder how this caching works, given that the dynamic nature means that virtually every operation could have side effects, causing wrong behaviour when cached. The only mitigation for this that I can imagine is that caching just occurs for basic operations defined in the standard library, where it is known that they are free of side effects or "pure". A web search did reveal some discussions[1,2] and a module related to dealing with pure functions, but, as far as I see, not related to optimization. As an example, consider a code like this: ```py @pure def rot_factor(angle_deg: float) -> complex: # This could also be a much more expensive calculation. return cmath.exp(angle_deg / 180 * cmath.pi * 1j) # ... res: List[Tuple(complex, complex, complex, float)] = [] for x in many: res.append(( x * rot_factor(90), x * rot_factor(45), x * rot_factor(-45), x * math.sin(math.pi/8), )) ``` The problem with this code is obvious, every loop iteration calls `rot_factor()` with 90, 45 and -45 and will get exactly the same set of results. The last factor might already be inline cached by the interpreter, since it probably knows that `math.pi` is a constant and `math.sin()` is a pure function. Optimizing this by hand (not considering a list comprehension or other more sophisticated improvements) is easy, but not very pretty: ```py f_p90 = rot_factor(90) f_p45 = rot_factor(45) f_m45 = rot_factor(-45) f_sin = math.sin(math.pi / 8) res: List[Tuple(complex, complex, complex, float)] = [] for x in many: res.append(( x * f_p90, x * f_p45, x * f_m45, x * f_sin, )) ``` I actually find myself often factoring such data out of loops in Python, whereas in C I would just leave that to the optimizer/compiler. An available option would be to use `@lru_cache` for `rot_factor()`, but this will still cause the same dictionary lookups in every iteration and it may not work at all in case the function argument(s) is/are not hashable. Now, if the interpreter understood the `@pure` decorator for `rot_factor()` indicated above would give it the same opportunity to cache the three results throughout the loop, basically creating the manually-optimized code above. For these completely static values, it could even precompute the results and integrate them into the bytecode. Has anything like this been considered already, or is the interpreter itself capable to perform such optimizations? Thanks and best regards, Philipp [1] 'pure' type annotation for mypy: https://github.com/python/mypy/issues/4468 [2] pure-func module: https://pypi.org/project/pure-func/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/XDYZRC6L7LBPE3T6RO6S5IVY3J6IMRSJ/ Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/A5CATJEKKNZN4XOWXVJ2ICK2Z4A3WFYU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] compiling errors, SSL
I have built this on systems at work, that are populated by CAD guys who have developed a good set of libraries to maintain in a linux distribution. Went without a hitch. I am trying to build this at home with an opensuse distribution. I am not trying to do any modifications to python, now or in the future. I am trying to build this as another software installation wants 3.7 or better and opensuse provided 3.6. I am stuck with a early compile error after the make command. I have downloaded, built and installed the openSSl.I have changed the ld.so.conf to include the newly built ssl in the list and re-ran ldconfig. Even though I have added the newly built ssl to the conf file a dump of the ldconfig does not show the locally built ssl libs. Does this process depend on LD_LIBRARY_PATH ? Defining LD_LIBRARY_PATH made no discernable difference. kevin@localhost:~/Sources/Python-3.10.5> sudo ldconfig -p | grep ssl [sudo] password for root: libssl3.so (libc6,x86-64) => /usr/lib64/libssl3.so libssl.so.1.1 (libc6,x86-64) => /usr/lib64/libssl.so.1.1 libevent_openssl-2.1.so.6 (libc6,x86-64) => /usr/lib64/libevent_openssl-2.1.so.6 The newly built ssl dir:kevin@localhost:~/Sources/Python-3.10.5> ls -lrt /usr/local/ssl total 40 drwxr-xr-x 1 root root 14 Jul 18 15:17 include drwxr-xr-x 1 root root 190 Jul 18 15:17 lib64 drwxr-xr-x 1 root root 30 Jul 18 15:17 bin drwxr-xr-x 1 root root 0 Jul 18 15:17 private drwxr-xr-x 1 root root 0 Jul 18 15:17 certs drwxr-xr-x 1 root root 36 Jul 18 15:17 misc -rw-r--r-- 1 root root 12292 Jul 18 15:17 openssl.cnf.dist -rw-r--r-- 1 root root 12292 Jul 18 15:17 openssl.cnf -rw-r--r-- 1 root root 412 Jul 18 15:17 ct_log_list.cnf.dist -rw-r--r-- 1 root root 412 Jul 18 15:17 ct_log_list.cnf drwxr-xr-x 1 root root 12 Jul 18 15:18 share I see in the web pages the known prerequisites and installed them.kevin@localhost:/usr/local/ssl/lib64> sudo zypper install python310-idle python310-devel python310-curses python310-dbm python310-tk kevin@localhost:/usr/local/ssl/lib64> sudo zypper install build-essential gdb lcov pkg-config libbz2-dev libffi-dev libgdbm-dev libgdbm-compat-dev liblzma-dev libncur ses5-dev libreadline6-dev libsqlite3-dev libssl-dev lzma lzma-dev tk-dev uuid-dev zlib1g-dev I see in the web pages this snip:Python build finished successfully! The necessary bits to build these optional modules were not found: _bz2 _dbm _gdbm _lzma _sqlite3 _ssl _tkinter _uuid readline zlib To find the necessary bits, look in setup.py in detect_modules() for the module's name.What is one supposed to do with detect_modules? Add something or remove something ? This is the config line: kevin@localhost:~/Sources/Python-3.10.5> ./configure --prefix=/usr/local --enable-optimizations --with-openssl=/usr/local/ssl --with-openssl-rpath=auto This is output from make: kevin@localhost:~/Sources/Python-3.10.5> make Rebuilding with profile guided optimizations: rm -f profile-clean-stamp make build_all CFLAGS_NODIST=" -fprofile-use -fprofile-correction" LDFLAGS_NODIST="" make[1]: Entering directory '/home/kevin/Sources/Python-3.10.5' gcc -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fno-semantic-interposition -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-miss ing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden -fprofile-use -fprofile-correction -I./Include/internal -I. -I./Include -DPy_BUILD_CORE \ -DABIFLAGS='""' \ -DMULTIARCH=\"x86_64-linux-gnu\" \ -o Python/sysmodule.o ./Python/sysmodule.c gcc -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fno-semantic-interposition -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-miss ing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden -fprofile-use -fprofile-correction -I./Include/internal -I. -I./Include -DPy_BUILD_CORE \ -DSOABI='"cpython-310-x86_64-linux-gnu"' \ -o Python/dynload_shlib.o ./Python/dynload_shlib.c gcc -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fno-semantic-interposition -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-miss ing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden -fprofile-use -fprofile-correction -I./Include/internal -I. -I./Include -DPy_BUILD_CORE -o Mo dules/config.o Modules/config.c gcc -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fno-semantic-interposition -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-miss ing-field-initializers -Werror=implicit-function-declaration -fvisibility=hidden -fprofile-use -fprofile-corre
[Python-Dev] Re: [SPAM] Re: Switching to Discourse
On 15/07/2022 16:09, Rob Boehne via Python-Dev wrote: 100% agree – dealing with 5 or more platforms for discussion groups is a nightmare, and I tend not to follow any of them as closely for that reason. I agree. I don't mind having to use Discourse if I want to take part in a discussion but 99% of the time I just want to keep up to date with what is going on. In that case I want the information to come to me - I don't want to have to hunt for it. Can there be an RSS feed for everything, not just PEPs? Phil From: Skip Montanaro Date: Friday, July 15, 2022 at 9:26 AM To: Petr Viktorin Cc: python-dev@python.org Subject: [SPAM] [Python-Dev] Re: Switching to Discourse The discuss.python.org<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdiscuss.python.org%2F=05%7C01%7Crobb%40datalogics.com%7C241da9f510764bf2ba8608da666df61c%7Cfc3d8cdfd6994f23ae232659c3da4749%7C0%7C1%7C637934919720701261%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C=DThYDKE32GfsdNG9hlvthdjnl%2B%2BmnvPUj3lM9SnsjbE%3D=0> experiment has been going on for quite a while, and while the platform is not without its issues, we consider it a success. The Core Development category is busier than python-dev. According to staff, discuss.python.org<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdiscuss.python.org%2F=05%7C01%7Crobb%40datalogics.com%7C241da9f510764bf2ba8608da666df61c%7Cfc3d8cdfd6994f23ae232659c3da4749%7C0%7C1%7C637934919720701261%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C=DThYDKE32GfsdNG9hlvthdjnl%2B%2BmnvPUj3lM9SnsjbE%3D=0> is much easier to moderate.. If you're following python-dev but not discuss.python.org<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdiscuss.python.org%2F=05%7C01%7Crobb%40datalogics.com%7C241da9f510764bf2ba8608da666df61c%7Cfc3d8cdfd6994f23ae232659c3da4749%7C0%7C1%7C637934919720701261%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C=DThYDKE32GfsdNG9hlvthdjnl%2B%2BmnvPUj3lM9SnsjbE%3D=0>, you're missing out. Personally, I think you are focused too narrowly and aren't seeing the forest for the trees. Email protocols were long ago standardized. As a result, people can use any of a large number of applications to read and organize their email. To my knowledge, there is no standardization amongst the various forum tools out there. I'm not suggesting discuss is necessarily better or worse than other (often not open source) forum tools, but each one implements its own walled garden. I'm referring more broadly than just Python, or even Python development, though even within the Python community it's now difficult to manage/monitor all the various discussion sources (email, discuss, GitHub, Stack Overflow, ...) Get off my lawn! ;-) Skip, kinda glad he's retired now... _______ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5R376DBMGYMJCJTXCZPNRUBNUPV5OSAJ/ Code of Conduct: http://python.org/psf/codeofconduct/ _______ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/PZ246BKJSWB3AQZSYMWUTX35RMWCPPQ6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Switching to Discourse
On Fri, Jul 15, 2022 at 9:33 AM Skip Montanaro wrote: > Email protocols were long ago standardized. As a result, people can use > any of a large number of applications to read and organize their email. To > my knowledge, there is no standardization amongst the various forum tools > out there. > While I understand and somewhat agree with you, Skip, there is a "hidden" feature of Discourse that does make it a little easier to track many different forums: You can add ".rss" to various URLs and get an RSS feed for that topic/channel/etc. e.g. the WebAssembly group is: https://discuss.python.org/c/webassembly/28 And its corresponding RSS feed is: https://discuss.python.org/c/webassembly/28.rss Cheers, Peter _______ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/MZMYCTFGLUKFD5JGE7XC5JGQ6NAIDTY3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [SPAM] Re: Switching to Discourse
100% agree – dealing with 5 or more platforms for discussion groups is a nightmare, and I tend not to follow any of them as closely for that reason. From: Skip Montanaro Date: Friday, July 15, 2022 at 9:26 AM To: Petr Viktorin Cc: python-dev@python.org Subject: [SPAM] [Python-Dev] Re: Switching to Discourse The discuss.python.org<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdiscuss.python.org%2F=05%7C01%7Crobb%40datalogics.com%7C241da9f510764bf2ba8608da666df61c%7Cfc3d8cdfd6994f23ae232659c3da4749%7C0%7C1%7C637934919720701261%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C=DThYDKE32GfsdNG9hlvthdjnl%2B%2BmnvPUj3lM9SnsjbE%3D=0> experiment has been going on for quite a while, and while the platform is not without its issues, we consider it a success. The Core Development category is busier than python-dev. According to staff, discuss.python.org<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdiscuss.python.org%2F=05%7C01%7Crobb%40datalogics.com%7C241da9f510764bf2ba8608da666df61c%7Cfc3d8cdfd6994f23ae232659c3da4749%7C0%7C1%7C637934919720701261%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C=DThYDKE32GfsdNG9hlvthdjnl%2B%2BmnvPUj3lM9SnsjbE%3D=0> is much easier to moderate.. If you're following python-dev but not discuss.python.org<https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdiscuss.python.org%2F=05%7C01%7Crobb%40datalogics.com%7C241da9f510764bf2ba8608da666df61c%7Cfc3d8cdfd6994f23ae232659c3da4749%7C0%7C1%7C637934919720701261%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C=DThYDKE32GfsdNG9hlvthdjnl%2B%2BmnvPUj3lM9SnsjbE%3D=0>, you're missing out. Personally, I think you are focused too narrowly and aren't seeing the forest for the trees. Email protocols were long ago standardized. As a result, people can use any of a large number of applications to read and organize their email. To my knowledge, there is no standardization amongst the various forum tools out there. I'm not suggesting discuss is necessarily better or worse than other (often not open source) forum tools, but each one implements its own walled garden. I'm referring more broadly than just Python, or even Python development, though even within the Python community it's now difficult to manage/monitor all the various discussion sources (email, discuss, GitHub, Stack Overflow, ...) Get off my lawn! ;-) Skip, kinda glad he's retired now... _______ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5R376DBMGYMJCJTXCZPNRUBNUPV5OSAJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Python 3.11 bytecode and exception table
Hi Matthieu, Yes I am interested. Please ping me for PR reviews or any progress updates. Thanks Irit > On 5 Jul 2022, at 20:27, Matthieu Dartiailh wrote: > > Hi Irit, hi Patrick, > > Thanks for your quick answers. > > First thanks Patrick, it seems I went back to the stable docs at one point > without noticing it and hence I missed the new opcodes. > > Thanks Irit for the clarification regarding the pseudo-instructions use in > dis. > > Regarding the existence of nested try/except I believe a we could have 2 > SETUP_* followed by 2 POP_BLOCK so I am not sure what issue you see there. > However if we can have exception tables with two rows such as (1, 3, ...) and > (2, 4, ...) then yes I will have an issue. I guess I will have to try > implementing something and try to roundtrip on as many examples as possible. > Would you be interested in being posted about my progress ? > > Best > > Matthieu ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/B2G4LQ3WPAYEUEZX6LURWO336EMZTPC2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Python 3.11 bytecode and exception table
Hi Matthieu, The dis output for this function in 3.12 is the same as it is in 3.11. The pseudo-instructions are emitted by the compiler's codegen stage, but never make it to compiled bytecode. They are removed or replaced by real opcodes before the code object is created. The recent change to the dis module that you mentioned did not change how the disassembly of bytecode gets displayed. Rather, it added the pseudo-instructions to the opcodes list so that we have access to their mnemonics from python. This is a step towards exposing intermediate compilation steps to python (for unit tests, etc). BTW - part of this will require writing some test utilities for cpython that let us specify and compare opcode sequences, similar to what you have in bytecode. As for deconstructing the exception table and planting the pseudo instructions back into the code - it would be nice if dis could do that, but we may need to settle for an approximation because I'm not sure the exact block structure can be reliably reconstructed from the exception table at the moment. I may be wrong. Having a SETUP_*/POP_BLOCK for each line in the exception table is not going to be correct - there can be nested try-except blocks, for instance, and even without them the compiler can emit the code of an except block in non-contiguous order (in https://github.com/python/cpython/pull/93622 I fixed one of those cases to reduce the size of the exception table, but it wasn't a correctness bug). Irit On Tue, Jul 5, 2022 at 9:27 AM Matthieu Dartiailh wrote: > Hi all, > > I am the current maintainer of bytecode ( > https://github.com/MatthieuDartiailh/bytecode) which is a library to > perform assembly and disassembly of Python bytecode. The library was > created by V. Stinner. > > I started looking in Python 3.11 support in bytecode, I read > Objects/exception_handling_notes.txt and I have a couple of questions > regarding the exception table: > > Currently bytecode exposes three level of abstractions: > - the concrete level in which one deals with instruction offset for > jumps and explicit indexing into the known constants and names > - the bytecode level which uses labels for jumps and allow non integer > argument to instructions > - the cfg level which provides basic blocks delineation over the > bytecode level > > So my first idea was to directly expose the unpacked exception table > (start, stop, target, stack_depth, last_i) at the concrete level and use > pseudo-instruction and labels at the bytecode level. At this point of my > reflections, I saw > https://github.com/python/cpython/commit/c57aad777afc6c0b382981ee9e4bc94c03bf5f68 > about adding pseudo-instructionto dis output in 3.12 and though it would > line up quite nicely. Reading through, I got curious about how SETUP_WITH > handled popping one extra item from the stack so I went to look at dis > results on a couple of small examples. I tried on 3.10 and 3.11b3 (for some > reasons I cannot compile main at a391b74d on windows). > > I looked at simple things and got a bit surprised: > > Disassembling: > def f(): > try: > a = 1 > except: > raise > > I get on 3.11: > 1 0 RESUME 0 > > 2 2 NOP > > 3 4 LOAD_CONST 1 (1) > 6 STORE_FAST 0 (a) > 8 LOAD_CONST 0 (None) > 10 RETURN_VALUE > >> 12 PUSH_EXC_INFO > > 4 14 POP_TOP > > 5 16 RAISE_VARARGS0 > >> 18 COPY 3 > 20 POP_EXCEPT > 22 RERAISE 1 > ExceptionTable: > 4 to 6 -> 12 [0] > 12 to 16 -> 18 [1] lasti > > On 3.10: > 2 0 SETUP_FINALLY5 (to 12) > > 3 2 LOAD_CONST 1 (1) > 4 STORE_FAST 0 (a) > 6 POP_BLOCK > 8 LOAD_CONST 0 (None) > 10 RETURN_VALUE > > 4 >> 12 POP_TOP > 14 POP_TOP > 16 POP_TOP > > 5 18 RAISE_VARARGS0 > > This surprised me on two levels: > - first I have never seen the RESUME opcode and it is currently not > documented > - my second surprise comes from the second entry in the exception table. > At first I failed to see why it was needed but writing this I realize it > corresponds to the explicit handling of exception propagation to the > caller. Since I cannot compile 3.12 ATM I am wondering how this plays with > pseudo-instruction: in particular are pseudo-instructions generated for all > entries in the exception table ? > > My initial idea was to have a SETUP_FINALLY/SETUP
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2022-06-10 - 2022-06-17)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7146 ( +0)
closed 51841 ( +0)
total 58987 ( +0)
Open issues with patches: 2890
Most recent 15 issues with no replies (15)
==
#47258: Python 3.10 hang at exit in drop_gil() (due to resource warnin
https://bugs.python.org/issue47258
#47256: re: limit the maximum capturing group to 1,073,741,823, reduce
https://bugs.python.org/issue47256
#47253: LOAD_GLOBAL instruction with wrong source position
https://bugs.python.org/issue47253
#47252: socket.makefile documentation is missing data regarding the 'b
https://bugs.python.org/issue47252
#47251: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE
https://bugs.python.org/issue47251
#47244: email.utils.formataddr does not respect double spaces
https://bugs.python.org/issue47244
#47242: Annoying white bar in IDLE (line 457 in sidebar.py)
https://bugs.python.org/issue47242
#47241: [C API] Move the PyCodeObject structure to the internal C API
https://bugs.python.org/issue47241
#47238: Python threading.Event().wait() depends on the system time
https://bugs.python.org/issue47238
#47236: Document types.CodeType.replace() changes about co_exceptionta
https://bugs.python.org/issue47236
#47228: Document that na??ve datetime objects represent local time
https://bugs.python.org/issue47228
#47222: subprocess.Popen() should allow capturing output and sending i
https://bugs.python.org/issue47222
#47219: asyncio with two interpreter instances
https://bugs.python.org/issue47219
#47218: adding name to lzmafile
https://bugs.python.org/issue47218
#47217: adding name to BZ2File
https://bugs.python.org/issue47217
Most recent 15 issues waiting for review (15)
=
#47256: re: limit the maximum capturing group to 1,073,741,823, reduce
https://bugs.python.org/issue47256
#47255: Many broken :meth: roles in the docs
https://bugs.python.org/issue47255
#47254: enhanced dir?
https://bugs.python.org/issue47254
#47251: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE
https://bugs.python.org/issue47251
#47243: Duplicate entry in 'Objects/unicodetype_db.h'
https://bugs.python.org/issue47243
#47233: show_caches option affects code positions reported by dis.get_
https://bugs.python.org/issue47233
#47222: subprocess.Popen() should allow capturing output and sending i
https://bugs.python.org/issue47222
#47218: adding name to lzmafile
https://bugs.python.org/issue47218
#47217: adding name to BZ2File
https://bugs.python.org/issue47217
#47216: adding mtime option to gzip open()
https://bugs.python.org/issue47216
#47215: Add "unstable" frame stack api
https://bugs.python.org/issue47215
#47208: Support libffi implementations that cannot support invocations
https://bugs.python.org/issue47208
#47205: posix.sched_{get|set}affinity(-1) no longer returns ProcessLoo
https://bugs.python.org/issue47205
#47200: Add ZipInfo.mode property
https://bugs.python.org/issue47200
#47199: multiprocessing: micro-optimize Connection.send_bytes() method
https://bugs.python.org/issue47199
_______
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/PNMW3MJ2K6FWBD3EOZOXF6QWEVWARHYM/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2022-06-03 - 2022-06-10)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7146 ( +0)
closed 51841 ( +0)
total 58987 ( +0)
Open issues with patches: 2890
Most recent 15 issues with no replies (15)
==
#47258: Python 3.10 hang at exit in drop_gil() (due to resource warnin
https://bugs.python.org/issue47258
#47256: re: limit the maximum capturing group to 1,073,741,823, reduce
https://bugs.python.org/issue47256
#47253: LOAD_GLOBAL instruction with wrong source position
https://bugs.python.org/issue47253
#47252: socket.makefile documentation is missing data regarding the 'b
https://bugs.python.org/issue47252
#47251: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE
https://bugs.python.org/issue47251
#47244: email.utils.formataddr does not respect double spaces
https://bugs.python.org/issue47244
#47242: Annoying white bar in IDLE (line 457 in sidebar.py)
https://bugs.python.org/issue47242
#47241: [C API] Move the PyCodeObject structure to the internal C API
https://bugs.python.org/issue47241
#47238: Python threading.Event().wait() depends on the system time
https://bugs.python.org/issue47238
#47236: Document types.CodeType.replace() changes about co_exceptionta
https://bugs.python.org/issue47236
#47228: Document that na??ve datetime objects represent local time
https://bugs.python.org/issue47228
#47222: subprocess.Popen() should allow capturing output and sending i
https://bugs.python.org/issue47222
#47219: asyncio with two interpreter instances
https://bugs.python.org/issue47219
#47218: adding name to lzmafile
https://bugs.python.org/issue47218
#47217: adding name to BZ2File
https://bugs.python.org/issue47217
Most recent 15 issues waiting for review (15)
=
#47256: re: limit the maximum capturing group to 1,073,741,823, reduce
https://bugs.python.org/issue47256
#47255: Many broken :meth: roles in the docs
https://bugs.python.org/issue47255
#47254: enhanced dir?
https://bugs.python.org/issue47254
#47251: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE
https://bugs.python.org/issue47251
#47243: Duplicate entry in 'Objects/unicodetype_db.h'
https://bugs.python.org/issue47243
#47233: show_caches option affects code positions reported by dis.get_
https://bugs.python.org/issue47233
#47222: subprocess.Popen() should allow capturing output and sending i
https://bugs.python.org/issue47222
#47218: adding name to lzmafile
https://bugs.python.org/issue47218
#47217: adding name to BZ2File
https://bugs.python.org/issue47217
#47216: adding mtime option to gzip open()
https://bugs.python.org/issue47216
#47215: Add "unstable" frame stack api
https://bugs.python.org/issue47215
#47208: Support libffi implementations that cannot support invocations
https://bugs.python.org/issue47208
#47205: posix.sched_{get|set}affinity(-1) no longer returns ProcessLoo
https://bugs.python.org/issue47205
#47200: Add ZipInfo.mode property
https://bugs.python.org/issue47200
#47199: multiprocessing: micro-optimize Connection.send_bytes() method
https://bugs.python.org/issue47199
_______
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/WB3V7R2SIVLOHMBF4CTOUS6236J5LKAS/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2022-05-27 - 2022-06-03)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7146 ( +0)
closed 51841 ( +0)
total 58987 ( +0)
Open issues with patches: 2890
Most recent 15 issues with no replies (15)
==
#47258: Python 3.10 hang at exit in drop_gil() (due to resource warnin
https://bugs.python.org/issue47258
#47256: re: limit the maximum capturing group to 1,073,741,823, reduce
https://bugs.python.org/issue47256
#47253: LOAD_GLOBAL instruction with wrong source position
https://bugs.python.org/issue47253
#47252: socket.makefile documentation is missing data regarding the 'b
https://bugs.python.org/issue47252
#47251: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE
https://bugs.python.org/issue47251
#47244: email.utils.formataddr does not respect double spaces
https://bugs.python.org/issue47244
#47242: Annoying white bar in IDLE (line 457 in sidebar.py)
https://bugs.python.org/issue47242
#47241: [C API] Move the PyCodeObject structure to the internal C API
https://bugs.python.org/issue47241
#47238: Python threading.Event().wait() depends on the system time
https://bugs.python.org/issue47238
#47236: Document types.CodeType.replace() changes about co_exceptionta
https://bugs.python.org/issue47236
#47228: Document that na??ve datetime objects represent local time
https://bugs.python.org/issue47228
#47222: subprocess.Popen() should allow capturing output and sending i
https://bugs.python.org/issue47222
#47219: asyncio with two interpreter instances
https://bugs.python.org/issue47219
#47218: adding name to lzmafile
https://bugs.python.org/issue47218
#47217: adding name to BZ2File
https://bugs.python.org/issue47217
Most recent 15 issues waiting for review (15)
=
#47256: re: limit the maximum capturing group to 1,073,741,823, reduce
https://bugs.python.org/issue47256
#47255: Many broken :meth: roles in the docs
https://bugs.python.org/issue47255
#47254: enhanced dir?
https://bugs.python.org/issue47254
#47251: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE
https://bugs.python.org/issue47251
#47243: Duplicate entry in 'Objects/unicodetype_db.h'
https://bugs.python.org/issue47243
#47233: show_caches option affects code positions reported by dis.get_
https://bugs.python.org/issue47233
#47222: subprocess.Popen() should allow capturing output and sending i
https://bugs.python.org/issue47222
#47218: adding name to lzmafile
https://bugs.python.org/issue47218
#47217: adding name to BZ2File
https://bugs.python.org/issue47217
#47216: adding mtime option to gzip open()
https://bugs.python.org/issue47216
#47215: Add "unstable" frame stack api
https://bugs.python.org/issue47215
#47208: Support libffi implementations that cannot support invocations
https://bugs.python.org/issue47208
#47205: posix.sched_{get|set}affinity(-1) no longer returns ProcessLoo
https://bugs.python.org/issue47205
#47200: Add ZipInfo.mode property
https://bugs.python.org/issue47200
#47199: multiprocessing: micro-optimize Connection.send_bytes() method
https://bugs.python.org/issue47199
_______
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/7ENQYJII52HGDBH3IYWHYE26WKUSWVGR/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2022-05-20 - 2022-05-27)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7146 ( +0)
closed 51841 ( +0)
total 58987 ( +0)
Open issues with patches: 2890
Most recent 15 issues with no replies (15)
==
#47258: Python 3.10 hang at exit in drop_gil() (due to resource warnin
https://bugs.python.org/issue47258
#47256: re: limit the maximum capturing group to 1,073,741,823, reduce
https://bugs.python.org/issue47256
#47253: LOAD_GLOBAL instruction with wrong source position
https://bugs.python.org/issue47253
#47252: socket.makefile documentation is missing data regarding the 'b
https://bugs.python.org/issue47252
#47251: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE
https://bugs.python.org/issue47251
#47244: email.utils.formataddr does not respect double spaces
https://bugs.python.org/issue47244
#47242: Annoying white bar in IDLE (line 457 in sidebar.py)
https://bugs.python.org/issue47242
#47241: [C API] Move the PyCodeObject structure to the internal C API
https://bugs.python.org/issue47241
#47238: Python threading.Event().wait() depends on the system time
https://bugs.python.org/issue47238
#47236: Document types.CodeType.replace() changes about co_exceptionta
https://bugs.python.org/issue47236
#47228: Document that na??ve datetime objects represent local time
https://bugs.python.org/issue47228
#47222: subprocess.Popen() should allow capturing output and sending i
https://bugs.python.org/issue47222
#47219: asyncio with two interpreter instances
https://bugs.python.org/issue47219
#47218: adding name to lzmafile
https://bugs.python.org/issue47218
#47217: adding name to BZ2File
https://bugs.python.org/issue47217
Most recent 15 issues waiting for review (15)
=
#47256: re: limit the maximum capturing group to 1,073,741,823, reduce
https://bugs.python.org/issue47256
#47255: Many broken :meth: roles in the docs
https://bugs.python.org/issue47255
#47254: enhanced dir?
https://bugs.python.org/issue47254
#47251: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE
https://bugs.python.org/issue47251
#47243: Duplicate entry in 'Objects/unicodetype_db.h'
https://bugs.python.org/issue47243
#47233: show_caches option affects code positions reported by dis.get_
https://bugs.python.org/issue47233
#47222: subprocess.Popen() should allow capturing output and sending i
https://bugs.python.org/issue47222
#47218: adding name to lzmafile
https://bugs.python.org/issue47218
#47217: adding name to BZ2File
https://bugs.python.org/issue47217
#47216: adding mtime option to gzip open()
https://bugs.python.org/issue47216
#47215: Add "unstable" frame stack api
https://bugs.python.org/issue47215
#47208: Support libffi implementations that cannot support invocations
https://bugs.python.org/issue47208
#47205: posix.sched_{get|set}affinity(-1) no longer returns ProcessLoo
https://bugs.python.org/issue47205
#47200: Add ZipInfo.mode property
https://bugs.python.org/issue47200
#47199: multiprocessing: micro-optimize Connection.send_bytes() method
https://bugs.python.org/issue47199
_______
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/EVJ3AP6NBD5OGKSDMY7H3QFZKDO77HSH/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2022-05-13 - 2022-05-20)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7146 ( +0)
closed 51841 ( +0)
total 58987 ( +0)
Open issues with patches: 2890
Most recent 15 issues with no replies (15)
==
#47258: Python 3.10 hang at exit in drop_gil() (due to resource warnin
https://bugs.python.org/issue47258
#47256: re: limit the maximum capturing group to 1,073,741,823, reduce
https://bugs.python.org/issue47256
#47253: LOAD_GLOBAL instruction with wrong source position
https://bugs.python.org/issue47253
#47252: socket.makefile documentation is missing data regarding the 'b
https://bugs.python.org/issue47252
#47251: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE
https://bugs.python.org/issue47251
#47244: email.utils.formataddr does not respect double spaces
https://bugs.python.org/issue47244
#47242: Annoying white bar in IDLE (line 457 in sidebar.py)
https://bugs.python.org/issue47242
#47241: [C API] Move the PyCodeObject structure to the internal C API
https://bugs.python.org/issue47241
#47238: Python threading.Event().wait() depends on the system time
https://bugs.python.org/issue47238
#47236: Document types.CodeType.replace() changes about co_exceptionta
https://bugs.python.org/issue47236
#47228: Document that na??ve datetime objects represent local time
https://bugs.python.org/issue47228
#47222: subprocess.Popen() should allow capturing output and sending i
https://bugs.python.org/issue47222
#47219: asyncio with two interpreter instances
https://bugs.python.org/issue47219
#47218: adding name to lzmafile
https://bugs.python.org/issue47218
#47217: adding name to BZ2File
https://bugs.python.org/issue47217
Most recent 15 issues waiting for review (15)
=
#47256: re: limit the maximum capturing group to 1,073,741,823, reduce
https://bugs.python.org/issue47256
#47255: Many broken :meth: roles in the docs
https://bugs.python.org/issue47255
#47254: enhanced dir?
https://bugs.python.org/issue47254
#47251: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE
https://bugs.python.org/issue47251
#47243: Duplicate entry in 'Objects/unicodetype_db.h'
https://bugs.python.org/issue47243
#47233: show_caches option affects code positions reported by dis.get_
https://bugs.python.org/issue47233
#47222: subprocess.Popen() should allow capturing output and sending i
https://bugs.python.org/issue47222
#47218: adding name to lzmafile
https://bugs.python.org/issue47218
#47217: adding name to BZ2File
https://bugs.python.org/issue47217
#47216: adding mtime option to gzip open()
https://bugs.python.org/issue47216
#47215: Add "unstable" frame stack api
https://bugs.python.org/issue47215
#47208: Support libffi implementations that cannot support invocations
https://bugs.python.org/issue47208
#47205: posix.sched_{get|set}affinity(-1) no longer returns ProcessLoo
https://bugs.python.org/issue47205
#47200: Add ZipInfo.mode property
https://bugs.python.org/issue47200
#47199: multiprocessing: micro-optimize Connection.send_bytes() method
https://bugs.python.org/issue47199
_______
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/7GFR3OYQFIOXBUORFPXGSBFERMZ5RHIX/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2022-05-06 - 2022-05-13)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7146 ( +0)
closed 51841 ( +0)
total 58987 ( +0)
Open issues with patches: 2890
Most recent 15 issues with no replies (15)
==
#47258: Python 3.10 hang at exit in drop_gil() (due to resource warnin
https://bugs.python.org/issue47258
#47256: re: limit the maximum capturing group to 1,073,741,823, reduce
https://bugs.python.org/issue47256
#47253: LOAD_GLOBAL instruction with wrong source position
https://bugs.python.org/issue47253
#47252: socket.makefile documentation is missing data regarding the 'b
https://bugs.python.org/issue47252
#47251: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE
https://bugs.python.org/issue47251
#47244: email.utils.formataddr does not respect double spaces
https://bugs.python.org/issue47244
#47242: Annoying white bar in IDLE (line 457 in sidebar.py)
https://bugs.python.org/issue47242
#47241: [C API] Move the PyCodeObject structure to the internal C API
https://bugs.python.org/issue47241
#47238: Python threading.Event().wait() depends on the system time
https://bugs.python.org/issue47238
#47236: Document types.CodeType.replace() changes about co_exceptionta
https://bugs.python.org/issue47236
#47228: Document that na??ve datetime objects represent local time
https://bugs.python.org/issue47228
#47222: subprocess.Popen() should allow capturing output and sending i
https://bugs.python.org/issue47222
#47219: asyncio with two interpreter instances
https://bugs.python.org/issue47219
#47218: adding name to lzmafile
https://bugs.python.org/issue47218
#47217: adding name to BZ2File
https://bugs.python.org/issue47217
Most recent 15 issues waiting for review (15)
=
#47256: re: limit the maximum capturing group to 1,073,741,823, reduce
https://bugs.python.org/issue47256
#47255: Many broken :meth: roles in the docs
https://bugs.python.org/issue47255
#47254: enhanced dir?
https://bugs.python.org/issue47254
#47251: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE
https://bugs.python.org/issue47251
#47243: Duplicate entry in 'Objects/unicodetype_db.h'
https://bugs.python.org/issue47243
#47233: show_caches option affects code positions reported by dis.get_
https://bugs.python.org/issue47233
#47222: subprocess.Popen() should allow capturing output and sending i
https://bugs.python.org/issue47222
#47218: adding name to lzmafile
https://bugs.python.org/issue47218
#47217: adding name to BZ2File
https://bugs.python.org/issue47217
#47216: adding mtime option to gzip open()
https://bugs.python.org/issue47216
#47215: Add "unstable" frame stack api
https://bugs.python.org/issue47215
#47208: Support libffi implementations that cannot support invocations
https://bugs.python.org/issue47208
#47205: posix.sched_{get|set}affinity(-1) no longer returns ProcessLoo
https://bugs.python.org/issue47205
#47200: Add ZipInfo.mode property
https://bugs.python.org/issue47200
#47199: multiprocessing: micro-optimize Connection.send_bytes() method
https://bugs.python.org/issue47199
_______
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/LEYLS2TYSZ4NVDFLTDSQUT25C2Y4QG2O/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2022-04-29 - 2022-05-06)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7146 ( +0)
closed 51841 ( +0)
total 58987 ( +0)
Open issues with patches: 2890
Most recent 15 issues with no replies (15)
==
#47258: Python 3.10 hang at exit in drop_gil() (due to resource warnin
https://bugs.python.org/issue47258
#47256: re: limit the maximum capturing group to 1,073,741,823, reduce
https://bugs.python.org/issue47256
#47253: LOAD_GLOBAL instruction with wrong source position
https://bugs.python.org/issue47253
#47252: socket.makefile documentation is missing data regarding the 'b
https://bugs.python.org/issue47252
#47251: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE
https://bugs.python.org/issue47251
#47244: email.utils.formataddr does not respect double spaces
https://bugs.python.org/issue47244
#47242: Annoying white bar in IDLE (line 457 in sidebar.py)
https://bugs.python.org/issue47242
#47241: [C API] Move the PyCodeObject structure to the internal C API
https://bugs.python.org/issue47241
#47238: Python threading.Event().wait() depends on the system time
https://bugs.python.org/issue47238
#47236: Document types.CodeType.replace() changes about co_exceptionta
https://bugs.python.org/issue47236
#47228: Document that na??ve datetime objects represent local time
https://bugs.python.org/issue47228
#47222: subprocess.Popen() should allow capturing output and sending i
https://bugs.python.org/issue47222
#47219: asyncio with two interpreter instances
https://bugs.python.org/issue47219
#47218: adding name to lzmafile
https://bugs.python.org/issue47218
#47217: adding name to BZ2File
https://bugs.python.org/issue47217
Most recent 15 issues waiting for review (15)
=
#47256: re: limit the maximum capturing group to 1,073,741,823, reduce
https://bugs.python.org/issue47256
#47255: Many broken :meth: roles in the docs
https://bugs.python.org/issue47255
#47254: enhanced dir?
https://bugs.python.org/issue47254
#47251: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE
https://bugs.python.org/issue47251
#47243: Duplicate entry in 'Objects/unicodetype_db.h'
https://bugs.python.org/issue47243
#47233: show_caches option affects code positions reported by dis.get_
https://bugs.python.org/issue47233
#47222: subprocess.Popen() should allow capturing output and sending i
https://bugs.python.org/issue47222
#47218: adding name to lzmafile
https://bugs.python.org/issue47218
#47217: adding name to BZ2File
https://bugs.python.org/issue47217
#47216: adding mtime option to gzip open()
https://bugs.python.org/issue47216
#47215: Add "unstable" frame stack api
https://bugs.python.org/issue47215
#47208: Support libffi implementations that cannot support invocations
https://bugs.python.org/issue47208
#47205: posix.sched_{get|set}affinity(-1) no longer returns ProcessLoo
https://bugs.python.org/issue47205
#47200: Add ZipInfo.mode property
https://bugs.python.org/issue47200
#47199: multiprocessing: micro-optimize Connection.send_bytes() method
https://bugs.python.org/issue47199
_______
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/NPP3DJ5OLV6UWD76FQUMFYU7OPHGZIVL/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Proto-PEP part 4: The wonderful third option
Hi Paul, On Sun, May 1, 2022 at 3:47 PM Paul Bryan wrote: > > Can someone state what's currently unpalatable about 649? It seemed to > address the forward-referencing issues, certainly all of the cases I was > expecting to encounter. Broadly speaking I think there are 3-4 issues to resolve as part of moving forward with PEP 649: 1) Class decorators (the most relevant being @dataclass) that need to inspect something about annotations, and because they run right after class definition, the laziness of PEP 649 is not sufficient to allow forward references to work. Roughly in a similar boat are `if TYPE_CHECKING` use cases where annotations reference names that aren't ever imported. 2) "Documentation" use cases (e.g. built-in "help()") that really prefer access to the original text of the annotation, not the repr() of the fully-evaluated object -- this is especially relevant if the annotation text is a nice short meaningful type alias name, and the actual value is some massive unreadable Union type. 3) Ensuring that we don't regress import performance too much. 4) A solid migration path from the status quo (where many people have already started adopting PEP 563) to the best future end state. Particularly for libraries that want to support the full range of supported Python versions. Issues (1) and (2) can be resolved under PEP 649 by providing a way to run the __co_annotations__ function without erroring on not-yet-defined names, I think we have agreement on a plan there. Performance of the latest PEP 649 reference implementation does not look too bad relative to PEP 563 in my experiments, so I think this is not an issue -- there are ideas for how we could reduce the overhead even further. The migration path is maybe the most difficult issue -- specifically how to weigh "medium-term migration pain" (which under some proposals might last for years) vs "best long-term end state." Still working on reaching consensus there, but we have options to choose from. Expect a more thorough proposal (probably in the form of an update to PEP 649?) sometime after PyCon. Carl _______ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/M3FB6QHB2IOMEXDGHFRHYQEDR3KGZPHG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2022-04-22 - 2022-04-29)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7146 ( +0)
closed 51841 ( +0)
total 58987 ( +0)
Open issues with patches: 2890
Most recent 15 issues with no replies (15)
==
#47258: Python 3.10 hang at exit in drop_gil() (due to resource warnin
https://bugs.python.org/issue47258
#47256: re: limit the maximum capturing group to 1,073,741,823, reduce
https://bugs.python.org/issue47256
#47253: LOAD_GLOBAL instruction with wrong source position
https://bugs.python.org/issue47253
#47252: socket.makefile documentation is missing data regarding the 'b
https://bugs.python.org/issue47252
#47251: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE
https://bugs.python.org/issue47251
#47244: email.utils.formataddr does not respect double spaces
https://bugs.python.org/issue47244
#47242: Annoying white bar in IDLE (line 457 in sidebar.py)
https://bugs.python.org/issue47242
#47241: [C API] Move the PyCodeObject structure to the internal C API
https://bugs.python.org/issue47241
#47238: Python threading.Event().wait() depends on the system time
https://bugs.python.org/issue47238
#47236: Document types.CodeType.replace() changes about co_exceptionta
https://bugs.python.org/issue47236
#47228: Document that na??ve datetime objects represent local time
https://bugs.python.org/issue47228
#47222: subprocess.Popen() should allow capturing output and sending i
https://bugs.python.org/issue47222
#47219: asyncio with two interpreter instances
https://bugs.python.org/issue47219
#47218: adding name to lzmafile
https://bugs.python.org/issue47218
#47217: adding name to BZ2File
https://bugs.python.org/issue47217
Most recent 15 issues waiting for review (15)
=
#47256: re: limit the maximum capturing group to 1,073,741,823, reduce
https://bugs.python.org/issue47256
#47255: Many broken :meth: roles in the docs
https://bugs.python.org/issue47255
#47254: enhanced dir?
https://bugs.python.org/issue47254
#47251: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE
https://bugs.python.org/issue47251
#47243: Duplicate entry in 'Objects/unicodetype_db.h'
https://bugs.python.org/issue47243
#47233: show_caches option affects code positions reported by dis.get_
https://bugs.python.org/issue47233
#47222: subprocess.Popen() should allow capturing output and sending i
https://bugs.python.org/issue47222
#47218: adding name to lzmafile
https://bugs.python.org/issue47218
#47217: adding name to BZ2File
https://bugs.python.org/issue47217
#47216: adding mtime option to gzip open()
https://bugs.python.org/issue47216
#47215: Add "unstable" frame stack api
https://bugs.python.org/issue47215
#47208: Support libffi implementations that cannot support invocations
https://bugs.python.org/issue47208
#47205: posix.sched_{get|set}affinity(-1) no longer returns ProcessLoo
https://bugs.python.org/issue47205
#47200: Add ZipInfo.mode property
https://bugs.python.org/issue47200
#47199: multiprocessing: micro-optimize Connection.send_bytes() method
https://bugs.python.org/issue47199
_______
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/RUVCN7UD4CAO6DUJ3VGRGBYOCM64HR5T/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Proto-PEP part 4: The wonderful third option
On 26/04/2022 20:48, Carl Meyer via Python-Dev wrote:
On Tue, Apr 26, 2022 at 1:25 PM Guido van Rossum wrote:
I also would like to hear more about the problem this is trying to solve, when
th real-world examples. (E.g. from pydantic?)
Yes please. I think these threads have jumped far too quickly into
esoteric details of implementation and syntax, without critical
analysis of whether the semantics of the proposal are in fact a good
solution to a real-world problem that someone has.
I've already outlined in a more detailed reply on the first thread why
I don't think forward declarations provide a practically useful
solution to forward reference problems for users of static typing
(every module that imports something that might be a forward reference
would have to import its implementation also, turning every one-line
import of that class into two or three lines) and causes new problems
for every user of Python due to its reliance on import side effects
causing global changes at a distance. See
https://mail.python.org/archives/list/python-dev@python.org/message/NMCS77YFM2V54PUB66AXEFTE4NXFHWPI/
for details.
Under PEP 649, forward references are a small problem confined to the
edge case of early resolution of type annotations. There are simple
and practical appropriately-scoped solutions easily available for that
small problem: providing a way to resolve type annotations at runtime
without raising NameError on not-yet-defined names. Such a facility
(whether default or opt-in) is practically useful for many users of
annotations (including dataclasses and documentation tools), which
have a need to introspect some aspects of annotations without
necessarily needing every part of the annotation to resolve. The
existence of such a facility is a reasonable special case for
annotations specifically, because annotations are fundamentally
special: they provide a description of code, rather than being only a
part of the code. (This special-ness is precisely also why they cause
more forward references in the first place.)
IMO, this forward declaration proposal takes a small problem in a
small corner of the language and turns it into a big problem for the
whole language, without even providing as nice and usable an option
for common use cases as "PEP 649 with option for lax resolution" does.
This seems like a case study in theoretical purity ("resolution of
names in annotations must not be special") running roughshod over
practicality.
Carl
Insofar as I understand the above (knowing almost nothing about typing), +1.
Best wishes
Rob Cliffe
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/DWA4AGXTBI5SU2R2T5O7KTQJ4F6DU27S/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes
On Tue, Apr 26, 2022 at 7:24 PM Greg Ewing wrote: > On 27/04/22 2:01 am, Chris Angelico wrote: > > That would be the case if monkeypatching were illegal. Since it's not, > > wherein lies the difference? > > The proposed feature is analogous to forward declaring a > struct in C. Would you call what C does monkeypatching? > It is not analogous; it is a false analogy that obscures the issues with this proposal in Python. A C forward declaration (not to mention the full struct declaration also!) is purely for the compiler; at runtime one can have a pointer to some memory that the compiler expects to be shaped like that struct, but one can never get hold of any runtime value that is “the struct definition itself,” let alone a runtime value that is the nascent forward-declared yet-to-be-completed struct. So clearly there can be no patching of something that never exists at runtime at all. Python is quite different from C in this respect. Classes are runtime objects, and so is the “forward declared class” object. The proposal is for a class object to initially at runtime be the latter, and then later (at some point that is not well defined if the implementation is in a separate module, because global module import ordering is an unstable emergent property of all the imports in the entire codebase) may suddenly, everywhere and all at once, turn into the former. Any given module that imports the forward declared name can have no guarantee when (if ever) that object will magically transform into something that is safe to use. Whether we call it monkeypatching or not is irrelevant. Having global singleton objects change from one thing to a very different thing, at an unpredictable point in time, as a side effect of someone somewhere importing some other module, causes very specific problems in being able to locally reason about code. I think it is more useful to discuss the specific behavior and its consequences than what it is called. Carl ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/CQ7TAV6TWGEG2HLVY7T46U6JCPESRACR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Proto-PEP part 4: The wonderful third option
On Tue, Apr 26, 2022 at 1:25 PM Guido van Rossum wrote:
> I also would like to hear more about the problem this is trying to solve,
> when th real-world examples. (E.g. from pydantic?)
Yes please. I think these threads have jumped far too quickly into
esoteric details of implementation and syntax, without critical
analysis of whether the semantics of the proposal are in fact a good
solution to a real-world problem that someone has.
I've already outlined in a more detailed reply on the first thread why
I don't think forward declarations provide a practically useful
solution to forward reference problems for users of static typing
(every module that imports something that might be a forward reference
would have to import its implementation also, turning every one-line
import of that class into two or three lines) and causes new problems
for every user of Python due to its reliance on import side effects
causing global changes at a distance. See
https://mail.python.org/archives/list/python-dev@python.org/message/NMCS77YFM2V54PUB66AXEFTE4NXFHWPI/
for details.
Under PEP 649, forward references are a small problem confined to the
edge case of early resolution of type annotations. There are simple
and practical appropriately-scoped solutions easily available for that
small problem: providing a way to resolve type annotations at runtime
without raising NameError on not-yet-defined names. Such a facility
(whether default or opt-in) is practically useful for many users of
annotations (including dataclasses and documentation tools), which
have a need to introspect some aspects of annotations without
necessarily needing every part of the annotation to resolve. The
existence of such a facility is a reasonable special case for
annotations specifically, because annotations are fundamentally
special: they provide a description of code, rather than being only a
part of the code. (This special-ness is precisely also why they cause
more forward references in the first place.)
IMO, this forward declaration proposal takes a small problem in a
small corner of the language and turns it into a big problem for the
whole language, without even providing as nice and usable an option
for common use cases as "PEP 649 with option for lax resolution" does.
This seems like a case study in theoretical purity ("resolution of
names in annotations must not be special") running roughshod over
practicality.
Carl
_______
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/RVQSLD435BFKEVIMY2AIA5MCJB37BPHK/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Proto-PEP part 4: The wonderful third option
> On 26 Apr 2022, at 20:52, Larry Hastings wrote:
>
>
>
> On 4/25/22 23:56, Ronald Oussoren wrote:
>> A problem with this trick is that you don’t know how large a class object
>> can get because a subclass of type might add new slots. This is currently
>> not possible to do in Python code (non-empty ``__slots__`` in a type
>> subclass is rejected at runtime), but you can do this in C code.
> Dang it! __slots__! Always there to ruin your best-laid plans. *shakes
> fist at heavens*
>
> I admit I don't know how __slots__ is currently implemented, so I wasn't
> aware of this. However! The first part of my proto-PEP already proposes
> changing the implementation of __slots__, to allow adding __slots__ after the
> class is created but before it's instantiated. Since this is so
> late-binding, it means the slots wouldn't be allocated at the same time as
> the type, so happily we'd sidestep this problem. On the other hand, this
> raises the concern that we may need to change the C interface for creating
> __slots__, which might break C extensions that use it. (Maybe we can find a
> way to support the old API while permitting the new late-binding behavior,
> though from your description of the problem I'm kind of doubtful.)
>
I used the term slots in a very loose way. In PyObjC I’m basically doing:
typedef struct {
PyHeapTypeObject base;
/* Extra C fields go here */
} PyObjCClassObject;
Those extra C fields don’t get exposed to Python, but could well be by using
getset definitions. This has worked without problems since early in the 2.x
release cycle (at least, that’s when I started doing this in PyObjC), and is
how one subclasses other types as well.
“Real” __slots__ don’t work when subclassing type() because type is a var
object. That’s “just” an implementation limitation, it should be possible to
add slots after the variable length bit (he says while wildly waving his
hands).
Ronald
—
Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/XYK7NO4CJGP5N6CLDOI7IONOBJAZYNHK/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Proto-PEP part 4: The wonderful third option
> On 26 Apr 2022, at 07:32, Larry Hastings wrote: > > […] > What could go wrong? My biggest question so far: is there such a thing as a > metaclass written in C, besides type itself? Are there metaclasses with a > __new__ that doesn't call super().__new__ or three-argument type? If there > are are metaclasses that allocate their own class objects out of raw bytes, > they'd likely sidestep this entire process. I suspect this is rare, if > indeed it has ever been done. Anyway, that'd break this mechanism, so exotic > metaclasses like these wouldn't work with "forward-declared classes". But at > least they needn't fail silently. We just need to add a guard after the call > to metaclass.__new__: if we passed in "__forward__=C" into metaclass.__new__, > and metaclass.__new__ didn't return C, we raise an exception. > There are third party metaclasses written in C, one example is PyObjC which has meta classes written in C and those meta classes create a type with additional entries in the C struct for the type. I haven’t yet tried to think about the impact of this proposal, other than the size of the type (as mentioned earlier). The PyObjC meta class constructs both the Python class and a corresponding Objective-C class in lock step. On first glance this forward class proposal should not cause any problems here other than the size of the type object. Ronald — Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/33PUXWIV6OAVRFJAQWYIV7CMLDKBI2ER/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Proto-PEP part 4: The wonderful third option
> On 26 Apr 2022, at 07:32, Larry Hastings wrote: > > [… snip …] > Next we have the "continue" class statement. I'm going to spell it like this: > > continue class C(BaseClass, ..., metaclass=MyMetaclass): > # class body goes here > ... > > I'll mention other possible spellings later. The first change I'll point out > here: we've moved the base classes and the metaclass from the "forward" > statement to the "continue" statement. Technically we could put them either > place if we really cared to. But moving them here seems better, for reasons > you'll see in a minute. > > Other than that, this "continue class" statement is similar to what I (we) > proposed before. For example, here C is an expression, not a name. > > Now comes the one thing that we might call a "trick". The trick: when we > allocate the ForwardClass instance C, we make it as big as a class object can > ever get. (Mark Shannon assures me this is simply "heap type", and he knows > far more about CPython internals than I ever will.) Then, when we get to the > "continue class" statement, we convince metaclass.__new__ call to reuse this > memory, and preserve the reference count, but to change the type of the > object to "type" (or what-have-you). C has now been changed from a > "ForwardClass" object into a real type. (Which almost certainly means C is > now mutable.) > A problem with this trick is that you don’t know how large a class object can get because a subclass of type might add new slots. This is currently not possible to do in Python code (non-empty ``__slots__`` in a type subclass is rejected at runtime), but you can do this in C code. Ronald — Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/ _______ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/JMO4V4S6OHOFFSKQ3XGU2AEEQVYUAY6J/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes
One reason I dislike this whole proposal is that I can see forward declarations (FDs) ending up in code that doesn't need them. This could happen if (a) The FDs were needed at some point, but then the type declarations were taken out. This could happen with someone modifying their own code, or lifting from someone else's code. (b) A relative newbie could see FDs in someone else's code and assume that they were necessary, or at least desirable, and put unnecessary FDs in their own code in imitation. Result: Code clutter and confusion. AIUI the problem to be solved is solely related to typing. Is it not possible to solve it purely in the "typing world", rather than letting it leak out and "infect" something basic in the core language like how classes are declared? By "core language" I guess I mean "Python without typing". Best wishes Rob Cliffe _______ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/F36RCN5GLRIKZJD44LGUFNJ2YQEBUMMZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [Typing-sig] Almost accepting PEP 681 – Data Class Transforms
* Erik, could you propose a change to the PEP text? I just created https://github.com/python/peps/pull/2555 to address these issues. -Erik ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/W4NJNTXJIH75QKOBTRIYYNSQYN5R4ZRK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes
On Sun, Apr 24, 2022 at 10:20 AM Joao S. O. Bueno wrote: > > I am not worried about the bikeshed part of which syntax to use - > and more worried with the possible breaking of a lot of stuff, unless > we work with creation of a non-identical "forward object" that is > rebound, as in plain name binding, when the second part > is declared. I've stated that amidst my ramblings, > but Nick Coghlan managed to keep it suscint at > https://mail.python.org/archives/list/python-dev@python.org/message/DMITVTUIQKJW6RYVOPQXHD54VSYE7QHA/ I don't think name rebinding works. That means that if we have `forward class Bar` in module `foo` and `continue class Bar: ...` in module `foo.impl`, if module `baz` does `from foo import Bar`, it will forever have either the forward reference object or the real class, and which one it has is entirely unpredictable (depends on import ordering accidents of the rest of the codebase.) If `baz` happens to be imported before `foo.impl`, the name `Bar` in the `baz` namespace will never be resolved to the real class, and isn't resolvable to the real class without some outside intervention. > """ > Something worth considering: whether forward references need to be > *transparent* at runtime. If they can just be regular ForwardRef objects > then much of the runtime complexity will go away (at the cost of some > potentially confusing identity check failures between forward references > and the actual class objects). > > ForwardRef's constructor could also potentially be enhanced to accept a > "resolve" callable, and a "resolve()" method added to its public API, > although the extra complexity that would bring may not be worth it. > """ I'm not sure how this `resolve()` method is even possible under the proposed syntax. If `forward class Bar` and `continue class Bar` are in different modules, then how can `forward class Bar` (which must create the "forward reference" object) possibly know which module `continue class Bar: ...` exists in? How can it know how to resolve itself? Carl _______ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/WLZRZIMPRST52UMINB5VB57TOIQVTYQH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes
Hi Larry, On Sat, Apr 23, 2022 at 1:53 AM Larry Hastings wrote: > But rather than speculate further, perhaps someone who works on one of the > static type analysis checkers will join the discussion and render an informed > opinion about how easy or hard it would be to support "forward class" and > "continue class". I work on a Python static type checker. I think a major issue with this proposal is that (in the separate-modules case) it requires monkey-patching as an import side effect, which is quite hard for both humans and static analysis tools to reason effectively about. Imagine we have a module `foo` that contains `forward class Bar`, a separate module `foo.impl` that contains `continue class Bar: ...`, and then a module `baz` that contains `import foo`. What type of object is `foo.Bar` during the import of `baz`? Will it work for the module body of `baz` to create a singleton instance `my_bar = foo.Bar()`? The answer is that we have no idea. `foo.Bar` might be a non-instantiable "forward class declaration" (or proxy object, in your second variation), or it might be a fully-constituted class. Which one it is depends on accidents of import order anywhere else in the codebase. If any other module happens to have imported `foo.impl` before `baz` is imported, then `foo.Bar` will be the full class. If nothing else has imported `foo.impl`, then it will be a non-instantiable declaration/proxy. This question of import order potentially involves any other module in the codebase, and the only way to reliably answer it is to run the entire program; neither a static type checker nor a reader of the code can reliably answer it in the general case. It will be very easy to write a module `baz` that does `import foo; my_bar = foo.Bar()` and have it semi-accidentally work initially, then later break mysteriously due to a change in imports in a seemingly unrelated part of the codebase, which causes `baz` to now be imported before `foo.impl` is imported, instead of after. There is another big problem for static type checkers with this hypothetical module `baz` that only imports `foo`. The type checker cannot know the shape of the full class `Bar` unless it sees the right `continue Bar: ...` statement. When analyzing `baz`, it can't just go wandering the filesystem aimlessly in hopes of encountering some module with `continue Bar: ...` in it, and hope that's the right one. (Even worse considering it might be `continue snodgrass: ...` or anything else instead.) So this means a type checker must require that any module that imports `Bar` MUST itself import `foo.impl` so the type checker has a chance of understanding what `Bar` actually is. This highlights an important difference between this proposal and languages with real forward declarations. In, say, C++, a forward declaration of a function or class contains the full interface of the function or class, i.e. everything a type checker (or human reader) would need to know in order to know how it can use the function or class. In this proposal, that is not true; lots of critical information about the _interface_ of the class (what methods and attributes does it have, what are the signatures of its methods?) are not knowable without also seeing the "implementation." This proposal does not actually forward declare a class interface; all it declares is the existence of the class (and its inheritance hierarchy.) That's not sufficient information for a type checker or a human reader to make use of the class. Taken together, this means that every single `import foo` in the codebase would have to be accompanied by an `import foo.impl` right next to it. In some cases (if `foo.Bar` is not used in module-level code and we are working around a cycle) it might be safe for the `import foo.impl` to be within an `if TYPE_CHECKING:` block; otherwise it would need to be a real runtime import. But it must always be there. So every single `import foo` in the codebase must now become two or three lines rather than one. There are of course other well-known problems with import-time side effects. All the imports of `foo.impl` in the codebase would exist only for their side effect of "completing" Bar, not because anyone actually uses a name defined in `foo.impl`. Linters would flag these imports as unused, requiring extra cruft to silence the linter. Even worse, these imports would tend to appear unused to human readers, who might remove them and be confused why that breaks the program. All of these import side-effect problems can be resolved by dis-allowing module separation and requiring `forward class` and `continue class` to appear in the same module. But then the proposal no longer helps with resolving inter-module cycles, only intra-module ones. Because of these issues (and others that have been mentioned), I don't think this proposal is a good solution to forward references. I think PEP 649, with some tricks th
[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes
UGH! I thought there was a general understanding that when typing was added to Python, there would be no impact, or at least minimal impact, on people who didn't use it. (Raises hand.) Now we see an(other) instance of intention creep. Rob Cliffe On 23/04/2022 02:13, Larry Hastings wrote: This document is a loose proto-PEP for a new "forward class" / "continue class" syntax. Keep in mind, the formatting is a mess. If I wind up submitting it as a real PEP I'll be sure to clean it up first. /arry -- PEP : Forward declaration of classes Overview Python currently has one statement to define a class, the `class` statement: ```Python class X(): # class body goes here def __init__(self, key): self.key = key ``` This single statement declares the class, including its bases and metaclass, and also defines the contents of the class in the "class body". This PEP proposes an additional syntax for declaring a class which splits this work across two statements: * The first statement is `forward class`, which declares the class and binds the class object. * The second statement is `continue class`, which defines the contents of the class in the "class body". To be clear: `forward class` creates the official, actual class object. Code that wants to take a reference to the class object may take references to the `forward class` declared class, and interact with it as normal. However, a class created by `forward class` can't be *instantiated* until after the matching `continue class` statement finishes. Defining class `X` from the previous example using this new syntax would read as follows: ``` forward class X() continue class X: # class body goes here def __init__(self, key): self.key = key ``` This PEP does not propose altering or removing the traditional `class` statement; it would continue to work as before. Rationale - Python programmers have had a minor problem with classes for years: there's no way to have early-bound circular dependencies between objects. If A depends on B, and B depends on A, there's no linear order that allows you to cleanly declare both. Most of the time, the dependencies were in late-binding code, e.g. A refers to B inside a method. So this was rarely an actual problem at runtime. When this problem did arise, in code run at definition-time, it was usually only a minor headache and could be easily worked around. But the explosion of static type analysis in Python, particularly with the `typing` module and the `mypy` tool, has made circular definition-time dependencies between classes commonplace--and much harder to solve. Here's one simple example: ```Python class A: value: B class B: value: A ``` An attribute of `B` is defined using a type annotation of `A`, and an attribute of `A` is defined using a type annotation of `B`. There's no order to these two definitions that works; either `A` isn't defined yet, or `B` isn't defined yet. Various workarounds and solutions have been proposed to solve this problem, including two PEPs: PEP 563 (automatic stringized annotations) and PEP 649 (delayed evaluation of annotations using functions). But nothing so far has been both satisfying and complete; either it is wordy and clumsy to use (manually stringizing annotations), or it added restrictions and caused massive code breakage for runtime use of annotations (PEP 563), or simply didn't solve every problem (PEP 649). This proposed `forward class` / `continue class` syntax should permit solving *every* forward-reference and circular-reference problem faced in Python, using an elegant and Pythonic new syntax. As a side benefit, `forward class` and `continue class` syntax enables rudimentary separation of "interface" from "implementation", at least for classes. A user seeking to "hide" the implementation details of their code could put their class definitions in one module, and the implementations of those classes in a different module. This new syntax is not intended to replace the traditional `class` declaration syntax in Python. If this PEP were accepted, the `class` statement would still be the preferred mechanism for creating classes in Python; `forward class` should only be used when it confers some specific benefit. Syntax -- The `forward class` statement is the same as the `class` statement, except it doesn't end with a colon and is not followed by an indented block. Without any base classes or metaclass, the `forward class` statement is as follows: ``` forward class X ``` This would declare class `X`. If `X` needs base classes or metaclass, the corresponding `forward class` statement would be as follows, rendered in a sort of "function prototype" manner: ``` forward class X(*b
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2022-04-15 - 2022-04-22)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7146 ( +0)
closed 51841 ( +0)
total 58987 ( +0)
Open issues with patches: 2890
Most recent 15 issues with no replies (15)
==
#47258: Python 3.10 hang at exit in drop_gil() (due to resource warnin
https://bugs.python.org/issue47258
#47256: re: limit the maximum capturing group to 1,073,741,823, reduce
https://bugs.python.org/issue47256
#47253: LOAD_GLOBAL instruction with wrong source position
https://bugs.python.org/issue47253
#47252: socket.makefile documentation is missing data regarding the 'b
https://bugs.python.org/issue47252
#47251: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE
https://bugs.python.org/issue47251
#47244: email.utils.formataddr does not respect double spaces
https://bugs.python.org/issue47244
#47242: Annoying white bar in IDLE (line 457 in sidebar.py)
https://bugs.python.org/issue47242
#47241: [C API] Move the PyCodeObject structure to the internal C API
https://bugs.python.org/issue47241
#47238: Python threading.Event().wait() depends on the system time
https://bugs.python.org/issue47238
#47236: Document types.CodeType.replace() changes about co_exceptionta
https://bugs.python.org/issue47236
#47228: Document that na??ve datetime objects represent local time
https://bugs.python.org/issue47228
#47222: subprocess.Popen() should allow capturing output and sending i
https://bugs.python.org/issue47222
#47219: asyncio with two interpreter instances
https://bugs.python.org/issue47219
#47218: adding name to lzmafile
https://bugs.python.org/issue47218
#47217: adding name to BZ2File
https://bugs.python.org/issue47217
Most recent 15 issues waiting for review (15)
=
#47256: re: limit the maximum capturing group to 1,073,741,823, reduce
https://bugs.python.org/issue47256
#47255: Many broken :meth: roles in the docs
https://bugs.python.org/issue47255
#47254: enhanced dir?
https://bugs.python.org/issue47254
#47251: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE
https://bugs.python.org/issue47251
#47243: Duplicate entry in 'Objects/unicodetype_db.h'
https://bugs.python.org/issue47243
#47233: show_caches option affects code positions reported by dis.get_
https://bugs.python.org/issue47233
#47222: subprocess.Popen() should allow capturing output and sending i
https://bugs.python.org/issue47222
#47218: adding name to lzmafile
https://bugs.python.org/issue47218
#47217: adding name to BZ2File
https://bugs.python.org/issue47217
#47216: adding mtime option to gzip open()
https://bugs.python.org/issue47216
#47215: Add "unstable" frame stack api
https://bugs.python.org/issue47215
#47208: Support libffi implementations that cannot support invocations
https://bugs.python.org/issue47208
#47205: posix.sched_{get|set}affinity(-1) no longer returns ProcessLoo
https://bugs.python.org/issue47205
#47200: Add ZipInfo.mode property
https://bugs.python.org/issue47200
#47199: multiprocessing: micro-optimize Connection.send_bytes() method
https://bugs.python.org/issue47199
_______
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/T4FH4WLLKDRAS2YSQI75RHXVVZE3R4JZ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Need help on security vulnerability zlib 1.2.11
> On 19 Apr 2022, at 23:07, Prasad, PCRaghavendra > wrote: > > Hi All, > > We are facing some issue with the zlib package 1.2.11. Recently there was a > vulnerability in zlib and we had to upgrade to 1.2.12 on all supported > platforms > We did that in all platforms including windows, python39.dll is now showing > 1.2.12 but the problem is we use pyinstaller to generate application exe. > This exe is still referring to 1.2.11 we tried lot of things to find how it > is linking to 1.2.11, there is no line of sight on this. > > Can any one please provide some input on this Please ask the pyinstaller developers about this. Ronald — Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/ _______ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/PB6VU7RQNBRDT4GDZEFKNTH7N6D74ERZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2022-04-08 - 2022-04-15)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7146 ( +0)
closed 51841 ( +0)
total 58987 ( +0)
Open issues with patches: 2890
Most recent 15 issues with no replies (15)
==
#47258: Python 3.10 hang at exit in drop_gil() (due to resource warnin
https://bugs.python.org/issue47258
#47256: re: limit the maximum capturing group to 1,073,741,823, reduce
https://bugs.python.org/issue47256
#47253: LOAD_GLOBAL instruction with wrong source position
https://bugs.python.org/issue47253
#47252: socket.makefile documentation is missing data regarding the 'b
https://bugs.python.org/issue47252
#47251: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE
https://bugs.python.org/issue47251
#47244: email.utils.formataddr does not respect double spaces
https://bugs.python.org/issue47244
#47242: Annoying white bar in IDLE (line 457 in sidebar.py)
https://bugs.python.org/issue47242
#47241: [C API] Move the PyCodeObject structure to the internal C API
https://bugs.python.org/issue47241
#47238: Python threading.Event().wait() depends on the system time
https://bugs.python.org/issue47238
#47236: Document types.CodeType.replace() changes about co_exceptionta
https://bugs.python.org/issue47236
#47228: Document that na??ve datetime objects represent local time
https://bugs.python.org/issue47228
#47222: subprocess.Popen() should allow capturing output and sending i
https://bugs.python.org/issue47222
#47219: asyncio with two interpreter instances
https://bugs.python.org/issue47219
#47218: adding name to lzmafile
https://bugs.python.org/issue47218
#47217: adding name to BZ2File
https://bugs.python.org/issue47217
Most recent 15 issues waiting for review (15)
=
#47256: re: limit the maximum capturing group to 1,073,741,823, reduce
https://bugs.python.org/issue47256
#47255: Many broken :meth: roles in the docs
https://bugs.python.org/issue47255
#47254: enhanced dir?
https://bugs.python.org/issue47254
#47251: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE
https://bugs.python.org/issue47251
#47243: Duplicate entry in 'Objects/unicodetype_db.h'
https://bugs.python.org/issue47243
#47233: show_caches option affects code positions reported by dis.get_
https://bugs.python.org/issue47233
#47222: subprocess.Popen() should allow capturing output and sending i
https://bugs.python.org/issue47222
#47218: adding name to lzmafile
https://bugs.python.org/issue47218
#47217: adding name to BZ2File
https://bugs.python.org/issue47217
#47216: adding mtime option to gzip open()
https://bugs.python.org/issue47216
#47215: Add "unstable" frame stack api
https://bugs.python.org/issue47215
#47208: Support libffi implementations that cannot support invocations
https://bugs.python.org/issue47208
#47205: posix.sched_{get|set}affinity(-1) no longer returns ProcessLoo
https://bugs.python.org/issue47205
#47200: Add ZipInfo.mode property
https://bugs.python.org/issue47200
#47199: multiprocessing: micro-optimize Connection.send_bytes() method
https://bugs.python.org/issue47199
_______
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/V6QTLZZ3XT4ZH4SXP7SAFZDZYVCEAPP7/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Importing a submodule doesn't always set an attribute on its parent
Brett Cannon wrote: > So we don't want to strengthen the definition at > all; best we are comfortable with is put up a warning that you don't want > to do stuff with sys.modules unless you know what you're doing. OK, thanks for the clarification. Having read through the source of importlib one too many times, I guess I will declare that I "know what [I'm] doing" for now and keep on mutating sys.modules, since the alternative (intercepting all imports) seems more painful to me. If my code breaks in a future Python version I'll only blame myself :) Best, Daniel ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HZEPOAI3YME4GD2M6RPWG2KG4OTSB5KX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] RFC on PEP 681: Data Class Transforms
PEP 681<https://www.python.org/dev/peps/pep-0681/> improves type checker support for libraries with dataclass-like behaviors by introducing a way to map the behaviors of decorators and classes in those libraries to the behaviors of stdlib dataclass. The PEP will not affect CPython directly except for the addition of the dataclass_transform decorator in typing.py. The decorator is currently in typing_extensions. The canonical discussion thread is on Typing SIG<https://mail.python.org/archives/list/typing-...@python.org/thread/EAALIHA3XEDFDNG2NRXTI3ERFPAD65Z4/>. Please send any comments there. Any feedback would be appreciated! Thanks, Erik ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/7MEB5WYMUZ6SPEVZMVG5H7NQRI7KRB25/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Importing a submodule doesn't always set an attribute on its parent
Thanks, Brett. I understand why the behavior happens, I just don't understand the decision to implement imports this way. Since there's no warning in the documentation that removing items from sys.modules can break the fact that "import X.Y" defines "X.Y" (note that the "behind the curtain" stuff happens *before* the second import, so it's still the case that the second import does not define "X.Y" as implied by the docs), and there's also no warning that submodules must be removed at the same time as their parent, I would expect my example code to work. I don't see any downside to having "import X.Y" always set the Y attribute of X (instead of only setting it if 'X.Y' is not already in sys.modules), but if you think it's a bad idea, here's a suggestion for a paragraph to add at the end of PLR 5.4.2: "Note that the binding to the submodule object in the parent module's namespace is only added when the submodule is actually *loaded*. If the submodule is already present in `sys.modules` when it is imported (through any of the mechanisms above), then it will not be loaded again and no binding will be added to the parent module." If removing a module but not its submodules from sys.modules is considered "cheating" and could potentially break other parts of the import system, that should also be documented, e.g. by adding the sentence "If you delete a key for a module in `sys.modules`, you must also delete the keys for all submodules of that module." at the end of the 3rd paragraph of PLR 5.3.1. However, I would much rather not impose this restriction, since it seems unnecessarily restrictive (indeed, my code violates it but works fine, and changing it to transitively remove all submodules would necessitate reloading many modules which do not actually need to be reloaded). (Terry, thanks for your suggestion. My concern about adding such a vague warning is that to me, it reads as saying that all bets are off if you modify sys.modules by hand, which means it would never be safe to do so, i.e., the behavior might change arbitrarily in a future Python version. But in my opinion there are legitimate cases where it is necessary to ensure a module will be reloaded the next time it is imported, and the documented way to do that is to remove entries from sys.modules.) Daniel ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/N763W6AGD6NQ4IXVWMNGDL4DBN3LXBJ7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Declarative imports
Hi Malthe, On Fri, Apr 8, 2022 at 12:04 PM Malthe wrote: > Actually, to me the interesting idea is not so much lazy imports – I > think they should not be lazy, at least that was my initial thought. I > think they should be immediately resolved before anything else in that > module: I'm +0.25 on your idea as simply a streamlined syntax for inline imports (given actually finding an appropriate syntax, which I haven't thought much about; @ probably doesn't work due to the conflict with decorator syntax, but there might be other options.). If it existed I would probably use it occasionally, but I don't feel a strong need for it. But I think your proposal is much stronger if you eliminate the hoisting from it; with the hoisting I'd be -1. Out-of-source-order execution like this is just quite surprising in the context of Python. > 1. This would settle any discussion about performance impact (there > wouldn't be any). If the inline import is actually a performance problem because a certain code path is very hot, the solution is simple: don't use the inline import there, use a top-of-module import instead. > 2. This would enable IDEs, typers and other tooling to know the type > using existing import logic. I don't think it enables any such thing. Static-analysis tooling has only the source code to work with, runtime behavior doesn't affect it. If the runtime executes these imports out-of-order, that won't make the slightest difference to how easily IDEs and type checkers can analyze the source code. > 3. Catch errors early! The very strong precedent in Python is that errors in code are caught when the code runs, and the code runs more or less when you'd expect it to, in source order. If you want to catch errors earlier, use a static analysis tool to help catch them. Carl ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ARI44O62CRMAF2IKPHJVLU5D2ADR2DP6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Declarative imports
Hi Barry, On Fri, Apr 8, 2022 at 12:44 PM Barry Warsaw wrote: > > Start up overhead due to imports is a real problem for some class of > applications, e.g. CLIs, and I’ve seen a lot of hacks implemented to get > Python CLIs to be more responsive. E.g. getting from invocation to —help > output is a major UX problem. Definitely, we have this same problem, and also the same symptom of people pushing hard to rewrite Python CLIs in Go for this reason. > It’s often more complicated than just imports alone though. Expensive module > scope initializations and decorators contribute to this problem. One of our projects that can prevent much of this expensive work being done at import time is Strict Modules[1]. Currently it's only available as part of Cinder, though we're hoping to make it pip-installable as part of our project to make Cinder's features more easily accessible. Our experience in practice, though, has been that universally lazy imports is somewhat easier to adopt than Strict Modules, and has had a much bigger overall impact on reducing startup time for big CLIs (and a big web server too; as you note it's not as serious an issue for a web server in production, but restart time still does make a difference to dev speed / experience.) Removing slow stuff happening at import time helps, but it'll never match the speed of not doing the import at all! We've seen startup time improvements up to 70% in real-world CLIs just by making imports lazy. We've also opened an issue to discuss the possibility of upstreaming this. [2] [1] https://github.com/facebookincubator/cinder/#strict-modules [2] https://bugs.python.org/issue46963 _______ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/62OTFJMAMQ2WHZ4H3TUEJTECMPJDQ557/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Importing a submodule doesn't always set an attribute on its parent
Hello, I came across what seems like either a bug in the import system or a gap in its documentation, so I'd like to run it by folks here to see if I should submit a bug report. If there's somewhere else more appropriate to discuss this, please let me know. If you import A.B, then remove A from sys.modules and import A.B again, the newly-loaded version of A will not contain an attribute referring to B. Using "collections.abc" as an example submodule from the standard library: >>> import sys >>> import collections.abc >>> del sys.modules['collections'] >>> import collections.abc >>> collections.abc Traceback (most recent call last): File "", line 1, in AttributeError: module 'collections' has no attribute 'abc' This behavior seems quite counter-intuitive to me: why should the fact that B is already loaded prevent adding a reference to it to A? It also goes against the general principle that "import FOO" makes the expression "FOO" well-defined; for example PLR 5.7 states that "'import XXX.YYY.ZZZ' should expose 'XXX.YYY.ZZZ' as a usable expression". Finally, it violates the "invariant" stated in PLR 5.4.2 that if 'A' and 'A.B' both appear in sys.modules, then A.B must be defined and refer to sys.modules['A.B']. On the other hand, PLR 5.4.2 also states that "when a submodule is loaded using any mechanism... a binding is placed in the parent module's namespace to the submodule object", which is consistent with the behavior above, since the second import of A.B does not actually "load" B (only retrieve it from the sys.modules cache). So perhaps Python is working as intended here, and there is an unwritten assumption that if you unload a module from the cache, you must also unload all of its submodules. If so, I think this needs to be added to the documentation (which currently places no restrictions on how you can modify sys.modules, as far as I can tell). This may be an obscure corner case that is unlikely to come up in practice (I imagine few people need to modify sys.modules), but it did actually cause a bug in a project I work on, where it is necessary to uncache certain modules so that they can be reloaded. I was able to fix the bug some other way, but I think it would still be worthwhile to either make the import behavior more consistent (so that 'import A.B' always sets the B attribute of A) or add a warning in the documentation about this case. I'd appreciate any thoughts on this! Thanks, Daniel ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/VIPXZRK3OJNSVNSZSAJ7CO6QFC2RX27W/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Declarative imports
An interesting point in the lazy imports design space that I hadn't previously considered could be: - lazy imports are explicitly marked and usage of the imported name within the module is transparent, but - lazily imported names are _not_ visible in the module namespace; they can't be accessed by other modules or re-exported; they are internal-use-only within the module This compromise would, I think, make it possible to implement lazy imports entirely in the compiler (effectively as syntax sugar for an inline import at every usage site), which is definitely an implementation improvement. I think in practice explicitly marking lazy imports would make it somewhat harder to gain the benefits of lazy imports for e.g. speeding up startup time in a large CLI, compared to an implicit/automatic approach. But still could be usable to get significant benefits. Carl ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ZT6CXQPFCWZD2M65YXCSAPPGNDGA6WNE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2022-04-01 - 2022-04-08)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7146 ( -7)
closed 51841 (+78)
total 58987 (+71)
Open issues with patches: 2890
Issues opened (49)
==
#47104: Rewrite asyncio.to_thread tests to use IsolatedAsyncioTestCase
https://bugs.python.org/issue47104 reopened by kj
#47136: The variable __module__ in the class body getting an undesirab
https://bugs.python.org/issue47136 reopened by ethan.furman
#47191: inspect - getasyncgeneratorstate, getasyncgeneratorlocals
https://bugs.python.org/issue47191 opened by animatea.programming
#47192: sys._getframe audit event has frame as argument in 3.8-3.10
https://bugs.python.org/issue47192 opened by Dutcho
#47193: Use zlib-ng rather than zlib in binary releases
https://bugs.python.org/issue47193 opened by gregory.p.smith
#47194: Upgrade to zlib v1.2.12 in CPython binary releases
https://bugs.python.org/issue47194 opened by gregory.p.smith
#47195: importlib lock race issue in deadlock handling code
https://bugs.python.org/issue47195 opened by rpurdie
#47197: ctypes mishandles `void` return type
https://bugs.python.org/issue47197 opened by hoodchatham
#47199: multiprocessing: micro-optimize Connection.send_bytes() method
https://bugs.python.org/issue47199 opened by malin
#47200: Add ZipInfo.mode property
https://bugs.python.org/issue47200 opened by sam_ezeh
#47201: pip3.10.4 is configured with locations that require TLS/SSL, h
https://bugs.python.org/issue47201 opened by alessandro.pioli
#47204: Ensure PyEval_GetGlobals() doesn't set an exception when retur
https://bugs.python.org/issue47204 opened by ncoghlan
#47205: posix.sched_{get|set}affinity(-1) no longer returns ProcessLoo
https://bugs.python.org/issue47205 opened by christian.heimes
#47206: pickle docs are wrong about nested classes
https://bugs.python.org/issue47206 opened by JelleZijlstra
#47207: Switch datetime docstrings / documentation to using "Returns"
https://bugs.python.org/issue47207 opened by p-ganssle
#47208: Support libffi implementations that cannot support invocations
https://bugs.python.org/issue47208 opened by hoodchatham
#47209: Documentation for asserting values of `unittest.mock.Mock.call
https://bugs.python.org/issue47209 opened by himkt
#47214: builtin_function_or_method is also either a function or a meth
https://bugs.python.org/issue47214 opened by apostofes
#47215: Add "unstable" frame stack api
https://bugs.python.org/issue47215 opened by Mark.Shannon
#47216: adding mtime option to gzip open()
https://bugs.python.org/issue47216 opened by ellaellela
#47217: adding name to BZ2File
https://bugs.python.org/issue47217 opened by ellaellela
#47218: adding name to lzmafile
https://bugs.python.org/issue47218 opened by ellaellela
#47219: asyncio with two interpreter instances
https://bugs.python.org/issue47219 opened by mbadaire
#47220: Document the optional callback parameter of weakref.WeakMethod
https://bugs.python.org/issue47220 opened by maggyero
#47222: subprocess.Popen() should allow capturing output and sending i
https://bugs.python.org/issue47222 opened by pprindeville
#47228: Document that na??ve datetime objects represent local time
https://bugs.python.org/issue47228 opened by p-ganssle
#47231: TarFile.getmember cannot work on tar sourced directory over 10
https://bugs.python.org/issue47231 opened by cfernald
#47233: show_caches option affects code positions reported by dis.get_
https://bugs.python.org/issue47233 opened by 15r10nk
#47234: PEP-484 "numeric tower" approach makes it hard/impossible to s
https://bugs.python.org/issue47234 opened by tfish2
#47236: Document types.CodeType.replace() changes about co_exceptionta
https://bugs.python.org/issue47236 opened by vstinner
#47237: Inheritance from base class with property in class makes them
https://bugs.python.org/issue47237 opened by Germandrummer92
#47238: Python threading.Event().wait() depends on the system time
https://bugs.python.org/issue47238 opened by AleksandrAQ
#47240: Python 3.x built for ppc+ppc64 errs on: No module named 'msvcr
https://bugs.python.org/issue47240 opened by barracuda156
#47241: [C API] Move the PyCodeObject structure to the internal C API
https://bugs.python.org/issue47241 opened by vstinner
#47242: Annoying white bar in IDLE (line 457 in sidebar.py)
https://bugs.python.org/issue47242 opened by antudic
#47243: Duplicate entry in 'Objects/unicodetype_db.h'
https://bugs.python.org/issue47243 opened by LiarPrincess
#47244: email.utils.formataddr does not respect double spaces
https://bugs.python.org/issue47244 opened by AlecRosenbaum
#47247: Default arguments for access 'mode' parameters in pathlib and
https://bugs.python.org/issue47247 opened by AidanWoolley
#47248: Possible slowdown of
[Python-Dev] Re: Declarative imports
You only get the ease-of-implementation benefit if you are willing to explicitly mark every _use_ of a lazy-imported name as special (and give the fully qualified name at every usage site). This is rather more cumbersome (assuming multiple uses in a module) than just explicitly marking an import as lazy in one location and then using the imported name in multiple places normally. Other "lazy import" solutions are trying to solve a problem where you want the name to be usable (without special syntax or marking) in many different places in a module, and visible in the module namespace always -- but not actually imported until someone accesses/uses it. The difficulty arises because in this case you need some kind of placeholder for the "deferred import", but you need to avoid this "deferred object" escaping and becoming visible to Python code without being resolved first. Explicitly marking which imports are lazy is fine if you want it (it's just a matter of syntax), but it doesn't do anything to solve the problem of allowing usage of the lazy-imported name to be transparent. I agree that the idea that top-of-module imports help readability is overstated; it sounds slightly Stockholm-syndrome-ish to me :) Top-of-module imports are frankly a pain to maintain and a pain to read (because they are often distant from the uses of the names). But they are a necessary evil if you want a) namespaces and b) not constantly retyping fully-qualified names at every usage site. Python is pretty committed to namespaces at this point (and I wouldn't want to change that), so that leaves the choice between top-of-module imports vs fully qualifying every use of every name; pick your poison. (Inline imports in a scope with multiple uses are a middle ground.) Carl _______ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/N4T2YMPHBLJXKCFA5CIPBFIZJJKO7SHR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2022-03-25 - 2022-04-01) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open7153 ( +8) closed 51763 (+61) total 58916 (+69) Open issues with patches: 2902 Issues opened (49) == #46907: Update Windows and MacOS installer to SQLite 3.38.2 https://bugs.python.org/issue46907 reopened by ned.deily #47122: Fix the table of methods in the collections.abc documentation https://bugs.python.org/issue47122 opened by maggyero #47123: ZipFile.writestr should respect SOURCE_DATE_EPOCH https://bugs.python.org/issue47123 opened by ghost43 #47124: explore hashlib use of the Apple CryptoKit macOS https://bugs.python.org/issue47124 opened by gregory.p.smith #47125: Explore hashlib use of the Windows Crypto API NG https://bugs.python.org/issue47125 opened by gregory.p.smith #47131: Speedup test_unparse https://bugs.python.org/issue47131 opened by jkloth #47132: Move tests from setobject.c to _testcapimodule https://bugs.python.org/issue47132 opened by arhadthedev #47133: enhance unittest to show test name and docstring on one line https://bugs.python.org/issue47133 opened by ethan.furman #47134: Document the meaning of the number in OverflowError https://bugs.python.org/issue47134 opened by steven.daprano #47135: Allow decimal.localcontext to accept keyword arguments to set https://bugs.python.org/issue47135 opened by steven.daprano #47136: Wrong value assigned automatically to the variable __module__ https://bugs.python.org/issue47136 opened by Takuo Matsuoka #47138: Pin Jinja2 to fix docs build https://bugs.python.org/issue47138 opened by hugovk #47139: pthread_sigmask needs SIG_BLOCK behaviour explaination https://bugs.python.org/issue47139 opened by rpurdie #47140: configure --enable-optimizations with clang *12* fails to dete https://bugs.python.org/issue47140 opened by ofekshilon #47141: EmailMessage may lack Mime-Version https://bugs.python.org/issue47141 opened by Vlastimil.Z??ma #47142: Document importlib.resources.abc.Traversable https://bugs.python.org/issue47142 opened by petr.viktorin #47143: Add types.copy_class() which updates closures https://bugs.python.org/issue47143 opened by vstinner #47144: Allow setting __classcell__ https://bugs.python.org/issue47144 opened by douglas-raillard-arm #47145: Improve graphlib.TopologicalSort by removing the prepare step https://bugs.python.org/issue47145 opened by larry #47147: Allow `return yield from` https://bugs.python.org/issue47147 opened by pxeger #47149: DatagramHandler doing DNS lookup on every log message https://bugs.python.org/issue47149 opened by bmerry #47150: HTTPRedirectHandler fails on POST for 307 and 308 https://bugs.python.org/issue47150 opened by Jairo Llopis #47152: Reorganize the re module sources https://bugs.python.org/issue47152 opened by serhiy.storchaka #47153: __doc__ should generally be writable https://bugs.python.org/issue47153 opened by pitrou #47154: -arch detection in _osx_support generates false positiv https://bugs.python.org/issue47154 opened by isuruf #47156: IDLE: make use of extended SyntaxError info. https://bugs.python.org/issue47156 opened by terry.reedy #47158: logging.handlers.SysLogHandler doesn't get cleaned up properly https://bugs.python.org/issue47158 opened by ngie #47159: multiprocessing.pool.Pool.apply block infinitely when stressed https://bugs.python.org/issue47159 opened by harsh8398 #47161: pathlib method relative_to doesnt work with // in paths https://bugs.python.org/issue47161 opened by John15321 #47164: [C API] Add private "CAST" macros to clean up casts in C code https://bugs.python.org/issue47164 opened by vstinner #47165: [C API] Test that the Python C API is compatible with C++ https://bugs.python.org/issue47165 opened by vstinner #47166: Dataclass transform should ignore TypeAlias variables https://bugs.python.org/issue47166 opened by thomkeh #47167: Allow overriding future-task compliance check in asyncio https://bugs.python.org/issue47167 opened by asvetlov #47168: Improvements for stable ABI definition files https://bugs.python.org/issue47168 opened by petr.viktorin #47169: Stable ABI: Some optional (#ifdef'd) functions aren't handled https://bugs.python.org/issue47169 opened by petr.viktorin #47174: Define behavior of descriptor-typed fields on dataclasses https://bugs.python.org/issue47174 opened by debonte #47175: Allow applications to tune the condition that triggers a GIL r https://bugs.python.org/issue47175 opened by gregory.p.smith #47176: Interrupt handling for wasm32-emscripten builds without pthrea https://bugs.python.org/issue47176 opened by hoodmane #47177: Frames should store next_instr instead of lasti https://bugs.python.org/issue47177 opened by brandtbucher #47179: pymalloc should align to max_align_t https://bugs.
[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]
> On 29 Mar 2022, at 19:51, Brett Cannon wrote: > > > > On Tue, Mar 29, 2022 at 8:58 AM Ronald Oussoren <mailto:ronaldousso...@mac.com>> wrote: > > >> On 29 Mar 2022, at 00:34, Brett Cannon > <mailto:br...@python.org>> wrote: >> >> >> >> Once >> https://mail.python.org/archives/list/python-committ...@python.org/thread/5EUZLT5PNA4HT42NGB5WVN5YWW5ASTT5/ >> >> <https://mail.python.org/archives/list/python-committ...@python.org/thread/5EUZLT5PNA4HT42NGB5WVN5YWW5ASTT5/> >> is considered resolved, the next part of my "what is the stdlib" plan is to >> finally try to suss all of this out and more-or-less write a stdlib policy >> PEP so we stop talking about this. My guess it will be more of guidance >> about what we want the stdlib to be and thus guide what things belong in it. >> No ETA on that work since I also have four other big Python projects on the >> go right now whose work I am constantly alternating between. > > Having such a policy is a good thing and helps in evolving the stdlib, but I > wonder if the lack of such a document is the real problem. IMHO the main > problem is that the CPython team is very small and therefore has little > bandwidth for maintaining, let alone evolving, large parts of the stdlib. In > that it doesn’t help that some parts of the stdlib have APIs that make it > hard to make modifications (such as distutils where effectively everything is > part of the public API). Shrinking the stdlib helps in the maintenance > burden, but feels as a partial solution. > > You're right that is the fundamental problem. But for me this somewhat stems > from the fact that we don't have a shared understanding of what the stdlib > is, and so the stdlib is a bit unbounded in its size and scope. That leads > to a stdlib which is hard to maintain. That (the hard to maintain part) is not necessarily true, if we had enough resources…. In theory the stdlib could be split into logical parts with teams that feel responsible for those parts (similar to having maintainers sign up for various platforms). That doesn’t work because of the small team, and partially also due to necessarily having very strict rules w.r.t. backward compatibility. > It's just like dealing with any scarce resource: you try to cut back on your > overall use as best as you can and then become more efficient with what you > must still consume; I personally think we don't have an answer to the "must > consume" part of that sentence that leads us to "cut back" to a size we can > actually keep maintained so we don't have 1.6K open PRs > <https://github.com/python/cpython/pulls>. I agree, but this is something to state explicitly when describing what should and should not be in scope for the stdlib. I’m a fan of a batteries included stdlib, but with our current resources we cannot afford to have some bits in the stdlib that would “obviously” be a candidate for a modern batteries included stdlib, such as a decent HTTP stack with support for HTTP/1, /2 and /3. Ronald — Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/JS23QUVXW3HZHQFMZBOXUCKT332KGRYS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API
Got it, thanks for the clarifications! Tracking 3.x Python versions is fine. We already need to do that to support things like new bytecodes, and PyTorch supports an explicit list of 3.x Python versions with separate builds for each. Tracking 3.x.y Python versions would be much more painful, and make us need to rethink our approach. So what Steve Downer described as "remain compatible within a single 3.x release", seems like exactly what we want. I support that level of compatibility guarantee. Could we keep that guarantee with this change? Thanks, Jason From: Victor Stinner Sent: Wednesday, March 30, 2022 7:56 AM To: Steve Dower Cc: Jason Ansel; python-dev@python.org Subject: Re: [Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API On Wed, Mar 30, 2022 at 2:26 AM Steve Dower wrote: > Right now, the API is allowed/expected to change between 3.x releases > (which normally we don't allow without a deprecation period) but it > still has to remain compatible within a single 3.x release. Making it > fully internal *without adding a stability guarantee* means it could > change more frequently, which you wouldn't be able to handle as an > installable package. > > It's *unlikely* that it'll change that often, because there are still > other public interfaces that cannot. But, the plan behind this is to > make more stuff internal so that it can be modified more freely, so we > may see that rate of change increase. Well, my plan is not break these internal C API just for fun. It's only to better "advertise" the separation between the "stable" public C API (backward compatibility warranty) and the "unstable" private/internal C API (can change any time, changes are not documented). Victor -- Night gathers, and now my watch begins. It shall not end until my death. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/U7M65SSDZMM7LNAKEDZZ4KKQIFTCOQ2M/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]
> On 29 Mar 2022, at 00:34, Brett Cannon wrote: > > > > On Mon, Mar 28, 2022 at 11:52 AM Christopher Barker <mailto:python...@gmail.com>> wrote: > On Mon, Mar 28, 2022 at 11:29 AM Paul Moore <mailto:p.f.mo...@gmail.com>> wrote: > To be honest, I feel like I'm just reiterating stuff I've said before > here, and I think the same is true of the points I'm responding to > ... > (I'm not *against* going over the debate again, > it helps make sure people haven't changed their minds, but it's > important to be clear that none of the practical facts have changed, > if that is the case). > > Maybe there's a way to make this discussion (it feels more like a discussion > than debate at the moment) more productive by writing some things down. I'm > not sure it's a PEP, but some kind of: > > "policy for the stdlib" document in which we could capture the primary points > of view, places where there's consensus, etc. would be helpful to keep us > retreading this over and over again. > > I suggest this without the bandwidth to actually shepherd the project, but if > someone wants to, I think it would be a great idea. > > Once > https://mail.python.org/archives/list/python-committ...@python.org/thread/5EUZLT5PNA4HT42NGB5WVN5YWW5ASTT5/ > > <https://mail.python.org/archives/list/python-committ...@python.org/thread/5EUZLT5PNA4HT42NGB5WVN5YWW5ASTT5/> > is considered resolved, the next part of my "what is the stdlib" plan is to > finally try to suss all of this out and more-or-less write a stdlib policy > PEP so we stop talking about this. My guess it will be more of guidance about > what we want the stdlib to be and thus guide what things belong in it. No ETA > on that work since I also have four other big Python projects on the go right > now whose work I am constantly alternating between. Having such a policy is a good thing and helps in evolving the stdlib, but I wonder if the lack of such a document is the real problem. IMHO the main problem is that the CPython team is very small and therefore has little bandwidth for maintaining, let alone evolving, large parts of the stdlib. In that it doesn’t help that some parts of the stdlib have APIs that make it hard to make modifications (such as distutils where effectively everything is part of the public API). Shrinking the stdlib helps in the maintenance burden, but feels as a partial solution. That said, I have no ideas on how a better stdlib development proces would look like, let alone on how to get there. Ronald > > -Brett > > > -CHB > > -- > Christopher Barker, PhD (Chris) > > Python Language Consulting > - Teaching > - Scientific Software Development > - Desktop GUI and Web Development > - wxPython, numpy, scipy, Cython > ___ > Python-Dev mailing list -- python-dev@python.org > <mailto:python-dev@python.org> > To unsubscribe send an email to python-dev-le...@python.org > <mailto:python-dev-le...@python.org> > https://mail.python.org/mailman3/lists/python-dev.python.org/ > <https://mail.python.org/mailman3/lists/python-dev.python.org/> > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/GAZAFRFVJVQZMEIHTQUJASP7VRAKA5RR/ > > <https://mail.python.org/archives/list/python-dev@python.org/message/GAZAFRFVJVQZMEIHTQUJASP7VRAKA5RR/> > Code of Conduct: http://python.org/psf/codeofconduct/ > <http://python.org/psf/codeofconduct/> > ___ > Python-Dev mailing list -- python-dev@python.org > <mailto:python-dev@python.org> > To unsubscribe send an email to python-dev-le...@python.org > <mailto:python-dev-le...@python.org> > https://mail.python.org/mailman3/lists/python-dev.python.org/ > <https://mail.python.org/mailman3/lists/python-dev.python.org/> > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/PC67DOLDEQXIAGXEB2QXCGS3C4B6PTCY/ > > <https://mail.python.org/archives/list/python-dev@python.org/message/PC67DOLDEQXIAGXEB2QXCGS3C4B6PTCY/> > Code of Conduct: http://python.org/psf/codeofconduct/ > <http://python.org/psf/codeofconduct/> — Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/XHETPUVT6UYWQ5URQNF6IQBFBZRPGMN6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API
The PyTorch team plans to use PEP 523 as a part of PyTorch 2.0, so this proposal may break the next major release of PyTorch. The related project is TorchDynamo, which can be found here: https://github.com/facebookresearch/torchdynamo We will likely move this into the core of PyTorch closer to release. If the changed happens, would PyTorch still be able to use the eval frame API? Or would it prevent from being used entirely? ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/RVQ7LDIJ2OYAN4QMIPTI3A3PODGBLNN7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: import * and __future__ imports
On Mon, Mar 28, 2022 at 4:44 PM Guido van Rossum wrote: > > "Future" imports are special to the parser, and they may also set a flag > for the runtime to alter its behavior, but they are intentionally not > treated specially by code generation, so they are still properly imported. > However the presence of the imported thing is not used by the runtime to > determine its behavior; those flags are stored elsewhere guided by the code > generator. > Right, this is why it's confusing when the object is there for no reason (the future import did not have any impact on the module, but the object showed up via an import *). > I don't think there's anything to do here. > How about the suggestion in https://bugs.python.org/issue26120 ? It's about these objects showing up in pydoc (both when the __future__ had an impact and when it didn't - in either case it's not an interesting part of the module's API). _______ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/JVHTGPOZX72J73SUVKGEWBXHKK4KIFAV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] import * and __future__ imports
If you have a __future__ import in a script, and you import * from it in another script, the object for this future appears in the dir() of the other script, even though the __future__ import has no effect there. % cat x.py from __future__ import annotations % cat y.py from x import * print(dir()) class D: def f(self, a: D): return 42 % ./python.exe y.py ['__annotations__', '__builtins__', '__cached__', '__doc__', '__file__', '__loader__', '__name__', '__package__', '__spec__', 'annotations'] Traceback (most recent call last): File "/Users/iritkatriel/src/cpython-654/y.py", line 5, in class D: File "/Users/iritkatriel/src/cpython-654/y.py", line 6, in D def f(self, a: D): ^ NameError: name 'D' is not defined I think we should change import * to exclude the __future__ import objects, and perhaps also to not show them in dir(x). Any objections? This came up in the discussion about https://bugs.python.org/issue26120 . See the attached PR for a technique we can use to identify those objects. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/3BUUCY2OHZILBJLOTS6I33M5YW4INDW3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2022-03-18 - 2022-03-25) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open7145 (-20) closed 51702 (+82) total 58847 (+62) Open issues with patches: 2903 Issues opened (53) == #45618: Documentation builds fail with Sphinx 3.2.1 https://bugs.python.org/issue45618 reopened by Maciej Olko #46429: Merge all deepfrozen files into one https://bugs.python.org/issue46429 reopened by kumaraditya303 #46864: Deprecate ob_shash in BytesObject https://bugs.python.org/issue46864 reopened by christian.heimes #46975: clang: error: linker command failed with exit code 1 (use -v t https://bugs.python.org/issue46975 reopened by jaraco #47060: importlib.metadata.version can return None https://bugs.python.org/issue47060 opened by David Robertson #47061: Deprecate modules listed in PEP 594 https://bugs.python.org/issue47061 opened by brett.cannon #47063: SimpleHTTPRequestHandler has hard coded index page list. https://bugs.python.org/issue47063 opened by myronww #47064: thread QOS attribute on macOS https://bugs.python.org/issue47064 opened by ronaldoussoren #47065: test_curses fails if terminal defaults to bright white text (1 https://bugs.python.org/issue47065 opened by ncoghlan #47067: Add vectorcall for generic alias object https://bugs.python.org/issue47067 opened by penguin_wwy #47068: Improve __repr__ of TypeVar https://bugs.python.org/issue47068 opened by ktbarrett #47069: socket._GLOBAL_DEFAULT_TIMEOUT being an object() makes for ugl https://bugs.python.org/issue47069 opened by ferdnyc #47070: Improve performance of array_inplace_repeat https://bugs.python.org/issue47070 opened by pieter.eendebak #47071: asyncio proactor udp transport stops responding after send to https://bugs.python.org/issue47071 opened by esoma #47072: Database corruption with the shelve module https://bugs.python.org/issue47072 opened by HubTou #47073: Solution for recursion error when comparing dataclass objects https://bugs.python.org/issue47073 opened by dankner #47074: Convenient `simplefilter()` in `warnings.catch_warnings()` https://bugs.python.org/issue47074 opened by Zac Hatfield-Dodds #47075: test_multiprocessing_spawn leaks QueueManager dangling process https://bugs.python.org/issue47075 opened by vstinner #47077: test_asyncio ignores exception in _ProactorBasePipeTransport._ https://bugs.python.org/issue47077 opened by vstinner #47078: test_ctypes modified files on aarch64 Fedora Rawhide 3.9: ldco https://bugs.python.org/issue47078 opened by vstinner #47079: Integral.denominator shouldn't return an int https://bugs.python.org/issue47079 opened by Sergey.Kirpichev #47082: No protection: `import numpy` in two different threads can lea https://bugs.python.org/issue47082 opened by jhgoebbert #47083: The __complex__ method is missing from the complex, float, and https://bugs.python.org/issue47083 opened by maggyero #47086: Include HTML docs with Windows installer instead of CHM https://bugs.python.org/issue47086 opened by steve.dower #47087: Implement PEP 655 (Required/NotRequired) https://bugs.python.org/issue47087 opened by JelleZijlstra #47088: Implement PEP 675 (LiteralString) https://bugs.python.org/issue47088 opened by JelleZijlstra #47089: Avoid sporadic failure of test_compileall on Windows https://bugs.python.org/issue47089 opened by jkloth #47090: Make zlib required on all platforms (simplifies code) https://bugs.python.org/issue47090 opened by gregory.p.smith #47091: Improve performance of list and tuple repeat methods https://bugs.python.org/issue47091 opened by pieter.eendebak #47092: [C API] Add PyFrame_GetVar(frame, name) function https://bugs.python.org/issue47092 opened by vstinner #47093: Documentation Fix: Remove .bat when activating venv on windows https://bugs.python.org/issue47093 opened by jovinator #47095: Prefer libb2 over vendored copy of blake2 https://bugs.python.org/issue47095 opened by christian.heimes #47096: Use the PDH API in WindowsLoadTracker https://bugs.python.org/issue47096 opened by eryksun #47097: Document PEP 646 https://bugs.python.org/issue47097 opened by JelleZijlstra #47098: sha3: Replace Keccak Code Package with tiny_sha3 https://bugs.python.org/issue47098 opened by christian.heimes #47099: Replace with_traceback() with exception chaining and reraising https://bugs.python.org/issue47099 opened by arhadthedev #47100: Help text for Store Python shows "null" under usage https://bugs.python.org/issue47100 opened by steve.dower #47101: hashlib.algorithms_available lists algorithms that are not ava https://bugs.python.org/issue47101 opened by christian.heimes #47102: explore hashlib use of the Linux Kernel CryptoAPI https://bugs.python.org/issue47102 opened by gregory.p.smith #47103: Copy pgort140.dll when building for
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2022-03-11 - 2022-03-18) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open7165 (-68) closed 51620 (+139) total 58785 (+71) Open issues with patches: 2903 Issues opened (50) == #22628: Idle: Tree lines are spaced too close together. https://bugs.python.org/issue22628 reopened by exarkun #43253: asyncio open_connection fails when a socket is explicitly clos https://bugs.python.org/issue43253 reopened by asvetlov #45405: configure fails on macOS with non-Apple clang version 13 which https://bugs.python.org/issue45405 reopened by ned.deily #46948: [CVE-2022-26488] Escalation of privilege via Windows Installer https://bugs.python.org/issue46948 reopened by steve.dower #46989: signal.signal, et al, doesn't support [SIGRTMIN,SIGRTMAX] on F https://bugs.python.org/issue46989 opened by ngie #46990: Surprising list overallocation from .split() https://bugs.python.org/issue46990 opened by tim.peters #46992: If use textwrap.dedent with string formatting, may get uninten https://bugs.python.org/issue46992 opened by xncbf12 #46997: Invalid memory write in bytearray https://bugs.python.org/issue46997 opened by JelleZijlstra #46998: Allow subclassing Any at runtime https://bugs.python.org/issue46998 opened by hauntsaninja #46999: test_multiprocessing_fork running without any timeout https://bugs.python.org/issue46999 opened by doko #47000: Make encoding="locale" uses locale encoding even in UTF-8 mode https://bugs.python.org/issue47000 opened by methane #47002: argparse - "expected one argument" when used -: in argument https://bugs.python.org/issue47002 opened by Pythass #47006: PEP 646: Decide on substitution behavior https://bugs.python.org/issue47006 opened by JelleZijlstra #47007: [doc] str docs are inconsistent with special method lookup https://bugs.python.org/issue47007 opened by itsvs #47009: Streamline list.append for the common case https://bugs.python.org/issue47009 opened by Dennis Sweeney #47010: Implement zero copy writes in SelectorSocketTransport in async https://bugs.python.org/issue47010 opened by kumaraditya303 #47011: Cloned turtle pen is not cleared completely https://bugs.python.org/issue47011 opened by learncoding #47012: Speed up iteration of bytes and bytearray https://bugs.python.org/issue47012 opened by kumaraditya303 #47013: test_bdb and test_distutils fail on installed Python 3.9, 3.10 https://bugs.python.org/issue47013 opened by vstinner #47014: ProactorEventLoop ignores Ctrl+C after closing unrelated loop https://bugs.python.org/issue47014 opened by mhils #47015: Update tests from asyncore to asyncio https://bugs.python.org/issue47015 opened by arhadthedev #47016: Create a test verifying bundled pip and setuptools wheels https://bugs.python.org/issue47016 opened by illia-v #47017: frozen modules are on by default in dev build https://bugs.python.org/issue47017 opened by gvanrossum #47019: Fatal Python Error in sqlite3 Python 3.10 https://bugs.python.org/issue47019 opened by hydroflask #47021: Add separate match and case doc to pydoc https://bugs.python.org/issue47021 opened by duckboycool #47022: PEP 594: Document removal of asynchat, asyncore and smtpd https://bugs.python.org/issue47022 opened by hugovk #47025: bytes do not work on sys.path https://bugs.python.org/issue47025 opened by graingert #47026: BytesWarning in zipimport paths on sys.path https://bugs.python.org/issue47026 opened by graingert #47027: subprocess.run(), subprocess.Popen() should accept file descri https://bugs.python.org/issue47027 opened by ydroneaud #47029: Fix a BrokenPipeError when a multiprocessing.Queue is garbage https://bugs.python.org/issue47029 opened by maggyero #47030: singledispatch does not work with positional arguments with de https://bugs.python.org/issue47030 opened by randolf.scholz #47031: math.nan should note that NANs do not compare equal to anythin https://bugs.python.org/issue47031 opened by steven.daprano #47037: Build problems on Windows https://bugs.python.org/issue47037 opened by terry.reedy #47040: Remove invalid versionchanged in doc https://bugs.python.org/issue47040 opened by malin #47043: Argparse can't parse subparsers with parse_known_args https://bugs.python.org/issue47043 opened by rive-n #47045: Remove the RESUME instruction https://bugs.python.org/issue47045 opened by Mark.Shannon #47046: Add `f_state` attribute to FrameObjects. https://bugs.python.org/issue47046 opened by Mark.Shannon #47047: smtplib: allow custom policy or use msg.policy in send_message https://bugs.python.org/issue47047 opened by Miksus #47048: Python 3.10.3 + Osx Lion : fatal error (make) signalmodule or https://bugs.python.org/issue47048 opened by laurentang001 #47049: Incorrect shutil.copytree() behaviour with symlinks htt
[Python-Dev] Re: Restrict the type of __slots__
> On 18 Mar 2022, at 14:37, Joao S. O. Bueno wrote: Please don’t toppost when responding to a normally threaded message. That makes it unnecessary hard to follow the conversation. > > IMO this is a purism that have little, if any place in language restrictions. > I see that not allowing. "run once" iterables could indeed void attempts to > write > "deliberatly non cooperative code" - but can it even be reliably detected? > > The other changes seem just to break backwards compatibility for little or no > gain at all. It may not be worth the trouble to fix this, but Serhiy’s proposal does try to fix a ward. It may be better to rely on linter’s here, but one way to do this with few backward compatibility concerns: - if __slots__ is a dict keep it as is - Otherwise use tuple(__slots__) while constructing the class and store that value in the __slots__ attribute of the class That way the value of the attribute reflects the slots that were created while not breaking code that uses __slots__ and doesn’t change the value after class creation. Ronald > > > > On Fri, Mar 18, 2022 at 6:57 AM Ronald Oussoren via Python-Dev > mailto:python-dev@python.org>> wrote: > > >> On 18 Mar 2022, at 10:29, Serhiy Storchaka > <mailto:storch...@gmail.com>> wrote: >> >> Currently __slots__ can be either string or an iterable of strings. >> >> 1. If it is a string, it is a name of a single slot. Third-party code which >> iterates __slots__ will be confused. >> >> 2. If it is an iterable, it should emit names of slots. Note that >> non-reiterable iterators are accepted too, but it causes weird bugs if >> __slots__ is iterated more than once. For example it breaks default pickling >> and copying. >> >> I propose to restrict the type of __slots__. Require it always been a tuple >> of strings. Most __slots__ in real code are tuples. It is rarely we need >> only single slot and set __slots__ as a string. >> >> It will break some code (there are 2 occurrences in the stdlib an 1 in >> scripts), but that code can be easily fixed. > > Pydoc supports __slots__ that is a dict, and will use the values in the dict > als documentation for the slots. I’ve also seen code using ``__slots__ = > “field1 field2”.split()``. I don’t particularly like this code pattern, but > your proposal would break this. > > Also note that __slots__ only has a side effect during class definition, > changing it afterwards is possible but has no effect (“class Foo: pass; > Foo.__slots__ = 42”). This surprised my recently and I have no idea if this > feature is ever used. > > Ronald > >> >> ___ >> Python-Dev mailing list -- python-dev@python.org >> <mailto:python-dev@python.org> >> To unsubscribe send an email to python-dev-le...@python.org >> <mailto:python-dev-le...@python.org> >> https://mail.python.org/mailman3/lists/python-dev.python.org/ >> <https://mail.python.org/mailman3/lists/python-dev.python.org/> >> Message archived at >> https://mail.python.org/archives/list/python-dev@python.org/message/E32BRLAWOU5GESMZ5MLAOIYPXSL37HOI/ >> >> <https://mail.python.org/archives/list/python-dev@python.org/message/E32BRLAWOU5GESMZ5MLAOIYPXSL37HOI/> >> Code of Conduct: http://python.org/psf/codeofconduct/ >> <http://python.org/psf/codeofconduct/> > > — > > Twitter / micro.blog: @ronaldoussoren > Blog: https://blog.ronaldoussoren.net/ <https://blog.ronaldoussoren.net/> > ___ > Python-Dev mailing list -- python-dev@python.org > <mailto:python-dev@python.org> > To unsubscribe send an email to python-dev-le...@python.org > <mailto:python-dev-le...@python.org> > https://mail.python.org/mailman3/lists/python-dev.python.org/ > <https://mail.python.org/mailman3/lists/python-dev.python.org/> > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/YQUWR7CYKNM65HR5FZQ3BANR5SNNK6N6/ > > <https://mail.python.org/archives/list/python-dev@python.org/message/YQUWR7CYKNM65HR5FZQ3BANR5SNNK6N6/> > Code of Conduct: http://python.org/psf/codeofconduct/ > <http://python.org/psf/codeofconduct/> — Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/FZFRSHSJ3HQU37V6RFZNHMFGJXUPJ32X/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Restrict the type of __slots__
> On 18 Mar 2022, at 10:29, Serhiy Storchaka wrote: > > Currently __slots__ can be either string or an iterable of strings. > > 1. If it is a string, it is a name of a single slot. Third-party code which > iterates __slots__ will be confused. > > 2. If it is an iterable, it should emit names of slots. Note that > non-reiterable iterators are accepted too, but it causes weird bugs if > __slots__ is iterated more than once. For example it breaks default pickling > and copying. > > I propose to restrict the type of __slots__. Require it always been a tuple > of strings. Most __slots__ in real code are tuples. It is rarely we need only > single slot and set __slots__ as a string. > > It will break some code (there are 2 occurrences in the stdlib an 1 in > scripts), but that code can be easily fixed. Pydoc supports __slots__ that is a dict, and will use the values in the dict als documentation for the slots. I’ve also seen code using ``__slots__ = “field1 field2”.split()``. I don’t particularly like this code pattern, but your proposal would break this. Also note that __slots__ only has a side effect during class definition, changing it afterwards is possible but has no effect (“class Foo: pass; Foo.__slots__ = 42”). This surprised my recently and I have no idea if this feature is ever used. Ronald > > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/E32BRLAWOU5GESMZ5MLAOIYPXSL37HOI/ > Code of Conduct: http://python.org/psf/codeofconduct/ — Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/YQUWR7CYKNM65HR5FZQ3BANR5SNNK6N6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2022-03-04 - 2022-03-11) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open7233 ( +9) closed 51481 (+56) total 58714 (+65) Open issues with patches: 2940 Issues opened (43) == #45138: [sqlite3] expand bound values in traced statements when possib https://bugs.python.org/issue45138 reopened by erlendaasland #46924: make install hangs when installing zoneinfo/_zoneinfo.py https://bugs.python.org/issue46924 opened by AmericanEnglish #46925: Document dict behavior when setting equal but not identical ke https://bugs.python.org/issue46925 opened by malthe #46926: runpy.run_path didn't set __package__ to None as describe in d https://bugs.python.org/issue46926 opened by yanhao.charles #46930: Iterating over cls.__dict__ in classmethod causes RuntimeError https://bugs.python.org/issue46930 opened by PythonF #46931: zipfile library will raise uncaught oserror when reading lengt https://bugs.python.org/issue46931 opened by ultimalium #46934: Started multiprocessing.Process instances are unserialisable https://bugs.python.org/issue46934 opened by maggyero #46938: dataclass __post_init__ recursion https://bugs.python.org/issue46938 opened by bar.harel #46939: Specialize calls for Python classes https://bugs.python.org/issue46939 opened by kj #46942: Convert Object/classobject.c to Argument Clinic https://bugs.python.org/issue46942 opened by arhadthedev #46943: fix[imaplib]: call Exception with string instance https://bugs.python.org/issue46943 opened by spaceone #46944: Use FASTCALL calling convention in generator.throw https://bugs.python.org/issue46944 opened by kumaraditya303 #46945: Quantifier and Expanded Regex Expression Gives Different Resul https://bugs.python.org/issue46945 opened by vmd3.14 #46946: Port core types to Argument Clinic https://bugs.python.org/issue46946 opened by arhadthedev #46949: Print an indication if traceback exceeds sys.tracebacklimit https://bugs.python.org/issue46949 opened by JelleZijlstra #46950: Windows 11 venv https://bugs.python.org/issue46950 opened by darrel.opry #46951: Zipapp contents are in filesystem-dependent order https://bugs.python.org/issue46951 opened by h.finucane #46953: use FASTCALL for __import__ builtin https://bugs.python.org/issue46953 opened by kumaraditya303 #46956: TextIOWrapper.seek silently wraps around on very large offsets https://bugs.python.org/issue46956 opened by vlaci #46957: Logger with a custom class breaks on copy https://bugs.python.org/issue46957 opened by govinda18 #46958: json dump/dumps prints each array element on a new line (bad f https://bugs.python.org/issue46958 opened by Entirity #46959: ctypes.util.find_library can delete /dev/null https://bugs.python.org/issue46959 opened by barry.c.davis #46960: Docs: Link from settrace to frame https://bugs.python.org/issue46960 opened by guettli #46961: Caching/interning of small ints sometimes fails https://bugs.python.org/issue46961 opened by steven.daprano #46962: Fix docstrings that do not honor --without-doc-strings https://bugs.python.org/issue46962 opened by arhadthedev #46963: Deep Lazy Imports - Interpreter-level deferred module loading https://bugs.python.org/issue46963 opened by Kronuz #46964: The global config should not be stored on each interpreter https://bugs.python.org/issue46964 opened by eric.snow #46965: Enable informing callee it's awaited via vector call flag https://bugs.python.org/issue46965 opened by dino.viehland #46966: c_void_p array is a footgun on I32LP64 systems https://bugs.python.org/issue46966 opened by taralx #46967: Type union for except https://bugs.python.org/issue46967 opened by Henry Schreiner #46968: Insufficient sigaltstack size used by CPython prevents extensi https://bugs.python.org/issue46968 opened by oleksandr-pavlyk #46970: dataclass(slots=True) incompatible with __init_subclass__ https://bugs.python.org/issue46970 opened by crusaderky #46973: Provide make target to regenerate autoconf files with containe https://bugs.python.org/issue46973 opened by christian.heimes #46975: clang: error: linker command failed with exit code 1 (use -v t https://bugs.python.org/issue46975 opened by Battant #46976: Update macOS installer builds to use ncurses 6.3 https://bugs.python.org/issue46976 opened by ned.deily #46977: tempfile.TemporaryDirectory fails removing dir in some edge ca https://bugs.python.org/issue46977 opened by afeblot #46978: Doc strings for built-in, in-place operators are misleading https://bugs.python.org/issue46978 opened by nickovs #46981: Empty typing.Tuple https://bugs.python.org/issue46981 opened by serhiy.storchaka #46983: test_sqlite3: test_trace_too_much_expanded_sql() failed on AMD https://bugs.python.org/issue46983 opened by vstinner #46984: test_concurrent_futures logs many
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2022-02-25 - 2022-03-04) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open7224 ( +4) closed 51425 (+62) total 58649 (+66) Open issues with patches: 2938 Issues opened (48) == #44807: typing.Protocol silently overrides __init__ method of delivere https://bugs.python.org/issue44807 reopened by gvanrossum #46623: test_zlib: test_pair() and test_speech128() fail with s390x ha https://bugs.python.org/issue46623 reopened by petr.viktorin #46823: Add LOAD_FAST__LOAD_ATTR_INSTANCE_VALUE combined opcode https://bugs.python.org/issue46823 reopened by brandtbucher #46858: mmap constructor resets the file pointer on Windows https://bugs.python.org/issue46858 opened by benrg #46860: `--with-suffix` not respected on case-insensitive file systems https://bugs.python.org/issue46860 opened by brett.cannon #46862: subprocess makes environment blocks with duplicate keys on Win https://bugs.python.org/issue46862 opened by benrg #46863: Python 3.10 OpenSSL Configuration Issues https://bugs.python.org/issue46863 opened by adam #46864: Deprecate ob_shash in BytesObject https://bugs.python.org/issue46864 opened by methane #46868: Improve performance of math.prod with bignums (and functools.r https://bugs.python.org/issue46868 opened by benrg #46870: Improper Input Validation in urlparse https://bugs.python.org/issue46870 opened by P0cas #46872: Odd handling of signal raised if an illegal syscall is attempt https://bugs.python.org/issue46872 opened by bup #46878: [sqlite3] remove "non-standard" from docstrings https://bugs.python.org/issue46878 opened by erlendaasland #46879: [doc] incorrect sphinx object names https://bugs.python.org/issue46879 opened by push-f #46880: zipfile library doesn't extract windows zip files properly on https://bugs.python.org/issue46880 opened by nimrodf #46881: Statically allocate and initialize the latin1 characters. https://bugs.python.org/issue46881 opened by kumaraditya303 #46882: Clarify argument type of platform.platform(aliased, terse) to https://bugs.python.org/issue46882 opened by Rotzbua #46883: Add glossary entries to clarify the true/True and false/False https://bugs.python.org/issue46883 opened by steven.daprano #46884: [doc] msilib.rst uses data directive to document modules https://bugs.python.org/issue46884 opened by push-f #46885: Ensure PEP 663 changes are reverted from 3.11 https://bugs.python.org/issue46885 opened by pablogsal #46887: ./Programs/_freeze_module fails with MSAN: Uninitialized value https://bugs.python.org/issue46887 opened by vstinner #46888: SharedMemory.close() destroys memory https://bugs.python.org/issue46888 opened by ronny-rentner #46890: venv does not create "python" link in python 3.11 https://bugs.python.org/issue46890 opened by ronaldoussoren #46892: Async Call-Stack Reconstruction https://bugs.python.org/issue46892 opened by mpage #46893: Allow extensions to set the vectorcall field on instances of P https://bugs.python.org/issue46893 opened by itamaro #46895: Allow extensions to set a callback to be invoked when a type i https://bugs.python.org/issue46895 opened by mpage #46896: add support for watching writes to selected dictionaries https://bugs.python.org/issue46896 opened by carljm #46897: Add API to allow extensions to set callback function on creati https://bugs.python.org/issue46897 opened by mpage #46898: Add API to allow extensions to set callback function on creati https://bugs.python.org/issue46898 opened by mpage #46899: use of uninitialized value with msan from subprocess_fork_exec https://bugs.python.org/issue46899 opened by yilei #46901: Deprecate and eventually remove macOS-only PYTHONEXECUTABLE en https://bugs.python.org/issue46901 opened by ned.deily #46902: Typo hint message for from-imports? https://bugs.python.org/issue46902 opened by Jean_Abou_Samra #46903: Crash when setting attribute with string subclass as the name https://bugs.python.org/issue46903 opened by ronaldoussoren #46904: Python Decimal supports '#' format, C Decimal does not. https://bugs.python.org/issue46904 opened by const #46905: winsound.PlaySound should accept pathlib.Path instances https://bugs.python.org/issue46905 opened by Julian-O #46906: Add PyFloat_(Pack|Unpack)(2|4|8) to the public C API https://bugs.python.org/issue46906 opened by methane #46907: Update Windows and MacOS installer to SQLite 3.38.0. https://bugs.python.org/issue46907 opened by felixxm #46908: Debugger jumps to a wrong instruction in for loop https://bugs.python.org/issue46908 opened by franarenasafan #46911: Early tracing has lineno=None for modules https://bugs.python.org/issue46911 opened by nedbat #46912: Full gc collection blocked from collecting after some amount o https://bugs.python.org/issue46912
[Python-Dev] Re: Defining tiered platform support
> On 4 Mar 2022, at 00:30, Brett Cannon wrote: > > Do we officially support NetBSD? Do you know how to find out if we do? You > might think to look at > https://www.python.org/dev/peps/pep-0011/#supporting-platforms > <https://www.python.org/dev/peps/pep-0011/#supporting-platforms> , but that > just loosely defines the criteria and it still doesn't list the actual > platforms we support. (BTW I don't know if we do officially support NetBSD, > hence this email.) > > I think we should clarify this sort of thing and be a bit more upfront with > the level of support we expect/provide for a platform. As such, I want to > restructure PEP 11 to list the platforms we support, not just list the > platforms we stopped supporting. To do this I want define 3 different tiers > that outline what our support requirements and promises are for platforms. > > Tier 1 is the stuff we run CI against: latest Windows, latest macOS, Linux w/ > the latest glibc (I don't know of a better way to define Linux support as I > don't know if a per-distro list is the right abstraction). These are > platforms we won't even let code be committed for if they would break; they > block releases if they don't work. These platforms we all implicitly promise > to support. > > Tier 2 is the platforms we would revert a change within 24 hours if they > broke: latest FeeBSD, older Windows, older macOS, Linux w/ older glibc.This > is historically the "stable buildbot plus a core dev" group of platforms. The > change I would like to see is two core devs (in case one is on vacation), and > a policy as to how a platform ends up here (e.g. SC must okay it based on > consensus of everyone). The stable buildbot would still be needed to know if > a release is blocked as we would hold a release up if they were red. The > platform and the core devs supporting these platforms would be listed in PEP > 11. What’s the difference between Tier 1 and 2 other than that PRs are checked with tier 1 platforms before committing and with tier 2 afterwards? In particular, tier 1 contains windows server and not desktop (even though I expect that those are compatible as far as our use is concerned), and does not contain the macOS versions that we actually support in the installers on python.org <http://python.org/> (macOS 10.9 or later, both x86_64 and arm64). AFAIK support for macOS 10.9 in the python.org <http://python.org/> installers is now primarily, if not only, tested by Ned. That could, and probably should, be automated but that’s a significant amount of work. […] > > > I don't know if we want to bother listing CPU architectures since we are a > pure C project which makes CPU architecture less of a thing, but I'm > personally open to the idea of CPU architectures being a part of the platform > definition. CTypes is hardware specific, although through libiff. There’s also intermittent discussions about support for ancient hardware platforms. Would we block a release when (for example) support for Linux on sparc32 is broken? Ronald — Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/VDCMUXNSAMJGSHD6A235WBDHI7YETLVQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2022-02-18 - 2022-02-25) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open7220 ( +2) closed 51363 (+64) total 58583 (+66) Open issues with patches: 2939 Issues opened (46) == #46793: expose expat XML billion laughs attack mitigation APIs https://bugs.python.org/issue46793 opened by gregory.p.smith #46794: Please update bundled libexpat to 2.4.6 with security fixes (5 https://bugs.python.org/issue46794 opened by sping #46797: ast.Constant.n deprecated without warning https://bugs.python.org/issue46797 opened by jwilk #46798: xml.etree.ElementTree: get() doesn't return default value, alw https://bugs.python.org/issue46798 opened by padremayi #46799: ShareableList memory bloat and performance improvement https://bugs.python.org/issue46799 opened by tcl326 #46803: Item not shown when using mouse wheel to scroll for Listbox/Co https://bugs.python.org/issue46803 opened by Jason990420 #46805: Add low level UDP socket functions to asyncio https://bugs.python.org/issue46805 opened by alex.gronholm #46806: Overlapping PYTHONPATH may cause import already imported modul https://bugs.python.org/issue46806 opened by aklajnert #46808: remove NEXT_BLOCK() from compile.c https://bugs.python.org/issue46808 opened by iritkatriel #46809: copy.deepcopy can fail with unhelpful diagnostics https://bugs.python.org/issue46809 opened by remdragon #46810: multiprocessing.connection.Client doesn't support ipv6 https://bugs.python.org/issue46810 opened by mhupfer #46811: Test suite needs adjustments for Expat >=2.4.5 https://bugs.python.org/issue46811 opened by sping #46812: Thread starvation with threading.Condition https://bugs.python.org/issue46812 opened by msg555 #46814: Documentation for constructing abstract base classes is mislea https://bugs.python.org/issue46814 opened by Yoshanuikabundi #46815: Extra `DeprecationWarning` when running `lib2to3` tests https://bugs.python.org/issue46815 opened by sobolevn #46816: Remove declarations for non-__STDC__ compilers https://bugs.python.org/issue46816 opened by arhadthedev #46817: Add a line-start table to the code object. https://bugs.python.org/issue46817 opened by Mark.Shannon #46823: Add LOAD_FAST__LOAD_ATTR_INSTACE_VALUE combined opcode https://bugs.python.org/issue46823 opened by Dennis Sweeney #46824: use AI_NUMERICHOST | AI_NUMERICSERV to skip getaddrinfo thread https://bugs.python.org/issue46824 opened by graingert #46826: prefixes argument to site.getsitepackages() missing documentat https://bugs.python.org/issue46826 opened by asnell #46828: math.prod can return integers (contradicts doc) https://bugs.python.org/issue46828 opened by neilwebber #46829: Confusing CancelError message if multiple cancellations are sc https://bugs.python.org/issue46829 opened by asvetlov #46831: Outdated comment for __build_class__ in compile.c https://bugs.python.org/issue46831 opened by hauntsaninja #46832: unicodeobject.c doesn't compile when defined EXPERIMENTAL_ISOL https://bugs.python.org/issue46832 opened by moytrage #46833: Installer Wizard is unclear and has redundant settings https://bugs.python.org/issue46833 opened by buhtz #46834: test_gdb started to fail on buildbot/s390x RHEL7 https://bugs.python.org/issue46834 opened by sobolevn #46835: ImportError: bad magic number in ... does not indicate where i https://bugs.python.org/issue46835 opened by hroncok #46836: [C API] Move PyFrameObject to the internal C API https://bugs.python.org/issue46836 opened by vstinner #46838: Parameters and arguments parser syntax error improvments https://bugs.python.org/issue46838 opened by Andy_kl #46840: xmlrpc.client.ServerProxy shows password in __repr__ when usin https://bugs.python.org/issue46840 opened by perrinjerome #46841: Inline bytecode caches https://bugs.python.org/issue46841 opened by brandtbucher #46842: py to pyc location mapping with sys.pycache_prefix isn't 1-to- https://bugs.python.org/issue46842 opened by benrg #46843: PersistentTaskGroup API https://bugs.python.org/issue46843 opened by achimnol #46845: dict: Use smaller entry for Unicode-key only dict. https://bugs.python.org/issue46845 opened by methane #46846: functools.partial objects should set __signature__ and _annota https://bugs.python.org/issue46846 opened by larry #46847: functools.update_wrapper doesn't understand partial objects an https://bugs.python.org/issue46847 opened by larry #46848: Use optimized string search function in mmap.find() https://bugs.python.org/issue46848 opened by rumpelsepp #46849: Memory problems detected using Valgrind https://bugs.python.org/issue46849 opened by sxt1001 #46850: [C API] Move _PyEval_EvalFrameDefault() to the internal C API https://bugs.python.org/issue46850 opened by vstinner #46851: Docum
[Python-Dev] Re: PEP 683: "Immortal Objects, Using a Fixed Refcount"
Hey Inada, thanks for the feedback > Generally speaking, fork is a legacy API. It is too difficult to know which > library is fork-safe, even for stdlibs. Yes, this is something that Instagram has to go into great lengths to make sure that we get the entire execution into a state where it's safe to fork. It works, but it's hard to maintain. We'd rather have a simpler model! > I hope per-interpreter GIL replaces fork use cases. We hope so too, hence the big push towards having immutable shared state across the interpreters. For large applications like Instagram, this is a must, otherwise copying state into every interpreter would be too costly. > Anyway, I don't believe stopping refcounting will fix the CoW issue yet. See > this article [1] again. That article is five years old so it doesn't reflect the current state of the system! We have continuous profiling and monitoring of Copy on Writes and after introducing the techniques described in this PEP, we have largely fixed the majority of scenarios where this happens. You are right in the fact that just addressing reference counting will not fix all CoW issues. The trick here is also to leverage the permanent GC generation used for the `gc.freeze` API. That is, if you have a container that it's known to be immortal, it should be pushed into the permanent GC generation. This will guarantee that the GC itself will not change the GC headers of said instance. Thus, if you immortalize your heap before forking (using the techniques in: https://github.com/python/cpython/pull/31489) then you'll end up removing the vast majority of scenarios where CoW takes place. I can look into writing a new technical article for Instagram with more up to date info but this might take time to get through! Now, I said that we've largely fixed the CoW issue because there are still places where it happens such as: free lists, the small object allocator, etc. But these are relatively small compared to the ones coming from reference counts and the GC head mutations. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/TBXKYD6OOR7I5QAMTE3VAJT5YCDISOET/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] A memory map based data persistence and startup speedup approach
Hi folks, as illustrated in faster-cpython#150 [1], we have implemented a mechanism that supports data persistence of a subset of python date types with mmap, therefore can reduce package import time by caching code object. This could be seen as a more eager pyc format, as they are for the same purpose, but our approach try to avoid [de]serialization. Therefore, we get a speedup in overall python startup by ~15%. Currently, we’ve made it a third-party library and have been working on open-sourcing. Our implementation (whose non-official name is “pycds”) mainly contains two parts: importlib hooks, this implements the mechanism to dump code objects to an archive and a `Finder` that supports loading code object from mapped memory. Dumping and loading (subset of) python types with mmap. In this part, we deal with 1) ASLR by patching `ob_type` fields; 2) hash seed randomization by supporting only basic types who don’t have hash-based layout (i.e. dict is not supported); 3) interned string by re-interning strings while loading mmap archive and so on. After pycds has been installed, complete workflow of our approach includes three parts: Record name of imported packages to heap.lst, `PYCDSMODE=TRACE PYCDSLIST=heap.lst python run.py` Dump memory archive of code objects of imported packages, this step does not involve the python script, `PYCDSMODE=DUMP PYCDSLIST=heap.lst PYCDSARCHIVE=heap.img python` Run other python processes with created archive, `PYCDSMODE=SHARE PYCDSARCHIVE=heap.img python run.py` We could even make use of immortal objects if PEP 683 [2] was accepted, which could give CDS more performance improvements. Currently, any archived object is virtually immortal, we add rc by 1 to who has been copied to the archive to avoid being deallocated. However, without changes to CPython, rc fields of archived objects will still be updated, therefore have extra footprint due to CoW. More background and detailed implementation could be found at [1]. We think it could be an effective way to improve python’s startup performance, and could even do more like sharing large data between python instances. As suggested in python-ideas [3], we posted this here, looking for questions/suggestions to the overall design and workflow, we also welcome code reviews after we get our lawyers happy and can publish the code. Best, Yichen Yan Alibaba Compiler Group [1] “Faster startup -- Share code objects from memory-mapped file”, https://github.com/faster-cpython/ideas/discussions/150 [2] PEP 683: "Immortal Objects, Using a Fixed Refcount" (draft), https://mail.python.org/archives/list/python-dev@python.org/message/TPLEYDCXFQ4AMTW6F6OQFINSIFYBRFCR/ [3] [Python-ideas] "A memory map based data persistence and startup speedup approach", https://mail.python.org/archives/list/python-id...@python.org/thread/UKEBNHXYC3NPX36NS76LQZZYLRA4RVEJ/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/B77BQQFDSTPY4KA4HMHYXJEV3MOU7W3X/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2022-02-11 - 2022-02-18) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open7218 (+40) closed 51299 (+27) total 58517 (+67) Open issues with patches: 2932 Issues opened (52) == #46725: Unpacking without parentheses is allowed since 3.9 https://bugs.python.org/issue46725 opened by pablogsal #46726: Thread spuriously marked dead after interrupting a join call https://bugs.python.org/issue46726 opened by Kevin Shweh #46727: Should shutil functions support bytes paths? https://bugs.python.org/issue46727 opened by Jelle Zijlstra #46729: Better str() for BaseExceptionGroup https://bugs.python.org/issue46729 opened by iritkatriel #46731: posix._fcopyfile flags addition https://bugs.python.org/issue46731 opened by devnexen #46732: object.__bool__ docstring is wrong https://bugs.python.org/issue46732 opened by Jelle Zijlstra #46733: pathlib.Path methods can raise NotImplementedError https://bugs.python.org/issue46733 opened by barneygale #46734: Add Maildir.get_flags() to access message flags without openin https://bugs.python.org/issue46734 opened by gildea #46735: gettext.translations crashes when locale is unset https://bugs.python.org/issue46735 opened by amazingminecrafter2015 #46736: Generate HTML 5 with SimpleHTTPRequestHandler.list_directory https://bugs.python.org/issue46736 opened by dom1310df #46740: Improve Telnetlib's throughput https://bugs.python.org/issue46740 opened by martin_kirch #46742: Add '-d $fd' option to trace module, akin to bash -x feature https://bugs.python.org/issue46742 opened by PenelopeFudd #46743: Enable usage of object.__orig_class__ in __init__ https://bugs.python.org/issue46743 opened by Gobot1234 #46744: installers on ARM64 suggest wrong folders https://bugs.python.org/issue46744 opened by conio #46746: IDLE: Consistently handle non .py source files https://bugs.python.org/issue46746 opened by terry.reedy #46748: Python.h includes stdbool.h https://bugs.python.org/issue46748 opened by petr.viktorin #46749: Support cross compilation on macOS https://bugs.python.org/issue46749 opened by autoantwort #46750: some code paths in ssl and _socket still import idna unconditi https://bugs.python.org/issue46750 opened by slingamn #46751: Windows-style path is not recognized under cygwin https://bugs.python.org/issue46751 opened by mikekaganski #46752: Introduce task groups to asyncio and change task cancellation https://bugs.python.org/issue46752 opened by gvanrossum #46753: Statically allocate and initialize the empty tuple. https://bugs.python.org/issue46753 opened by eric.snow #46754: Improve Python Language Reference based on [K??hl 2020] https://bugs.python.org/issue46754 opened by gvanrossum #46755: QueueHandler logs stack_info twice https://bugs.python.org/issue46755 opened by erik.montnemery #46756: Incorrect authorization check in urllib.request https://bugs.python.org/issue46756 opened by serhiy.storchaka #46757: dataclasses should define an empty __post_init__ https://bugs.python.org/issue46757 opened by NeilGirdhar #46758: Incorrect behaviour creating a Structure with ctypes.c_bool bi https://bugs.python.org/issue46758 opened by dudenwatschn #46759: sys.excepthook documentation doesn't mention that it isn't cal https://bugs.python.org/issue46759 opened by cjwatson #46760: test_dis should test the dis module, not everything else https://bugs.python.org/issue46760 opened by Mark.Shannon #46761: functools.update_wrapper breaks the signature of functools.par https://bugs.python.org/issue46761 opened by larry #46763: os.path.samefile incorrect results for shadow copies https://bugs.python.org/issue46763 opened by nijave #46764: Wrapping a bound method with a @classmethod no longer works https://bugs.python.org/issue46764 opened by msullivan #46765: Replace Locally Cached Strings with Statically Initialized Obj https://bugs.python.org/issue46765 opened by eric.snow #46767: [Doc] sqlite3 Cursor.execute() return value is unspecified https://bugs.python.org/issue46767 opened by kephas #46769: Improve documentation for `typing.TypeVar` https://bugs.python.org/issue46769 opened by AlexWaygood #46770: ConfigParser(dict_type=) not behaving as expected https://bugs.python.org/issue46770 opened by malonn #46771: Add some form of cancel scopes https://bugs.python.org/issue46771 opened by gvanrossum #46772: Statically Initialize PyArg_Parser in clinic.py https://bugs.python.org/issue46772 opened by eric.snow #46773: Add a Private API for Looking Up Global Objects https://bugs.python.org/issue46773 opened by eric.snow #46774: Importlib.metadata.version picks first distribution not latest https://bugs.python.org/issue46774 opened by kkirsche-github #46775: [Windows] OSError should unconditionally call winerror_to_errn https
[Python-Dev] Re: Move the pythoncapi_compat project under the GitHub Python or PSF organization?
> On 14 Feb 2022, at 14:07, Petr Viktorin wrote: > > > > On 14. 02. 22 13:37, Antoine Pitrou wrote: >> On Mon, 14 Feb 2022 13:19:00 +0100 >> Petr Viktorin wrote: >>> >>> If we don't have much sympathy for projects that use private API where >>> does that leave pythoncapi_compat? >> If you look at pythoncapi_compat.h, it provides backports for >> recently-introduced public APIs such as PyObject_CallOneArg(). > > Yes. > On older Python versions, where the public API wasn't yet available, those > backports use private API. If we change the private API in a point release, > the backport will break. Do you have an example of this? On first glance the pythoncapi_compat.h header only uses public APIs, other than (maybe) accessing fields of the thread state directly. BTW. I’m +1 on providing this header, it makes it easier for projects to maintain compatibility with older Python versions. That said, we should continue to be careful and considerate when evolving the public API as migrating a project to a newer API is still work. Ronald — Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/B7TKVUPXADTHYANTLIKCAVE4ZCNUJ64M/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2022-02-04 - 2022-02-11) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open7178 (+34) closed 51272 (+50) total 58450 (+84) Open issues with patches: 2912 Issues opened (63) == #42548: debugger stops at breakpoint of `pass` that is not actually re https://bugs.python.org/issue42548 reopened by iritkatriel #44006: symbol documentation still exists https://bugs.python.org/issue44006 reopened by vstinner #45459: Limited API support for Py_buffer https://bugs.python.org/issue45459 reopened by vstinner #46430: intern strings in deepfrozen modules https://bugs.python.org/issue46430 reopened by christian.heimes #46639: Ceil division with math.ceildiv https://bugs.python.org/issue46639 opened by Vladimir Feinberg #46640: Python can now use the C99 NAN constant or __builtin_nan() https://bugs.python.org/issue46640 opened by vstinner #46642: typing: tested TypeVar instance subclass TypeError is incident https://bugs.python.org/issue46642 opened by GBeauregard #46643: typing.Annotated cannot wrap typing.ParamSpec args/kwargs https://bugs.python.org/issue46643 opened by GBeauregard #46644: typing: remove callable() check from typing._type_check https://bugs.python.org/issue46644 opened by GBeauregard #46645: Portable python3 shebang for Windows, macOS, and Linux https://bugs.python.org/issue46645 opened by joshtriplett #46646: `address` arg can be `bytes` for `ip_*` functions in `ipaddres https://bugs.python.org/issue46646 opened by sobolevn #46649: Propagate Python thread name to thread state structure https://bugs.python.org/issue46649 opened by Gabriele Tornetta #46650: `priority` in `sched.scheduler` is not sufficiently tested https://bugs.python.org/issue46650 opened by sobolevn #46652: Use code.co_qualname to provide richer information https://bugs.python.org/issue46652 opened by Gabriele Tornetta #46653: sys.path entries normalization in site.py doesn't follow POSIX https://bugs.python.org/issue46653 opened by jpoiret #46654: urllib.request.urlopen doesn't handle UNC paths produced by pa https://bugs.python.org/issue46654 opened by ikelos #46655: typing.TypeAlias is not in the list of allowed plain _SpecialF https://bugs.python.org/issue46655 opened by GBeauregard #46656: Compile fails if Py_NO_NAN is defined https://bugs.python.org/issue46656 opened by mark.dickinson #46657: Add mimalloc memory allocator https://bugs.python.org/issue46657 opened by christian.heimes #46658: shutil Lib enables sendfile on solaris for regular files https://bugs.python.org/issue46658 opened by devnexen #46659: Deprecate locale.getdefaultlocale() function https://bugs.python.org/issue46659 opened by vstinner #46661: Duplicat deprecation warnings in docs for asyncio https://bugs.python.org/issue46661 opened by gvanrossum #46662: Lib/sqlite3/dbapi2.py: convert_timestamp function failed to co https://bugs.python.org/issue46662 opened by Rayologist #46663: test_math test_cmath test_complex fails on Fedora Rawhide buil https://bugs.python.org/issue46663 opened by vstinner #46664: PY_SSIZE_T_MAX is not an integer constant expression https://bugs.python.org/issue46664 opened by ov2k #46665: IDLE Windows shortcuts by default https://bugs.python.org/issue46665 opened by primexx #4: IDLE Add indent guide https://bugs.python.org/issue4 opened by primexx #46667: SequenceMatcher & autojunk - false negative https://bugs.python.org/issue46667 opened by jonathan-lp #46668: encodings: the "mbcs" alias doesn't work https://bugs.python.org/issue46668 opened by vstinner #46670: Build Python with -Wundef: don't use undefined macros https://bugs.python.org/issue46670 opened by vstinner #46671: "ValueError: min() arg is an empty sequence" is wrong (builtin https://bugs.python.org/issue46671 opened by Nnarol #46672: NameError in asyncio.gather when passing a invalid type as an https://bugs.python.org/issue46672 opened by onerandomusername #46675: Allow more than 16 items in split-keys dicts and "virtual" obj https://bugs.python.org/issue46675 opened by Mark.Shannon #46677: TypedDict docs are incomplete https://bugs.python.org/issue46677 opened by Jelle Zijlstra #46679: test.support.wait_process ignores timeout argument https://bugs.python.org/issue46679 opened by notarealdeveloper #46681: gzip.compress does not forward compresslevel to zlib.compress https://bugs.python.org/issue46681 opened by iii-i #46682: python 3.10 Py_Initialize/Py_Main std path no longer includes https://bugs.python.org/issue46682 opened by pjaggi1 #46685: Add additional tests for new features in `typing.py` https://bugs.python.org/issue46685 opened by sobolevn #46686: [venv / PC/launcher] issue with a space in the installed pytho https://bugs.python.org/issue46686 opened by ho
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2022-01-28 - 2022-02-04) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open7144 (-13) closed 51222 (+84) total 58366 (+71) Open issues with patches: 2890 Issues opened (44) == #45711: Simplify the interpreter's (type, val, tb) exception represent https://bugs.python.org/issue45711 reopened by vstinner #45773: Compiler hangs during jump elimination https://bugs.python.org/issue45773 reopened by brandtbucher #46570: Windows support for OpenSSL 3.0 https://bugs.python.org/issue46570 opened by jay0lee #46571: Strange `@typing.no_type_check` behavior for class variables https://bugs.python.org/issue46571 opened by sobolevn #46575: One-off errors in hashlib.scrypt error messages https://bugs.python.org/issue46575 opened by ron_kaminsky #46577: Hostname spoofing via backslashes in URL https://bugs.python.org/issue46577 opened by meetdash #46578: cant DEBUG os.spawnv() https://bugs.python.org/issue46578 opened by michaellongge #46580: email.utils.unquote strips too many slashes https://bugs.python.org/issue46580 opened by hbandi #46581: _typevar_types and _paramspec_tvars are missing from _GenericA https://bugs.python.org/issue46581 opened by posita #46585: Should we re-export `PyObj_FromPtr` in `ctypes`? https://bugs.python.org/issue46585 opened by sobolevn #46586: In documentation contents enum.property erroneously links to b https://bugs.python.org/issue46586 opened by Dutcho #46587: datetime and time tests use non-portal "%4Y" format https://bugs.python.org/issue46587 opened by christian.heimes #46589: Improve documentation for typing._GenericAlias https://bugs.python.org/issue46589 opened by matthew.rahtz #46592: Undocumented behavior in strptime for ISO week dates https://bugs.python.org/issue46592 opened by Jonatan Skogsfors #46593: memoryview lacks support for half floats https://bugs.python.org/issue46593 opened by pitrou #46594: Windows "Edit with IDLE >" only has one selection https://bugs.python.org/issue46594 opened by terry.reedy #46596: PyLineTable_InitAddressRange isn't exported - causing C Extens https://bugs.python.org/issue46596 opened by nathan3 #46598: ElementTree: wrong XML prolog for the utf-8-sig encoding https://bugs.python.org/issue46598 opened by prikryl #46600: Python built with clang -O0 allocates 10x more stack memory th https://bugs.python.org/issue46600 opened by vstinner #46601: macOS installer "Install Certificates.command" fails if pip is https://bugs.python.org/issue46601 opened by cryptophoto #46603: `typing._strip_annotations` is not fully covered https://bugs.python.org/issue46603 opened by sobolevn #46604: Documentation fix in ssl module https://bugs.python.org/issue46604 opened by glk0 #46605: Py_XDECREF() module on fail in Py_mod_exec https://bugs.python.org/issue46605 opened by ov2k #46606: Large C stack usage of os.getgroups() and os.setgroups() https://bugs.python.org/issue46606 opened by methane #46607: Add DeprecationWarning to configparser's LegacyInterpolation https://bugs.python.org/issue46607 opened by hugovk #46608: Exclude marshalled-frozen data if deep-freezing to save 300 KB https://bugs.python.org/issue46608 opened by kumaraditya303 #46609: Generator-based coroutines in Python 3.10 docs https://bugs.python.org/issue46609 opened by srittau #46611: Improve coverage of `__instancecheck__` and `__subclasscheck__ https://bugs.python.org/issue46611 opened by sobolevn #46613: Add PyType_GetModuleByDef to the public & limited API https://bugs.python.org/issue46613 opened by petr.viktorin #46614: Add option to output UTC datetimes as "Z" in `.isoformat()` https://bugs.python.org/issue46614 opened by p-ganssle #46615: Use-after-free by mutating set during set operations https://bugs.python.org/issue46615 opened by Dennis Sweeney #46619: lazy module property not recognized by doctests https://bugs.python.org/issue46619 opened by jaraco #46620: Documentation of ipaddress behavior for prefix length with lea https://bugs.python.org/issue46620 opened by lay20114 #46621: Should map(function, iterable, ...) replace StopIteration with https://bugs.python.org/issue46621 opened by xavieryao #46622: Support decorating a coroutine with functools.cached_property https://bugs.python.org/issue46622 opened by uranusjr #46623: test_zlib: test_pair() and test_speech128() fail with s390x ha https://bugs.python.org/issue46623 opened by vstinner #46625: timeout option of socket.create_connection is not respected https://bugs.python.org/issue46625 opened by Nicolas SURRIBAS #46631: Implement a "strict" mode for getpass.getuser() https://bugs.python.org/issue46631 opened by eryksun #46632: test_ssl: 2 tests fail on cstratak-CentOS9-fips-x86_64 https://bugs.python.org/issue46632
[Python-Dev] Re: Moving away from _Py_IDENTIFIER().
> On 2 Feb 2022, at 23:41, Eric Snow wrote: > > I […] > > Cons: > > * a little less convenient: adding a global string requires modifying > a separate file from the one where you actually want to use the string > * strings can get "orphaned" (I'm planning on checking in CI) > * some strings may never get used for any given ./python invocation > (not that big a difference though) The first two cons can probably be fixed by adding some indirection, with some markers at the place of use and a script that uses those to generate the C definitions. Although my gut feeling is that adding a the CI check you mention is good enough and adding the tooling for generating code isn’t worth the additional complexity. Ronald — Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/ _______ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/6EJSL7LBAZM4HL5THZDZGTYFS5HRAIPY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python
> On 2 Feb 2022, at 11:50, Stefan Behnel wrote: > > Petr Viktorin schrieb am 02.02.22 um 10:22: >> Moving off the internal (unstable) API would be great, but I don't think >> Cython needs to move all the way to the limited API. >> There are three "levels" in the C API: >> - limited API, with long-term ABI compatibility guarantees > > That's what "-DCYTHON_LIMITED_API -DPy_LIMITED_API=..." is supposed to do, > which currently fails for much if not most code. > > >> - "normal" public API, covered by the backwards compatibility policy (users >> need to recompile for every minor release, and watch for deprecation >> warnings) > > That's probably close to what "-DCYTHON_LIMITED_API" does by itself as it > stands. I can see that being a nice feature that just deserves a more > suitable name. (The name was chosen because it was meant to also internally > define "Py_LIMITED_API" at some point. Not sure if it will ever do that.) > > >> - internal API (underscore-prefixed names, `internal` headers, things >> documented as private) >> AFAIK, only the last one is causing trouble here. > > Yeah, and that's the current default mode on CPython. Is is possible to automatically pick a different default version when building with a too new CPython version? That way projects can at least be used and tested with pre-releases of CPython, although possibly with less performance. Ronald > > Maybe we should advertise the two modes more. And make sure that both work. > There are certainly issues with the current state of the "limited API" > implementation, but that just needs work and testing. > > Stefan > > _______ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/ESEPW36K3PH4RM7OFVKAOE4QMBI2WYVU/ > Code of Conduct: http://python.org/psf/codeofconduct/ — Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/DDIQ6RYX6ECQ5YSSB5PUDNN2OLZE725R/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python
Stefan, There two separate issues here. One is the timing of committing changes into cython, and the other is the process by which the cython devs learn about cpython development. On the first issue, you wrote: I'm reluctant to working on adapting Cython during alphas, because it > happened more than once that incompatible changes in CPython were rolled > back or modified again during alpha, beta and rc phases. That means more > work for me and the Cython project, and its users. Code that Cython users > generate and release on their side with a release version of Cython will > then be broken, and sometimes even more broken than with an older Cython > release. > I saw in your patch that you make changes such that they impact only the new cpython version. So for old versions the generated code should not be broken. Surely you don't guarantee that cython code generated for an alpha version of cpython will work on later versions as well? Users who generate code for an alpha version should regenerate it for the next alpha and for beta, right? On the second issue: I don't have the capacity to follow all relevant changes in CPython, > incompatible or not. We get that, and this is why we're asking to work with you on cython updates so that this will be easier for all of us. There are a number of cpython core devs who would like to help cython maintenance. We realise how important and thinly resourced cython is, and we want to reduce your maintenance burden. With better communication we could find ways to do that. Returning to the issue that started this thread - how do you suggest we proceed with the exc_info change? Irit ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/MBGJFYWKBFBUKNA2MXJ5THX5M657J5WH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python
Miro, I have offered before and my offer still stands to help fix this. This was already fixed in the cython main branch by Stefan. The discussion now is about when to backport it to cython 0.29. I'm actually working on the backport now (learning cython in the process). But we will need to come up with a release plan that doesn't make me revert the cpython changes until after the 3.11 beta is released, because that would mean that I can only make them in 3.12. On Tue, Feb 1, 2022 at 6:53 PM Miro Hrončok wrote: > On 01. 02. 22 17:42, Victor Stinner wrote: > > The problem right now is the pressure put on Cython maintainers to fix > > Cython as soon as possible. IMO core developers who introduce > > incompatible changes should be more involved in the Cython changes, > > since Cython is a **key component** of the Python ecosystem. IMO > > knowing that a change breaks Cython and relying on "the community" to > > fix it is not a nice move. Well, that's my opinion;-) > > As the Fedora Python maintainer, I agree with this opinion. Broken Cython > means > we cannot actually test the next pre-release of CPython until it is fixed. > And > the CPython contributors who introduced the chnage are the most equipped > ones > to help fix it. > > I understand the desire to innovate fast, but making sure Cython works > should > be an essential part of the innovation process (even while Cython is not > part > of the CPython source tree, it's part of the bigger picture). > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > > _______ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/K7LZAJTGDBFDM5TEQE7EALZMXQTCMQUS/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/L564CUXVMFZ4YHDNPM6K47FRBGUT5FDH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Please update Cython *before* introcuding C API incompatible changes in Python
_PyErr_StackItem is not part of the C API, it's an internal struct that cython accesses directly. On Tue, Feb 1, 2022 at 3:42 PM Christian Heimes wrote: > On 01/02/2022 16.08, Victor Stinner wrote: > > -- > > > > I would prefer to introduce C API incompatible changes differently: > > first fix Cython, and *then* introduce the change. > > > > - (1) Propose a Cython PR and get it merged > > - (2) Wait until a new Cython version is released > > - (3) If possible, wait until numpy is released with regenerated Cython > code > > - (4) Introduce the incompatible change in Python > > > > Note: Fedora doesn't need (3) since we always regenerated Cython code in > numpy. > > Hi, > > this is a reasonable request for beta releases, but IMHO it is not > feasible for alphas. During alphas we want to innovate fast and play > around. Your proposal would slow down innovation and impose additional > burden on core developers. > > There are more code binding generators than just Cython. Shouldn't we > work with cffi, SWIG, sip, pybind11, and PyO3 developers as well? I care > for cffi and PyO3, too... > > I would prefer if we can get Cython and all the other code generator and > bindings library off the unstable C-API. They should use the limited API > instead. If they require any C-APIs outside the limited API, then we > should investigate and figure something out. > > Christian > > > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/7UD4FZC7ANLR646CNP4HJ2WNWLFRYL7I/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/KFFTVAJI4QVKNCDIIVU5HEHISQJI5ZWI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Increase of Spammy PRs and PR reviews
> Gaming the system doesn't end up working well in the end anyway. The first > time the gamers try to get a job interview and can't explain how they'd do a > code review—something GitHub says they've done hundreds or thousands of > times—the whole thing will fail. Observably, it feels like they are doing this for core privileges (if they don't already exist, they are a member of the python org?). Every time I see one of those PRs (e.g add test for X, add delete redundant variables for Y), the author seem to be cc-ing their mentor. This gives a bad impression to others about their intentions (constant contribution of trivial / low quality stuff with little-to-no-gain to achieve a higher number of commits, since it is a visible metric).___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/JZBQ2UYTXDCHADW4LEPGPE5SFLRHW5E3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Increase of Spammy PRs and PR reviews
A non-core approval changes the label from "awaiting review" to "awaiting core review". I find this useful, and occasionally filter on "awaiting core review" because it indicates that at least one other person found the PR sound / interesting. I would not like this to change - I think high quality reviews from non-core contributors are valuable for the project and are a very quick way for the contributor to get the right kind of attention from core devs. If people spam the approvals (i.e., approve PRs without reviewing them) then the distinction between the labels becomes meaningless, of course. Though I do wonder what the motivation for doing that repeatedly would be. My basic assumption is that people usually try not to make fools of themselves. Note that contributors can still approve a perfect PR - a quality review in this case would include a brief comment indicating that you understand the change and perhaps why you find it valuable. On the matter of spammy PRs - I agree with both Rupert and Ethan (F): trivial PRs can add value, and a large number of them can be annoying. You can add value and be annoying at the same time (my triage work on b.p.o is probably in this category. Thankfully it's clear I'm not after "triage points", because there aren't any). At the end of the day, it doesn't really matter what a contributor's motivation is - it's up to the core devs to decide which PRs are valuable enough to merge, or even to review, and who they enjoy working with. These things tend to sort themselves out on their own. I don't think we need to restrict access for non-core contributors compared to the status quo. What I do think we need is to make it easier for core devs to close issues and PRs. We have a huge pile of open issues and PRs, some of which we know will never happen (stale or otherwise) and we don't close them because it's an unpleasant task to let someone down, and sometimes they argue, and we're volunteers and why should we bother with this emotional labour. Through triage I found many 6 year old issues that, once I refreshed and perhaps put an 'easy' label on, got fixed. The useless issues we don't want to close are obscuring the ones we can and should fix. I'm sure this has been discussed before. My only idea is that we formalize some guidelines/criteria for closing old issues and PRs that make it more of a joint decision of the core devs and less of a personal issue between the core dev and the contributor. I would not suggest a blanket 'close issues/PRs with no activity for X months', as I said I found useful 6 year old issues. It has to be more sophisticated than that. In summary - my view is that rather than making contributors contribute less, we should be more effective in reviewing the contributions, including rejecting those that should be rejected. On Sun, Jan 30, 2022 at 8:06 AM Ethan Smith wrote: > > > On Sat, Jan 29, 2022 at 7:38 PM Inada Naoki > wrote: > >> On Sun, Jan 30, 2022 at 12:03 PM Ethan Smith wrote: >> > >> > As a non-committer, I want to make a plea for non-committer approval >> reviews, or at least that they have a place. When asked how outsiders can >> contribute I frequently see "review open PRs" as a suggested way of >> contributing to CPython. Not being able to approve PRs that are good would >> be a barrier to those contributions. >> > >> > Furthermore, I am collaborating with a couple of core devs, it would >> make collaboration more difficult if I couldn't review their work and say >> that I thought the changes looked good. >> > >> >> You can still write a review comment, including "LGTM". > > > Fair enough, I suppose commenting with "LGTM" works just as well. > > >> What you can >> not is labeling PR as "Approved." >> So I don't think it makes collaboration difficult. >> > By preventing approval from others, we can easily find PRs approved >> from core-devs or triage members but not merged yet. >> > >> > I know "drive by approvals" are annoying but I think it is >> unfortunately part of open source projects. >> > >> >> Sorry, but I don't think so. >> > > Well, if you disallow drive-by approvals, you will still get drive-by LGTM > comments. People seem to believe that adding their approval will expedite a > PR merge, for some reason (or want to bump a stale PR in hopes of a quicker > merge). > > >> >> -- >> Inada Naoki >> > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mai
[Python-Dev] Increase of Spammy PRs and PR reviews
As someone who is watching the python/cpython repository, I'm very used to see lots of traffic. But lately there have been a surge of spammy PRs which are about the same, generally very trivial subject but individually fixing each occurrence one by one: - Add coverage to X (tens of them, as separate PRs) - Make `test_xxx` executable with direct invocation (tens of them, as separate PRs) - Lint source with flake8, fix linting errors (stylistic changes) And lots of non-committer PR reviews that only approve. Am I the only one who feels like this is only done to 'grind' commits (get a higher number of commits into the repository, and boast about it)? In the past there were one or two people who would submit typo fixes, but most of them weren't making it continuously. The situation right now feels much worse than those.___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/7RGI4LUJSEKU2JUYSV7UMZ2CXRGAANEF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2022-01-21 - 2022-01-28) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open7157 (-18) closed 51138 (+124) total 58295 (+106) Open issues with patches: 2888 Issues opened (71) == #33205: GROWTH_RATE prevents dict shrinking https://bugs.python.org/issue33205 reopened by rhettinger #38195: A bug in the multiprocessing module https://bugs.python.org/issue38195 reopened by eshkrig #44733: Feature request: maxtasksperchild for ProcessPoolExecutor https://bugs.python.org/issue44733 reopened by gregory.p.smith #44734: turtle: tests for Vec2D.__abs__ are too strict https://bugs.python.org/issue44734 reopened by petr.viktorin #45162: Remove old deprecated unittest features https://bugs.python.org/issue45162 reopened by gregory.p.smith #45200: Address Sanitizer: libasan dead lock in pthread_create() (test https://bugs.python.org/issue45200 reopened by vstinner #45680: Documentation on `GenericAlias` objects and `__class_getitem__ https://bugs.python.org/issue45680 reopened by kj #46240: Incorrect hint about forgetting a comma https://bugs.python.org/issue46240 reopened by vstinner #46285: protocol_version in http.server.test can be ignored https://bugs.python.org/issue46285 reopened by eric.araujo #46462: Email Header Folding Converts Non-CRLF Newlines to CRLFs https://bugs.python.org/issue46462 opened by jwalterclark #46464: concurrent.futures.ProcessPoolExecutor can deadlock when tcmal https://bugs.python.org/issue46464 opened by yilei #46465: Regression caused by CALL_FUNCTION specialization for C functi https://bugs.python.org/issue46465 opened by vstinner #46472: A option that choose between single quote and double quote in https://bugs.python.org/issue46472 opened by I-love-study #46475: typing.Never and typing.assert_never https://bugs.python.org/issue46475 opened by Jelle Zijlstra #46477: Enum: ensure bitwise operators on subclasses are correct https://bugs.python.org/issue46477 opened by ethan.furman #46479: Implement typing.reveal_locals https://bugs.python.org/issue46479 opened by Jelle Zijlstra #46480: Implement typing.assert_type https://bugs.python.org/issue46480 opened by Jelle Zijlstra #46482: `typing.Annotation.__new__` is not covered https://bugs.python.org/issue46482 opened by sobolevn #46483: `pathlib.PurePath.__class_getitem__` does not return `GenericA https://bugs.python.org/issue46483 opened by sobolevn #46484: Add test for Calendar().iterweekdays() https://bugs.python.org/issue46484 opened by wangjiahua #46487: `_SSLProtocolTransport` doesn't have the `get_write_buffer_lim https://bugs.python.org/issue46487 opened by mooncell07 #46489: webbrowser crashes Ubuntu kernel https://bugs.python.org/issue46489 opened by dizcza #46490: Add "follow_symlinks=False" support for "os.utime()" on Window https://bugs.python.org/issue46490 opened by Delgan #46493: Add an API to indicate if the process might have multiple thre https://bugs.python.org/issue46493 opened by gregory.p.smith #46494: Mention typing_extensions in the typing documentation https://bugs.python.org/issue46494 opened by Jelle Zijlstra #46495: IDLE subsection of What's New 3.11 https://bugs.python.org/issue46495 opened by terry.reedy #46496: idlelib/NEWS.txt for 3.11.0 and backports https://bugs.python.org/issue46496 opened by terry.reedy #46497: IDLE macOS shortcut ctrl+S doesn???t work for show completions https://bugs.python.org/issue46497 opened by dvd101x #46498: Add new triplets for loongarch64 https://bugs.python.org/issue46498 opened by loongson-zn #46500: make timeit module accept files https://bugs.python.org/issue46500 opened by CCLDArjun #46501: Windows 10, turtle left right not working https://bugs.python.org/issue46501 opened by wizprokidz #46506: [Windows] wrap CreateFile to support follow_symlinks https://bugs.python.org/issue46506 opened by eryksun #46507: enabling cProfile to profile code given as an argument "?? la" https://bugs.python.org/issue46507 opened by jul2 #46508: codec name acceptance became way too lenient in 3.9 https://bugs.python.org/issue46508 opened by gregory.p.smith #46509: Type-specialized Py_DECREF https://bugs.python.org/issue46509 opened by Dennis Sweeney #46511: dataclasses: Allow typing.Annotated to wrap dataclasses-specif https://bugs.python.org/issue46511 opened by GBeauregard #46512: Explicit or correct behavior of filecmp.cmpfiles w/ absolute p https://bugs.python.org/issue46512 opened by bers #46518: SSL socket timeout not set after client connects via accept https://bugs.python.org/issue46518 opened by tomazas #46520: `ast.unparse` produces syntactically illegal code for identifi https://bugs.python.org/issue46520 opened by Kodiologist #46521: compile_command not raising syntax error when command en
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2022-01-14 - 2022-01-21) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open7175 (-27) closed 51014 (+108) total 58189 (+81) Open issues with patches: 2878 Issues opened (59) == #24711: Document getpass.getpass behavior on ^C https://bugs.python.org/issue24711 reopened by iritkatriel #44133: Some C-API symbols (e.g. Py_FrozenMain) are not always exporte https://bugs.python.org/issue44133 reopened by vstinner #45522: Allow to build Python without freelists https://bugs.python.org/issue45522 reopened by vstinner #46035: mimetypes.guess_type returns deprecated mimetype application/x https://bugs.python.org/issue46035 reopened by iritkatriel #46133: Feature request: allow mechanism for creator of exec-generated https://bugs.python.org/issue46133 reopened by posita #46381: Improve documentation of CFLAGS_NODIST, LDFLAGS_NODIST https://bugs.python.org/issue46381 opened by matthiaskoeppe #46382: dataclass(slots=True) does not account for slots in base class https://bugs.python.org/issue46382 opened by ariebovenberg #46383: _zoneinfo module_free has invalid function signature https://bugs.python.org/issue46383 opened by christian.heimes #46384: Request: make lzma._(encode|decode)_filter_properties public https://bugs.python.org/issue46384 opened by miurahr #46389: 3.11: unused generator comprehensions cause f_lineno==None https://bugs.python.org/issue46389 opened by nedbat #46390: Multiple test failures on Alpine 3.15 / musl-1.2.2-r7 https://bugs.python.org/issue46390 opened by christian.heimes #46391: Library multiprocess leaks named resources. https://bugs.python.org/issue46391 opened by milestonejxd #46392: MessageIDHeader is too strict for message-id https://bugs.python.org/issue46392 opened by bpoaugust #46393: Generate frozenset constants when explicitly appropriate https://bugs.python.org/issue46393 opened by terry.reedy #46396: Invalid usage of `Concatenate` is not covered at all https://bugs.python.org/issue46396 opened by sobolevn #46397: urllib.parse.urlencode() return wrong character https://bugs.python.org/issue46397 opened by scratch #46398: posixshmem module shm_rename freebsd support. https://bugs.python.org/issue46398 opened by devnexen #46399: Addition of `mapping` attribute to dict views classes has inad https://bugs.python.org/issue46399 opened by AlexWaygood #46400: Please update bundled libexpat to 2.4.3 with security fixes https://bugs.python.org/issue46400 opened by sping #46404: 3.11a4: a small attrs regression https://bugs.python.org/issue46404 opened by tinchester #46406: optimize int division https://bugs.python.org/issue46406 opened by gregory.p.smith #46407: optimizing `1 << n` or `2 ** n` and modulo-only operations https://bugs.python.org/issue46407 opened by February291948 #46410: TypeError when parsing regexp with unicode named character seq https://bugs.python.org/issue46410 opened by jirkamarsik #46414: Add typing.reveal_type https://bugs.python.org/issue46414 opened by Jelle Zijlstra #46416: Direct invocation of `Lib/test/test_typing.py` fails https://bugs.python.org/issue46416 opened by sobolevn #46417: Clear static types in Py_Finalize() for embedded Python https://bugs.python.org/issue46417 opened by vstinner #46419: Incomplete Comparison to C++ Methods https://bugs.python.org/issue46419 opened by jharmse #46420: Use NOTRACE_DISPATCH in specialized opcodes https://bugs.python.org/issue46420 opened by Dennis Sweeney #46421: unittest ValueError when invoking as module https://bugs.python.org/issue46421 opened by BaderSZ #46422: Why do we need `dis.Positions`? https://bugs.python.org/issue46422 opened by sobolevn #46425: Multiple test modules fail to run if invoked directly https://bugs.python.org/issue46425 opened by sobolevn #46426: Improve tests for the dir_fd argument https://bugs.python.org/issue46426 opened by serhiy.storchaka #46429: Merge all deepfrozen files into one https://bugs.python.org/issue46429 opened by kumaraditya303 #46430: intern strings in deepfrozen modules https://bugs.python.org/issue46430 opened by kumaraditya303 #46431: Trouble subclassing ExceptionGroup https://bugs.python.org/issue46431 opened by petr.viktorin #46432: AMD64 FreeBSD Shared 3.x buildbot fails to build: error: error https://bugs.python.org/issue46432 opened by vstinner #46433: _PyType_GetModuleByDef optimization is incorrect https://bugs.python.org/issue46433 opened by petr.viktorin #46434: pdb help fails with AttributeError when using Windows embeddab https://bugs.python.org/issue46434 opened by sparrowt #46435: MessageID parser can crash with IndexError: string index out o https://bugs.python.org/issue46435 opened by bpoaugust #46436: Pass the -d/--directory command-line option to http.server.CGI https://bugs.pyth
[Python-Dev] Re: SC Acceptance: PEP 646 -- Variadic Generics
Fantastic, Petr! Thanks for letting us know - and thank you once again for your patience with our last-minute changes! We'll go ahead and mark the PEP as accepted, and merge our CPython implementation soon. On Wed, 19 Jan 2022 at 08:34, Petr Viktorin wrote: > On 17. 11. 21 23:47, Barry Warsaw wrote: > > Hello Mark, Matthew, Pradeep, Vincent, and Guido, > > > > The Python Steering Council discussed the latest version of PEP 646 > (Variadic Generics) at our last meeting, and have unanimously decided to > accept the PEP. Congratulations! > > > > We want to specifically mention that we appreciate the way you called > out the Python grammar changes required by the typing features you > proposed. As we’ve said before, the Steering Council strongly believes > that the typing language and the “general” Python programming language > should remain aligned, so the implications of syntax change proposed in the > PEP for typing needed to be addressed for non-typed Python as well. The > PEP explains this change well, and does a good job of justifying the > semantics and usefulness of the change for non-type related purposes. > > > > Please feel free to change the PEP status to Accepted, and to merge your > changes to Python 3.11 at your convenience. > > > > With our appreciation, > > -Barry (on behalf of the Python Steering Council) > > > Hello Mark, Matthew, Pradeep, Vincent, and Guido, > > The 2022 Python Steering Council discussed the updated PEP 646 -- > Variadic Generics, and decided to accept the PEP again, with the > following note: > >The details around multiple unpackings in a type expression aren't >specified precisely. This gives individual type checkers some leeway, >but can be tightened in future PEPs. > > Please feel free to change the PEP status to Accepted and add the note > to it, and merge your changes to Python 3.11. > > As Barry mentioned previously, we appreciate justifying the changes for > non-typed Python as well. > > > Thank you for your patience as we set up the new SC, and happy typing! > - Petr (on behalf of the Python Steering Council) > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HSVDU4YJFOAEBS3NIE77UVEF7G34DZ7Q/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Fwd: PEP 646 (Variadic Generics): final call for comments
> Even less, actually. > The PEP doesn't make a very clear distinction between invalid Python > syntax vs. invalid type annotation, so I wanted to check if we're on the > same page here: the newly valid syntax will be subject to PEP 387. > We clearly are on the same page, and I don't think you need to update > the PEP. Ok, fair enough. > When I asked my curious question, I thought I misread a piece of text, > not that it's a detail that went unnoticed, and could delay the PEP. > I can't speak for the whole SC, but on the Monday meeting I'll suggest > accepting the PEP with a note that > - index assignment is also affected, and > - the details around multiple unpackings in a type expression aren't > specified precisely. This gives individual type checkers some leeway, > but can be tightened in future PEPs. Cool. Thanks, Petr! _______ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/VZHGKB7SKI45GFP7BI7FDTO6ENOL4NL6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2022-01-07 - 2022-01-14) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open7202 ( +3) closed 50906 (+81) total 58108 (+84) Open issues with patches: 2886 Issues opened (48) == #32876: HTMLParser raises exception on some inputs https://bugs.python.org/issue32876 reopened by iritkatriel #46298: Automatically check for __slots__-mistakes in Lib https://bugs.python.org/issue46298 opened by ariebovenberg #46304: Unable to iterate over lines in a file without a block of code https://bugs.python.org/issue46304 opened by jaraco #46309: Task created by StreamReaderProtocol gets garbage collected. https://bugs.python.org/issue46309 opened by simwr872 #46311: Clean up PyLong_FromLong and PyLong_FromLongLong https://bugs.python.org/issue46311 opened by mark.dickinson #46312: range() function could accept slice() objects as parameters https://bugs.python.org/issue46312 opened by yota moteuchi #46313: SSLObject does not raise SSLEOFError on OpenSSL 3 https://bugs.python.org/issue46313 opened by alex.gronholm #46315: Add support for WebAssembly System Interface (wasm32-wasi) https://bugs.python.org/issue46315 opened by christian.heimes #46316: Optimize pathlib.Path.iterdir() https://bugs.python.org/issue46316 opened by barneygale #46317: Pathlib.rename isn't robust https://bugs.python.org/issue46317 opened by Oz.Tiram #46318: asyncio and ssl: ResourceWarning: unclosed transport https://bugs.python.org/issue46318 opened by mdk #46323: Use _PyObject_Vectorcall in Modules/_ctypes/callbacks.c https://bugs.python.org/issue46323 opened by hydroflask #46325: Documentation for SubprocessTransport.get_pipe_transport retur https://bugs.python.org/issue46325 opened by xx11mz #46326: 'venv --clear' should prompt user before nuking entire directo https://bugs.python.org/issue46326 opened by alimpfard #46329: Split up the CALL_NO_KW and CALL_KW instructions. https://bugs.python.org/issue46329 opened by Mark.Shannon #46330: Simplify the signature of __exit__ https://bugs.python.org/issue46330 opened by Jelle Zijlstra #46333: ForwardRef.__eq__ does not respect module parameter https://bugs.python.org/issue46333 opened by andreash #46334: Glossary URLs with anchor link no longer jump to definitions https://bugs.python.org/issue46334 opened by trey #46335: asyncio.create_subprocess_exec throws RuntimeError yet still e https://bugs.python.org/issue46335 opened by Clint Olsen #46336: Sixth element of tuple from __reduce__(), inconsistency betwee https://bugs.python.org/issue46336 opened by lev.bishop #46337: urllib.parse: Allow more flexibility in schemes and URL resolu https://bugs.python.org/issue46337 opened by lincolnauster #46338: libc_ver() runtime error when sys.executable is empty https://bugs.python.org/issue46338 opened by allie.hammond #46339: PEG parser segfault from ast.literal_eval https://bugs.python.org/issue46339 opened by gregory.p.smith #46340: DeprecationWarning emitted when running asyncio tests https://bugs.python.org/issue46340 opened by kumaraditya303 #46341: duplicate paragraphs - asyncio Coroutines and Tasks file https://bugs.python.org/issue46341 opened by davem #46343: Add PyErr_GetActiveException and PyErr_SetActiveException https://bugs.python.org/issue46343 opened by iritkatriel #46349: inspect.getdoc() should append parent class method docs when e https://bugs.python.org/issue46349 opened by gregory.p.smith #46350: re.sub, re.Match.expand, etc doesn't allow x, u, U, or N escap https://bugs.python.org/issue46350 opened by bup #46351: Makefile missing '/' for some path names https://bugs.python.org/issue46351 opened by gwolski #46353: 'pydoc -k' fails when some module's loader is not found https://bugs.python.org/issue46353 opened by dlax #46356: [C API] Enforce usage of PyFrame_GetBack() https://bugs.python.org/issue46356 opened by vstinner #46360: Inconsistent import behavior for (unusual) submodules https://bugs.python.org/issue46360 opened by eric.snow #46361: Small ints aren't always cached properly https://bugs.python.org/issue46361 opened by brandtbucher #46363: Two typos in versions 3.7 document translation of zh_CN https://bugs.python.org/issue46363 opened by perlang #46364: asyncio subprocess cannot read from /dev/stdin https://bugs.python.org/issue46364 opened by xoph #46367: multiprocessing's "spawn" doesn't actually use spawn https://bugs.python.org/issue46367 opened by jakirkham #46368: faulthandler: add the ability to dump all interpreters, not on https://bugs.python.org/issue46368 opened by vstinner #46369: get_type_hints does not evaluate ForwardRefs inside NewType https://bugs.python.org/issue46369 opened by andreash #46371: A better way to resolve ForwardRefs in type aliases across mod https://bugs.python.org/issue463
[Python-Dev] Re: PEP 646 (Variadic Generics): final call for comments
type parameter list that is implicit in the >>> syntax. Generic classes can be explicitly instantiated by giving them type >>> arguments, and an instantiation has a (explicit or implicit) type argument >>> list.) >>> >>> So when I read: >>> >>> """ >>> As of this PEP, only a single type variable tuple may appear in a type >>> parameter list: >>> >>> class Array(Generic[*Ts1, *Ts2]): ... # Error\ >>> """ >>> >>> I interpreted it to mean that the error is that the type _parameters_ of >>> the generic class Array include *Ts1 and *Ts2 (not that they were used as >>> type arguments to Generic). Similarly, this should be an error: >>> >>> class Array(dict[*Ts1], Generator[*Ts2]): ... >>> >>> even though there is only a single type variable tuple appearing in a >>> type _argument_ list. >>> >>> The reason for the restriction is that the tupling of Array's type >>> arguments is not explicit in an instantiation of Array, so we rely on this >>> restriction so that they can be unambiguously tupled. >>> >>> I don't think there is necessarily a similar restriction on a generic >>> function's type parameters, because we don't have the ability to explicitly >>> instantiate generic functions anyway. >>> >>> An alternative wording is along the lines of: "As of this PEP, only a >>> single type variable tuple may appear among a generic class's type >>> parameters." >>> >>> def foo(*args: tuple[*Ts1, *Ts2]) -> ... >>> >>> is already prohibited by "Multiple Unpackings in a Tuple: Not Allowed". >>> >>> There are three other occurrences of "type parameter list" in the PEP. >>> Two of them talk about instantiating generic type aliases and should be >>> changed to "type argument list". The last one is less clear, I can't quite >>> parse out what it's trying to say. >>> >>> On Wed, Jan 12, 2022 at 5:04 PM Guido van Rossum >>> wrote: >>> >>>> On Wed, Jan 12, 2022 at 4:57 AM Petr Viktorin >>>> wrote: >>>> >>>>> Matthew Rahtz wrote: >>>>> > Hi everyone, >>>>> > >>>>> > We've got to the stage now with PEP 646 that we're feeling pretty >>>>> happy >>>>> > with it. So far though we've mainly been workshopping it in >>>>> typing-sig, so >>>>> > as PEP 1 requires we're asking for some feedback here too before >>>>> submitting >>>>> > it to the steering council. >>>>> > >>>>> > If you have time over the next couple of weeks, please take a look >>>>> at the >>>>> > current draft and let us know your thoughts: >>>>> > https://www.python.org/dev/peps/pep-0646/ (Note that the final >>>>> couple of >>>>> > sections are out of date; https://github.com/python/peps/pull/1880 >>>>> > clarifies which grammar changes would be required, now that PEP 637 >>>>> has >>>>> > been rejected. We also have a second PR in progress at >>>>> > https://github.com/python/peps/pull/1881 clarifying some of the >>>>> motivation.) >>>>> > >>>>> > Thanks! >>>>> > Matthew and Pradeep >>>>> >>>>> Hi, >>>>> I'm very late to the discussion -- I relied on the typing-sig and SC >>>>> to >>>>> handle this, but now that I'm on the SC, I no longer have that luxury >>>>> :) >>>>> This mail has my own opinions, not necessarily the SC's. >>>>> >>>>> >>>>> I've read the PEP, and I quite like it! It's clear that typing-sig >>>>> thought this through very well. >>>>> The thing that surprised me is the proposed changes that affect more >>>>> than typing annotations. Quite deep in the PEP, the "Grammar Changes" >>>>> section explains the (quite exciting) change to make star-unpacking >>>>> possible in normal indexing operations, e.g.:: >>>>> >>>>> idxs_to_select = (1, 2) >>>>> array[0, *idxs_to_select, -1] # Equivalent to [0, 1, 2, -1] >>>>> >>>>> However, the PEP is silent about indexing assignment, e.g.:: >>>>> >&g
[Python-Dev] Re: PEP 646 (Variadic Generics): final call for comments
Yes, exactly. Specifically, the "wrong" example in section 'Multiple Type Variable Tuples: Not Allowed' suggests that maybe what is wrong is that `Generic` was given more than one unpacked type variable tuple. The actual problem is a consequence of that: `class Array` has more than one type variable tuple as type parameters. (But there are other ways that could happen and all of them should be wrong.) I think it might be good to say that explicitly in that section. On Thu, Jan 13, 2022 at 4:18 PM Matthew Rahtz wrote: > Thanks also Kevin for this feedback! > > Good point about being careful to distinguish type parameters vs type > arguments. If I understand correctly, you're making two points: > > 1. The wording of the 'Multiple Type Variable Tuples: Not Allowed' section > - you're saying that we're being a bit imprecise here in saying that we > disallow multiple TypeVarTuples in a type parameter list, given that in > e.g. `def f(x: *Ts1, y: *Ts2)`, both Ts1 and Ts2 are members of the > parameter list for the function f, but there it's unambiguous, so in fact > it *is* allowed. > > 2. Use of wrong terminology elsewhere in the PEP. Agreed. > > I'll draft a PR tweaking the wording to fix both these points. > > > On Thu, 13 Jan 2022 at 11:28, Kevin Millikin > wrote: > >> The wording there probably should be improved. I had a different >> interpretation when I read that, so that suggests it needs to be clarified. >> >> We should ensure to draw a clear distinction between type parameters and >> type arguments. (Generic classes and functions are parameterized over type >> parameters and they have a type parameter list that is implicit in the >> syntax. Generic classes can be explicitly instantiated by giving them type >> arguments, and an instantiation has a (explicit or implicit) type argument >> list.) >> >> So when I read: >> >> """ >> As of this PEP, only a single type variable tuple may appear in a type >> parameter list: >> >> class Array(Generic[*Ts1, *Ts2]): ... # Error\ >> """ >> >> I interpreted it to mean that the error is that the type _parameters_ of >> the generic class Array include *Ts1 and *Ts2 (not that they were used as >> type arguments to Generic). Similarly, this should be an error: >> >> class Array(dict[*Ts1], Generator[*Ts2]): ... >> >> even though there is only a single type variable tuple appearing in a >> type _argument_ list. >> >> The reason for the restriction is that the tupling of Array's type >> arguments is not explicit in an instantiation of Array, so we rely on this >> restriction so that they can be unambiguously tupled. >> >> I don't think there is necessarily a similar restriction on a generic >> function's type parameters, because we don't have the ability to explicitly >> instantiate generic functions anyway. >> >> An alternative wording is along the lines of: "As of this PEP, only a >> single type variable tuple may appear among a generic class's type >> parameters." >> >> def foo(*args: tuple[*Ts1, *Ts2]) -> ... >> >> is already prohibited by "Multiple Unpackings in a Tuple: Not Allowed". >> >> There are three other occurrences of "type parameter list" in the PEP. >> Two of them talk about instantiating generic type aliases and should be >> changed to "type argument list". The last one is less clear, I can't quite >> parse out what it's trying to say. >> >> On Wed, Jan 12, 2022 at 5:04 PM Guido van Rossum >> wrote: >> >>> On Wed, Jan 12, 2022 at 4:57 AM Petr Viktorin >>> wrote: >>> >>>> Matthew Rahtz wrote: >>>> > Hi everyone, >>>> > >>>> > We've got to the stage now with PEP 646 that we're feeling pretty >>>> happy >>>> > with it. So far though we've mainly been workshopping it in >>>> typing-sig, so >>>> > as PEP 1 requires we're asking for some feedback here too before >>>> submitting >>>> > it to the steering council. >>>> > >>>> > If you have time over the next couple of weeks, please take a look at >>>> the >>>> > current draft and let us know your thoughts: >>>> > https://www.python.org/dev/peps/pep-0646/ (Note that the final >>>> couple of >>>> > sections are out of date; https://github.com/python/peps/pull/1880 >>>> > clarifies which grammar changes would be required, now that PEP 637 >>>> has >>>>
[Python-Dev] Re: PEP 646 (Variadic Generics): final call for comments
[Matthew] > 1. The wording of the 'Multiple Type Variable Tuples: Not Allowed' section - you're saying that we're being a bit imprecise here in saying that we disallow multiple TypeVarTuples in a type parameter list, given that in e.g. `def f(x: *Ts1, y: *Ts2)`, both Ts1 and Ts2 are members of the parameter list for the function f, but there it's unambiguous, so in fact it is allowed. [Guido] > That looks like a syntax error. We only allow *Ts if the argument is of the form *a. `def f(x: *Ts1)` is not allowed. > Maybe you were thinking of `def f(x: Array[*Ts1], y: Array[*Ts2]) as the example? That seems unambiguous since the two positional arguments are given separately. Sorry, yes! _______ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/3BW75IG7XINYKUNMWR35TJW2F5DGW6LQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 646 (Variadic Generics): final call for comments
Thanks also Kevin for this feedback! Good point about being careful to distinguish type parameters vs type arguments. If I understand correctly, you're making two points: 1. The wording of the 'Multiple Type Variable Tuples: Not Allowed' section - you're saying that we're being a bit imprecise here in saying that we disallow multiple TypeVarTuples in a type parameter list, given that in e.g. `def f(x: *Ts1, y: *Ts2)`, both Ts1 and Ts2 are members of the parameter list for the function f, but there it's unambiguous, so in fact it *is* allowed. 2. Use of wrong terminology elsewhere in the PEP. Agreed. I'll draft a PR tweaking the wording to fix both these points. On Thu, 13 Jan 2022 at 11:28, Kevin Millikin wrote: > The wording there probably should be improved. I had a different > interpretation when I read that, so that suggests it needs to be clarified. > > We should ensure to draw a clear distinction between type parameters and > type arguments. (Generic classes and functions are parameterized over type > parameters and they have a type parameter list that is implicit in the > syntax. Generic classes can be explicitly instantiated by giving them type > arguments, and an instantiation has a (explicit or implicit) type argument > list.) > > So when I read: > > """ > As of this PEP, only a single type variable tuple may appear in a type > parameter list: > > class Array(Generic[*Ts1, *Ts2]): ... # Error\ > """ > > I interpreted it to mean that the error is that the type _parameters_ of > the generic class Array include *Ts1 and *Ts2 (not that they were used as > type arguments to Generic). Similarly, this should be an error: > > class Array(dict[*Ts1], Generator[*Ts2]): ... > > even though there is only a single type variable tuple appearing in a type > _argument_ list. > > The reason for the restriction is that the tupling of Array's type > arguments is not explicit in an instantiation of Array, so we rely on this > restriction so that they can be unambiguously tupled. > > I don't think there is necessarily a similar restriction on a generic > function's type parameters, because we don't have the ability to explicitly > instantiate generic functions anyway. > > An alternative wording is along the lines of: "As of this PEP, only a > single type variable tuple may appear among a generic class's type > parameters." > > def foo(*args: tuple[*Ts1, *Ts2]) -> ... > > is already prohibited by "Multiple Unpackings in a Tuple: Not Allowed". > > There are three other occurrences of "type parameter list" in the PEP. > Two of them talk about instantiating generic type aliases and should be > changed to "type argument list". The last one is less clear, I can't quite > parse out what it's trying to say. > > On Wed, Jan 12, 2022 at 5:04 PM Guido van Rossum wrote: > >> On Wed, Jan 12, 2022 at 4:57 AM Petr Viktorin >> wrote: >> >>> Matthew Rahtz wrote: >>> > Hi everyone, >>> > >>> > We've got to the stage now with PEP 646 that we're feeling pretty happy >>> > with it. So far though we've mainly been workshopping it in >>> typing-sig, so >>> > as PEP 1 requires we're asking for some feedback here too before >>> submitting >>> > it to the steering council. >>> > >>> > If you have time over the next couple of weeks, please take a look at >>> the >>> > current draft and let us know your thoughts: >>> > https://www.python.org/dev/peps/pep-0646/ (Note that the final couple >>> of >>> > sections are out of date; https://github.com/python/peps/pull/1880 >>> > clarifies which grammar changes would be required, now that PEP 637 has >>> > been rejected. We also have a second PR in progress at >>> > https://github.com/python/peps/pull/1881 clarifying some of the >>> motivation.) >>> > >>> > Thanks! >>> > Matthew and Pradeep >>> >>> Hi, >>> I'm very late to the discussion -- I relied on the typing-sig and SC to >>> handle this, but now that I'm on the SC, I no longer have that luxury :) >>> This mail has my own opinions, not necessarily the SC's. >>> >>> >>> I've read the PEP, and I quite like it! It's clear that typing-sig >>> thought this through very well. >>> The thing that surprised me is the proposed changes that affect more >>> than typing annotations. Quite deep in the PEP, the "Grammar Changes" >>> section explains the (quite exciting) change to make star-unpacking >>> possible in normal
[Python-Dev] Fwd: PEP 646 (Variadic Generics): final call for comments
Thanks for this feedback, Petr! *First point (indexing assignment)* Great catch; we hadn't thought about this. I agree it would be better to keep these in sync. I just tested this in our current CPython implementation, and can confirm it looks like this already works fine. So as much as I agree with Guido in preferring not to make too many more updates to the PEP, I guess we can indeed just fix this with a small clarification. I'll also add some tests for this to our CPython implementation. *Second point (multiple TypeVarTuples)* In terms of the wording in the PEP - Guido, our intention actually *was* to prohibit even the straightforward cases for now. Iirc, our reasoning was that we thought the decision boundary between "straightforward to infer type assignment" and "nontrivial to infer type assignment" (and of course "no unique type assignment") was tricky enough that we shouldn't complicate the already-long PEP by trying to describe all the cases where it was and wasn't ok. Petr, do I understand that the crux for you is basically that we should commit to multiple-stars at the syntax level - the main implication being to make sure we've properly documented and tested it? I'm happy with this; we plan to follow up with another PEP that *does* talk about when multiple unpackings are ok anyway. I guess we should just a) clarify in the PEP that allowing multiple unpackings in the grammar isn't accidental, and b) test this in our CPython implementation? *Third point (aliases)* This is actually a great point - I had to think about this myself. Since PEP 484 doesn't explicitly spell out how assignment of type to type variables in generic aliases works either, I had to try some things with mypy playground to figure out what the current rules are. I think the logic is, if we have an alias like Foo = tuple[T1, T1, T2] Foo[int, str] then we construct a list of unique type variables in the alias (here [T1, T2]), then assign types to those variables by going left to right through the type argument list when the alias is instantiated. Guido, can you remember from your time with mypy whether this is correct? Pradeep, I guess you'll also know about this? Based on that precedent, I believe that: SplitDataset = Tuple[Array[*Ts], Array[*Ts]] SplitDataset[Height] # Valid; equivalent Tuple[Array[Height], Array[Height]] (indeed, I just tested this with Pyre, and that matches our implementation there) For this one: TwoArrays = Tuple[Array[*Ts1], Array[*Ts2]] TwoArrays[Height] Since we we allow a TypeVarTuple to be bound to an *empty* list of types, when we try to assign type arguments [Height] to the unique list of type variables [Ts1, Ts2], I think we should end up with Ts1 containing Height and Ts2 being empty; thus: TwoArrays[Height] # Valid; equivalent to Tuple[Array[Height], Array[()]] But I actually can't get this to type check correctly in Pyre. Pradeep, this is the test I was using: https://gist.github.com/mrahtz/cc86c29538de1d4a80a2e8958ae71c5a Am I doing something wrong? Also, by that logic, in this situation *all* the type arguments would be assigned to Ts1, and Ts2 would always end up being empty. That seems a bit weird but...*shrug* it also seems correct. In any case, this is definitely something we should explain better in the PEP. I'll make a TODO for myself to write something on this once Pradeep and Guido have confirmed whether my understanding is correct. _______ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/3TGPEF465RBVLURM75RGRRR3627PXXNF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 646 (Variadic Generics): final call for comments
The wording there probably should be improved. I had a different interpretation when I read that, so that suggests it needs to be clarified. We should ensure to draw a clear distinction between type parameters and type arguments. (Generic classes and functions are parameterized over type parameters and they have a type parameter list that is implicit in the syntax. Generic classes can be explicitly instantiated by giving them type arguments, and an instantiation has a (explicit or implicit) type argument list.) So when I read: """ As of this PEP, only a single type variable tuple may appear in a type parameter list: class Array(Generic[*Ts1, *Ts2]): ... # Error\ """ I interpreted it to mean that the error is that the type _parameters_ of the generic class Array include *Ts1 and *Ts2 (not that they were used as type arguments to Generic). Similarly, this should be an error: class Array(dict[*Ts1], Generator[*Ts2]): ... even though there is only a single type variable tuple appearing in a type _argument_ list. The reason for the restriction is that the tupling of Array's type arguments is not explicit in an instantiation of Array, so we rely on this restriction so that they can be unambiguously tupled. I don't think there is necessarily a similar restriction on a generic function's type parameters, because we don't have the ability to explicitly instantiate generic functions anyway. An alternative wording is along the lines of: "As of this PEP, only a single type variable tuple may appear among a generic class's type parameters." def foo(*args: tuple[*Ts1, *Ts2]) -> ... is already prohibited by "Multiple Unpackings in a Tuple: Not Allowed". There are three other occurrences of "type parameter list" in the PEP. Two of them talk about instantiating generic type aliases and should be changed to "type argument list". The last one is less clear, I can't quite parse out what it's trying to say. On Wed, Jan 12, 2022 at 5:04 PM Guido van Rossum wrote: > On Wed, Jan 12, 2022 at 4:57 AM Petr Viktorin wrote: > >> Matthew Rahtz wrote: >> > Hi everyone, >> > >> > We've got to the stage now with PEP 646 that we're feeling pretty happy >> > with it. So far though we've mainly been workshopping it in typing-sig, >> so >> > as PEP 1 requires we're asking for some feedback here too before >> submitting >> > it to the steering council. >> > >> > If you have time over the next couple of weeks, please take a look at >> the >> > current draft and let us know your thoughts: >> > https://www.python.org/dev/peps/pep-0646/ (Note that the final couple >> of >> > sections are out of date; https://github.com/python/peps/pull/1880 >> > clarifies which grammar changes would be required, now that PEP 637 has >> > been rejected. We also have a second PR in progress at >> > https://github.com/python/peps/pull/1881 clarifying some of the >> motivation.) >> > >> > Thanks! >> > Matthew and Pradeep >> >> Hi, >> I'm very late to the discussion -- I relied on the typing-sig and SC to >> handle this, but now that I'm on the SC, I no longer have that luxury :) >> This mail has my own opinions, not necessarily the SC's. >> >> >> I've read the PEP, and I quite like it! It's clear that typing-sig >> thought this through very well. >> The thing that surprised me is the proposed changes that affect more >> than typing annotations. Quite deep in the PEP, the "Grammar Changes" >> section explains the (quite exciting) change to make star-unpacking >> possible in normal indexing operations, e.g.:: >> >> idxs_to_select = (1, 2) >> array[0, *idxs_to_select, -1] # Equivalent to [0, 1, 2, -1] >> >> However, the PEP is silent about indexing assignment, e.g.:: >> >> array[0, *idxs_to_select, -1] = 1 >> >> IMO, it would be very confusing to not keep these in sync. If they are, >> the assignment change should be documented and tested appropriately. Is >> that the plan? >> > > The previous SC approved the PEP despite this. > > If you want to convince the SC to request this feature parity in the PEP, > I won't stop you. > > But unless that happens I would rather not update the PEP again (it's been > tough to get to this point). > > Maybe you can write a separate PEP? That would probably be simpler for all > involved (the PEP 646 authors would not have to be involved, and the > separate PEP would be very straightforward. > > >> For a second point, the PEP says: >> >> > this PEP disallows multiple unpacked TypeVarTuples within a single type >
[Python-Dev] PEP 676 -- PEP Infrastructure Process
Hi, I would like to announce PEP 676 to python-dev. It is a meta-PEP focussed on modernising the PEP build infrastructure. From the abstract, "This PEP addresses the infrastructure around rendering PEP files from reStructuredText files to HTML webpages. We aim to specify a self-contained and maintainable solution for PEP readers, authors, and editors." Link: https://www.python.org/dev/peps/pep-0676/ Rendered through the PEP 676 system: https://python.github.io/peps/pep-0676/ Please see https://discuss.python.org/t/10774 for prior discussion and to give any feedback. Thanks, Adam Turner _______ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/C675PLAF535FSUL7KX4FS2NK6ZPPQ3HB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2021-12-31 - 2022-01-07)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7199 ( +4)
closed 50825 (+78)
total 58024 (+82)
Open issues with patches: 2886
Issues opened (50)
==
#34931: os.path.splitext with more dots
https://bugs.python.org/issue34931 reopened by xnovakj
#46009: sending non-None values makes generator raise StopIteration on
https://bugs.python.org/issue46009 reopened by christian.heimes
#46110: compile("-"*300 + "4", '', mode) causes hard crash
https://bugs.python.org/issue46110 reopened by pablogsal
#46216: spurious link to os.system() from os.times() documentation ent
https://bugs.python.org/issue46216 opened by emery.berger
#46217: 3.11 build failure on Win10: new _freeze_module changes?
https://bugs.python.org/issue46217 opened by terry.reedy
#46220: imaplib.py "select" mailbox names containing spaces.
https://bugs.python.org/issue46220 opened by mckenzm
#46223: asyncio cause infinite loop during debug
https://bugs.python.org/issue46223 opened by zillionare
#46225: f_lasti behaves differently for lambdas returned from loops
https://bugs.python.org/issue46225 opened by nedbat
#46226: User specific paths added to System PATH environment variable
https://bugs.python.org/issue46226 opened by akrymskiy
#46227: add pathlib.Path.walk method
https://bugs.python.org/issue46227 opened by Ovsyanka
#46232: Client certificates with UniqueIdentifier in the subject break
https://bugs.python.org/issue46232 opened by kacper
#46234: 3.11: Tracing of decorators now visits the decorator line befo
https://bugs.python.org/issue46234 opened by nedbat
#46235: Do all ref-counting at once for sequence multiplication
https://bugs.python.org/issue46235 opened by Dennis Sweeney
#46237: Incorrect line reported in syntax error
https://bugs.python.org/issue46237 opened by arian-f
#46242: Improve error message when attempting to extend an enum with `
https://bugs.python.org/issue46242 opened by sobolevn
#46244: typing._TypeVarLike missing __slots__
https://bugs.python.org/issue46244 opened by ariebovenberg
#46245: Add support for dir_fd in shutil.rmtree()
https://bugs.python.org/issue46245 opened by serhiy.storchaka
#46246: importlib.metadata.DeprecatedList appears to be missing __slot
https://bugs.python.org/issue46246 opened by ariebovenberg
#46247: in xml.dom.minidom, Node and DocumentLS appear to be missing _
https://bugs.python.org/issue46247 opened by ariebovenberg
#46249: [sqlite3] move set lastrowid out of the query loop and enable
https://bugs.python.org/issue46249 opened by erlendaasland
#46250: 3.10 docs responsive design removes navigation buttons (next,
https://bugs.python.org/issue46250 opened by vkvanjavk
#46252: SSLWantReadError causes _SelectorSocketTransport to close
https://bugs.python.org/issue46252 opened by matan1008
#46253: C API documentation of Py_UNICODE_* character properties macro
https://bugs.python.org/issue46253 opened by juliangilbey
#46254: Better fitting type for iterating in the trace_init C function
https://bugs.python.org/issue46254 opened by uriya1998
#46255: Remove unnecessary check in _IOBase._check*() methods
https://bugs.python.org/issue46255 opened by malin
#46258: Minor algorithmic improvements for math.isqrt
https://bugs.python.org/issue46258 opened by mark.dickinson
#46261: [doc] fix inaccuracies in sqlite3.Cursor.lastrowid docs
https://bugs.python.org/issue46261 opened by erlendaasland
#46264: 'I'.lower() should give non dotted i for LANG=tr_TR
https://bugs.python.org/issue46264 opened by fbacher
#46265: Error when cross compiling for hardfloat MIPS
https://bugs.python.org/issue46265 opened by jefferyto
#46267: gzip.compress incorrectly ignores level parameter
https://bugs.python.org/issue46267 opened by rhpvorderman
#46269: '__new__' is never shown in `dir(SomeEnum)`
https://bugs.python.org/issue46269 opened by sobolevn
#46270: Comparison operators in Python Tutorial 5.7
https://bugs.python.org/issue46270 opened by realjanpaulus
#46271: frozen modules are not regenerated on bytecode magic change wh
https://bugs.python.org/issue46271 opened by christian.heimes
#46272: Fix bitwise and logical terminology in python.gram
https://bugs.python.org/issue46272 opened by rhettinger
#46273: Document what asyncio.wait() and asyncio.as_completed() do if
https://bugs.python.org/issue46273 opened by termim
#46274: Tokenizer module does not handle backslash characters correctl
https://bugs.python.org/issue46274 opened by ucodery
#46275: caret location for syntax error pointing with f-strings
https://bugs.python.org/issue46275 opened by williamnavaraj
#46276: ImportError: DLL load failed while importing
https://bugs.python.org/issue46276 opened by 89z
#46279: [docs] Minor information-orderi
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2021-12-24 - 2021-12-31) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open7195 ( -1) closed 50747 (+41) total 57942 (+40) Open issues with patches: 2871 Issues opened (32) == #46118: Migrate importlib.resources into a package https://bugs.python.org/issue46118 reopened by jaraco #46175: Zero argument super() does not function properly inside genera https://bugs.python.org/issue46175 opened by tritium #46177: can't install launcher for all users https://bugs.python.org/issue46177 opened by Amine #46178: Remove `.travis.yml`? https://bugs.python.org/issue46178 opened by sobolevn #46180: Button clicked failed when mouse hover tooltip and tooltip des https://bugs.python.org/issue46180 opened by Jason990420 #46181: Destroying an expaned Combobox prevents Entry focus until Alt+ https://bugs.python.org/issue46181 opened by j.lahav #46182: `super` and descriptor clarification https://bugs.python.org/issue46182 opened by Arthur-Milchior #46184: Remove `netlify.toml`? https://bugs.python.org/issue46184 opened by sobolevn #46186: replace `io.IncrementalNewlineDecoder` with non incremental ne https://bugs.python.org/issue46186 opened by guoci #46187: Optionally support rounding for math.isqrt() https://bugs.python.org/issue46187 opened by rhettinger #46192: Optimize builtin functions min() and max() https://bugs.python.org/issue46192 opened by colorfulappl #46194: Wrong base class for transport returned by loop.create_datagra https://bugs.python.org/issue46194 opened by asvetlov #46195: Annotated and Optional get_type_hints buggy interaction https://bugs.python.org/issue46195 opened by med2277 #46196: documentation for cmd library should include columnize() funct https://bugs.python.org/issue46196 opened by sharewell #46197: ensurepip bootstrap breaks out of isolated environment https://bugs.python.org/issue46197 opened by kcdodd #46198: Duplicated test name `test_get_unstructured_invalid_ew` in `te https://bugs.python.org/issue46198 opened by sobolevn #46199: Calculation influenced by print https://bugs.python.org/issue46199 opened by wby78826 #46200: Discourage logging f-strings due to security considerations https://bugs.python.org/issue46200 opened by ariebovenberg #46201: PEP 495 misnames PyDateTime_DATE_GET_FOLD https://bugs.python.org/issue46201 opened by drougge #46202: remove opcode POP_EXCEPT_AND_RERAISE https://bugs.python.org/issue46202 opened by iritkatriel #46203: Add timeout for Windows build steps https://bugs.python.org/issue46203 opened by mark.dickinson #46204: Graphlib documentation (general cleanup) https://bugs.python.org/issue46204 opened by dam1784 #46205: Race condition in runtest_mp leads to hangs (never exits) https://bugs.python.org/issue46205 opened by colesbury #46206: Crash when editing emoji containing strings https://bugs.python.org/issue46206 opened by 10maurycy10 #46207: Log emit performance degradation in RotatingFileHandlers due t https://bugs.python.org/issue46207 opened by dfritz #46208: os.path.normpath change between 3.11.0a2 and 3.11.0a3+ https://bugs.python.org/issue46208 opened by hugovk #46209: add documentation for decoding newlines in the `io` module https://bugs.python.org/issue46209 opened by guoci #46210: print deadlocks https://bugs.python.org/issue46210 opened by notarealdeveloper #46211: Recursively calling makepasv() finally leads to core dumped. https://bugs.python.org/issue46211 opened by xxm #46212: Avoid temporary `varargs` tuple creation in argument passing https://bugs.python.org/issue46212 opened by colorfulappl #46213: webbrowser.open doesn't work in Termux https://bugs.python.org/issue46213 opened by DonaldDuck1313 #46214: Remove unused opcode ROT_FOUR https://bugs.python.org/issue46214 opened by iritkatriel Most recent 15 issues with no replies (15) == #46214: Remove unused opcode ROT_FOUR https://bugs.python.org/issue46214 #46213: webbrowser.open doesn't work in Termux https://bugs.python.org/issue46213 #46211: Recursively calling makepasv() finally leads to core dumped. https://bugs.python.org/issue46211 #46210: print deadlocks https://bugs.python.org/issue46210 #46209: add documentation for decoding newlines in the `io` module https://bugs.python.org/issue46209 #46207: Log emit performance degradation in RotatingFileHandlers due t https://bugs.python.org/issue46207 #46205: Race condition in runtest_mp leads to hangs (never exits) https://bugs.python.org/issue46205 #46204: Graphlib documentation (general cleanup) https://bugs.python.org/issue46204 #46203: Add timeout for Windows build steps https://bugs.python.org/issue46203 #46202: remove opcode POP_EXCEPT_AND_RERAISE https://bugs.python.org/issue46202 #46201: PEP 495 misnames PyDateTime_DATE_GET_FOLD https
[Python-Dev] Requesting a code review for #29560 (bpo-26175: Implement io.IOBase interface for SpooledTemporaryFile)
Hi all, I submitted my first PR against Python a month or so ago and was wondering if someone could take a quick look at it and let me know if anything needs to be fixed before it can be merged. It's a pretty simple change (mostly just boilerplate delegation) that allows SpooledTemporaryFile objects to be used like all other io.IOBase objects. This brings it more inline with the documentation, as well as fixes a variety of use cases that require the `seekable`, `readable`, etc. methods to be available on it. Python bug: https://bugs.python.org/issue26175 Current PR: https://github.com/python/cpython/pull/29560 Thanks! Carey ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/B3PPGZJYAOHPNFP5ECJ3REC3DEYCVPGC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2021-12-17 - 2021-12-24) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open7196 (+16) closed 50706 (+41) total 57902 (+57) Open issues with patches: 2866 Issues opened (37) == #44598: test_constructor (test.test_ssl.ContextTests) ... Fatal Python https://bugs.python.org/issue44598 reopened by sxt1001 #46118: Migrate importlib.resources into a package https://bugs.python.org/issue46118 opened by jaraco #46119: Update bundled pip to 21.3.1 and setuptools to 59.7.0 https://bugs.python.org/issue46119 opened by kumaraditya303 #46120: Add note to `typing.Union` that it is recommended to use `|` i https://bugs.python.org/issue46120 opened by sobolevn #46121: Add a note to QueueListener documentation saying that SimpleQu https://bugs.python.org/issue46121 opened by iamdbychkov #46124: Deprecation warning in zoneinfo module https://bugs.python.org/issue46124 opened by xtreak #46125: Test the preferred API instead of relying on legacy for covera https://bugs.python.org/issue46125 opened by jaraco #46126: Unittest output drives developers to avoid docstrings https://bugs.python.org/issue46126 opened by jaraco #46128: Strip IsolatedAsyncioTestCase frames from reported stacktraces https://bugs.python.org/issue46128 opened by asvetlov #46133: Unclear whether one can (or how to) provide source to exec-gen https://bugs.python.org/issue46133 opened by posita #46134: Confusing error message for AttributeError with dataclasses https://bugs.python.org/issue46134 opened by landonjpginn #46141: Fix ipaddress.ip_network TypeErrors https://bugs.python.org/issue46141 opened by bar.harel #46142: python --help output is too long https://bugs.python.org/issue46142 opened by eric.araujo #46143: [docs] IO > Text Encoding info outdated https://bugs.python.org/issue46143 opened by gilbertson.david #46146: Python IDLE fails to start (tk font issue?) https://bugs.python.org/issue46146 opened by mcepl #46147: Support AddressSanitizer in Windows build https://bugs.python.org/issue46147 opened by anthonypjshaw #46148: Optimize pathlib https://bugs.python.org/issue46148 opened by kumaraditya303 #46149: FIPS usedforsecurity flag is no longer functional with OpenSSL https://bugs.python.org/issue46149 opened by florinspatar #46150: test_pathlib assumes "fakeuser" does not exist as user https://bugs.python.org/issue46150 opened by twouters #46151: SimpleCookie.js_output is vulnerable to HTML injection https://bugs.python.org/issue46151 opened by trungpaaa #46154: MIMEMultipart enforces line endings also for binary subparts https://bugs.python.org/issue46154 opened by sophonet #46156: 3.9.9: python built-in SSL module unable to connect to an IIS https://bugs.python.org/issue46156 opened by lkraav #46157: Typo in JSON documentation https://bugs.python.org/issue46157 opened by jordan-bonecutter #46158: Hardcoded sysroot path, to MacOSX11.sdk, in python sysconfig https://bugs.python.org/issue46158 opened by akumar9 #46159: Segfault when using trace functions in 3.11a3 https://bugs.python.org/issue46159 opened by reaperhulk #46161: `class A(1, 2, 3, **d): pass` gives bad bytecode https://bugs.python.org/issue46161 opened by zq1997 #46162: Make `builtins.property` generic https://bugs.python.org/issue46162 opened by sobolevn #46163: multiprocessing logger deadlocks if used with logging.handlers https://bugs.python.org/issue46163 opened by iamdbychkov #46166: Get "self" args or non-null co_varnames from frame object with https://bugs.python.org/issue46166 opened by Skylion007 #46167: Parse assert (x == y, "Descriptive text") as statement params https://bugs.python.org/issue46167 opened by gregory.p.smith #46168: Incorrect format specified for the "style" key in the configur https://bugs.python.org/issue46168 opened by bokunogf #46169: Same-moment datetimes with different ZoneInfo timezones are no https://bugs.python.org/issue46169 opened by huonw #46170: Improving the error message when subclassing NewType https://bugs.python.org/issue46170 opened by Gobot1234 #46171: venv module produces spurious warning that location has moved https://bugs.python.org/issue46171 opened by layday #46172: [doc] Outdated description of `license` object https://bugs.python.org/issue46172 opened by CCXXXI #46173: float(x) with large x not raise OverflowError https://bugs.python.org/issue46173 opened by cykerway #46174: Feature Request for Python Interfaces https://bugs.python.org/issue46174 opened by Orie Most recent 15 issues with no replies (15) ====== #46174: Feature Request for Python Interfaces https://bugs.python.org/issue46174 #46172: [doc] Outdated description of `license` object https://bugs.python.org/issue46172 #46170: I
[Python-Dev] Re: RFC on Callable Syntax PEP
Ahah, that makes sense. But then I think I buy into your reasoning that this isn't really a replacement for callable syntax (although functions as types opens up other interesting possibilities). For this and other reasons I'd hate to see callable syntax rejected in favor of it, so definite +1 on new callable syntax for me. p.s. I'm +0.5 on | binding tighter than -> ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ZURCWPSOE72MFPWONUIOH3XWVJ6ETWR5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: RFC on Callable Syntax PEP
Does `lambda b: 3` type check with `IntToIntFunc` or only `lambda a: 3`? The intent seems to be it's more like `Callable` (where the argument name is not important), but maybe both could be supported? I wonder about making more use of the `_` soft keyword where calling a function with multiple `_` is a runtime error. Maybe it would make too much of a mess. After some testing evidently mypy only applies its knowledge sometimes anyway: https://github.com/python/mypy/issues/11807 ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/MDR2TCLEN7YKNUHKID5D6KMBJL73UBOZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2021-12-10 - 2021-12-17) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open7180 (-15) closed 50665 (+93) total 57845 (+78) Open issues with patches: 2857 Issues opened (56) == #20741: Documentation archives should be available also in tar.xz form https://bugs.python.org/issue20741 reopened by iritkatriel #23522: Misleading note in Statistics module documentation https://bugs.python.org/issue23522 reopened by gvanrossum #29221: ABC Recursion Error on isinstance() with less than recursion l https://bugs.python.org/issue29221 reopened by serhiy.storchaka #43749: venv module does not copy the correct python exe https://bugs.python.org/issue43749 reopened by eryksun #44413: OverflowError: mktime argument out of range after 2019 https://bugs.python.org/issue44413 reopened by andrei.avk #46044: Update distutils documentation to say PyPI only accepts tar.g https://bugs.python.org/issue46044 opened by mbussonn #46045: NetBSD: do not use POSIX semaphores https://bugs.python.org/issue46045 opened by wiz #46050: [pathlib] Option so that OSError does not block glob in pathli https://bugs.python.org/issue46050 opened by matt32106 #46051: Make @atexit.register work for functions with arguments https://bugs.python.org/issue46051 opened by quapka #46052: IDLE: make Ctrl,Alt + IME non-ascii letter work on Windows https://bugs.python.org/issue46052 opened by anton.bryl #46053: NetBSD: ossaudio support incomplete https://bugs.python.org/issue46053 opened by wiz #46054: Incorrect error when parsing non-utf8 files https://bugs.python.org/issue46054 opened by pablogsal #46055: Speed up binary shifting operators https://bugs.python.org/issue46055 opened by xuxinhang #46061: Journal execution gives fatal error in Python 3.10.1 https://bugs.python.org/issue46061 opened by eaqrzn #46064: Permalinks to underscored documentation entries don't work. https://bugs.python.org/issue46064 opened by Fabian Dill #46065: re.findall takes forever and never ends https://bugs.python.org/issue46065 opened by ramzitra #46066: TypedDict alternative definition syntax with keyword args is c https://bugs.python.org/issue46066 opened by 97littleleaf11 #46067: SSLContext.set_npn_protocols broken in Python 3.10, tries to c https://bugs.python.org/issue46067 opened by diabonas #46068: Change use of warnings.warn to logging.warning in a few places https://bugs.python.org/issue46068 opened by andrei.avk #46070: _PyImport_FixupExtensionObject() regression causing a crash in https://bugs.python.org/issue46070 opened by graysky #46071: Graphlib documentation https://bugs.python.org/issue46071 opened by dam1784 #46072: Unify handling of stats in the CPython VM https://bugs.python.org/issue46072 opened by Mark.Shannon #46073: ast.unparse produces: 'FunctionDef' object has no attribute 'l https://bugs.python.org/issue46073 opened by TheRobotCarlson #46075: CookieJar.extract_cookies doesn't process cookies form local d https://bugs.python.org/issue46075 opened by keddad #46076: Document using __slots__ to provide per-attribute docstrings https://bugs.python.org/issue46076 opened by AlexWaygood #46077: Include sha256 hashes of release downloads in announcement com https://bugs.python.org/issue46077 opened by gregory.p.smith #46079: [doc] Broken URL in "Brief Tour of the Standard Library" https://bugs.python.org/issue46079 opened by vivekvashist #46080: argparse.BooleanOptionalAction with default=argparse.SUPPRESS https://bugs.python.org/issue46080 opened by felixfontein #46083: PyUnicode_FSConverter() has confusing reference semantics https://bugs.python.org/issue46083 opened by twouters #46084: Python 3.9.6 scan_dir returns filenotfound on long paths, but https://bugs.python.org/issue46084 opened by jschwar313 #46085: OrderedDict iterator allocates di_result unnecessarily https://bugs.python.org/issue46085 opened by Kevin Shweh #46086: Add ratio_min() function to the difflib library https://bugs.python.org/issue46086 opened by gibu #46088: Build hangs under Visual Studio in deepfreeze stage https://bugs.python.org/issue46088 opened by gvanrossum #46089: Problems with AF_PACKET sockets https://bugs.python.org/issue46089 opened by gallard #46090: C extensions can't swap out live frames anymore https://bugs.python.org/issue46090 opened by brandtbucher #46091: IndendationError from multi-line indented statements https://bugs.python.org/issue46091 opened by ucodery #46092: Fix/update missing parameters in function signatures for Built https://bugs.python.org/issue46092 opened by vivekvashist #46094: Missing unit test on unittest.TestResult to check for required https://bugs.python.org/issue46094 opened by DreamSh0t #46095: Warning about iterate/modify has unwarranted detail https://bugs.python.org/
[Python-Dev] Re: "immortal" objects and how they would help per-interpreter GIL
I've just updated the original Immortal Instances PR with a bunch of tricks that I used to achieve as much performance parity as possible: https://github.com/python/cpython/pull/19474 . You can see the details along with some benchmarks in the PR itself. This should address a bunch of the original performance concerns. Furthermore, it opens up the possibility of iterating on top of this to keep improving perf (i.e immortal intern strings, immortal heap types, less gc cycles from moving long lived objects to the perm gen, etc.). ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/IDG6XIL7265EYGV5ZANOTQ7SPXU55HNT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2021-12-03 - 2021-12-10) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open7195 (-57) closed 50572 (+123) total 57767 (+66) Open issues with patches: 2859 Issues opened (44) == #23469: Delete Misc/*.wpr files https://bugs.python.org/issue23469 reopened by berker.peksag #28533: Remove asyncore, asynchat and smtpd modules https://bugs.python.org/issue28533 reopened by vstinner #31184: Fix data descriptor detection in inspect.getattr_static https://bugs.python.org/issue31184 reopened by davidhalter #45620: A misleading url in 'Floating Point Arithmetic' page https://bugs.python.org/issue45620 reopened by eric.smith #45798: Move _decimal build setup into configure https://bugs.python.org/issue45798 reopened by ned.deily #45975: Simplify some while-loops with walrus operator https://bugs.python.org/issue45975 opened by nickdrozd #45977: Unexpected effect of sys.pycache_prefix = "" https://bugs.python.org/issue45977 opened by andrei.avk #45978: deepfreeze opaquely fails on Windows when building from Visual https://bugs.python.org/issue45978 opened by Dennis Sweeney #45979: Fix Tkinter tests with old Tk https://bugs.python.org/issue45979 opened by serhiy.storchaka #45981: Get raw file name in bytes from ZipFile https://bugs.python.org/issue45981 opened by accelerator0099 #45985: AttributeError from @property inadvertantly flows into __getat https://bugs.python.org/issue45985 opened by koreno #45988: inspect.signature fails on a @staticmethod https://bugs.python.org/issue45988 opened by PhilipVinc #45990: Exception notes need more documentation https://bugs.python.org/issue45990 opened by cool-RR #45991: Improve ambiguous docstrings in pkgutil https://bugs.python.org/issue45991 opened by khock #45992: distutils paths are scattered between PythonXY and PythonXY-32 https://bugs.python.org/issue45992 opened by uranusjr #45994: Add simple usage to email module https://bugs.python.org/issue45994 opened by tarao1006 #45995: string formatting: normalize negative zero https://bugs.python.org/issue45995 opened by John Belmonte #45996: Worse error from asynccontextmanager in Python 3.10 https://bugs.python.org/issue45996 opened by Dima.Tisnek #45997: asyncio.Semaphore waiters deque doesn't work https://bugs.python.org/issue45997 opened by hyzyla #45998: Document best practice for including and linking python framew https://bugs.python.org/issue45998 opened by ronaldoussoren #46005: [doc] replace 'distutils' examples with 'setuptools' https://bugs.python.org/issue46005 opened by elmjag #46006: [subinterpreter] _PyUnicode_EqualToASCIIId() issue with subint https://bugs.python.org/issue46006 opened by vstinner #46010: Cookie cutter templates to allow variable fields and data tran https://bugs.python.org/issue46010 opened by Francisco #46011: Python 3.10 email returns invalid Date: header unchanged. https://bugs.python.org/issue46011 opened by msapiro #46013: Confusing period in object.__hash__ doc https://bugs.python.org/issue46013 opened by JMcB17 #46014: functools.singledispatch does not support Union types https://bugs.python.org/issue46014 opened by evansd #46017: Tutorial incorrectly refers to skits rather than sketches. https://bugs.python.org/issue46017 opened by k2k #46020: Optimize long_pow for the common case https://bugs.python.org/issue46020 opened by rhettinger #46021: fcntl module update supports FreeBSD F_KINFO flag https://bugs.python.org/issue46021 opened by devnexen #46022: Multiprocessing.Server.serve_forever runs sys.exit() https://bugs.python.org/issue46022 opened by bar.harel #46023: Modules/makesetup generated rules ignore *disabled* https://bugs.python.org/issue46023 opened by christian.heimes #46024: Different behaviour with zipfile https://bugs.python.org/issue46024 opened by flvn.dev #46026: importlib.resources.read_text() raises FileNotFound https://bugs.python.org/issue46026 opened by Zac Hatfield-Dodds #46027: email.utils.parsedate_to_datetime() handling of - offset https://bugs.python.org/issue46027 opened by fdrake #46028: 3.11.0a3: under tox, sys._base_executable is wrong https://bugs.python.org/issue46028 opened by nedbat #46030: socket module add couple of FreeBSD constants https://bugs.python.org/issue46030 opened by dcarlier #46031: add POP_JUMP_IF_NOT_NONE and POP_JUMP_IF_NONE https://bugs.python.org/issue46031 opened by penguin_wwy #46032: functools' singledispatch does not support GenericAlias https://bugs.python.org/issue46032 opened by kumaraditya303 #46033: Duplicated sentence in for statement documentation https://bugs.python.org/issue46033 opened by michcio1234 #46035: mimetypes.guess_type returns deprecated mimetype application/x https://bugs.python.org/issue46035 opened by milahu #46036: Single-phase i
