Guido van Rossum wrote:
> 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.
Agreed.
Given that we have a source code encoding which would need
to be honored, b"..." doesn't really make all that much sense
(unless you always use hex escapes).
Note that if we drop the string type, all codecs which currently
return strings will have to return bytes. This gives you a pretty
exhaustive way of defining your binary literals in Python :-)
Here's one:
data = "abc".encode("latin-1")
To simplify things we might want to have
bytes("abc")
do the above encoding per default.
> --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/mal%40egenix.com
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Feb 13 2006)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
_______________________________________________
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
