[issue47145] Improve graphlib.TopologicalSort by removing the prepare step

Larry Hastings added the comment: One final aside. Let me preface this by saying: I'm not proposing the following for graphlib.TopologicalSort. It's obviously too late to change that object this much. It's just something I'm thinking about--maybe I'll use this in my own library. Where

[issue47145] Improve graphlib.TopologicalSort by removing the prepare step

Larry Hastings added the comment: I agree that the API should have as few surprises as possible. AFAICT you haven't made any terminal pronouncements like "it's impossible to add this feature without too many unacceptable surprises", so I'll proceed assuming we can f

[issue47145] Improve graphlib.TopologicalSort by removing the prepare step

Larry Hastings added the comment: I'm not sure I follow you. What do you suggest graphlib is guessing at? I thought we were discussing what graphlib's (documented, intentional) behavior should be; if there was any guessing going on, it was us doing it, guessing at what behavior the user

[issue47145] Improve graphlib.TopologicalSort by removing the prepare step

Larry Hastings added the comment: Having slept on it, I think the footgun is slightly bigger than I gave it credit for. Also the problem of nodes lingering forever is easily solved: give the user control. My next iteration will keep the done nodes around, but I'll also add a forget

[issue47145] Improve graphlib.TopologicalSort by removing the prepare step

Larry Hastings added the comment: > Assuming we do want to be able to add() after a get_ready(), is there > a reason that "forgetting" already-produced nodes is the correct > behavior, as opposed to remembering all nodes ever added, and > raising iff the addition cre

[issue47145] Improve graphlib.TopologicalSort by removing the prepare step

Larry Hastings added the comment: I'm using my graph library to manage a list of tasks that need doing in some sort of proper order. One task may spawn other tasks at runtime, and we don't necessarily know what the tasks will be until runtime. It's way more convenient to simply add

[issue47145] Improve graphlib.TopologicalSort by removing the prepare step

New submission from Larry Hastings : I've maintained my own topological sort class for a while now. The API I came up with (or was it Tim and I?) was adopted for graphlib.TopologicalSort(). Some of my method names are slightly different, but the APIs are so similar, I can do a little

[issue46761] functools.update_wrapper breaks the signature of functools.partial objects

Larry Hastings added the comment: Ooh, good one. I don't know anybody in the Django project to contact though. Anybody have any leads? -- ___ Python tracker <https://bugs.python.org/issue46

[issue46761] functools.update_wrapper breaks the signature of functools.partial objects

Larry Hastings added the comment: I heard back from both Samuel Colvin (Pydantic) and Sebastián Ramírez (FastAPI). They said neither of them use update_wrapper with partial objects. They also took a peek in a bunch of other projects (FastAPI, Typer, SQLModel, Asyncer, SQLAlchemy, Trio

[issue39298] add BLAKE3 to hashlib

Larry Hastings added the comment: > Performance wise... The SHA series have hardware acceleration on > modern CPUs and SoCs. External libraries such as OpenSSL are in a > position to provide implementations that make use of that. Same with > the Linux Kernel CryptoAPI (https://bug

[issue39298] add BLAKE3 to hashlib

Larry Hastings added the comment: I can't answer why the Rust one is so much larger--that's a question for Jack. But the blake3-py you built might (should?) have support for SIMD extensions. See the setup.py for how that works; it appears to at least try to use the SIMD extensions on x86

[issue39298] add BLAKE3 to hashlib

Larry Hastings added the comment: The Rust version is already quite "lean". And it can be much faster than the C version, because it supports internal multithreading. Even without multithreading I bet it's at least a hair faster. Also, Jack has independently written a Python pac

[issue39298] add BLAKE3 to hashlib

Larry Hastings added the comment: Ok, I give up. -- resolution: -> rejected stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue39298] add BLAKE3 to hashlib

Larry Hastings added the comment: > Given that I don't want to see us gain new vendored copies of > significant but non-critical third party hash code in our tree > (Modules/_blake3/impl/ in PR 31686) for anything but a known > fixed term need (ex: the sha2 libtomcrypt code is gon

[issue39298] add BLAKE3 to hashlib

Larry Hastings added the comment: Jack: I've updated the PR, improving compatibility with the "blake3" package on PyPI. I took your notes, and also looked at the C module you wrote. The resulting commit is here: https://github.com/python/cpython/pull/316

[issue46761] functools.update_wrapper breaks the signature of functools.partial objects

Larry Hastings added the comment: You make a good point. I filed a separate bug (#46846) suggesting that partial objects should set their own annotations and signature. I agree that objects performing such magic should take care of these details themselves, rather than requiring

[issue46761] functools.update_wrapper breaks the signature of functools.partial objects

Larry Hastings added the comment: Nobody I've nosied on this issue recently has expressed any opinion on the matter. I'm gonna try one more person: Graham Dumpleton, the maintainer of "wrapt", Python's premier function-wrapping. Graham, care to express any opinions about this i

[issue45319] Possible regression in __annotations__ descr for heap type subclasses

Larry Hastings added the comment: I only did my experiments with the _wrappers.c Christian gave me. If that's not the shipping version of wrapt, and wrapt doesn't exhibit this behavior in 3.10, then that's good. I agree you can wait to address this behavior until it affects code you

[issue45319] Possible regression in __annotations__ descr for heap type subclasses

Larry Hastings added the comment: Graham: I'm happy to help. I can write a more elaborate explanation of what's happening, or answer questions, whatever you like. I'm a fan of wrapt so I'd certainly like to see this issue resolved. And, seeing as you're the author and maintainer of wrapt

[issue45319] Possible regression in __annotations__ descr for heap type subclasses

Larry Hastings added the comment: (It's also possible your workaround where wrapt explicitly defines an "__annotations__" getset on every child of ObjectProxy is the right fix. I don't know; I don't know the fine points of attribute access, like when does it access getsets on th

[issue45319] Possible regression in __annotations__ descr for heap type subclasses

Larry Hastings added the comment: This isn't a CPython bug. It's a change in CPython behavior that wrapt needs to accommodate. In particular, it isn't 'causing a regression for C subclasses of heap types when the parent class has an "__annotations__" descriptor', nor do child cl

[issue46930] Iterating over cls.__dict__ in classmethod causes RuntimeError when printing __annotations__

Larry Hastings added the comment: When accessing __annotations__ *in a class without annotations*, and *for the first time*. And your workaround seems reasonable. -- ___ Python tracker <https://bugs.python.org/issue46

[issue39298] add BLAKE3 to hashlib

Larry Hastings added the comment: Right, and I did say "(or BDFL)". Apparently you didn't bother to consult with the BDFL in advance, or at least not in the usual public venues--I haven't found a record of such a conversation on the bpo issue, nor in python-dev. BTW you simu

[issue39298] add BLAKE3 to hashlib

Larry Hastings added the comment: Jack O'Connor: > Was any of the experimental C extension code [...] useful to you? > I was wondering if it could be possible to copy blake3module.c from > there verbatim. I concede I didn't even look at it. The glue code to mate the library with the

[issue39298] add BLAKE3 to hashlib

Larry Hastings added the comment: Also, for what it's worth: I just ran my checksum benchmarker using a freshly built python a la my PR. Here are my results when hashing 462183782 bytes (dicey-dungeons-linux64.zip): hash algorithm timebytes/sec

[issue39298] add BLAKE3 to hashlib

Larry Hastings added the comment: Okay, so. Here's a PR that adds BLAKE3 support to hashlib. The code was straightforward; I just took the BLAKE2 module and modified it to only have one algorithm. I also copied over the whole C directory tree from BLAKE3, which is totally okay fine

[issue39298] add BLAKE3 to hashlib

Change by Larry Hastings : -- pull_requests: +29805 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/31686 ___ Python tracker <https://bugs.python.org/issu

[issue46761] functools.update_wrapper breaks the signature of functools.partial objects

Larry Hastings added the comment: I emailed the Pydantic and FastAPI guys and didn't hear back. Given what you found on their issue trackers, I think it's unlikely that they care a lot about this issue (but were too busy to reply). It's far more likely that they don't care. Doing

[issue28824] os.environ should preserve the case of the OS keys ?

Change by Larry Hastings : -- nosy: -larry, loewis ___ Python tracker <https://bugs.python.org/issue28824> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46847] functools.update_wrapper doesn't understand partial objects and annotations

New submission from Larry Hastings : functools.update_wrapper currently copies over every attribute listed in the "assigned" parameter, which defaults to WRAPPER_ASSIGNMENTS, which means it copies the wrapped function's __annotations__ to the wrapper. This is slightly wrong if t

[issue46846] functools.partial objects should set __signature__ and _annotations__

New submission from Larry Hastings : I ran across an interesting bug in issue #46761. If you call functools.update_wrapper on a functools.partial object, inspect.signature will return the wrong (original) signature for the partial object. We're still figuring that one out. And, of course

[issue46761] functools.update_wrapper breaks the signature of functools.partial objects

Larry Hastings added the comment: Okay, so, I considered the problem for a while, and I have a reasonable theory about what follow_wrapper_chains was for in the first place. If you have a generic decorator, like functools.cache(), it usually looks like this: def my_decorator(fn): def

[issue46761] functools.update_wrapper breaks the signature of functools.partial objects

Larry Hastings added the comment: Ofey, I appreciate your enthusiasm, but you should probably slow down. Fixing the bug is probably going to be the easy part here. But we're not to that stage quite yet. First, we need to determine * why the code behaves like this--is this behavior

[issue46807] Wrong class __annotations__ when field name and type are equal

Larry Hastings added the comment: Yeah, it's the same behavior. In that class, you have defined Str to be "", then you reference Str in the annotation, and its value is "". Whatever you set Str to in the example in [21], that's the value of the annotation. GvR closed

[issue46761] functools.update_wrapper breaks the signature of functools.partial objects

Larry Hastings added the comment: Yury, Ka-Ping, can you guys shed any light on this? Your names are still on inspect.py. -- nosy: +ping, yselivanov ___ Python tracker <https://bugs.python.org/issue46

[issue39298] add BLAKE3 to hashlib

Larry Hastings added the comment: Just checking--I can liberally pull code from https://github.com/BLAKE3-team/BLAKE3 yes? -- ___ Python tracker <https://bugs.python.org/issue39

[issue46783] Add a new feature to enumerate(iterable, start=0) built-in function

Change by Larry Hastings : -- components: -Argument Clinic nosy: -larry ___ Python tracker <https://bugs.python.org/issue46783> ___ ___ Python-bugs-list mailin

[issue39298] add BLAKE3 to hashlib

Larry Hastings added the comment: I thought someone volunteered to do it--if that's not happening, I could take a look at it next week. Shouldn't be too hard... unless I have to touch autoconf, which I only barely understand. -- ___ Python

[issue46761] functools.update_wrapper breaks the signature of functools.partial objects

New submission from Larry Hastings : It's considered good hygiene to use functools.update_wrapper() to make your wrapped functions look like the original. However, when using functools.partial() to pre-supply arguments to a function, if you then call functools.update_wrapper() to update

[issue39298] add BLAKE3 to hashlib

Larry Hastings added the comment: I assume by "intrinsics" you mean using the GCC SIMD stuff, not like inlining memcpy() or something. My assumption is yes, that's fine, we appear to already be using them for BLAKE2. -- ___ Pyth

[issue39298] add BLAKE3 to hashlib

Larry Hastings added the comment: > In setup.py I assume that the target platform of the build is the same as the > current interpreter's platform. If this is included in CPython, it won't be using setup.py, so this isn't a concern. I don't think there's a way to use setup.py to

[issue46314] Stray RESUME opcode for unused lambda

Change by Larry Hastings : -- components: -2to3 (2.x to 3.x conversion tool), Argument Clinic, Build, C API, Cross-Build, Demos and Tools, Distutils, Documentation, Extension Modules, FreeBSD, IDLE, IO, Installation, Library (Lib), Parser, Regular Expressions, SSL, Subinterpreters

[issue39298] add BLAKE3 to hashlib

Larry Hastings added the comment: So, can we shoot for adding this to 3.11? Jack, do you consider the code is in good shape? I'd be up for shepherding it along in the process. In particular, I can contribute the bindings so BLAKE3 is a first-class citizen of hashlib

[issue46347] memory leak in PyEval_EvalCodeEx

Larry Hastings added the comment: (Sorry--it'll leak "kwnames", "newargs", and "defaults".) -- ___ Python tracker <https://bugs.python.org/issue46347> ___ __

[issue46347] memory leak in PyEval_EvalCodeEx

Larry Hastings added the comment: The function will still leak "kwnames" and "default" if creating the "func" object fails. Admittedly that would only happen in a low-memory condition which is a) rare and b) probably only happens just before the interpr

[issue43424] Document the `controller.name` field in `webbrowser` module

Change by Larry Hastings : -- components: +Documentation nosy: -larry ___ Python tracker <https://bugs.python.org/issue43424> ___ ___ Python-bugs-list mailin

[issue43424] Document the `controller.name` field in `webbrowser` module

Change by Larry Hastings : -- components: +Library (Lib) -Argument Clinic ___ Python tracker <https://bugs.python.org/issue43424> ___ ___ Python-bugs-list mailin

[issue43424] Document the `controller.name` field in `webbrowser` module

Change by Larry Hastings : -- components: -2to3 (2.x to 3.x conversion tool), Build, C API, Cross-Build, Demos and Tools, Distutils, Documentation, Extension Modules, FreeBSD, IDLE, IO, Installation, Interpreter Core, Library (Lib), Parser, Regular Expressions, SSL, Subinterpreters

[issue19838] test.test_pathlib.PosixPathTest.test_touch_common fails on FreeBSD with ZFS

Larry Hastings added the comment: I can confirm that the behavior is fixed in ZFS on Linux. My test case C program now prints "Everything is okay." when run on a ZFS partition on Linux, and test_touch_common from the current tree passes every time. ZFS fixing this was the bes

[issue45319] Possible regression in __annotations__ descr for heap type subclasses

Larry Hastings added the comment: (Preferably not using "tox". I don't know that tool.) -- ___ Python tracker <https://bugs.python.org/issue45319> ___ ___

[issue45319] Possible regression in __annotations__ descr for heap type subclasses

Larry Hastings added the comment: I got the PR locally, but the command-line you gave me fails, tox can't find python3.10 despite it being on the path. Rather than force me to reverse-engineer and recreate your build environment, can you give me a straightforward command-line or shell

[issue45319] Possible regression in __annotations__ descr for heap type subclasses

Larry Hastings added the comment: I finally have some bandwidth to look at this--sorry for being a bit slow. I wasn't able to reproduce, because the patch didn't apply cleanly. I downloaded the patch ( https://patch-diff.githubusercontent.com/raw/GrahamDumpleton/wrapt/pull/187.patch

[issue31000] Test failure in resource module on ZFS

Larry Hastings added the comment: FWIW the test still fails in exactly the same way. This was building with main, on Pop!_OS 21.04 64-bit. -- ___ Python tracker <https://bugs.python.org/issue31

[issue45020] Freeze all modules imported during startup.

Larry Hastings added the comment: Nope. On Windows, os.path is "ntpath". -- ___ Python tracker <https://bugs.python.org/issue45020> ___ ___ Python-b

[issue45392] docstring of "type" could use an update

Larry Hastings added the comment: Removing it makes sense to me. Not sure what I was thinking, way back when. Thanks for catching--and volunteering to fix--this! -- ___ Python tracker <https://bugs.python.org/issue45

[issue45020] Freeze all modules imported during startup.

Larry Hastings added the comment: > What the two approaches have in common is that they require rebuilding the > python binary whenever you edit any of the changed modules. I heard somewhere > (I'm sorry, I honestly don't recall who said it first, possibly Eric himself) > t

[issue45020] Freeze all modules imported during startup.

Larry Hastings added the comment: There should be a boolean flag that enables/disables cached copies of .py files from Lib/. You should be able to turn it off with either an environment variable or a command-line option, and when it's off it skips all the internal cached stuff and uses

[issue45020] Freeze all modules imported during startup.

Larry Hastings added the comment: Since nobody's said so in so many words (so far in this thread anyway): the prototype from Jeethu Rao in 2018 was a different technology than what Eric is doing. The "Programs/_freeze_importlib.c" Eric's playing with essentially inlines a .pyc

[issue44879] How to insert newline characters as normal characters while input()?

Larry Hastings added the comment: This is not a bug, you are asking for programming help. Please don't use the Python issue tracker for programming help. You won't get any, you'll just waste people's time. -- components: -Argument Clinic, FreeBSD, IO, Interpreter Core, Windows

[issue25782] CPython hangs on error __context__ set to the error itself

Change by Larry Hastings : -- nosy: -larry ___ Python tracker <https://bugs.python.org/issue25782> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue22018] signal.set_wakeup_fd() should accept sockets on Windows

Change by Larry Hastings : -- nosy: -larry ___ Python tracker <https://bugs.python.org/issue22018> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36216] CVE-2019-9636: urlsplit does not handle NFKC normalization

Change by Larry Hastings : -- nosy: -larry ___ Python tracker <https://bugs.python.org/issue36216> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37923] Combining typing.get_type_hints and inspect.signature

Change by Larry Hastings : -- nosy: -larry ___ Python tracker <https://bugs.python.org/issue37923> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37923] Combining typing.get_type_hints and inspect.signature

Larry Hastings added the comment: "Type hints" and "annotations" aren't the same thing. And type hints are more opinionated about the values of annotations than would be appropriate for the inspect module. For example, typing.get_type_hints() wraps strings with Fo

[issue43987] Add "Annotations Best Practices" to HOWTO

Larry Hastings added the comment: Thanks to Jelle for an enormous amount of reviewing and re-reviewing! That was just spiffy. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracke

[issue43987] Add "Annotations Best Practices" to HOWTO

Larry Hastings added the comment: New changeset 49b26fa517165f991c35a4afcbef1fcb26836bec by larryhastings in branch 'master': bpo-43987: Add "Annotations Best Practices" HOWTO doc. (#25746) https://github.com/python/cpython/commit/49b26fa517165f991c35a4afcbef1f

[issue43901] Lazy-create an empty annotations dict in all unannotated user classes and modules

Larry Hastings added the comment: Ah, I see. So it wasn't a Windows thing, it was a "we run the test multiple times and that particular test assumed it was only run once" thing. And reflink testing is guaranteed to run every test mult

[issue43901] Lazy-create an empty annotations dict in all unannotated user classes and modules

Larry Hastings added the comment: Obviously the original assertion failure ("AssertionError: False is not true") wasn't caused by the refleaks. So I'm still puzzled about why that test worked on POSIX and failed on Windows. I admit I was pulling some wacky import shenanigans i

[issue43901] Lazy-create an empty annotations dict in all unannotated user classes and modules

Larry Hastings added the comment: You want a separate PR for the refleak fix, or should I roll them both up into one? -- ___ Python tracker <https://bugs.python.org/issue43

[issue43901] Lazy-create an empty annotations dict in all unannotated user classes and modules

Larry Hastings added the comment: Eek! I swear I did a refleak check and got a clean bill of health. Again, sorry about this! -- ___ Python tracker <https://bugs.python.org/issue43

[issue43901] Lazy-create an empty annotations dict in all unannotated user classes and modules

Change by Larry Hastings : -- pull_requests: +24442 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/25752 ___ Python tracker <https://bugs.python.org/issu

[issue43901] Lazy-create an empty annotations dict in all unannotated user classes and modules

Larry Hastings added the comment: Gee whiz! Sorry about that. I swear, it works fine on my machine. I'll incorporate import_helper.import_fresh_module helper into the test as you suggest, and once I get it to work I'll send you a PR. I don't know how to test fixing this failure, though

[issue43987] Add "Annotations Best Practices" to HOWTO

Change by Larry Hastings : -- nosy: +Jelle Zijlstra ___ Python tracker <https://bugs.python.org/issue43987> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43987] Add "Annotations Best Practices" to HOWTO

Change by Larry Hastings : -- keywords: +patch pull_requests: +24436 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/25746 ___ Python tracker <https://bugs.python.org/issu

[issue43987] Add "Annotations Best Practices" to HOWTO

New submission from Larry Hastings : Dealing with annotations is complicated. I think there should be a section of the Python documentation describing best practices for working with annotations. So, here goes. The best spot I found for it was as a new HOWTO. I added links to that HOWTO

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: Thanks for your feedback, everybody! It's now checked in. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: New changeset 74613a46fc79cacc88d3eae4105b12691cd4ba20 by larryhastings in branch 'master': bpo-43817: Add inspect.get_annotations(). (#25522) https://github.com/python/cpython/commit/74613a46fc79cacc88d3eae4105b12691cd4ba20

[issue43951] Two minor fixes for C module object

Larry Hastings added the comment: Thanks for the review, Victor! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue43901] Lazy-create an empty annotations dict in all unannotated user classes and modules

Larry Hastings added the comment: Thanks for your feedback and reviews, everybody! Python just got an eensy teensy tiny bit better. -- assignee: -> larry resolution: -> fixed stage: patch review -> resolved status: open -> closed __

[issue43901] Lazy-create an empty annotations dict in all unannotated user classes and modules

Larry Hastings added the comment: New changeset 2f2b69855d6524e15d12c15ddc0adce629e7de84 by larryhastings in branch 'master': bpo-43901: Lazy-create an empty annotations dict in all unannotated user classes and modules (#25623) https://github.com/python/cpython/commit

[issue42904] get_type_hints does not provide localns for classes

Larry Hastings added the comment: Thank you for your in-depth and thoughtful reply! I think that APIs should behave in a predictable way. So, for my use case, I tell the user that I'm passing "globals" and "locals" into eval()--and I think I'd have to have a *ver

[issue42904] get_type_hints does not provide localns for classes

Larry Hastings added the comment: kj: I just added support for default locals to inspect.get_annotation(), and I basically copied-and-pasted your dict(vars(base)) approach. Is this "surprising, but required" behavior due specifically to this being a backwards-incompati

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: Ie debated about this with myself (and with a friend!) over the last few days, and I've concluded that evaluating strings by default is too opinionated for the standard library. I've changed both inspect.signature() and inspect.get_annotations() so

[issue43954] Possible missing word on unittest doc

Change by Larry Hastings : -- nosy: -larry ___ Python tracker <https://bugs.python.org/issue43954> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43901] Lazy-create an empty annotations dict in all unannotated user classes and modules

Larry Hastings added the comment: I think the PR is in good shape. If anybody has the time for a review, I'd appreciate it! -- ___ Python tracker <https://bugs.python.org/issue43

[issue43941] Unit test failure in test_gdb only with -O0

Larry Hastings added the comment: Did that. Well, technically, I replaced two lines with the equivalent: % CFLAGS='-O0 -g3' ./configure I do see this in the Makefile: CONFIGURE_CFLAGS= -O0 -g3 so, I didn't screw it up! The test still failed

[issue43941] Unit test failure in test_gdb only with -O0

Larry Hastings added the comment: I'm on "Pop!_OS 20.10". Current versions: * Linux kernel 5.11.0-7612 * gcc version 10.2.0 (Ubuntu 10.2.0-13ubuntu1) * GNU gdb (Ubuntu 9.2-0ubuntu2) 9.2 % ./python -m sysconfig | grep CFLAGS BASECFLAGS = "-Wno-unused-result

[issue43951] Two minor fixes for C module object

Change by Larry Hastings : -- keywords: +patch pull_requests: +24349 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/25658 ___ Python tracker <https://bugs.python.org/issu

[issue43951] Two minor fixes for C module object

New submission from Larry Hastings : While working on another issue, I noticed two minor nits in the C implementation of the module object. Both are related to getting a module's name. -- First, the C function module_dir() (module.__dir__) starts by ensuring the module dict is valid

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: One final thought on that idea. Part of the reason why I didn't go back to the drawing board and re-think the API was because I thought folks were pushing back on the idea of *default* behavior possibly raising exceptions. If I misread it, and the pushback

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: Just to be clear: I would *not* want this new mode to be the *default* behavior. So far I think ONLY_IF_STRINGIZED is the best compromise for default behavior. -- ___ Python tracker <https://bugs.python.

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: I like Eric's suggestion best of all. I'd be willing to add a "silence errors on a case-by-case basis" flag to inspect.signature(). I imagine that would add a new field to the Parameter object (as Guido suggested) indicating which objects fail

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: > There may be a (deliberate? :-) misunderstanding. When I wrote about > "you" inspecting code by a "3rd party" I meant that as a symmetric > relationship -- the "you" could be a library and from the library's > PO

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: > I use inspect.signature for getting information about callables > (third-party and first-party) in my type checker: > https://github.com/quora/pyanalyze/blob/master/pyanalyze/arg_spec.py#L436. > In that context, I'd much rather get string

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: > I'm not a big user of the inspect module, but I always thought that > its use was so that you could look at a function (or other object) > *produced by a 3rd party* and learn something about it. That's interesting! I always thought its

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: I keep thinking about it, and I think letting inspect.get_annotations() and inspect.signature() raise exceptions is the right API choice. I note that that's what typing.get_type_hints() did in Python 3.9. During the development of Python 3.10

[issue43901] Lazy-create an empty annotations dict in all unannotated user classes and modules

Change by Larry Hastings : -- keywords: +patch pull_requests: +24322 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/25623 ___ Python tracker <https://bugs.python.org/issu

[issue43941] Unit test failure in test_gdb only with -O0

New submission from Larry Hastings : Recent Python source trees fail a regression test in test_gdb. Oddly, the behavior only appears up when optimization is turned off. To reproduce: % git clone cpython buildtrunk % cd buildtrunk % ./configure % vi Makefile # change "-O3&quo

[issue43901] Lazy-create an empty annotations dict in all unannotated user classes and modules

Larry Hastings added the comment: > Functions don't store __annotations__ in their __dict__, it is a > separate slot named func_annotations (see funcobject.c). I guess > that's because the __dict__ is purely for user-defined function > attributes. I brought up functions bec

[issue43901] Lazy-create an empty annotations dict in all unannotated user classes and modules

Larry Hastings added the comment: Hmm. Sorry for the stream-of-consciousness thought process here, but this approach adds wrinkles too. Function objects from the very beginning have lazy-created their annotations dict if it's not set. Which means this works fine: while True

  1   2   3   4   5   6   7   8   9   10   >