On Mon, Sep 27, 2010 at 8:21 AM, Greg Ewing email@example.com wrote:
Nick Coghlan wrote:
Constant parameter territory isn't *necessarily* a bad thing if the number of parameters is sufficiently high.
That's true, but the number of parameters wouldn't be high in this case.
How high is high enough? Just in realpath, normpath, normcase we already have 3 options, with the "match the existing case-preserving filename if it exists" variant requested in this discussion making it 4. Supporting platform appropriate Unicode normalisation would make it 5.
Note that I'm not saying the swiss-army function is necessarily the right answer here, but remembering "use os.realpath to get canonical filenames" and then having a bunch of flags to enable/disable various aspects of the normalisation (defaulting to the current implementation of only expanding symlinks) fits my brain more easily than remembering the distinctions between the tasks that currently correspond to each function name. If there really isn't a name that makes sense for the new variant, then maybe adding some constant parameters to one of the existing methods is the way to go.
realpath and normpath are the two most likely candidates to use as a basis for such an approach. If realpath was used as a basis, then it would gain keyword-only parameters along the lines of "expand_links=True", "collapse=False", "lower_case=False", "match_case=False". Setting both lower_case=True and match_case=True would trigger ValueError, but the API with separate boolean flags is easier to use than one with a single tri-state parameter for the case conversion. If normcase was used as a basis instead, then symlink expansion would remain a separate operation and normpath would gain "collapse=True", "lower_case=False", "match_case=False" as keyword-only parameters.