On Mar 4, 2020, at 03:00, Steven D'Aprano <st...@pearwood.info> wrote: > > On Wed, Mar 04, 2020 at 01:08:35AM -0800, Andrew Barnert wrote: > >> I liked everything up to using magic numbers like this. > > I'm not wedded to the idea of error number. I chose them because I > expect there will only be a few of them (three?) and the majority > of the time you won't bother to check the number.
OK, but what’s the downside of giving you a named constant instead of making you use the magic number 2? Making CPython 400 bytes bigger? Forcing the help for ParameterError to display the kinds of error the same way all named constants are displayed when you had a better way to display them? >> But this is just arguing about the colour of the bikeshed. Do you agree >> with me that the bikeshed itself is useful? I’m +0 on this (if there’s an implementation that can cover all of the common cases). If people are switching on the error message string in real code (and I think I’ve done that once, for Python 2.7/3.3 code where I auto-generated wrappers around appscript proxies), there ought to be another way, and having a new error subclass is the obvious pythonic better way. The only question is whether it comes up often enough to be worth fixing. >> The other question: what exactly do you propose to change? I don’t >> think you can do this on the caller side (the ceval bytecode handler >> and the PyCall functions). > > I don't know enough about the Python internals to give a definitive > answer, but I'm assuming/hoping that there is a single, or at most a > few, places in the interpreter that matches up arguments to formal > parameters, and if there's a discrepency it currently raises TypeError. > PyCall sounds promising :-) I’m pretty sure there isn’t a single place, and PyCall is not useful—but I think there may be a small handful of places that’s good enough. IIRC, it works like this: The PyCall functions and the bytecode handler eventually call the same code, but that code just prepares the arguments in a generic way that the callee can match them: as a tuple of positional args and a dict of keyword args. It doesn’t even know anything about the callee. The parsing of that tuple and dict is up to the callee. Which can be anything. But usually, it’s either: * a function (or type or thing with __call__) written in Python, in which case the PyFunction object handles matching args to params and creating exceptions * a C function that just passes the tuple and dict to one of a small set of PyArg parse functions, which do the matching and exceptions * a C function with auto-generated argclinic code, which I think is the same as above, but if not argclinic is just one more place to change A C function could just manually parse the tuple and dict, but at that point it’s like a Python function that asks for *args, **kw and parses those, and I think you’re right that we don’t need to worry about those. Especially since in most cases they’re just proxies or bridges to some other function that will parse the args the normal way and they’ll just pass that exception up. So, I think those 2 or 3 places (that may turn out to be like 6 places in the CPython source) may be sufficient. But you’d have to check that, not just go by my memory. :) Also, it’s probably worth checking some very popular special cases: ctypes (with argtypes), cffi, a couple of proxy callables like partial and MethodType, Cython, the code generator from NumPy, a few static and dynamic bridge libraries like boost::python and PyObjC, … I think most of them will already just work, except maybe for some dynamic bridges (e.g., if PyObjC is just converting the tuple and dict to an NSInvocation, calling that via ObjC, and then parsing the ObjC error to generate the Python one…), which I think would be perfectly acceptable. But it’s worth knowing whether there will be such cases. >> That still leaves functions that >> parse *args and **kw and raise TypeError manually, whether in Python >> or in C, but I suppose you can say that in that case it really isn’t a >> parameter error (the signature really is *args, **kw so everything >> matches). > > Indeed. > > I don't have any expectations about those functions. If the maintainer > of the function eventually changes whatever error they are currently > raising to ParameterError, that will be grand, but I don't expect every > third-party function that implements some custom variety of parameter > handling to support this. If they do, great, if they don't, we're no > worse off than the status quo. > >> What about inspect.Signature.bind? > > Do you have a specific concern? Just whether you’re proposing to change it as part of the proposal. I think you do want to, and I think it’ll be easy, but I don’t think either answer would be a deal breaker. More generally, I’m just trying to make sure things like inspect.signature, and partial and so on, have been considered before anyone makes a decision. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2JEZZ6RER77EEXSIEGSJJPX26SFMKCH5/ Code of Conduct: http://python.org/psf/codeofconduct/
