Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?

est regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options

Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?

s Perl 6 > example? If they ever do, please make them not follow the Perl 6 example! -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev ___ Python-Dev mailing list [email protected] https://mail.

Re: [Python-Dev] Keyword-only parameters

If you’re introducing a new parameter that is a boolean, making it kw-only is generally accepted. Some people (myself included) would encourage you to do so. Besides asyncio, there are already new arguments that are kw-only in many modules, including configparser, unittest, xml.etree, xmlrpc, ur

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

of PEP 484 but from my perspective it’s not type annotations that are ugly, it’s the stubs. The annotation syntax might be improved for future releases. Stubs - by design - will always be inferior because of the reasons stated above. -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

ity to use stub > (or hint) files. We might have not chosen the wording that makes this obvious to you but we definitely did consider all of the points you’re referring to: https://www.python.org/dev/peps/pep-0484/#stub-files -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twit

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

> On Apr 21, 2015, at 11:23 AM, Guido van Rossum wrote:> > 2. Clearly, great thought has been put into this PEP. If anyone has a good > analysis of the potential impact on Python 3 adoption, please do pass along. > I would be interested in reading the information.> > I wish I had a crystal

Re: [Python-Dev] Committing into which branches?

branch. The mark on the website simply tells you that this is the newest commit on default. Otherwise it’s, well, default. -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev___ Python-Dev mailing list

Re: [Python-Dev] PEP 3152 and yield from Future()

le. None of the existing async/await implementations in other languages force you to write stuff like this. -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev___ Python-Dev mailing list Python-Dev@p

Re: [Python-Dev] async/await in Python; v2

add__ vs __radd__ vs __add__, __ior__ vs __ror__ vs __or__, etc.? -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman

Re: [Python-Dev] async/await in Python; v2

ptimize for some unproven backwards compatibility with tools, we’re sacrificing better readability of "async def foo()" - if that tool wants to work with Python 3.5, it’ll still have to support "await" so we’re going to be incompatible anyway; let alone "async for" and "async with" So all in a

Re: [Python-Dev] PEP 492 vs. PEP 3152, new round

raise StopIteration return self.buffer.popleft() So, the same way we added wrapping in RuntimeErrors for generators in PEP 479, we might add transparent wrapping in a _StopAsyncIteration for CO_COROUTINE. > 7. compatibility wit

Re: [Python-Dev] PEP 492 vs. PEP 3152, new round

as already been rejected in the "No implicit wrapping in Futures" section of the PEP. PEP 492 manages to solve all issues without introducing a built-in Future. -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC:

[Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

PEP 572 caused a strong emotional reaction in me. I wanted to first understand my intuitive objection to the idea before posting anything. I feel that (name := expression) doesn't fit the narrative of PEP 20. It doesn't remove complexity, it only moves it. What was its own assignment before now is

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

> On 25 Apr, 2018, at 1:28 PM, Guido van Rossum wrote:> > You don't seem to grasp the usability improvements this will give. I hear you > but at this point appeals to Python's "Zen" don't help you. This reads dismissive to me. I did read the PEP and followed the discussion on python-dev. I re

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

> On 25 Apr, 2018, at 1:24 PM, Chris Angelico wrote: > > On Thu, Apr 26, 2018 at 6:21 AM, Łukasz Langa wrote: >> := also goes against having one obvious way to do it. Since it's an >> expression, >> it can also be placed on its own line or in otherwise we

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

> On 25 Apr, 2018, at 5:20 PM, Chris Angelico wrote:> > On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivanov> wrote:>> Just yesterday this snippet was used on python-dev to show how great the>> new syntax is:>> >> my_func(arg, buffer=(buf := [None]*get_size()), size=len(buf))>> >>

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Uncle T]> One language feature conspicuous by absence in newbie> confusions was, consistently, assignment expressions. Read any book> or tutorial for such a language, and you'll find very little space> devoted to them too. Well, you have an entire code style built around this feature called

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

> On Apr 25, 2018, at 11:10 PM, Steven D'Aprano wrote:> Criticising binding- > expressions for that reason, especially implying that we must always use > parens, is simply FUD. The PEP has more examples with parentheses than without.>> As soon as we have to wrap a part of an expression in p

Re: [Python-Dev] Yearly PyPI breakage

Why don’t you just *host* the files on PyPI?> On May 3, 2016, at 12:06 PM, Stefan Krah wrote:> > > Hello,> > Could someone enlighten me which hoops I have to jump through> this year in order to keep pip downloads working?> > Collecting cdecimal> Could not find a version that satisfies

Re: [Python-Dev] Yearly PyPI breakage

> On May 3, 2016, at 1:42 PM, Stefan Krah wrote:> > I don't fully understand your explanation. Judging by the link that> Donald posted (thanks!) it seems that PEP 470 introduced extra work> for him that would not have been present had things been left in place. IIRC the PyPI maintainers were

[Python-Dev] PyGC_Collect ignores state of `enabled`

Is this deliberate? Could we change it for 3.6 so PyGC_Collect does take `enabled` into account? Context: we’re experimenting with disabling the gc entirely for some workloads because it doesn’t fare too well with Copy-on-Write on Linux. What ends up happening is that disabling the gc actually

Re: [Python-Dev] PEP 492: __aiter__ should return async iterator directly instead of awaitable

On Jun 6, 2016, at 12:23 PM, Yury Selivanov wrote:> > However, with the current PEP 492 design, the above code would be invalid! > The interpreter expects __aiter__ to return a coroutine, not an async > generator.> Yes, I remember asking about the reason behind __aiter__ being an awaitable

Re: [Python-Dev] static typing of input arguments in signatures (was: Language Summit notes)

honic and not overwhelming. Don't worry before you get your hands on the draft, though. -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev ___ Python-Dev mailing list [email protected] https://m

Re: [Python-Dev] List vs Tuple / Homogeneous vs Heterogeneous / Mutable vs Immutable

ple because of that "struct" mindset :) -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscr

Re: [Python-Dev] static typing of input arguments in signatures

it was how (badly) it was implemented. `assert obj.__class__ == list` being my favorite one (especially when any iterable would work just fine). -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev ___

Re: [Python-Dev] LDLAST variable in configure.ac

> On 2 Oct 2018, at 12:29, Michael Felt wrote:> > Michael, this message looks encrypted on my end. For people without your public key, it's impossible to read. This was probably unintentional on your end. In either case I'd avoid encrypting messages that go to public mailing lists. - Ł s

Re: [Python-Dev] Petr Viktorin as BDFL-Delegate for PEP 580

> On 3 Oct 2018, at 15:51, INADA Naoki wrote:> > > 2018年10月3日(水) 21:24 Jeroen Demeyer >:> Hello,> > > I am well aware of the current governance issues, but several people> have mentioned that the BDFL-Delegate process can still continue for> now.> > Really?

Re: [Python-Dev] Petr Viktorin as BDFL-Delegate for PEP 580

> On 3 Oct 2018, at 17:06, Łukasz Langa wrote: > > My understand is 🤦🏻‍♂️ ...and no ability to edit to correct it. It's like this forever now, my grand children will ridicule me for this. - Ł signature.asc Description: Message signe

Re: [Python-Dev] Petr Viktorin as BDFL-Delegate for PEP 580

> On 3 Oct 2018, at 23:10, Terry Reedy wrote:> > On 10/3/2018 8:12 AM, Jeroen Demeyer wrote:>> Hello,>> I would like to propose Petr Viktorin as BDFL-Delegate for PEP 580, titled >> "The C call protocol". He has co-authored several PEPs (PEP 394, PEP 489, >> PEP 534, PEP 547, PEP 573), seve

Re: [Python-Dev] Petr Viktorin as BDFL-Delegate for PEP 580

> On 4 Oct 2018, at 08:14, Nick Coghlan wrote:> > I was figuring we could treat it as a caretaker mode governance: anything we > do before the new governance model is formalised is subject to ratification > by the new council members (or the new BDFL if that option ends up being > chosen).

Re: [Python-Dev] Asking for reversion

> On 4 Feb 2019, at 01:49, Guido van Rossum wrote:> > I think this is now up to the 3.8 release manager. I responded on the tracker: https://bugs.python.org/issue35813#msg334817 I wrote:> @Davin, in what time can you fill in the missing tests and documentation? If > this is something you

Re: [Python-Dev] Why a merge for 3.8.0a1?

> On 4 Feb 2019, at 11:58, Stephane Wirtel wrote: > > Hi all, > > After a git pull, I have seen there is a merge for v3.8.0a1 by Łukasz > Langa, why? I think the code should keep a linear commit and in this > case, it's against the "commit&squash" of

[Python-Dev] [RELEASE] Python 3.8.0a1 is now available for testing

I packaged my first release. *wipes sweat off of face* Go get it here: https://www.python.org/downloads/release/python-380a1/ Python 3.8.0a1 is the first of four planned alpha releases of Python 3.8, the next feature release of Python. During the alpha phase, Python 3.8 remains under heavy devel

[Python-Dev] [RELEASE] Python 3.8.0a1 is now available for testing

I packaged another release. Go get it here: https://www.python.org/downloads/release/python-380a2/ Python 3.8.0a2 is the second of four planned alpha releases of Python 3.8, the next feature release of Python. During the alpha phase, Python 3.8 remains under heavy development: additional features

[Python-Dev] Announcing: signups are open for the 2019 Python Language Summit

The Python Language Summit is an event for the developers of Python implementations (CPython, PyPy, Jython, and so on) to share information, discuss our shared problems, and — hopefully — solve them. These issues might be related to the language itself, the standard library, the development proces

Re: [Python-Dev] [python-committers] Announcing: signups are open for the 2019 Python Language Summit

> On 27 Feb 2019, at 14:22, Łukasz Langa wrote: > > The Python Language Summit is an event for the developers of Python > implementations (CPython, PyPy, Jython, and so on) to share information, > discuss our shared problems, and — hopefully — solve them. Oh, you'd also lik

[Python-Dev] [RELEASE] Python 3.8.0a3 is now available for testing

It's time for the third alpha of Python 3.8.0. Go get it here: https://www.python.org/downloads/release/python-380a3/ Python 3.8.0a3 is the third of four planned alpha releases of Python 3.8, the next feature release of Python. During the alpha phase, Python 3.8 remains under heavy development: a

[Python-Dev] [RELEASE] Python 3.8.0a4 is now available for testing

It's time for the LAST alpha of Python 3.8.0. Go get it here: https://www.python.org/downloads/release/python-380a4/ Python 3.8.0a4 is the fourth and final alpha release of Python 3.8, the next feature release of Python. During the alpha p

[Python-Dev] [RELEASE] Python 3.8.0b1 is now available for testing

The time has come for Python 3.8.0b1: https://www.python.org/downloads/release/python-380b1/ This release is the first of four planned beta release previews. Beta release previews are intended to give the wider community the opportunity to

[Python-Dev] PEP 596 proposes doubling the release cadence

PEP body and discussion link: https://discuss.python.org/t/pep-596-python-3-9-release-schedule-doubling-the-release-cadence/1828 - Ł signature.asc Description: Message signed with OpenPGP ___ Python-Dev mailing list -- [email protected] To unsubscr

[Python-Dev] [RELEASE] Python 3.8.0b2 is now available for testing

After a few days of delay, but somewhat cutely timed with the US Independence Day, I present you Python 3.8.0b2: https://www.python.org/downloads/release/python-380b2/ This release is the second of four planned beta release previews. Beta

[Python-Dev] [RELEASE] Python 3.8.0b3 is now available for testing

This time without delays, I present you Python 3.8.0b3: https://www.python.org/downloads/release/python-380b3/ This release is the third of four planned beta release previews. Beta release previews are intended to give the wider community

[Python-Dev] [RELEASE] Python 3.9.1rc1 is now ready for testing

3.10 Release Schedule Report bugs at https://bugs.python.org <https://bugs.python.org/>. Help fund Python and its community <https://www.python.org/psf/donations/>. Your friendly release team, Ned Deily @nad <https://discuss.python.org/u/nad> Steve Dower @steve.dower <http

[Python-Dev] [RELEASE] Python 3.8.7 is now available

dation. Your friendly release team, Ned Deily @nad <https://discuss.python.org/u/nad> Steve Dower @steve.dower <https://discuss.python.org/u/steve.dower> Łukasz Langa @ambv <https://discuss.python.org/u/ambv>___ Python-Dev mailing list

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

> On 11 Jan 2021, at 18:21, Larry Hastings wrote:> > I've written a new PEP. Please find it below. Happy reading!> Interesting! I like the clever lazy-evaluation of the __annotations__ using a pre-set code object. My only real reservation is that the transition process will be weird but

[Python-Dev] [RELEASE] Python 3.9.2rc1 and 3.8.8rc1 are now available for testing

r friendly release team, Ned Deily @nad <https://discuss.python.org/u/nad> Steve Dower @steve.dower <https://discuss.python.org/u/steve.dower> Łukasz Langa @ambv <https://discuss.python.org/u/ambv>___ Python-Dev mailing list -- python-dev@python

[Python-Dev] [RELEASE] Python 3.9.2 and 3.8.8 are now available

Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation. Your friendly release team, Ned Deily @nad <https://discuss.python.org/u/nad> Steve Dower @steve.dower <https://di

[Python-Dev] Python Language Summit 2021 Signups Are Now Open

) Co-chairs: Mariatta Wijaya & Łukasz Langa Blogger: Joanna Jablonski Sign up to attend and actively participate: https://forms.gle/cgmGnmQMDhD2mhHY8 <https://forms.gle/cgmGnmQMDhD2mhHY8> (closes after March 22nd, 2021 AoE) Propose a topic: https://forms.gle/Jui9mxsHrB4fVvAB8 <http

[Python-Dev] [RELEASE] Python 3.9.3 and 3.8.9 are now available

supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation. Your friendly release team, Ned Deily @nad <https://discuss.python.org/u/nad> Steve Dower @steve.dower <https://discus

[Python-Dev] NOTE: Python 3.9.3 contains an unintentional ABI incompatibility leading to crashes on 32-bit systems

The memory layout of PyThreadState was unintentionally changed in the recent 3.9.3 bugfix release. This leads to crashes on 32-bit systems when importing binary extensions compiled for Python 3.9.0 - 3.9.2. This is a regression. We will be releasing a hotfix 3.9.4 around 24 hours from now to add

[Python-Dev] Re: NOTE: Python 3.9.3 contains an unintentional ABI incompatibility leading to crashes on 32-bit systems

> On 4 Apr 2021, at 11:34, Matthias Klose wrote:> > On 4/4/21 4:44 AM, Terry Reedy wrote:>> >> Unless the mistake was just introduced, the mistake would have happened. One>> this severe would likely have been caught within the week or two before a>> final. But as Łukasz noted when announc

[Python-Dev] Re: NOTE: Python 3.9.3 contains an unintentional ABI incompatibility leading to crashes on 32-bit systems

> On 4 Apr 2021, at 01:15, Miro Hrončok wrote:> > However, I need to ask: Would this also happen if there was a rc version of > 3.9.3? Good question. The RC would not help. Most importantly, 3.9.3 was itself an expedited release due to its security content. When I did use an RC phase for 3.

[Python-Dev] [RELEASE] Python 3.9.4 hotfix is now available

porting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation. Your friendly release team, Łukasz Langa @ambv <https://discuss.python.org/u/ambv> Ned Deily @nad <https://discuss.python.org/u/nad> Steve Dower @steve.dower <https:/

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

Hi all, I got pinged to voice my opinion on PEP 649 as the instigator of PEP 563. I'm sorry, this is long, and a separate thread, because it deals with three things: - Goals set for PEP 563 and how it did in practice; - PEP 649 and how it addresses those same goals; - can we cleanly adopt PEP 649?

[Python-Dev] [RELEASE] Python 3.8.10, 3.9.5, and 3.10.0b1 are now available

@nad <https://discuss.python.org/u/nad> Steve Dower @steve.dower <https://discuss.python.org/u/steve.dower> Pablo Galindo Salgado @pablogsal <https://discuss.python.org/u/pablogsal> Łukasz Langa @ambv <https://discuss.python.org/u/ambv>__

[Python-Dev] Re: On the migration from master to main

> On 4 May 2021, at 01:45, Tim Peters wrote:> > Right? Wrong? Do we need some mix of both? Something else? Having renamed the branch in my fork first, the exact sequence I used on my own clone was: ❯ git checkout master ❯ git branch -m master main ❯ git fetch origin ❯ git branch -u origin/m

[Python-Dev] Re: On the migration from master to main

> On 4 May 2021, at 02:04, Łukasz Langa wrote: > > Having renamed the branch in my fork first, the exact sequence I used on my > own clone was: > > ❯ git checkout master > ❯ git branch -m master main > ❯ git fetch origin > ❯ git branch -u origin/main main > ❯

[Python-Dev] Re: github and dependabot

It's bogus automation, you can safely reject those pull requests. If you do merge any pull requests to `main` of your personal fork, your `main` branch will diverge from python/cpython's. Not recommended. I just merged the equivalent pull requests from dependabot on python/cpython. You can pull

[Python-Dev] Re: Question for potential python development contributions on Windows

> On 20 May 2021, at 07:03, [email protected] wrote:> > The Python Developers Guide specifically states to get VS2017 for developing > or enhancing python on a Windows system.> > Is it still correct to specifically use VS2017 , or is VS2019 also acceptable? We have to update the devgui

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

> On 25 May 2021, at 21:57, Guido van Rossum wrote:> > On Tue, May 25, 2021 at 12:34 PM Brett Cannon > wrote:> > I personally think it should be a Standards Track PEP. This PEP isn't > documenting some detail like PEP 13 or some release schedule, but is instead > p

[Python-Dev] [RELEASE] Python 3.9.6, 3.8.11, 3.7.11, and 3.6.14 are now available

ed Deily @nad <https://discuss.python.org/u/nad> Steve Dower @steve.dower <https://discuss.python.org/u/steve.dower> Łukasz Langa @ambv <https://discuss.python.org/u/ambv> signature.asc Description: Message signed with OpenPGP ___ Python-Dev ma

[Python-Dev] Re: Heads up: `make` in Doc now creates a venv

> On 4 Aug 2021, at 11:48, Miro Hrončok wrote:> > On 04. 08. 21 11:28, Petr Viktorin wrote:>> Hi,>> A recent change "make html" in the Doc directory create a venv if one wasn't >> there before. If you don't want to download sphinx and other dependencies >> from PyPI, you'll need to adjust y

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

> On 10 Aug 2021, at 13:05, Eric V. Smith wrote:> > If 649 is accepted, there will be few places where stringified annotations > will be needed. For example, forward references that are defined before > __annotations__ is examined will not need to be specified as strings. From > the PEP: "Ac

[Python-Dev] Re: Deprecate Py_TRASHCAN_SAFE_BEGIN/END in 3.10?

Hi everybody, I'd like to revive this thread as I feel like we have to do something here but some consensus is needed first. To recap, the current state of things is as follows: - in March 2000 (d724b23420f) Christian Tismer contributed the "trashcan" patch that added Py_TRASHCAN_SAFE_BEGIN and

[Python-Dev] Re: Deprecate Py_TRASHCAN_SAFE_BEGIN/END in 3.10?

> On 18 Aug 2021, at 11:47, Irit Katriel wrote:> > It remains the decide how to backport the compiler warning to older versions, > and to which versions. 3.8 is when the macros broke. Since they cause segfaults, I'd say that's a pretty good reason to backport the warnings. While 3.8 in secur

[Python-Dev] [RELEASE] Python 3.9.7 and 3.8.12 are now available

>We hope you enjoy the new releases Your friendly release team, Ned Deily @nad <https://discuss.python.org/u/nad> Steve Dower @steve.dower <https://discuss.python.org/u/steve.dower> Łukasz Langa @ambv <https://discuss.python.org/u/ambv> signature.asc Description: Message si

[Python-Dev] Re: PEP 654 except* formatting

> On 3 Oct 2021, at 18:37, Steven D'Aprano wrote:> > On Sun, Oct 03, 2021 at 04:47:57PM +0100, Irit Katriel via Python-Dev wrote:>> We wonder if people have a view on which of the following is clearer/better:>> >> 1. except *E as e: // except *(E1, E2) as e:> > That looks like you're unp

[Python-Dev] Re: PEP 654 except* formatting

> On 3 Oct 2021, at 20:11, MRAB wrote: > > On 2021年10月03日 18:50, Brandt Bucher wrote: >> Łukasz Langa wrote: >>> My idea is this: >>> try: >>>... >>> except group E as e: >>>... >>> except group E1, T2 as e: >>>

[Python-Dev] Re: PEP 654 except* formatting

> On 4 Oct 2021, at 15:00, Calvin Spealman wrote:> > It is difficult to understand why any special syntax is needed at all. > ExceptionGroup is still an exception class like any other, isn't it? Why > wouldn't the existing syntax suffice? This is covered at length in the PEP. Those sections

[Python-Dev] Re: PEP 654 except* formatting

> On 6 Oct 2021, at 12:06, Larry Hastings wrote:> > It seems like, for this to work, "group" would have to become a keyword.> No, just like `match` and `case` didn't have to.> This would play havoc with a lot of existing code.> Extraordinary claims require extraordinary evidence, Larry. I

[Python-Dev] Re: PEP 654 except* formatting

> On 6 Oct 2021, at 16:01, Petr Viktorin wrote:> > What about this:> > group = (KeyboardInterrupt, MemoryError)> other_group = (KeyError, IndexError)> > try:> ...> except group + other_group as error:> ... Haha, let's see if we can write a Mersienne twister all inside an except st

[Python-Dev] Re: PEP 654 except* formatting

> On 6 Oct 2021, at 18:13, Larry Hastings wrote: > On 10/6/21 2:34 PM, Łukasz Langa wrote: > >> We can even make its error message smarter than the default NameError, since >> -- as I claim -- it's terribly unlikely somebody would mean to name their >> dyn

[Python-Dev] Re: PEP 654 except* formatting

> On 6 Oct 2021, at 18:14, Brandt Bucher wrote: > > Łukasz Langa wrote: >> Joking aside, since we allow any expression after 'except' 'group' then this >> is indeed ambiguous. In theory! > > The ambiguity with function calls, though, is probably

[Python-Dev] Re: PEP 654 except* formatting

> On 6 Oct 2021, at 18:05, Yury Selivanov wrote:> > I don't like `except group` or any variant with soft keywords. As Brandt just commented, this proposal is a no go due to confusion with function calls. I'll respond below anyway because looking through it was an interesting experience> I

[Python-Dev] Re: Python multithreading without the GIL

> On 8 Oct 2021, at 10:13, Steven D'Aprano wrote:> > Hi Sam,> > On Thu, Oct 07, 2021 at 03:52:56PM -0400, Sam Gross wrote:> >> I've been working on changes to CPython to allow it to run without the>> global interpreter lock. I'd like to share a working proof-of-concept that>> can run with

Re: [Python-Dev] What if we didn't have repr?

y string conversion. 2. Move the current __repr__() contracts, both firm and informal to a new, extensible version of pprint. There has been some discussion led by Raymond in 2010 about a general `pprint rewrite`__ and I'm willing to pick up the idea with a PEP for inclusion in 3.4. _

[Python-Dev] PEP 443 - Single-dispatch generic functions

Hello, I would like to submit the following PEP for discussion and evaluation. PEP: 443 Title: Single-dispatch generic functions Version: $Revision$ Last-Modified: $Date$ Author: Łukasz Langa Discussions-To: Python-Dev Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 22

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions

at we'll find ourselves longing for multiple dispatch or predicate-based dispatch in the future, I'm sure there's still going to be enough PEP numbers free. The @singledispatch name has been chosen to ensure there's no name clash in that case (thanks Nick for suggesting tha

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions

On 23 maj 2013, at 09:33, Armin Rigo wrote: > Hi, > > On Thu, May 23, 2013 at 12:33 AM, Łukasz Langa wrote: >> Alternative approaches >> == > > You could also mention "pairtype", used in PyPy: Thanks for pointing that out. Informatio

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions

tch on annotations, e.g.: @func.register def _(arg: int): ... versus @func.register(int) def _(arg): ... -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev ___ Python-Dev mailing list [email protected]

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions

y: > >@func.register >def do_int(foo: int): >... Me too. The PEP has been updated to specify that explicitly. -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev ___ Pyth

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions

ning methods in a class or overriding them in a subclass. -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/list

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions

the reference implementation now, stay tuned. -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsub

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions

On 24 maj 2013, at 14:53, Ronan Lamy wrote: >> 2013年5月24日 Łukasz Langa >> >> I recognize the need for such behaviour to be discoverable. This is >> important for debugging purposes. This is why I'm going to let users >> inspect registered overloads, as well

[Python-Dev] PEP 443 - Single-dispatch generic functions (including ABC support)

Title: Single-dispatch generic functions Version: $Revision$ Last-Modified: $Date$ Author: Łukasz Langa Discussions-To: Python-Dev Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 22-May-2013 Post-History: 22-May-2013, 25-May-2013 Replaces: 245, 246, 3124 Abstract

Re: [Python-Dev] __subclasses__() return order

return a list. > > I guess I should explain myself more clearly: __subclasses__() already > computes its result on-the-fly (it must weed out dead weakrefs) (*). So > the visible behaviour of __subclasses__ wouldn't change, except for > ordering. +1 Makes sense to me. As

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions (including ABC support)

(which doesn't even do ABCs at > the moment). Yes, that sounds neat. Thanks for feedback! -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev ___ Python-Dev mailing list Python-Dev@pyt

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions (including ABC support)

assigned myself to the issue. I hope it doesn't require a PEP? ;-) -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions (including ABC support)

on here: http://hg.python.org/features/pep-443/file/tip/Doc/library/functools.rst#l189 The tests here: http://hg.python.org/features/pep-443/file/tip/Lib/test/test_functools.py#l855 I say we're ready. -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions (including ABC support)

First.__bases__ = (SecondABC,) >>> assert FirstABC not in ImplementsFirst.__mro__ >>> assert SecondABC in ImplementsFirst.__mro__ >>> assert issubclass(ImplementsFirst, SecondABC) But it still reports being a subclass: >>> assert issubclass(ImplementsFirst, FirstA

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions (including ABC support)

On 26 maj 2013, at 03:37, Nick Coghlan wrote: > On Sun, May 26, 2013 at 9:07 AM, PJ Eby wrote: >> On Sat, May 25, 2013 at 4:16 PM, Łukasz Langa wrote: >>> So, the latest document is live: >>> http://www.python.org/dev/peps/pep-0443/ >>> >>> The co

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions (including ABC support)

On 27 maj 2013, at 15:31, Łukasz Langa wrote: > This is exactly what I did now. I also exposed ._clear_cache() and the > uncached ._find_impl() if somebody finds it necessary to use it. Both > are left undocumented. For the record, I moved _find_impl out of the closure for easier testa

[Python-Dev] Segmentation fault on 3.4 with --pydebug

in f File "/Users/ambv/Documents/Projekty/Python/cpython/py34/Lib/test/test_exceptions.py", line 453 in f ... (repeated a 100 times) Command terminated abnormally. Everything runs fine without --with-pydebug (or before 83937 with --with-pydebug). -- Best regards, Łukasz Langa W

Re: [Python-Dev] Segmentation fault on 3.4 with --pydebug

On 30 maj 2013, at 14:45, Ronald Oussoren wrote: > Issue #18075 contains a patch. I probably won't have time to commit until > sunday, but feel free to apply the patch yourself :-) I did just that. Fixed, thanks! -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitt

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions (including ABC support)

raised." except TypeError: pass # properly refused to add a string -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev ___ Python-Dev mailing list [email protected] http://mai

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions (including ABC support)

On 31 maj 2013, at 01:47, Łukasz Langa wrote: > class State: >def __init__(self): >self.add.register(int, self.add_int) Ouch, I realized this is wrong just after I hit "Send". self.add is a staticmethod so this registration will overload on every instance. Whic

Re: [Python-Dev] PEP 443 - Single-dispatch generic functions (including ABC support)

On 31 maj 2013, at 01:51, Łukasz Langa wrote: > On 31 maj 2013, at 01:47, Łukasz Langa wrote: > >> class State: >>def __init__(self): >>self.add.register(int, self.add_int) > > Ouch, I realized this is wrong just after I hit "Send&quo

[Python-Dev] PEP 443 - request for pronouncement

already up: https://pypi.python.org/pypi/singledispatch PEP: 443 Title: Single-dispatch generic functions Version: $Revision$ Last-Modified: $Date$ Author: Łukasz Langa Discussions-To: Python-Dev Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 22-May-2013 Post-History: 2

Re: [Python-Dev] PEP 443 - request for pronouncement

I added a sentence clarifying that. See the commit: http://hg.python.org/peps/rev/4d6c827944c4 Does that address your concern? > So my comment is just about clarity of the PEP text. I do not wish to > interfere with pronouncement. Sure thing. Thanks for your feedback! -- Best regards

Re: [Python-Dev] PEP 443 Accepted

viour. The PEP briefly explains that "Where there is no registered implementation for a specific type, its method resolution order is used to find a more generic implementation." As Nick noted, the reason the description is so brief is that this works just like calling methods. -- Be

1 2 3 >