Thank you for your efforts with IronPython 2.6.1. I am looking forward to the
final product.
I was testing 2.6.1 RC1 to see if an issue I was having with v2.6.0 was fixed
and I ran into an interesting problem with pyReadLine (v1.13), which I had
installed under CPython v2.6.4. A python-based
On 11/02/2010 15:44, Vernon Cole wrote:
Just a little reminder in all this noise...
The correct thing to do with unicode(u'a unicode string') is MAKE NO
CHANGE.
The correct thing to do with str('an ASCII string') is MAKE NO CHANGE.
I assume by ASCII string you actually mean bytestring?
Wow, that's awful.
I imagine that you would need to use VirtualProtect to make that page
writeable in order for this to work. I can't see how modifying IronPython's
ctypes to make this possible would be a good idea -- the vast majority of
uses for ctypes don't involve writing into arbitrary DLL
David,
A big thank you to you and all of the IP team for this; the import speed
enhancement is particularly welcome. We'll try it out in Resolver One
and report back to the list.
Regards,
Giles
On 10/02/2010 21:55, David DiCato wrote:
Hello Python Community,
We're pleased to announce
This is an automated email letting you know that sources
have recently been pushed out. You can download these newer
sources directly from
http://ironpython.codeplex.com/SourceControl/changeset/view/63918.
MODIFIED SOURCES
On Thu, Feb 11, 2010 at 8:44 AM, Vernon Cole vernondc...@gmail.com wrote:
Just a little reminder in all this noise...
The correct thing to do with unicode(u'a unicode string') is MAKE NO CHANGE.
The correct thing to do with str('an ASCII string') is MAKE NO CHANGE.
Ah, but it's not string
Actually this looks like a bug in IronPython. ctypes.addressof(msvcrt.system)
is returning the wrong value - in CPython it's returning the address which
points to the function. In IronPython it's returning the address of the
function it's self.
Hopefully the real code is doing something more
I've created http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=26185
but I already have a fix for this.
From: users-boun...@lists.ironpython.com
[mailto:users-boun...@lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Thursday, February 11, 2010 10:14 AM
To: Discussion of
On Thu, Feb 11, 2010 at 8:48 AM, Michael Foord fuzzy...@voidspace.org.ukwrote:
On 11/02/2010 15:44, Vernon Cole wrote:
Just a little reminder in all this noise...
The correct thing to do with unicode(u'a unicode string') is MAKE NO
CHANGE.
The correct thing to do with str('an ASCII
Dino,
The readline module is patching the PyOS_ReadLineFunctionPointer variable in
the DLL that implements the sys module (in CPython's case, this is the
Python26.dll). Since IronPython doesn't support intercepting line reads in
this way (or at all, apparently), this isn't going to work on
Vernon wrote:
You need the 'byte' class for Python 3 anyway. Implement it now.
Done! Assuming you mean bytes it’s in 2.6 already. Now if everyone would
upgrade their code to use b’’ :)
A small sample...
code x.py
import sys
u = u'1234\u00f6'
s = '1234'
x = str(s)
print type(x),
No reason not to fix this bug though :) I'd suggest that readline should check
for dllhandle being 0 and have some sort of graceful fallback. Long term we
might find having a fake dllhandle might be useful - that way we could work
better with ctypes code doing low level stuff.
From:
Oh, I should also add I think Michael's proposed fix makes this code work
correctly.
-Original Message-
From: users-boun...@lists.ironpython.com [mailto:users-
boun...@lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Thursday, February 11, 2010 11:07 AM
To: Discussion of
Dear Dino and Jeff:
I think we are all on the same wavelength. IronPython makes unicode and
str the same implicitly. Python 3 makes them the same explicitly -- by
getting rid of __unicode__ completely.
The effort to make django (or any other application) run on IronPython
and the effort to
And it turns out this works great! We now pass all of the tests in
test_str and test_unicode related to calling str/unicode and getting
the appropriate __str__/__unicode__ method called. We also now properly
don't decode strings when you do unicode('foo') so we no longer throw
for Vernon's
On Thu, Feb 11, 2010 at 8:37 PM, Dino Viehland di...@microsoft.com wrote:
And it turns out this works great! We now pass all of the tests in
test_str and test_unicode related to calling str/unicode and getting
the appropriate __str__/__unicode__ method called. We also now properly
don't
16 matches
Mail list logo
