Re: [Python-Dev] The "lazy strings" patch
Talin wrote: > Interesting - is it possible that the same technique could be used to > hide differences in character width? Specifically, if I concatenate an > ascii string with a UTF-32 string, can the up-conversion to UTF-32 also > be done lazily? of course. and if all you do with the result is write it to an UTF-8 stream, it doesn't need to be done at all. this requires a slightly more elaborate C-level API interface than today's PyString_AS_STRING API, though... (which is why this whole exercise belongs on the Python 3000 lists, not on python-dev for 2.X) ___ 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] The "lazy strings" patch [was: PATCH submitted: Speed up + for string concatenation, now as fast as "".join(x) idiom]
Larry Hastings schrieb: > I've significantly enhanced my string-concatenation patch, to the point > where that name is no longer accurate. So I've redubbed it the "lazy > strings" patch. It's not clear to me what you want to achieve with these patches, in particular, whether you want to see them integrated into Python or not. > The major new feature is that string *slices* are also represented with > a lazy-evaluation placeholder for the actual string, just as > concatenated strings were in my original patch. The lazy slice object > stores a reference to the original PyStringObject * it is sliced from, > and the desired start and stop slice markers. (It only supports step = > 1.) I think this specific approach will find strong resistance. It has been implemented many times, e.g. (apparently) in NextStep's NSString, and in Java's string type (where a string holds a reference to a character array, a start index, and an end index). Most recently, it was discussed under the name "string view" on the Py3k list, see http://mail.python.org/pipermail/python-3000/2006-August/003282.html Traditionally, the biggest objection is that even small strings may consume insane amounts of memory. > Its ob_sval is NULL until the string is rendered--but that rarely > happens! Not only does this mean string slices are faster, but I bet > this generally reduces overall memory usage for slices too. Channeling Guido: what real-world applications did you study with this patch to make such a claim? > I'm ready to post the patch. However, as a result of this work, the > description on the original patch page is really no longer accurate: > > http://sourceforge.net/tracker/index.php?func=detail&aid=1569040&group_id=5470&atid=305470 > Shall I close/delete that patch and submit a new patch with a more > modern description? After all, there's not a lot of activity on the old > patch page... Closing the issue and opening a new is fine. 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] OT: fdopen on Windows question
[EMAIL PROTECTED] schrieb: > That is, can I change stdin from text to binary this way or is it destined > to always be in text mode? You can call _setmode on the file descriptor. 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] Massive test_sqlite failure on Mac OSX ... sometimes
Followup #2... Yesterday I whittled my problems with test_sqlite on my OSX g5 to test_ctypes and test_sqlite: ./python.exe Lib/test/regrtest.py -l -f tests test_ctypes test_sqlite test test_sqlite failed -- errors occurred; run in verbose mode for details 1 test OK. 1 test failed: test_sqlite Today I refined things further. I renamed all the test_*.py files in Lib/ctypes/test/ until all I was left with was test_find.py. It fails if that's the only ctypes test script run: $ ls -l *.py -rw--- 1 buildbot buildbot 6870 Oct 20 06:30 __init__.py -rw--- 1 buildbot buildbot 624 Oct 20 06:30 runtests.py -rw--- 1 buildbot buildbot 3463 Oct 21 12:52 test_find.py montanaro:~/pybot/trunk.montanaro-g5/build/Lib/ctypes/test buildbot$ cd - /Library/Buildbot/pybot/trunk.montanaro-g5/build montanaro:~/pybot/trunk.montanaro-g5/build buildbot$ ./python.exe Lib/test/regrtest.py -l -f tests test_ctypes test_sqlite test test_sqlite failed -- errors occurred; run in verbose mode for details 1 test OK. 1 test failed: test_sqlite test_find.py contains checks for three OpenGL libraries on darwin: gl, glu and glut. If I comment out all those tests, test_sqlite succeeds. If any of them are enabled, test_sqlite fails. I've taken this about as far as I can. I submitted a bug report here: http://python.org/sf/1581906 Skip ___ 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] The "lazy strings" patch
See also the Cedar Ropes work: http://www.cs.ubc.ca/local/reading/proceedings/spe91-95/spe/vol25/issue12/spe986.pdf Bill ___ 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] ctypes and win64
Thomas Heller schrieb: > The official Python-2.5.amd64.msi does *not* contain ctypes, so > the official Python-2.5.x.amd64.msi should also not contain ctypes (I assume). That would be good, yes. > Not many people (I assume again) are running 64-bit windows, and use the > 64-bit Python > version I also agree. > - but that will probably change soon. It speculation either way, but I disagree. It will take several years until people widely use Win64. For the foreseeable future, there are too many inconveniences to make it practical. > I would like to merge the 64-bit windows related ctypes changes in trunk, as > soon as > I'm sure that they work, back into the release25-maint branch. And also make > separate > ctypes releases from the release25-maint source code. I will only backport > these changes > if I'm convinced that they do not change the functionality of tehe current > code. I understand this. Still, integrating such changes formally introduces a new feature to the 2.5 branch (even though the feature isn't exposed readily). Whether or not this is ok is for the release manager to decide. What I don't understand is what the "64-bit windows related ctypes changes" are. Do they include changes to the PCbuild directory? 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] The "lazy strings" patch
Larry Hastings <[EMAIL PROTECTED]> wrote: > > I've significantly enhanced my string-concatenation patch, to the point > where that name is no longer accurate. So I've redubbed it the "lazy > strings" patch. [snip] Honestly, I don't believe that pure strings should be this complicated. The implementation of the standard string and unicode type should be as simple as possible. The current string and unicode implementations are, in my opinion, as simple as possible given Python's needs. As such, I don't see a need to go mucking about with the standard string implementation to make it "lazy" so as to increase performance, reduce memory consumption, etc.. However, having written a somewhat "lazy" string slicing/etc operation class I called a "string view", whose discussion and implementation can be found in the py3k list, I do believe that having a related type, perhaps with the tree-based implementation you have written, or a simple pointer + length variant like I have written, would be useful to have available to Python. I also believe that it smells like a Py3k feature, which suggests that you should toss the whole string reliance and switch to unicode, as str and unicode become bytes and text in Py3k, with bytes being mutable. - Josiah ___ 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] The "lazy strings" patch
Hmm, I have not viewed the patch in question, but I'm curious why we wouldn't want to include such a patch if it were transparent to the user (Python based or otherwise). Especially if it increased performance without sacrificing maintainability or elegance. Further considering the common usage of strings in usual programming, I fail to see why an implementation like this would not be desirable? If there's a widely recognized argument against this, a link will likely sate my curiosity. Thanks, Mark > ---Original Message--- > From: Josiah Carlson <[EMAIL PROTECTED]> > Subject: Re: [Python-Dev] The "lazy strings" patch > Sent: 21 Oct '06 22:02 > > > Larry Hastings <[EMAIL PROTECTED]> wrote: > > > > I've significantly enhanced my string-concatenation patch, to the point > > where that name is no longer accurate. So I've redubbed it the "lazy > > strings" patch. > [snip] > > Honestly, I don't believe that pure strings should be this complicated. > The implementation of the standard string and unicode type should be as > simple as possible. The current string and unicode implementations are, > in my opinion, as simple as possible given Python's needs. > > As such, I don't see a need to go mucking about with the standard string > implementation to make it "lazy" so as to increase performance, reduce > memory consumption, etc.. However, having written a somewhat "lazy" > string slicing/etc operation class I called a "string view", whose > discussion and implementation can be found in the py3k list, I do > believe that having a related type, perhaps with the tree-based > implementation you have written, or a simple pointer + length variant > like I have written, would be useful to have available to Python. > > I also believe that it smells like a Py3k feature, which suggests that > you should toss the whole string reliance and switch to unicode, as str > and unicode become bytes and text in Py3k, with bytes being mutable. > > > - Josiah > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/mark%40pandapocket.com > ___ 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] Modulefinder
Could you also prepare a patch for the p3yk branch? It's broken there too... On 10/13/06, Thomas Heller <[EMAIL PROTECTED]> wrote: > I have patched Lib/modulefinder.py to work with absolute and relative imports. > It also is faster now, and has basic unittests in > Lib/test/test_modulefinder.py. > > The work was done in a theller_modulefinder SVN branch. > If nobody objects, I will merge this into trunk, and possibly also into > release25-maint, when I have time. -- --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] The "lazy strings" patch
On Sat, 21 Oct 2006, Mark Roberts wrote: [...] > If there's a widely recognized argument against this, a link will likely > sate my curiosity. Quoting from Martin v. Loewis earlier on the same day you posted: """ I think this specific approach will find strong resistance. It has been implemented many times, e.g. (apparently) in NextStep's NSString, and in Java's string type (where a string holds a reference to a character array, a start index, and an end index). Most recently, it was discussed under the name "string view" on the Py3k list, see http://mail.python.org/pipermail/python-3000/2006-August/003282.html Traditionally, the biggest objection is that even small strings may consume insane amounts of memory. """ John ___ 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] Optional type checking/pluggable type systems for Python
Dear All I'm a Master's student at Imperial College London currently selecting a Master's thesis subject. I am exploring the possibility of "optional typing" and "pluggable type systems" (Bracha) for Python. Reading around I see that PEP 246 (object adaption) was dropped for "something better". Is this "something better" currently in production for Python 3000 or just a thinking ground. I'd like to know whether there would be any merit in exploring the project or whether this is something that is going to appear as implementation within the next 6 months (the length of my thesis). If you think it is still something worth exploring I'd plan to pick up the idea as a research project and explore implementations, probabaly in CPython or Jython. Any help with this would be great, could you please reply directly to [EMAIL PROTECTED] as I haven't subscribed to python-dev for a while now. Thanks, Neil Dunn ___ 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] Optional type checking/pluggable type systems for Python
On Sat, Oct 21, 2006, Neil Dunn wrote: > > Any help with this would be great, could you please reply directly to > [EMAIL PROTECTED] as I haven't subscribed to python-dev for a while now. You should also post this to the python-3000 list; the lists do not all have the same readership. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "If you don't know what your program is supposed to do, you'd better not start writing it." --Dijkstra ___ 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] Optional type checking/pluggable type systems forPython
"Neil Dunn" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Dear All > > I'm a Master's student at Imperial College London currently selecting > a Master's thesis subject. I am exploring the possibility of "optional > typing" and "pluggable type systems" (Bracha) for Python. Reading > around I see that PEP 246 (object adaption) was dropped for "something > better". Is this "something better" currently in production for Python > 3000 or just a thinking ground. Thinking, as far as I know. > I'd like to know whether there would be any merit in exploring the > project or whether this is something that is going to appear as > implementation within the next 6 months (the length of my thesis). > > If you think it is still something worth exploring I'd plan to pick up > the idea as a research project and explore implementations, probabaly > in CPython or Jython. > > Any help with this would be great, could you please reply directly to > [EMAIL PROTECTED] as I haven't subscribed to python-dev for a while now. You can follow both python-dev and py3000 lists as newsgroups via news.gmane.org. It also has archives. ___ 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
