Re: [IronPython] repr() results with uint, etc.
At least one of those is now fixed in 2.0.1 & 2.6 (http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPython&WorkItemId=20632) The other one I know of is __index__ support, are there more? Seems like doing these all at once makes sense. -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Michael Foord Sent: Saturday, February 07, 2009 6:04 AM To: Discussion of IronPython Subject: Re: [IronPython] repr() results with uint, etc. Dino Viehland wrote: > And the correct change to the source code would be adding __repr__ methods to > the various *Ops types (Int16Ops, UInt16Ops, etc...) which return the correct > formatting. Presumably by updating the scripts that generate these types. > OTOH there's nothing particularly unsafe about your changes other then they > don't match the normal convention for __repr__. > +1 for the changes. There are various other minor places where uints don't behave like numbers, which would be nice to address - especially for Ironclad (and making 64bit support a bit less painful for William). Michael Michael Foord > -Original Message- > From: users-boun...@lists.ironpython.com > [mailto:users-boun...@lists.ironpython.com] On Behalf Of Curt Hagenlocher > Sent: Friday, February 06, 2009 9:36 PM > To: Discussion of IronPython > Subject: Re: [IronPython] repr() results with uint, etc. > > On Fri, Feb 6, 2009 at 9:32 PM, Jeff Slutter wrote: > >> Ok, looking at the source, I see the issue in: >> >> public static string Repr(CodeContext/*!*/ context, object o) >> >> Is it safe to add these types in to there like: >>if ((s = o as string) != null) return StringOps.__repr__(s); >>if (o is int) return Int32Ops.__repr__((int)o); >>if (o is uint) return ((uint)o).ToString(); >>if (o is long) return ((long)o).ToString() + "L"; >>if (o is ulong) return ((ulong)o).ToString() + "UL"; >>if (o is byte) return ((byte)o).ToString(); >>if (o is sbyte) return ((sbyte)o).ToString(); >>if (o is char) return ((char)o).ToString(); >>if (o is Int16) return ((Int16)o).ToString(); >>if (o is UInt16) return ((UInt16)o).ToString(); >> ? >> > > It's traditional (when possible) for repr to return a string > representation of something that can be typed into the interpreter to > get the original object back. This is what distinguishes it from str. > That's why Dino suggested the form he did. > > -- > Curt Hagenlocher > c...@hagenlocher.org > ___ > Users mailing list > Users@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > ___ > Users mailing list > Users@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] repr() results with uint, etc.
I totally agree that it should be done the right way - I didn't know what the right way was. CodePlex issue has been opened: 21040 Thanks! Dino Viehland wrote: > And the correct change to the source code would be adding __repr__ methods to > the various *Ops types (Int16Ops, UInt16Ops, etc...) which return the correct > formatting. Presumably by updating the scripts that generate these types. > OTOH there's nothing particularly unsafe about your changes other then they > don't match the normal convention for __repr__. ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] repr() results with uint, etc.
Dino Viehland wrote: And the correct change to the source code would be adding __repr__ methods to the various *Ops types (Int16Ops, UInt16Ops, etc...) which return the correct formatting. Presumably by updating the scripts that generate these types. OTOH there's nothing particularly unsafe about your changes other then they don't match the normal convention for __repr__. +1 for the changes. There are various other minor places where uints don't behave like numbers, which would be nice to address - especially for Ironclad (and making 64bit support a bit less painful for William). Michael Michael Foord -Original Message- From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Curt Hagenlocher Sent: Friday, February 06, 2009 9:36 PM To: Discussion of IronPython Subject: Re: [IronPython] repr() results with uint, etc. On Fri, Feb 6, 2009 at 9:32 PM, Jeff Slutter wrote: Ok, looking at the source, I see the issue in: public static string Repr(CodeContext/*!*/ context, object o) Is it safe to add these types in to there like: if ((s = o as string) != null) return StringOps.__repr__(s); if (o is int) return Int32Ops.__repr__((int)o); if (o is uint) return ((uint)o).ToString(); if (o is long) return ((long)o).ToString() + "L"; if (o is ulong) return ((ulong)o).ToString() + "UL"; if (o is byte) return ((byte)o).ToString(); if (o is sbyte) return ((sbyte)o).ToString(); if (o is char) return ((char)o).ToString(); if (o is Int16) return ((Int16)o).ToString(); if (o is UInt16) return ((UInt16)o).ToString(); ? It's traditional (when possible) for repr to return a string representation of something that can be typed into the interpreter to get the original object back. This is what distinguishes it from str. That's why Dino suggested the form he did. -- Curt Hagenlocher c...@hagenlocher.org ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com