Re: [Python-Dev] should i put this on the bug tracker ?
On 8/8/06, Bart Thate [EMAIL PROTECTED] wrote: hello python-dev, the following code hangs on FreeBSD 6.1-STABLE, Python 2.5b3 (r25b3:51041, Aug 5 2006, 20:46:57) Python 2.5 now uses system scope threads in FreeBSD just like in other platforms. So python may behave different for corner cases. [snip] works fine on python2.4 is this a bug or is it something i should not do ? In my machine (FreeBSD 6.1), 2.4 and 2.5 work same. What was the problem on your running? Did you install it from the port? BTW, os.exec() from a sub-thread looks not so safe. Hye-Shik ___ 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] Google Summer of Code proposal: New class for work with binary trees AVL and RB as with the standard dictionary.
On 4/25/06, Josiah Carlson [EMAIL PROTECTED] wrote: There exists various C and Python implementations of both AVL and Red-Black trees. For users of Python who want to use AVL and/or Red-Black trees, I would urge them to use the Python implementations. In the case of *needing* the speed of a C extension, there already exists a CPython extension module for AVL trees: http://www.python.org/pypi/pyavl/1.1 And a C implementation for redblack tree is here: http://python.org/sf/1324770 :) Hye-Shik ___ 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] Stream codecs and _multibytecodec
On 4/21/06, Thomas Wouters [EMAIL PROTECTED] wrote: While merging the trunk changes into the p3yk branch, I discovered what I think is a bug in the stream codecs. It's easily reproduced in the trunk: in Lib/codecs.py, make the 'Codec' class new-style. Then, suddenly, test_codecs will crash with an exception like this: [snip] I'm not sure whether this attribute conflict is on purpose or not, but since it will break in the future, I suggest it gets fixed. It *looks* like renaming the _MultibyteStreamWriter attribute is the easiest solution, but I don't know which API has precedence. The readonly attribute stream of _MultibyteStreamWriter is exactly equivalent to codecs.StreamWriter's and it can't be removed to work correctly. I intended to override all methods of StreamWriters. The only reason why it inherits from codecs.StreamWriter is not to break isinstance(x, StreamWriter) checks and nothing from StreamWriter is used at all. I'll verify and fix it in p3yk branch soon. Thank you for the inspection! Hye-Shik ___ 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
[Python-Dev] Inconsistency in 2.4.3 for __repr__() returning unicode
We got an inconsistency for __repr__() returning unicode as reported in http://python.org/sf/1459029 : class s1: def __repr__(self): return '\\n' class s2: def __repr__(self): return u'\\n' print repr(s1()), repr(s2()) Until 2.4.2: \n \n 2.4.3: \n \\n \\n looks bit weird but it's correct. As once discussed[1] in python-dev before, if __repr__ returns unicode object, PyObject_Repr encodes it via unicode-escape codec. So, non-latin character also could be in repr neutrally. But our unicode-escape had a bug since when it is introduced. The bug was that it doesn't escape backslashes. Therefore, backslashes wasn't escaped in repr while it sholud be escaped because we used the unicode-escape codec. So, fixing the bug made a behavior inconsistency. How do we resolve the problem? Hye-Shik [1] http://mail.python.org/pipermail/python-dev/2000-July/005353.html ___ 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] checkin r43015
On 3/14/06, Jeff Epler [EMAIL PROTECTED] wrote: After the recent discussion about Coverity, I took a look at one of the checkins made, apparently based on output from their tool. http://svn.python.org/view/python/branches/release24-maint/Objects/object.c?r1=43015r2=43014rev=43015view=diffdiff_format=l This change, a backport of a similar change made to HEAD, doesn't seem to fix the flaw: the PyUnicode_CheckExact() call is now guarded against a NULL return, but the subsequent PyUnicode_Check() and PyString_Check() calls don't seem to be. Agreed. That change doesn't fix the real problem. I bet it'll still segfault for PyObject_Unicode(NULL). In fact, I and Neal talked about the problem and have a correct patch. But the patch looks bit messy so we hated it. :-) http://python.org/sf/1444030 I'm not 100% sure what's going on here, but it still looks a bit fishy. The API reference says that PyObject_AsUnicode may return NULL, so why doesn't the function just call PyErr_BadInternalCall() and return NULL? For the consistency with PyObject_String(NULL) which returns a string NULL. Hye-Shik ___ 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] Stateful codecs [Was: str object going in Py3K]
On 2/19/06, Walter Dörwald [EMAIL PROTECTED] wrote: M.-A. Lemburg wrote: Walter Dörwald wrote: Anyway, I've started implementing a patch that just adds codecs.StatefulEncoder/codecs.StatefulDecoder. UTF8, UTF8-Sig, UTF-16, UTF-16-LE and UTF-16-BE are already working. Nice :-) gencodec.py is updated now too. The rest should be manageble too. I'll leave updating the CJKV codecs to Hye-Shik though. Okay. I'll look whether how CJK codecs can be improved by the new protocol soon. I guess it'll be not so difficult because CJK codecs have a their own common stateful framework already. BTW, CJK codecs don't have V yet. :-) Hye-Shik ___ 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] any support for a methodcaller HOF?
On 2/4/06, Jean-Paul Calderone [EMAIL PROTECTED] wrote: On Fri, 3 Feb 2006 07:00:26 -0800, Alex Martelli [EMAIL PROTECTED] wrote: I understand your worry re the syntax issue. So what about Michael Hudson's placeholder class idea, where X[1] returns the callable that will do x[1] when called, etc? Looks elegant to me... FWIW, http://cvs.twistedmatrix.com/cvs/sandbox/glyph/eacher.py?view=markuprev=12804 http://cvs.twistedmatrix.com/cvs/sandbox/cake.py?view=markuprev=12804 Yet another implementation, http://mail.python.org/pipermail/python-announce-list/2004-January/002801.html Hye-Shik ___ 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
[Python-Dev] ctypes patch (was: (libffi) Re: Copyright issue)
On 1/30/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Hye-Shik Chang wrote: I did some work to make ctypes+libffi compacter and liberal. http://openlook.org/svnpublic/ctypes-compactffi/ (svn) I removed sources/gcc and put sources/libffi copied from gcc 4.0.2. And removed all automake-related build processes and integrated them into setup.py. There's still aclocal.m4 in sources/libffi. But it is just identical to libffi's acinclude.m4 which looks liberal. Well done! Would you like to derive a Python patch from that? Don't worry about MSVC, yet, I will do that once the sources are in the subversion. Here goes patches for the integration: [1] http://people.freebsd.org/~perky/ctypesinteg-f1.diff.bz2 [2] http://people.freebsd.org/~perky/ctypesinteg-f2.diff.bz2 I implemented it in two flavors. [1] runs libffi's configure along with Python's and setup.py just builds it. And [2] has no change to Python's configure and setup.py runs libffi configure and builds it. And both patches don't have things for documentations yet. (Of course, for due process, it would be better if this code gets integrated into the official ctypes first, and then we incorporate some named/versioned snapshot into /external, and svn cp it into python/trunk from there). Thomas and I collaborated on integration into the ctypes repository and testing on various platforms yesterday. My patches for Python are derived from ctypes CVS with a change of only one line. Hye-Shik ___ 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] (libffi) Re: Copyright issue
On 1/30/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Well done! Would you like to derive a Python patch from that? Yup. I'll do. On 1/30/06, Thomas Heller [EMAIL PROTECTED] wrote: That's great! Would you like to integrate these changes into to ctypes CVS repository yourself? I indend to do a few releases still from there, before the first Python 2.5. If so, please tell me your SF username and I'll add you as developer. Also, please note that all work should be done on the 'branch_1_0' CVS branch - the HEAD is only experimental code (and not currently used). My SF username is perky. I'll try to make it portable but it'll lose some platforms through compilers because few of libffi sources are in preprocessed assembly (.S) which isn't supported by distutils yet. So, we'll need tests on various compiler/platforms before the release. Hye-Shik ___ 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] (libffi) Re: Copyright issue
On 1/28/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Thomas Heller wrote: Can anyone of the python-dev core team comment: can we live with the GPL licensed aclocal.m4 file, in the source distribution and in SVN? My understanding that doing so would be in violation of section 2b) of the GPL. However, I still think it is possible to include libffi - we just have to discard the build process, and do our own. I did some work to make ctypes+libffi compacter and liberal. http://openlook.org/svnpublic/ctypes-compactffi/ (svn) I removed sources/gcc and put sources/libffi copied from gcc 4.0.2. And removed all automake-related build processes and integrated them into setup.py. There's still aclocal.m4 in sources/libffi. But it is just identical to libffi's acinclude.m4 which looks liberal. Hye-Shik ___ 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] ElementTree - Why not part of the core? (fwd)
On 12/12/05, Fredrik Lundh [EMAIL PROTECTED] wrote: Fredrik Lundh wrote: just one question: where do you want [to put] the vendor checkins ? I'm using a flat kits namespace in my own repositories, e.g. anyone has a better name? anyone ? I think contrib is somewhat conventional for the purpose. Hye-Shik ___ 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
[Python-Dev] LXR site for Python CVS
Hi, I just set up a LXR instance for Python CVS for my personal use: http://pxr.openlook.org/pxr/ If you find it useful, feel free to use the site. :) The source files will be updated twice a day. Hye-Shik ___ 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] test_cmd_line failure on Kubuntu 5.10 with GCC 4.0
On 10/8/05, Nick Coghlan [EMAIL PROTECTED] wrote: Anyone else seeing any problems with test_cmd_line? I've got a few failures in test_cmd_line on Kubuntu 5.10 with GCC 4.0 relating to a missing \n line ending. Same problem here. (FreeBSD 6.0 with GCC 3.4.4) In my short inspection, popen2.popen4.read() returned just an empty string. I'll investigate more in this weekend. Hye-Shik ___ 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
On 10/6/05, M.-A. Lemburg [EMAIL PROTECTED] wrote: Hye-Shik Chang wrote: (encoding, fastmap codec) % ./python Lib/timeit.py -s s='a'*53*1024; e='iso8859_10_fc'; u=unicode(s, e) u.encode(e) 1000 loops, best of 3: 536 usec per loop (encoding, utf-8 codec) % ./python Lib/timeit.py -s s='a'*53*1024; e='utf_8'; u=unicode(s, e) u.encode(e) 1000 loops, best of 3: 1.5 msec per loop I wonder why the UTF-8 codec is slower than the fastmap codec in this case. I guess that resizing made the difference. fastmap encoder doesn't resize the output buffer at all in the test case while UTF-8 encoder allocates 4*53*1024 bytes and resizes it to 53*1024 bytes in the end. Hye-Shik ___ 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
On 10/5/05, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Of course, a C version could use the same approach as
the unicodedatabase module: that of compressed lookup
tables...
http://aggregate.org/TechPub/lcpc2002.pdf
genccodec.py anyone ?
I had written a test codec for single byte character sets to evaluate
algorithms to use in CJKCodecs once before (it's not a direct
implemention of you've mentioned, tough) I just ported it
to unicodeobject (as attached). It showed relatively fine result
than charmap codecs:
% python ./Lib/timeit.py -s s='a'*1024*1024; u=unicode(s)
s.decode('iso8859-1')
10 loops, best of 3: 96.7 msec per loop
% ./python ./Lib/timeit.py -s s='a'*1024*1024; u=unicode(s)
s.decode('iso8859_10_fc')
10 loops, best of 3: 22.7 msec per loop
% ./python ./Lib/timeit.py -s s='a'*1024*1024; u=unicode(s)
s.decode('utf-8')
100 loops, best of 3: 18.9 msec per loop
(Note that it doesn't contain any documentation nor good error
handling yet. :-)
Hye-Shik
fastmapcodec.diff
Description: Binary data
___
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
On 10/6/05, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Hye-Shik, could you please provide some timeit figures for
the fastmap encoding ?
(before applying Walter's patch, charmap decoder)
% ./python Lib/timeit.py -s s='a'*53*1024; e='iso8859_10';
u=unicode(s, e) s.decode(e)
100 loops, best of 3: 3.35 msec per loop
(applied the patch, improved charmap decoder)
% ./python Lib/timeit.py -s s='a'*53*1024; e='iso8859_10';
u=unicode(s, e) s.decode(e)
1000 loops, best of 3: 1.11 msec per loop
(the fastmap decoder)
% ./python Lib/timeit.py -s s='a'*53*1024; e='iso8859_10_fc';
u=unicode(s, e) s.decode(e)
1000 loops, best of 3: 1.04 msec per loop
(utf-8 decoder)
% ./python Lib/timeit.py -s s='a'*53*1024; e='utf_8'; u=unicode(s,
e) s.decode(e)
1000 loops, best of 3: 851 usec per loop
Walter's decoder and the fastmap decoder run in mostly same way.
So the performance difference is quite minor. Perhaps, the minor
difference came from the existence of wrapper function on each codecs;
the fastmap codec provides functions usable as Codecs.{en,de}code
directly.
(encoding, charmap codec)
% ./python Lib/timeit.py -s s='a'*53*1024; e='iso8859_10';
u=unicode(s, e) u.encode(e)
100 loops, best of 3: 3.51 msec per loop
(encoding, fastmap codec)
% ./python Lib/timeit.py -s s='a'*53*1024; e='iso8859_10_fc';
u=unicode(s, e) u.encode(e)
1000 loops, best of 3: 536 usec per loop
(encoding, utf-8 codec)
% ./python Lib/timeit.py -s s='a'*53*1024; e='utf_8'; u=unicode(s,
e) u.encode(e)
1000 loops, best of 3: 1.5 msec per loop
If the encoding optimization can be easily done in Walter's approach,
the fastmap codec would be too expensive way for the objective because
we must maintain not only fastmap but also charmap for backward
compatibility.
Hye-Shik
___
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] Python code.interact() and UTF-8 locale
On 9/11/05, Victor STINNER [EMAIL PROTECTED] wrote: Hi, I found a bug in Python interactive command line (program python alone: looks to be code.interact() function in code.py). With UTF-8 locale, the command ué returns u'\xc3\xa9' and not u'\xE9' . Remember: the french e with acute is Unicode 233 (0xE9), encoded \xC3 \xA9 in UTF-8. Which version of python do you use? From 2.4, the interactive mode respects locale as a source code encoding and it falls back to latin-1 when decoding fails. Python 2.4.1 (#2, Jul 31 2005, 04:45:53) [GCC 3.4.2 [FreeBSD] 20040728] on freebsd5 Type help, copyright, credits or license for more information. ué u'\xe9' Hye-Shik ___ 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] Python code.interact() and UTF-8 locale
On 9/13/05, Hye-Shik Chang [EMAIL PROTECTED] wrote: On 9/11/05, Victor STINNER [EMAIL PROTECTED] wrote: I found a bug in Python interactive command line (program python alone: looks to be code.interact() function in code.py). With UTF-8 locale, the command ué returns u'\xc3\xa9' and not u'\xE9' . Remember: the french e with acute is Unicode 233 (0xE9), encoded \xC3 \xA9 in UTF-8. Which version of python do you use? From 2.4, the interactive mode respects locale as a source code encoding and it falls back to latin-1 when decoding fails. Aah, code.interact() and IDLE behaviors different from the real interactive mode currently. I think it needs to be fixed before the next release. For IDLE, I filed a patch on SF #1061803. But it may need some discussion because of its trickiness. :) Hye-Shik ___ 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] Shorthand for lambda
On Wed, 23 Mar 2005 10:33:53 -0600 (CST), Ka-Ping Yee [EMAIL PROTECTED] wrote: Hey folks, from placeholder import _ numbers = [5, 9, 56, 34, 1, 24, 37, 89] filter(_ 30, numbers) [5, 9, 1, 24] map(_ + 10, numbers) [15, 19, 66, 44, 11, 34, 47, 99] Look ma, no lambdas! I bet someone has already done this before, right? I tried it once before: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/perky/anonfunc-1.0.tar.gz from anonfunc import * f = (arg0 * arg1 + 3 * arg2) ** 2 f(5, 6, 7) 2601 f = kw1 and kw2 f(kw1=False, kw2=True) True f(kw2=False, kw1=True) False But there were some serious drawbacks to use it instead of lambda. * (a,b,c) is impossible * unable to use it with list comprehensions and generator expressions * can't call functions and use its return value * and many builtin functions as you described (such as len(), sorted()) Hye-Shik ___ 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
