Re: pathlib.Path.is_file vs os.path.isfile difference

> On 10 Mar 2024, at 14:49, Thomas Passin via Python-list > wrote: > > That and there's a registry setting: > > https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation > Yep that and rules about size of parts of the path. Barry --

Re: pathlib.Path.is_file vs os.path.isfile difference

On 3/10/2024 9:33 AM, Albert-Jan Roskam wrote: On Mar 10, 2024 12:59, Thomas Passin via Python-list wrote: On 3/10/2024 6:17 AM, Barry wrote: > > >> On 8 Mar 2024, at 23:19, Thomas Passin via Python-list wrote: >> >> We just learned a few posts back that

Re: pathlib.Path.is_file vs os.path.isfile difference

On Mar 10, 2024 12:59, Thomas Passin via Python-list wrote: On 3/10/2024 6:17 AM, Barry wrote: > > >> On 8 Mar 2024, at 23:19, Thomas Passin via Python-list wrote: >> >> We just learned a few posts back that it might be specific to Linux; I ran it

Re: pathlib.Path.is_file vs os.path.isfile difference

On 3/10/2024 6:17 AM, Barry wrote: On 8 Mar 2024, at 23:19, Thomas Passin via Python-list wrote: We just learned a few posts back that it might be specific to Linux; I ran it on Windows. Depending on the exact win32 api used there is a 257 limit on windows. The 257 includes 2 for the

Re: pathlib.Path.is_file vs os.path.isfile difference

> On 8 Mar 2024, at 23:19, Thomas Passin via Python-list > wrote: > > We just learned a few posts back that it might be specific to Linux; I ran it > on Windows. Depending on the exact win32 api used there is a 257 limit on windows. The 257 includes 2 for the device, C:, and 255 for the

Re: pathlib.Path.is_file vs os.path.isfile difference

On 2024-03-08, Thomas Passin via Python-list wrote: > >> Hi, I tested this with Python 3.8. Good to know that this was fixed! > > We just learned a few posts back that it might be specific to Linux; I > ran it on Windows. On Linux, the limit is imposed by the filesystem. Most of the "real"

Re: pathlib.Path.is_file vs os.path.isfile difference

Path(256 * "x").is_file()  # OSError > os.path.isfile(256 * "x")  # bool > Is this intended? Does pathlib try to resemble os.path as closely as > possible? You must have an very old version of Python.  I'm running 3.

Re: pathlib.Path.is_file vs os.path.isfile difference

s_file() # OSError > os.path.isfile(256 * "x") # bool > Is this intended? Does pathlib try to resemble os.path as closely as > possible? You must have an very old version of Python. I'm running 3.12.2 and it returns False. Either that or that path

Re: pathlib.Path.is_file vs os.path.isfile difference

;).is_file() # OSError os.path.isfile(256 * "x") # bool Is this intended? Does pathlib try to resemble os.path as closely as possible? You must have an very old version of Python. I'm running 3.12.2 and it returns False. It throws OSError with Python 3.11.8 on Linux. Sorry

Re: pathlib.Path.is_file vs os.path.isfile difference

On 2024-03-08, Grant Edwards via Python-list wrote: >> OSError: [Errno 36] File name too long: >>

Re: pathlib.Path.is_file vs os.path.isfile difference

>> Path(256 * "x").is_file() # OSError >>> os.path.isfile(256 * "x") # bool >>> Is this intended? Does pathlib try to resemble os.path as closely as >>> possible? >> >> You must have an very old version of Python.

Re: pathlib.Path.is_file vs os.path.isfile difference

On 2024-03-08, Thomas Passin via Python-list wrote: > On 3/8/2024 1:03 PM, Albert-Jan Roskam via Python-list wrote: >> Hi, >> I was replacing some os.path stuff with Pathlib and I discovered this: >> Path(256 * "x").is_file() # OSError >>

Re: pathlib.Path.is_file vs os.path.isfile difference

On 3/8/2024 1:03 PM, Albert-Jan Roskam via Python-list wrote: Hi, I was replacing some os.path stuff with Pathlib and I discovered this: Path(256 * "x").is_file() # OSError os.path.isfile(256 * "x") # bool Is this intended? Does pathlib try to resembl

pathlib.Path.is_file vs os.path.isfile difference

Hi, I was replacing some os.path stuff with Pathlib and I discovered this: Path(256 * "x").is_file() # OSError os.path.isfile(256 * "x") # bool Is this intended? Does pathlib try to resemble os.path as closely as possible? Best wishes,

[issue45013] os.path.isfile fails on path exactly 260 Chars long in Windows

Change by Steve Dower : -- resolution: -> third party stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue45013] os.path.isfile fails on path exactly 260 Chars long in Windows

Luke Rossi added the comment: What an annoying edge case - makes sense that there isn't an easy fix. The extended path prefix worked perfectly - thanks -- ___ Python tracker

[issue45013] os.path.isfile fails on path exactly 260 Chars long in Windows

Eryk Sun added the comment: The legacy maximum buffer size is 260 characters, but remember that strings in C are terminated by a null character (i.e. "\0"). So the maximum path length is actually 259 characters when opening files. In Windows 10 with Python 3.6+, you can enable the

[issue45013] os.path.isfile fails on path exactly 260 Chars long in Windows

Luke Rossi added the comment: I saw 33105, but believe this to be a different issue as path length 260 is valid. I did testing by crafting a path that is exactly 260 by hand - A path 259 in length reports .isfile() as True. The Stack Error: [WinError 3] The system cannot find the path

[issue45013] os.path.isfile fails on path exactly 260 Chars long in Windows

: serhiy.storchaka, ubermidget2 priority: normal severity: normal status: open title: os.path.isfile fails on path exactly 260 Chars long in Windows type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue45

[issue33105] os.path.isfile returns false on Windows when file path is longer than 260 characters

Eryk Sun added the comment: I'm closing this as not a bug. If the process limits DOS paths to MAX_PATH, then checking os.path.isfile() should not be special cased to support longer DOS paths because calling open() on such a path will raise FileNotFoundError. My suggestion in msg314126

[issue37436] os.path.isfile() with big number cause OverflowError: fd is greater than maximum

Serhiy Storchaka added the comment: I considered this. There is a limited number of functions that can produce RawFD (os.open(), os.dup(), etc), and this is a single source of file descriptors in an isolated program. File descriptors can be inherited by child processes. But there are other

[issue37436] os.path.isfile() with big number cause OverflowError: fd is greater than maximum

Zufu Liu added the comment: I'm fine with this been closed. Maybe it's better to have a RawFd type like Julia: julia> RawFD RawFD julia> typeof(RawFD) DataType julia> RawFD(0) RawFD(0x) julia> RawFD(0)==0 false Rust has RawFd as c_int. --

[issue37436] os.path.isfile() with big number cause OverflowError: fd is greater than maximum

Change by Serhiy Storchaka : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue37436] os.path.isfile() with big number cause OverflowError: fd is greater than maximum

Anj-A <2017...@gmail.com> added the comment: Hey, if there is no bug here, could we get this issue closed? Alternatively, I'd be interested in doing the required change in documentation/error type if that's seen to be the right solution. Personally, I think returning False instead of raising

[issue37436] os.path.isfile() with big number cause OverflowError: fd is greater than maximum

Serhiy Storchaka added the comment: I am not sure there is much in common between this and issue33721. There are many ways to get a file path unrepresentable at the OS level. But I do not know any valid case for getting an out-of-range file descriptor. I am not convinced there is a bug

[issue37436] os.path.isfile() with big number cause OverflowError: fd is greater than maximum

Anj-A <2017...@gmail.com> added the comment: Hey, I'm not exactly clear what the required fix is here and would appreciate some guidance, is it in the documentation or in the way the error is handled? -- ___ Python tracker

[issue37436] os.path.isfile() with big number cause OverflowError: fd is greater than maximum

STINNER Victor added the comment: This issue reminds me bpo-33721: "os.path functions that return a boolean result like exists(), lexists(), isdir(), isfile(), islink(), and ismount() now return False instead of raising ValueError or its subclasses UnicodeEncodeError and UnicodeDecodeError

[issue37436] os.path.isfile() with big number cause OverflowError: fd is greater than maximum

Anj-A <2017...@gmail.com> added the comment: Hi all, I'm a newcomer interested in doing a small fix. Wondering if anyone's working on this at the moment? -- nosy: +Anj-A ___ Python tracker

[issue37436] os.path.isfile() with big number cause OverflowError: fd is greater than maximum

quot;credits" or "license" for more information. >>> class MyInt(int):pass ... >>> a=MyInt(6) >>> a 6 >>> import os.path >>> os.path.isfile(a) False >>> os.path.isfile(True) False >>> os.path.isfile(False) False >&

[issue37436] os.path.isfile() with big number cause OverflowError: fd is greater than maximum

Zufu Liu added the comment: Personally I prefer TypeError. Use file descriptor is rare, I never used it in Python script. I encountered this because arguments passed in wrong order in my function, then I passed the wrong argument to isfile() without checking. Make isfile() returns False

[issue37436] os.path.isfile() with big number cause OverflowError: fd is greater than maximum

Steve Dower added the comment: You use this by getting the file descriptor/fileno for an open file, and then testing whether it's a file or not: >>> f=open("python.bat") >>> f.fileno() 3 >>> import os >>> os.path.isfile(3) True This i

[issue37436] os.path.isfile() with big number cause OverflowError: fd is greater than maximum

, False otherwise. in posixmodule.c: * path_converter also optionally accepts signed * integers (representing open file descriptors) instead * of path strings. although i dunno how to use then: $ echo "test" > 123 $ ls -i 123 8012691 123 $ ./python -c "import os.path; pr

[issue37436] os.path.isfile() with big number cause OverflowError: fd is greater than maximum

"copyright", "credits" or "license" for more information. >>> import os.path >>> os.path.isfile(123) False >>> os.path.isfile(2**32) Traceback (most recent call last): File "", line 1, in File "D:\Dev\Python3\lib\genericpat

[issue33105] os.path.isfile returns false on Windows when file path is longer than 260 characters

Eryk Sun added the comment: > If you use os.listdir() on the networked folder, the log file > will come up. Querying a file's parent directory (e.g. via os.scandir in Python 3) can provide a basic stat (i.e. attributes, reparse tag, size, and timestamps) when opening the

[issue33105] os.path.isfile returns false on Windows when file path is longer than 260 characters

h(). For example: f1_path = os.path.normpath(u"//?/UNC/tst/tc/proj/MTV/cs_fft/Milo/Fries/STL/BLNA/F1") log_path = os.path.join(f1_path, log_filename) assert os.path.isfile(log_path) -- nosy: +eryksun title: os.isfile returns false on Windows when file path is l

Re: os.path.isfile

On Sun, Feb 12, 2017 at 4:29 AM, Chris Angelico wrote: > Registry subkeys aren't paths, and the other two cases are extremely > narrow. Convert slashes to backslashes ONLY in the cases where you > actually need to. \\?\ paths are required to exceed MAX_PATH (a paltry 260

Re: os.path.isfile

On Mon, 13 Feb 2017 11:43 am, Chris Angelico wrote: > On Mon, Feb 13, 2017 at 11:40 AM, Erik wrote: >> FWIW, if you'd have written the above as your first response I wouldn't >> have argued ;) You alluded to it, for sure ... :D > > Nothing wrong with respectfully

Re: os.path.isfile

On Mon, Feb 13, 2017 at 11:40 AM, Erik wrote: > FWIW, if you'd have written the above as your first response I wouldn't have > argued ;) You alluded to it, for sure ... :D Nothing wrong with respectfully arguing. It's one of the best ways to zero in on the truth :)

Re: os.path.isfile

On 13/02/17 00:34, Chris Angelico wrote: The unit "\t" always means U+0009, even if it's following a raw string literal; and the unit "\d" always means "\\d", regardless of the rawness of any of the literals involved. The thing that's biting you here is that unrecognized escapes get rendered as

Re: os.path.isfile

On Mon, Feb 13, 2017 at 11:34 AM, Erik wrote: > OK, I get it now - because '\d' is not a valid escape sequence, then even in > a non-raw string literal, the '\' is treated as a literal backslash > character (not an escape). > > So, the second string token is NOT being

Re: os.path.isfile

On 13/02/17 00:23, Erik wrote: r"hello \the" "worl\d" "\t" 'hello \\theworl\\d\t' The initial string is raw. The following string adopts that (same as the second example), but the _next_ string does not! Why is the first string token parsed as a "raw" string, the second string token also

Re: os.path.isfile

On Mon, Feb 13, 2017 at 11:29 AM, Erik wrote: > On 13/02/17 00:13, Chris Angelico wrote: >> >> On Mon, Feb 13, 2017 at 11:11 AM, Chris Angelico wrote: >>> >>> The string "\t" gets shown in the repr as "\t". It is a string >>> consisting of one

Re: os.path.isfile

On 13/02/17 00:13, Chris Angelico wrote: On Mon, Feb 13, 2017 at 11:11 AM, Chris Angelico wrote: The string "\t" gets shown in the repr as "\t". It is a string consisting of one character, U+0009, a tab. The string r"\t" is shown as "\\t" and consists of two characters,

Re: os.path.isfile

On 13/02/17 00:11, Chris Angelico wrote: Firstly, be aware that there's no such thing as a "raw string" - what you have is a "raw string literal". It's a purely syntactic feature. I do understand that. When I said "is raw"/"rawness", I am talking about what the _parser_ is doing. I don't

Re: os.path.isfile

On Mon, Feb 13, 2017 at 11:11 AM, Chris Angelico wrote: > The string "\t" gets shown in the repr as "\t". It is a string > consisting of one character, U+0009, a tab. The string r"\t" is shown > as "\\t" and consists of two characters, REVERSE SOLIDUS and LATIN > SMALL LETTER T.

Re: os.path.isfile

On Mon, Feb 13, 2017 at 10:56 AM, Erik wrote: > Actually, while contriving those examples, I noticed that sometimes when > using string literal concatenation, the 'rawness' of the initial string is > sometimes applied to the following string and sometimes not: >

Re: os.path.isfile

On 12/02/17 23:56, Erik wrote: r"hello \the" "worl\d" 'hello \\theworl\\d' Slightly surprising. The concatenated string adopts the initial string's 'rawness'. "hello \the" r"worl\d" "\t" 'hello \theworl\\d\t' The initial string is not raw, the following string is. The string following

Re: os.path.isfile

On 12/02/17 04:53, Steve D'Aprano wrote: py> s = r'documents\' File "", line 1 s = r'documents\' ^ SyntaxError: EOL while scanning string literal (I still don't understand why this isn't just treated as a bug in raw string parsing and fixed...) I would imagine that

Re: os.path.isfile

On Sun, 12 Feb 2017 03:20 pm, eryk sun wrote: > On Sun, Feb 12, 2017 at 3:52 AM, Steve D'Aprano > wrote: >> In Python, you should always use forward slashes for paths, even on >> Windows. > > There are cases where slash doesn't work (e.g. some command lines; > \\?\

Re: os.path.isfile

On Sun, Feb 12, 2017 at 3:20 PM, eryk sun wrote: > On Sun, Feb 12, 2017 at 3:52 AM, Steve D'Aprano > wrote: >> In Python, you should always use forward slashes for paths, even on Windows. > > There are cases where slash doesn't work (e.g. some

Re: os.path.isfile

On Sun, Feb 12, 2017 at 3:52 AM, Steve D'Aprano wrote: > In Python, you should always use forward slashes for paths, even on Windows. There are cases where slash doesn't work (e.g. some command lines; \\?\ prefixed paths; registry subkey paths), so it's simpler to

Re: os.path.isfile

On Sat, 11 Feb 2017 05:11 am, epro...@gmail.com wrote: > Hello NG > > Python 3.5.2 > > Windows 10 > > os.path.isfile() no recognise file with double dot? > > eg. match.cpython-35.pyc I doubt that very much. I expect you are probably writing something like t

Re: os.path.isfile

On Sat, 11 Feb 2017 06:50 am, Vincent Vande Vyvre wrote: > Le 10/02/17 à 19:11, epro...@gmail.com a écrit : >> Hello NG >> >> Python 3.5.2 >> >> Windows 10 >> >> os.path.isfile() no recognise file with double dot? >> >> eg. match.

Re: os.path.isfile

ail.com a écrit : >>>>> >>>>> Python 3.5.2 >>>>> >>>>> Windows 10 >>>>> >>>>> os.path.isfile() no recognise file with double dot? >>>>> >>>>> eg. match.cpython-35.pyc >>>>

Re: os.path.isfile

Le 10/02/17 à 22:03, Vincent Vande Vyvre a écrit : Le 10/02/17 à 21:36, Peter Otten a écrit : Vincent Vande Vyvre wrote: Le 10/02/17 à 19:11, epro...@gmail.com a écrit : Hello NG Python 3.5.2 Windows 10 os.path.isfile() no recognise file with double dot? eg. match.cpython-35.pyc Please

Re: os.path.isfile

Le 10/02/17 à 21:36, Peter Otten a écrit : Vincent Vande Vyvre wrote: Le 10/02/17 à 19:11, epro...@gmail.com a écrit : Hello NG Python 3.5.2 Windows 10 os.path.isfile() no recognise file with double dot? eg. match.cpython-35.pyc Please somebody know something about that? Thank You

Re: os.path.isfile

Vincent Vande Vyvre wrote: > Le 10/02/17 à 19:11, epro...@gmail.com a écrit : >> Hello NG >> >> Python 3.5.2 >> >> Windows 10 >> >> os.path.isfile() no recognise file with double dot? >> >> eg. match.cpython-35.pyc >> >>

Re: os.path.isfile

On 2017-02-10 19:50, Vincent Vande Vyvre wrote: Le 10/02/17 à 19:11, epro...@gmail.com a écrit : Hello NG Python 3.5.2 Windows 10 os.path.isfile() no recognise file with double dot? eg. match.cpython-35.pyc Please somebody know something about that? Thank You in advance Interesting

Re: os.path.isfile

; or "license" for more information. >>>> import os >>>> >>>> os.path.isfile('/home/vincent/oqapy-3/trunk/__pycache__/grid.cpython-34.pyc >>>> ') > False Works on my system, in 3.4, 3.5, 3.6, and 3.7: Python 3.4.4 (default, Apr 17 2016, 16:02:33) [G

Re: os.path.isfile

Le 10/02/17 à 19:11, epro...@gmail.com a écrit : Hello NG Python 3.5.2 Windows 10 os.path.isfile() no recognise file with double dot? eg. match.cpython-35.pyc Please somebody know something about that? Thank You in advance Interesting, you're right. Python 3.4.3 (default, Nov 17 2016

os.path.isfile

Hello NG Python 3.5.2 Windows 10 os.path.isfile() no recognise file with double dot? eg. match.cpython-35.pyc Please somebody know something about that? Thank You in advance -- https://mail.python.org/mailman/listinfo/python-list

[issue22719] os.path.isfile os.path.exists bug in while loop

Aaron added the comment: Python 3.3.0, Windows 7, both 64 bit. Has it been resolved with the newer version, then? On Mon, Nov 3, 2014 at 11:15 PM, Zachary Ware rep...@bugs.python.org wrote: Zachary Ware added the comment: Aaron, what version of Python are you using on what version of

[issue22719] os.path.isfile os.path.exists bug in while loop

Zachary Ware added the comment: I haven't built 3.3.0 again yet to try to reproduce with it, but there have been enough bug and security fixes in the more recent 3.3 releases that I'd strongly advise updating on general principle and seeing if this issue goes away. If not to 3.4.2, at least to

[issue22719] os.path.isfile os.path.exists bug in while loop

Zachary Ware added the comment: I have had a chance to build 3.3.0 and I was able to reproduce the bug with it, so it is in fact fixed in later versions. -- resolution: - out of date stage: - resolved status: open - closed ___ Python tracker

[issue22719] os.path.isfile os.path.exists bug in while loop

Zachary Ware added the comment: Aaron, what version of Python are you using on what version of Windows? Also, 32 or 64 bit on both? I can't reproduce this with any Python 3.3.6 or newer on 64-bit Windows 8.1. -- ___ Python tracker

[issue22719] os.path.isfile os.path.exists but in while loop

New submission from Aaron: When using os.path.isfile() and os.path.exists() in a while loop under certain conditions, os.path.isfile() returns True for paths that do not actually exist. Conditions: The folder C:\Users\EAARHOS\Desktop\Python Review exists, as do the files C:\Users\EAARHOS

[issue22719] os.path.isfile os.path.exists bug in while loop

Changes by Aaron hosfor...@gmail.com: -- title: os.path.isfile os.path.exists but in while loop - os.path.isfile os.path.exists bug in while loop ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22719

[issue22719] os.path.isfile os.path.exists bug in while loop

R. David Murray added the comment: Interesting bug. The obvious difference between the two cases is that in the += version the address of the string pointing to the filepath doesn't change, whereas when you use a temp variable it does (there's an optimization in += that reuses the same

[issue22719] os.path.isfile os.path.exists bug in while loop

Steve Dower added the comment: I wonder whether the same thing occurs if you're not appending a new extension each time? There could be some optimisation (from the dark old days of 8.3 filename) that compares baseExcel and .bak separately and assumes that the name is known. Last I looked at

[issue22719] os.path.isfile os.path.exists bug in while loop

Serhiy Storchaka added the comment: Could we encode both paths to the unicode_internal encoding and check if results are equal? -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22719

[issue22719] os.path.isfile os.path.exists bug in while loop

R. David Murray added the comment: Looking at the code, it looks like it calls the win32 api directly if path-wide is true, which I'm guessing is the case unless you are using bytes paths in windows? It looks like the critical call, then, is CreateFileA (why A in a _w method I have no

[issue22719] os.path.isfile os.path.exists bug in while loop

eryksun added the comment: What do you get for os.stat? bak_path = rC:\Users\EAARHOS\Desktop\Python Review\baseExcel.py print(os.stat(bak_path)) bak_path += '.bak' print(os.stat(bak_path)) bak_path += '.bak' print(os.stat(bak_path)) # This should raise FileNotFoundError

[issue22719] os.path.isfile os.path.exists bug in while loop

Aaron added the comment: Interesting. It continues to reuse the last one's stats once the path is no longer valid. bak_path = rC:\Users\EAARHOS\Desktop\Python Review\baseExcel.py print(os.stat(bak_path)) nt.stat_result(st_mode=33206, st_ino=8162774324652726, st_dev=0, st_nlink=1, st_uid=0,

[issue22719] os.path.isfile os.path.exists bug in while loop

Aaron added the comment: If I use a separate temp variable, the bug doesn't show, but if I use the same variable, even with + instead of +=, it still happens. bak_path = rC:\Users\EAARHOS\Desktop\Python Review\baseExcel.py print(os.stat(bak_path)) nt.stat_result(st_mode=33206,

[issue22719] os.path.isfile os.path.exists bug in while loop

eryksun added the comment: When appending to a singly-referenced string, the interpreter tries to reallocate the string in place. This applies to both `s += 'text'` and `s = s + 'text'`. Storing to a temp variable is adding a 2nd reference, so a new string gets allocated instead. If the

[issue22719] os.path.isfile os.path.exists bug in while loop

eryksun added the comment: i.e. the object id is the same after appending Actually, that's wrong. bak_path is a compact string. So the whole object is realloc'd, and the base address (i.e. id) could change. Check PyUnicode_AsUnicode even if the id changes. --

[issue17212] os.path.isfile() in Python 3.3 sometimes fails

Georg Brandl added the comment: Closing due to lack of feedback. -- nosy: +georg.brandl status: pending - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17212 ___

[issue17212] os.path.isfile() in Python 3.3 sometimes fails

Terry J. Reedy added the comment: #17137 has a patch that will be in 3.3.1, coming soon we hope. If you cannot build Python on Windows, please retest with the new release. -- nosy: +terry.reedy ___ Python tracker rep...@bugs.python.org

[issue17212] os.path.isfile() in Python 3.3 sometimes fails

Changes by Ezio Melotti ezio.melo...@gmail.com: -- resolution: - duplicate status: open - pending superseder: - Malfunctioning compiled code in Python 3.3 x64 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17212

[issue17212] os.path.isfile() in Python 3.3 sometimes fails

Changes by Antoine Pitrou pit...@free.fr: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17212 ___ ___ Python-bugs-list mailing

[issue17212] os.path.isfile() in Python 3.3 sometimes fails

STINNER Victor added the comment: Looks like a duplicate of issue #17137. Le 17 févr. 2013 23:08, Antoine Pitrou rep...@bugs.python.org a écrit : Changes by Antoine Pitrou pit...@free.fr: -- nosy: +haypo ___ Python tracker

[issue17212] os.path.isfile() in Python 3.3 sometimes fails

New submission from G. Poore: os.path.isfile() sometimes incorrectly reports that a file does not exist under Python 3.3 (only tested under Windows). This may be encoding related. The issue only appears under a very particular set of circumstances; see comments in the attached script

[issue14985] os.path.isfile and os.path.isdir inconsistent on OSX Lion

New submission from Adrian Bastholm javahax...@gmail.com: os.path.isfile doesn't reckognize a .picasa.ini file as a file and os.path.isdir doesn't reckognize a directory as a directory code: def traverse (targetDir): currentDir = targetDir dirs = os.listdir(targetDir) #dirs = [x

[issue14985] os.path.isfile and os.path.isdir inconsistent on OSX Lion

Hynek Schlawack h...@ox.cx added the comment: I think your problem is a different one: os.listdir() doesn't return full paths and os.path.isfile()/isdir() return False if the supplied path doesn't exist. For example if you have this directory structure: foo/ foo/bar/ foo/bar/baz Calling

[issue14985] os.path.isfile and os.path.isdir inconsistent on OSX Lion

= os.listdir(targetDir) for entry in dirs: if os.path.isdir(os.path.join(currentDir,entry)): print(Traversing + os.path.join(targetDir,entry)) traverse(os.path.join(targetDir,entry)) else: if os.path.isfile(os.path.join(targetDir,entry

os.path.isfile and wildcard for directory name

Hi everyone, I'm just beginning to learn python language and i'm trying to do something and i can't figure it out. I want to test if a file exists but my path contain a directory name that differs from a server to another. In shell i would have done something like that : #!/bin/bash

Re: os.path.isfile and wildcard for directory name

Hello, 2010/12/30 smain...@free.fr: How can i do the same thing (wildcard in a directory name) in python please ? You can get the contents of a directory with os.listdir and filter with fnmatch.fnmatch more or less as in the example from the documentation: - import fnmatch

Re: os.path.isfile and wildcard for directory name

| if [ -f $mypath/$myfile ] [...] Check out the glob module: http://docs.python.org/library/glob.html#module-glob Use it to do the glob, then os.path.isfile with a path constructed from the result: http://docs.python.org/library/os.path.html#os.path.isfile Cheers, -- Cameron Simpson c

Re: os.path.isfile and wildcard for directory name

}/alpha You can get a list of candidates with import glob candidates = glob.glob(yadda*/alpha) candidates ['yadda5/alpha', 'yadda2/alpha', 'yadda4/alpha', 'yadda7/alpha'] and then use isfile() to find the actual files: import os [f for f in candidates if os.path.isfile(f)] ['yadda5/alpha

Re: os.path.isfile and wildcard for directory name

something like that : | #!/bin/bash | mypath=/dire*/directory02/ | myfile=filename | myfile=toto | if [ -f $mypath/$myfile ] [...] Check out the glob module: http://docs.python.org/library/glob.html#module-glob Use it to do the glob, then os.path.isfile with a path constructed from

[issue10754] os.path.isfile doesn't work with some greek characters

New submission from Wang Yanjin wyj1...@gmail.com: There is a file named µTorrent.lnk in the folder. Here is the code: #encoding=utf-8 import os for i in os.listdir('.'): print os.path.isfile(i), '\t', i a = input() and the output: True3.py False aμ汉字.txt TrueuTorrent.lnk

[issue10754] os.path.isfile doesn't work with some greek characters

R. David Murray rdmur...@bitdance.com added the comment: I am unable to reproduce this on any python from py3k trunk down to 2.6.6. Can you provide a complete test program that demonstrates the failure? (That is, it creates the file and then fails to detect it as a file with isfile.)

[issue10754] os.path.isfile doesn't work with some greek characters

R. David Murray rdmur...@bitdance.com added the comment: Oh, yes, and it is likely to be important to know what OS you are on. I tested on linux. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10754

[issue10754] os.path.isfile doesn't work with some greek characters

Wang Yanjin wyj1...@gmail.com added the comment: I encoutered this problem on Winxp sp3. I have retested it on the win7, and it could return the correct value as it did on linux. -- ___ Python tracker rep...@bugs.python.org

[issue10754] os.path.isfile doesn't work with some greek characters

R. David Murray rdmur...@bitdance.com added the comment: Since the os functions tend to be small wrappers around system functions, this sounds like it is probably a platform issue and not a Python issue. I'm adding our windows experts as nosy, they can reopen the issue if they disagree.

[issue10754] os.path.isfile doesn't work with some greek characters

Alexander Belopolsky belopol...@users.sourceforge.net added the comment: Just a random thought (no, I don't know anything about Windows): there are two mu characters: GREEK SMALL LETTER MU (μ) and MICRO SIGN (µ). Normalization turns one into the other: from unicodedata import *

[issue10754] os.path.isfile doesn't work with some greek characters

Martin v. Löwis mar...@v.loewis.de added the comment: On Windows, using the bytes APIs for filenames is unreliable and fails for characters that are not in the ANSI code page. So you should use import os for i in os.listdir(u'.'): print os.path.isfile(i), '\t', i instead. -- nosy

os.path.isfile()

Here is a program to print out the files in a directory: --- import os myfiles = os.listdir(../) print myfiles for afile in myfiles: print afile if os.path.isfile(afile): print afile, ___file if os.path.isdir(afile): print afile, ___dir print

Re: os.path.isfile()

7stud [EMAIL PROTECTED] wrote: Here is a program to print out the files in a directory: --- import os myfiles = os.listdir(../) print myfiles for afile in myfiles: print afile if os.path.isfile(afile): print afile, ___file if os.path.isdir(afile

Re: os.path.isfile()

On Jul 1, 3:36 am, Duncan Booth [EMAIL PROTECTED] wrote: 7stud [EMAIL PROTECTED] wrote: Here is a program to print out the files in a directory: --- import os myfiles = os.listdir(../) print myfiles for afile in myfiles: print afile if os.path.isfile(afile

  1   2   >