I don't think the PEG parser switch would change anything -- it produces
the same AST as the old parser and ast.parse().
It looks a reasonable thing to move into the stdlib (maybe as
ast.unparse()?), assuming it's complete. Tests and doc need to be written.
On Tue, Nov 19, 2019 at 1:08 AM Mahmoud
>From the first time I found it years ago, I've often wondered why it wasn't
exposed. I presumed due to certain API shifts I wasn't paying close
attention to, that maybe the ast module was buffering. But I've definitely
wanted to import it in the past.
If the API is as stable as you say, then I gu
Hi,
What do people feel about exposing Tools/parser/unparse.py in the standard
library? Here is my initial rationale:
* The tool already needs to be maintained and updated as is tested as part
of the test suite.
* I have used the tool almost all the time I needed to deal with AST
transformations.
Guido,
Thank you for your generous comments. All of them.
On 2019/11/18 15:33, Guido van Rossum wrote:
It won't be easy to add this to the stdlib.
Maybe there are other existing threads that considered a new recursive
mapping object for stblib that someone can point me to?
One thing that b
On Tue., 19 Nov. 2019, 7:32 am Dave Cinege, wrote:
> Tal,
>
> On 2019/11/18 10:59, Tal Einat wrote:
> >
> > These days, thanks to pip and PyPI, anyone can publish libraries and it
> > is easy for developers to find and use them if they like. There is no
> > longer a need to add things to the stdl
On Tue., 19 Nov. 2019, 6:46 am , wrote:
>
> Thus, my proposal is to change the default value for UDP to False or
> deprecate the function and introduce a new one as suggested by Yuri in my
> original bug report at: https://bugs.python.org/issue37228
Guido's suggestion on the ticket sounds like
On Mon., 18 Nov. 2019, 8:19 am Nathaniel Smith, wrote:
>
> > - Eventually make it easier for embedding applications to control which
> Python code runs in which thread state by moving the thread state
> activation dance out of the application and into the CPython shared library
>
> That seems lik
Tal,
On 2019/11/18 10:59, Tal Einat wrote:
These days, thanks to pip and PyPI, anyone can publish libraries and it
is easy for developers to find and use them if they like. There is no
longer a need to add things to the stdlib just to make them widely
available.
Fair enough, only that you
When creating UDP servers with asyncio's create_datagram_endpoint(), the
default value for reuse_address = True, resulting in a dangerous (and currently
incorrectly documented) situation. I have proposed changing the default value
but understandably such a change for a core library function para
When creating UDP servers with asyncio's create_datagram_endpoint(), the
default value for reuse_address = True, resulting in a dangerous (and currently
incorrectly documented) situation. I have proposed changing the default value
but understandably such a change for a core library function para
It won't be easy to add this to the stdlib. One thing that bugs me in
particular is that you can access key via '.attr' notation (the example
shows t['a']['b']['c']['d'] as equivalent to t.a.b.c.d). This feels
problematic: What should happen if the key happens to be the name of a
method (e.g. .keys
On Mon, 18 Nov 2019 12:39:00 -0500
Random832 wrote:
> On Mon, Nov 18, 2019, at 05:26, Antoine Pitrou wrote:
> > > For the first goal, I don't think this is possible, or desirable.
> > > Obviously if we remove the GIL somehow then at a minimum we'll need to
> > > make the global threadstate a threa
On Mon, Nov 18, 2019, at 05:26, Antoine Pitrou wrote:
> > For the first goal, I don't think this is possible, or desirable.
> > Obviously if we remove the GIL somehow then at a minimum we'll need to
> > make the global threadstate a thread-local. But I think we'll always
> > have to keep it around
Hello Tal,
Yes I understand that. I posted this here because it's been suggested by
those less in the know that Thesaurus and ThesaurusCfg (or some of the
the concepts contained in them) might have a place in the future mainline.
Remember that Thesaurus is a data type and ThesaurusCfg is a al
On Mon, Nov 18, 2019 at 5:30 PM Dave Cinege wrote:
> Hello Tal,
>
> Yes I understand that. I posted this here because it's been suggested by
> those less in the know that Thesaurus and ThesaurusCfg (or some of the
> the concepts contained in them) might have a place in the future mainline.
>
Ah,
Hi Dave,
Thesaurus looks interesting and it is obvious that you've put a lot of
effort into it!
This list is for the discussion of the development *of* Python itself,
however, rather than development *with* Python, so it's not an appropriate
place for such posts.
I suggest you post this on pytho
Le sam. 16 nov. 2019 à 20:55, Neil Schemenauer
a écrit :
> If you use threadstate often,
> passing it explicitly (which likely uses a CPU register) could be a
> win. If you use it rarely, that CPU register would be better
> utilized for passing function arguments you actually use.
Currently, I
On Fri, 15 Nov 2019 14:21:53 -0800
Nathaniel Smith wrote:
> As you know, I'm skeptical that PEP 554 will produce benefits that are
> worth the effort, but let's assume for the moment that it is, and
> we're all 100% committed to moving all globals into the threadstate.
> Even given that, the motiv
18 matches
Mail list logo
