[issue26545] [doc] os.walk is limited by python's recursion limit

Irit Katriel added the comment: I agree with Stanley. The documentation for os is clear that recursion is used and the documentation for RecursionError links to getrecursionlimit(). This seems sufficient. -- nosy: +iritkatriel resolution: -> wont fix stage: -> resolved status:

[issue26545] [doc] os.walk is limited by python's recursion limit

Stanley added the comment: I'm not too sure about documenting the recursive limit here. There's a few other recursive functions in the os library (such as makedirs()) and if we note the recursive limit for os.walk then all of them should be noted too, but that doesn't seem quite right to me

[issue12970] [doc] os.walk() consider some symlinks as dirs instead of non-dirs

Change by Irit Katriel : -- title: os.walk() consider some symlinks as dirs instead of non-dirs -> [doc] os.walk() consider some symlinks as dirs instead of non-dirs versions: +Python 3.11 -Python 2.7, Python 3.2, Python 3.3 ___ Python trac

[issue45564] shutil.rmtree and os.walk are implemented using recursion, fail on deep hierarchies

New submission from Alexander Patrakov : It is possible to create deep directory hierarchies that cannot be removed via shutil.rmtree or walked via os.walk, because these functions exceed the interpreter recursion limit. This may have security implications for web services (e.g. various

[issue26545] [doc] os.walk is limited by python's recursion limit

Change by Ryan Mast (nightlark) : -- nosy: +rmast ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue26545] [doc] os.walk is limited by python's recursion limit

Change by Irit Katriel : -- keywords: +easy title: os.walk is limited by python's recursion limit -> [doc] os.walk is limited by python's recursion limit versions: +Python 3.10, Python 3.11, Python 3.9 -Python 3.5 ___ Python tracker <

[issue44008] os.walk and other directory traversal does not handle recursive mounts on Windows

Change by Eryk Sun : -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> os.walk always follows Windows junctions ___ Python tracker <https://bugs.python

[issue23407] os.walk always follows Windows junctions

Eryk Sun added the comment: Windows implements filesystem symlinks and mountpoints as name-surrogate reparse points. Python 3.8 introduced behavior changes to how reparse points are supported, but the stat st_mode value still sets S_IFLNK only for actual symlinks, not for mountpoints. This

[issue23407] os.walk always follows Windows junctions

Change by Eryk Sun : -- Removed message: https://bugs.python.org/msg389286 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue44008] os.walk and other directory traversal does not handle recursive mounts on Windows

New submission from R0b0t1 : Using `os.walk` to traverse a filesystem on Windows does not terminate in the case of a recursive mountpoint existing somewhere in the path. In my case C:\circlemount is linked to C:\, producing paths such as C:\circlemount\circlemount\circlemount\circlemount

[issue23407] os.walk always follows Windows junctions

may only support IO_REPARSE_TAG_SYMLINK in various cases, but sometimes perfect is the enemy of good. That said, os.walk() can still special case mountpoints and other name-surrogate reparse points. To support cases like this, the lstat() result was extended to include the st_reparse_tag value of

[issue39567] Add audit for os.walk(), os.fwalk(), Path.glob() and Path.rglob()

Saiyang Gou added the comment: Should we backport this to 3.8? I believe that we should either backport this to 3.8 or document that these audit events are new in 3.9. -- nosy: +gousaiyang ___ Python tracker

[issue40160] documentation example of os.walk should be less destructive

Serhiy Storchaka added the comment: 1. There is already a warning before example. 2. Even if you blindly copy-paste the example it will not work. You have to set the top variable. So I don't see any problem here. You always can shoot yourself in the foot if try enough. --

[issue40160] documentation example of os.walk should be less destructive

Kyle Stanley added the comment: > I made the suggested change to just print the os.remove() statements (instead > of executing them) and also removed the 'skip news'. I think you may have misunderstood the suggestion. Specifically, the key part was "I would suggest adding succinct comments

[issue40160] documentation example of os.walk should be less destructive

John Taylor added the comment: I made the suggested change to just print the os.remove() statements (instead of executing them) and also removed the 'skip news'. -- ___ Python tracker

[issue40160] documentation example of os.walk should be less destructive

Kyle Stanley added the comment: Serhiy Storchaka wrote: > I do not think there is clearer example of topdown=False than recursive > remove. > > If you think that this example is destructive, consider how destructive is > any possible example for shutil.rmtree()! I concur with Serhiy. If the

[issue40160] documentation example of os.walk should be less destructive

Serhiy Storchaka added the comment: I do not think there is clearer example of topdown=False than recursive remove. If you think that this example is destructive, consider how destructive is any possible example for shutil.rmtree()! -- nosy: +serhiy.storchaka

[issue40160] documentation example of os.walk should be less destructive

Raymond Hettinger added the comment: One possibility is a gathering cumulative directory statistics that include totals from all descendants (i.e. how many bytes of files would you save by removing the directory with rm -rf). Outside of aggregating statistics, the normal reason to use

[issue40160] documentation example of os.walk should be less destructive

John Taylor added the comment: I would prefer an example that does not actually modify the file system. Is there any way this could be achieved, yet still demonstrate why topdown=False is necessary? -- ___ Python tracker

[issue40160] documentation example of os.walk should be less destructive

Raymond Hettinger added the comment: The proposed replacement doesn't succeed in demonstrating why topdown=False is necessary. Consider doing a rename instead of a deletion or print. -- nosy: +rhettinger ___ Python tracker

[issue40160] documentation example of os.walk should be less destructive

John Taylor added the comment: https://github.com/python/cpython/pull/19313 I have just signed the CLA. -- ___ Python tracker ___

[issue40160] documentation example of os.walk should be less destructive

Change by Roundup Robot : -- keywords: +patch nosy: +python-dev nosy_count: 2.0 -> 3.0 pull_requests: +18678 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19313 ___ Python tracker

[issue40160] documentation example of os.walk should be less destructive

priority: normal severity: normal status: open title: documentation example of os.walk should be less destructive versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue40

[issue39567] Add audit for os.walk(), os.fwalk(), Path.glob() and Path.rglob()

Change by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue39567] Add audit for os.walk(), os.fwalk(), Path.glob() and Path.rglob()

Serhiy Storchaka added the comment: New changeset db283b32e7580741a8b6b7f27f616cc656634750 by Serhiy Storchaka in branch 'master': bpo-39567: Document audit for os.walk, os.fwalk, Path.glob and Path.rglob. (GH-18499) https://github.com/python/cpython/commit

[issue39567] Add audit for os.walk(), os.fwalk(), Path.glob() and Path.rglob()

Serhiy Storchaka added the comment: Oh, I did not know about the audit-event directive. Thanks Karthikeyan. As for backporting this to 3.8 I left it on to the RM. -- nosy: +lukasz.langa resolution: fixed -> stage: resolved -> patch review status: closed -> open

[issue39567] Add audit for os.walk(), os.fwalk(), Path.glob() and Path.rglob()

Change by Serhiy Storchaka : -- pull_requests: +17873 pull_request: https://github.com/python/cpython/pull/18499 ___ Python tracker ___

[issue39567] Add audit for os.walk(), os.fwalk(), Path.glob() and Path.rglob()

Steve Dower added the comment: Yes, they should be. They can also be backported to 3.8 - it was deliberate in the original PEP that adding new events is not a breaking change or a new feature. -- ___ Python tracker

[issue39567] Add audit for os.walk(), os.fwalk(), Path.glob() and Path.rglob()

Karthikeyan Singaravelan added the comment: Do these new audit events have to be documented? -- nosy: +xtreak ___ Python tracker ___

[issue39567] Add audit for os.walk(), os.fwalk(), Path.glob() and Path.rglob()

Change by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue39567] Add audit for os.walk(), os.fwalk(), Path.glob() and Path.rglob()

Change by miss-islington : -- pull_requests: +17848 pull_request: https://github.com/python/cpython/pull/18478 ___ Python tracker ___

[issue39567] Add audit for os.walk(), os.fwalk(), Path.glob() and Path.rglob()

Serhiy Storchaka added the comment: New changeset f4f445b69306c68a2ba8ce8eb8c6cb3064db5fe7 by Serhiy Storchaka in branch 'master': bpo-39567: Add audit for os.walk(), os.fwalk(), Path.glob() and Path.rglob(). (GH-18372) https://github.com/python/cpython/commit

[issue39567] Add audit for os.walk(), os.fwalk(), Path.glob() and Path.rglob()

Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +17748 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18372 ___ Python tracker

[issue39567] Add audit for os.walk(), os.fwalk(), Path.glob() and Path.rglob()

Change by Serhiy Storchaka : -- title: Add audit for os.walk, os.fwalk, Path.glob() and Path.rglob() -> Add audit for os.walk(), os.fwalk(), Path.glob() and Path.rglob() ___ Python tracker <https://bugs.python.org/issu

[issue39567] Add audit for os.walk, os.fwalk, Path.glob() and Path.rglob()

status: open title: Add audit for os.walk, os.fwalk, Path.glob() and Path.rglob() type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39

[issue39246] shutil.rmtree is inefficient because of using os.scandir instead of os.walk

Felipe A. Hernandez added the comment: After some tests, due the accumulating nature of fwalk, I've just realised it's not very safe for big directories, so I'll be closing this issue. Alternatively, using py37+ fd based scandir, and dir_fd unlink and rmdir calls would reduce complexity

[issue39246] shutil.rmtree is inefficient because of using os.scandir instead of os.walk

. -- components: Library (Lib) messages: 359512 nosy: Felipe A. Hernandez priority: normal severity: normal status: open title: shutil.rmtree is inefficient because of using os.scandir instead of os.walk versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

Re: urllib unqoute providing string mismatch between string found using os.walk (Python3)

On Saturday, 21 December 2019 21:46:43 UTC, Ben Hearn wrote: > Hello all, > > I am having a bit of trouble with a string mismatch operation in my tool I am > writing. > > I am comparing a database collection or url quoted paths to the paths on the > users drive. > > These 2 paths look

Re: urllib unqoute providing string mismatch between string found using os.walk (Python3)

On 12/21/19 8:25 PM, MRAB wrote: > On 2019-12-22 00:22, Michael Torrie wrote: >> On 12/21/19 2:46 PM, Ben Hearn wrote: >>> These 2 paths look identical, one from the drive & the other from an >>> xml url: >>> a = '/Users/macbookpro/Music/tracks_new/_NS_2018/J.Staaf - >>> ¡Móchate! _PromoMix_.wav'

Re: urllib unqoute providing string mismatch between string found using os.walk (Python3)

On 2019-12-22 00:22, Michael Torrie wrote: On 12/21/19 2:46 PM, Ben Hearn wrote: These 2 paths look identical, one from the drive & the other from an xml url: a = '/Users/macbookpro/Music/tracks_new/_NS_2018/J.Staaf - ¡Móchate! _PromoMix_.wav'

Re: urllib unqoute providing string mismatch between string found using os.walk (Python3)

On Sun, Dec 22, 2019 at 11:33 AM Michael Torrie wrote: > > On 12/21/19 2:46 PM, Ben Hearn wrote: > > These 2 paths look identical, one from the drive & the other from an xml > > url: > > a = '/Users/macbookpro/Music/tracks_new/_NS_2018/J.Staaf - ¡Móchate! > > _PromoMix_.wav' >

Re: urllib unqoute providing string mismatch between string found using os.walk (Python3)

On 12/21/19 2:46 PM, Ben Hearn wrote: > These 2 paths look identical, one from the drive & the other from an xml url: > a = '/Users/macbookpro/Music/tracks_new/_NS_2018/J.Staaf - ¡Móchate! > _PromoMix_.wav' ^^ > b =

Re: urllib unqoute providing string mismatch between string found using os.walk (Python3)

On 12/21/19 4:46 PM, Ben Hearn wrote: import difflib print('\n'.join(difflib.ndiff([a], [b]))) - /Users/macbookpro/Music/tracks_new/_NS_2018/J.Staaf - ¡Móchate! _PromoMix_.wav ? ^^ +

Re: urllib unqoute providing string mismatch between string found using os.walk (Python3)

Ben Hearn writes: > Hello all, > > I am having a bit of trouble with a string mismatch operation in my tool I am > writing. > > I am comparing a database collection or url quoted paths to the paths on the > users drive. > > These 2 paths look identical, one from the drive & the other from an

urllib unqoute providing string mismatch between string found using os.walk (Python3)

Hello all, I am having a bit of trouble with a string mismatch operation in my tool I am writing. I am comparing a database collection or url quoted paths to the paths on the users drive. These 2 paths look identical, one from the drive & the other from an xml url: a =

[issue23407] os.walk always follows Windows junctions

Steve Dower added the comment: At a minimum, it needs to be turned into a GitHub PR. We've made some significant changes in this area in 3.8, so possibly the best available code is now in shutil.rmtree (or shutil.copytree) rather than the older patch files. --

[issue23407] os.walk always follows Windows junctions

Jim Carroll added the comment: I can confirm the os.walk() behavior still exists on 3.8. Just curious on the status of the patch? -- nosy: +jamercee ___ Python tracker <https://bugs.python.org/issue23

[issue25461] Unclear language (the word ineffective) in the documentation for os.walk

miss-islington added the comment: New changeset d94b762ce824e97c441f9231f0e69ef8f59beeab by Miss Islington (bot) in branch '3.7': closes bpo-25461: Update os.walk() docstring to match the online docs. (GH-11836) https://github.com/python/cpython/commit

[issue25461] Unclear language (the word ineffective) in the documentation for os.walk

miss-islington added the comment: New changeset c43f26eca35f22707a52fb8f3fbfc9340639b58d by Miss Islington (bot) in branch '3.8': closes bpo-25461: Update os.walk() docstring to match the online docs. (GH-11836) https://github.com/python/cpython/commit

[issue25461] Unclear language (the word ineffective) in the documentation for os.walk

Benjamin Peterson added the comment: New changeset 734f1202a50641eb2c4bfbcd5b75247c1dc99a8f by Benjamin Peterson (Bernt Røskar Brenna) in branch 'master': closes bpo-25461: Update os.walk() docstring to match the online docs. (GH-11836) https://github.com/python/cpython/commit

[issue25461] Unclear language (the word ineffective) in the documentation for os.walk

Change by miss-islington : -- pull_requests: +15490 pull_request: https://github.com/python/cpython/pull/15844 ___ Python tracker ___

[issue25461] Unclear language (the word ineffective) in the documentation for os.walk

Change by miss-islington : -- pull_requests: +15489 pull_request: https://github.com/python/cpython/pull/15843 ___ Python tracker ___

[issue37462] Default starting directory for os.walk()

Kyle Stanley added the comment: Oh okay thanks taleinat. I wasn't aware of the existence of the ideas mailing list, I'll have to check that out next time. -- ___ Python tracker

[issue37462] Default starting directory for os.walk()

Tal Einat added the comment: Hi Kyle, First off, thanks for bringing this up, and for taking our feedback so well! > Before attempting to create any more original issues, I'll work on existing > issues and the suggestions of others to develop a better practical > understanding of the

[issue37462] Default starting directory for os.walk()

aeros167 added the comment: For any future issues, is it more appropriate to leave the issue status on pending until the proposal is approved? This may not apply if the issue was specifically mentioned or requested by a core developer, but it may be better to use pending for any original

[issue37462] Default starting directory for os.walk()

aeros167 added the comment: Oh okay, that's fair enough. I can definitely understand that assigning the current directory as the default does not provide a significant change in improved functionality, and it is not implicit that os.walk() would use the current directory as the default

[issue37462] Default starting directory for os.walk()

Tal Einat added the comment: I agree with Serhiy: In this case, it seems to me that "explicit is better than implicit" should be the guiding principle. -- nosy: +taleinat ___ Python tracker

[issue37462] Default starting directory for os.walk()

Serhiy Storchaka added the comment: It is not obvious that the majority of os.walk() calls are with the current working directory. And if you need to walk from the current working directory, it is not hard to pass "." explicitly. Even if your program contains a lot of os.walk(&quo

[issue37462] Default starting directory for os.walk()

aeros167 added the comment: Created a new PR which sets the default value of top to the current working directory. (https://github.com/python/cpython/pull/14497) -- ___ Python tracker

[issue37462] Default starting directory for os.walk()

Change by aeros167 : -- keywords: +patch pull_requests: +14312 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14497 ___ Python tracker ___

[issue37462] Default starting directory for os.walk()

New submission from aeros167 : As a quality of life enhancement, it would beneficial to set a default starting directory for os.walk() to use when one is not specified. I would suggest for this to be the system's current working directory. The implementation would be rather straightforward

[issue36771] Feature Request: An option to os.walk() to return os.DirEntry lists instead of just filenames/dirnames

CJ Kucera added the comment: Will do, thanks for the input! -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue36771] Feature Request: An option to os.walk() to return os.DirEntry lists instead of just filenames/dirnames

Stéphane Wirtel added the comment: Thank you for your contribution but as discussed in this issue, we prefer to have a new function and not a new boolean flag. Here is my suggestions. * Create an other PR where you add a new function * Change the title of this issue. Thank you --

[issue36771] Feature Request: An option to os.walk() to return os.DirEntry lists instead of just filenames/dirnames

Serhiy Storchaka added the comment: I concur with Stéphane. The boolean option for changing the type of the returned value is considered a bad design. -- ___ Python tracker

[issue36771] Feature Request: An option to os.walk() to return os.DirEntry lists instead of just filenames/dirnames

Stéphane Wirtel added the comment: I would like to have the advices of Serhiy. -- nosy: +serhiy.storchaka ___ Python tracker ___

[issue36771] Feature Request: An option to os.walk() to return os.DirEntry lists instead of just filenames/dirnames

Stéphane Wirtel added the comment: And another solution, you could use the pathlib.Path class for your project. Have a nice day, -- ___ Python tracker ___

[issue36771] Feature Request: An option to os.walk() to return os.DirEntry lists instead of just filenames/dirnames

CJ Kucera added the comment: Yeah, I'd wondered that too (re: a separate function) but it seemed like an awful lot of duplicated code. The PR I'd put through just changes the datatypes within the `filenames` and `dirnames` lists... I'd been thinking that'd be sufficient since you wouldn't

[issue36771] Feature Request: An option to os.walk() to return os.DirEntry lists instead of just filenames/dirnames

Stéphane Wirtel added the comment: Hi, I think you have to create a new function and not to modify the current os.walk(), just because you change the type of the returned value. We have to avoid the inconsistency for the caller of os.walk(). is it a list of DirEntry or another list

[issue36771] Feature Request: An option to os.walk() to return os.DirEntry lists instead of just filenames/dirnames

CJ Kucera added the comment: I've started up a Github PR for this, btw, though IMO it's not really in a mergeable state yet: 1) I wasn't sure what to do about os.fwalk(), since that *doesn't* already generate DirEntry objects, and this change would introduce a small inconsistency between

[issue36771] Feature Request: An option to os.walk() to return os.DirEntry lists instead of just filenames/dirnames

Change by Roundup Robot : -- keywords: +patch pull_requests: +12960 stage: -> patch review ___ Python tracker ___ ___

[issue36771] Feature Request: An option to os.walk() to return os.DirEntry lists instead of just filenames/dirnames

New submission from CJ Kucera : It'd be nice to have an option to os.walk which would return DirEntry objects in its return tuple, as opposed to just the string filenames/dirnames. (Or failing that, an alternate function which does so.) The function already uses os.scandir() internally, so

[issue25461] Unclear language (the word ineffective) in the documentation for os.walk

Change by Roundup Robot : -- pull_requests: +11867 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue25461] Unclear language (the word ineffective) in the documentation for os.walk

STINNER Victor added the comment: > What is the status on this? From this discussion, it looks like @vstinner > pushed changes to resolve this. Do we close this? If this still needs a > patch, then one of the patches can be reviewed in a PR on GitHub. It seems like os_walk_doc.patch and

[issue25461] Unclear language (the word ineffective) in the documentation for os.walk

Joannah Nanjekye added the comment: What is the status on this? From this discussion, it looks like @vstinner pushed changes to resolve this. Do we close this? If this still needs a patch, then one of the patches can be reviewed in a PR on GitHub. -- nosy: +nanjekyejoannah

[issue25461] Unclear language (the word ineffective) in the documentation for os.walk

Change by Jonathan Fine : -- nosy: +jfine2358 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33202] os.walk mentions os.listdir instead of os.scandir

miss-islington <mariatta.wijaya+miss-isling...@gmail.com> added the comment: New changeset fa5157e0499f7afdb59e220e3f4fdbf44adb5ac8 by Miss Islington (bot) in branch '3.6': closes bpo-33202: fix os.walk mentioning os.listdir instead of os.scandir (GH-6335) https://github.com/python/c

[issue33202] os.walk mentions os.listdir instead of os.scandir

miss-islington <mariatta.wijaya+miss-isling...@gmail.com> added the comment: New changeset f6d1d65803f290dfe14048f17d8125f8093a61ec by Miss Islington (bot) in branch '3.7': closes bpo-33202: fix os.walk mentioning os.listdir instead of os.scandir (GH-6335) https://github.com/python/c

[issue33202] os.walk mentions os.listdir instead of os.scandir

Change by miss-islington : -- pull_requests: +6071 ___ Python tracker ___

[issue33202] os.walk mentions os.listdir instead of os.scandir

Change by miss-islington : -- pull_requests: +6070 ___ Python tracker ___

[issue33202] os.walk mentions os.listdir instead of os.scandir

Benjamin Peterson <benja...@python.org> added the comment: New changeset badb8948aaa8b669c4a6f675a0bc7d98e188 by Benjamin Peterson (Andrés Delfino) in branch 'master': closes bpo-33202: fix os.walk mentioning os.listdir instead of os.scandir (GH-6335) https://github.com/python/c

[issue33202] os.walk mentions os.listdir instead of os.scandir

ntation messages: 314786 nosy: adelfino, docs@python priority: normal pull_requests: 6049 severity: normal status: open title: os.walk mentions os.listdir instead of os.scandir versions: Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://b

[issue31214] os.walk has a bug on Windows

Chris Lovett added the comment: Oh, my bad then. Apologies for the noise in your system. -- ___ Python tracker ___

[issue31214] os.walk has a bug on Windows

Changes by R. David Murray : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker ___

[issue31214] os.walk has a bug on Windows

Peter Otten added the comment: Read the documentation of os.walk() again. It already walks the complete directory tree starting with src. When you invoke it again by calling your copy_dir() method recursively you will of course see once more the files and directories in the respective

[issue31214] os.walk has a bug on Windows

New submission from Chris Lovett: When I walk a directory recursively, it is tacking on an additional non-existant file from one of the subdirectories. Here's the code: def copy_dir(self, src, dest): result = sftp.mkdir(dest) for dirname, dirnames, filenames in os.walk(src

[issue26781] os.walk max_depth

Raymond Hettinger added the comment: > I think there is a little need in this feature. I concur with Serhiy and think we're better-off without this proposal. Marking this as closed. -- nosy: +rhettinger resolution: -> rejected stage: -> resolved status: open -> closed

[issue26781] os.walk max_depth

André Rossi Korol added the comment: I proposed a new function called lwalk(level walk) that recurses only to a certain level of depth: http://bugs.python.org/issue30942 It is implemented in os.py and calls os.walk, but making sure it recurses only to a selected level of depth

[issue25911] Regression: os.walk now using os.scandir() breaks bytes filenames on windows

Changes by STINNER Victor : -- pull_requests: +2536 ___ Python tracker ___ ___

Re: os.walk the apostrophe and unicode

> > I am in fact using Python 3.5. I may be lacking in unicode skills > > but I do have the sense enough to know the version of Python I am > > invoking. So I included this screenshot of that so the version of > > Python and the files list returned by os.walk > > > &

Re: os.walk the apostrophe and unicode

oding. > I am in fact using Python 3.5. I may be lacking in unicode skills but I > do have the sense enough to know the version of Python I am invoking. I've made so many "stupid errors" myself that I always consider them first ;) > So I included this screenshot of that so the version

Re: os.walk the apostrophe and unicode

m invoking. > So I included this screenshot of that so the version of Python and the > files list returned by os.walk > > http://rodperson.com/graphics/uc/files.png If I create a file that has the U+2019 character in it on my Linux machine (BtrFS), and do os.walk on it, I see the characte

Re: os.walk the apostrophe and unicode

I included this screenshot of that so the version of Python and the files list returned by os.walk http://rodperson.com/graphics/uc/files.png So the fact that it shows as a string and not bytes in the debugger was throwing me for a loop, in my log section I was trying to determine if it was unic

Re: os.walk the apostrophe and unicode

On Sun, 25 Jun 2017 02:23:15 -0700, wxjmfauth wrote: > Le samedi 24 juin 2017 21:10:47 UTC+2, alister a écrit : >> On Sat, 24 Jun 2017 14:57:21 -0400, Rod Person wrote: >> >> > \xe2\x80\x99, >> >> because the file name has been created using "Right single quote" >> instead of apostrophe, the

Re: os.walk the apostrophe and unicode

Steve D'Aprano wrote: > On Sun, 25 Jun 2017 04:57 pm, Peter Otten wrote: >> if everything worked correctly? Though I don't understand why the OP >> doesn't see >> >> '06 - Toddâ\x80\x99s Song (Post-Spiderland Song in Progress).flac' >> >> which is the repr() that I get. > > That's mojibake

Re: os.walk the apostrophe and unicode

On Sun, 25 Jun 2017 04:57 pm, Peter Otten wrote: > Steve D'Aprano wrote: > >> On Sun, 25 Jun 2017 07:17 am, Peter Otten wrote: >> >>> Then I'd fix the name manually... >> >> The file name isn't broken. >> >> >> What's broken is parts of the OP's code which assumes that non-ASCII file >>

Re: os.walk the apostrophe and unicode

Steve D'Aprano wrote: > On Sun, 25 Jun 2017 07:17 am, Peter Otten wrote: > >> Then I'd fix the name manually... > > The file name isn't broken. > > > What's broken is parts of the OP's code which assumes that non-ASCII file > names are broken... Hm, the OP says '06 - Todd\xe2\x80\x99s Song

Re: os.walk the apostrophe and unicode

On Sun, 25 Jun 2017 07:17 am, Peter Otten wrote: > Then I'd fix the name manually... The file name isn't broken. What's broken is parts of the OP's code which assumes that non-ASCII file names are broken... -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure

Re: os.walk the apostrophe and unicode

d flac files, everything is working great until >> > the follow file is found >> > >> > '06 - Todd's Song (Post-Spiderland Song in Progress).flac' >> > >> > for some reason that I can't understand os.walk() returns this file >> > name as &g

Re: os.walk the apostrophe and unicode

rything is working great until > the follow file is found > > '06 - Todd's Song (Post-Spiderland Song in Progress).flac' > > for some reason that I can't understand os.walk() returns this file > name as > > '06 - Todd\xe2\x80\x99s Song (Post-Spiderland Song in > Progre

Re: os.walk the apostrophe and unicode

Can os.fsencode and os.fsdecode help? I've seen it somewhere. I've never used it. To fix encodings, sometimes I use the module ftfy Greetings Andre -- https://mail.python.org/mailman/listinfo/python-list

  1   2   3   4   5   6   7   >