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 resul
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
[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://m
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
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.pytho
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
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 im
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 usa
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.
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
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
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 ([E
"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
13 matches
Mail list logo
