FileSequence.basename cut at the wrong place with still frames about fileseq HOT 7 OPEN

On Jun 17, 2018, 06:22 +0100, Justin Israel ***@***.***>, wrote: I've pushed a 65_long_ext_parsing branch with a fix for this problem. However I am a bit torn on some resulting behaviour: Given input: file.v2.tar.gz Currently the output will be: basename: file.v2 ; ext: .tar.gz There is logic that detects when the split was on a possible version number instead of a frame, and it merged it into the basename, leaving the rest as the extension. I am torn on whether the output should actually be: basename: file.v2.tar ; ext: .gz Will need to think about this. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

Hmm, at first blush I like the ".tar.gz", but something tells me it's probably better to try and remain consistent with os.path.splitext and pathlib.Path.suffix. On Jun 17, 2018, 06:22 +0100, Justin Israel ***@***.***>, wrote: > I've pushed a 65_long_ext_parsing branch with a fix for this problem. However I am a bit torn on some resulting behaviour: > Given input: file.v2.tar.gz > Currently the output will be: basename: file.v2 ; ext: .tar.gz > There is logic that detects when the split was on a possible version number instead of a frame, and it merged it into the basename, leaving the rest as the extension. I am torn on whether the output should actually be: basename: file.v2.tar ; ext: .gz > Will need to think about this. > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub, or mute the thread. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#65 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AARPxuSYCGZYnLyIwR3zJigqPH51vV__ks5t-WEVgaJpZM4UiUfR> .

On Jun 19, 2018, 22:28 +0100, Justin Israel ***@***.***>, wrote: Yea. I thought it would be good to try and preserve things like that, considering the use case. The problem is that if I don't capture it, where do I store the extra string component without dropping it? file.0100.tar.gz If the extension is captured as .gz, then .tar is lost. It isn't as simple as splitext since we store dirname, basename, range, pad, ext On Wed, Jun 20, 2018, 8:37 AM Michael Morehouse ***@***.***> wrote: > Hmm, at first blush I like the ".tar.gz", but something tells me it's > probably better to try and remain consistent with os.path.splitext and > pathlib.Path.suffix. > On Jun 17, 2018, 06:22 +0100, Justin Israel ***@***.***>, > wrote: > > I've pushed a 65_long_ext_parsing branch with a fix for this problem. > However I am a bit torn on some resulting behaviour: > > Given input: file.v2.tar.gz > > Currently the output will be: basename: file.v2 ; ext: .tar.gz > > There is logic that detects when the split was on a possible version > number instead of a frame, and it merged it into the basename, leaving the > rest as the extension. I am torn on whether the output should actually be: > basename: file.v2.tar ; ext: .gz > > Will need to think about this. > > — > > You are receiving this because you are subscribed to this thread. > > Reply to this email directly, view it on GitHub, or mute the thread. > > — > You are receiving this because you were assigned. > > > Reply to this email directly, view it on GitHub > <#65 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AARPxuSYCGZYnLyIwR3zJigqPH51vV__ks5t-WEVgaJpZM4UiUfR> > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

Yeah, not sure. This is where pathlib.Path offers the .suffixes method, which gives you a list of all the extension components... I've wondered about rewriting FileSeq in light of pathlib, subclassing Path to incorporate the idea of frame and padding, but leaving the non-sequential extension components in .suffixes, but I was holding off until having time to rewrite for 3 as well. On Jun 19, 2018, 22:28 +0100, Justin Israel ***@***.***>, wrote: > Yea. I thought it would be good to try and preserve things like that, > considering the use case. The problem is that if I don't capture it, where > do I store the extra string component without dropping it? > > > file.0100.tar.gz > > If the extension is captured as .gz, then .tar is lost. It isn't as simple > as splitext since we store dirname, basename, range, pad, ext > > On Wed, Jun 20, 2018, 8:37 AM Michael Morehouse < ***@***.***> > wrote: > > > Hmm, at first blush I like the ".tar.gz", but something tells me it's > > probably better to try and remain consistent with os.path.splitext and > > pathlib.Path.suffix. > > On Jun 17, 2018, 06:22 +0100, Justin Israel ***@***.*** >, > > wrote: > > > I've pushed a 65_long_ext_parsing branch with a fix for this problem. > > However I am a bit torn on some resulting behaviour: > > > Given input: file.v2.tar.gz > > > Currently the output will be: basename: file.v2 ; ext: .tar.gz > > > There is logic that detects when the split was on a possible version > > number instead of a frame, and it merged it into the basename, leaving the > > rest as the extension. I am torn on whether the output should actually be: > > basename: file.v2.tar ; ext: .gz > > > Will need to think about this. > > > — > > > You are receiving this because you are subscribed to this thread. > > > Reply to this email directly, view it on GitHub, or mute the thread. > > > > — > > You are receiving this because you were assigned. > > > > > > Reply to this email directly, view it on GitHub > > <#65 (comment)>, or mute > > the thread > > < https://github.com/notifications/unsubscribe-auth/AARPxuSYCGZYnLyIwR3zJigqPH51vV__ks5t-WEVgaJpZM4UiUfR > > > . > > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub, or mute the thread. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#65 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AARPxgWm7N5-NXBGdiZLJZrdP99EvQe5ks5t-YwogaJpZM4UiUfR> .

On Jun 20, 2018, 02:31 +0100, Justin Israel ***@***.***>, wrote: Well I was also thinking of rewriting fileseq to be a binding of libfileseq (c++) so that I don't have to maintain the 3 individual language ports that I currently look after. Also the gofileseq/libfileseq versions have a more memory efficient solution to storing range data than the python implementation. On Wed, Jun 20, 2018, 11:41 AM Michael Morehouse ***@***.***> wrote: > Yeah, not sure. This is where pathlib.Path offers the .suffixes method, > which gives you a list of all the extension components... I've wondered > about rewriting FileSeq in light of pathlib, subclassing Path to > incorporate the idea of frame and padding, but leaving the non-sequential > extension components in .suffixes, but I was holding off until having time > to rewrite for 3 as well. > On Jun 19, 2018, 22:28 +0100, Justin Israel ***@***.***>, > wrote: > > Yea. I thought it would be good to try and preserve things like that, > > considering the use case. The problem is that if I don't capture it, > where > > do I store the extra string component without dropping it? > > > > > > file.0100.tar.gz > > > > If the extension is captured as .gz, then .tar is lost. It isn't as > simple > > as splitext since we store dirname, basename, range, pad, ext > > > > On Wed, Jun 20, 2018, 8:37 AM Michael Morehouse < > ***@***.***> > > wrote: > > > > > Hmm, at first blush I like the ".tar.gz", but something tells me it's > > > probably better to try and remain consistent with os.path.splitext and > > > pathlib.Path.suffix. > > > On Jun 17, 2018, 06:22 +0100, Justin Israel ***@***.*** > >, > > > wrote: > > > > I've pushed a 65_long_ext_parsing branch with a fix for this problem. > > > However I am a bit torn on some resulting behaviour: > > > > Given input: file.v2.tar.gz > > > > Currently the output will be: basename: file.v2 ; ext: .tar.gz > > > > There is logic that detects when the split was on a possible version > > > number instead of a frame, and it merged it into the basename, leaving > the > > > rest as the extension. I am torn on whether the output should actually > be: > > > basename: file.v2.tar ; ext: .gz > > > > Will need to think about this. > > > > — > > > > You are receiving this because you are subscribed to this thread. > > > > Reply to this email directly, view it on GitHub, or mute the thread. > > > > > > — > > > You are receiving this because you were assigned. > > > > > > > > > Reply to this email directly, view it on GitHub > > > <#65 (comment)>, > or mute > > > the thread > > > < > https://github.com/notifications/unsubscribe-auth/AARPxuSYCGZYnLyIwR3zJigqPH51vV__ks5t-WEVgaJpZM4UiUfR > > > > > . > > > > > — > > You are receiving this because you commented. > > Reply to this email directly, view it on GitHub, or mute the thread. > > — > You are receiving this because you were assigned. > > > Reply to this email directly, view it on GitHub > <#65 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AARPxgWm7N5-NXBGdiZLJZrdP99EvQe5ks5t-YwogaJpZM4UiUfR> > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.