click.Path returns str, not pathlib.Path

[flying-sheep]

It’s surprising that INT returns an int, File a file, STRING a str, but Path a …str?

A click.Path parameter should return a pathlib.Path object.

[untitaker]

pathlib is Python 3 only afaict, Click isn't.

[untitaker]

FWIW I'm certain that an option to return a Path object is useful, but I can't see it becoming the default.

[flying-sheep]

it’s backported

[untitaker]

It's still not possible to make this a default since this would mean that the behavior of Click would depend on whether that backport is installed. And depending on that backport is not worth the added value.

[flying-sheep]

depending on that backport is not worth the added value.

what cost/value function evaluates to this result? 😄

[untitaker]

In this case, new functionality. Pathlib is merely a new API for the same
thing.

Sorry, but I don't think this is going to happen. I'll gladly accept PRs for a
non-default option though.

On Mon, Aug 10, 2015 at 06:28:08AM -0700, Philipp A. wrote:

depending on that backport is not worth the added value.

what cost/value function evaluates to this result? 😄

---

Reply to this email directly or view it on GitHub:
#405 (comment)

[flying-sheep]

What do you mean with “non-default option”?

[untitaker]

Opt-in for returning a pathlib.Path object instead of a string. The user has to
depend on the pathlib library themselves unless it's in the stdlib. I think
that's doable.

On Mon, Aug 10, 2015 at 06:37:04AM -0700, Philipp A. wrote:

What do you mean with “non-default option”?

---

Reply to this email directly or view it on GitHub:
#405 (comment)

[flying-sheep]

got it, makes sense. best would be to do it on arbitrary levels, right?

e.g. you could create a group that is configured to do it, passing it down to all subcommands and parameters, or on single parameters or even options.

the interaction of this with click.CommandCollection is obvious, but bad: merging a non-pathlib group with a pathlib group would simply behave as if each individual command would have been configured, and result in a mess, but that’s not really a problem i guess, and there’s no alternative anyway

[untitaker]

got it, makes sense. best would be to do it on arbitrary levels, right?

Honestly I don't think that's a good idea, it makes it hard to trace why a particular option is returning this particular type. If you want to avoid repetition/verbosity, you can still bind the created decorator to a new name for reuse, or create a new decorator that has it as default.

[flying-sheep]

hmm, yeah, using partial. only commands are defined on the group, so this would be easy.

[mitsuhiko]

Not going to happen. A custom path implementation might be something for addon packages.