"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
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
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, 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
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.
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
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
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
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
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.pytho
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
[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
Python-Dev@python.org
http://m
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
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
13 matches
Mail list logo
