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

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

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

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

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

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

[Python-Dev] Re: Python grammar test cases

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+ '/' ',' > |

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

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

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

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

[Python-Dev] Re: Proposal to deprecate mailcap

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: >

[Python-Dev] Re: Proposal to deprecate mailcap

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

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

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

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

[Python-Dev] Re: Relaxing the annotation syntax

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

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

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

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

otations 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 G

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

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

[Python-Dev] Re: typo in PEP 636

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

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

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

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

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

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

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: > >

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

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.

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

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

Re: [Python-Dev] Question about PEP 484

tly, 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 >

Re: [Python-Dev] Question about PEP 484

ev 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

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

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.

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

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

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

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

Re: [Python-Dev] PEP 561 rework

he 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

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

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 >

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

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: > >

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

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

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

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

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

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.

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

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`)

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

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

Re: [Python-Dev] __signature__ for PySide ready

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

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

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 >

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

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

Re: [Python-Dev] Await and Async keywords

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 >

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

g > 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

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

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

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

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

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

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

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