> 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],
> 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
> 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
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/
___
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
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
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
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
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)
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
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 ).
>
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
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
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.
>
>
> 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
> 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
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
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
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
> 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
20 matches
Mail list logo
