I tend to agree about the 1.0 Argument, the lack of a true specification for this functionality makes these things a trial and error process, and until the Iron python user base grows, there just simply isn't enough user coverage to have ironed out the obvious wrinkles (or in some cases, forgetting to iron the wrinkles in ;o) that are cropping up day to day with this support functionality (considering how inactive this list is lately).
Just my two cents though... -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fredrik Lundh Sent: Monday, 13 November 2006 2:14 p.m. To: Discussion of IronPython Subject: Re: [IronPython] base64 bug > >>> import base64 > >>> base64.decodestring('w/==') > '\xc3' > > Now, imagine, what kind of debugging hell the above bug entailed. on the other hand: >>> base64.encodestring("\xc3") 'ww==\n' so it's really the encoder that's broken. unless I'm mistaken, the "w/==" string use the wrong padding (ones in- stead of zeros), and the relevant RFC doesn't specify how to deal with that situation. as far as the specification is concerned, the decoder is free to do whatever it wants when it gets bogus data. (as for the "this is not 1.0" argumentation, I think you're all overestimating how well Python is specified. different CPython releases aren't even com- patible with themselves on things like this, so it's a bit naive to expect an independent implementation to be compatible at a bug-by-bug level) </F> _______________________________________________ users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ users mailing list [email protected] http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
