Re: [Python-Dev] Python code.interact() and UTF-8 locale
Victor STINNER wrote:
> RexFi explains me that Python can't guess eval('len(u"é")') charset.
I personally like to see a charset argument for eval() and compile().
exec would not directly support other charsets; you would have to
compile() first to specify a charset.
I have a patch somewhere that does that, but did not get to publish
it yet.
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.path.diff(path1, path2)
On 9/12/05, Nathan Bullock <[EMAIL PROTECTED]> wrote: > Just wondering if a function such as this has ever > been considered? I find that I quite often want a > function that will give me a relative path from path A > to path B. I have created such a function, but it > would be nice if it was in the standard library. I also often have to plop a snippet of Python in my code to do the same and always wonder why there isn't anything like that in the standard library. +1 for adding this to os.path, it would be very handy. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] speeding up list append calls
Neal Norwitz wrote: > This code doesn't really work in general. It assumes that any append > function call is a list method, which is obviously invalid. But if a > variable is known to be a list (ie, local and assigned as list > (BUILD_LIST) or a list comprehension), could we do something like this > as a peephole optimization? Alternatively, couldn't LIST_APPEND check that this really is a list, and, if it isn't, fall back to PyObject_CallMethod? Not sure which .append call is performed most frequently, but the traditional trick of caching x.append in a local variable might give you most of the speedup. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] speeding up list append calls
Martin v. Löwis wrote: > Neal Norwitz wrote: >> This code doesn't really work in general. It assumes that any append >> function call is a list method, which is obviously invalid. But if a >> variable is known to be a list (ie, local and assigned as list >> (BUILD_LIST) or a list comprehension), could we do something like this >> as a peephole optimization? > > Alternatively, couldn't LIST_APPEND check that this really is a list, > and, if it isn't, fall back to PyObject_CallMethod? Are there any other optimizations which solely act on the name of a method? This seems a step too far. Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] speeding up list append calls
Martin v. Löwis wrote: > Alternatively, couldn't LIST_APPEND check that this really is a list, > and, if it isn't, fall back to PyObject_CallMethod? that's the obvious solution, of course. cf. existing shortcuts: $ grep -n INLINE Python-2.4.1/Python/ceval.c 1103: /* INLINE: int + int */ 1133: /* INLINE: int - int */ 1156: /* INLINE: list[int] */ 1305: /* INLINE: int + int */ 1335: /* INLINE: int - int */ 1967: /* INLINE: cmp(int, int) */ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] speeding up list append calls
At 06:55 PM 9/14/2005 +0200, Martin v. Löwis wrote: >Neal Norwitz wrote: > > This code doesn't really work in general. It assumes that any append > > function call is a list method, which is obviously invalid. But if a > > variable is known to be a list (ie, local and assigned as list > > (BUILD_LIST) or a list comprehension), could we do something like this > > as a peephole optimization? > >Alternatively, couldn't LIST_APPEND check that this really is a list, >and, if it isn't, fall back to PyObject_CallMethod? That's an interesting idea - the opcodes for some math operators check if the operands are integers and then have a fast path, so this would sort of be the reverse. >Not sure which .append call is performed most frequently, but the >traditional trick of caching x.append in a local variable might give >you most of the speedup. Maybe the VM could actually do that caching for you, if we had a CALL_METHOD opcode that cached the attribute in a local variable if it was a C method or Python instance method, and reused the cached attribute as long as the target object is of the same type/class as the last invocation at that point. I think this is called a "polymorphic inline cache", although it doesn't seem very polymorphic if you're only caching one type. :) The downside, alas, would be that modifying the class, or using dynamically generated methods would break this, unless there was some sort of "version counter" on the class that could also be checked, and the caching mechanism only cached in the first place if the attribute was found in a class dictionary. Or perhaps the same mechanism that notifies subclasses of changes to the class could be used to notify frame objects of cache invalidation. The interesting question, of course, is whether all the extra complexity would be worth it. I think other polymorphic inline caches actually cache per call site, not per frame invocation, so it might be that the code object would actually be the place to cache this, allowing the program as a whole to gain. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Skiping searching throw dictionaries of mro() members.
Excuse my english. I have a complex Idea. It can be not worth, but just look at. It touches the classes and inheritance. Base point: We change classes not too often. But every look at a member leads to search throw a __dict__ of all bases in ierarhy till member found. We could cache this search in class.__dict__ itself and check only bases versions. Lets see: we have some classes: __metaclass__=object class a: def meth_a(self): pass class b: def meth_b(self): pass class c(a,b): pass Every class has mro. >>>c.mro() [, , , ] if we call methon from a base class, we look at c.__dict__ and at dict of every inherited class till found the method itself. so c.meth_a() leads to search throw c.__dict__ and a.__dict__ c.meth_b() leads to search throw c.__dict__ , a.__dict__ and b.__dict__ We could cash looks by this way: Store with a class its version. Every time after creation when we change a class (add,remove or chage class member, including __base__, __bases__ and mro) , we increase the version number. Lets call it VERSION Also store a tuple MRO_VERSION=tuple(base.VERSION for base in self.mro()). It changes, when we touches __base__, __bases__ or self.mro) Store with every class member a tuple : MEMBER_VERSION=(,) When we add member to (or change member of) class __dict__ directly, we store in this tuple (MRO_VERSION,class.mro().index(class)). When we search a class member: a) and have not found it in class.__dict__, we search it throw mro() by a classic way. If we've found it (in a class _BASE_), we store it in class.__dict__ with a tuple MEMBER_VERSION=(MRO_VERSION, class.mro().index(_BASE_)). Also we check all of seen base.VERSION to match their cached in MRO_VERSION values. If some is not match, we should update MRO_VERSION (berfore storing founded member in a class.__dict__) and adjust VERSION. If it was not found, we could store a (MRO_VERSION, class.mro().index(class)) with an internal value NotFound or do not store anything, and report that we have not found anything (so we search in an object itself). b) When we've found a class member in class.__dict__ we check versions if MEMBER_VERSION[0]==class.MRO_VERSION (the same object) then we just compare MRO_VERSION[i]==class.mro()[i].VERSION for i in range(MEMBER_VERSION[1]+1) and not search throw mro()[i].__dict__ what we are doing now. If all versions concur, we return found member (or, if we've found previously stored NotFound, we report that we have not found anything) if version of MRO_VERSION[j]!=class.mro()[j].VERSION and class!=class.mro()[j] (here can be a bug, one must think about it more) then we revert to a) point, but search throw [base.__dict__ for base in class.mro()[j:]], (and, of cause, update MRO_VERSION) if MEMBER_VERSION[0]!=class.MRO_VERSION, we reverts to a) point. That's all. PS. We can subclass module from a __builtin__, so we leave one dict lookup. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Skiping searching throw dictionaries of mro() members.
At 09:12 PM 9/14/2005 +0400, Sokolov Yura wrote: >We could cash looks by this way: >Store with a class its version. Every time after creation when we change >a class >(add,remove or chage class member, including __base__, __bases__ and mro) , >we increase the version number. Lets call it VERSION FYI, there is already a mechanism for new-style classes that notifies subclasses of changes to the base class; this mechanism could be used to push cache flushes downward, rather than doing version checking upward. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Fwd: [Python-checkins] python/dist/src/Misc NEWS, 1.1193.2.94, 1.1193.2.95
I have no way to test this code on Windows (or on other UNIX platforms besides Linux and AIX). Hopefully someone can verify whether it breaks anything. -- Forwarded message -- From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: Sep 14, 2005 11:15 AM Subject: [Python-checkins] python/dist/src/Misc NEWS, 1.1193.2.94, 1.1193.2.95 To: [EMAIL PROTECTED] Update of /cvsroot/python/python/dist/src/Misc In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv24791/Misc Modified Files: Tag: release24-maint NEWS Log Message: - Changes donated by Elemental Security to make it work on AIX 5.3 with IBM's 64-bit compiler (SF patch #1284289). This also closes SF bug #105470: test_pwd fails on 64bit system (Opteron). Index: NEWS === RCS file: /cvsroot/python/python/dist/src/Misc/NEWS,v retrieving revision 1.1193.2.94 retrieving revision 1.1193.2.95 diff -u -d -r1.1193.2.94 -r1.1193.2.95 --- NEWS14 Sep 2005 17:54:39 - 1.1193.2.94 +++ NEWS14 Sep 2005 18:15:03 - 1.1193.2.95 @@ -12,6 +12,10 @@ Core and builtins - +- Changes donated by Elemental Security to make it work on AIX 5.3 + with IBM's 64-bit compiler (SF patch #1284289). This also closes SF + bug #105470: test_pwd fails on 64bit system (Opteron). + - Changes donated by Elemental Security to make it work on HP-UX 11 on Itanium2 with HP's 64-bit compiler (SF patch #1225212). ___ Python-checkins mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-checkins -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] python/dist/src/Lib/test regrtest.py, 1.171, 1.172 test_ioctl.py, 1.2, 1.3
> Index: test_ioctl.py
> ===
> RCS file: /cvsroot/python/python/dist/src/Lib/test/test_ioctl.py,v
> retrieving revision 1.2
> retrieving revision 1.3
> diff -u -d -r1.2 -r1.3
> --- test_ioctl.py 20 Mar 2003 04:33:16 - 1.2
> +++ test_ioctl.py 14 Sep 2005 18:09:41 - 1.3
> @@ -16,19 +16,23 @@
>
> class IoctlTests(unittest.TestCase):
> def test_ioctl(self):
> -pgrp = os.getpgrp()
> +# If this process has been put into the background, TIOCGPGRP returns
> +# the session ID instead of the process group id.
> +ids = (os.getpgrp(), os.getsid(0))
> tty = open("/dev/tty", "r")
> r = fcntl.ioctl(tty, termios.TIOCGPGRP, "")
> -self.assertEquals(pgrp, struct.unpack("i", r)[0])
> +rpgrp = struct.unpack("i", r)[0]
> +self.assert_(rpgrp in ids, "%s not in %s" % (rpgrp, ids))
With the change to use unsigned ints in pwd and grp modules, should
the struct.unpack() use "I" (capital i) instead of "i"?
n
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] speeding up list append calls
Phillip J. Eby wrote: > I think this is called a "polymorphic inline cache", although it doesn't > seem very polymorphic if you're only caching one type. :) if it's not polymorphic, it's an ordinary inline cache (aka "call-site cache"). (see various Self papers for more on polymorphic caches) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unintentional and unsafe use of realpath()
[re-adding Python-Dev]
On Wed, 2005-09-14 at 02:00 +0200, Henrik Levkowetz wrote:
> Hi Peter,
>
> on 2005-09-10 21:29 Peter Jones said the following:
> > Hi,
> >
> > In Python 2.4.1, Python/sysmodule.c includes a function PySys_SetArgv().
> > One of the things it does is attempt to resolve symbolic links into
> > absolute paths. Currently, it uses readlink() if configure found that
> > your system supports it, and then it tries to do the same thing again
> > using realpath() if you system supports that.
> >
> > This seems wrong; there's really no reason to do both. So here's a
> > patch to move the realpath() usage into a #else following the
> > HAVE_READLINK test:
> >
>
> If a path component above the basename is a link, it will not be
> resolved by only doing readlink() on the basename, while realpath() will
> resolve it. So it seems to me that your proposed patch will accomplish
> less than the current code for systems which have realpath().
What the current code is doing is a buffer overrun. Nevertheless,
you're right that it would behave differently than the current code if
that code worked as intended.
Here's a different patch; it uses canonicalize_file_name instead, and if
you don't have that it just uses the same codepath that's already in the
tree. canonicalize_file_name is identical to realpath() when using the
glibc extension of allocating a buffer when you pass in a NULL target,
as in:
fullpath = realpath(path, NULL);
I chose to use canonicalize_file_name simply because the autoconf test
for it is easier than testing to see if the extension works.
Here's the new patch:
--- Python-2.4.1/pyconfig.h.in.canonicalize 2005-09-14 11:47:04.0
-0400
+++ Python-2.4.1/pyconfig.h.in 2005-09-14 11:47:02.0 -0400
@@ -58,6 +58,9 @@
/* Define if pthread_sigmask() does not work on your system. */
#undef HAVE_BROKEN_PTHREAD_SIGMASK
+/* Define to 1 if you have the `canonicalize_file_name' function. */
+#undef HAVE_CANONICALIZE_FILE_NAME
+
/* Define to 1 if you have the `chown' function. */
#undef HAVE_CHOWN
--- Python-2.4.1/Python/sysmodule.c.canonicalize2005-09-14
11:53:30.0 -0400
+++ Python-2.4.1/Python/sysmodule.c 2005-09-14 11:52:04.0 -0400
@@ -1184,6 +1184,9 @@
char *p = NULL;
int n = 0;
PyObject *a;
+#ifdef HAVE_CANONICALIZE_FILE_NAME
+argv0 = canonicalize_file_name(argv0);
+#else /* ! HAVE_CANONICALIZE_FILE_NAME */
#ifdef HAVE_READLINK
char link[MAXPATHLEN+1];
char argv0copy[2*MAXPATHLEN+1];
@@ -1256,6 +1259,7 @@
#endif /* Unix */
}
#endif /* All others */
+#endif /* ! HAVE_CANONICALIZE_FILE_NAME */
a = PyString_FromStringAndSize(argv0, n);
if (a == NULL)
Py_FatalError("no mem for sys.path insertion");
--- Python-2.4.1/configure.in.canonicalize 2005-09-14 11:46:00.0
-0400
+++ Python-2.4.1/configure.in 2005-09-14 11:47:22.0 -0400
@@ -2096,8 +2096,8 @@
AC_MSG_RESULT(MACHDEP_OBJS)
# checks for library functions
-AC_CHECK_FUNCS(alarm bind_textdomain_codeset chown clock confstr ctermid \
- execv fork fpathconf ftime ftruncate \
+AC_CHECK_FUNCS(alarm bind_textdomain_codeset canonicalize_file_name chown \
+ clock confstr ctermid execv fork fpathconf ftime ftruncate \
gai_strerror getgroups getlogin getloadavg getpeername getpgid getpid \
getpriority getpwent getsid getwd \
kill killpg lchown lstat mkfifo mknod mktime \
--
Peter
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Term unification
Hi, looking at bug #1283289, I saw that the term "keyword parameter" is used in Python/getargs.c, mixed with "keyword argument". Grepping through the source, "keyword parameter" had 43 matches, while "keyword argument" had 430. Should the "parameter" form be extinguished? Reinhold (And BTW, should bug #1283289 be fixed as the poster suggests?) -- Mail address is perfectly valid! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Term unification
Correct usage is argument for the call site but parameter for the function/method definition. So you can't just count occurrences. On 9/14/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote: > Hi, > > looking at bug #1283289, I saw that the term "keyword parameter" is used in > Python/getargs.c, mixed with "keyword argument". > > Grepping through the source, "keyword parameter" had 43 matches, while > "keyword argument" had 430. Should the "parameter" form be extinguished? > > Reinhold > > (And BTW, should bug #1283289 be fixed as the poster suggests?) > > > -- > Mail address is perfectly valid! > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Term unification
Ah, ok. Then I guess everything's fine. It was just the /* make sure there are no duplicate values for an argument; its not clear when to use the term "keyword argument vs. keyword parameter in messages */ that disturbed me. Reinhold Guido van Rossum wrote: > Correct usage is argument for the call site but parameter for the > function/method definition. So you can't just count occurrences. > > On 9/14/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote: >> Hi, >> >> looking at bug #1283289, I saw that the term "keyword parameter" is used in >> Python/getargs.c, mixed with "keyword argument". >> >> Grepping through the source, "keyword parameter" had 43 matches, while >> "keyword argument" had 430. Should the "parameter" form be extinguished? >> >> Reinhold >> >> (And BTW, should bug #1283289 be fixed as the poster suggests?) -- Mail address is perfectly valid! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] str.dedent
Hi, some time ago, I proposed a string method "dedent" (which currently is in the textwrap module). The RFE is at http://python.org/sf/1237680. Any opinions? If I don't get positive comments, I'll reject it. Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.dedent
>From the sound of it, it's probably not worth endowing every string object with this method and hardcoding its implementation forever in C code. There are so many corner cases and variations on the functionality of "dedenting" a block that it's better to keep it as Python source code. On 9/14/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote: > Hi, > > some time ago, I proposed a string method "dedent" (which currently is in the > textwrap module). The RFE is at http://python.org/sf/1237680. > > Any opinions? If I don't get positive comments, I'll reject it. > > Reinhold -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] python/dist/src/Lib/test regrtest.py, 1.171, 1.172 test_ioctl.py, 1.2, 1.3
On 9/14/05, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> > Index: test_ioctl.py
> > ===
> > RCS file: /cvsroot/python/python/dist/src/Lib/test/test_ioctl.py,v
> > retrieving revision 1.2
> > retrieving revision 1.3
> > diff -u -d -r1.2 -r1.3
> > --- test_ioctl.py 20 Mar 2003 04:33:16 - 1.2
> > +++ test_ioctl.py 14 Sep 2005 18:09:41 - 1.3
> > @@ -16,19 +16,23 @@
> >
> > class IoctlTests(unittest.TestCase):
> > def test_ioctl(self):
> > -pgrp = os.getpgrp()
> > +# If this process has been put into the background, TIOCGPGRP
> > returns
> > +# the session ID instead of the process group id.
> > +ids = (os.getpgrp(), os.getsid(0))
> > tty = open("/dev/tty", "r")
> > r = fcntl.ioctl(tty, termios.TIOCGPGRP, "")
> > -self.assertEquals(pgrp, struct.unpack("i", r)[0])
> > +rpgrp = struct.unpack("i", r)[0]
> > +self.assert_(rpgrp in ids, "%s not in %s" % (rpgrp, ids))
>
> With the change to use unsigned ints in pwd and grp modules, should
> the struct.unpack() use "I" (capital i) instead of "i"?
I asked the author of the patch (Monte Davidoff, who occasionally
comes to baypiggies meetings :-) and his response is:
"""
No. The change to the pwd and grp modules and the change to test_ioctl
are unrelated. Unfortunately, the term "group" is overloaded, which
leads to confusion.
The pwd and grp modules read the password database and the group
database, which are attributes of a UNIX user.
The test_ioctl test case is calling the TIOCGPGRP ioctl, which returns
the process group id, which is an attribute of the process. This has
type pid_t, which is signed.
I hope this clarifies the situation. I am glad to hear that it is
checked in!
Monte
"""
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.path.diff(path1, path2)
Nathan Bullock wrote: > I find that I quite often want a > function that will give me a relative path from path A > to path B. I have created such a function, but it > would be nice if it was in the standard library. +1 from me. It's a fairly common thing to want to do. Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.dedent
> some time ago, I proposed a string method "dedent" (which currently is in > the > textwrap module). The RFE is at http://python.org/sf/1237680. > > Any opinions? If I don't get positive comments, I'll reject it. -1 Let it continue to live in textwrap where the existing pure python code adequately serves all string-like objects. It's not worth losing the duck typing by attaching new methods to str, unicode, UserString, and everything else aspiring to be string-like. String methods should be limited to generic string manipulations. String applications should be in other namespaces. That is why we don't have str.md5(), str.crc32(), str.ziplib(), etc. Also, I don't want to encourage dedenting as a way of life --- programs using it often are likely to be doing things the hard way. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary
___
Patches : 343 open ( +1) / 2927 closed ( +4) / 3270 total ( +5)
Bugs: 908 open ( +0) / 5245 closed (+13) / 6153 total (+13)
RFE : 189 open ( +1) / 185 closed ( +0) / 374 total ( +1)
New / Reopened Patches
__
Allow to restrict ModuleFinder to get "direct" dependencies (2005-09-08)
http://python.org/sf/1284670 opened by Scherer Michael
pygettext - provide comments to help translators (2005-09-11)
http://python.org/sf/1288056 opened by Toby Dickenson
FreeBSD 5.3 and upward has thread-safe getaddrinfo(3) (2005-09-12)
http://python.org/sf/1288833 opened by Maxim Sobolev
Fix reload() error message (2005-09-13)
CLOSED http://python.org/sf/1290454 opened by Collin Winter
mmap with unsigned int offset and cross build for ppc (2005-09-14)
http://python.org/sf/1291169 opened by José Pedro Pereira Valente de M
Patches Closed
__
Fix reload() error message (2005-09-13)
http://python.org/sf/1290454 closed by birkenfeld
HP-UX ia64 64-bit Python executable (2005-06-21)
http://python.org/sf/1225212 closed by gvanrossum
AIX port from Elemental Security (2005-09-07)
http://python.org/sf/1284289 closed by gvanrossum
new patch for fixing skipitem() in getargs.c (2005-06-01)
http://python.org/sf/1212928 closed by birkenfeld
New / Reopened Bugs
___
traceback module can return undecodable byte strings (2005-09-08)
http://python.org/sf/1284496 opened by Stuart Bishop
logging module's setLoggerClass not really working (2005-09-08)
http://python.org/sf/1284928 opened by Rotem Yaari
urllib.quote is too slow (2005-09-08)
http://python.org/sf/1285086 opened by Tres Seaver
Call to cmd.exe fails (2005-09-08)
CLOSED http://python.org/sf/1285325 opened by Alex Luso
Digest Authentication not working in all cases (2005-09-08)
http://python.org/sf/1285440 opened by Jakob Simon-Gaarde
re special sequence '\w' (2005-09-09)
CLOSED http://python.org/sf/1285809 opened by ChristianJ
Python code.interact() and UTF-8 locale (2005-09-12)
http://python.org/sf/1288615 opened by STINNER Victor
timedelta multiply and divide by floating point (2005-09-12)
http://python.org/sf/1289118 opened by Daniel Stutzbach
distutils extension library path bug on cygwin (2005-09-12)
http://python.org/sf/1289136 opened by John Whitley
PyDoc crashes at os.py line 133 (2005-09-12)
CLOSED http://python.org/sf/1289210 opened by Colin J. Williams
cjkcodec compile error under AIX 5.2 on symbol 100_encode (2005-09-13)
http://python.org/sf/1290333 opened by Deron Meranda
--no-compile option has no effect (2005-09-13)
CLOSED http://python.org/sf/1290382 opened by Tim Peters
strptime(): can't switch locales more than once (2005-09-13)
CLOSED http://python.org/sf/1290505 opened by Adam Monsen
SSLObject breaks read semantics (2005-09-14)
http://python.org/sf/1291446 opened by Jonathan Ellis
Bugs Closed
___
Call to cmd.exe fails (2005-09-08)
http://python.org/sf/1285325 deleted by delenca
exception when unpickling array.array objects (2005-09-04)
http://python.org/sf/1281556 closed by rhettinger
PyDoc crashes at os.py line 133 (2005-09-12)
http://python.org/sf/1289210 closed by rhettinger
--no-compile option has no effect (2005-09-13)
http://python.org/sf/1290382 closed by tim_one
RE parser too loose with {m,n} construct (2005-05-15)
http://python.org/sf/1202493 closed by niemeyer
document {m} regex matcher wrt empty matches (2005-01-31)
http://python.org/sf/1113484 closed by niemeyer
r'\10' as replacement pattern loops in compilation (2004-11-02)
http://python.org/sf/1058786 closed by niemeyer
re nested conditional matching (?()) doesn't work (2005-09-08)
http://python.org/sf/1284341 closed by birkenfeld
skipitem() in getargs.c missing some types (2004-02-09)
http://python.org/sf/893549 closed by birkenfeld
re special sequence '\w' (2005-09-09)
http://python.org/sf/1285809 closed by birkenfeld
suspected cPickle memory leak (2005-05-13)
http://python.org/sf/1201461 closed by birkenfeld
splitunc not documented (2005-08-27)
http://python.org/sf/1274828 closed by birkenfeld
os.startfile() doesn't accept Unicode filenames (2004-08-11)
http://python.org/sf/1007046 closed by birkenfeld
strptime(): can't switch locales more than once (2005-09-13)
http://python.org/sf/1290505 closed by bcannon
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.dedent
Okay. I consider it rejected. Reinhold Guido van Rossum wrote: >>From the sound of it, it's probably not worth endowing every string > object with this method and hardcoding its implementation forever in C > code. There are so many corner cases and variations on the > functionality of "dedenting" a block that it's better to keep it as > Python source code. > > On 9/14/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote: >> Hi, >> >> some time ago, I proposed a string method "dedent" (which currently is in the >> textwrap module). The RFE is at http://python.org/sf/1237680. >> >> Any opinions? If I don't get positive comments, I'll reject it. >> >> Reinhold > -- Mail address is perfectly valid! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python/dist/src/Lib urllib.py, 1.165.2.1, 1.165.2.2
[EMAIL PROTECTED] wrote: > Update of /cvsroot/python/python/dist/src/Lib > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv31892 > > Modified Files: > Tag: release24-maint > urllib.py > Log Message: > Sync-up with patches to the head. > Includes SF 1016880: urllib.urlretrieve silently truncates downloads > and the performance fix-ups. This last patch includes a new exception, are you sure that this can be safely backported? If so, the documentation changes must be backported, too. Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] python/dist/src/Lib urllib.py, 1.165.2.1, 1.165.2.2
[Reinhold Birkenfeld]
> This last patch includes a new exception, are you sure that this can
be
> safely backported?
Not too worried about it. Better to have the exception reported than
the silent failure that confused the heck out of everyone who tried to
figure-out what caused the OP's problem.
> If so, the documentation changes must be backported, too.
Maybe. My thought is the new message is akin to an improved error
message. However, adding it to the Py2.4 docs suggests that you could
catch and handle the exception, but that cannot be done portably across
Py2.4 versions. If you really feel the need, go ahead and add to the
docs with \versionadded{2.4.2}. My preference is to leave it be.
Raymond
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
