mixed solution: unicase (unique allowed case) (was: Re:
Tim Rowe
digitig at cix.co.uk
Mon Jun 5 18:04:00 EDT 2000
More information about the Python-list mailing list
Mon Jun 5 18:04:00 EDT 2000
- Previous message (by thread): MemoryError crashes within try clause
- Next message (by thread): mixed solution: unicase (unique allowed case) (was: Re:
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
In article <5Ys_4.5311$Hz.39657 at news-server.bigpond.net.au>, neilh at scintilla.org (Neil Hodgson) wrote: > So it is a required parameter? In the original problem statement it > was > an optional parameter, which is why the name is more prominent. I agree > that > the primary subject of a call may sensibly follow a different naming > scheme > than a bunch of optional arguments which generally indicate > 'flavourings' of > a call. In my particular case it is required, but if the method had a default Canvas, making canvas an optional parameter, I'd use the same convention. > Mmm. Fixing up Python's lack of strictly typed parameters ;) AIUI, Python /does/ have strictly typed parameters. It strictly checks that all parameters are objects :-) More seriously, if you start making changes like that you move Python in the direction of being C++ (with STL). If I want that, I /use/ C++! > I'm thinking about moving the opposite way (I sometimes currently use > lower case class names for class instances) and starting to write > aCanvas > rather than canvas as it doesn't seem much additional verbiage to > remove an > opportunity for confusion. It's not the additional verbiage; it's the fact that /every/ parameter has to have the prefix, or you have to remember which parameters have, which haven't. You then have a naming scheme that's inconsistent with the standard libraries, so you have to remember where a function comes from... I found that the "a_" convention caused /more/ confusion than the upper/lower case convention, and that the "opportunity for confusion" in the latter was entirely theoretical. Of course, you may work in a different way and find the opposite, but there seemed to be an opinion in this thread that I should be prevented from working in a way /I/ find reliable and effective, to no benefit that I can see. By all means have editors or static checkers with the /option/ of looking for this, but no enforcement in the language, please!
- Previous message (by thread): MemoryError crashes within try clause
- Next message (by thread): mixed solution: unicase (unique allowed case) (was: Re:
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list