On 16/09/20 4:54 pm, Guido van Rossum wrote:
I'm not entirely sure how this would preserve the hygiene of the macros
though,
Despite the title of the PEP, it doesn't actually propose to enforce
hygiene either, it just gives some suggested guidelines for macro
processors to do it themselves.
--
On Tue, Sep 15, 2020 at 7:31 PM Benjamin Peterson
wrote:
> On Tue, Sep 15, 2020, at 20:10, Greg Ewing wrote:
> > Maybe the PEP should propose an AST of its own, which would initially
> > be a third thing separate from either of the existing ones, with
> > the possibility of adopting it as the ast
On Tue, Sep 15, 2020 at 2:41 PM Pablo Galindo Salgado
wrote:
> * Not using an arena allocator for the nodes can introduce more challenges
> than simplifications. The first is that deleting a deep tree currently is
> just freeing the arena block, while if the nodes were PyObjects it will
> involve
Great idea +1
2020년 9월 16일 (수) 오후 1:13, Guido van Rossum 님이 작성:
> Good idea. I tweeted pretty much what you wrote.
> https://twitter.com/gvanrossum/status/1306082472443084801
>
> On Tue, Sep 15, 2020 at 7:58 PM Steven D'Aprano
> wrote:
>
>> There's still a lot of community angst over the possibi
Good idea. I tweeted pretty much what you wrote.
https://twitter.com/gvanrossum/status/1306082472443084801
On Tue, Sep 15, 2020 at 7:58 PM Steven D'Aprano wrote:
> There's still a lot of community angst over the possibility that
> some hypothetical Python 4 will be like the 2/3 transition. Some
On 14Sep2020 18:17, Terry Reedy wrote:
>On 9/14/2020 5:25 AM, Cameron Simpson wrote:
>>On 14Sep2020 01:16, Ned Deily wrote:
I'll make some PRs. How to submit? Here, or a BPO or something?
>>>
>>>My suggestion would be to open one BPO issue for "adding PEP references to
>>>documentation" and
There's still a lot of community angst over the possibility that
some hypothetical Python 4 will be like the 2/3 transition. Some people
even imagine that the version after 3.9 could be that transition.
I know we're not responsible for the ravings of people on social media,
but do you think we
On Tue, Sep 15, 2020, at 20:10, Greg Ewing wrote:
> On 16/09/20 12:37 pm, Guido van Rossum wrote:
> > IMO if we were to standardize the AST for times immemorial this would
> > have to be a separate PEP.
>
> Perhaps, but a stable AST seems to be a prerequisite for this kind
> of feature. Prefer
On 16/09/20 12:37 pm, Guido van Rossum wrote:
IMO if we were to standardize the AST for times immemorial this would
have to be a separate PEP.
Perhaps, but a stable AST seems to be a prerequisite for this kind
of feature. Preferably one that corresponds as closely as possible
to the language sy
On Tue, Sep 15, 2020 at 5:23 PM Greg Ewing
wrote:
> On 16/09/20 9:34 am, Pablo Galindo Salgado wrote:
> > The first is that deleting a deep tree
> > currently is just freeing the arena block, while if the nodes were
> > PyObjects it will involve recursive destruction. That could potentially
> > s
On 16/09/20 9:34 am, Pablo Galindo Salgado wrote:
The first is that deleting a deep tree
currently is just freeing the arena block, while if the nodes were
PyObjects it will involve recursive destruction. That could potentially
segfault
Not sure why that would be a concern. It's theoretically
Mark,
Thanks you this is an interesting proposal. I can see how many of the "magics"
provided by IPython/Jupyter could also be replaced by some of those macros.
A couple of questions – which I understand could be delegated to further
improvement to macros in a subsequent proposal.
- I'm no
Hi Mark,
In 2016, I wrote PEP 511 "API for code transformers" which proposed a
different implementation but also used "preprocessor" use case in the
rationale:
"""
A preprocessor can be easily implemented with an AST transformer. A
preprocessor has various and different usages.
Some examples:
*
Thanks for the proposal Mark!
I wanted to make some comments regarding converting AST nodes to PyObjects
internally. I see some challenges here:
* Not using an arena allocator for the nodes can introduce more challenges
than simplifications. The first is that deleting a deep tree currently is
jus
September 15, 2020 4:31 PM, "Gregory P. Smith" mailto:g...@krypto.org?to=%22Gregory%20P.%20Smith%22%20)>
wrote:
On Tue, Sep 15, 2020 at 1:27 PM mailto:ed...@211mainstreet.net)> wrote:
September 15, 2020 4:02 PM, "Daniel Butler" mailto:dabutle...@gmail.com?to=%22daniel%20butler%22%20%3cdabutle...@
I had not read it. Thanks for the clarification
On Tue, Sep 15, 2020 at 4:32 PM Gregory P. Smith wrote:
>
>
> On Tue, Sep 15, 2020 at 1:27 PM wrote:
>
>> September 15, 2020 4:02 PM, "Daniel Butler" > >
>> wrote:
>>
>> > Users would be encouraged to try it but
>>
>> > NOT to publish code using i
On Tue, Sep 15, 2020 at 1:27 PM wrote:
> September 15, 2020 4:02 PM, "Daniel Butler" >
> wrote:
>
> > Users would be encouraged to try it but
>
> > NOT to publish code using it.
>
> Thinking out loud, macros could be enabled with a command line flag.
> Advanced users would know how to use it but
September 15, 2020 4:02 PM, "Daniel Butler" mailto:dabutle...@gmail.com?to=%22Daniel%20Butler%22%20)>
wrote:
> Users would be encouraged to try it but
> NOT to publish code using it.
Thinking out loud, macros could be enabled with a command line flag. Advanced
users would know how to use it but
Three-ish questions:
1. What could this do that Macropy does not already do? (yes, I know "run
as top-level script", but that's uninspiring for me).
2. Do you have any evidence Numba developers would actually want this?! (as
claimed in draft FAQ). I know a lot of them, and teach Numba sometimes,
> Users would be encouraged to try it but
>
> > NOT to publish code using it.
>
>
Thinking out loud, macros could be enabled with a command line flag.
Advanced users would know how to use it but others would not. If the macro
flag is not enabled it raises a syntax error. Thoughts?
--
Thank you!
D
On Wed, Sep 16, 2020 at 5:23 AM Mark Shannon wrote:
> In general, I would except macros to be used within libraries, so that
> those libraries gain the power of their custom macros without making
> Python ever larger and more complex.
>
> However, there is no reason why they cannot be made more wi
On Wed, Sep 16, 2020 at 5:31 AM Chris Angelico wrote:
> Users would be encouraged to try it but
> NOT to publish code using it.
Clarification: by "publish" I mean in production, or as libraries that
people will be depending on. It'd be on par with playing around in a
fork of Python with the new f
Hi all,
I'd like to propose a new PEP for hygienic macros.
I'm attempting to reduce the controversy and pain of adding new syntax
to Python,
... by adding new syntax.
That might sound silly, but I hope to persuade that it isn't.
Adding a new feature to the language is always controversial.
23 matches
Mail list logo
