bytes.ord is a bad name, given the behavior would be the opposite of ord (ord converts length one str to int, not int to length one str).
PEP467 (currently deferred to 3.9 or later) does have proposals for this case, either bytes.byte (old proposal: https://legacy.python.org/dev/peps/pep-0467/#addition-of-explicit-single-byte-constructors ) or bytes.fromord/a top level built-in named bchr in the new version of the PEP ( https://www.python.org/dev/peps/pep-0467/#addition-of-bchr-function-and-explicit-single-byte-constructors ). So if that's the way we want to go, we could just push forward on PEP467. It's only a subset of Serhiy's broader proposal, though admittedly one of the cases where the existing design is unusually weak and improvements would better fill niches currently occupied by non-obvious solutions. On Tue, May 7, 2019 at 12:23 AM Steven D'Aprano <st...@pearwood.info> wrote: > On Tue, May 07, 2019 at 09:54:03AM +1000, Cameron Simpson wrote: > > On 06May2019 18:47, Antoine Pitrou <solip...@pitrou.net> wrote: > [...] > > >The main constructors for built-in types are used so pervasively that > > >there is no hope of actually removing such deprecated behavior. > > > > I don't find that compelling. I for one would welcome a small suite of > > unambiguous factories that can't be misused. bytes() can easily be > > misused by accident, introducing bugs and requiring debug work. I'd be > > very happy for my own future code to be able to take advantage of hard > > to misuse constructors. > > There is a difference between *adding* new constructor methods, and what > Antoine is saying: that we cannot realistically remove existing uses of > the current constructors. > > I think that Antoine is right: short of another major 2to3 backwards- > incompatible version, the benefit of actually removing any of the > built-in constructor behaviours is too small and the cost is too great. > So I think removal of existing behaviour should be off the table. > > Or at least, taken on a case-by-case basis. Propose a specific API you > want to remove, and we'll discuss that specific API. > > > As for adding *new* constructors: > > > Of course we could all write tiny factories for these modes but (a) we'd > > all have to write and debug them and (b) they'de all have different > > spellings and signatures > > Probably because everyone will want them to do something different. > > We've already seen two different semantics for the same desired > constructor call: > > bytes(10) -> b'10' # like str(), but returning bytes > bytes(10) -> b'\x0A' # like ord(), but returning a byte > > That suggests a possible pair of constructors: > > bytes.from_int(n) -> equivalent to b'%d' % n > bytes.ord(n) -> equivalent to bytes((n,)) > > > The proposal in this thread seems to me to be a blanket call to add new > constructors everywhere, and I don't think that's appropriate. I think > that each proposed new constructor should live or die on its own merits. > The two above for bytes seem like simple, obvious APIs that do something > useful which is otherwise a small pain point. Both are syntactic sugar > for something otherwise ugly or hard to discover. > > I think that, if somebody is willing to do the work (it can't be me, > sorry) adding two new class methods to bytes for the above two cases > would be a nett win, and they should be minor enough that it doesn't > need a PEP. > > Thoughts? > > > > -- > Steven > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
