Make all switches keyword-only
Hello! This is my first time posting to a python list, so be kind with the newbie :-)
From issue 6372:
"I propose that all formal parameters that really act as options/switches be made keyword-only. Examples of switches are all flags, timeouts, 'verbose' bools, maximums and minimums, etc. This stresses the difference between needed input for a function and an argument that changes/extends the behavior. Besides, the code would be more readable, because instead of having some cryptic function call like register('Pablo Torres', 2, 4, 5, False) you would have the prettier register('Pablo Torres', hour=2, min=4, sec=5, had_reservation=False). The implementation would just require putting a star '*' before all options, according to pep 3102. If needed, I can rewrite this as a PEP." Since this would break pretty much all the code out there, I suspect that we should come up with a warning mechanism first. Maybe leave the warning there for a couple of releases before making it definitive. What do you guys think?
Pablo Torres N. wrote:
Hello! This is my first time posting to a python list, so be kind with the newbie :-)
You propose to break nearly everyone's code and make writing Python code harder by having your stylistic preference imposed on everyone. Do you consider *that* to be 'kind'? Before proposing wholesale changes, I kindly suggest that you please think about and learn the following Python design and principles: Python is a consenting-adults language. Breaking existing code is bad, and should only be done with excellent reason.
From issue 6372:
"I propose that all formal parameters that really act as options/switches be made keyword-only. Examples of switches are all flags, timeouts, 'verbose' bools, maximums and minimums, etc.
Once you get beyond binary switches, you enter the land of ambiguity and endless argument.
This stresses the difference between needed input for a function and an argument that changes/extends the behavior. Besides, the code would be more readable, because instead of having some cryptic function call like register('Pablo Torres', 2, 4, 5, False) you would have the prettier register('Pablo Torres', hour=2, min=4, sec=5, had_reservation=False).
You are free to write your code like this. Do you? How many 100s or 1000s of lines? This style require that one remember the *exact* name of each keyword parameter, rather than just the position. Easier for you, perhaps, but not for everyone. It also requires that one accurately type 'name ='. More chance for typos.
The implementation would just require putting a star '*' before all options, according to pep 3102.
You are free to write your functions like this. Others are free to refuse to use them if you do.
If needed, I can rewrite this as a PEP."
Please do not.
Since this would break pretty much all the code out there, I suspect that we should come up with a warning mechanism first. Maybe leave the warning there for a couple of releases before making it definitive.
People are already not switching to Python3 because it breaks existing code. Others who would like to, cannot, because the 3rd-party libraries they need have not been converted. There should not be any more wholesale code break changes in Python 3.
What do you guys think?
You should have posted to python-list something like the following. subj: Arguments by keyword. "I like this style of calling functions. What do you guys think?" Terry Jan Reedy
On Mon, Jun 29, 2009 at 11:48 AM, Pablo Torres N.
Hello! This is my first time posting to a python list, so be kind with the newbie :-)
From issue 6372:
"I propose that all formal parameters that really act as options/switches be made keyword-only.
It is probably way too late for existing functions. What you might propose (but it would still be a long shot) are changes to PEP 8, which often gets used as a style guide. You may wish to recommend that (a) *future* such functions be keyword-only, and (b) current calls be updated to act as though the underlying functions were keyword-only. -jJ
It is probably way too late for existing functions. What you might propose (but it would still be a long shot) are changes to PEP 8, which often gets used as a style guide.
You may wish to recommend that (a) *future* such functions be keyword-only, and (b) current calls be updated to act as though the underlying functions were keyword-only.
-jJ
After all the bad critics here and in the bug tracker, I think I'll leave it to that.
participants (3)
-
Jim Jewett -
Pablo Torres N. -
Terry Reedy