Re: [Python-Dev] os.normpath may change the meaning of the path if it contains symbolic links?
Consider:
$ mkdir -p d/d/d
$ echo 1 > d/d/a
$ echo 2 > a
$ ln -s d/d/d x
$ python -c 'import os; print open(os.path.normpath("x/../a")).read(),'
2
$ cat x/../a
1
Jeff
pgpy3c6WUgcp4.pgp
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch Req. # 1351020 & 1351036: PythonD modifications
On Mon, Nov 21, 2005 at 06:08:45PM +1100, Ben Decker wrote: > I think the port has beed supported for three years now. I am not sure what > kind of commitment you are looking for, but the patch and software are > supplied under the same terms of liability and warranty as anything else > under the GPL. Python is not GPL software. If your patch is under the terms of the GPL, it cannot be accepted into Python. Jeff pgpMgSdWqGNaF.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patch Req. # 1351020 & 1351036: PythonD modifications
On Sat, Nov 19, 2005 at 11:06:16PM +0100, "Martin v. Löwis" wrote: > [EMAIL PROTECTED] wrote: > > I would appreciate feedback concerning these patches before the next > > "PythonD" (for DOS/DJGPP) is released. > > PEP 11 says that DOS is not supported anymore since Python 2.0. So > I am -1 on reintroducing support for it. If we have someeone who is volunteering the time to make it work, not just today but in the future as well, we shouldn't rule out re-adding support. I've taken a glance at the patch. There are probably a few things to quarrel over--for instance, it looks like a site.py change will cause python to print a blank line when it's started, and the removal of a '#define HAVE_FORK 1' in posixmodule.c---but this still doesn't mean the re-addition of DOS as a supported platform should be rejected out of hand. Jeff pgpjEOaUPEZZv.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] to_int -- oops, one step missing for use.
$ python2.4 -c 'import sys; print sys.maxint, sys.maxint == (1<<63) - 1' 9223372036854775807 True $ python2.4 test_hi_powers.py Test 0.2 of to_int 0.16 .. -- Ran 70 tests in 0.006s OK pgpq5Yx7ylgEf.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] make testall hanging on HEAD?
ditto on the "curses" problem, but test_timeout completed just fine, at least the first time around. fedora core 4, x86_64 [GCC 4.0.1 20050727 (Red Hat 4.0.1-5)] on linux2 Jeff pgpTesSunOdI7.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cross compiling python for embedded systems
There's a patch on sourceforge for cross compiling. I haven't used it personally. http://sourceforge.net/tracker/index.php?func=detail&aid=1006238&group_id=5470&atid=305470 Jeff pgpzVmD49shTu.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] AST branch update
I'm excited to see work continuing (resuming?) on the AST tree. I don't know how many machines you've been able to test the AST branch on. I have a linux/amd64 machine handy and I've tried to run the test suite with a fresh copy of the ast-branch. test_trace segfaults consistently, even when run alone. You didn't give me the impression that the failure was a segfault, so I'll include more information about it below. With '-x test_trace -x test_codecencodings_kr', I get through the testsuite run. Compared to a build of HEAD, also from today, I get additional failures in test_genexps test_grp test_pwd test_symtable and additional unexpected skips of: test_email test_email_codecs The 'pwd' and 'grp' failures look like they're due to a change not merged from HEAD. I'm not sure what to make of the 'genexps' failure. Is it just a harmless output difference? I didn't see you mention that in your message. Here is some of the relevant-looking output: $ ./python -E -tt ./Lib/test/regrtest.py [...] ** File "/usr/src/python-ast/Lib/test/test_genexps.py", line ?, in test.test_genexps.__test__.doctests Failed example: (y for y in (1,2)) = 10 Expected: Traceback (most recent call last): ... SyntaxError: assign to generator expression not possible Got: Traceback (most recent call last): File "/usr/src/python-ast/Lib/doctest.py", line 1243, in __run compileflags, 1) in test.globs File "", line 1 SyntaxError: assignment to generator expression not possible (, line 1) ** File "/usr/src/python-ast/Lib/test/test_genexps.py", line ?, in test.test_genexps.__test__.doctests Failed example: (y for y in (1,2)) += 10 Expected: Traceback (most recent call last): ... SyntaxError: augmented assign to tuple literal or generator expression not possible Got: Traceback (most recent call last): File "/usr/src/python-ast/Lib/doctest.py", line 1243, in __run compileflags, 1) in test.globs File "", line 1 SyntaxError: augmented assignment to generator expression not possible (, line 1) ** [...] test test_grp failed -- Traceback (most recent call last): File "/usr/src/python-ast/Lib/test/test_grp.py", line 29, in test_values e2 = grp.getgrgid(e.gr_gid) OverflowError: signed integer is greater than maximum [...] test test_pwd failed -- Traceback (most recent call last): File "/usr/src/python-ast/Lib/test/test_pwd.py", line 42, in test_values self.assert_(pwd.getpwuid(e.pw_uid) in entriesbyuid[e.pw_uid]) OverflowError: signed integer is greater than maximum The segfault in test_trace looks like this: $ gdb ./python (gdb) source Misc/gdbinit (gdb) run Lib/test/test_trace.py [...] test_10_no_jump_to_except_1 (__main__.JumpTestCase) ... FAIL Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 46912496260768 (LWP 11945)] PyEval_EvalFrame (f=0x652c30) at Python/ceval.c:1994 [1967 case COMPARE_OP:) 1994Py_DECREF(v); (gdb) print oparg $1 = 10 [PyCmp_EXC_MATCH?] (gdb) pyo v NULL $2 = void #0 PyEval_EvalFrame (f=0x652c30) at Python/ceval.c:1994 #1 0x00475800 in PyEval_EvalFrame (f=0x697390) at Python/ceval.c:3618 #2 0x00475800 in PyEval_EvalFrame (f=0x694f10) at Python/ceval.c:3618 #3 0x00475800 in PyEval_EvalFrame (f=0x649fa0) at Python/ceval.c:3618 [...] #50 0x004113bb in Py_Main (argc=Variable "argc" is not available.) at Modules/main.c:484 (gdb) pystack Lib/test/test_trace.py (447): no_jump_to_except_2 Lib/test/test_trace.py (447): run_test Lib/test/test_trace.py (557): test_11_no_jump_to_except_2 /usr/src/python-ast/Lib/unittest.py (581): run /usr/src/python-ast/Lib/unittest.py (280): __call__ /usr/src/python-ast/Lib/unittest.py (420): run /usr/src/python-ast/Lib/unittest.py (427): __call__ /usr/src/python-ast/Lib/unittest.py (420): run /usr/src/python-ast/Lib/unittest.py (427): __call__ /usr/src/python-ast/Lib/unittest.py (692): run /usr/src/python-ast/Lib/test/test_support.py (692): run_suite /usr/src/python-ast/Lib/test/test_support.py (278): run_unittest Lib/test/test_trace.py (600): test_main Lib/test/test_trace.py (600): I'm not sure what other information from gdb to furnish. Jeff pgpwR8FC2UMjQ.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubs
Re: [Python-Dev] Unicode charmap decoders slow
The function the module below, xlate.xlate, doesn't quite do what "".decode
does. (mostly that characters that don't exist are mapped to u+fffd always,
instead of having the various behaviors avilable to "".decode)
It builds the fast decoding structure once per call, but when decoding 53kb of
data that overhead is small enough to make it much faster than
s.decode('mac-roman'). For smaller buffers (I tried 53 characters), s.decode is
two times faster. (43us vs 21us)
$ timeit.py -s "s='a'*53*1024; import xlate" "s.decode('mac-roman')"
100 loops, best of 3: 12.8 msec per loop
$ timeit.py -s "s='a'*53*1024; import xlate, encodings.mac_roman" \
"xlate.xlate(s, encodings.mac_roman.decoding_map)"
1000 loops, best of 3: 573 usec per loop
Jeff
#include
#include
#include
PyObject *xlate(PyObject *s, PyObject *o) {
unsigned char *inbuf;
int i, length, pos=0;
PyObject *map, *key, *value, *ret;
Py_UNICODE *u, *ru;
if(!PyArg_ParseTuple(o, "s#O", (char*)&inbuf, &length, &map)) return NULL;
if(!PyDict_Check(map)) {
PyErr_SetString(PyExc_TypeError, "Argument 2 must be a dictionary");
return NULL;
}
u = PyMem_Malloc(sizeof(Py_UNICODE) * 256);
if(!u) { return NULL; }
for(i=0; i<256; i++) {
u[i] = 0xfffd;
}
while(PyDict_Next(map, &pos, &key, &value)) {
int ki, vi;
if(!PyInt_Check(key)) {
PyErr_SetString(PyExc_TypeError, "Dictionary keys must be ints");
return NULL;
}
ki = PyInt_AsLong(key);
if(ki < 0 || ki > 255) {
PyErr_Format(PyExc_TypeError,
"Dictionary keys must be in the range 0..255 (saw %d)", ki);
return NULL;
}
if(value == Py_None) continue;
if(!PyInt_Check(value)) {
PyErr_SetString(PyExc_TypeError, "Dictionary values must be ints or
None");
return NULL;
}
vi = PyInt_AsLong(value);
u[ki] = vi;
}
ret = PyUnicode_FromUnicode(NULL, length);
if(!ret) { free(u); return NULL; }
ru = PyUnicode_AsUnicode(ret);
for(i=0; iimport encodings.mac_roman
import xlate
def test(encname, decoding_map):
s = ""
for k, v in decoding_map.items():
if v is not None:
s += chr(k)
u1 = s.decode(encname)
print decoding_map
u2 = xlate.xlate(s, decoding_map)
assert u1 == u2
test("mac-roman", encodings.mac_roman.decoding_map)
pgpyIMySVfb2z.pgp
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode charmap decoders slow
As the OP suggests, decoding with a codec like mac-roman or iso8859-1 is very
slow compared to encoding or decoding with utf-8. Here I'm working with 53k of
data instead of 53 megs. (Note: this is a laptop, so it's possible that
thermal or battery management features affected these numbers a bit, but by a
factor of 3 at most)
$ timeit.py -s "s='a'*53*1024; u=unicode(s)" "u.encode('utf-8')"
1000 loops, best of 3: 591 usec per loop
$ timeit.py -s "s='a'*53*1024; u=unicode(s)" "s.decode('utf-8')"
1000 loops, best of 3: 1.25 msec per loop
$ timeit.py -s "s='a'*53*1024; u=unicode(s)" "s.decode('mac-roman')"
100 loops, best of 3: 13.5 msec per loop
$ timeit.py -s "s='a'*53*1024; u=unicode(s)" "s.decode('iso8859-1')"
100 loops, best of 3: 13.6 msec per loop
With utf-8 encoding as the baseline, we have
decode('utf-8') 2.1x as long
decode('mac-roman') 22.8x as long
decode('iso8859-1') 23.0x as long
Perhaps this is an area that is ripe for optimization.
Jeff
pgpq6roOfs3n8.pgp
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bug in urlparse
On Thu, Sep 08, 2005 at 12:41:39PM -0600, Mike Brown wrote: > [EMAIL PROTECTED] wrote: > > According to RFC 2396[1] section 5.2: > > RFC 2396 is obsolete. It was superseded by RFC 3986 / STD 66 early this year. Thanks for the correction. Jeff pgpFDXgf6EeqZ.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bug in urlparse
According to RFC 2396[1] section 5.2:
g) If the resulting buffer string still begins with one or more
complete path segments of "..", then the reference is
considered to be in error. Implementations may handle this
error by retaining these components in the resolved path (i.e.,
treating them as part of the final URI), by removing them from
the resolved path (i.e., discarding relative levels above the
root), or by avoiding traversal of the reference.
If I read this right, it explicitly allows the urlparse.urljoin behavior
("handle this error by retaining these components in the resolved path").
Also see C.2. Abnormal Examples.
In practice, some implementations strip leading relative symbolic
elements (".", "..") after applying a relative URI calculation, based
on the theory that compensating for obvious author errors is better
than allowing the request to fail. Thus, the above two references
will be interpreted as "http://a/g"; by some implementations.
Jeff
[1] http://www.faqs.org/rfcs/rfc2396.html
pgpepLuYWWdL4.pgp
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SWIG and rlcompleter
You don't need something like a buggy SWIG to put non-strings in dir(). >>> class C: pass ... >>> C.__dict__[3] = "bad wolf" >>> dir(C) [3, '__doc__', '__module__'] This is likely to happen "legitimately", for instance in a class that allows x.y and x['y'] to mean the same thing. (if the user assigns to x[3]) Jeff pgppqGM432Wx4.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
