> 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
--
https://mail.python.org/mailm
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 it
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 on
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 dev
> 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 pat
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"
file
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.12.2 and
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
;).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.
On 2024-03-08, Grant Edwards via Python-list wrote:
>> OSError: [Errno 36] File name too long:
>> 'x
>> 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.
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
>>
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 resemble o
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,
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 characters)
or to avoid q
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 arguing. It's one of the best wa
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 :)
ChrisA
--
https://mail.python
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 b
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 treated as "raw", it just loo
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 pars
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 character, U+0009, a tab. The string r"\t" is shown
>
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, REVERSE SOLIDUS and LATI
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 think
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. That might be why
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:
>
"hello \the" r"worl\d"
> 'hell
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 _that
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 i
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;
> \\?\ prefixed paths; registry subke
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 command lines;
> \\?\ prefixed paths; registry subkey
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 follow
a rule to always convert
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
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.cpyth
gt;
>>>>> Python 3.5.2
>>>>>
>>>>> Windows 10
>>>>>
>>>>> os.path.isfile() no recognise file with double dot?
>>>>>
>>>>> eg. match.cpython-35.pyc
>>>>>
>>>> Intere
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
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 in
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
>>
>>
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
On Sat, Feb 11, 2017 at 6:50 AM, Vincent Vande Vyvre
wrote:
> Interesting, you're right.
>
> Python 3.4.3 (default, Nov 17 2016, 01:08:31)
> [GCC 4.8.4] on linux
> Type "help", "copyright", "credits" or "license" for more information.
&g
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
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
mething 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.pat
'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', 'yadda7/alpha']
Peter
--
http://mail.python.org/mailman/listinfo/python-list
$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 DoD#743
http
Hello,
2010/12/30 :
> 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
import os
for f
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
mypath=/d
es
>
> > for afile in myfiles:
> > print afile
> > if os.path.isfile(afile):
> > print afile, "___file"
> > if os.path.isdir(afile):
> > print afile, "___dir"
> > print
> >
>
>
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(
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
On Jun 6, 12:30 pm, "Roger Upole" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Can os.path.isfile(x) ever return True after os.remove(x) has
> > successfully completed? (Windows 2003, Python 2.3)
>
> Yes. If another application has opened the fil
[EMAIL PROTECTED] wrote:
> Can os.path.isfile(x) ever return True after os.remove(x) has
> successfully completed? (Windows 2003, Python 2.3)
Yes. If another application has opened the file with FILE_SHARE_DELETE,
os.remove succeeds but the file doesn't actually disappear until th
> Don't suppose you've got some kind of flashy software
> running which intercepts OS file-manipulation calls for
> Virus or Archiving purposes?
>
> TJG
As I mentioned in another reply, this server is virtual and so is the
drive. I'm wondering if this might also be significant.
Paul
--
http://
>
> Is the file on a network drive by any chance?
>
> Diez
No, but the server is actually a VMWare VM and the drive is a virtual
drive.
I'm thinking that this may be significant as it may be that the VMWare
VHD driver is the "flashy software running which intercepts OS file-
manipulation calls" t
Thanks for the response!
>
> I'd take the time to really examine the multiple threads of work you're
> running
> to make sure one of them isn't removing the file just as another creates it.
> Better still, use a locking semaphore around the code the creates/deletes the
> file
> to guarantee mutu
Thanks for the quick and detailed response!
> The most likely bet would seem to be a race condition
> as you suggest below. Doesn't have to be from a thread
> in your program, although I assume you know best about
> your own filesystem ;)
My first thought, after discounting the os.remove early r
[EMAIL PROTECTED] wrote:
> Can os.path.isfile(x) ever return True after os.remove(x) has
> successfully completed? (Windows 2003, Python 2.3)
>
> We had a couple of failures in a server application that we cannot yet
> reproduce in a simple case. Analysis of the code suggests
[EMAIL PROTECTED] wrote:
>
> The application is multithreaded so it is possible that another thread
> writes to the file between the "remove" and the "isfile", but at the
> end of the failure the file is actually not on the filesystem and I
> don't believe there is a way that the file could be r
[EMAIL PROTECTED] wrote:
> Can os.path.isfile(x) ever return True after os.remove(x) has
> successfully completed? (Windows 2003, Python 2.3)
As an afterthought, have you tried NTFS auditing, or
directory monitoring, such as:
http://timgolden.me.uk/python/win32_ho
[EMAIL PROTECTED] wrote:
> Can os.path.isfile(x) ever return True after os.remove(x) has
> successfully completed? (Windows 2003, Python 2.3)
>
> We had a couple of failures in a server application that we cannot yet
> reproduce in a simple case. Analysis of the code suggests
Can os.path.isfile(x) ever return True after os.remove(x) has
successfully completed? (Windows 2003, Python 2.3)
We had a couple of failures in a server application that we cannot yet
reproduce in a simple case. Analysis of the code suggests that the
only possible explanation is that the
in os.listdir(mydir)]
>> pprint.pprint(files)
>>
>> print os.path.join(mydir, "helloWorld.py")
>>
>> files = [file
>> for file in os.listdir(mydir)
>> if os.path.isfile(os.path.join(dir, file) )
>> ]
>>
>> pprint.pprint(files)
>> ---
ath.join(mydir, "helloWorld.py")
>
> files = [file
> for file in os.listdir(mydir)
> if os.path.isfile(os.path.join(dir, file) )
> ]
>
> pprint.pprint(files)
> output:
>
> ['.DS_Store', 'cpTest', 'dir1', &
ath.join(mydir, "helloWorld.py")
>
> files = [file
> for file in os.listdir(mydir)
> if os.path.isfile(os.path.join(dir, file) )
> ]
>
> pprint.pprint(files)
> output:
>
> ['.DS_Store', 'cpTest', 'dir1', &
ath.join(mydir, "helloWorld.py")
>
> files = [file
> for file in os.listdir(mydir)
> if os.path.isfile(os.path.join(dir, file) )
> ]
>
> pprint.pprint(files)
> output:
>
> ['.DS_Store', 'cpTest', 'dir1', &
>
> files = [file
> for file in os.listdir(mydir)
> if os.path.isfile(os.path.join(dir, file) )
That should be mydir, not dir.
> ]
>
> pprint.pprint(files)
> output:
>
> ['.DS_Store', 'cpTest', 'dir1', 'testfile1&#
Here's the code:
import os, os.path, pprint
mydir = "/Users/me/2testing"
files = [file for file in os.listdir(mydir)]
pprint.pprint(files)
print os.path.join(mydir, "helloWorld.py")
files = [file
for file in os.listdir(mydir)
if os.path.isfi
> Boudreau, Emile wrote:
(snip)
>> I have tried variations of: os.path.isfile( os.path.join("C:\\temp\\",
>> "rqp-win32-app", "*.tar.gz"))
As a side note, the whole point of os.path is to help writing portable
code. So passing an os.specific p
t;startOfString" + some version number + "inst.tar.gz"
> (component-8.3.16-inst.tar.gz) The version number will change quite
> frequently so I just want to check if there is a file with that format name.
>
> I have tried variations of: os.path.isfile( os.path.join("C:\\temp
t;startOfString" + some version number + "inst.tar.gz"
> (component-8.3.16-inst.tar.gz) The version number will change quite
> frequently so I just want to check if there is a file with that format name.
>
> I have tried variations of: os.path.isfile( os.path.join("C:\\temp
(component-8.3.16-inst.tar.gz) The version number will change quite
frequently so I just want to check if there is a file with that format
name.
I have tried variations of: os.path.isfile( os.path.join("C:\\temp\\",
"rqp-win32-app", "*.tar.gz"))
but nothing seem to w
69 matches
Mail list logo
