[Python-Dev] Re: PEP 638: Syntactic macros

[Jelle Zijlstra]

El vie, 3 feb 2023 a las 8:01, Stéfane Fermigier ()
escribió:

> "
>
>
> On Fri, Feb 3, 2023 at 12:28 PM Stephen J. Turnbull <
> stephenjturnb...@gmail.com> wrote:
>
>> Stéfane Fermigier writes:
>>
>>  > NB: on a very basic level, I remember trying, a few years ago, to use
>> the
>>  > Unicode "empty set" symbol as a synonym for set(), and it didn't end
>> well,
>>  > for several reasons, including the fact that Python didn't like it as a
>>  > variable name.
>>
>> I know about the issue that '∅' is not valid in identifiers, but I'm
>> curious about these other "several reasons".
>>
>
> IIRC (this was a few years back):  '∅' (aka EMPTY SET) was not accepted by
> Python, so I used instead ''Ø" (aka "LATIN CAPITAL LETTER O WITH STROKE").
>
> Python was OK with it, but some of the tools I use (one of flake8, isort,
> black... or maybe one of my IDE) barfed on it.
>

Black is fine with it; we've had the empty set symbol in our own source
code since the beginning (
https://github.com/psf/black/blob/b0d1fba7ac3be53c71fb0d3211d911e629f8aecb/src/black/linegen.py#L455
now). I believe we've had someone ask that we remove it because it was
breaking some tool that was processing the Black source code, but Łukasz
wasn't having it.


>
>   S.
>
> --
> Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier
> - http://linkedin.com/in/sfermigier
> Founder & CEO, Abilian - Enterprise Social Software -
> http://www.abilian.com/
> Co-Founder & Co-Chairman, National Council for Free & Open Source Software
> (CNLL) - http://cnll.fr/
> Co-Founder & Chairman, Association Professionnelle Européenne du Logiciel
> Libre (APELL) - https://www.apell.info/
> Co-Founder & Spokesperson, European Cloud Industrial Alliance (EUCLIDIA) -
> https://www.euclidia.eu/
>
> "I wish you were as accurate, & as much to be relied on, as I am myself"
> - Lady Ada Lovelace
> ___
> 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/H2UALG4YAA6IBMZQMWEL2QIOPDPK4RTG/
> 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/2VWIJNEP7WBKXJN5XC6LG375THKBUGUL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [CVE-2022-37454] SHA3 vulnerability and upcoming Python patches for 3.7 - 3.10

[Jelle Zijlstra]

El lun, 7 nov 2022 a las 12:28, Gregory P. Smith ()
escribió:

>
> You can see the planned schedule of those on
> https://peps.python.org/pep-0619/ and related similar peps for older
> python versions (i never remember pep numbers, i just google for "python
> 3.8 release schedule" to get to such a PEP myself).
>
> You can now also use https://peps.python.org/topic/release/ to get all
the release schedule PEPs.
___
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/FX7YUF4DTYJ77ZPYGQ6J4ACEFSTYCDY2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Presenting PEP 695: Type Parameter Syntax

[Jelle Zijlstra]

El mar, 12 jul 2022 a las 6:15, Petr Viktorin ()
escribió:

> On 12. 07. 22 6:30, Guido van Rossum wrote:
> > After several rounds of debate on typing-sig, I'd like to request
> > feedback on PEP 695: https://peps.python.org/pep-0695/
> > 
> >
> > I am sponsoring this PEP, which was written by Eric Traut. The PEP
> > attempts to solve the problem that defining generic classes, functions
> > and type aliases currently is lacking dedicated syntax, instead using
> > the cumbersome `T = TypeVar("T", ...)` notation to create global
> > variables that serve as type variables.
> >
> > As a personal historical note, I should mention that over 22 years ago I
> > already pondered type parameters. In an old document that I saved I
> > found the following code snippet:
> > ```
> > def f (a: T) -> T: ...
> > ```
> > which is eerily close to the proposal in this PEP, except that the PEP
> > uses square brackets:
> > ```
> > def f[T](a: T) -> T: ...
> > ```
> > It's been a long and circuitous road!
> >
> > I am not quoting the entire PEP here, please follow the link:
> > https://peps.python.org/pep-0695/ 
> >
>
> A beautifully written PEP, thank you!
> An extra thank you for clearly specifying compile-/run-time vs. type
> checker behavior!
>
>
> In “Type Parameter Declarations” it would be nice to better specify why
> this example is an error:
> ```
> class ClassA[__T, _ClassA__S]:
>  __T = 0  # OK
>  __S = 0  # Syntax Error (because mangled name is _ClassA__S)
> ```
> It's specified later in the Compiler changes section (“An active type
> variable symbol cannot be used for other purposes”), but it would be
> nice to mention it up here too – perhaps replace the specific “Type
> parameters for a generic function cannot overlap the name of a function
> parameter.”
>
>
> I'm not a fan of a third overload of `type`, after the “get type of”
> function and “default metatype” class.
> Would `typevar` not work?
>

That piece of syntax is for type *aliases*, not type *variables*, which are
a different concept. Using "typevar" here would be quite confusing. We
could use something like "alias" or "typealias", but I think "type" is the
most intuitive term, and it matches other languages like TypeScript.


> (The addition of a soft keyword itself is a heavy change, though I'll
> let grammar experts weigh in on that.)
>
> I wonder if we should give some thought to other cases where a name is
> repeated – for example, a hypothetical:
>  namedtuple Point = ("x", "y")
> replacing:
>  Point = namedtuple("Point", ("x", "y"))
> Is the proposed `type` potentially setting a precedent? A good one?
>
>
> `TypeVar` taking `covariant`, `contravariant` and `autovariance` looks
> inconsistent to an outsider. Why is it not `autovariant`?
>
>
> The Rejected ideas mention “various syntactic options for specifying
> type parameters that preceded def and class statements” rejected because
> scoping is less clear and doesn't work well with decorators. I wonder if
> decorator-like syntax itself was considered, e.g. something like:
> ```
> @with type S
> @with type T
> @dec(Foo[S])
> class ClassA: ...
> ```
>
We did consider variations of that. Pure decorator syntax (like your "@dec"
line) wouldn't allow us to get the scoping right, since decorators can't
define new names. (Unless you use a walrus operator, but that wouldn't meet
the goal of providing cleaner syntax.)

We also considered some ideas similar to your "@with type". It can work,
but it feels more verbose than the current proposal, and it's not in line
with what most other languages do.


>
>
> And finally, I need to ask...
> The reference implementation doesn't include documentation. Is there any
> plan to document this feature outside this enhancement proposal?
>
> If not, what needs to happen to get this documented?
>

I'm sure we'll provide detailed documentation if and when the PEP is
accepted; full documentation seems a bit much to ask for in an early
prototype.


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

[Python-Dev] Re: Python grammar test cases

[Jelle Zijlstra]

El mar, 10 may 2022 a las 9:06, Venkat Ramakrishnan (<
venkat.archit...@gmail.com>) escribió:

> I am looking at:
> https://docs.python.org/3/reference/grammar.html
>
> in which the following definition is found:
>
> lambda_slash_no_default:
> | lambda_param_no_default+ '/' ','
> | lambda_param_no_default+ '/' &':'
>
> Can someone tell me how '/' is being used here in the syntax?
>

It just means the literal / character. It's the marker for positional-only
parameters from PEP 570.


>
> Thanks,
> Venkat.
> ___
> 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/WNQVENTVABM5VIVUMEPR4WTOV7GMHFXS/
> 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/ZBE2YFAOB3D6TY5VL5IEP6QGBE5P65S7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [Typing-sig] Almost accepting PEP 681 – Data Class Transforms

[Jelle Zijlstra]

El sáb, 23 abr 2022 a las 4:26, Petr Viktorin ()
escribió:

> Hello,
> As an initial implementation that will be improved in the future, the
> specification in PEP 681 is fine. Feel free to add the decorator to
> Python 3.11 at your convenience.
>

Thanks Petr, that's great to hear!

I opened a PR at https://github.com/python/cpython/pull/91861 so we can get
the new decorator in before the feature freeze.


>
> However, the PEP includes several worrying recommendations like:
>
> - we recommend that the maintainers of attrs move away from the legacy
> semantics and adopt auto_attribs behaviors by default.
> - We chose not to support this feature and recommend that attrs users
> avoid converters.
> - Attrs users should use the dataclass-standard eq and order parameter
> names instead.
>
> These are probably meant as recommendations from typing-sig, but an
> accepted PEP represents consensus of the entire Python community. A
> typing PEP is not an appropriate place to make recommendations like
> this, especially without reaching out to the maintainer of attrs.
> As far as I know,the attrs and pydantic libraries are using the
> reference implementation, but their authors weren't consulted on the PEP
> itself.
>
> Could you either change the wording (e.g. say that the unsupported
> features need bespoke type-checker functionality for proper type
> checking), or work with attrs to make the same recommendations in its
> documentation?
>

Agree that these recommendations sound overly normative. I think we should
remove the recommendations and simply spell out the features that won't
work with dataclass_transform(). It's up to users' own judgment what they
do with that information. Erik, could you propose a change to the PEP text?


>
>
> Happy typing,
> — Petr, on behalf of the Steering Council
> ___
> Typing-sig mailing list -- typing-...@python.org
> To unsubscribe send an email to typing-sig-le...@python.org
> https://mail.python.org/mailman3/lists/typing-sig.python.org/
> Member address: jelle.zijls...@gmail.com
>
___
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/QPT3SJBXKSUVQ4DEFSZVVQBTBMG2XKML/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

[Jelle Zijlstra]

I don't think this proposal is a good solution for the problems of static
typing users.

El vie, 22 abr 2022 a las 18:16, Larry Hastings ()
escribió:

> But the explosion of static type analysis in Python, particularly with
> the `typing` module and the `mypy` tool, has made circular definition-time
> dependencies between classes commonplace--and much harder to solve.  Here's
> one simple example:
>
> ```Python
>  class A:
>  value: B
>
>  class B:
>  value: A
> ```
>
> So to reiterate, your proposal would be to write this as:

forward class B:
pass

class A:
value: B

continue class B:
value: A

While the current workaround is:

class A:
value: "B"

class B:
 value: "A"

I don't think I would write the "forward class" version if I had the
choice. It's clunkier and requires more refactoring if I change my mind
about whether the `value` attribute should exist.

I'd prefer if we found some elegant way to get the natural way to write
this code to work, which is the way you wrote it in your post (with no
explicit declarations or stringifications). Carl Meyer's idea at
https://github.com/larryhastings/co_annotations/issues/2#issuecomment-1092432875
is a very promising approach that should allow us to do that.

I also agree with Mehdi2277's concern that this feature would be difficult
for static type checkers to fully implement, because class declaration and
implementation may be widely separated. To be sure, static checkers can put
in additional restrictions, like requiring declaration and implementation
to be in the same module, but it would be unfortunate if a feature designed
to help users of static typing actually makes it harder to adopt it.

-

That said, one nice thing about the proposal is that it can help with
forward references outside of annotations, a problem which neither PEP 563
nor 649 currently solves. Those include type aliases (MyAlias = Sequence["A
| B"]) and TypeVar bounds (Typevar("AT", bound="A | B")). However, it
doesn't solve the problem for base classes. For example, str is
conceptually defined as `class str(Sequence["str"]):`. A forward reference
can't make `str` defined when the bases are evaluated, because bases are
resolved at the `forward class` stage.
___
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/F7L4SU3QIQLPOYHJF5RNJLROF4VMJTMK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proposal to deprecate mailcap

[Jelle Zijlstra]

El jue, 14 abr 2022 a las 12:21, Damian Shaw ()
escribió:

> > I searched grep.app and found no significant usage.
>
> Maybe someone wants to inform mitmproxy?
>
> It's a very popular tool and it comes up using that tool when searching
> for "import mailcap" using grep.app:
> https://grep.app/search?q=import%20mailcap
>
> https://github.com/mitmproxy/mitmproxy/blob/main/mitmproxy/tools/console/master.py#L2
>

Thanks for catching that! I missed it because I mistakenly searched for
'"import mailcap"' in quotes. It looks like mitmproxy isn't vulnerable to
the security issue because it only passes a filename from mkstemp() to
mailcap, and hopefully mkstemp filenames don't have shell metacharacters in
them. However, if we deprecate mailcap mitmproxy will have to change their
code.

El jue, 14 abr 2022 a las 13:33, Guido van Rossum ()
escribió:

> Probably because it’s not a top level module — it’s inside the email
> package.
>
It's in fact a top-level module.
___
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/25FNDJBERE5PLBP3VX3JQ7ER2LNE2K2O/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proposal to deprecate mailcap

[Jelle Zijlstra]

El jue, 14 abr 2022 a las 11:47, Brett Cannon () escribió:

> A CVE has been opened against mailcap (see
> https://github.com/python/cpython/issues/68966 for details). I'm not
> aware of anyone trying to maintain the module and Victor did a search
> online and didn't find any use of the module in the top 5000 projects on
> PyPI (see the issue). The module is also under 300 lines of Python code
> that only  (https://github.com/python/cpython/blob/main/Lib/mailcap.py),
> so vendoring wouldn't be burdensome.
>
> As such, I'm proposing we deprecate mailcap in 3.11 and remove it in 3.13.
> Any explicit objections?
>

Agree on deprecating. I searched grep.app and found no significant usage.

Do you know why this module wasn't included in PEP 594? Should we do
another audit of old modules to deprecate them before they cause problems?


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

[Python-Dev] Re: Need gh-13143 (bpo-34975: Add start_tls() method to streams API) to be merged

[Jelle Zijlstra]

El lun, 11 abr 2022 a las 9:10, Oleg Iarygin ()
escribió:

> Hi everyone,
>
> Can PR gh-13143 be reopened and reviewed/merged when possible? It was
> closed in favor of the new asyncio streams API (gh-13251). Later, the API
> was cleanly removed (gh-16482) so the proposed PR became relevant again.
>

I can't reopen the PR; I assume the branch was deleted. It's going to be
easier to just open a new PR.


>
> The added method allows to turn encryption on on demand (and off, as the
> author expressed his readiness). It's required for a CPython test suit, to
> port `test.test_ftplib.DummyFTPServer` from asyncore/asynchat before their
> removal according to PEP 594 (Removing dead batteries from the standard
> library).
>
> Thank you in advance.
> ___
> 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/RNQKBKAU3DPLGQLX3WZB5IRPEUKU6XKK/
> 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/SMZEYTOYSJOFRKQMSVZPJJOGLMAKIACA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Changing unittest verbose output.

[Jelle Zijlstra]

El sáb, 26 mar 2022 a las 17:51, Itay Yeshaya ()
escribió:

>
> Any thoughts on the mentioned solutions?
>

This is a bit more out there, but can anyone explain why we show the
docstring at all? As far as I can tell it causes a bunch of confusion and
helps little. If there's a failing test, I want the test name so I can
quickly find it in the code; I don't want the docstring which may not even
be unique.


>
> https://bugs.python.org/issue47133
>
___
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/YNMCBR6CG3Q4OHW2ZKH2K3AX5UBLCKRI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: It's now time to deprecate the stdlib urllib module

[Jelle Zijlstra]

El dom, 6 feb 2022 a las 9:12, Paul Moore () escribió:

> On Sun, 6 Feb 2022 at 16:51, Christian Heimes 
> wrote:
>
> > The urllib package -- and to some degree also the http package -- are
> > constant source of security bugs. The code is old and the parsers for
> > HTTP and URLs don't handle edge cases well. Python core lacks a true
> > maintainer of the code. To be honest, we have to admit defeat and be up
> > front that urllib is not up to the task for this decade. It was designed
> > written during a more friendly, less scary time on the internet.
> >
> > If I had the power and time, then I would replace urllib with a simpler,
> > reduced HTTP client that uses platform's HTTP library under the hood
> > (WinHTTP on Windows, NSURLSession (?) on macOS, Web API for Emscripten,
> > maybe curl on Linux/BSD). For non-trivial HTTP requests, httpx or
> > aiohttp are much better suited than urllib.
> >
> > The second best option is to reduce the feature set of urllib to core
> > HTTP (no ftp, proxy, HTTP auth) and a partial rewrite with stricter,
> > more standard conform parsers for urls, query strings, and RFC 2822
> > instead of RFC 822 for headers.
>
> I'd likely be fine with either of these two options. I'm not worried
> about supporting "advanced" uses. But having no way of getting a file
> from the internet without relying on 3rd party packages seems like a
> huge gap in functionality for a modern language. And having to use a
> 3rd party library to parse URLs will simply push more people to use
> home-grown regexes rather than something safe and correct. Remember
> that a lot of Python users are not professional software developers,
> but scientists, data analysts, and occasional users, for whom the
> existence of something in the stdlib is the *only* reason they have
> any idea that URLs need specialised parsing in the first place.
>
> And while we all like to say 3rd party modules are great, the reality
> is that they provide a genuine problem for many of these
> non-specialist users - and I say that as a packaging specialist and
> pip maintainer. The packaging ecosystem is *not* newcomer-friendly in
> the way that core Python is, much as we're trying to improve that
> situation.
>
> I've said it previously, but I'll reiterate - IMO this *must* have a
> PEP, and that PEP must be clear that the intention is to *remove*
> urllib, not simply to "deprecate and then think about it". That could
> be making it part of PEP 594, or a separate PEP, but one way or
> another it needs a PEP.
>
PEP 594 is meant to be a set of uncontroversial removals of mostly unused
modules. Removing urllib is obviously not going to be uncontroversial, so
it should be discussed in a separate PEP.


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

[Python-Dev] Re: Increase of Spammy PRs and PR reviews

[Jelle Zijlstra]

El dom, 30 ene 2022 a las 2:40, Irit Katriel via Python-Dev (<
python-dev@python.org>) escribió:

>
> A non-core approval changes the label from "awaiting review" to "awaiting
> core review".
>
Interestingly, it also changes if a non-core dev requests changes (e.g.,
see https://github.com/python/cpython/pull/31021). Should that be
considered a bug?


> I find this useful, and occasionally filter on "awaiting core review"
> because it indicates that at least one other person found the PR sound /
> interesting.  I would not like this to change - I think high quality
> reviews from non-core contributors are valuable for the project and are a
> very quick way for the contributor to get the right kind of attention from
> core devs.
>
> If people spam the approvals (i.e., approve PRs without reviewing them)
> then the distinction between the labels becomes meaningless, of course.
> Though I do wonder what the motivation for doing that repeatedly would be.
> My basic assumption is that people usually try not to make fools of
> themselves.
>
> Note that contributors can still approve a perfect PR - a quality review
> in this case would include a brief comment indicating that you understand
> the change and perhaps why you find it valuable.
>
> On the matter of spammy PRs - I agree with both Rupert and Ethan (F):
> trivial PRs can add value, and a large number of them can be annoying.  You
> can add value and be annoying at the same time (my triage work on b.p.o is
> probably in this category. Thankfully it's clear I'm not after "triage
> points", because there aren't any). At the end of the day, it doesn't
> really matter what a contributor's motivation is - it's up to the core devs
> to decide which PRs are valuable enough to merge, or even to review, and
> who they enjoy working with. These things tend to sort themselves out on
> their own.
>
> I don't think we need to restrict access for non-core contributors
> compared to the status quo.  What I do think we need is to make it easier
> for core devs to close issues and PRs. We have a huge pile of open issues
> and PRs, some of which we know will never happen (stale or otherwise) and
> we don't close them because it's an unpleasant task to let someone down,
> and sometimes they argue, and we're volunteers and why should we bother
> with this emotional labour.
>
> Through triage I found many 6 year old issues that, once I refreshed and
> perhaps put an 'easy' label on, got fixed. The useless issues we don't want
> to close are obscuring the ones we can and should fix.
>
> I'm sure this has been discussed before. My only idea is that we formalize
> some guidelines/criteria for closing old issues and PRs that make it more
> of a joint decision of the core devs and less of a personal issue between
> the core dev and the contributor. I would not suggest a blanket 'close
> issues/PRs with no activity for X months', as I said I found useful 6 year
> old issues. It has to be more sophisticated than that.
>

Agree, the count of 1.6k open PRs is not a good look for new contributors.
We should be OK with closing an issue or PR if we are not going to make the
change.


>
> In summary - my view is that rather than making contributors contribute
> less, we should be more effective in reviewing the contributions, including
> rejecting those that should be rejected.
>
>
> On Sun, Jan 30, 2022 at 8:06 AM Ethan Smith  wrote:
>
>>
>>
>> On Sat, Jan 29, 2022 at 7:38 PM Inada Naoki 
>> wrote:
>>
>>> On Sun, Jan 30, 2022 at 12:03 PM Ethan Smith  wrote:
>>> >
>>> > As a non-committer, I want to make a plea for non-committer approval
>>> reviews, or at least that they have a place. When asked how outsiders can
>>> contribute I frequently see "review open PRs" as a suggested way of
>>> contributing to CPython. Not being able to approve PRs that are good would
>>> be a barrier to those contributions.
>>> >
>>> > Furthermore, I am collaborating with a couple of core devs, it would
>>> make collaboration more difficult if I couldn't review their work and say
>>> that I thought the changes looked good.
>>> >
>>>
>>> You can still write a review comment, including "LGTM".
>>
>>
>> Fair enough, I suppose commenting with "LGTM" works just as well.
>>
>>
>>> What you can
>>> not is labeling PR as "Approved."
>>> So I don't think it makes collaboration difficult.
>>>
>> By preventing approval from others, we can easily find PRs approved
>>> from core-devs or triage members but not merged yet.
>>>
>>
>>> > I know "drive by approvals" are annoying but I think it is
>>> unfortunately part of open source projects.
>>> >
>>>
>>> Sorry, but I don't think so.
>>>
>>
>> Well, if you disallow drive-by approvals, you will still get drive-by
>> LGTM comments. People seem to believe that adding their approval will
>> expedite a PR merge, for some reason (or want to bump a stale PR in hopes
>> of a quicker merge).
>>
>>
>>>
>>> --
>>> Inada Naoki  
>>>
>> ___
>> Py

[Python-Dev] Re: RFC on PEP 673: Self Type

[Jelle Zijlstra]

El lun, 17 ene 2022 a las 6:25, Petr Viktorin ()
escribió:

> On Wed, Nov 17, 2021 at 8:31 AM Pradeep Kumar Srinivasan
>  wrote:
> >
> > This PEP [1] introduces a simple and intuitive way to annotate methods
> and classmethods that return an instance of their class. Such methods and
> classmethods occur quite frequently, but the existing way to annotate them
> correctly is quite arcane and error-prone. The PEP introduces a special
> type `Self` to represent the type of the `self` parameter, similar to the
> `this` type in TypeScript and the `Self` type in Rust. We have
> implementations for mypy and pyright. The PEP does not affect CPython
> directly except for the addition of one special form (Self) to typing.py
> [2].
> >
> > Since we have reached consensus on the PEP in typing-sig [3], we wanted
> to get your comments and suggestions before submitting to the Steering
> Council.
> >
> > Thanks,
> > Pradeep Kumar Srinivasan
> > James Hilton-Balfe
> >
> > [1]: https://www.python.org/dev/peps/pep-0673/
> > [2]: Adding `Self` to typing_extensions.py:
> https://github.com/python/typing/pull/933
> > [3]: See the comments from typing-sig members on the Google doc:
> https://docs.google.com/document/d/1ujuSMXDmSIOJpiZyV7mvBEC8P-y55AgSzXcvhrZciuI/edit?usp=sharing
>
> Hello, and thanks for the PEP!
> Sorry I'm late, but I have two curious questions about the PEP.
> I don't think they should hold back accepting the PEP, but I'm
> interested in the answers.
>
> The PEP uses `reveal_type`, a function that's appeared in a few PEPs
> already, but was never described. Is it a standard function in typing
> tools, something specific to mypy, or pseudocode?
>

It's a function that doesn't exist at runtime, but when a type checker sees
a call, it emits the inferred type of the argument. It originated with mypy
but I believe has been adopted by all type checkers.

There's been some talk of adding it to the `typing` module, but that hasn't
happened so far. I opened https://bugs.python.org/issue46414 to suggest
adding it.


>
> The PEP says "we reject Self in metaclasses."
> "Metaclass" can mean "subclass of `type`", or it can refer to how a
> value is used -- for example, you can write `class
> Foo(metaclass=print): ...`.
> In the PEP's example, is MyMetaclass rejected because:
> - it's used as a metaclass in a class statement, or
> - it's a subclass of `type` (so it's rejected even if unused), or
> - it becomes a class of a class?
> Or is the exact interpretation best left to the type checker?
> ___
> 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/DVOQK3U6MOYXPRXF5OVLVLJBPEJRUIM5/
> 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/6OZWGEQYZI4XR6GKRPKYEBOKXANSNGXE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Suggestion: a little language for type definitions

[Jelle Zijlstra]

El dom, 9 ene 2022 a las 10:50, Chris Angelico ()
escribió:

> On Mon, Jan 10, 2022 at 3:49 AM Christopher Barker 
> wrote:
> > > If "x->y" is syntactically valid anywhere in Python code, it's not a
> > problem that there are no core data types for which it's meaningful.)
> >
> > Here's where I'm not so sure -- this looks a lot like a binary operator,
> but it behaves quite differently. IIUC it would always create a Callable,
> regardless of what the types were of the two other types. And it would not
> invoke a dinder on either, yes.
> >
> > Nor would it be like assignment.
> >
> > This is even worse than the use of [] in type hinting which is also
> using the same sytax for a very different meaning -- at least that one is
> stil calling __getitem__ :-)
> >
>
> From my understanding, "x->y" would create a Callable if given two
> *types*, but its meaning if given two other objects is still
> undefined. So there's still room for it to be an operator, just like
> [] is, and for it to be given semantic meaning for the 'type' type and
> all of its subclasses. Or alternatively, there's room for it to be
> given meaning in a completely different way, but still universally
> (there's a proposal for it to be a form of inline function, although
> I'm not 100% sure of the details there).
>

With the current iteration of PEP 677, `(x) -> y` would return a special
object (defined in the `types` module) that simply holds whatever `x` and
`y` evaluate to. You could put whatever expression you want at runtime and
it would work, though a static checker may be unhappy with you.

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

[Python-Dev] Re: Semi-proposal: Tagged None

[Jelle Zijlstra]

El jue, 21 oct 2021 a las 10:25, David Mertz, Ph.D. ()
escribió:

> I've moved this to python-ideas where it is more appropriate, as Chris
> notes
>
> On Thu, Oct 21, 2021, 8:42 PM Chris Angelico  wrote:
>
>> On Fri, Oct 22, 2021 at 3:23 AM David Mertz, Ph.D.
>>  wrote:
>> >
>> > On Thu, Oct 21, 2021 at 2:52 AM Steven D'Aprano 
>> wrote:
>> >>
>> >> On Tue, Oct 19, 2021 at 05:09:42PM -0700, Michael Selik wrote:
>> >> > None and its ilk often conflate too many qualities. For example, is
>> it
>> >> > missing because it doesn't exist, it never existed, or because we
>> never
>> >> > received a value, despite knowing it must exist?
>> >
>> >
>> >>
>> >> 30+ years later, and we cannot easily, reliably or portably use NAN
>> >> payloads. Most people don't care. If we offerred them a dozen or a
>> >> thousand distinct sentinels for all the various kinds of missing data,
>> >> how many people would use them and how many would just stick to plain
>> >> old None?
>> >
>> >
>> > In data science, I have been frustrated by the sparsity of ways of
>> spelling "missing value."
>>
>> Might be worth redirecting this to -ideas.
>>
>> > Besides the distinction Michael points out, and that Steven did in
>> relation to NaNs with payloads, I encounter missingness of various other
>> sorts as well.  Crucially,  an important kind of missing data is data where
>> the value I received seems unreliable and I have decided to *impute*
>> missingness rather than accept a value I believe is unreliable.
>> >
>> > But there is also something akin to what Michael points out (maybe it's
>> just an example).  For example, "middle name" is something that some people
>> simply do not have, other people choose not to provide on a survey, and
>> others still we just don't know anything beyond "it's not there."
>> >
>>
> This feels like something you should express with an enum for all the
different kinds of missing data:

class MissingReason(enum.Enum):
no_middle_name = 1
not_provided = 2
unknown = 3

middle_name: str | MissingReason

This gives you more structured and precise data than None-plus-string-tag
and avoids breaking the ecosystem by changing the meaning and behavior of
None.
___
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/EOBURF7EFGD5CLZS35GFTCWYZU2M7RDQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Type annotations, PEP 649 and PEP 563

[Jelle Zijlstra]

El jue, 21 oct 2021 a las 10:31, Carl Meyer () escribió:

> On Thu, Oct 21, 2021 at 10:44 AM Damian Shaw
>  wrote:
> > Sorry for the naive question but why doesn't "TYPE_CHECKING" work under
> PEP 649?
> >
> > I think I've seen others mention this but as the code object isn't
> executed until inspected then if you are just using annotations for type
> hints it should work fine?
> >
> > Is the use case wanting to use annotations for type hints and real time
> inspection but you also don't want to import the objects at run time?
>
> Yes, you're right. And I don't think PEP 649 and PEP 563 are really
> all that different in this regard: if you have an annotation using a
> non-imported name, you'll be fine as long as you don't introspect it
> at runtime. If you do, you'll get a NameError. And with either PEP you
> can work around this if you need to by ensuring you do the imports
> first if you're going to need the runtime introspection of the
> annotations.
>
> The difference is that PEP 563 makes it easy to introspect the
> annotation _as a string_ without triggering NameError, and PEP 649
> takes that away, but I haven't seen anyone describe a really
> compelling use case for that.
>
> I would want this for my type checker, pyanalyze. I'd want to get the raw
annotation and turn it into a type. For example, if the annotation is
`List[SomeType]` and `SomeType` is imported in `if TYPE_CHECKING`, I'd at
least still be able to extract `List[Any]` instead of bailing out
completely. With some extra analysis work on the module I could even get
the real type out of the `if TYPE_CHECKING` block.
___
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/Y2647QWRAOYLL22UWZL37DKAEUK22UIC/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Jelle Zijlstra]

El vie, 8 oct 2021 a las 0:54, Paul Moore () escribió:

> On Fri, 8 Oct 2021 at 03:45, S Pradeep Kumar  wrote:
>
> > Typing-sig has been discussing user-friendly syntax for the type used to
> represent callables. [1] Since this affects the Python language syntax, we
> wanted to get some high-level feedback from you before putting up a
> detailed PEP.
>
> Disclaimer: I personally find that use of complex type annotations
> like Callable make code unreadable for the *human* reader, as compared
> to out of line information like a clearly-written comment or
> documentation. Therefore I'd probably be extremely reluctant to use
> this new syntax in real-life projects, regardless of the form that it
> takes. However, I do have some experience working on projects that use
> type annotations like this for callbacks, so I will answer in spite of
> my personal reservations.
>

The point of this change is to make Callable annotations more readable:
(int) -> int is a lot less dense than Callable[[int], int]. We hope that
the new syntax will make it easier to use more complex annotations. Of
course, if you think the annotations are still too complex, that's your
choice.


>
> > **Question 1**: Are there concerns we should keep in mind about such a
> syntax proposal?
>
> In my experience, a common pattern for functions that take non-trivial
> callbacks is to call them with named arguments rather than positional,
> in order to preserve future compatibility. So I would like callback
> annotations to be able to express the type "a function returning X,
> taking arguments `arg1` of type Y and `arg2` of type Z". The lack of
> keyword argument support in this proposal makes it unusable for APIs
> like this.
>
That's one of the differences between the proposals discussed here. The
basic proposal Pradeep pointed out would not support named arguments, the
more complete syntax favored by Guido (and also by me; 2(a) in Pradeep's
email) would support it.

Pradeep has done some empirical analysis that shows that in practice it is
not very common to use such types, though.


>
> Conversely, for callbacks with single arguments like f(cb: int->int)
> -> int, in my experience a lot of uses are lambda expressions, so
> something like f(lambda x: x+1). I would be a strong -1 on having to
> add types to lambda expressions (they are ugly enough already) so how
> does this interact with the annotation? Are type checkers able to
> correctly infer the type of lambda x: x+1, or would the whole
> expression end up being untyped? Similarly with functools.partial -
> would that correctly match the type? If common uses of callbacks end
> up being untyped in practice, that drastically reduces the value of
> the new syntax. (Note that this point is equally applicable to
> Callable - so I guess it's not so much about the new syntax as it is
> about whether annotating callbacks is sufficiently useful to be
> *worth* improving).
>

Type checkers should be able to infer this type. You would not need to
write any explicit type when you call f(). However, the definition of `f`
would look something like `def f(callback: (int) -> int) -> None: ...`.
Currently, you'd write that as `def f(callback: Callable[[int], int]) ->
None: ...`.


>
> Also, note that I automatically used a type of int->int up there. As
> someone else asked, is that form allowed, or is it required to be
> (int)->int? In my view, if we require the latter, I expect there will
> be a *lot* of people making that mistake and having to correct it.
>
That's not something we discussed before. I'd be OK with allowing this
unless it makes the grammar too ambiguous.


>
> > **Question 2**: Do you have preferences either way? Do we propose (1)
> alone or (1) + (2)?
>
> See above. My experience is that using named arguments for callbacks
> is a useful approach, and should probably be encouraged rather than
> made difficult, so I'd say that named argument support is important.
> Having said that, I think that making simple types like int->int or
> (int, int)->int more awkward to write would be a disadvantage - they
> are used a *lot* in things like the `key` argument of `sort`. So I'm
> -1 on things like (for example) requiring a colon as in (:int, :int)
> -> int.
>
> But to reiterate, I'm probably not likely to ever be a significant
> consumer of this feature, so consider the above with that in mind ;-)
>
> Paul
> ___
> 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/ANGLWMP4X7AIBFI5SII7RBCOHRIZZ7TH/
> 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/

[Python-Dev] Re: python3.10rc2 compilation on android/termux/clang12.0.1 fails

[Jelle Zijlstra]

Did previous versions of Python compile successfully? The RC phase wouldn't
be the right time to add support for a new platform.

El mié, 15 sept 2021 a las 10:15, Sandeep Gupta ()
escribió:

> I am trying to compile Python3.10rc2 on rather unusual platform (termux on
> android). The
> gcc version is listed below:
> ~ $ g++ -v
> clang version 12.0.1
> Target: aarch64-unknown-linux-android24
> Thread model: posix
> InstalledDir: /data/data/com.termux/files/usr/bin
>
> I get following warnings and errors:
> Python/pytime.c:398:10: warning: implicit conversion from 'long' to
> 'double' changes value from 9223372036854775807 to 9223372036854775808
> [-Wimplicit-const-int-float-conver
> sion]
>if (!_Py_InIntegralTypeRange(_PyTime_t, d)) {
>
> Python/bootstrap_hash.c:141:17: error: implicit declaration of function
> 'getrandom' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
>n = getrandom(dest, n, flags);
>^
> Python/bootstrap_hash.c:145:17: error: implicit declaration of function
> 'getrandom' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
>n = getrandom(dest, n, flags);
>
> Not sure if this is limitation of the platform or Python codebase needs
> fixes.
>
> Thanks
> -S ___
> 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/KEURSMCLUVI7VPKM6M2VUV4JIW6FP66Z/
> 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/G6LCSHQBTPR3HUPUNTCANXYPW4K34TFQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 663: Improving and Standardizing Enum str(), repr(), and format() behaviors

[Jelle Zijlstra]

El vie, 10 sept 2021 a las 22:56, Ethan Furman ()
escribió:

> 
>
> Specification
> =
>
> There a three broad categories of enum usage:
>
> - standard: Enum or Flag
>a new enum class is created, and the members are used as
> ``class.member_name``
>
> - drop-in replacement: IntEnum, IntFlag, StrEnum
>a new enum class is created which also subclasses ``int`` or ``str``
> and uses
>``int.__str__`` or ``str.__str__``; the ``repr`` can be changed by
> using the
>``global_enum`` decorator
>
> - user-mixed enums and flags
>the user creates their own integer-, float-, str-, whatever-enums
> instead of
>using enum.IntEnum, etc.
>
> Some sample enums::
>
>  # module: tools.py
>
>  class Hue(Enum):  # or IntEnum
>  LIGHT = -1
>  NORMAL = 0
>  DARK = +1
>
>  class Color(Flag):  # or IntFlag
>  RED = 1
>  GREEN = 2
>  BLUE = 4
>
>  class Grey(int, Enum):  # or (int, Flag)
> BLACK = 0
> WHITE = 1
>
> Using the above enumerations, the following table shows the old and new
> behavior, while the last shows the final result:
>
>
>
> +-+--+-++---+---++---+
> | type   | enum repr() | enum str() | enum format()
>  | flag repr()   | flag str()
>  | flag format() |
>
> +-+--+-++---+---++---+
> | standard| 3.10 | ||
>  |   |
> Color.RED|GREEN| Color.RED|GREEN   |
> |
>
> +--+-++---+---++---+
> | | new  | ||
>  |  |
> Color.RED|Color.GREEN  | Color.RED|Color.GREEN |
>
> +-+--+-++---+---++---+
>
> +-+--+-++---+---++---+
> | user mixed  | 3.10 | || 1
>  ||
>  | 1 |
> |
>
> +--+-++---+---++---+
> | | new  | || Grey.WHITE
>   |   |
>  | Grey.WHITE|
>
> +-+--+-++---+---++---+
>
> +-+--+-++---+---++---+
> | int drop-in | 3.10 | | Hue.LIGHT  |
>  |   |
> Color.RED|GREEN|   |
> |
>
> +--+-++---+---++---+
> | | new  | | -1 |
>  |  | 3
>  |   |
>
> +-+--+-++---+---++---+
>
> +-+--+-++---+---++---+
> | global  | 3.10 |  | Hue.LIGHT  | Hue.LIGHT
>  |   |
> Color.RED|GREEN| Color.RED|GREEN   |
> |
>
> +--+-++---+---++---+
> | | new  | tools.LIGHT | LIGHT  | LIGHT
>  | tools.RED|tools.GREEN | RED|GREEN
>  | RED|GREEN |
>
> +-+--+-++---+---++---+
>
> +-+--+-++---+---++---+
> | user mixed  | 3.10 ||| Grey.WHITE
>  | 1 |
> |
>
> +--+-++---+---++---+
> | | new  | tools.WHITE | WHITE  | WHITE
>  | tools.WHITE   | WHITE
>  | WHITE |
>
> +-+--+-++---+---++-

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

[Jelle Zijlstra]

El mar, 10 ago 2021 a las 11:20, Thomas Grainger ()
escribió:

> Although the co_annoations code could intercept the NameError and replace
> return a ForwardRef object instead of the resolved name
>
I implemented a version of this in
https://github.com/larryhastings/co_annotations/pull/3 but Larry didn't
like it.


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

[Python-Dev] Re: Enum -- last call for comments on 3.10 changes

[Jelle Zijlstra]

El lun, 28 jun 2021 a las 1:00, Ethan Furman ()
escribió:

> I have spoken with Pablo (3.10 RM), and he agrees that a change to Enum
> str() in 3.10 and another in 3.11 is less than
> ideal, so this new thread is to collect comments about Enum and it's str()
> and repr() and whether the changes take
> effect in 3.10, 3.11, or both.
>
> TL;DR -- sorry, there isn't one.
>
> History:
> 
> As Enum and IntEnum have started proliferating in the stdlib, some of
> those enumerations have changed the str() and
> repr() of their members -- for example, in 3.8 re.RegexFlag had its repr()
> and str() changed to be module.name
> (re.ASCII) for both instead of 
> () for the repr(); that change made sense
> because all the members are exported to re's global name space, and they
> are accessed as `re.ASCII` in existing code.
>
> While a good change (in my opinion and with which I had nothing to do), we
> now have stdlib enumerations with differing
> str() and repr()s, which is a minor ding against recognizability and
> usability.
>
>
> Current 3.10 Changes
> 
> In an effort to standardize the stdlib enums, a new decorator was added:
> global_enum().  It can be called manually (for
> example in re.RegexFlag), or automatically by Enum._convert_ (for example
> in ssl.VerifyFlags).
>
> That changed was visually appealing, and I had users wanting that type of
> output for Enum in general, so after asking
> for feedback on python-dev and python-ideas (and receiving little) I
> changed the basic str() and repr() of Enum to:
>
> - str(): NAME
> - repr(): enum.NAME
>
> While working on some other bugs/changes in Enum.__format__ and
> serialization in general, I have come to believe that
> IntEnum (and IntFlag) should be as near-perfect a drop-in replacement as
> possible for when they are used to replace
> existing integer constants (which I believe is their most important
> use-case).
>
>
> Reverting 3.10 Changes
> --
> I have been increasingly unhappy with the general `Enum.__repr__` change,
> so while the stdlib global repr() change is
> staying, Enum, IntEnum, etc., is going back to .
>
Great!

>
>
> Proposed 3.10 Change (for 3.10.0 beta 4)
> 
> In order to improve the drop-in replacement use-case for IntEnum and
> IntFlag, I would like to change the str() for those
> two to be simply the value of the member, as if it was still a plain
> integer and not part of an enumeration.  At that
> point the only obvious difference would be the repr(), which I think is
> the most important and useful change as that is
> what (should) show up in log files, the REPL, etc.
>
> This would also make IntEnum and IntFlag consistent with StrEnum as, for
> other reasons, StrEnum member str()s are the
> values of the members rather than the names of the members.  Note also
> that this change would not affect user created
> enumerations that mixed in int on their own.
>
>
> The Question
> 
> With all the changes currently happening to the str()s and repr()s of the
> various enums, what are the good reasons to
> not make this final change now, and instead have one more change in 3.11?
>

Just to make myself less confused, the behavior of str(Color.RED) (where
Color is an IntEnum) is:
- 3.9 and below: "Color.RED"
- Current 3.10 branch: "RED"
- Proposed change: "256"

I agree that we shouldn't change the behavior in 3.10 and again in 3.11,
and also that the proposed behavior is the best long-term option.

If it's too late for completely new behavior in 3.10, we could instead
revert 3.10 to use the 3.9 behavior and make the change only in 3.11.


>
>
> --
> ~Ethan~
>
>
> Summary of Enum str()s and repr()s by category
>
> |   | repr() | str() | format()
>
Somewhat unrelatedly, I don't like that str() and format() may return
different results for enums; I think enums are the only type I commonly
encounter for which this is the case. If possible, any change we make
should move us closer to having both return the same result.


> | stdlib global | re.ASCII   | re.ASCII  | 256
> | Enum  |  | Color.RED | RED
> | IntEnum   |  | 1 | 1
> | int, Enum |  | Color.RED | 1 (will be RED in 3.12 due
> to back-compatibility
> |   || constraints which should
> affect very few people as
> |   || as they are probably using
> IntEnum instead of mixing
> |   || in int themselves --
> comments about this likelihood also
> |   || appreciated)
>
It does happen sometimes:
https://grep.app/search?q=%28int%2C%20Enum%29&case=true&filter[lang][0]=Python
.

> ___
> 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.

[Python-Dev] Re: IntEnum, IntFlag, and the stdlib

[Jelle Zijlstra]

Ethan reached out to me for clarification and it turns out the work for
updating to the 3.10 changes actually isn't too bad for our codebase. On a
quick test, I did see several failures as a result of the change to str()
and repr() for enum members. For example, the repr() of a compound data
structure changed because it incorporated the str() of an enum somewhere
inside the data structure. Similarly, another test relied on the repr() of
an enum member being of the form . It's not too bad, though; about
half a dozen failing tests out of ~5000, and they're probably not terribly
hard to fix.

Still, changes like this add up and make it harder to upgrade Python
seamlessly, so we should still try to minimize them.

El mié, 23 jun 2021 a las 20:13, Jelle Zijlstra ()
escribió:

>
>
> El mié, 23 jun 2021 a las 19:54, Ethan Furman ()
> escribió:
>
>> TL;DR  I am considering changing IntEnum and IntFlag's `__str__` to be
>> `int.__str__`
>>
>> IntEnum and IntFlag are becoming more common in the stdlib.  They
>> currently show up in
>>
>> * http
>> * re
>> * signal
>> * ssl
>> * socket
>>
>> to name just a few.
>>
>> 3.10 already has some changes to the str() and repr() of enums in general:
>>
>> HTTPStatus ->  OK  and  HTTPStatus.OK  instead of HTTPStatus.OK and
>> 
>>
>>
>> Enum's that are taking the place of global constants have the repr()
>> further modified:
>>
>> RegexFlag -> ASCII  and  re.ASCII  instead of RegexFlag.ASCII and
>> 
>>
>>
>> When Enum was first created we also modified the default JSON encoder to
>> be able to encode int- and float-based
>> enumerations; however, with the continued rise of Python in the world a
>> user stumbled upon a stdlib encoder that we
>> missed: `urllib.parse.urlencode()` (as seen in issue 33025 [1]).
>>
>> IIRC enum.IntEnum (and later enum.IntFlag) were introduced so they could
>> be drop-in replacements for existing integer
>> constants.  At the time I didn't fully appreciate how those constants
>> were used in code with regards to str() -- which
>> is to say, changing the str() output can be a breaking change, even
>> inside the stdlib.
>>
>> What I would like to do for the enum module is make any supplied mixed-in
>> enums a little more vanilla:
>>
>> * str() is the mixed-in `__str__`, not the Enum `__str__`
>> * format() is the mixed-in `__format__`, not the Enum `__format__` (this
>> is the current effective behavior already)
>>
>> Other benefits, particularly repr(), would remain.  Note that a mixed
>> enum created by a user would have the normal Enum
>> `__str__` and `__format__`.
>>
>>
>> Summary:  mixed enums provided in the enum module should maintain the
>> mixed data types `__str__` and `__format__`.
>>
>> Thoughts?
>>
>
> This seems like it's going to be a backwards incompatible change that may
> turn out to be fairly disruptive for the codebase I have to maintain. We
> use IntEnum heavily and any change in behavior is likely to require
> migration work. I'm already pretty worried about the other enum changes in
> 3.10.
>
>
>>
>> --
>> ~Ethan~
>>
>>
>>
>> [1] https://bugs.python.org/issue33025
>> ___
>> 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/HE36QRXPPQNHGQKYZM3ZTG42EQQRHAIX/
>> 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/6JVFXFPFWKKOBKZTQ3HQO7XFRQC4IYSP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: IntEnum, IntFlag, and the stdlib

[Jelle Zijlstra]

El mié, 23 jun 2021 a las 19:54, Ethan Furman ()
escribió:

> TL;DR  I am considering changing IntEnum and IntFlag's `__str__` to be
> `int.__str__`
>
> IntEnum and IntFlag are becoming more common in the stdlib.  They
> currently show up in
>
> * http
> * re
> * signal
> * ssl
> * socket
>
> to name just a few.
>
> 3.10 already has some changes to the str() and repr() of enums in general:
>
> HTTPStatus ->  OK  and  HTTPStatus.OK  instead of HTTPStatus.OK and
> 
>
>
> Enum's that are taking the place of global constants have the repr()
> further modified:
>
> RegexFlag -> ASCII  and  re.ASCII  instead of RegexFlag.ASCII and
> 
>
>
> When Enum was first created we also modified the default JSON encoder to
> be able to encode int- and float-based
> enumerations; however, with the continued rise of Python in the world a
> user stumbled upon a stdlib encoder that we
> missed: `urllib.parse.urlencode()` (as seen in issue 33025 [1]).
>
> IIRC enum.IntEnum (and later enum.IntFlag) were introduced so they could
> be drop-in replacements for existing integer
> constants.  At the time I didn't fully appreciate how those constants were
> used in code with regards to str() -- which
> is to say, changing the str() output can be a breaking change, even inside
> the stdlib.
>
> What I would like to do for the enum module is make any supplied mixed-in
> enums a little more vanilla:
>
> * str() is the mixed-in `__str__`, not the Enum `__str__`
> * format() is the mixed-in `__format__`, not the Enum `__format__` (this
> is the current effective behavior already)
>
> Other benefits, particularly repr(), would remain.  Note that a mixed enum
> created by a user would have the normal Enum
> `__str__` and `__format__`.
>
>
> Summary:  mixed enums provided in the enum module should maintain the
> mixed data types `__str__` and `__format__`.
>
> Thoughts?
>

This seems like it's going to be a backwards incompatible change that may
turn out to be fairly disruptive for the codebase I have to maintain. We
use IntEnum heavily and any change in behavior is likely to require
migration work. I'm already pretty worried about the other enum changes in
3.10.


>
> --
> ~Ethan~
>
>
>
> [1] https://bugs.python.org/issue33025
> ___
> 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/HE36QRXPPQNHGQKYZM3ZTG42EQQRHAIX/
> 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/ZIUN5MTAS75QI2UFSIN5YO6SVIY3AXNY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Future PEP: Include Fine Grained Error Locations in Tracebacks

[Jelle Zijlstra]

El sáb, 8 may 2021 a las 10:00, Devin Jeanpierre ()
escribió:

> > What are people thoughts on the feature?
>
> I'm +1, this level of detail in the bytecode is very useful. My main
> interest is actually from the AST though. :) In order to be in the
> bytecode, one assumes it must first be in the AST. That information is
> incredibly useful for refactoring tools like https://github.com/ssbr/refex
> (n.b. author=me) or https://github.com/gristlabs/asttokens (which refex
> builds on). Currently, asttokens actually attempts to re-discover that kind
> of information after the fact, which is error-prone and difficult.
>
The AST already has column offsets (
https://docs.python.org/3.10/library/ast.html#ast.AST.col_offset).


>
> This could also be useful for finer-grained code coverage tracking and/or
> debugging. One can actually imagine highlighting the spans of code which
> were only partially executed: e.g. if only x() were ever executed in "x()
> and y()" . Ned Batchelder once did wild hacks in this space, and maybe this
> proposal could lead in the future to something non-hacky?
> https://nedbatchelder.com/blog/200804/wicked_hack_python_bytecode_tracing.html
> I say "in the future" because it doesn't just automatically work, since as
> I understand it, coverage currently doesn't track spans, but lines hit by
> the line-based debugger. Something else is needed to be able to track which
> spans were hit rather than which lines, and it may be similarly hacky if
> it's isolated to coveragepy. If, for example, enough were exposed to let a
> debugger skip to bytecode for the next different (sub) span, then this
> would be useful for both coverage and actual debugging as you step through
> an expression. This is probably way out of scope for your PEP, but even so,
> the feature may be laying some useful ground work here.
>
> -- Devin
>
> On Fri, May 7, 2021 at 2:52 PM Pablo Galindo Salgado 
> wrote:
>
>> Hi there,
>>
>> We are preparing a PEP and we would like to start some early discussion
>> about one of the main aspects of the PEP.
>>
>> The work we are preparing is to allow the interpreter to produce more
>> fine-grained error messages, pointing to
>> the source associated to the instructions that are failing. For example:
>>
>> Traceback (most recent call last):
>>
>>   File "test.py", line 14, in 
>>
>> lel3(x)
>>
>> ^^^
>>
>>   File "test.py", line 12, in lel3
>>
>> return lel2(x) / 23
>>
>>^^^
>>
>>   File "test.py", line 9, in lel2
>>
>> return 25 + lel(x) + lel(x)
>>
>> ^^
>>
>>   File "test.py", line 6, in lel
>>
>> return 1 + foo(a,b,c=x['z']['x']['y']['z']['y'], d=e)
>>
>>  ^
>>
>> TypeError: 'NoneType' object is not subscriptable
>>
>> The cost of this is having the start column number and end column number
>> information for every bytecode instruction
>> and this is what we want to discuss (there is also some stack cost to
>> re-raise exceptions but that's not a big problem in
>> any case). Given that column numbers are not very big compared with line
>> numbers, we plan to store these as unsigned chars
>> or unsigned shorts. We ran some experiments over the standard library and
>> we found that the overhead of all pyc files is:
>>
>> * If we use shorts, the total overhead is ~3% (total size 28MB and the
>> extra size is 0.88 MB).
>> * If we use chars. the total overhead is ~1.5% (total size 28 MB and the
>> extra size is 0.44MB).
>>
>> One of the disadvantages of using chars is that we can only report
>> columns from 1 to 255 so if an error happens in a column
>> bigger than that then we would have to exclude it (and not show the
>> highlighting) for that frame. Unsigned short will allow
>> the values to go from 0 to 65535.
>>
>> Unfortunately these numbers are not easily compressible, as every
>> instruction would have very different offsets.
>>
>> There is also the possibility of not doing this based on some build flag
>> on when using -O to allow users to opt out, but given the fact
>> that these numbers can be quite useful to other tools like coverage
>> measuring tools, tracers, profilers and the such adding conditional
>> logic to many places would complicate the implementation considerably and
>> will potentially reduce the usability of those tools so we prefer
>> not to have the conditional logic. We believe this is extra cost is very
>> much worth the better error reporting but we understand and respect
>> other points of view.
>>
>> Does anyone see a better way to encode this information **without
>> complicating a lot the implementation**? What are people thoughts on the
>> feature?
>>
>> Thanks in advance,
>>
>> 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.p

[Python-Dev] Re: Can't sync cpython main to my fork

[Jelle Zijlstra]

El jue, 6 may 2021 a las 6:58, Skip Montanaro ()
escribió:

> > Your main branch in GitHub has some commits they are not in
> python/cpython.
> > https://github.com/smontanaro/cpython/commits/main
>
> Regarding this. How else am I to keep my fork in sync with
> python/cpython other than by the occasional pull upstream/push origin
> process? That's what all those merges are. Is that first commit
> (Github (un)Dependabot) the culprit, or are all the other git merge
> results also problematic?
>

Maybe others have different workflows, but I don't see much of a need for
keeping your fork's main branch up to date. My workflow is something like
this:

% git remote -v
origin g...@github.com:JelleZijlstra/cpython.git (fetch)
origin g...@github.com:JelleZijlstra/cpython.git (push)
upstream https://github.com/python/cpython.git (fetch)
upstream https://github.com/python/cpython.git (push)
% git checkout main
Already on 'main'
Your branch is up to date with 'upstream/main'.
% git pull
... get new changes from upstream
% git checkout -b myfeature
... write my code
% git push -u origin myfeature
... open a pull request

So my local main branch tracks upstream/main (the real CPython repo), not
origin/main (my fork).


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

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

[Jelle Zijlstra]

For what it's worth, Larry's PEP 649 branch currently prohibits yield,
yield from, await, and the walrus operator in annotations. That seems like
the right choice unless there's some realistic use case for any of these.

El vie, 23 abr 2021 a las 11:27, Batuhan Taskaya ()
escribió:

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

[Python-Dev] Re: Anyone else gotten bizarre personal replies to mailing list posts?

[Jelle Zijlstra]

I got a few of these too. I'm not sure anything can be done about it, since
the mailing list is publicly archived, so anyone could send emails to
anyone who posts here.

El vie, 23 abr 2021 a las 8:42, Nathaniel Smith () escribió:

> I just got the reply below sent directly to my personal account, and I'm
> confused about what's going on. If it's just a one off I'll chalk it up to
> random internet weirdness, but if other folks are getting these too it
> might be something the list admins should look into? Or... something?
>
> -- Forwarded message -
> From: Hoi lam Poon 
> Date: Fri, Apr 23, 2021, 02:01
> Subject: Re: [Python-Dev] Re: PEP 654: Exception Groups and except*
> [REPOST]
> To: Nathaniel Smith 
>
>
> Stop pretending, I can definitely get the key control file, your working
> group, all past actions and instructions cannot be cleared in front of me
> at all. You have been playing around for a few days, and I won’t stop you.
> Your face? I won’t, you know, you can’t drive me away, and that file is
> all, after I get it, you will be convicted even if you disband, I swear
>
> 在 2021年4月23日 週五 16:23，Nathaniel Smith  寫道：
>
>> On Wed, Apr 21, 2021 at 4:50 PM Guido van Rossum 
>> wrote:
>> > On Wed, Apr 21, 2021 at 3:26 PM Nathaniel Smith  wrote:
>> >> Sure. This was in my list of reasons why the backwards compatibility
>> >> tradeoffs are forcing us into awkward compromises. I only elaborated
>> >> on it b/c in your last email you said you didn't understand why this
>> >> was a problem :-). And except* is definitely useful. But I think there
>> >> are options for 'except' that haven't been considered fully.
>> >
>> > Do you have any suggestions, or are you just telling us to think
>> harder? Because we've already thought as hard as we could and within all
>> the constraints (backwards compatibility and otherwise) we just couldn't
>> think of a better one.
>>
>> The main possibility that I don't think we've examined fully is to
>> make 'except' blocks fire multiple times when there are multiple
>> exceptions. We ruled it out early b/c it's incompatible with nested
>> EGs, but if flat EGs are better anyway, then the balance shifts around
>> and it might land somewhere different. it's a tricky discussion
>> though, b/c both the current proposal and the alternative have very
>> complex implications and downsides. So we probably shouldn't get too
>> distracted by that until after the flat vs nested discussion has
>> settled down more.
>>
>> I'm not trying to filibuster here -- I really want some form of EGs to
>> land. I think python has the potential to be the most elegant and
>> accessible language around for writing concurrent programs, and EGs
>> are a key part of that. I don't want to fight about anything; I just
>> want to work together to make sure we have a full picture of our
>> options, so we can be confident we're making the best choice.
>>
>> > The real cost here is that we would need a new "TracebackGroup"
>> concept, since the internal data structures and APIs keep the traceback
>> chain and the exception object separated until the exception is caught. In
>> our early design stages we actually explored this and the complexity of the
>> data structures was painful. We eventually realized that we didn't need
>> this concept at all, and the result is much clearer, despite what you seem
>> to think.
>>
>> I'm not talking about TracebackGroups (at least, I think I'm not?). I
>> think it can be done with exactly our current data structures, nothing
>> new.
>>
>> - When an EG is raised, build the traceback for just that EG while
>> it's unwinding. This means if any C code peeks at exc_info while it's
>> in flight, it'll only see the current branch of the traceback tree,
>> but that seems fine.
>> - When the exception is caught and we go to write back the traceback
>> to its __traceback__ attribute, instead "peek through" the EG and
>> append the built-up traceback entries onto each of the constituent
>> exceptions.
>>
>> You could get cleverer for efficiency, but that basic concept seems
>> pretty simple and viable to me. What am I missing?
>>
>> -n
>>
>> --
>> Nathaniel J. Smith -- https://vorpus.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/VOBOWZGW44GNMW6IUZU6P5OO2A5YKB53/
>> 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/4BAOL763Y2O2AXLEILYGHSNG2VMZJIN6/
> Code of Conduct: http://py

[Python-Dev] Re: Keeping Python a Duck Typed Language.

[Jelle Zijlstra]

El mié, 21 abr 2021 a las 15:30, Paul Bryan () escribió:

> As demonstrated, protocols don't get us there because duck typing isn't a
> matter of having an object exhibit all of the attributes of a duck, but
> rather some subset of attributes to be used by the consumer. I want this
> duck to quack; someone else will want it to waddle. I don't see how type
> hints could reasonably support "file like object" in the duck type sense
> (unless the consumer were to specify the exact attributes of the duck it's
> interested in, which I fear would become a tedious type writing style). '
>

This approach (a Protocol that declares exactly what you need the file-like
object to do) is in fact what we've been doing in typeshed, the repository
that provides type hints for the standard library. For those unfamiliar, it
would look something like this:

from typing import Protocol

class SupportsRead(Protocol):
def read(self) -> bytes: ...

def uses_a_file(f: SupportsRead) -> None:
 f.read()

That's somewhat tedious, to be sure, but it is working duck typing.


>
> I too have sensed static typing driving the typing development agenda in
> Python recently, causing other typing methods to take a back seat, so to
> speak. I add my voice to those requesting Python handle other typing
> methods.
>
> Barring an innovation to allow a "subset" of a type to be declared in a
> type hint, I would conclude that static typing and duck typing are
> diametrically opposed. If we agree that both are valuable, developers could
> build consensus on that point, and work to ensure that one does not move
> forward at the expense of the other.
>
What would you suggest? Should the syntax for declaring Protocols be more
concise?


>
> Paul
>
> On Wed, 2021-04-21 at 12:36 -0700, Christopher Barker wrote:
>
> Thanks Mark for posting this. I know some of us are uneasy about the pace
> of the typing train 
>
> On Tue, Apr 20, 2021 at 11:20 AM Nathaniel Smith  wrote:
>
> > If you guarded your code with `isinstance(foo, Sequence)` then I could
> > not use it with my `Foo` even if my `Foo` quacked like a sequence. I was
> > forced to use nominal typing; inheriting from Sequence, or explicitly
> > registering as a Sequence.
>
> You say this like it's a bad thing, but how is this avoidable, even in
> principle? Structural typing lets you check whether Foo is duck-shaped
> -- has appropriate attribute names, etc. But quacking like a duck is
> harder: you also have to implement the Sequence behavioral contract,
> and realistically the only way to know that is if the author of Foo
> tells you.
>
>
> But that's not what duck typing is (at least to me :-) ) For a given
> function, I need the passed in object to quack (and yes, I need that quack
> to sound like a duck) -- but I usually don't care whether that object
> waddles like a duck.
>
> So yes, isinstance(obj, Sequence) is really the only way to know that obj
> is a Sequence in every important way -- but if you only need it to do one
> or two things like a Sequence, then you don't care.
>
> And this is not uncommon -- I suspect it's very rare for a single function
> to use most of the methods of a given ABC (or protocol, or whatever).
>
> And a lot of the standard library works exactly this way. Two examples
> (chosen arbitrarily, I just happen to have thought about how they work):
>
> json.load() simply calls ``fp.read()``, and passes the result on down to
> json.loads(). That's it -- no checking of anything.
>
> If fp does not have a read() method, you get an AttributeError. If fp has
> a read() method, but it returns something other than a string, then you get
> some other Exception. And if it returns a string, but that string isn't
> valid JSON, you get yet another kind of error.
>
> In short, json.load(fp, ...) requires fp to have a read() method that
> returns a valid JSON string. But it doesn't check, nor does it need to, if
> it's getting an actual io.TextIOBase object. Is that the right one? I'm not
> totally sure, which I kind of think makes my point -- I've been using
> "file-like" objects for years (decades) without worrying about it.
>
> Example 2:
>
> The str.translate method takes:
>
> "a mapping of Unicode ordinals to Unicode ordinals, strings, or None"
>
> Ok, then you need to pass in a Mapping, yes? Well, no you don't. The docs
> go on to say:
>
> The table must implement lookup/indexing via __getitem__, for instance a
> dictionary or list.
>
> Ah -- so we don't need a Mapping -- we need anything indexable by an
> integer that contains "ordinals, strings, or None". What the heck ABC could
> we use for that?
>
> The ABCs do have an already complex hierarchy of containers, but there is
> no "Indexable", (quacks) and certainly no "indexable and returns these
> particular things. (quacks a certain way). (maybe there's something in the
> typing module that would work for static typing -- I have no idea).
>
> I'm pretty sure this particular API was designed to accommodate the old
> 

[Python-Dev] Re: PEP 563 in light of PEP 649

[Jelle Zijlstra]

El lun, 19 abr 2021 a las 14:17, Larry Hastings ()
escribió:

> On 4/19/21 1:37 PM, Ethan Furman wrote:
>
> On 4/19/21 10:51 AM, Larry Hastings wrote:
>
> Something analogous /could/ happen in the PEP 649 branch but currently
> doesn't.  When running Inada Noki's benchmark, there are a total of nine
> possible annotations code objects.  Except, each function generated by the
> benchmark has a unique name, and I incorporate that name into the name
> given to the code object (f"{function_name}.__co_annotations__"). Since
> each function name is different, each code object name is different, so
> each code object /hash/ is different, and since they aren't /exact/
> duplicates they are never consolidated.
>
>
> I hate anonymous functions, so the name is very important to me.  The
> primary code base I work on does have hundreds of methods with the same
> signature -- unfortunately, many of the also have the same name (four
> levels of super() calls is not unusual, and all to the same
> read/write/create parent methods from read/write/create child methods).  In
> such a case would the name make a meaningful difference?
>
> Or maybe the name can be store when running in debug mode, and not stored
> with -O ?
>
>
> I think it needs to have *a* name.  But if it made a difference, perhaps
> it could use f"{function_name}.__co_annotations__" normally, and simply
> "__co_annotations__" with -O.
>
> Note also that this is the name of the annotations code object, although I
> think the annotations function object reuses the name too.  Anyway, under
> normal circumstances, the Python programmer would have no reason to
> interact directly with the annotations code/function object, so it's not
> likely it will affect them one way or another.  The only time they would
> see it would be, say, if the calculation of an annotation threw an
> exception, in which case it seems like seeing
> f"{function_name}.__co_annotations__" in the traceback might be a helpful
> clue in diagnosing the problem.
>
If the line numbers in the traceback are right, I'm not sure the function
name would make much of a difference.

>
> I'd want to see some real numbers before considering changes here.  If it
> has a measurable and beneficial effect on real-world code, okay! let's
> change it!  But my suspicion is that it doesn't really matter.
>
>
> Cheers,
>
>
> */arry*
> ___
> 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/ZAPCP4MFDOF34E3G2TWAVY7JUQRHDOOB/
> 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/V3N5ILAED6CWOEXL6L7XHRTUIS3AKN4M/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 563 and 649: The Great Compromise

[Jelle Zijlstra]

El sáb, 17 abr 2021 a las 20:45, Larry Hastings ()
escribió:

>
> The heart of the debate between PEPs 563 and 649 is the question: what
> should an annotation be?  Should it be a string or a Python value?  It
> seems people who are pro-PEP 563 want it to be a string, and people who are
> pro-PEP 649 want it to be a value.
>
> Actually, let me amend that slightly.  Most people who are pro-PEP 563
> don't actually care that annotations are strings, per se.  What they want
> are specific runtime behaviors, and they get those behaviors when PEP 563
> turns their annotations into strings.
>
> I have an idea--a rough proposal--on how we can mix together aspects of
> PEP 563 and PEP 649.  I think it satisfies everyone's use cases for both
> PEPs.  The behavior it gets us:
>
>- annotations can be stored as strings
>- annotations stored as strings can be examined as strings
>- annotations can be examined as values
>
>
> The idea:
>
> We add a new type of compile-time flag, akin to a "from __future__"
> import, but not from the future.  Let's not call it "from __present__", for
> now how about "from __behavior__".
>
> In this specific case, we call it "from __behavior__ import
> str_annotations".  It behaves much like Python 3.9 does when you say "from
> __future__ import annotations", except: it stores the dictionary with
> stringized values in a new member on the function/class/module called
> "__str_annotations__".
>
> If an object "o" has "__str_annotations__", set, you can access it and see
> the stringized values.
>
> If you access "o.__annotations__", and the object has
> "o.__str_annotations__" set but "o.__annotations__" is not set, it builds
> (and caches) a new dict by iterating over o.__str_annotations__, calling
> eval() on each value in "o.__str_annotations__".  It gets the globals()
> dict the same way that PEP 649 does (including, if you compile a class with
> str_annotations, it sets __globals__ on the class).  It does *not* unset
> "o.__str_annotations__" unless someone explicitly sets
> "o.__annotations__".  This is so you can write your code assuming that
> "o.__str_annotations__" is set, and it doesn't explode if somebody
> somewhere ever looks at "o.__annotations__".  (This could lead to them
> getting out of sync, if someone modified "o.__annotations__".  But I
> suspect practicality beats purity here.)
>
How would this work with annotations that access a local scope?

def f():
class X: pass
def inner() -> X: pass
return innfer

f().__annotations__

>From your description it sounds like it would fail, just like calling
typing.get_type_hints() would fail on it today.

If so I don't see this as much better than the current situation: all it
does is provide a builtin way of calling get_type_hints().
___
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/SZA3BUYWYVYS45PZT5NS4TOEZH6SLZIP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

[Jelle Zijlstra]

El sáb, 17 abr 2021 a las 8:30, Nick Coghlan ()
escribió:

>
>
> On Fri, 16 Apr 2021, 3:14 pm Larry Hastings,  wrote:
>
>>
>> Anyway I assume it wasn't "fixable".  The compiler would presumably
>> already prefer to generate LOAD_GLOBAL vs LOAD_NAME, because LOAD_GLOBAL
>> would be cheaper every time for a global or builtin.  The fact that it
>> already doesn't do so implies that it can't.
>>
>
> Metaclass __prepare__ methods can inject names into the class namespace
> that the compiler doesn't know about, so yeah, it unfortunately has to be
> conservative and use LOAD_NAME in class level code.
>
> But of course, most metaclasses don't. I wonder if there are cases where
the compiler can statically figure out that there are no metaclass
shenanigans going on, and emit LOAD_GLOBAL anyway. It seems safe at least
when the class has no base classes and no metaclass=.


> 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/IZJYDHWJNMMMICUE32M3O7DGMSMVIOQ3/
> 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/W4LYALS5RMLTGIU5PE5YMF4L3MWL2HXY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: In support of PEP 649

[Jelle Zijlstra]

El vie, 16 abr 2021 a las 21:32, Christopher Barker ()
escribió:

> ...
> dataclasses may be the only part of the stdlib that uses annotations.
>
>
> There's another one, actually: functools.singledispatch, at
https://github.com/python/cpython/blob/3.9/Lib/functools.py#L860. It uses
the annotations on the first argument to an `@register`ed function to
figure out how to dispatch. Currently it uses `typing.get_type_hints` to
get the type. Presumably, this would break with PEP 563 semantics if you
try to create a singledispatch function in a nested namespace.
___
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/BGC5WTYMO5EQBBNNR2YNZRJZHX5O3AH6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Relaxing the annotation syntax

[Jelle Zijlstra]

El vie, 16 abr 2021 a las 10:01, Walter Dörwald ()
escribió:

> On 16 Apr 2021, at 16:59, Guido van Rossum wrote:
>
> If you look deeper, the real complaints are all about the backwards
> incompatibility when it comes to locally-scoped types in annotations. I.e.
>
> def test():
> class C: ...
> def func(arg: C): ...
> return func
>
> typing.get_type_hints(test()) # raises NameError: name 'C' is not defined
>
> Can't this be solved by wrapping the annotation in a lambda, i.e.
>
> >>> def test():
> ...   class C: ...
> ...   def func(arg: lambda: C): ...
> ...   return func
> ...
> >>> test().__annotations__['arg']()
> .C'>
>
> So typing.get_type_hints() would simply call an annotation if the
> annotation was callable and replace it with the result of the call.
>
That sort of thing can work, but just like string annotations it's not good
for usability. Users using annotations will have to remember that in some
contexts they need to wrap their annotation in a lambda, and unless they
have a good understanding of how type annotations work under the hood, it
will feel like a set of arbitrary rules. That's what I like about PEP 649:
code like this would (hopefully!) just work without needing users to
remember to use any special syntax.
___
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/V6NQ7ZOPV5BCZ3NGZXT36WVDGJKZQS47/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP-0467: Minor API improvements for binary sequences

[Jelle Zijlstra]

Thanks for this PEP! Most of these proposals would make for useful
improvements to the language. I have a few pieces of feedback below.

El mar, 13 abr 2021 a las 14:14, Ethan Furman ()
escribió:

> This PEP has been deferred until Python 3.9 at the earliest, as the open
>
This should be 3.10 at least (and even that is pushing it by now).


>
> While this does create some duplication, there are valid reasons for it:
>
> * the ``bchr`` builtin is to recreate the ``ord``/``chr``/``unichr`` trio
> from
>Python 2 under a different naming scheme (however, see the Open
> Questions
>section below)
> * the class method is mainly for the ``bytearray.fromord`` case, with
>``bytes.fromord`` added for consistency
>
>
> I don't see an "Open questions" section in this email (only an "Open
issues" section talking about memoryview).

I don't find the argument for a builtin very persuasive. Why is it
important to recreate the Python 2 trio? `bchr` is a more obscure name than
`bytes.fromord`. `bytes.fromord` is already short and doesn't require an
import, so we don't gain that much from the separate builtin.
___
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/V7O7RGOL2QT73VZJFMPVZAAIZUKXZW72/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Status of PEP 649 -- Deferred Evaluation Of Annotations Using Descriptors

[Jelle Zijlstra]

El sáb, 27 mar 2021 a las 15:37, Guido van Rossum ()
escribió:

> Since my last post on the subject I have pretty much given up on PEP 649
> in favor of what we have in 3.10alpha6 -- annotations are always
> stringified. The two problems brought up by Joseph Perez in particular seem
> too thorny to try and devise a solution for.
>
> Jelle, could you explain why for your use cases PEP 649 is preferred over
> PEP 563?
>
> The static(ish) type checker we use internally,
https://github.com/quora/pyanalyze, relies on the runtime `__annotations__`
object to get types. I also support getting types out of string
annotations, but it would make my life simpler if `__annotations__` worked
like in PEP 649 so I wouldn't have to worry about scoping.

Consider code like this:

def make_function(return_type):
def f() -> return_type:
pass
return f

int_func = make_function(int)

Currently, I can look at int_func.__annotations__ and see that the return
type is int, but with stringified annotations it's just "return_type" and I
have no way to get int out.

Now, PEP 649 doesn't actually fix this at the moment, since it still
resolves all annotations in the global scope, but that's easily fixed by
removing the special case in
https://github.com/larryhastings/co_annotations/blob/co_annotations/Python/compile.c#L3815
.


> On Sat, Mar 27, 2021 at 7:35 AM Jelle Zijlstra 
> wrote:
>
>> Hi Larry, I have the same question as Guido last month. I'd really like
>> to see some version of PEP 649 go into 3.10; is there anything I can do to
>> help? I opened https://github.com/larryhastings/co_annotations/issues/1
>> to discuss what seems to be the main problem identified in the previous
>> discussion.
>>
>> El jue, 4 feb 2021 a las 10:59, Guido van Rossum ()
>> escribió:
>>
>>> Breaks are good. Looking forward to the next prototype!
>>>
>>> On Thu, Feb 4, 2021 at 10:45 AM Larry Hastings 
>>> wrote:
>>>
>>>>
>>>> After working on it and stressing out about it for some months, I
>>>> decided to take a break and scratch some other itches.  I'll return to PEP
>>>> 649 soon, and I have every intention of having the PEP done and the
>>>> prototype done well in advance of 3.10b1--worry not.
>>>>
>>>> Thanks for checking in,
>>>>
>>>>
>>>> */arry*
>>>> On 2/4/21 9:17 AM, Guido van Rossum wrote:
>>>>
>>>> Hi Larry,
>>>>
>>>> Can you give us a status update for your PEP 649? I don't recall
>>>> reading anything about it in the past few weeks. I am super excited about
>>>> this solution to the problem (even if there are a few issues to work
>>>> through) and I think it will provide better backwards compatibility than
>>>> the current plan for Python 3.10 (PEP 563, from __future__ import
>>>> annotations, causing all annotations to be stringified).
>>>>
>>>> If we don't get this into 3.10, we'd have a much more complicated
>>>> transition. There are only two more alphas before 3.10b1 gets released! And
>>>> we'd have to get this approved by the Steering Council, which can take a
>>>> few weeks (cut them some slack, they have a big backlog). Fortunately you
>>>> already have an implementation that can be landed quickly once the PEP is
>>>> accepted.
>>>>
>>>> --
>>>> --Guido van Rossum (python.org/~guido)
>>>> *Pronouns: he/him **(why is my pronoun here?)*
>>>> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
>>>>
>>>>
>>>
>>> --
>>> --Guido van Rossum (python.org/~guido)
>>> *Pronouns: he/him **(why is my pronoun here?)*
>>> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
>>> ___
>>> 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/IXIAUVSP62HMLCYY6RMALSETIU2UPIAQ/
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>>
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
>
___
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/IS4H2UVCZ42P4GVH3M2MVFYJHOMJPA4I/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Status of PEP 649 -- Deferred Evaluation Of Annotations Using Descriptors

[Jelle Zijlstra]

Hi Larry, I have the same question as Guido last month. I'd really like to
see some version of PEP 649 go into 3.10; is there anything I can do to
help? I opened https://github.com/larryhastings/co_annotations/issues/1 to
discuss what seems to be the main problem identified in the previous
discussion.

El jue, 4 feb 2021 a las 10:59, Guido van Rossum ()
escribió:

> Breaks are good. Looking forward to the next prototype!
>
> On Thu, Feb 4, 2021 at 10:45 AM Larry Hastings  wrote:
>
>>
>> After working on it and stressing out about it for some months, I decided
>> to take a break and scratch some other itches.  I'll return to PEP 649
>> soon, and I have every intention of having the PEP done and the prototype
>> done well in advance of 3.10b1--worry not.
>>
>> Thanks for checking in,
>>
>>
>> */arry*
>> On 2/4/21 9:17 AM, Guido van Rossum wrote:
>>
>> Hi Larry,
>>
>> Can you give us a status update for your PEP 649? I don't recall reading
>> anything about it in the past few weeks. I am super excited about this
>> solution to the problem (even if there are a few issues to work through)
>> and I think it will provide better backwards compatibility than the current
>> plan for Python 3.10 (PEP 563, from __future__ import annotations, causing
>> all annotations to be stringified).
>>
>> If we don't get this into 3.10, we'd have a much more complicated
>> transition. There are only two more alphas before 3.10b1 gets released! And
>> we'd have to get this approved by the Steering Council, which can take a
>> few weeks (cut them some slack, they have a big backlog). Fortunately you
>> already have an implementation that can be landed quickly once the PEP is
>> accepted.
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>> *Pronouns: he/him **(why is my pronoun here?)*
>> 
>>
>>
>
> --
> --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/IXIAUVSP62HMLCYY6RMALSETIU2UPIAQ/
> 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/G5L3OJMISIB5M3BRCVM6IOHA3HJYAL4E/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: typo in PEP 636

[Jelle Zijlstra]

Submitted a PR to fix it: https://github.com/python/peps/pull/1891. In the
future, feel free to submit a PR directly to the PEP repo for this sort of
minor fix.

El mar, 23 mar 2021 a las 10:22,  escribió:

> Hello,
>
> The GUI section of PEP 636 reads: “It will also requires that the event
> has a position attribute that matches the (x, y) pattern”. It should read
> “It will also require that the event has a position attribute that matches
> the (x, y) pattern”.
>
>
>
> Thanks,
>
> Bill
> ___
> 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/GD27GMRKSAXTIIHKFCQMICEAAUILKNAS/
> 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/LTTTLH64IFRI7G2V6JXXD565C4WBG7FW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [python-committers] Rejecting PEP 637 (Support for indexing with keyword arguments)

[Jelle Zijlstra]

El lun, 15 mar 2021 a las 13:13, Guido van Rossum ()
escribió:

> Let me clarify what the typing-sig folks wanted out of this PEP. We only
> care about adding support for `x[*y]` (including things like `x[a, *b,
> c]`). We'll just update PEP 646 to add that explicitly there and hope that
> PEP 646 fares better than PEP 637.
>
> To fans of PEP 637 I would call out that the main reason for rejection
> seems to be this paragraph:
>
> The benefits of the new syntax as outlined in the PEP are not particularly
>> strong, and community support for the new syntax seems low. The new syntax
>> doesn’t provide an obvious way to do something that is currently
>> error-prone, and doesn’t open up new possibilities that were not possible
>> before. While there are certainly cases that could use the new syntax, for
>> many of them it’s not clear that it would be a win, or that third-party
>> libraries would indeed use the syntax. The Steering Council isn’t really
>> convinced by any of the suggested uses in the PEP.
>>
>
> This seems to imply that in order for a proposal like this to fare better
> in the future, the authors would need to line up support from specific,
> important communities like the scientific, data science or machine learning
> communities. Currently such support seems absent except for one specific
> package (xarray).
>
> Yes, I was surprised to read the focus on typing in the rejection notice
because my recollection from the discussions around PEP 637 was that typing
was not in fact the major motivation, named column indexing was.

Looking at the PEP's motivation section now (
https://www.python.org/dev/peps/pep-0637/#use-cases), two (#2 and #7) are
about typing. #2 ("MyType[T=int]") is rather weak, since "T=int" doesn't
provide any increase in clarity over just "int". #7 (PEP 646) is stronger,
but was tacked on later and doesn't provide much detail.

Among the other use cases, #1 and #3 are quite general. The compelling ones
to me are #4 (pandas), #5 (xarray) and #7 (trio.run and similar functions).
Focusing more on these use cases would have made the PEP's motivation more
similar to matrix multiplication (PEP 465): helping the scientific Python
stack make a construct that's currently awkward more simple.



> --
> --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/MOXRTWGVRDRUMV2FAJ3W4OCWT4CMI5EO/
> 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/F5KGJC4IABWZSRLHUDPJZPMJRW2ONDJJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Jelle Zijlstra]

El mar., 23 jun. 2020 a las 9:10, Guido van Rossum ()
escribió:

> I'm happy to present a new PEP for the python-dev community to review.
> This is joint work with Brandt Bucher, Tobias Kohn, Ivan Levkivskyi and
> Talin.
>
> Thanks to Guido and all the others working on this! It's going to be a
great addition to the language.

One piece of bikeshedding: I agree with the previous posters who said that
the ".x" syntax for referring to variables isn't great, and I'd prefer
marking variables that are being assigned to with a special symbol. So
instead of:

y = 3
case Point(x, .y): ...  # x is assigned to, y is looked up

we'd have

y = 3
case Point($x, y): ...  # x is assigned to, y is looked up

The trouble with the current syntax is that if you forget the ".", you
always get a hard-to-detect bug: your pattern unexpectedly matches and "y"
suddenly has a different value. Even if you find the bug, it's hard to find
out where exactly the mistake happened.

But with the proposed "$" syntax, if you forget the "$", you probably will
just immediately get a NameError that will tell you exactly where your bug
is. (Except of course if you happen to already have the name "x" in scope,
but that's hopefully not very common, and it's already what happens if you
typo a local variable name.)
___
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/MN2B6JOEJ2JTCEPL5YSH3SUMOQS6WSOG/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Jelle Zijlstra]

El jue., 2 abr. 2020 a las 11:19, Guido van Rossum ()
escribió:

> 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.
>
> The current CPython parser usually just produces "SyntaxError: invalid
syntax" for any error, while other languages that I work with usually say
something more precise like 'expected x, got y'. What will the error
messages in the PEG parser look like? Making syntax errors more informative
can be a nice improvement to usability.


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

[Python-Dev] Re: strip behavior provides inconsistent results with certain strings

[Jelle Zijlstra]

El jue., 27 jun. 2019 a las 11:51,  escribió:

> excellent and extraordinarily obvious
>
> Thanks for the pointer.
>
> a bit unfortunate that old docs for a module that doesn't seem to exist in
> py3 with less clear but still correct words is still the top google result
> for python string strip.
>
> https://docs.python.org/2/library/string.html#string.lstrip
>
>  string.lstrip(s[, chars])¶
>
> Return a copy of the string with leading characters removed. If chars
> is omitted or None, whitespace characters are removed. If given and not
> None, chars must be a string; the characters in the string will be stripped
> from the beginning of the string this method is called on.
>
That function actually also behaves like str.lstrip() does in Python 3:

>>> string.lstrip('abcd', 'ba')
'cd'


> ___
> 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/EL26KYH6P6I6KWXKM7DUF46HVGGV6USV/
>
___
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/X6UYUCDH23WIANHVGGVSIO47X624DE2N/

Re: [Python-Dev] 2to3 for python annotations

[Jelle Zijlstra]

2018-07-17 12:37 GMT-07:00 Philippe Fremy :

> Hi,
>
> While contributing to pyannotate, I became familiar enough with 2to3
> fixers to be able to convert Python 2 style annotations to Python 3.
>
> Is it something that would be interesting to put into python 2to3 ? If
> so I would propose a PR for this.
>
> There already a tool that does this:
https://github.com/ilevkivskyi/com2ann.

I am not sure it would be appropriate for 2to3. Type comments still work in
Python 3, and I feel like 2to3 should do the minimum necessary to get
working code in Python 3.


> Cheers,
>
> Philippe
>
> ___
> 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/
> jelle.zijlstra%40gmail.com
>
___
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

Re: [Python-Dev] Question about PEP 484

[Jelle Zijlstra]

2018-07-17 9:55 GMT-07:00 Sebastian Rittau :

> On 17.07.2018 17:05, Guido van Rossum wrote:
>
>> This is a good point. I presume specifying this unambiguously would be a
>> huge amount of work, and it would mostly codify mypy's current behavior. I
>> don't think that's within the scope of PEP 484, but it could well be done
>> as a separate PEP (perhaps an informational one?). I hope you understand
>> that I am not volunteering.
>>
> An informational PEP sounds about right to me. Such a PEP could also
> include style recommendations like those from typeshed's CONTRIBUTING file (
> https://github.com/python/typeshed/blob/master/CONTRIBUTING.md).
>
> I guess I just volunteered to help with such a PEP, although I feel that
> someone from mypy's core team should take the lead on that. And if I
> understood this thread correctly, the pytype team is also willing to help
> out?

I can also help out.

>
>
>  - Sebastian
>
> ___
> 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/jelle.
> zijlstra%40gmail.com
>
___
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

Re: [Python-Dev] Question about PEP 484

[Jelle Zijlstra]

2018-07-16 10:21 GMT-07:00 Adam Cataldo via Python-Dev <
python-dev@python.org>:

>
>
>
>
>
> *Hi Folks,Cc: Rebecca, pytypeThis is Adam Cataldo; I’m the engineering
> manager for the Python team at Google. Rebecca Chen, our lead pytype
> <https://github.com/google/pytype> contributor, and I are interested in
> helping finalize PEP 484 if possible. To that end, we wanted to find out
> what technical issues the PEP 484 authors feel they still need to finalize.
> We also wanted to know how we can help.We have a large Python code base at
> Google, and may be able to use this to help resolve current incomplete
> definitions, by collecting data on how types are used. We also have a
> couple ambiguities that we’d love to get closure on: - One thing we care
> about in particular, given the implementation of pytype, is the detailed
> definition of what goes in a .pyi file. Do folks think this makes sense to
> include as part of PEP 484, or would this be better in a separate PEP? We’d
> love to get your thoughts.*
>

I would be happy to contribute to this if that would be useful for type
checkers like pytype, although like Guido I don't think the current text of
the PEP is ambiguous. Typeshed already has a set of lint rules that limit
what can be put in stub files, but it could be useful to communicate the
exact set of allowed constructs.


>
> * - The relationship between unicode and typing.Text in Python 2 has been
> a recurring source of confusion for our users. Especially since we
> contributed <https://github.com/python/peps/pull/302> to the current state
> of affairs, we’d like to figure out how to establish clarity here.*
>
There has already been a long discussion on the typing issue tracker that
resulted in no consensus for any change to the current recommendation.
Perhaps there is something we can do, but it's not clear to me what that
would be.

>
>
> *Thoughts?Thanks,Adam*
>
>
> ___
> 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/jelle.
> zijlstra%40gmail.com
>
>
___
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

Re: [Python-Dev] PEP 572: Assignment Expressions

[Jelle Zijlstra]

2018-04-20 14:54 GMT-07:00 Mike Miller :

>
> In other words, the with statement would continue to require an as clause
> outside of the parentheses.  A double name binding doesn't seem very useful
> however.
>
> The with statement does not require an as clause.
___
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

Re: [Python-Dev] Use more Argument Clinic Annotations?

[Jelle Zijlstra]

2018-03-25 5:36 GMT-07:00 Dave Halter :

> Hi Python Devs
>
> I recently started testing Jedi with Python 3.7. Some tests broke. I
> realized that one of the things that changed in 3.7 was the use of
> argument clinic in methods like str.replace.
>
> The issue is that the text signature doesn't contain a return annotation.
>
> >>> str.replace.__text_signature__
> '($self, old, new, count=-1, /)
>
>
> In Python < 3.7 there was a `S.replace(old, new[, count]) -> str` at
> the top of the __doc__. T
>
> If the __text_signature__ was `'($self, old, new, count=-1, /) -> str`
> a lot of tools would be able to have the information again.
>
> Is this intentional or was this just forgotten? I'd like to note that
> this information is insanely helpful (at least for Jedi) to pick up
> type information. I really hope this information can make it back into
> 3.7, since it was there in earlier versions.
>
> If you lack don't have time I might have some. Just give me some
> instructions.
>
> Perhaps you should use https://github.com/python/typeshed/ to get type
information?


> ~ Dave
>
>
> PS: Don't get me wrong, I love argument clinic/inspect.signature and
> am generally in favor of using it everywhere. It helps tools like
> jedi, pycharm and others get accurate information about a builtin
> function.
> ___
> 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/
> jelle.zijlstra%40gmail.com
>
___
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

Re: [Python-Dev] inconsistency in annotated assigned targets

[Jelle Zijlstra]

2018-01-25 15:00 GMT-08:00 Joe Jevnik via Python-Dev 
:

> Currently there are many ways to introduce variables in Python; however,
> only a few allow annotations. I was working on a toy language and chose to
> base my syntax on Python's when I noticed that I could not annotate a loop
> iteration variable. For example:
>
> for x: int in range(5):
> ...
>
> This led me to search for other places where new variables are introduced
> and I noticed that the `as` target of a context manager cannot have an
> annotation. In the case of a context manager, it would probably need
> parenthesis to avoid ambiguity with a single-line with statement, for
> example:
>
> with ctx as (variable: annotation): body
>
> Finally, you cannot annotate individual members of a destructuring
> assignment like:
>
> a: int, b: int, c: int = 1, 2, 3
>
> Looking at the grammar, these appear to be `expr` or `exprlist` targets.
> One change may be to allow arbitrary expressions to have an annotation .
> This would be a small change to the grammar but would potentially have a
> large effect on the language or static analysis tools.
>
> I am posting on the mailing list to see if this is a real problem, and if
> so, is it worth investing any time to address it. I would be happy to
> attempt to fix this, but I don't want to start if people don't want the
> change. Also, I apologize if this should have gone to python-idea; this
> feels somewhere between a bug report and implementation question more than
> a new feature so I wasn't sure which list would be more appropriate.
>
I have written a fair amount of code with variable annotations, and I don't
remember ever wanting to add annotations in any of the three contexts you
mention. In practice, variable annotations are usually needed for
class/instance variables and for variables whose type the type checker
can't infer. The types of loop iteration variables and context manager
assignment targets can almost always be inferred trivially.


>
> ___
> 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/
> jelle.zijlstra%40gmail.com
>
>
___
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

Re: [Python-Dev] Tricky way of of creating a generator via a comprehension expression

[Jelle Zijlstra]

2017-11-22 9:58 GMT-08:00 Guido van Rossum :

> Wow, 44 messages in 4 hours. That must be some kind of record.
>
> If/when there's an action item, can someone summarize for me?
>
> The main disagreement seems to be about what this code should do:

g = [(yield i) for i in range(3)]

Currently, this makes `g` into a generator, not a list. Everybody seems to
agree this is nonintuitive and should be changed.

One proposal is to make it so `g` gets assigned a list, and the `yield`
happens in the enclosing scope (so the enclosing function would have to be
a generator). This was the way things worked in Python 2, I believe.

Another proposal is to make this code a syntax error, because it's
confusing either way. (For what it's worth, that would be my preference.)

There is related discussion about the semantics of list comprehensions
versus calling list() on a generator expression, and of async semantics,
but I don't think there's any clear point of action there.


> --
> --Guido van Rossum (python.org/~guido)
>
> ___
> 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/
> jelle.zijlstra%40gmail.com
>
>
___
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

Re: [Python-Dev] PEP 561 rework

[Jelle Zijlstra]

ormation as simple and
> easy as possible, packaging and distribution is done through existing
> frameworks.
>
> Package maintainers who wish to support type checking of their code MUST add
> a ``py.typed`` file to their package supporting typing. This marker is
> recursive, if a top-level package includes it, all sub-packages MUST support
> type checking as well. To have this file installed with the package,
> maintainers can use existing packaging options such as ``package_data`` in
> distutils, shown below.
>
> Distutils option example::
>
> ...
> package_data = {
> 'pkg': ['py.typed'],
> },
> ...
>
> For namespace packages, the ``py.typed`` file should be in the submodules of
> the namespace, to avoid conflicts and for clarity.
>
> Stub Only Packages
> ''''''''''''''''''
>
> For package maintainers wishing to ship stub files containing all of their
> type information, it is preferred that the ``*.pyi`` stubs are alongside the
> corresponding ``*.py`` files. However, the stubs can also be put in a separate
> package and distributed separately. Third parties can also find this method
> useful if they wish to distribute stub files. The name of the stub package
> MUST follow the scheme ``pkg_stubs`` for type stubs for the package named
> ``pkg``. The normal resolution order of checking ``*.pyi`` before ``*.py``
> will be maintained.
>
> This is very minor, but what do you think of using "pkg-stubs" instead of
"pkg_stubs" (using a hyphen rather than an underscore)? This would make the
name illegal to import as a normal Python package, which makes it clear
that it's not a normal package. Also, there could be real packages named
"_stubs".

>
> Third parties seeking to distribute stub files are encouraged to contact the
> maintainer of the package about distribution alongside the package. If the
> maintainer does not wish to maintain or package stub files or type information
> inline, then a third party stub only package can be created.
>
> In addition, stub only distributions SHOULD indicate which version(s)
> of the runtime package are supported by indicating the runtime distribution's
> version(s) through normal dependency data. For example, if there was a
> stub package ``flyingcircus_stubs``, it can indicate the versions of the
> runtime ``Flyingcircus`` distribution supported through ``install_requires``
> in distutils based tools, or the equivalent in other packaging tools.
>
>
> Type Checker Module Resolution Order
> 
>
> The following is the order that type checkers supporting this PEP SHOULD
> resolve modules containing type information:
>
> 1. User code - the files the type checker is running on.
>
> 2. Stubs or Python source manually put in the beginning of the path. Type
>checkers SHOULD provide this to allow the user complete control of which
>stubs to use, and patch broken stubs/inline types from packages.
>
> 3. Stub packages - these packages can supersede the installed packages.
>They can be found at ``pkg_stubs`` for package ``pkg``.
>
> 4. Inline packages - if there is nothing overriding the installed
>package, and it opts into type checking, inline types SHOULD be used.
>
> 5. Typeshed (if used) - Provides the stdlib types and several third party
>libraries.
>
> Type checkers that check a different Python version than the version they run
> on MUST find the type information in the ``site-packages``/``dist-packages``
> of that Python version. This can be queried e.g.
> ``pythonX.Y -c 'import site; print(site.getsitepackages())'``. It is also 
> recommended
> that the type checker allow for the user to point to a particular Python
> binary, in case it is not in the path.
>
>
> Implementation
> ==
>
> The proposed scheme of indicating support for typing is completely backwards
> compatible, and requires no modification to tooling. A sample package with
> inline types is available [typed_pkg]_, as well as a sample package checker
> [pkg_checker]_ which reads the metadata of installed packages and reports on
> their status as either not typed, inline typed, or a stub package.
>
>
> Acknowledgements
> 
>
> This PEP would not have been possible without the ideas, feedback, and support
> of Ivan Levkivskyi, Jelle Zijlstra, Nick Coghlan, Daniel F Moisset, Nathaniel
> Smith, and Guido van Rossum.
>
>
> Version History
> ===
>
> * 2017-11-12
>
> * Rewritten to use existing tooling only
> * No need to indicate kind of type

Re: [Python-Dev] Analog of PEP 448 for dicts (unpacking in assignment with dict rhs)

[Jelle Zijlstra]

2017-11-10 19:53 GMT-08:00 Ben Usman :

> The following works now:
>
> seq = [1, 2]
> d = {'c': 3, 'a': 1, 'b': 2}
>
> (el1, el2) = *seq
> el1, el2 = *seq
> head, *tail = *seq
>
> seq_new = (*seq, *tail)
> dict_new = {**d, **{'c': 4}}
>
> def f(arg1, arg2, a, b, c):
> pass
>
> f(*seq, **d)
>
> It seems like dict unpacking syntax would not be fully coherent with
> list unpacking syntax without something like:
>
> {b, a, **other} = **d
>
> Because iterables have both syntax for function call unpacking and
> "rhs in assignment unpacking" and dict has only function call
> unpacking syntax.
>
> I was not able to find any PEPs that suggest this (search keywords:
> "PEP 445 dicts", "dictionary unpacking assignment", checked PEP-0),
> however, let me know if I am wrong.
>
> It was discussed at great length on Python-ideas about a year ago. There
is a thread called "Unpacking a dict" from May 2016.


> The main use-case, in my understating, is getting shortcuts to
> elements of a dictionary if they are going to be used more then
> ones later in the scope. A made-up example is using a config to
> initiate a bunch of things with many config arguments with long
> names that have overlap in keywords used in initialization.
>
> One should either write long calls like
>
> start_a(config['parameter1'], config['parameter2'],
> config['parameter3'], config['parameter4'])
>
> start_b(config['parameter3'], config['parameter2'],
> config['parameter3'], config['parameter4'])
>
> many times or use a list-comprehension solution mentioned above.
>
> It becomes even worse (in terms of readability) with nested structures.
>
> start_b(config['group2']['parameter3'], config['parameter2'],
> config['parameter3'], config['group2']['parameter3'])
>
>
> ## Rationale
>
> Right now this problem is often solved using [list] comprehensions,
> but this is somewhat verbose:
>
> a, b = (d[k] for k in ['a', 'b'])
>
> or direct per-instance assignment (looks simple for with
> single-character keys, but often becomes very verbose with
> real-world long key names)
>
> a = d['a']
> b = d['b']
>
> Alternatively one could have a very basic method\function
> get_n() or __getitem__() accepting more then a single argument
>
> a, b = d.get_n('a', 'b')
> a, b = get_n(d, 'a', 'b')
> a, b = d['a', 'b']
>
> All these approaches require verbose double-mentioning of same
> key. It becomes even worse if you have nested structures
> of dictionaries.
>
> ## Concerns and questions:
>
> 0. This is the most troubling part,  imho, other questions
> are more like common thoughts. It seems (to put it mildly)
> weird that execution flow depends on names of local variables.
>
> For example, one can not easily refactor these variable names. However,
> same is true for dictionary keys anyway: you can not suddenly decide
> and refactor your code to expect dictionaries with keys 'c' and
> 'd' whereas your entire system still expects you to use dictionaries
> with keys 'a' and 'b'. A counter-objection is that this specific
> scenario is usually handled with record\struct-like classes  with
> fixed members rather then dicts, so this is not an issue.
>
> Quite a few languages (closure and javascript to name a few) seem
> to have this feature now and it seems like they did not suffer too
> much from refactoring hell. This does not mean that their approach
> is good, just that it is "manageable".
>
> 1. This line seems coherent with sequence syntax, but redundant:
> {b, a, **other} = **d
>
> and the following use of "throwaway" variable just looks poor visually
> {b, a, **_} = **d
>
> could it be less verbose like this
> {b, a} = **d
>
> but it is not very coherent with lists behavior.
>
> E.g. what if that line did not raise something like "ValueError:
> Too many keys to unpack, got an unexpected keyword argument 'c'".
>
> 2. Unpacking in other contexts
>
> {self.a, b, **other} = **d
>
> should it be interpreted as
> self.a, b = d['a'], d['b']
>
> or
>
> self.a, b = d['self.a'], d['b']
>
> probably the first, but what I am saying is that these name-extracting
> rules should be strictly specified and it might not be trivial.
>
> ---
> Ben
>
> ___
> 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/
> jelle.zijlstra%40gmail.com
>
>
___
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

Re: [Python-Dev] PEP 484: difference between tuple and ()

[Jelle Zijlstra]

2017-11-08 14:01 GMT-08:00 Jean-Patrick Francoia <
jeanpatrick.franc...@gmail.com>:

> This is my first post on this list, so please don't kill me if I ask it in
> the wrong place, or if the question is stupid.
>
>
> I asked this question on Stack Overflow already:
>
> https://stackoverflow.com/questions/47163048/python-
> annotations-difference-between-tuple-and
>
>
> In very short, which form is correct ?
>
>
> def func() -> Tuple[int, int]
>
>
>
> But this requires to import the typing module.
>
>
> Or this (doesn't crash):
>
>
> def func() -> (int, int):
>
>
> The former is correct. Type checkers should reject the second one. But
because type checking in Python is through static analysis, either will
work at runtime—you need to run a separate static analysis tool like mypy
or pytype to find type errors in your code.

Also, python-dev is a mailing list for the development of Python, not for
questions about Python. The Gitter chatroom at
https://gitter.im/python/typing and the typing issue tracker at
https://github.com/python/typing are better places for questions about
typing in Python.

> ___
> 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/
> jelle.zijlstra%40gmail.com
>
>
___
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

Re: [Python-Dev] Reminder: 12 weeks to 3.7 feature code cutoff

[Jelle Zijlstra]

2017-11-03 16:44 GMT-07:00 Joao S. O. Bueno :

> This just popped up in Brython's issue tracker discussion:
>
> """
> Pierre Quentel 
>
> 04:57 (16 hours ago)
> to brython-dev/br., Subscribed
>
> I think it's better to rename all occurences of async now, although
> it's strange that :
>
> there is currently no deprecation warning in CPython with code that
> uses it as a variable name, PEP492 said that "async and await names
> will be softly deprecated in CPython 3.5 and 3.6"
> there is no mention of async and await becoming keywords in What's new
> in Python 3.7
>
> Maybe the idea was finally given up, but I can't find a reference.
>
> """
>
> So, what is the status of promoting async and await to full keyword for
> 3.7?
>
> This was implemented, and it's in NEWS:
https://github.com/python/cpython/pull/1669.

>
> On 1 November 2017 at 19:47, Ned Deily  wrote:
> > Happy belated Halloween to those who celebrate it; I hope it wasn't too
> scary!  Also possibly scary: we have just a little over 12 weeks remaining
> until Python 3.7's feature code cutoff, 2018-01-29.  Those 12 weeks include
> a number of traditional holidays around the world so, if you are planning
> on writing another PEP for 3.7 or working on getting an existing one
> approved or getting feature code reviewed, please plan accordingly.
> If you have something in the pipeline, please either let me know or, when
> implemented, add the feature to PEP 537, the 3.7 Release Schedule PEP.  As
> you may recall, the release schedule calls for 4 alpha preview releases
> prior to the feature code cutoff with the first beta release.  We have
> already produced the first two alphas.  Reviewing the schedule recently, I
> realized that I had "front-loaded" the alphas, leaving a bigger gap between
> the final alphas and the first beta.  So I have adjusted the schedule a
> bit, pushing alpha 3 and 4 out.  The new
>   d
> >  ates are:
> >
> > - 3.7.0 alpha 3: 2017-11-27 (was 2017-11-13)
> > - 3.7.0 alpha 4: 2018-01-08 (was 2017-12-18)
> > - 3.7.0 beta 1:  2018-01-29 (feature freeze - unchanged)
> >
> > I hope the new dates give you a little bit more time to get your bits
> finished and get a little bit of exposure prior to the feature freeze.
> >
> > Considering how quickly and positively it has been adopted, 3.6 is going
> to be a tough act to follow.  But we can do it again.  Thank you all for
> your ongoing efforts!
> >
> > --Ned
> >
> > --
> >   Ned Deily
> >   n...@python.org -- []
> >
> > ___
> > 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/
> jsbueno%40python.org.br
> ___
> 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/
> jelle.zijlstra%40gmail.com
>
___
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

Re: [Python-Dev] Remove typing from the stdlib (was: Reminder: 12 weeks to 3.7 feature code cutoff)

[Jelle Zijlstra]

2017-11-03 10:46 GMT-07:00 Brett Cannon :

>
>
> On Fri, 3 Nov 2017 at 08:09 Paul Moore  wrote:
>
>> On 3 November 2017 at 14:50, Serhiy Storchaka 
>> wrote:
>> > 03.11.17 16:36, Guido van Rossum пише:
>> >> Maybe we should remove typing from the stdlib?
>> >> https://github.com/python/typing/issues/495
>> >
>> > I didn't use typing, but AFAIK the most used feature from typing is
>> > NamedTuple. If move NamedTuple and maybe other convenient classes not
>> > directly related to typing into collections or types modules, I think
>> > removing typing from the stdlib will less stress people.
>>
>> (Checks docs) Hmm, I'd missed that this was even in there.
>>
>> Regardless of what happens with the typing module, I think this should
>> be moved. I expect there are many people who never looked at the docs
>> of the typing module because they don't use type annotations. I know
>> the class uses type annotations to define its attributes, but I don't
>> see that as an issue. Data classes do the same, and they won't be in
>> the typing module...
>>
>
> There is another option and that's splitting up the typing module into
> core, abstract things, and then the stuff that is about concrete types. For
> instance, ClassVar, Union, and cast() are all abstract concepts that are
> basic to type hints. But things like Mapping are more concrete and not a
> fundamental concept to type hints. You could argue that the fundamentals
> that won't change could stay in the stdlib while the concrete type classes
> could get pulled out so they can be managed more easily/quickly.
>

I don't think the fundamentals are less likely to change—if anything, it
may be the opposite. Many of the potential innovations we'd want to add to
typing (Protocols, literal types, intersection types) are fundamental to
the type system, and things like Mapping actually don't change very often.


>
> ___
> 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/
> jelle.zijlstra%40gmail.com
>
>
___
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

Re: [Python-Dev] how/where is open() implemented ?

[Jelle Zijlstra]

2017-10-05 19:19 GMT-07:00 Yubin Ruan :

> Hi,
> I am looking for the implementation of open() in the src, but so far I
> am not able to do this.
>
> In Python 3, builtins.open is the same as io.open, which is implemented in
the _io_open function in Modules/_io/_iomodule.c.


> From my observation, the implementation of open() in python2/3 does
> not employ the open(2) system call. However without open(2) how can
> one possibly obtain a file descriptor?
>
There is a call to open() (the C function) in _io_FileIO___init___impl in
Modules/_io/fileio.c. I haven't traced through all the code, but I suspect
builtins.open ends up calling that.

>
> Yubin
> ___
> 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/
> jelle.zijlstra%40gmail.com
>
___
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

Re: [Python-Dev] To reduce Python "application" startup time

[Jelle Zijlstra]

2017-09-05 6:02 GMT-07:00 INADA Naoki :

> Hi,
>
> While I can't attend to sprint, I saw etherpad and I found
> Neil Schemenauer and Eric Snow will work on startup time.
>
> I want to share my current knowledge about startup time.
>
> For bare (e.g. `python -c pass`) startup time,  I'm waiting C
> implementation of ABC.
>
> But application startup time is more important.  And we can improve
> them with optimize importing common stdlib.
>
> Current `python -v` is not useful to optimize import.
> So I use this patch to profile import time.
> https://gist.github.com/methane/e688bb31a23bcc437defcea4b815b1eb
>
> With this profile, I tried optimize `python -c 'import asyncio'`, logging
> and http.client.
>
> https://gist.github.com/methane/1ab97181e74a33592314c7619bf342
> 33#file-0-optimize-import-patch
>
> This patch moves a few imports inside functions. I wonder whether that
kind of change actually helps with real applications—doesn't any real
application end up importing the socket module anyway at some point?


> With this small patch:
>
> logging: 14.9ms -> 12.9ms
> asyncio: 62.1ms -> 58.2ms
> http.client: 43.8ms -> 36.1ms
>
> I haven't created pull request yet.
> (Can I create without issue, as trivial patch?)
>
> I'm very busy these days, maybe until December.
> But I hope this report helps people working on optimizing startup time.
>
> Regards,
>
> INADA Naoki  
> ___
> 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/
> jelle.zijlstra%40gmail.com
>
___
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

Re: [Python-Dev] Inplace operations for PyLong objects

[Jelle Zijlstra]

2017-09-01 13:05 GMT-07:00 Chris Barker :

> On Thu, Aug 31, 2017 at 5:12 PM, Antoine Pitrou 
> wrote:
>
>> I'm skeptical there are some programs out there that are limited by the
>> speed of PyLong inplace additions.
>>
>
> indeed, but that could be said about any number of operations.
>
> My question is -- how can the interpreter know if it can alter what is
> supposed to be an immutable in-place? If it's used only internally to a
> function, the it would be safe, but how to know that?
>
I believe Catalin's implementation checks if the object's refcount is 1. If
that is the case, it is safe to mutate it.

>
> -CHB
>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> chris.bar...@noaa.gov
>
> ___
> 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/
> jelle.zijlstra%40gmail.com
>
>
___
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

Re: [Python-Dev] __signature__ for PySide ready

[Jelle Zijlstra]

2017-08-18 18:20 GMT+02:00 Yury Selivanov :

> Hi Christian,
>
> On Fri, Aug 18, 2017 at 4:41 AM, Christian Tismer 
> wrote:
> > Hi friends,
> >
> > in the last months, I have developed signature support for
> > PySide. The module creates the same signatures as are known
> > for plain Python functions.
> >
> > As a non-trivial addition, the module also handles multiple
> > signatures as a list. I consider this extension to PySide
> > as quite essential and actually more important as for Python
> > itself, because type info is rather crucial for PySide.
> >
> > Initially, I wrote this as a pure Python 3 extension.
> > Then I was "asked" to port this to Python 2 too, which was
> > quite hairy to do. I'm not sure if I should have done that.
> >
> > Before I publish this module, I want to ask:
> > 
> >
> > Is it a bad idea to support signatures in Python 2 as well?
>
> There's a backport of signature API to Python 2.  Although last time I
> checked it was fairly outdated.
>
> I wrote a backport earlier this year:
https://pypi.python.org/pypi/inspect2.


> > Do I introduce a feature that should not exist in Python 2?
> > Or is it fine to do so?
> >
> > Please let me know your opinion, I am happy with any result.
> ___
> 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/
> jelle.zijlstra%40gmail.com
>
___
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

Re: [Python-Dev] Impact of Namedtuple on startup time

[Jelle Zijlstra]

2017-07-17 9:45 GMT-07:00 Steven D'Aprano :

> On Mon, Jul 17, 2017 at 02:43:19PM +0200, Antoine Pitrou wrote:
> >
> > Hello,
> >
> > Cost of creating a namedtuple has been identified as a contributor to
> > Python startup time.  Not only Python core and the stdlib, but any
> > third-party library creating namedtuple classes (there are many of
> > them).  An issue was created for this:
> > https://bugs.python.org/issue28638
>
> Some time ago, I needed to backport a version of namedtuple to Python
> 2.4, so I started with Raymond's recipe on Activestate and modified it
> to only exec the code needed for __new__. The rest of the class is an
> ordinary inner class:
>
> # a short sketch
> def namedtuple(...):
> class Inner(tuple):
> ...
> exec(source, ns)
> Inner.__new__ = ns['__new__']
> return Inner
>
>
> Here's my fork of Raymond's recipe:
>
> https://code.activestate.com/recipes/578918-yet-another-namedtuple/
>
>
> Out of curiosity, I took that recipe, updated it to work in Python 3,
> and compared it to the std lib version. Here are some representative
> timings:
>
> [steve@ando ~]$ python3.5 -m timeit -s "from collections import
> namedtuple" "K = namedtuple('K', 'a b c')"
> 1000 loops, best of 3: 1.02 msec per loop
>
> [steve@ando ~]$ python3.5 -m timeit -s "from nt3 import namedtuple" "K =
> namedtuple('K', 'a b c')"
> 1000 loops, best of 3: 255 usec per loop
>
>
> I think that proves that this approach is viable and can lead to a big
> speed up.
>
> I have an open pull request implementing this approach:
https://github.com/python/cpython/pull/2736. We can discuss the exact form
the code should take there (Ivan already added some good suggestions).


> I don't think that merely dropping the _source attribute will save much
> time. It might save a bit of memory, but in my experiements dropping it
> only saves about 10µs more. I think the real bottleneck is the cost of
> exec'ing the entire class.
>
>
>
> --
> Steve
> ___
> 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/
> jelle.zijlstra%40gmail.com
>
___
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

Re: [Python-Dev] PEP 544: Protocols - second round

[Jelle Zijlstra]

2017-05-25 7:19 GMT-07:00 Nick Coghlan :

> On 25 May 2017 at 21:26, Antoine Pitrou  wrote:
> > On Wed, 24 May 2017 23:31:47 +0200
> > Ivan Levkivskyi  wrote:
> >
> >> Hi all,
> >>
> >> After collecting suggestions in the previous discussion on python-dev
> >> https://mail.python.org/pipermail/python-dev/2017-
> March/thread.html#147629
> >> and playing with implementation, here is an updated version of PEP 544.
> >>
> >> --
> >> Ivan
> >>
> >>
> >> A link for those who don't like reading long e-mails:
> >> https://www.python.org/dev/peps/pep-0544/
> >>
> >> =
> >>
> >> PEP: 544
> >> Title: Protocols
> >
> > Can you give this PEP a more explicit title? "Protocols" sound like
> > network protocols to me.
>
> Especially given the existing use of the term in an asyncio context:
> https://www.python.org/dev/peps/pep-3156/#transports-and-protocols
>
> Given the abstract, I'd suggest "Structural Subtyping" as a suitable
> title for the PEP.
>
> That said, I think it's fine to use "protocol" throughout the rest of
> the PEP as is currently the case - object protocols and network
> protocols are clearly different things, it's just the bare word
> "Protocols" appearing as a PEP title in the PEP index with no other
> context that's potentially confusing.
>
> I'm +1 on the general idea of the PEP, and only have one question
> regarding the specifics. Given:
>
> import typing
>
> class MyContainer:
> def __len__(self) -> int:
> ...
> def close(self) -> None:
> ...
>
> Would that be enough for a static typechecker to consider MyContainer
> a structural subtype of both typing.Sized and SupportsClose from the
> PEP, even though neither is imported explicitly into the module? I'm
> assuming the answer is "Yes", but I didn't see it explicitly stated
> anywhere.
>
> Yes, that should be the case. Specifically, if you pass a MyContainer
object to a function whose argument is annotated as typing.Sized or
SupportsClose, a type checker should accept that call.


> Cheers,
> Nick.
>
>
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> 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/
> jelle.zijlstra%40gmail.com
>
___
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

Re: [Python-Dev] Await and Async keywords

[Jelle Zijlstra]

2017-03-24 3:57 GMT-07:00 Aymeric Fromherz :

> Hi,
>
> I'm currently looking into how Python3 is parsed, and I'm wondering why
> await and async aren't considered as keywords? Are there programs
> actually using await and async as variable names? Is there another
> behaviour where it is interesting to use async for something different?
>
> They are not keywords to prevent breaking backwards compatibility, but
they will be full keywords in 3.7. async/await was introduced in 3.5, and
Python generally avoids introducing backwards-incompatible in minor
versions. Usually, that's done with __future__ imports; if I recall
correctly, when "with" statements were introduced (making "with" a
keyword), Python first released one or two versions where you had to do
"from __future__ import with_statement" to use them, and then this flag was
turned on by default. For async/await, instead the parser was hacked to
recognize "async def" as a special token, and to add special parsing rules
within "async def" function to recognize other uses of async and await.
However, this is temporary and async and await will be full keywords in
Python 3.7. See https://www.python.org/dev/peps/pep-0492/#transition-plan.

And yes, real code uses async and await as identifiers. asyncio itself had
a function called asyncio.async() (now renamed to ensure_future()). Making
async and await full keywords would have immediately broken any such code
for people who were upgrading to Python 3.5.



> Cheers,
> Aymeric
> ___
> 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/
> jelle.zijlstra%40gmail.com
>
___
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

Re: [Python-Dev] API design: where to add async variants of existing stdlib APIs?

[Jelle Zijlstra]

2017-03-07 10:15 GMT-08:00 Ethan Furman :

> On 03/07/2017 09:41 AM, Brett Cannon wrote:
>
> I don't think a common practice has bubbled up yet for when there's both
>> synchronous and asynchronous versions of an API
>> (closest I have seen is appending an "a" to the async version but that
>> just looks like a spelling mistake to me most of
>> the time). This is why the question of whether separate modules are a
>> better idea is coming up.
>>
>
> I'm undoubtedly going to show my ignorance with this question, but is it
> feasible to have both sync and async support in the same object?
>
> It's possible, but it quickly gets awkward and will require a lot of code
duplication. For example, we could make @contextmanager work for async
functions by making the _GeneratorContextManager class implement both
enter/exit and aenter/aexit, but then you'd get an obscure error if you
used with on an async contextmanager or async with on a non-async
contextmanager.


> --
> ~Ethan~
>
> ___
> 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/jelle.
> zijlstra%40gmail.com
>
___
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

Re: [Python-Dev] GitHub migration scheduled for Friday

[Jelle Zijlstra]

2017-02-07 10:03 GMT-08:00 Brett Cannon :

> To let the non-core devs know, the GitHub migration will be happening this
> Friday. For those of you who use the current GitHub mirror to create
> patches, do be aware that the hashes will most likely be changing so don't
> expect your checkout to work past Thursday (you can always generate a patch
> and apply it to a fresh checkout). Otherwise https://cpython-
> devguide.readthedocs.io/en/github/ is what the devguide will become on
> Friday if you want to read now instead of waiting for the official
> switch-over (although for non-core devs the migration basically means you
> can use GitHub to submit changes instead of uploading patches).
>
> This is great, I'm looking forward to being able to submit pull requests
to CPython. Thanks Brett and others for all your hard work on this!

> ___
> 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/
> jelle.zijlstra%40gmail.com
>
>
___
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

Re: [Python-Dev] Deprecate `from __future__ import unicode_literals`?

[Jelle Zijlstra]

I've actually found unicode_literals useful in getting code to be Python
2/3-compatible. I try to use a Python 3-like model of always using unicode
for text data and only using str for binary data, and unicode_literals
helps achieve that, since most string literals are meant to be text, not
binary data. The issue with functions like getattr is annoying, but in my
experience it's not a common problem (I don't often call getattr() with a
string literal as an argument).

2016-12-16 14:56 GMT-08:00 Raymond Hettinger :

>
> > On Dec 16, 2016, at 11:24 AM, Guido van Rossum  wrote:
> >
> > I am beginning to think that `from __future__ import unicode_literals`
> does more harm than good. I don't recall exactly why we introduced it, but
> with the restoration of u"" literals in Python 3.3 we have a much better
> story for writing straddling code that is unicode-correct.
> >
> > The problem is that the future import does both too much and not enough
> -- it does too much because it changes literals to unicode even in contexts
> where there is no benefit (e.g. the argument to getattr() -- I still hear
> of code that breaks due to this occasionally) and at the same time it
> doesn't do anything for strings that you read from files, receive from the
> network, or even from other files that don't use the future import.
> >
> > I wonder if we can add an official note to the 2.7 docs recommending
> against it? (And maybe even to the 3.x docs if it's mentioned there at all.)
>
> +1  Leaving it in place will likely cause more problems than it solves, so
> I think your suggest is a net win even if there is some bit of disruption.
> Also, as far as I can tell, the adoption rate of Python 3.2 was very low.
> Python 3's story didn't become attractive until later.
>
>
> Raymond
> ___
> 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/
> jelle.zijlstra%40gmail.com
>
___
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

Re: [Python-Dev] [Python-checkins] cpython (3.5): Fix os.urandom() using getrandom() on Linux

[Jelle Zijlstra]

I think this is an issue unrelated to the big discussion from a little
while ago. The problem isn't that os.urandom() uses getrandom(), it's that
it calls it in a mode that may block.

2016-06-14 8:07 GMT-07:00 Steven D'Aprano :

> Is this right? I thought we had decided that os.urandom should *not*
> fall back on getrandom on Linux?
>
>
>
> On Tue, Jun 14, 2016 at 02:36:27PM +, victor. stinner wrote:
> > https://hg.python.org/cpython/rev/e028e86a5b73
> > changeset:   102033:e028e86a5b73
> > branch:  3.5
> > parent:  102031:a36238de31ae
> > user:Victor Stinner 
> > date:Tue Jun 14 16:31:35 2016 +0200
> > summary:
> >   Fix os.urandom() using getrandom() on Linux
> >
> > Issue #27278: Fix os.urandom() implementation using getrandom() on Linux.
> > Truncate size to INT_MAX and loop until we collected enough random bytes,
> > instead of casting a directly Py_ssize_t to int.
> >
> > files:
> >   Misc/NEWS   |  4 
> >   Python/random.c |  2 +-
> >   2 files changed, 5 insertions(+), 1 deletions(-)
> >
> >
> > diff --git a/Misc/NEWS b/Misc/NEWS
> > --- a/Misc/NEWS
> > +++ b/Misc/NEWS
> > @@ -13,6 +13,10 @@
> >  Library
> >  ---
> >
> > +- Issue #27278: Fix os.urandom() implementation using getrandom() on
> Linux.
> > +  Truncate size to INT_MAX and loop until we collected enough random
> bytes,
> > +  instead of casting a directly Py_ssize_t to int.
> > +
> >  - Issue #26386: Fixed ttk.TreeView selection operations with item id's
> >containing spaces.
> >
> > diff --git a/Python/random.c b/Python/random.c
> > --- a/Python/random.c
> > +++ b/Python/random.c
> > @@ -143,7 +143,7 @@
> > to 1024 bytes */
> >  n = Py_MIN(size, 1024);
> >  #else
> > -n = size;
> > +n = Py_MIN(size, INT_MAX);
> >  #endif
> >
> >  errno = 0;
> >
> > --
> > Repository URL: https://hg.python.org/cpython
>
> > ___
> > Python-checkins mailing list
> > python-check...@python.org
> > https://mail.python.org/mailman/listinfo/python-checkins
>
> ___
> 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/jelle.zijlstra%40gmail.com
>
___
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

Re: [Python-Dev] Adding NewType() to PEP 484

[Jelle Zijlstra]

2016-05-27 16:01 GMT-07:00 Guido van Rossum :

> Also -- the most important thing. :-) What to call these things? We're
> pretty much settled on the semantics and how to create them (A =
> NewType('A', int)) but what should we call types like A when we're
> talking about them? "New types" sounds awkward.
>

For what it's worth, Haskell uses the term "newtype" for a very similar
concept (https://wiki.haskell.org/Newtype), so maybe Python should follow
suit in the interest of not creating new confusing terminology.

"Dependent type" (proposed by a few people) already means something else (
https://en.wikipedia.org/wiki/Dependent_type), so it doesn't seem like a
good choice here.

>
> On Fri, May 27, 2016 at 12:54 PM, Guido van Rossum 
> wrote:
> > Sorry, this is more meant to be the start of a discussion about the
> proposed
> > feature. And typing.py has its own upstream repo (like asyncio).
> >
> > --Guido (mobile)
> >
> > On May 27, 2016 12:52 PM, "Brett Cannon"  wrote:
> >>
> >> Patches to Python's stdlib should go through bugs.python.org so it
> isn't
> >> lost in email.
> >>
> >>
> >> On Fri, May 27, 2016, 12:00 Ivan Levkivskyi 
> wrote:
> >>>
> >>> Hi,
> >>>
> >>> It has been proposed to enhance the typing module with a NewType
> function
> >>> that allows to define simple unique types with almost zero runtime
> >>> overhead.
> >>>
> >>> The PR containing actual implementation and PEP 484 update is here:
> >>> https://github.com/python/typing/pull/226
> >>>
> >>> Review comments are very welcome.
> >>>
> >>> Best regards,
> >>> Ivan
> >>> ___
> >>> 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/brett%40python.org
> >>
> >>
> >> ___
> >> 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/guido%40python.org
> >>
> >
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> ___
> 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/jelle.zijlstra%40gmail.com
>
___
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