the python docs say that re.LOCALE makes certain character classes
dependent on the current locale.
here's what i currently see on my system:
import re, locale
locale.getdefaultlocale()
('en_GB', 'UTF8')
locale.getlocale()
(None, None)
re.findall(r'\w', u'a b c \xe5 \xe6 \xe7', re.L)
On 03/08/10 19:40, MRAB wrote:
Baz Walter wrote:
the python docs say that re.LOCALE makes certain character classes
dependent on the current locale.
re.LOCALE just passes the character to the underlying C library. It
really only works on bytestrings which have 1 byte per character.
the re
On 03/08/10 21:24, MRAB wrote:
And, BTW, none of your examples pass a UTF-8 bytestring to re.findall:
all those string literals starting with the 'u' prefix are Unicode
strings!
not sure what you mean by this: if the string was encoded as utf8,
'\w' still wouldn't match any of the non-ascii
On 05/05/10 07:24, Nobody wrote:
On Wed, 05 May 2010 02:41:09 +0100, Baz Walter wrote:
i think the algorithm also can't guarantee the intended result when
crossing filesystem boundaries. IIUC, a stat() call on the root directory
of a mounted filesystem will give the same inode number as its
On 04/05/10 02:12, Ben Finney wrote:
Baz Walterbaz...@ftml.net writes:
On 03/05/10 18:41, Grant Edwards wrote:
Firstly, a file may have any number of paths (including 0).
yes, of course. i forgot about hard links
Rather, you forgot that *every* entry that references a file is a hard
On 04/05/10 03:19, Grant Edwards wrote:
On 2010-05-03, Baz Walterbaz...@ftml.net wrote:
On 03/05/10 19:12, Grant Edwards wrote:
Even though the user provided a legal and openable path?
that sounds like an operational definition to me: what's the
difference between legal and openable?
On 04/05/10 09:23, Gregory Ewing wrote:
Grant Edwards wrote:
In your example, it's simply not possible to determine the file's
absolute path within the filesystem given the relative path you
provided.
Actually, I think it *is* theoretically possible to find an
absolute path for the file in
On 04/05/10 09:08, Gregory Ewing wrote:
Grant Edwards wrote:
except that Python objects can form a generalized graph, and Unix
filesystems are constrained to be a tree.
Actually I believe that root is allowed to create arbitrary
hard links to directories in Unix, so it's possible to turn
the
On 04/05/10 03:25, Grant Edwards wrote:
On 2010-05-04, Charlesc.sand...@deletethis.bom.gov.au wrote:
I don't see how it's inelegant at all. Perhaps it's
counter-intuitive if you don't understand how a Unix filesystem
works, but the underlying filesystem model is very simple, regular,
and
On 05/05/10 00:44, Nobody wrote:
On Tue, 04 May 2010 14:36:06 +0100, Baz Walter wrote:
this will work so long as the file is in a part of the filesystem that can
be traversed from the current directory to the root. what i'm not sure
about is whether it's possible to cross filesystem boundaries
Python 2.6.4 (r264:75706, Mar 7 2010, 02:18:40)
[GCC 4.4.1] on linux2
Type help, copyright, credits or license for more information.
import os
os.mkdir('/home/baz/tmp/xxx')
f = open('/home/baz/tmp/abc.txt', 'w')
f.write('abc')
f.close()
os.chdir('/home/baz/tmp/xxx')
os.getcwd()
On 03/05/10 14:18, Chris Rebert wrote:
Whether or not /home/baz/tmp/xxx/ exists, we know from the very
structure and properties of directory paths that its parent directory
is, *by definition*, /home/baz/tmp/ (just chop off everything after
the second-to-last slash). I would assume this is what
On 03/05/10 14:46, Peter Otten wrote:
Baz Walter wrote:
attempting to remove the cwd would produce an error). but how can python
determine the parent directory of a directory that no longer exists?
My tentative explanation would be that the directory, namely the inode,
still exists -- only
On 03/05/10 14:56, Chris Rebert wrote:
but how does '..' get resolved in the relative path '../abc.txt'? i'm
assuming python must initially use getcwd() internally to do this, and then
if that fails it falls back on something else. but what is that something
else? is it something that is
On 03/05/10 15:56, Grant Edwards wrote:
On 2010-05-03, Baz Walterbaz...@ftml.net wrote:
On 03/05/10 14:46, Peter Otten wrote:
Baz Walter wrote:
attempting to remove the cwd would produce an error). but how can python
determine the parent directory of a directory that no longer exists?
My
On 03/05/10 15:55, Grant Edwards wrote:
On 2010-05-03, Baz Walterbaz...@ftml.net wrote:
On 03/05/10 14:56, Chris Rebert wrote:
but how does '..' get resolved in the relative path '../abc.txt'? i'm
assuming python must initially use getcwd() internally to do this, and then
if that fails it
On 03/05/10 15:24, Grant Edwards wrote:
On 2010-05-03, Baz Walterbaz...@ftml.net wrote:
On 03/05/10 14:18, Chris Rebert wrote:
Whether or not /home/baz/tmp/xxx/ exists, we know from the very
structure and properties of directory paths that its parent directory
is, *by definition*,
On 03/05/10 18:12, Grant Edwards wrote:
On 2010-05-03, Baz Walterbaz...@ftml.net wrote:
Sort of. The file in question _has_ a full path, you just can't tell
what it is based on the path you used to open it.
yes, that's exactly what i was trying to demonstrate in my OP. i can
use python to
On 03/05/10 18:41, Grant Edwards wrote:
On 2010-05-03, Baz Walterbaz...@ftml.net wrote:
i think what i'm asking for is a python function that, given, say, a
valid file descriptor, can return the file's full path.
Firstly, a file may have any number of paths (including 0).
yes, of course.
On 03/05/10 19:05, Chris Rebert wrote:
On Mon, May 3, 2010 at 10:45 AM, Baz Walterbaz...@ftml.net wrote:
On 03/05/10 18:12, Grant Edwards wrote:
On 2010-05-03, Baz Walterbaz...@ftml.netwrote:
Sort of. The file in question _has_ a full path, you just can't tell
what it is based on the
On 03/05/10 19:12, Grant Edwards wrote:
On 2010-05-03, Baz Walterbaz...@ftml.net wrote:
You requested something that wasn't possible. It failed. What do
you think should have happened?
path = '../abc.txt'
os.path.realpath(path) - OSError: [Errno 2] No such file or directory
therefore:
i am using python 2.6 on a linux box and i have some utf-16 encoded
files with crlf line-endings which i would like to open with universal
newlines.
so far, i have been unable to get this to work correctly.
for example:
open('test.txt', 'w').write(u'a\r\nb\r\n'.encode('utf-16'))
On 11/04/10 15:37, Stefan Behnel wrote:
The codecs module does not support universal newline parsing (see the
docs). You need to use the new io module instead.
thanks.
i'd completely overlooked the io module - i thought it was only in
python 2.7/3.x.
--
hello
i thought that python automatically compiled pyc files after a module is
successfully imported. what could prevent this happening?
Python 2.6.1 (r261:67515, Apr 12 2009, 03:51:25)
[GCC 4.3.2] on linux2
Type help, copyright, credits or license for more information.
import os
Peter Otten wrote:
You did not set the PYTHONDONTWRITEBYTECODE environment variable in a former
life, or did you?
thanks peter
no i didn't, but i've just discovered a script in /etc/profile.d that
did. now i'll have to try to find out how that script got in there :-|
--
? also, those first two
results for v2 look really odd - what could explain the huge difference
relative to the other generator tests for v2?
(p.s. i re-ran the tests and got very similar results)
--
Baz Walter
--
http://mail.python.org/mailman/listinfo/python-list
Hello
I remember reading somewhere (probably this list) that python may cache the
module that starts a program (e.g. 'main.py'). I'm asking because I have found
that this can sometimes cause problems when making small edits to the module.
For instance, in my current module I changed the name
Guilherme Polo ggpolo at gmail.com writes:
Uhm.. this didn't make much sense. If you say the module is cached,
then supposing you did a minor edit, and then supposing because it is
cached your application wouldn't detect the change, then I don't see
the connection with memory leak.
Bring
Fredrik Lundh fredrik at pythonware.com writes:
Baz Walter wrote:
It's hard to supply an example for this, since it is local to the machine I
am
using. The startup module would look something like this:
would look, or does look? if it doesn't look like this, what else does
Fredrik Lundh fredrik at pythonware.com writes:
So what you're concerned about is the lack of cleanup during interpreter
shutdown, not a true leak (which would result in Max widgets growing
towards infinity).
Yes, sorry about my sloppy terminology.
The problem here is that you're relying
John Machin sjmachin at lexicon.net writes:
If you execute that stuff inside a function (see below) instead of in
global scope, do you get the same effect?
Thanks for your reply.
No, running it inside a function means I can't rely on python to garbage
collect, so there will be widgets left
Anthony Liu antonyliu2002 at yahoo.com writes:
Look what I have:
$ python
Python 2.4.2 (#1, Nov 20 2005, 13:03:38)
[GCC 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk)] on linux2
Yes, I realize that I don't have readline module
available.
The same Mandrake system has Python 2.3 as
32 matches
Mail list logo
