[Python-ideas] pathlib suggestions

[Vamsi Krishna Avula]

(I have a small question, I hope it's not off-topic for this thread.)

What was the rationale behind an explicit `iterdir` method? Why not simply make the `Path` objects iterable?
________________________________________
From: Python-ideas <python-ideas-bounces+vamsi_ism=outlook.com at python.org> on behalf of Todd <toddrjen at gmail.com>
Sent: Wednesday, January 25, 2017 3:32:14 AM
To: python-ideas
Subject: Re: [Python-ideas] pathlib suggestions

On Tue, Jan 24, 2017 at 4:27 PM, Chris Angelico <rosuav at gmail.com<mailto:rosuav at gmail.com>> wrote:
On Wed, Jan 25, 2017 at 7:30 AM, Todd <toddrjen at gmail.com<mailto:toddrjen at gmail.com>> wrote:
> First, for me, extensions are primarily useful as a single unit.  So,
> practically speaking, the extension of "spam.tar.gz" isn't ".gz", it is
> ".tar.gz".  So it would be nice to have some properties to make it easier to
> deal with the "complete" extension like this.  There is a "suffixes"
> property, but it returns a list, which you then have to recombine manually.
> And as far as I can tell there is no method to return the name without any
> extension.  And there is no method for replacing all the extensions at once.
>
> So although the names are tentative, perhaps there could be a "fullsuffix"
> property to return the extensions as a single string, a "nosuffix" extension
> to return the path without any extensions, and a "with_suffixes" method that
> replaces all the suffix and can accept multiple arguments (which would then
> be joined to create the extensions).

+0. Not all files with multiple dots in them are actually using them
to mean multiple file extensions. Every day I'm working with files
that use dots to separate words in a title, or have section numbers
("4.2.5 Yada Yada Yada.md" does not have a base name of "4"), etc.
Since there's no perfect way to pin these down, this needs to be a
completely separate feature, and it'd only really be useful for some
situations. So go ahead, if there's interest, but the current one
shouldn't be deprecated or anything.

ChrisA

Of course the current ones shouldn't be deprecated, I never suggested they should be.  The whole point of using new method and property names was to avoid any conflict with the existing methods.  And yes, it won't work in all situations.  Which method or property you would use depends on your specific needs.