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 cha
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 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'
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 a
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
On 04/05/10 03:25, Grant Edwards wrote:
On 2010-05-04, Charles 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 elegant.
but probably makes some
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 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 th
On 04/05/10 03:19, Grant Edwards wrote:
On 2010-05-03, Baz Walter 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 "open
On 04/05/10 02:12, Ben Finney wrote:
Baz Walter 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
link.
i'm
On 03/05/10 19:12, Grant Edwards wrote:
On 2010-05-03, Baz Walter 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&
On 03/05/10 19:05, Chris Rebert wrote:
On Mon, May 3, 2010 at 10:45 AM, Baz Walter wrote:
On 03/05/10 18:12, Grant Edwards wrote:
On 2010-05-03, Baz Walterwrote:
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.
On 03/05/10 18:41, Grant Edwards wrote:
On 2010-05-03, Baz Walter 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. i fo
On 03/05/10 18:12, Grant Edwards wrote:
On 2010-05-03, Baz Walter 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 open a
On 03/05/10 15:24, Grant Edwards wrote:
On 2010-05-03, Baz Walter 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*, /home/baz/tmp/ (just chop
On 03/05/10 15:55, Grant Edwards wrote:
On 2010-05-03, Baz Walter 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 th
On 03/05/10 15:56, Grant Edwards wrote:
On 2010-05-03, Baz Walter 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 tentative
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 reproduc
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: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 h
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'
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.
--
http://mail.python.org/mailman/listin
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'))
>>> repr(
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 :-|
--
http://mail.python.o
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
overall results for generators? 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
John Machin 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 over whethe
Fredrik Lundh 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 on Py
Fredrik Lundh 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
Guilherme Polo 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 some
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 of
Anthony Liu 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 well, an
32 matches
Mail list logo
