[Python-Dev] Re: Sinai and Bunimovich stadium Billiard
On 10/23/21 8:01 PM, edivmanci...@gmail.com wrote: > I'm starting now to program with kwant and I'm having problems like: Sorry, you've reached the wrong list -- this one is for the development of Python itself. For general help using Python, subscribe to python-l...@python.org which you can do at https://mail.python.org/mailman/listinfo/python-list Good luck! -- ~Ethan~ ___ 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/NQLJZDXQK7BFKBBHHCCF4C5S2JQD6HLU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Sinai and Bunimovich stadium Billiard
Hellou! I'm starting now to program with kwant and I'm having problems like: 1. How do I build a quarter Bunimovich stadium billiard and a quarter Sinai billiard? Thanks! Edivan ___ 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/KLST4HC5TCFSYNKKYHNTVCAEHTNHNN6M/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Type annotations, PEP 649 and PEP 563
On Sun, Oct 24, 2021 at 6:03 AM Bluenix wrote: > > Hmm, I thought I responded to this on Gmail but it hasn't appeared here on > the archive so I'll send it again.. > > Is it known how much more/less the annotations impact performance compared to > function defaults? > Basically, PEP 563 overhead is the same as function defaults. * Function annotations are one constant tuple per function. * Functions having the same signature share the same annotation tuple. * No GC overhead because it is constant (not tracked by GC). On the other hand, it is difficult to predicate PEP 649 overhead. When namespace is not kept: * Annotation is just a constant tuple too. * No GC overhead too. * The constant tuple will be slightly bigger than PEP 563. (It can be the same as PEP 563 when all annotations are constant.) * Although they are constant tuples, they may have their own names and firstlineno. So it is difficult to share whole annotation data between functions having the same signature. (*) (*) I proposed to drop firstlineno and names to share more annotations. See https://github.com/larryhastings/co_annotations/pull/9 When namespace is kept: * Annotations will be GC tracked objects. * They will be heavier than the "namespace is not kept", for both of startup time and memory consumption. * They have some GC overhead. To answer "how much more", we need a target application. But I don't have a good target application for now. Additionally, even if we have a good target application, it is still difficult to estimate real future impact. For example, SQLAlchemy has very heavy docstrings so the `-OO` option has a big impact. But SQLAlchemy doesn't use function annotations yet. So stock/PEP 563/PEP 649 have the same (zero) cost. Yay! But if SQLAlchemy starts using annotations, *all applications* using SQLAlchemy will be impacted in the future. Regards, -- Inada Naoki ___ 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/WHLQAVAXXXACUABGS2EJLYWU336ISZDD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Type annotations, PEP 649 and PEP 563
Hmm, I thought I responded to this on Gmail but it hasn't appeared here on the archive so I'll send it again.. Is it known how much more/less the annotations impact performance compared to function defaults? -- Blue ___ 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/X7NEHSWIRHFLXLN3HBR3WG7WT6DGUAZJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Should python-config be an stdlib module?
On Sat, 2021-10-23 at 12:25 -0300, Joannah Nanjekye wrote: > I remembered this issue on bpo with contracting opinions from when I first > looked in 2019. > > See https://bugs.python.org/issue33439 Hi, This script is currently not written in Python and hardcodes paths that are incorrect on virtual environments and relocated installs, so it would make sense to rewrite it in Python, using sysconfig. That does not require it to be exposed as a module, but would be a very cheap improvement. As the bulk of the work would be to actually rewriting it in Python, and as there is reasoning to do this other than just exposing it as a module, I would be +1 FWIW. Cheers, Filipe Laíns signature.asc Description: This is a digitally signed message part ___ 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/QWA3HPPFTHGDWYMMAXJRIXKVORC2ATLA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11
On Sun, Oct 24, 2021 at 12:35 AM Marc Mueller wrote: > > > Bear in mind that these last ones are exactly equivalent to the "or" > > operator, as they'll use the default if you have any falsy value. > > variable = some_function(...) or [] > > Isn't that in itself a good argument in favor of (??) ? By missing to add 'is > None', I would have already added a subtle bug that could be quite difficult > to find. (??) could prevent that while also being more readable. > Perhaps, but your alternate versions were identically buggy, which means that - in all probability - the bug wouldn't have been relevant. For instance, if you're asking for a file-like object, and will use stdout if no argument is passed, it's absolutely fine to use None as a default and "or" to replace it with sys.stdout, because only a pathological example will actually cause problems. And that's fine. There are myriad use-cases for a None-coalescing operator that would work just fine without one; if Python had such an operator, sure, it could be used, but they're not strong arguments for adding one. > > I'm actually more interested in a better idiom for non-constant > > function default arguments, since that's the place where this kind of > > thing often comes up. A nice ??= operator might help if your default > > is None, but if you then change the default to be object(), you can't > > use ??= any more. [...] > > True, but from my experience 'None' is just by far the most common default. > Why not improve how we handle it? > There are three situations to consider here: 1) Situations where there's no falsy value that would make sense 2) Situations where None is used and there are other falsy values that would make sense 3) Situations where any object makes sense The only ones where None-coalescing is truly significant are the second group. In the first group, "or" and "??" would behave identically, so why bother introducing a new operator? And in the third group, the default can't be None, so it has to be an artificially-invented object. All three would be improved by a late-binding feature, but only a strict subset of them would benefit from directly replacing None with something else. Like several others here, I am much more interested in the operators that do "if None, give back None, otherwise fetch an attribute/item". If we end up getting None-coalescing for free along with that, so be it, but I'm not really pushing for that part. Proper argument late-binding is an entirely orthogonal proposal, and would have many benefits that aren't part of PEP 505 or related proposals, but would do most of what we want from the ?? operator. PEP 505 has some oddities that are hard to explain, though - and I mean that not in the sense that the PEP itself is hard to read, but that I would have to go to some effort to explain what my code does (picture a mentor/student relationship here). If I offer a line of code saying <>, what happens if spam returns None? Unpacking it step by step reveals a bit more complexity than it first seems to have. Python tries to minimize such situations, doing them only when there is a very clear benefit (for instance, "3 < x < 8" is very different from "(3 < x) < 8", but that's because it is immensely valuable), and I do have misgivings about that part of it. Otherwise, though, I am in favour of this and would make good use of it. (And would do so regardless of the ultimate decision on the chaining.) 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/33M2GBBKPMYRTINEGV5ORG73AXPE643L/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Should python-config be an stdlib module?
I remembered this issue on bpo with contracting opinions from when I first looked in 2019. See https://bugs.python.org/issue33439 -- Best, Joannah Nanjekye *"You think you know when you learn, are more sure when you can write, even more when you can teach, but certain when you can program." Alan J. Perlis* ___ 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/R26FU6CGALX4E53J6OGI4AKQXXX22MLV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Type annotations, PEP 649 and PEP 563
(Off-topic) On Sat, Oct 23, 2021 at 07:42 Steven D'Aprano wrote: > I expect that people were using strings for forward references before > PEP 484, but it was 484 that made it official. I doubt it. We invented that specifically for mypy. I am not aware of any prior art. —Guido > > -- --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/CSMPER7J4F5K6KYVJ3DUC52V6JYIRLZI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Type annotations, PEP 649 and PEP 563
On Sat, Oct 23, 2021 at 09:49:10AM -0400, Larry Hastings wrote: > It's an debatable point since "from future" behavior is always off by > default. I'd certainly agree that libraries /should/ support stringized > annotations by now, considering they were nearly on by default in 3.10. > But I wouldn't say stringized annotations were a "standard" part of > Python, yet. As yet they are optional. Optional things aren't > standard, and standard things aren't optional. You misunderstand me. I'm not referring to PEP 563, which is still optional and requires the user to opt-in with a future import. I'm referring to the *manual* use of strings for forward references, which has been part of type-hinting since PEP 484 way back in 2014. https://www.python.org/dev/peps/pep-0484/#forward-references I expect that people were using strings for forward references before PEP 484, but it was 484 that made it official. -- Steve ___ 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/NGW3E43JXZ4N25GPXZIMSIAKHSMHUTSA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11
Marc Mueller writes: > True, but from my experience 'None' is just by far the most common > default. Why not improve how we handle it? The question is whether this is an improvement in the long run. When some falsies are expected, in-range values, "if arg is None: ..." or "x = default if arg is None else arg" is sufficiently precise and concise. I don't see "arg ?? default" as an improvement worthy of syntax. One the minus side, as David Mertz testifies, there is a maze of missing value use cases, all alike (or is that a missing maze of values, all alike?) These operators would further encourage conflating them all into None. At least in theory, that's not an improvement in handling None, that's a loss of precision in handling an important subset of Nones. I just don't see much value in ??. I don't have an opinion on the ?. and ?[] versions. I can see that they could make chained operations much more concise than nested if ... else expressions, and at least somewhat more precise (at least if you want to avoid deep nesting of try ... except KeyError statements, which I suppose most everybody would like to avoid). Steve ___ 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/CO7RY5NNCPMYGFH2OYNHU5JWEIP7NGIX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Type annotations, PEP 649 and PEP 563
On 10/22/21 1:45 AM, Steven D'Aprano wrote: Any other runtime annotation tool has to support strings, otherwise the "from __future__ import annotations" directive will have already broken it. If the tool does type-checking, then it should support stringified annotations. They have been a standard part of type-hinting since 2014 and Python 3.5: https://www.python.org/dev/peps/pep-0484/#forward-references Any type-checking tool which does not already support stringified references right now is broken. It's an debatable point since "from future" behavior is always off by default. I'd certainly agree that libraries /should/ support stringized annotations by now, considering they were nearly on by default in 3.10. But I wouldn't say stringized annotations were a "standard" part of Python, yet. As yet they are optional. Optional things aren't standard, and standard things aren't optional. //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/I4AC6DQL6FB3RG6DIRUVUDBJ2MP3BKLD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11
> Bear in mind that these last ones are exactly equivalent to the "or" > operator, as they'll use the default if you have any falsy value. > variable = some_function(...) or [] Isn't that in itself a good argument in favor of (??) ? By missing to add 'is None', I would have already added a subtle bug that could be quite difficult to find. (??) could prevent that while also being more readable. > I'm actually more interested in a better idiom for non-constant > function default arguments, since that's the place where this kind of > thing often comes up. A nice ??= operator might help if your default > is None, but if you then change the default to be object(), you can't > use ??= any more. [...] True, but from my experience 'None' is just by far the most common default. Why not improve how we handle 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/VDMN5ZHPMMBLCHVM63RROZJYAIII74A3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Type annotations, PEP 649 and PEP 563
On Sat, Oct 23, 2021 at 5:55 AM Bluenix wrote: > > > > Is the performance of PEP 649 and PEP 563 similar enough that we can > > outright discount it as a concern? Does anyone actually care about the > > overhead of type annotations anymore? Are there other options to alleviate > > this potential issue (like a process-wide switch to turn off annotations)? > > In my opinion this shouldn't warrant any concern as these costs are only > on startup of Python. The difference is not enough for me to care at least. > Costs are not only on startup time. Memory consumption is cost on process lifetime. And longer GC time is every time when full-GC is happened. So performance is problem for both of short lifecycle applications like CLI tools and long lifecycle applications like Web app. Regards, -- Inada Naoki ___ 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/ZQE3BXOTCETH6CDMGZHDGDEKV6SRQGQR/ Code of Conduct: http://python.org/psf/codeofconduct/
