[Python-Dev] a name for the ExceptHandler.type when it is a literal tuple of types
That's this bit: ``` except (A, B): ^^ ``` bpo-43149 currently calls it an "exception group", but that conflicts with PEP 654 -- Exception Groups and except* ``` >>> try: ... pass ... except A, B: ... pass Traceback (most recent call last): SyntaxError: exception group must be parenthesized ``` some alternatives: exception classinfo must be parenthesized (classinfo so named from the parameter to issubclass) exception sequence must be parenthesized see also: - https://github.com/python/cpython/pull/24467#discussion_r628756347 - https://www.python.org/dev/peps/pep-0654/ ___ 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/HSN6ESRB4BD6IUIPKLMNP4TPBQPWHBFK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: a name for the ExceptHandler.type when it is a literal tuple of types
There's a PR to use "SyntaxError: multiple exception types must be parenthesized" https://github.com/python/cpython/pull/25996 On Sat, 8 May 2021, 19:20 Gregory P. Smith, wrote: > > > On Sat, May 8, 2021 at 8:54 AM Thomas Grainger wrote: > >> That's this bit: >> >> ``` >> except (A, B): >>^^ >> ``` >> >> bpo-43149 currently calls it an "exception group", but that conflicts >> with PEP 654 -- Exception Groups and except* >> >> ``` >> >>>>> try: >>... pass >>... except A, B: >>... pass >>Traceback (most recent call last): >>SyntaxError: exception group must be parenthesized >> ``` >> >> some alternatives: >> >> exception classinfo must be parenthesized (classinfo so named from the >> parameter to issubclass) >> exception sequence must be parenthesized >> >> see also: >> >> - https://github.com/python/cpython/pull/24467#discussion_r628756347 >> - https://www.python.org/dev/peps/pep-0654/ > > > Given it requires ()s it is probably better to call it an "exception > sequence" or even go fully to "exception tuple" in order to avoid confusion > and tie in with the other meanings of the required syntax. > > -gps > ___ 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/2ZHLIOVQG27EUJLXQYMTQUB6Z67MNJ4I/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: a name for the ExceptHandler.type when it is a literal tuple of types
Would it be possible to drop the requirement that multiple exception types are parenthesized? Is it only ambiguous with the old Python2 syntax? On Sat, 8 May 2021, 20:15 Guido van Rossum, wrote: > I propose “exception tuple”, since syntactically and semantically it must > be a tuple. (Same as for isinstance() and issubclass().) > > On Sat, May 8, 2021 at 05:52 Thomas Grainger wrote: > >> That's this bit: >> >> ``` >> except (A, B): >>^^ >> ``` >> >> bpo-43149 currently calls it an "exception group", but that conflicts >> with PEP 654 -- Exception Groups and except* >> >> ``` >> >>>>> try: >>... pass >>... except A, B: >>... pass >>Traceback (most recent call last): >>SyntaxError: exception group must be parenthesized >> ``` >> >> some alternatives: >> >> exception classinfo must be parenthesized (classinfo so named from the >> parameter to issubclass) >> exception sequence must be parenthesized >> >> see also: >> >> - https://github.com/python/cpython/pull/24467#discussion_r628756347 >> - https://www.python.org/dev/peps/pep-0654/ >> ___ >> 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/HSN6ESRB4BD6IUIPKLMNP4TPBQPWHBFK/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > -- > --Guido (mobile) > ___ 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/3EW75R7I4IYIBKKVPBW333ZBYMPB5YGR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: a name for the ExceptHandler.type when it is a literal tuple of types
I opened a new thread here: https://mail.python.org/archives/list/python-id...@python.org/thread/WQOMBT4Z22EIFB53WN54E52AYS3QBKAV/ ___ 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/VGXHBXGKOYOKUP6TAEJIZVYBY2QFVPR2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: python-iterators mailing list on SourceForge
it might be possible to recover the account by contacting sfnet_...@slashdotmedia.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/QYNRUGSRE44ZJEPD7EWJHB7KMMNU32HZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Implementing async enumerate
https://aiostream.readthedocs.io/en/stable/operators.html#aiostream.stream.enumerate Is a nice version of an async enumerate. It also handles aclosing ___ 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/OOVBZZA4X2JF57K3GH3II46BYJSUWTCU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Delayed evaluation of f-strings?
for your usecase I'd write:
def delayed_fstring(*, name: str) -> str:
return "The current name is {name}"
def new_scope() -> None:
for name in ["foo", "bar"]:
print(delayed_fstring(name=name))
for logging I use:
class Msg:
def __init__(self, fn: Callable[[], str]):
self._fn = fn
def __str__(self) -> str:
return self._fn()
...
logger.info(Msg(lambda: f"The current name is {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/ZXRUDEMIY4AV3SIVIEAWHFKFMPGOLI4J/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [slightly OT] cryptographically strong random.SystemRandom()
https://docs.microsoft.com/en-us/windows/win32/seccng/cng-portal ? On Mon, 12 Jul 2021, 23:18 Dan Stromberg, wrote: > > On Mon, Jul 12, 2021 at 8:37 AM Steve Dower > wrote: > >> On 7/12/2021 4:11 PM, Dan Stromberg wrote: >> > It looks like CPython could do better on Windows: SystemRandom (because >> > of os.urandom()) is good on Linux and mac, but on Windows they use the >> > CryptGenRandom deprecated API >> > >> > Supporting detail: >> > >> https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptgenrandom >> > < >> https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptgenrandom >> > >> > >> > Should I open an issue? >> >> Please do, but note that the API is only deprecated because it was not >> very extensible and the new API is much more comple... er... extensible. >> >> There's nothing wrong with the randomness from the function. It'll be >> using the new API under the covers. So this is an enhancement, not a >> security issue, and should only target 3.11. >> > > I created https://bugs.python.org/issue44611 for this. > > ___ > 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/C3QBAG3YHBJSJQ5MO32TFN6R6PBYKEKD/ > 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/JSLZGO3TZUDLSS3VJHE2WHKEBUDWJLPH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations
dataclasses need to check for ClassVar ___ 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/WOTCUBAO62WRRCCQAO6ZJNASSMK36MDW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations
Damian Shaw wrote: > > dataclasses need to check for ClassVar > > Interesting, so the use case we are talking about is: 1) You are using > annotations to mean actual types, 2) But you also have to inspect them at > runtime, 3) For some of the types the name might not be defined at runtime > yet > In this example doesn't the current behavior, PEP 649, and PEP 563 (using > get_type_hints) all throw an exception? > Could PEP 649 be modified to say that if a NameError is raised the result > is not cached and therefore you can inspect it later at runtime to get the > real type once it is defined? Wouldn't that then allow users to write code > that allows for all use cases under this scenario? > - Damian (he/him) > On Tue, Aug 10, 2021 at 1:55 PM Thomas Grainger tagr...@gmail.com wrote: > > dataclasses need to check for ClassVar > > ___ > > 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/WOTCUBAO... > > Code of Conduct: http://python.org/psf/codeofconduct/ > > Yep it would need a note on the pep. It's a narrow usecase and everyone who does use the feature (attrs, pydantic etc) are watching this PEP carefully so it shouldn't be too much of a comparability concern ___ 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/TVFMEVEUUQSDQLEN5COUVXLYDXMWFMXM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations
Although the co_annoations code could intercept the NameError and replace return a ForwardRef object instead of the resolved 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/46OW5FQPHG54VIVKY2OQGLNITTPNCJXV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations
Jelle Zijlstra wrote: > El mar, 10 ago 2021 a las 11:20, Thomas Grainger (tagr...@gmail.com) > 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/46OW5FQP... > > Code of Conduct: http://python.org/psf/codeofconduct/ > > I'd like the updated PEP to mention this approach and describe if/why it wasn't included ___ 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/UMDSJGZZFUCO3LC6EPXU76ZTCRBYID57/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations
What about using a coroutine of `v = yield (name, scope)` so the caller can choose how and when names are resolved? ___ 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/RDQXLGRLCF6OWLU5ANDUSXJURNMKCIBL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations
I think as long as there's a test case for something like ``` @dataclass class Node: global_node: ClassVar[Node | None] left: InitVar[Node | None] right: InitVar[None | None] ``` the bug https://bugs.python.org/issue33453 and the current implementation https://github.com/python/cpython/blob/bfc2d5a5c4550ab3a2fadeb9459b4bd948ff61a2/Lib/dataclasses.py#L658-L714 shows this is a tricky problem ___ 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/FACVXQOACURN5PJROQLFADLCFCXUMP7K/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations
Larry Hastings wrote: > On 8/11/21 12:02 AM, Thomas Grainger wrote: > > I think as long as there's a test case for something like > > @dataclass > > class Node: > > global_node: ClassVar[Node | None] > > left: InitVar[Node | None] > > right: InitVar[None | None] > > > > the bug https://bugs.python.org/issue33453 and the current implementation > > https://github.com/python/cpython/blob/bfc2d5a5c4550ab3a2fadeb9459b4bd948ff6... > > shows this is a tricky problem > > The most straightforward workaround for this is to skip the decorator > syntax. With PEP 649 active, this code should work: > class Node: > global_node: ClassVar[Node | None] > left: InitVar[Node | None] > right: InitVar[None | None] > Node = dataclass(Node) > //arry/ the decorator version simply has to work ___ 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/2SHPHLZ2QV7YVCIC4PFPNLIHTW2WZP3A/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations
Larry Hastings wrote: > On 8/11/21 2:48 AM, Jukka Lehtosalo wrote: > > On Wed, Aug 11, 2021 at 10:32 AM Thomas Grainger > mailto:tagr...@gmail.com> wrote: > > Larry Hastings wrote: > > > On 8/11/21 12:02 AM, Thomas Grainger wrote: > > > > I think as long as there's a test case for something like > > > > @dataclass > > > > class Node: > > > > global_node: ClassVar[Node | None] > > > > left: InitVar[Node | None] > > > > right: InitVar[None | None] > > > > > > > > the bug https://bugs.python.org/issue33453 > > <https://bugs.python.org/issue33453> and the current > > implementation > > https://github.com/python/cpython/blob/bfc2d5a5c4550ab3a2fadeb9459b4bd948ff6. > > <https://github.com/python/cpython/blob/bfc2d5a5c4550ab3a2fadeb9459b4bd948ff6.>.. > > shows this is a tricky problem > > > > The most straightforward workaround for this is to skip the > > decorator > > > syntax. With PEP 649 active, this code should work: > > > class Node: > > > global_node: ClassVar[Node | None] > > > left: InitVar[Node | None] > > > right: InitVar[None | None] > > > Node = dataclass(Node) > > > //arry/ > > > > the decorator version simply has to work > > > > > > > > I also think that it would be unfortunate if the decorator version > > wouldn't work. This is a pretty basic use case. > > So, here's an idea, credit goes to Eric V. Smith. What if we tweak how > decorators work, /jst slghtly/, so that they work like the > workaround code above? > Specifically: currently, decorators are called just after the function > or class object is created, before it's bound to a variable. But we > could change it so that we first bind the variable to the initial value, > then call the decorator, then rebind. That is, this code: > @dekor8 > class C: > ... > would become equivalent to this code: > class C: > ... > C = dekorate(C) > This seems like it would solve the class self-reference problem--the > "Node" example above--when PEP 649 is active. > This approach shouldn't break reasonable existing code. That said, this > change would be observable from Python, and pathological code could > notice and break. For example: > def ensure_Foo_is_a_class(o): > assert isinstance(Foo, type) > return o > class Foo: > ... > @ensure_Foo_is_a_class > def Foo(): > ... > This terrible code currently would not raise an assertion. But if we > made the proposed change to the implementation of decorators, it would. > I doubt anybody does this sort of nonsense, I just wanted to fully flesh > out the topic. > If this approach seems interesting, here's one wrinkle to iron out. > When an object has multiple decorators, would we want to re-bind after > each decorator call? That is, would > @dekor1 > @dekor2 > @dekor3 > class C: > ... > turn into approach A: > class C: > ... > C = dekor1(dekor2(dekor3(C))) > or approach B: > class C: > ... > C = dekor3(C) > C = dekor2(C) > C = dekor1(C) > I definitely think "approach B" makes more sense. > //arry/ You mention that you wanted this to work also for non-type hint usage of annotations, and so a ForwardRef won't work. As such, would you also change this for function decorators so you can do this? ``` @decorator @typing.no_type_check def ham(spam: ham): ... So it means: ``` def ham(spam: ham): ... ham = typing.no_type_check(ham) ham = decorator(ham) ``` Obviously it's meaningless as a type hint, hence the no_type_check opt out ___ 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/OJKTIGCHNFTW224O6OM4NIZ3OZBK2YQI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations
Would: ``` @dataclass class Node: global_node: __class__ | None ``` "Just work" with co_annotations? ___ 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/ONQM6PTLD5QFC6UAJIYH437XFMAEEOAD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations
I don't think I've seen code like this. It would be incredibly useful to have a cpython-primer (like mypy-primer and black-primer) that ran as many test suites as possible from pypi with every cPython commit ___ 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/QEGUZ5GOKA4CI5ELA5BBDSS76UJN26BI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Regressions caused the recent work on ceval.c and frame objects
Are projects that ship pre-compiled wheels impacted? Eg twisted-iocpsupport ? On Sun, 19 Sep 2021, 22:09 Miro Hrončok, wrote: > On 19. 09. 21 21:34, dw-...@d-woods.co.uk wrote: > > Are you sure Cython is still broken? It looks like it was fixed back in > May (https://github.com/cython/cython/issues/4153) and all the tests look > to be passing on the 3.10-dev CI run for Cython. I think it only affected > the profiling feature on Cython (which most people will have turned off) so > probably won't cause widespread breakage. > > > > Which is not to say that you shouldn't fix the issue, but I don't think > it's a disaster from Cython's point of view. > > Cython is fixed. However all the projects that ship Cython pre-generated C > sources in sdists on PyPI that are affected and were not re-generated will > not > compile on Python 3.10. (Which might already be the case for different > changes > that affected Cython.) > > -- > Miro Hrončok > -- > Phone: +420777974800 > IRC: mhroncok > > ___ > 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/YHPXTAOHGYDKYF4WY42L2KSTDLR65Q2T/ > 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/55PGGLILX3VCKTJELZKFOKEKUEGKNQIY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: f-strings in the grammar
I don't think the python syntax should be beholden to syntax highlighting tools, eventually some syntax feature that PEG enables will require every parser or highlighter to switch to a similar or more powerful parse tool ___ 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/FI6QGN5GJJMVXOEM3VDZ7CAKIEUU2S4R/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Does ensurepip still have to include a copy of setuptools?
I raised an issue about this: https://github.com/pypa/pip/issues/10530 ___ 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/HYMTJHEWY5OAWADN4IZSZT4CODSRTOCR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 654 except* formatting
What about `except case ExceptionGroup[E1 | E2]:`? and use match semantics? On Sun, 3 Oct 2021, 16:50 Irit Katriel via Python-Dev, < python-dev@python.org> 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: > 2. except* E as e: // except* (E1, E2) as e: > > (The difference is in the whitespace around the *). > > At the moment * is a separate token so both are allowed, but we could > change that (e.g., make except* a token), and in any case we need to settle > on a convention that we use in documentation, etc. > > It is also not too late to opt for a completely different syntax if a > better one is suggested. > > > ___ > 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/4B256YKUPW5P2M44GG5H6FBL3PSV6ODP/ > 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/XNZNX2M2PQ24VEH5GWCGVFS5EY6XMRAX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Worried about Python release schedule and lack of stable C-API
I think that's unfortunate, you can still use and format the subset of Python 3.10 syntax with black. You already do this on python 3.9 for example black doesn't support parenthesized with ___ 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/5LWYHTZYZ4WJB7PSN3HWHECITMNHBT6O/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 654 except* formatting
How about ``` try: ... exceptgroup E1, E2: ... `` ___ 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/QY2I5EWUZZZWPCLS7YFFWR7RDRNGTCY7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Python multithreading without the GIL
Is D1.update(D2) still atomic with this implementation? https://docs.python.org/3.11/faq/library.html#what-kinds-of-global-value-mutation-are-thread-safe On Mon, 11 Oct 2021, 17:54 Sam Gross, wrote: > On Fri, Oct 8, 2021 at 12:04 PM Nathaniel Smith wrote: > >> I notice the fb.com address -- is this a personal project or something >> facebook is working on? what's the relationship to Cinder, if any? >> > > It is a Facebook project, at least in the important sense that I work on it > as an employee at Facebook. (I'm currently the only person working on it.) > I keep in touch with some of the Cinder devs regularly and they've advised > on the project, but otherwise the two projects are unrelated. > > >> Regarding the tricky lock-free dict/list reads: I guess the more >> straightforward approach would be to use a plain ol' mutex that's >> optimized for this kind of fine-grained per-object lock with short >> critical sections and minimal contention, like WTF::Lock. Did you try >> alternatives like that? If so, I assume they didn't work well -- can >> you give more details? >> > > I'm using WTF::Lock style locks for dict/list mutations. I did an > experiment > early on where I included locking around reads as well. I think it slowed > down > the pyperformance benchmarks by ~10% on average, but I can't find my notes > so I plan to re-run the experiment. > > Additionally, because dicts are used for things like global variables, I'd > expect > that locks around reads prevent efficient scaling, but I haven't measured > this. > > ___ > 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/V76ZRBM6UMGYU7FTNENMOOW7OYEFYQ5Q/ > 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/5RKLUR2DYJ53OIRX74WVZCVRGW7VUXLF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Python multithreading without the GIL
I have a PR to remove this FAQ entry: https://github.com/python/cpython/pull/28886 ___ 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/YP3QZ7ZLMMQUAWVQRGAGNNETA6IDXP4P/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Oh look, I've been subscribed to python/issues-test-2 notifications again
I was looking into migrating twisted trac to github, and contacted GitHub support who told me there's a secret API that doesn't notify subscribers https://gist.github.com/jonmagic/5282384165e0f86ef105 On Thu, 4 Nov 2021, 19:28 Brett Cannon, wrote: > What notification? (I fully admit I may not have gotten one due to some > team I'm in, but I have no such notification if it happened recently.) > > On Thu, Nov 4, 2021 at 12:16 AM Larry Hastings wrote: > >> >> I guess this is part of the migration from bpo to GitHub issues? Maybe >> the initial work could be done in a private repo, to cut down on the >> spurious email notifications to literally everybody subscribed to cpython? >> Which is a lot of people. >> >> >> */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/H5KW6GRHIF2VWOGNRH5367WB3K2GPARO/ >> 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/OJYGOHGS27CUY7KWHE5PEC2CKYH6M5PI/ > 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/X5OWAZZRM6ZL2O6U4V7Q6EXBLG4NTJUT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Decreasing refcount for locals before popping frame
Can you show a run-able example of the successful and unsuccessful usage of `with DAG(): ... `? On Fri, Apr 29, 2022, 6:31 AM Malthe wrote: > Pablo Galindo Salgado wrote: > > As it has been mentioned there is no guarantee that your variable will > even > > be finalized (or even destroyed) after the frame finishes. For example, > if > > your variable goes into a reference cycle for whatever reason it may not > be > > cleared until a GC run happens (and in some situations it may not even be > > cleared at any point). > > I think there is a reasonable guarantee in CPython that it will happen > exactly when you leave the frame, assuming there are no cycles or other > references to the object. There's always the future, but I don't see a very > near future where this will change fundamentally. > > Relying too much on CPython's behavior is a bad thing, but I think there > are cases where it makes sense and can be a pragmatic choice. Certainly > lots of programs have successfully relied on `sys._getframe` over the years. > ___ > 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/BVO7RMMZ2LJFEG4GRNNTYZU3Q4P3DHV3/ > 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/PK7XVKSI7MSU6IJQIQCWM7BHNO7UT5YW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Decreasing refcount for locals before popping frame
Does this only apply to DAGfiles? Eg
https://airflow.apache.org/docs/apache-airflow/1.10.12/concepts.html#scope
You can use a `__del__` method that warns on collection - like an unawaited
coroutine
Also if you're in control of importing the dagfile you can record all
created dags and report any that are missing from the globals of the module
On Fri, Apr 29, 2022, 7:45 AM Malthe wrote:
> On Fri, 29 Apr 2022 at 06:38, Thomas Grainger wrote:
> > Can you show a run-able example of the successful and unsuccessful usage
> of `with DAG(): ... `?
>
> from airflow import DAG
>
> # correct:
> dag = DAG("my_dag")
>
> # incorrect:
> DAG("my_dag")
>
> The with construct really has nothing to do with it, but it is a
> common source of confusion:
>
> # incorrect
> with DAG("my_dag"):
> ...
>
> It is less obvious (to some) in this way that the entire DAG will not
> be picked up. You will in fact have to write:
>
> # correct
> with DAG("my_dag") as dag:
> ...
>
> This way, you're capturing the DAG in the top-level scope which is the
> requirement.
>
___
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/PC3ZTY3COHM3XDOPO3KWWC3NYVCQ7SNH/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Decreasing refcount for locals before popping frame
Can you ping me on the airflow PR for this change? (@graingert) On Fri, Apr 29, 2022, 7:54 AM Malthe wrote: > On Fri, 29 Apr 2022 at 06:50, Thomas Grainger wrote: > > You can use a `__del__` method that warns on collection - like an > unawaited coroutine > > > > Also if you're in control of importing the dagfile you can record all > created dags and report any that are missing from the globals of the module > > Yes and I think this is the best we can do given how frames are being > cleared. > > We can notify the user that a DAG was instantiated and not exposed at > the top-level which is almost guaranteed to be a mistake. There's > probably no good way currently to do better (for some value of > "better"). > > Thanks > ___ 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/QEYZLMYN4OIV4Q7JTIBP7RHEI37QPJAS/ Code of Conduct: http://python.org/psf/codeofconduct/
