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/