On Mon, Sep 5, 2016 at 6:06 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 5 September 2016 at 06:42, Koos Zevenhoven <k7ho...@gmail.com> wrote: >> On Sun, Sep 4, 2016 at 6:38 PM, Nick Coghlan <ncogh...@gmail.com> wrote: >>> >>> There are two self-consistent sets of names: >>> >> >> Let me add a few. I wonder if this is really used so much that >> bytes.chr is too long to type (and you can do bchr = bytes.chr if you >> want to) >> >> bytes.chr (or bchr in builtins) > > The main problem with class method based spellings is that we need to > either duplicate it on bytearray or else break the bytearray/bytes > symmetry and propose "bytearray(bytes.chr(x))" as the replacement for > current cryptic "bytearray([x])"
Warning: some API-design philosophy below: 1. It's not as bad to break symmetry regarding what functionality is offered for related object types (here: str, bytes, bytearray) than it is to break symmetry in how the symmetric functionality is provided. IOW, a missing unnecessary functionality is less bad than exposing the equivalent functionality under a different name. (This might be kind of how Random832 was reasoning previously) 2. Symmetry is more important in object access functionality than it is in instance creation. IOW, symmetry regarding 'constructors' (here: bchr, bytes.chr, bytes.byte, ...) across different types is not as crucial as symmetry in slicing. The reason is that the caller of a constructor is likely to know which class it is instantiating. A consumer of bytes/bytearray/str-like objects often does not know which type is being dealt with. I might be crying over spilled milk here, but that seems to be the point of the whole PEP. That chars view thing might collect some of the milk back back into a bottle: mystr[whatever] <-> mybytes.chars[whatever] <-> mybytearray.chars[whatever] iter(mystr) <-> iter(mybytes.chars) <-> iter(mybytearray.chars) Then introduce 'chars' on str and this becomes mystring.chars[whatever] <-> mybytes.chars[whatever] <-> mybytearray.chars[whatever] iter(mystr.chars) <-> iter(mybytes.chars) <-> iter(mybytearray.chars) If iter(mystr.chars) is recommended and iter(mystr) discouraged, then after a decade or two, the world may look quite different regarding how important it is for a str to be iterable. This would solve multiple problems at once. Well I admit that "at once" is not really an accurate description of the process :). [...] > You also run into a searchability problem as "chr" will get hits for > both the chr builtin and bytes.chr, similar to the afalg problem that > recently came up in another thread. While namespaces are a honking > great idea, the fact that search is non-hierarchical means they still > don't give API designers complete freedom to reuse names at will. Oh, I can kind of see a point here, especially if the search hits aren't related in any way. Why not just forget all symmetry if this is an issue? But is it really a bad thing if by searching you find that there's a chr for both str and bytes? If I think, "I want to turn my int into a bytes 'character' kind of in the way that chr turns my int into a str". What am I going to search or google for? I can't speak for others, but I would probably search for something that contains 'chr' and 'bytes'. Based on this, I'm unable to see the search disadvantage of bytes.chr. [...] >> bytes.char (or bytes.chr or bchr in builtins) >> bytes.chars, bytearray.chars (sequence views) > > The views are already available via memoryview.cast if folks really > want them, but encouraging their use in general isn't a great idea, as > it means more function developers now need to ask themselves "What if > someone passes me a char view rather than a normal bytes object?". Thanks, I think this is the first real argument I hear against the char view. In fact, I don't think people should ask themselves that question, and just not accept bytes views as input. Would it be enough to discourage storing and passing bytes views? Anyway, the only error that would pass silently would be that the passed-in object gets indexed (e.g. obj[0]) and a bytes-char comes out instead of an int. But it would be a strange thing to do by the caller to pass a char view into the bytes-consumer. I could imagine someone wanting to pass a bytes view into a str-consumer. But there are no significant silently-passing errors there. If str also gets .chars, then it becomes even easier to support this. -- Koos > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia -- + Koos Zevenhoven + http://twitter.com/k7hoven + _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
