Re: [Python-Dev] ast changes for "debug" f-strings

[Batuhan Taskaya]

> This strictly speaking isn't necessary. I could have added another
Constant node for "x=" and left FormattedValue alone. I didn't for three
reasons: it was expedient; it didn't require a lot of surgery to
f-string parsing, which the extra Constant node would require; and it
allowed the Python/ast_unparse.c code to produce a string that was more
consistent with input string.

Agreed.

> Does anyone care that f'{x=}' would become f'x={x!r}' if I removed
expr_text from the FormattedValue node?

Yes, when i was implementing f-string debugging support to Berker's astor
project
the roundtrip tests i wrote is failing because of it adds an extra `!r` to
end. Then
i realized you added a new field (expr_text) for that.

> I'm not sure how much we care about all of this, but let me know if you
have a strong feeling about it.

I don't think we should complicate this. The current version is very simple
and understandable.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Re: PEP 11: Drop support for AIX releases without dlopen

[Batuhan Taskaya]

As far as I am aware, we already dropped support for AIX 5.3<=.  See 
https://bugs.python.org/issue40680 for details.


On 16.10.2020 23:15, Kevin Adler wrote:

Python has supported using dynload_shlib (using dlopen) on AIX since 
https://github.com/python/cpython/commit/c19c5a62aef7dce0e8147655b0d2f087965fae75
 in 2003. This is also about the time that AIX 4.3 went out of support, which 
is believed to be the AIX release that added support for dlopen. Considering it 
is now 20ish years later and in this time, every supported AIX release has had 
dlopen support, I suspect nobody has used or tested this code path in quite 
some time. I propose removing this support under PEP 11.

For reference, I opened https://bugs.python.org/issue42030 and changes were 
merged in https://github.com/python/cpython/pull/22717. I opened a PR to update 
PEP 11 in https://github.com/python/peps/issues/1653, but was told this needed 
discussion here. Sorry if this didn't quite follow the process correctly, I 
thought I had things in the right order, but I guess not. Also apologies if 
this is a duplicate, but my first message appears to have been lost/eaten 
(possibly a first-time moderation queue?).
___
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/7QVLHW36FBZBEHSEPNVXAKXGUQHP3WX5/
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/FYZOH3K7C5KK4CTSAFO5FEWEZRJADHMG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 637 - Support for indexing with keyword arguments: request for feedback for SC submission

[Batuhan Taskaya]

Lurking around the discussions I started to wonder whether this syntax
actually worths the burden it introduces. As you have commented out
earlier, there are no use cases in the built-in types, perhaps a
research would be great regarding possible use cases of keyword
arguments in and out of the stdlib. Here is an example:
https://www.python.org/dev/peps/pep-0572/#examples-from-the-python-standard-library
that was done for PEP 572, which actually helped me a lot to
understand/comprehend the proposal.  Now looking at PEP 637, even with
the theoretical examples given, it seems like we are introducing a
redundant syntax that has no other value than just complicating the
already complex subscript notation and becoming a bad alternative to
function call syntax.

On Tue, Feb 2, 2021 at 2:40 PM Stefano Borini  wrote:
>
> Hi all,
>
> I would like to request feedback by python-dev on the current
> implementation of PEP 637 - Support for indexing with keyword
> arguments.
>
> https://www.python.org/dev/peps/pep-0637/
>
> The PEP is ready for SC submission and it has a prototype
> implementation ready, available here (note, not reviewed, but
> apparently fully functional)
>
> https://github.com/python/cpython/compare/master...stefanoborini:PEP-637-implementation-attempt-2
>
> (note: not sure if there's a preference for the link to be to the diff
> or to the branch, let me know if you prefer I change the PEP link)
>
> Thank you for your help.
>
>
> --
> Kind regards,
>
> Stefano Borini
> ___
> 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/E3AMOIB3GKYAGN6IVSLEEKVP4VUEC2V3/
> 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/MO57TTSZGEBXAG2RMHEGLRO4Z72Z2GZC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Interaction of PEP 563's Annotations with Symbol Table

[Batuhan Taskaya]

About 4 months ago, I've created bpo-42725 in order to
resolve some of the points below though I decided to
postpone it for various reasons that blocked it completely
until the point of where we have a beta cut in a week or
so. So I'm asking for comments regarding how should we resolve
this behavior.

Even though PEP 563 blocks having all compiler-related activities
for annotations by behaving them strings, this doesn't happen until
the symbol is constructed which results with different problems. For
example you can use yield in annotation, and since PEP 563 will stringify
it you'd expect your function to act accordingly but it currently doesn't.
Also references to the upper scope variables will still be contained as closures
of the current function, and some other oddities that I've found regarding misc
stuff (usage of super() etc).

Here is a quick demo:

def foo():
for number in range(5):
foo: (yield number)
return number

foo() # ==> this will be a generator

We could go with acting these as strings and letting them stay as annotations
but making them no-op on the symbol table (which is the straight forward choice)
or we could restrict usage of those inside of annotations and raise
SyntaxErrors. I've
drafted patches for both of those ideas, though it definitely needs
more work and
there is not much time left so any comments would be appreciated.

P.S: I intend to submit a PR with the most likely option by, at latest, end of
saturday so that we can give reviewers enough time and also catch the
beta freeze
considering this is a clear behavioral change.
___
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/5NQH5GURAYW6XINPBO6VSF45CWLQOHUQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: RFC on Callable Syntax PEP

[Batuhan Taskaya]

First of all, thank you for authoring a really well-written PEP.

tl;dr: I find it very troubling that we are going on a path where need
to increase the language complexity (syntax) only in the cause
'easier' typing. So I am opposed to this change.

Most of the native typing use cases until now (PEP 585 / PEP 604) was
using the existing syntax, with slight adjustments on runtime. And
personally, I really liked them (being able to write `list[int | str]`
is nice), but not as much as I like the simplicity of the language. I
think the new syntax proposal for only a typing use case is really
destructive when we already have a very formal way of creating
callable types. I personally don't think it is verbose (as claimed by the PEP),
since the only thing that we have an extra is the `Callable` name. Aside from
these concerns, a few comments on the actual proposal:

- The syntax itself would probably confuse people, considering in
other languages (like javascript) the arrow functions are a thing that
loosely translates to our lambdas. People might try to write code like
`(x, y) -> x + y`, with the expectation that it would work (since it
is a valid syntax now), but it would immediately throw an error (if
x/y is not defined) and create confusion.

- Callables that return callables look very awkward with a double
arrow. `) -> (int, str) -> R:` (compared to `) -> Callable[[int, str],
R]:`. This was one of the examples that really made me look twice to
understand.

- `async` keyword used to be coupled with `def`/`for`/`with`, but
without any of these, it doesn't feel good to have it as some sort of
prefix to these expressions. I think it would be nice if the PEP can
address how much of the code out there uses `Callable[...,
Awaitable[...]]` syntax, since from what I understand by the current
proposal `async (int, str) -> bool` is the same with `(int, str) ->
Awaitable[bool]`, which is, in theory, a new syntax that we might be
adding for a very restricted use case.

- The parameter part (`(x, y) -> `) seem to be even diverging from an
actual expression (by allowing standalone [double-]starred operations,
and disallowing `(int, ...) ->`), which I think would complicate the
actual parsing process (even though we have an advanced parser in
CPython, that does not mean community maintained projects such as
jedi, parso, black will have one).

- Out of 4 concerns that are listed on the PEP about the current
callable syntax; only 1 is about the actual runtime behaviour, which
even if I did not agree initially, we have other solutions. Like an
open issue on the tracker about making `callable()` generic
https://bugs.python.org/issue42102.

- The other 3 is pretty much the same, claiming the syntax is dense.
Which I partly agree on. We probably could find other solutions (using
tuples to represent the parameter group, etc.), but I do not see those
points as very big deals (at least not as big as adding a very
complicated piece of new syntax).

I would assume some of these were previously discussed during the
typing-sig/python-dev threads, but as someone who recently learned
about this proposal, I feel like this is really overworked for a
problem that is (subjectively, again) small.
___
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/FI4AFU3I25PECARIH2EVKAD5C5RJRE2N/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: RFC on Callable Syntax PEP

[Batuhan Taskaya]

I think I've posted it as a standalone reply (sorry for my bad mailing list 
skills), so linking my thread about potential concerns/reservations: 
https://mail.python.org/archives/list/python-dev@python.org/thread/FI4AFU3I25PECARIH2EVKAD5C5RJRE2N/
___
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/4QFTYRBXNNIIJ7S3ZXDNBDZS63OBHLQT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 679 – Allow parentheses in assert statements

[Batuhan Taskaya]

> Does someone know if linters like pylint or pylakes current warn on 
> "assert(test, msg)" statements?

I believe so, both the python itself (through SyntaxWarnings) and
other linters warn about this.

> Is it possible to run a code search on PyPI top 5000 projects to see
> if such always-true assertion is common or not?

I don't think this is a common thing, so changing the behavior should
not break anything. In my PyPI dataset (4 or 5 thousand packages),
I've only found 4 examples which 2 of them intentional (for test
purposes on linters/parsers etc). The other 2 seem like problematic
use cases, which should be fixed:

pylint

/home/isidentical/projects/data/pypi/clean/pylint/tests/functional/a/assert_on_tuple.py:4:0
keras-mxnet

/home/isidentical/projects/data/pypi/clean/keras-mxnet/examples/deep_dream.py:88:4
parso

/home/isidentical/projects/data/pypi/clean/parso/test/normalizer_issue_files/E12_not_first.py:54:4

/home/isidentical/projects/data/pypi/clean/parso/test/normalizer_issue_files/E101.py:38:1
django-modeltranslation

/home/isidentical/projects/data/pypi/clean/django-modeltranslation/modeltranslation/tests/urls.py:6:4

On Mon, Jan 10, 2022 at 2:35 PM Victor Stinner  wrote:
>
> Does someone know if linters like pylint or pylakes current warn on
> "assert(test, msg)" statements?
>
> If a project use such assertions which are always true, they can start
> failing wit the PEP 679, right? Hopefully, the fix is easy: removing
> the parenthesis give the same behavior on old and new Python versions.
>
> Is it possible to run a code search on PyPI top 5000 projects to see
> if such always-true assertion is common or not?
>
> Victor
>
> On Mon, Jan 10, 2022 at 1:22 AM Pablo Galindo Salgado
>  wrote:
> >
> > Hi everyone,
> >
> > I would like to start a discussion about a small PEP proposal to allow 
> > parentheses in
> > assert statements to fix a common gotcha with assert statements.
> >
> > Link to the PEP: https://www.python.org/dev/peps/pep-0679/
> >
> > Please, redirect all discussions to:
> >
> > https://discuss.python.org/t/pep-679-allow-parentheses-in-assert-statements/13003
> >
> > as I will not be monitoring answers to this thread.
> >
> > Thanks, everyone for your time!
> >
> > Regards from cloudy London,
> > Pablo Galindo Salgado
> > ___
> > 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/I7MKCD3GHJXCERFCZ2FD3X7IPAX6ASVK/
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> --
> 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/LFQGI43BH3SWKHRBPO7T3DC6SEU5HMQ3/
> 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/2NJJM3ZNJOZJXFS67LPM2HM4MKKJJX3C/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 679 – Allow parentheses in assert statements

[Batuhan Taskaya]

> While it can indeed, make otherwise stable projects with "nop"s assert
sudden failing, that should be a trivial fix for any non-unmaintained
project.

Agreed. This would be like a bug fix. I don't think anyone is depending on
the current behavior (beside explicit tests in linters, which is only a
handful (2-3)). +1 to the PEP as well, which I find this restriction
unnecessary.

On Mon, Jan 10, 2022, 4:20 PM Joao S. O. Bueno 
wrote:

>
>
> On Mon, 10 Jan 2022 at 08:39, Victor Stinner  wrote:
>
>> Does someone know if linters like pylint or pylakes current warn on
>> "assert(test, msg)" statements?
>>
>> If a project use such assertions which are always true, they can start
>> failing wit the PEP 679, right?
>
>
> OTOH, any assertion which start failing in this way, is a statement which
> _should_ have been failing from the start, and was being ignored up to
> this change.
>
> While it can indeed, make otherwise stable projects with "nop"s assert
> sudden failing, that should be a trivial fix for any non-unmaintained
> project.
>
> +1 to the change
>
>
>
>
>> Hopefully, the fix is easy: removing
>> the parenthesis give the same behavior on old and new Python versions.
>>
>> (it will behave the same just if the first expression is actually truish)
>
>
>> Is it possible to run a code search on PyPI top 5000 projects to see
>> if such always-true assertion is common or not?
>>
>> Victor
>>
>> On Mon, Jan 10, 2022 at 1:22 AM Pablo Galindo Salgado
>>  wrote:
>> >
>> > Hi everyone,
>> >
>> > I would like to start a discussion about a small PEP proposal to allow
>> parentheses in
>> > assert statements to fix a common gotcha with assert statements.
>> >
>> > Link to the PEP: https://www.python.org/dev/peps/pep-0679/
>> >
>> > Please, redirect all discussions to:
>> >
>> >
>> https://discuss.python.org/t/pep-679-allow-parentheses-in-assert-statements/13003
>> >
>> > as I will not be monitoring answers to this thread.
>> >
>> > Thanks, everyone for your time!
>> >
>> > Regards from cloudy London,
>> > Pablo Galindo Salgado
>> > ___
>> > 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/I7MKCD3GHJXCERFCZ2FD3X7IPAX6ASVK/
>> > Code of Conduct: http://python.org/psf/codeofconduct/
>>
>>
>>
>> --
>> 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/LFQGI43BH3SWKHRBPO7T3DC6SEU5HMQ3/
>> 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/SFBWV5SAFYRFEASNJZJIRY4VUPIEOX24/
> 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/FOZDTZFT4EGS3UUDF6GGVKA65DF6COH7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 677 (Callable Type Syntax): Final Call for Comments

[Batuhan Taskaya]

> Has anyone considered adding a new special method like `__arrow__` or 
> something, that would be user-definable, but also defined for tuples and 
> types as returning a Callable? For example `int -> str` could mean 
> Callable[[int], str], and (int, str) -> bool could mean Callable[[int, str], 
> bool]. I would find that sort of semantics more agreeable since Python 
> already has operators that dispatch to dunder methods, and anyone who knows 
> how that bit of Python works would automatically mostly know how the new 
> operator works.

I would personally argue that this would make the situation worse,
considering the complexity would be increased with no possible use
case on the route beside type annotations.

On Thu, Jan 13, 2022 at 7:30 AM Dennis Sweeney
 wrote:
>
> Like others expressed, I don't like the idea of the typing and non-typing 
> parts of Python separating.
>
> Has anyone considered adding a new special method like `__arrow__` or 
> something, that would be user-definable, but also defined for tuples and 
> types as returning a Callable? For example `int -> str` could mean 
> Callable[[int], str], and (int, str) -> bool could mean Callable[[int, str], 
> bool]. I would find that sort of semantics more agreeable since Python 
> already has operators that dispatch to dunder methods, and anyone who knows 
> how that bit of Python works would automatically mostly know how the new 
> operator works.
>
> If I understand right, this is a sort of combination of two things for which 
> there is more precedent: first, adding a new operator based on the needs of a 
> subset of users (the @ operator and __matmul__), and second, adding new 
> operators to existing objects for the sake of typing (like the list[int] 
> syntax in which type.__getitem__ was implemented to dispatch to 
> the_type.__class_getitem__).
>
> If people don't want to add a new operator and dunder, I assume using the 
> right shift operator like `(int, bool) >> str` would be too cheesy?
> ___
> 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/GTYLK4QA6DHQDZH7NLYLELYCFUKOTNDT/
> 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/GDLOI64UZRCSG7GGSNM67MSKFWQ4LI5B/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] PEP 601: discussion-to discuss.python.org

[Batuhan Taskaya]

Please use 
https://discuss.python.org/t/pep-601-forbid-return-break-continue-breaking-out-of-finally/2239
for feedback and discussion.
___
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/IBMYFSKDMOQTPINAU4Z7HF667ARJJ7CG/

[Python-Dev] Re: Exposing Tools/parser/unparse.py in the stdlib?

[Batuhan Taskaya]

This is a really great idea, after pretty ast.dump it will be great
addition for people who works with AST code transformations.

I think with the new end_lineno and end_col_offset information output can
be little bit close the original.

I want to volunteer the work if there is an open opportunity after
consensus about adding this.

On Tue, Nov 19, 2019, 3:45 AM Pablo Galindo Salgado 
wrote:

> 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.
> * The public interface will have a very low surface API, keeping
> maintaining it (the public interface) a very small burden IMHO.
>
> We could add the public interface to the ast.py module or a new one if
> people feel strongly about it.
>
> Does anyone feel strongly against this or have any objection that I am not
> contemplating?
>
> Regards from rainy London,
> Pablo Galindo Salgado
> ___
> 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/JAQDBMC23HW2PQ27HQNJ7G244T423IDD/
> 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/QG5GKAJ6LXT5A64OPRIUGVYYJQGFAQ5R/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Exposing Tools/parser/unparse.py in the stdlib?

[Batuhan Taskaya]

Yes, there is a to_source function which allows AST to source conversation.

On Wed, Nov 20, 2019, 9:02 AM Guido van Rossum  wrote:

> On Tue, Nov 19, 2019 at 10:24 PM Nathaniel Smith  wrote:
>
>> On Mon, Nov 18, 2019 at 4:41 PM Pablo Galindo Salgado
>>  wrote:
>> >
>> > 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.
>> > * The public interface will have a very low surface API, keeping
>> maintaining it (the public interface) a very small burden IMHO.
>> >
>> > We could add the public interface to the ast.py module or a new one if
>> people feel strongly about it.
>>
>> How does it compare to Berker's popular and well-maintained PyPI
>> package for this? https://github.com/berkerpeksag/astor
>>
>
> Does that even have unparse() functionality? From the README it seems to
> focus on a nicer ast.dump(), which is quite different (in behavior and how
> it's used) from unparse().
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
> ___
> 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/3Z34GG2B2REAR7JHIBZJCKDGL7656NBB/
> 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/EA5ZN4IONDV5AIXSAGT4YRINY64AYIW6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Should we require all deprecations to have a removal version that we follow through on?

[Batuhan Taskaya]

> What do people think of the idea of requiring all deprecations specifying
a version that the feature will be removed in (which under our annual
release cadence would be at least the third release from the start of the
deprecation, hence the deprecation being public for 2 years)? And that we
also follow through with that removal?

IMHO that really helps to reduce amount of discussions for choosing when to
remove. Like should we remove it in 3.9 or we should wait to 3.10 etc. Also
the consumers of that depracted parts will know the exact version they
can't support if they'll continue using it. So big +1 from me

On Wed, Nov 27, 2019, 9:43 PM Brett Cannon  wrote:

> What do people think of the idea of requiring all deprecations specifying
> a version that the feature will be removed in (which under our annual
> release cadence would be at least the third release from the start of the
> deprecation, hence the deprecation being public for 2 years)? And that we
> also follow through with that removal?
>
> Now I'm not suggesting it **must** be in three feature releases. A
> deprecation could be set to Python 4 if people truly feel keeping the code
> is as easy it gets in terms of maintenance and there's enough usage to
> warrant such a potential indefinite deprecation/maintenance while keeping
> the code and docs alive (basically "there are better ways to do this, but
> this works fine, too, if you were already using it"). But what I am trying
> to avoid is the semi-regular discussion we seem to have of what is or is
> not reasonable to deprecate and leave versus deprecate and eventually
> remove because we didn't specify what the eventual plan was for a
> deprecation. Also feel like it would help users to know specifically what
> the plan is with a deprecation rather than wondering if something will get
> removed in the next feature release or not because we left off a specific
> removal version.
>
> If people are amenable to this idea I will update PEP 387 (which I plan to
> start a discussion about post-SC election) and I would also plan to add a
> warnings._deprecate() which I roughly outlined once at
> https://discuss.python.org/t/pendingdeprecationwarning-is-really-useful/1038/18
> .
> ___
> 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/BRA7G4UIGGW2X7YY55KQZBOGJEYNUV6O/
> 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/W24J7QWYLEBS7WB67IGTQV6QLD32TVRY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Batuhan Taskaya]

> Instead, we can do:
>
> * Don't recommend u-prefix except in Python 2&3 code.
> * Provide a tool to remove the u-prefix.

Great idea, +1 from me.

On Wed, Dec 4, 2019, 8:39 AM Inada Naoki  wrote:

> On Wed, Dec 4, 2019 at 11:49 AM Ned Batchelder 
> wrote:
> >
> > On 12/3/19 8:13 PM, Inada Naoki wrote:
> > > I think it is too early to determine when to remove it.
> > > Even only talking about it causes blaming war.
> >
> > Has anyone yet given a reason to remove it?
>
> Note that "never" is included in ”when".
> I didn't promoting removing it.  I just said let's stop discussion about
> it.
>
>
> > It will change working code
> > into broken code.  Why do that?
>
> Of course, everyone in this thread understands it.
> No one proposes remove it now.
>
> On the other hand, we remove some parts from Python language
> and the stdlib regularly to keep Python clean.
> All removal will break some code.  That's why we have a deprecation period.
>
> Currently, u-prefix is very widely used.  It shouldn't be removed anytime
> soon.
> And I agree that we shouldn't raise DeprecationWarning for now.
>
> But how about 5, 10, and 20 years later?  No one knows it.
> Let's stop discussing it.  It can not be productive.
>
> Instead, we can do:
>
> * Don't recommend u-prefix except in Python 2&3 code.
> * Provide a tool to remove the u-prefix.
>
> Regards,
> ___
> 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/EVKCCO5KMOGEEFMSSY2PZRVGT2LDOB5K/
> 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/5IPCQPWHUDEVAHDBZTHUMXCY4ZGPJSXS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 585: Type Hinting Generics In Standard Collections

[Batuhan Taskaya]

This issue might be useful about it: https://bugs.python.org/issue39019

On Sun, Feb 23, 2020 at 2:12 PM Ethan Smith  wrote:
>
> While working on the implementation with Guido I made a list of things that 
> inherit from typing.Generic in typeshed that haven't been listed/implemented 
> yet.
>
> https://github.com/gvanrossum/cpython/pull/1#issuecomment-582781121
>
>
>
> On Sat, Feb 22, 2020, 3:50 PM Nick Coghlan  wrote:
>>
>> This looks like a nice usability improvement to me.
>>
>> My only suggestion would be that types.MappingProxyType be included on the 
>> list of types to be updated.
>>
>> 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/EYU3VDK7T4OVT7MXM5OWOPFA4YKWXVDE/
>> 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/Z47AGWUR5ZVQQ7GEEFQYPE5HBCUMEL44/
> 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/SMSLIJOYCEFN6TEWHFX7ELO5FWKJEGYK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 614 accepted

[Batuhan Taskaya]

Congratulations Brandt!

On Tue, Mar 3, 2020, 9:19 PM Barry Warsaw  wrote:

> By unanimous consent, the Python Steering Council unanimously accepts PEP
> 614 —
> Relaxing Grammar Restrictions On Decorators.
>
> Congratulations to PEP author Brandt and PEP sponsor Guido, and thanks to
> everyone who’s worked on this PEP and its implementation.
>
> Cheers,
> -Barry
>
> ___
> 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/VSR66MOTCDCY7ZFH4IG7QVFI2JXQQZQ5/
> 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/H3XVVMNNXJUHAVB5BVL5NGHUWQKGNQ6W/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 617: New PEG parser for CPython

[Batuhan Taskaya]

Wonderful news! I'm really excited to see what is coming alongside
this flexible parser.

On Thu, Apr 2, 2020 at 9:16 PM Guido van Rossum  wrote:
>
> Since last fall's core sprint in London, Pablo Galindo Salgado, Lysandros 
> Nikolaou and myself have been working on a new parser for CPython. We are now 
> far enough along that we present a PEP we've written:
>
> https://www.python.org/dev/peps/pep-0617/
>
> Hopefully the PEP speaks for itself. We are hoping for a speedy resolution so 
> we can land the code we've written before 3.9 beta 1.
>
> If people insist I can post a copy of the entire PEP here on the list, but 
> since a lot of it is just background information on the old LL(1) and the new 
> PEG parsing algorithms, I figure I'd spare everyone the need of reading 
> through that. Below is a copy of the most relevant section from the PEP. I'd 
> also like to point out the section on performance (which you can find through 
> the above link) -- basically performance is on a par with that of the old 
> parser.
>
> ==
> Migration plan
> ==
>
> This section describes the migration plan when porting to the new PEG-based 
> parser
> if this PEP is accepted. The migration will be executed in a series of steps 
> that allow
> initially to fallback to the previous parser if needed:
>
> 1.  Before Python 3.9 beta 1, include the new PEG-based parser machinery in 
> CPython
> with a command-line flag and environment variable that allows switching 
> between
> the new and the old parsers together with explicit APIs that allow 
> invoking the
> new and the old parsers independently. At this step, all Python APIs like 
> ``ast.parse``
> and ``compile`` will use the parser set by the flags or the environment 
> variable and
> the default parser will be the current parser.
>
> 2.  After Python 3.9 Beta 1 the default parser will be the new parser.
>
> 3.  Between Python 3.9 and Python 3.10, the old parser and related code (like 
> the
> "parser" module) will be kept until a new Python release happens (Python 
> 3.10). In
> the meanwhile and until the old parser is removed, **no new Python Grammar
> addition will be added that requires the peg parser**. This means that 
> the grammar
> will be kept LL(1) until the old parser is removed.
>
> 4.  In Python 3.10, remove the old parser, the command-line flag, the 
> environment
> variable and the "parser" module and related code.
>
> --
> --Guido van Rossum (python.org/~guido)
> Pronouns: he/him (why is my pronoun here?)
> ___
> 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/HOZ2RI3FXUEMAT4XAX4UHFN4PKG5J5GR/
> 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/PIR74ZYSBM46TW3OZYGPFEBV4I4BZ5MN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Accepting PEP 617: New PEG parser for CPython

[Batuhan Taskaya]

Congratulations!

On Mon, Apr 20, 2020, 9:30 PM Brett Cannon  wrote:

> The steering council is happy to announce that  we have accepted PEP 617!
> Thanks to the PEP authors for all their hard work (which includes sending a
> PR to update the acceptance of the PEP 😉).
> ___
> 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/FTXPZTEHX25QXEMY2QJP3M6KZVXEQNHK/
> 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/E4CQN7ZAA3D6LSS56WDYDFYFRH2F4WRH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Hygenic macros PEP.

[Batuhan Taskaya]

On 16.09.2020 16:33, Benjamin Peterson wrote:

Is there any proposal that would let you add new tokens?


Not a proposal, but drafted a project a while back. By patching 
tokenizer and the parser at runtime (generated from lib2to3.pgen), 
allowed to introduce different tokens / rules, and worked like a 
transpiler (so that you can take the source code with creating a fake 
encoding, giving it as a raw source stream to the new parser with 
updated rules and then return the result as the decoded source);


https://github.com/isidentical/freesyntax/blob/master/example2.py
___
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/SBQUKFSJDXOJBPXM42RHRNDJAB3J4I2J/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Remove module's __version__ attributes in the stdlib

[Batuhan Taskaya]

I've indexed a vast majority of the files from top 4K pypi packages to 
this system, and here are the results about __version__ usage on 
argparse, cgi, csv, decimal, imaplib, ipaddress, optparse, pickle, 
platform, re, smtpd, socketserver, tabnanny (result of an quick grep)



rawdata/clean/argparse/setup.py

|argparse.__version__|

rawdata/pypi/junitparser-1.4.1/bin/junitparser

|argparse.__version__|

rawdata/pypi/interpret_community-0.15.1/interpret_community/mlflow/mlflow.py 



|pickle.__version__|

The pickle in the last example looks like a result of import cloudpickle 
as pickle, so we are safe to eliminate that.


Here is the query if you want to try by yourself on different 
parameters: 
https://search.tree.science/?query=Attribute%28Name%28%27argparse%27%7C%27cgi%27%7C%27csv%27%7C%27decimal%27%7C%27imaplib%27%7C%27ipaddress%27%7C%27optparse%27%7C%27platform%27%7C%27pickle%27%7C%27re%27%7C%27smtpd%27%7C%27socketserver%27%7C%27tabnanny%27%29%2C+%22__version__%22%29 


On 14.10.2020 21:23, Neil Schemenauer wrote:

On 2020-10-14, Serhiy Storchaka wrote:

I propose to remove __version__ in all stdlib modules. Are there any
exceptions?

I agree that these kinds of meta attributes are not useful and it
would be nice to clean them up.  However, IMHO, maybe the cleanup is
not worth breaking Python programs.  We could remove them from the
documentation, add comments (or deprecation warnings) telling people
not to use them.

I think it would be okay to remove them if we could show that the
top N PyPI packages don't use these attributes or at least very few
of them do.  As someone who regularly tests alpha releases, I've
found it quite painful to do since nearly every release is breaking
3rd party packages that my code depends on.  I feel we should try
hard to avoid breaking things unless there is a strong reason and
there is no easy way to provide backwards compatibility.
___
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/MI2SLQCZIKBRFX7HCUB7G4B64MTZ6XVC/
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/MSQTTUZOW6KSECSZE5XH65LANGII2P5F/
Code of Conduct: http://python.org/psf/codeofconduct/