[Python-ideas] reusing realpath()

Nick Coghlan ncoghlan at gmail.com
Mon Sep 27 14:15:27 CEST 2010


On Mon, Sep 27, 2010 at 8:21 AM, Greg Ewing <greg.ewing at canterbury.ac.nz> 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.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia



More information about the Python-ideas mailing list