Nick Coghlan wrote:
> OK, summarising the thread so far from my point of view.
[snip]
> To be honest, I don't think there is a lot we can do here except to
> further emphasise in the documentation and elsewhere that *bytes is
> not a string type* (regardless of any API similarities retained to
> ease transition from the 2.x series). For example, if we have any
> lingering references to "byte strings" they should be replaced with
> "byte sequences" or "bytes objects" (depending on context, as the
> former phrasing also encompasses bytearray objects).
I think this would be a big help.
> 2. As a concrete usability issue, it is awkward to programmatically
> check the value of a specific byte when working with an ASCII based
> protocol:
>
> data[i] == b'a' # Intuitive, but always False due to type mismatch
> data[i:i+1] == b'a' # Works, but clumsy
> data[i] == b'a'[0] # Ditto (but at least susceptible to compiler
> const-expression optimisation)
> data[i] == ord('a') # Clumsy and slow
> data[i] == 97 # Hard to read
>
> Proposals to address this include:
> - introduce a "character" literal to allow c'a' as an alternative to ord('a')
> Potentially workable, but leaves the intuitive answer above
> silently producing an unexpected answer
[snip]
> For point 2, I'm personally +0 on the idea of having 1-element bytes
> and bytearray objects delegate hashing and comparison operations to
> the corresponding integer object. We have the power to make the
> obvious code correct code, so let's do that. However, the implications
> of the additional key collisions in value based containers may need to
> be explored further.
Nick Coghlan also wrote:
> On further reflection, the key collision and semantics blurring
> problems mean I am at best -0 on this particular solution to the
> problem (and heading fairly rapidly in the direction of -1).
Last thought I have for a possible 'solution' -- when a bytes object is
tested for equality against an int raise TypeError. Precedent being
sum() raising a TypeError when passed a list of strings because
performance is so poor. Reason here being that the intuitive behavior
will never work and will always produce silent bugs.
~Ethan~
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4