Python-Dev December 2022

python-dev@python.org

39 participants
15 discussions

PEP 638: Syntactic macros
by Mark Shannon 05 Feb '23

05 Feb '23

Hi everyone, I've submitted my PEP on syntactic macros as PEP 638. https://www.python.org/dev/peps/pep-0638/ All comments and suggestions are welcome. Cheers, Mark

16 24

Switching to Discourse
by Petr Viktorin 26 Jan '23

26 Jan '23

Hello, Currently development discussions are split between multiple communication channels, for example: - python-dev and discuss.python.org for design discussions, - GitHub Issues and Pull Requests for specific changes, - IRC, Discord and private chats for real-time discussions, - Topic-specific channels like typing-sig. While most of these serve different needs, there is too much overlap between python-dev and discuss.python.org. It seems that for most people, this situation is worse than sticking to either one platform – even if we don't go with that person's favorite. The discuss.python.org 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 is much easier to moderate.. If you're following python-dev but not discuss.python.org, you're missing out. The Steering Council would like to switch from python-dev to discuss.python.org. Practically, this means: - Moving the required PEP announcements to discuss.python.org - Moving discuss.python.org up in the devguide communications page (https://devguide.python.org/communication/) - And that's it? I imagine that the mailing list will stay around for continuing past discussion threads and for announcements, eventually switching to auto-reject incoming messages with a pointer to discuss.python.org. To be clear, discuss.python.org allows editing posts, which is frankly handy for typos and clarifications. Editing alone should not be used for adding new info -- we should cultivate a culture of being friendly to mail users & notification watchers. This probably bears repeating in a few places. We're aware not everyone wants to use the discuss.python.org website, but there are some ways to avoid it: - For new PEPs, you can point your RSS client to https://www.python.org/dev/peps/peps.rss – it's not e-mail, but many email clients have RSS support. You can also watch the Steering Council issues on GitHub (https://github.com/python/steering-council/issues/) for important questions and discussions. - You can use discuss.python.org's “mailing list mode” (which subscribes you to all new posts), possibly with filtering and/or categorizing messages locally. However, we would like to know if this will pose an undue burden to anyone, if there are workflows or usage problems that we are not aware of. As mentioned, this is something the Steering Council thinks is a good idea, but we want to make sure we're aware of all the impact when we make the final decision. – Petr, on behalf of the Steering Council

43 114

Re: PEP 701 – Syntactic formalization of f-strings
by Rob Cliffe 22 Dec '22

22 Dec '22

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/2… > *** > > Thanks a lot, everyone for your time! > > Regards from rainy London, > Pablo Galindo Salgado > > _______________________________________________ > Python-Dev mailing list --python-dev(a)python.org > To unsubscribe send an email topython-dev-leave(a)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/IU4O3… > Code of Conduct:http://python.org/psf/codeofconduct/

1 0

Feature Request: Adding Way to Annotate Class Variables Distinct from Instance Variables
by sakaic2003＠gmail.com 21 Dec '22

21 Dec '22

Hello folks, I am Chihiro, a.k.a. Frodo821, and this is my first post to this group. I searched for a way to annotate both class variables and instance variables with different types and concluded that there is currently no way to do this. For example, what I want to: ``` class Foo: variable_both_class_and_instance = Field(desc="descriptive string") def __init__(self, value: int): self.variable_both_class_and_instance = value assert isinstance(Foo.variable_both_class_and_instance, Field) assert isinstance(Foo().variable_both_class_and_instance, int) ``` In this example, I want to annotate `Foo.variable_both_class_and_instance` with `Field` when it is accessed as a class variable. On the other hand, I want to annotate `Foo.variable_both_class_and_instance` with `int` when it is accessed as an instance variable. I don't have any smart ideas to accomplish this, but I think `typing.ClassVar` could be extended this like: ``` class Foo: variable_both_class_and_instance: Union[ClassVar[Field], int] = Field(desc="descriptive string") def __init__(self, value: int): self.variable_both_class_and_instance = value assert isinstance(Foo.variable_both_class_and_instance, Field) assert isinstance(Foo().variable_both_class_and_instance, int) ``` Do you have any ideas or comments about this?

4 3

PEP 701 – Syntactic formalization of f-strings
by Pablo Galindo Salgado 21 Dec '22

21 Dec '22

Hi everyone, I am very excited to share with you a PEP that Batuhan 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: - Reduced maintenance costs for f-string parsing code as well as improved usability for users and library developers. - Better error messages involving f-strings by leveraging the PEG parser machinery. - 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/2… <https://discuss.python.org/t/pep-701-syntactic-formalization-of-f-strings/2…> *** Thanks a lot, everyone for your time! Regards from rainy London, Pablo Galindo Salgado

1 1

computersmarketing
by jugnu7271＠gmail.com 20 Dec '22

20 Dec '22

I am jugnu25 working for computers marketing PR consultant. With extra than 6 years experience in PR and Digital Industry, helping groups to obtain dreams through streamilining the technique. https://www.computersmarketing.com/

2 1

problem with abandonned lib pyliblo
by Mathieu Picot 20 Dec '22

20 Dec '22

Hi. There is a problem with the lib pyliblo, the source code of the lib is here: https://github.com/dsacre/pyliblo The problem is that the lib is now incompatible with python3.11 because it uses inspect.getargspec function which does not exist anymore. This is very easy to fix, the main problem is that the author Dominic Sacré does not answer anymore to any message (PR, issues, email), so there is no hope he will fix the problem. I am ready to maintain this lib myself, I could simply fork it and rename the lib to pass it to pip list, but all programs using it will have to rename the lib in their requirements. Is there a sort of protocol to do when this happens, in order to replace the source package with a new version ? thanks for your help Mathieu

2 1

probably nothing but just in case.... 503 Service Unavailable error
by wonsuk yang 15 Dec '22

15 Dec '22

hi! thank you for amazing community! the python community is the light and the salt for me! the site https://buildbot.python.org/all/#/grid from https://www.python.org/dev/buildbot/ shows the error of "503 Service Unavailable; No server is available to handle this request." i reckon the site might be deprecated yet report this just in case sorry to bother if it is already known! hope the best w. yang

2 2

Python Launcher not Installed on Windows Machine
by Margo Hoover 15 Dec '22

15 Dec '22

Dear Jonathan and Brian, I have python and pip installed on my Windows machine. However, I do not seem to have the python launcher installed (if that is even possible). I am a very beginner in Python. Could you explain how I should 'download' the python installer, or if I should even do that. What would be a next step? Thank you once again, Sincerely, Margaux Hoover -- Margaux Hoover Xtrepid Design

3 2

Re: A proposal to modify `None` so that it hashes to a constant
by Rob Cliffe 11 Dec '22

11 Dec '22

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 <rosuav(a)gmail.com> wrote: >> On Thu, 1 Dec 2022 at 17:26, Yoni Lavi <yoni.lavi.p(a)gmail.com> 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(a)python.org > To unsubscribe send an email to python-dev-leave(a)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/MTTJJN2… > Code of Conduct: http://python.org/psf/codeofconduct/

3 3

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev December 2022