[Python-Dev] Re: RFC: New/update the Docs Sphinx theme: responsive, edit page links,

[Senthil Kumaran]

Replying to Python-Dev. I hope you found the list and got feedback from
the documentation maintainers. Python devguide
https://devguide.python.org/ was using an updated theme, and I assume
that docs will get updated soon a responsive. There have been plenty
discussions on this front.


Thank you,
Senthil
___
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/XIJ7KMLDAVMVCGILH5TJY2IPOANV7TW6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: f-strings in the grammar

[Nick Coghlan]

On Mon, 20 Sep 2021, 9:19 pm Pablo Galindo Salgado, 
wrote:

> Hi,
>
> I have started a project to move the parsing off-strings to the parser and
> the grammar. Appart
> from some maintenance improvements (we can drop a considerable amount of
> hand-written code),
> there are some interesting things we **could** (emphasis on could) get out
> of this and I wanted
> to discuss what people think about them.
>

The change seems like a good idea, but the consequences should be
summarised in a PEP (either the existing
https://www.python.org/dev/peps/pep-0536/ or a replacement for it).

Cheers,
Nick.

>
>
___
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/6JCSTZNIKWX7HMJO5RIAH3QARXWJSWFZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Porting python.gram to Python

[Pablo Galindo Salgado]

Hi Erik,

My first question is whether anyone is working on this as well (or
> hasalready done so and I missed it), to avoid duplication of effort.


We have already done this work. This was a contribution by Matthieu
Dartiailh:

https://github.com/we-like-parsers/pegen/blob/main/data/python.gram

I hope you find this useful,

Cheers from cloudy London,
Pablo


On Thu, 23 Sept 2021 at 20:10, Erik Demaine  wrote:

> Dear python-dev,
>
> I've been working on a port of cpython/Grammar/python.gram from C (as
> currently used in all the {} expressions to build the AST) to Python,
> directly
> building nodes via the ast package.  My motivation for this (as opposed to
> calling ast.parse, which uses the C parser) is to make it easy to
> experiment
> with adding features to the syntax, without having to build CPython.
> Porting
> is mostly straightforward, but it is a fair amount of work, because there
> are
> a lot of expressions to port
>
> My first question is whether anyone is working on this as well (or has
> already done so and I missed it), to avoid duplication of effort.
>
> Assuming not, my next question is where this belongs.  Some natural
> options I
> see:
>
> 1. Add it to cpython as a grammar maintained in parallel with the C
> grammar.
> This would mean more maintenance when the grammar changes, but the plus
> side
> is it guarantees that the two grammars (and ast) remain synchronized.
>
> 2. PyPy
>
> 3. 3rd party library (e.g., my own repo)
>
> Let me know what you think would be best.
>
> Erik
> --
> Erik Demaine  |  edema...@mit.edu  |  http://erikdemaine.org/
> ___
> 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/UM7ANICTBDU3Q2DLKFZIK6C6OU3THKP4/
> 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/VN7HT3O4ZX6GEVUE4SGNRVU6WYZCLUG5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Porting python.gram to Python

[Erik Demaine]

Dear python-dev,

I've been working on a port of cpython/Grammar/python.gram from C (as 
currently used in all the {} expressions to build the AST) to Python, directly 
building nodes via the ast package.  My motivation for this (as opposed to 
calling ast.parse, which uses the C parser) is to make it easy to experiment 
with adding features to the syntax, without having to build CPython.  Porting 
is mostly straightforward, but it is a fair amount of work, because there are 
a lot of expressions to port


My first question is whether anyone is working on this as well (or has 
already done so and I missed it), to avoid duplication of effort.


Assuming not, my next question is where this belongs.  Some natural options I 
see:


1. Add it to cpython as a grammar maintained in parallel with the C grammar. 
This would mean more maintenance when the grammar changes, but the plus side 
is it guarantees that the two grammars (and ast) remain synchronized.


2. PyPy

3. 3rd party library (e.g., my own repo)

Let me know what you think would be best.

Erik
--
Erik Demaine  |  edema...@mit.edu  |  http://erikdemaine.org/
___
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/UM7ANICTBDU3Q2DLKFZIK6C6OU3THKP4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] July Steering Council update.

[Thomas Wouters]

FYI, I've just published the July steering council update, also included
below:

https://github.com/python/steering-council/blob/main/updates/2021-07-steering-council-update.md

Just as a reminder, if you have any questions or concerns, feel free to
contact us or open an issue in the SC repo:
https://github.com/python/steering-council

July 5

   - No regular meeting because of the US holiday.
   - Most of the Steering Council met with Nathaniel Smith to discuss his
   alternative proposal for PEP 654
    (Exception Groups and except
   *).
   - Nathaniel and Carol will work to flesh out his proposal.

July
12

   - Steering Council discussed a clarification request from the PyPA folks
   around PEPs. It was determined that PyPA folks can sponsor their own PEPs.
   Brett informed them by responding to the comment.
   - SC discussed the enum repr() and str() changes in 3.10 and 3.11.
   - SC discussed PEP 582  (Python
   local packages directory).

July
19

   - Steering Council met with Łukasz, the Developer-in-Residence for the
   first time. The group discussed prioritization, balancing, and how to
   handle group requests. The Steering Council needs to handle prioritization
   if folks send Łukasz their lists of jobs. The group also discussed how this
   role is going to impact the strategic approach of merging issues from
   bugs.python.org to GitHub. A group Slack channel was created for Łukasz
   to have a way to ping the SC outside of email. The SC and Łukasz will meet
   every two weeks for now.
   - Group discussed PEP 649
 (Deferred
   Evaluation Of Annotations Using Descriptors) and typing in general. The
   group determined that they need to discuss the status of typing as part of
   the language, and write up a PEP to the community so the community knows
   how to proceed with typing PEPs.
   - Steering Council will continue to review PEP 648
    (Extensible customizations
   of the interpreter at startup) and will discuss it via email.

July
26

   - The Steering Council discussed PEP 648
    (Extensible customizations
   of the interpreter at startup) and decided the PEP needed more use cases
   and feedback from the community. The group is going to draft a response
   (reject it and tell them use cases are needed) and Barry will send it. If
   the PEP author provides use cases the SC can revisit the PEP later.
   - The SC discussed PEP 467
 (Minor
   API improvements for binary sequences) and decided that they will recommend
   removing the bchr builtin from the PEP and then the SC can review the
   revised PEP if the author wants to revisit it.
   - Thomas created the private Python committers Discord and Pablo
   suggested we use it for the next virtual Sprint, which the group agrees
   with.


-- 
Thomas Wouters 

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
___
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/LFGIY65HDOUBRE44HGXOC6UPDBIPIEYQ/
Code of Conduct: http://python.org/psf/codeofconduct/