One recommendation: for starters, I'd much rather see the bytes type
standardized without a literal notation. There should be are lots of
ways to create bytes objects from string objects, with specific
explicit encodings, and those should suffice, at least initially.
I also wonder if having a b"..." literal would just add more confusion
-- bytes are not characters, but b"..." makes it appear as if they
are.
--Guido
On 2/11/06, Bengt Richter <[EMAIL PROTECTED]> wrote:
> On Fri, 10 Feb 2006 21:35:26 -0800, Guido van Rossum <[EMAIL PROTECTED]>
> wrote:
>
> >> On Sat, 11 Feb 2006 05:08:09 +0000 (UTC), Neil Schemenauer <[EMAIL
> >> PROTECTED]> > >The backwards compatibility problems *seem* to be
> >> relatively minor.
> >> >I only found one instance of breakage in the standard library. Note
> >> >that my patch does not change PyObject_Str(); that would break
> >> >massive amounts of code. Instead, I introduce a new function:
> >> >PyString_New(). I'm not crazy about the name but I couldn't think
> >> >of anything better.
> >
> >On 2/10/06, Bengt Richter <[EMAIL PROTECTED]> wrote:
> >> Should this not be coordinated with PEP 332?
> >
> >Probably.. But that PEP is rather incomplete. Wanna work on fixing that?
> >
> I'd be glad to add my thoughts, but first of course it's Skip's PEP,
> and Martin casts a long shadow when it comes to character coding issues
> that I suspect will have to be considered.
>
> (E.g., if there is a b'...' literal for bytes, the actual characters of
> the source code itself that the literal is being expressed in could be ascii
> or latin-1 or utf-8 or utf16le a la Microsoft, etc. UIAM, I read that the
> source
> is at least temporarily normalized to Unicode, and then re-encoded (except now
> for string literals?) per coding cookie or other encoding inference. (I may be
> out of date, gotta catch up).
>
> If one way or the other a string literal is in Unicode, then presumably so is
> a byte string b'...' literal -- i.e. internally u"b'...'" just before
> being turned into bytes.
>
> Should that then be an internal straight u"b'...'".encode('byte') with
> default ascii + escapes
> for non-ascii and non-printables, to define the full 8 bits without encoding
> error?
> Should unicode be encodable into byte via a specific encoding? E.g.,
> u'abc'.encode('byte','latin1'),
> to distinguish producing a mutable byte string vs an immutable str type as
> with u'abc'.encode('latin1').
> (but how does this play with str being able to produce unicode? And when do
> these changes happen?)
> I guess I'm getting ahead of myself ;-)
>
> So I would first ask Skip what he'd like to do, and Martin for some hints on
> reading, to avoid
> going down paths he already knows lead to brick walls ;-) And I need to think
> more about PEP 349.
>
> I would propose to do the reading they suggest, and edit up a new version of
> pep-0332.txt
> that anyone could then improve further. I don't know about an early deadline.
> I don't want
> to over-commit, as time and energies vary. OTOH, as you've noticed, I could
> be spending my
> time more effectively ;-)
>
> I changed the thread title, and will wait for some signs from you, Skip,
> Martin, Neil, and I don't
> know who else might be interested...
>
> Regards,
> Bengt Richter
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
