On 25 January 2014 01:07, Larry Hastings <la...@hastings.org> wrote: > I'm sorting the problems we see into four rough categories. > > a) Functions where there's a static Python value that behaves > identically to not passing in that parameter (aka "the NULL problem") > > Possible Solutions: > 0) Do nothing, don't convert the function. > 1) Use that clever static value as the default.
For this case, I think option 1) is better, as there's no externally visible change in semantics, just a change to the internal implementation details. > b) Functions where there's no static Python value that behaves identically > to > not passing in that parameter (aka "the dynamic default problem") > > Possible solutions: > 0) Do nothing, don't convert the function. > 1) Use a magic value as None. Preferably of the same type as the > function accepts, but failing that use None. If they pass in > the magic value use the previous default value. Guido himself > suggested this in > 2) Use an Argument Clinic "optional group". This only works for > functions that don't support keyword arguments. Also, I hate > this, because "optional groups" are not expressable in Python > syntax, so these functions automatically have invalid signatures. I'm inclined to say "leave these for now, we'll fix them in 3.5". They're going to be hard to convert without altering their semantics, which we shouldn't be doing at this stage of the release cycle. There's going to be follow up work in 3.5 anyway, as I think we should continue with PEP 457 to make __text_signature__ a public API and add optional group support to inspect.Signature. > c) Functions that accept an 'int' when they mean 'boolean' (aka the > "ints instead of bools" problem) > > Solution: > 1) Use "bool". > 2) Use "int", and I'll go relax Argument Clinic so they > can use bool values as defaults for int parameters. If the temptation is to use True or False as the default, then I think that's a clear argument that these should be accepting "bool". However, expanding the accepted types is also clearly a new feature that would need a "versionchanged" in the docs for all affected functions, so I think these changes also belong in the "conversion implies semantic changes, so leave until 3.5" category. > d) Functions with behavior that deliberately defy being expressed as a > Python signature (aka the "untranslatable signature" problem) > > Example: > itertools.repeat(), which behaves differently depending on whether > "times" is supplied as a positional or keyword argument. (If > "times" is <0, and was supplied via position, the function yields > 0 times. If "times" is <0, and was supplied via keyword, the > function yields infinitely-many times.) > > Solution: > 0) Do nothing, don't convert the function. > 1) Change the signature until it is Python compatible. This new > signature *must* accept a superset of the arguments accepted > by the existing signature. (This is being discussed right > now in issue #19145.) For these, I think we should respect the release cycle and leave them until 3.5. Python has survived for a couple of decades with broken introspection for builtins and extension modules, we'll survive another release that still exhibits a subset of the problem :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
