[Python-Dev] Re: PEP 467 feedback from the Steering Council
On Fri, 10 Sep 2021, 12:32 am Arnaud Delobelle, wrote: > It probably won't fly but why not bytes.frombyte? > > There's no such thing as a byte type in Python, only bytes, so I want > to argue it makes it clear the argument is a number in the range > 0..255 and the result is a bytes object containing this single byte > value. > The getbyte() and iterbytes() methods added by the PEP make a length 1 bytes object the pseudo "byte" type, just as a length 1 string is the pseudo "character" (technically "code point") type, so "frombyte()" would have the type implications backwards (it produces a "byte", it doesn't really read one). I think it's OK for "int.from_bytes", "int.to_bytes", "bytes.fromint" and "byte array.fromint" to have closely related names, since they're closely related operations. The OverflowError raised for out of bounds values in the latter two methods could even mention int.to_bytes explicitly. While the SC already accepted "fromint", the range limitation could be made more explicit by appending "byte" to give "bytes.fromintbyte" and "bytearray.fromintbyte" (thus naming a pseudo "int byte" type for integers in the range 0-255 inclusive). An advantage of this approach is to give a specific name to the kinds of values that regular indexing and iteration of bytes objects produce. The SC has already rejected "fromord" as too obscure. I'd be OK with bytes.bchr, but bytearray.bchr would look odd to me, so I don't like that option as a whole. For "bytes.byte", I have 3 objections: * I think Greg's Smith's API stuttering concerns are valid * I think it's potentially ambiguous as to whether it is an alternate constructor or an indexed access method (i.e. doing what getbyte() does in the PEP) * I don't like it as a bytearray method name Cheers, Nick. > Tentatively, > > Arnaud > > PS. But truly I feel like this method is superfluous. > > On Thu, 9 Sept 2021 at 11:11, Victor Stinner wrote: > > > > I proposed bytes.byte earlier in this thread: > > > https://mail.python.org/archives/list/python-dev@python.org/message/KBVVBJL2PHI55Y26Z4FMSCJPER242LFA/ > > > > Gregory dislikes the name: "I don't *like* to argue over names (the > > last stage of anything) but I do need to point out how that sounds to > > read". > > > https://mail.python.org/archives/list/python-dev@python.org/message/DGJWM3VMNMDBUTGYG72H5WLKDWBYFSUV/ > > > > That's why I proposed: bytes.fromchar(). I still like bytes.byte() :-) > > > > Victor > > > > On Thu, Sep 9, 2021 at 11:07 AM Antoine Pitrou > wrote: > > > > > > On Thu, 9 Sep 2021 18:55:04 +1000 > > > Nick Coghlan wrote: > > > > > > > > P.S. The fact that it *didn't* look like the inverse operation for > > > > `int.from_bytes` was one advantage of calling the method > > > > `bytes.fromord` instead of `bytes.fromint`, but I'm still happy the > SC > > > > is right that `bytes.fromint` is a more comprehensible method name > > > > overall. > > > > > > Perhaps we can call it `bytes.byte` to make it unambiguous? > > > > > > Regards > > > > > > Antoine. > > > > > > > > > ___ > > > Python-Dev mailing list -- python-dev@python.org > > > To unsubscribe send an email to python-dev-le...@python.org > > > https://mail.python.org/mailman3/lists/python-dev.python.org/ > > > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/WZUPBP4UASRCJLAKP6FMQJLLMYJY22CL/ > > > Code of Conduct: http://python.org/psf/codeofconduct/ > > > > > > > > -- > > Night gathers, and now my watch begins. It shall not end until my death. > > ___ > > Python-Dev mailing list -- python-dev@python.org > > To unsubscribe send an email to python-dev-le...@python.org > > https://mail.python.org/mailman3/lists/python-dev.python.org/ > > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/6W4G32NOBXAQ73VESVE4UL7AZIWUAD6A/ > > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/P7XG5CLLBXZTS6UE72KSGWLVYXRDXKT4/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/OJBHNWKKCWUN25GMONL3BGGW6I3TGYUV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
Adding default arguments to int.to_bytes() is both useful on its own merits and kind of too easy *not* to do, so... https://bugs.python.org/issue45155 https://github.com/python/cpython/pull/28265 -Barry > On Sep 9, 2021, at 12:12, Barry Warsaw wrote: > > Signed PGP part > On Sep 9, 2021, at 10:56, Ethan Furman wrote: >> >> On 9/9/21 9:37 AM, Barry Warsaw wrote: >> >>> While I think int.to_bytes() is pretty obscure (I knew about it, forgot >>> about it, and learned >>> about it again!) I’m not so sure it’s any less obscure than a proposed >>> bytes.fromint(). >>> >>> So why don’t we just relax int.to_bytes()’s signature to include natural >>> default values: >>> >>> int.to_bytes(length=1, byteorder=sys.byteorder, *, signed=False) >>> >>> Then I ought to be able to just do >>> >> (65).to_bytes() >>> b’A’ >> >> That seems so much worse than >> > bchr(65) >> b'A' >> >> ;-) > > Maybe, but given that you can *already* do the equivalent of bchr() with: > (65).to_bytes(1, sys.byteorder) > b'A' > > it seems like a small stretch to make that more usable, and that would > outweigh adding a difficult to understand new builtin. TOOWTDI. > > In case you really want bchr(): > > def bchr(x): >return x.to_bytes(1, sys.byteorder) > bchr(65) > b’A' > > Cheers, > -Barry > > > signature.asc Description: Message signed with OpenPGP ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ZQWVF2HVGNDFQFMRFLEYRZ4UVVSPLOHN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 646 (Variadic Generics): final call for comments
Hi all, I very much share Stephan's opinion here and look forward to integrating the new PEP 646 variadics into numpy. In the context of numpy (and tensor typing general): the typing of array shapes is a fairly complicated subject and the introduction of variadics will likely play in big role in laying its foundation, as it allows for the expression of both dimensioability as well as basic shape manipulation . All in all, I'm very interested in where both PEP 646 and future PEPs will take us and look forward to further developments. Regards, Bas van Beek ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/5EXONQYGYWIUQ6GHRV3DIEJ27OFFYCN3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
On 9/9/21 12:12 PM, Barry Warsaw wrote: > On Sep 9, 2021, at 10:56, Ethan Furman wrote: >> On 9/9/21 9:37 AM, Barry Warsaw wrote: >> >>> While I think int.to_bytes() is pretty obscure (I knew about it, forgot about it, and learned >>> about it again!) I’m not so sure it’s any less obscure than a proposed bytes.fromint(). >>> >>> So why don’t we just relax int.to_bytes()’s signature to include natural default values: >>> >>> int.to_bytes(length=1, byteorder=sys.byteorder, *, signed=False) >>> >>> Then I ought to be able to just do >>> >>> >>> (65).to_bytes() >>> b’A’ >> >> That seems so much worse than >> >> >>> bchr(65) >> b'A' >> >> ;-) > > Maybe, but given that you can *already* do the equivalent of bchr() with: > (65).to_bytes(1, sys.byteorder) > b'A' > > it seems like a small stretch to make that more usable, and that would outweigh adding a difficult > to understand new builtin. TOOWTDI. FWIW, bchr doesn't feel (much) like a new built-in, but more like a swap from unichr. At any rate, I know the built-in is not going to happen. int.to_bytes() doesn't feel like the One Obvious Way to me, and it certainly doesn't do much for readability in the bytearray case. Instead of `.fromord()` or `.fromint()` (or `int.to_bytes()`), my new favorite name, guaranteed not to change for at least the rest the day, is: bytes.chr() bytearray.chr() - this gets rid of the superflous b in bchr (not needed as the method is on bytes/bytearray) - has a nice symmetry with both the Python 3 chr(), and the answer to "where did the Python 2 chr() go?" question -- ~Ethan~ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/WJOTPVYSPLK4RX2EFO2C4XK6KJ4Y47LE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
On Sep 9, 2021, at 10:56, Ethan Furman wrote: > > On 9/9/21 9:37 AM, Barry Warsaw wrote: > > > While I think int.to_bytes() is pretty obscure (I knew about it, forgot > > about it, and learned > > about it again!) I’m not so sure it’s any less obscure than a proposed > > bytes.fromint(). > > > > So why don’t we just relax int.to_bytes()’s signature to include natural > > default values: > > > > int.to_bytes(length=1, byteorder=sys.byteorder, *, signed=False) > > > > Then I ought to be able to just do > > > > >>> (65).to_bytes() > > b’A’ > > That seems so much worse than > >>>> bchr(65) >b'A' > > ;-) Maybe, but given that you can *already* do the equivalent of bchr() with: >>> (65).to_bytes(1, sys.byteorder) b'A' it seems like a small stretch to make that more usable, and that would outweigh adding a difficult to understand new builtin. TOOWTDI. In case you really want bchr(): def bchr(x): return x.to_bytes(1, sys.byteorder) >>> bchr(65) b’A' Cheers, -Barry signature.asc Description: Message signed with OpenPGP ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/KZOWPMF5SPOEB4PR7ZNPFVS6D5BE6WIR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
On 9/9/2021 1:56 PM, Ethan Furman wrote: On 9/9/21 9:37 AM, Barry Warsaw wrote: > While I think int.to_bytes() is pretty obscure (I knew about it, forgot about it, and learned > about it again!) I’m not so sure it’s any less obscure than a proposed bytes.fromint(). > > So why don’t we just relax int.to_bytes()’s signature to include natural default values: > > int.to_bytes(length=1, byteorder=sys.byteorder, *, signed=False) Default arg values are one of Python's great features. > Then I ought to be able to just do > > >>> (65).to_bytes() > b’A’ That seems so much worse than >>> bchr(65) b'A' ;-) Except that .to_bytes already exists, and arguably should have had such defaults from the beginning, making any new function to do the same thing superfluous. -- Terry Jan Reedy ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/A7OQPRVVE4WPQ7YCIMCGK2AMPXR6GYTB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
On 9/9/21 9:37 AM, Barry Warsaw wrote: > While I think int.to_bytes() is pretty obscure (I knew about it, forgot about it, and learned > about it again!) I’m not so sure it’s any less obscure than a proposed bytes.fromint(). > > So why don’t we just relax int.to_bytes()’s signature to include natural default values: > > int.to_bytes(length=1, byteorder=sys.byteorder, *, signed=False) > > Then I ought to be able to just do > > >>> (65).to_bytes() > b’A’ That seems so much worse than >>> bchr(65) b'A' ;-) -- ~Ethan~ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/2XY5B7KIODN4Q5EB6HUKVKMVOV7TPJUH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
> I would rather keep `bchr` and lose the `.fromint()` methods. For me, "bchr" isn't a readable name. If I expand mentally expand it to "byte_character", it becomes an oxymoron that opposes what we try teach about bytes and characters being different things. Can you show examples in existing code of how this would be used? I'm unclear on how frequently users need to create a single byte from an integer. For me, it is very rare. Perhaps once in a large program will I search for a record separator in binary data. I would prefer to write it as: RS = byte.fromint(30) ... i = data.index(RS, start) ... if RS in data: Having this as bchr() wouldn't make the code better because it is less explicit about turning an integer into a byte. Also, it doesn't look nice when in-lined without giving it a variable name: i = data.index(bchr(30), start) # Yuck ... if bchr(30) in data:# Yuck Also keep in mind that we already have a way to spell it, "bytes([30])", so any new way needs to significantly add more clarity. I think bytes.fromint() does that. The number of use cases also matters. The bar for adding a new builtin function is very high. Raymond ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/DOUFRRLGMAFYJZ4ONYK6CKHHCYKPXJBW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
While I think int.to_bytes() is pretty obscure (I knew about it, forgot about it, and learned about it again!) I’m not so sure it’s any less obscure than a proposed bytes.fromint(). So why don’t we just relax int.to_bytes()’s signature to include natural default values: int.to_bytes(length=1, byteorder=sys.byteorder, *, signed=False) Then I ought to be able to just do >>> (65).to_bytes() b’A’ and if I try to convert an integer value greater than 255, I get the same OverflowError? Seems good enough to me. -Barry > On Sep 9, 2021, at 08:53, Christopher Barker wrote: > > I fully admit serious bikeshedding here, but: > > I'm starting to think the name should be `bytes.bchr` -- it avoids any > confusion with the `int.to_bytes` and > `int.from_bytes` methods, > > are they so different? :-) > > In [23]: x.to_bytes(1, 'little') > Out[23]: b'A' > > In [27]: int.from_bytes(b'A', 'little') > Out[27]: 65 > > you can think of this as a useful specific case of the int methods. > > (by the way, why do I need to specify the byte order for a 1 byte int? Yes, I > know, it's always a required parameter -- though that 's one reason to have > the special case easily available) > > and is an appropriate name for the target domain (where bytes are treated as > characters). > > Is that the target domain? Yes, it's an important use case, but certainly not > the only one, and frankly kind of a specialized use case actually. If you are > working with characters (text) in Python 3, you should be using the str type. > > Using bytes for general text (even if you know the text at hand is all ASCII) > is not recommended. It is useful to use bytes for the specialized use case of > mixed text and binary data (which, by the way, I have had to do) but I don't > think we should say that particular use case is what bytes are targeted for. > Anyone doing that should know what they are doing :-) > > -CHB > > -- > Christopher Barker, PhD (Chris) > > Python Language Consulting > - Teaching > - Scientific Software Development > - Desktop GUI and Web Development > - wxPython, numpy, scipy, Cython > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/S3Q6NYRXHKUQLMP7WCQMCEEK3MCCGKNJ/ > Code of Conduct: http://python.org/psf/codeofconduct/ signature.asc Description: Message signed with OpenPGP ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/PUR7UCOITMMH6TZVVJA5LKRCBYS4RBMR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
On Sep 9, 2021, at 08:53, Christopher Barker wrote: > > I fully admit serious bikeshedding here, but: I think you meant “byte-shedding” :D -Barry signature.asc Description: Message signed with OpenPGP ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/SBS344CMJGIJZ2YW7Z4EYV6QZW3XPOO5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
On 9/9/21 8:53 AM, Christopher Barker wrote: > On 9/9/21 7:25 AM, Ethan Furman wrote: >> I'm starting to think the name should be `bytes.bchr` -- it avoids any confusion with the `int.to_bytes` and >> `int.from_bytes` methods, > > are they so different? :-) Yes, they are. Conceptually, one is working with integers, the other with bytestrings (which is either entirely ASCII encoded strings, or a mixture of the two). >> and is an appropriate name for the target domain (where bytes are treated as characters). > > Is that the target domain? Yes. PEP 467*, and PEP 461 before it, are targeting the wire format protocol domain. -- ~Ethan~ * The `fromint/bchr` portion for sure, and the other changes certainly help there although they may have wider uses. PEP 461: https://www.python.org/dev/peps/pep-0461/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/U4HOIBFOSQGUGKFI3GGFGBFPNPIQSIH7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
I fully admit serious bikeshedding here, but: I'm starting to think the name should be `bytes.bchr` -- it avoids any > confusion with the `int.to_bytes` and > `int.from_bytes` methods, are they so different? :-) In [23]: x.to_bytes(1, 'little') Out[23]: b'A' In [27]: int.from_bytes(b'A', 'little') Out[27]: 65 you can think of this as a useful specific case of the int methods. (by the way, why do I need to specify the byte order for a 1 byte int? Yes, I know, it's always a required parameter -- though that 's one reason to have the special case easily available) and is an appropriate name for the target domain (where bytes are treated > as characters). > Is that the target domain? Yes, it's an important use case, but certainly not the only one, and frankly kind of a specialized use case actually. If you are working with characters (text) in Python 3, you should be using the str type. Using bytes for general text (even if you know the text at hand is all ASCII) is not recommended. It is useful to use bytes for the specialized use case of mixed text and binary data (which, by the way, I have had to do) but I don't think we should say that particular use case is what bytes are targeted for. Anyone doing that should know what they are doing :-) -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/S3Q6NYRXHKUQLMP7WCQMCEEK3MCCGKNJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
It probably won't fly but why not bytes.frombyte? There's no such thing as a byte type in Python, only bytes, so I want to argue it makes it clear the argument is a number in the range 0..255 and the result is a bytes object containing this single byte value. Tentatively, Arnaud PS. But truly I feel like this method is superfluous. On Thu, 9 Sept 2021 at 11:11, Victor Stinner wrote: > > I proposed bytes.byte earlier in this thread: > https://mail.python.org/archives/list/python-dev@python.org/message/KBVVBJL2PHI55Y26Z4FMSCJPER242LFA/ > > Gregory dislikes the name: "I don't *like* to argue over names (the > last stage of anything) but I do need to point out how that sounds to > read". > https://mail.python.org/archives/list/python-dev@python.org/message/DGJWM3VMNMDBUTGYG72H5WLKDWBYFSUV/ > > That's why I proposed: bytes.fromchar(). I still like bytes.byte() :-) > > Victor > > On Thu, Sep 9, 2021 at 11:07 AM Antoine Pitrou wrote: > > > > On Thu, 9 Sep 2021 18:55:04 +1000 > > Nick Coghlan wrote: > > > > > > P.S. The fact that it *didn't* look like the inverse operation for > > > `int.from_bytes` was one advantage of calling the method > > > `bytes.fromord` instead of `bytes.fromint`, but I'm still happy the SC > > > is right that `bytes.fromint` is a more comprehensible method name > > > overall. > > > > Perhaps we can call it `bytes.byte` to make it unambiguous? > > > > Regards > > > > Antoine. > > > > > > ___ > > Python-Dev mailing list -- python-dev@python.org > > To unsubscribe send an email to python-dev-le...@python.org > > https://mail.python.org/mailman3/lists/python-dev.python.org/ > > Message archived at > > https://mail.python.org/archives/list/python-dev@python.org/message/WZUPBP4UASRCJLAKP6FMQJLLMYJY22CL/ > > Code of Conduct: http://python.org/psf/codeofconduct/ > > > > -- > Night gathers, and now my watch begins. It shall not end until my death. > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/6W4G32NOBXAQ73VESVE4UL7AZIWUAD6A/ > Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/P7XG5CLLBXZTS6UE72KSGWLVYXRDXKT4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
On 9/9/21 1:55 AM, Nick Coghlan wrote: > `bytes.fromint` is still the inverse of `ord` for bytes objects, even > without the `bchr` builtin alias. The spelling of the trio is just > `ord`/`bytes.fromint`/`chr` rather than `ord`/`bchr`/`chr`. The fact > the method throws an exception for integers that won't fit in a single > byte is an input data validation feature, not an undesirable > limitation. I'm starting to think the name should be `bytes.bchr` -- it avoids any confusion with the `int.to_bytes` and `int.from_bytes` methods, and is an appropriate name for the target domain (where bytes are treated as characters). -- ~Ethan~ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/LR6GZQEUBD6Q3AULB7ERPHLRCGJSFM4E/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
Brandt Bucher wrote: > You can even get creative and use the dedicated “pistol” operator… Ah, wait, ignore this example. I got the chr and ord behavior flipped in my head. Brandt ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/6JWFGVLOYIIDGATFNO3YUJTZPELXOK4E/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
On 9/9/21 3:49 AM, Steven D'Aprano wrote: > We're Python programmers. To Python programmers, the int 20 is not a > space character. That's because int 32 is the space character. ;-) -- ~Ethan~ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/6W5QDU6Q62BHTJKZG6TO634QXWD44O2F/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
Steven D'Aprano wrote: > TIL :-) > How have I never noticed to_bytes until now? o_O I’m going to go out on a limb here: because it’s rarely ever needed? I mean, the proposed bchr() functionality is crazy simple to implement yourself if you actually *do* need it. You can even get creative and use the dedicated “pistol” operator: >>> b = b"*" >>> i ,= b >>> i 42 ;) Brandt ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/AO5IOMBK2I5TSUBSRHEM75F6I3KC7AKP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
On Thu, Sep 09, 2021 at 12:29:46AM +0100, Rob Cliffe via Python-Dev wrote: > Why not byte() ? Too easy to typo it as bytes(). -- Steve ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/GL5JFNJE5MH7APLG34HRUITU3GIUEBIC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
On Wed, Sep 08, 2021 at 05:06:08PM -, Brandt Bucher wrote: > Steven D'Aprano wrote: > > To me, it sounds like should be the opposite of int.from_bytes. > > >>> int.from_bytes(b'Hello world', 'little') > > 121404708502361365413651784 > > >>> bytes.from_int(121404708502361365413651784, 'little') > > # should return b'Hello world' > > If that's not the API being suggested, that's going to be confusing. > > I'm a bit lost here... why are we convinced at all that we need a new > way to do this? Hasn't this functionality already existed for years? > > >>> x = int.from_bytes(b"*", "little") > >>> x > 42 > >>> x.to_bytes(1, "little") > b'*' TIL :-) How have I never noticed to_bytes until now? o_O -- Steve ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/QLYAHWFN5V27RKIJWTGFNYLG7KQJMJ6Q/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
On Thu, Sep 09, 2021 at 10:57:26AM +0200, Victor Stinner wrote:
> I propose to rename PEP 467 method bytes.fromint(n) to =>
> bytes.fromchar(n) <= to convert an integer to a single *character*: it
> fails if n is not in the [0; 255] range. "char" comes from
> "character", as "bchr()" means "bytes character".
Integers 0...255 are not characters. They are ints.
`bytes.fromchar` would have to accept a string of length 1, as in:
bytes.fromchar('a') # returns b'a'
otherwise the name is completely inaccurate.
> For C programmers,
We're Python programmers. To Python programmers, the int 20 is not a
space character.
> I suggest to *not* add a builtin function bchr(), it's not common
> enough to justify to add it
Agreed, having a builtin bchr() function doesn't seem to be justified.
We can always add it in the future if needed, but using a bytes method
should be fine.
--
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/K4ZMZXWABQS5RD7OSIRFGSNJTPVRC3X2/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
On Thu, 9 Sep 2021 12:06:49 +0200 Victor Stinner wrote: > I proposed bytes.byte earlier in this thread: > https://mail.python.org/archives/list/python-dev@python.org/message/KBVVBJL2PHI55Y26Z4FMSCJPER242LFA/ > > Gregory dislikes the name: "I don't *like* to argue over names (the > last stage of anything) but I do need to point out how that sounds to > read". > https://mail.python.org/archives/list/python-dev@python.org/message/DGJWM3VMNMDBUTGYG72H5WLKDWBYFSUV/ > > That's why I proposed: bytes.fromchar(). I still like bytes.byte() :-) Well, the proposed function converts *from* an integer *to* a byte "character". But the term character is a bit unfortunate here as well, since characters in Python are Unicode. Regards Antoine. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/BXUPHBDTEGSBZGEXYDUERLGL5BTYB5DY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
I proposed bytes.byte earlier in this thread: https://mail.python.org/archives/list/python-dev@python.org/message/KBVVBJL2PHI55Y26Z4FMSCJPER242LFA/ Gregory dislikes the name: "I don't *like* to argue over names (the last stage of anything) but I do need to point out how that sounds to read". https://mail.python.org/archives/list/python-dev@python.org/message/DGJWM3VMNMDBUTGYG72H5WLKDWBYFSUV/ That's why I proposed: bytes.fromchar(). I still like bytes.byte() :-) Victor On Thu, Sep 9, 2021 at 11:07 AM Antoine Pitrou wrote: > > On Thu, 9 Sep 2021 18:55:04 +1000 > Nick Coghlan wrote: > > > > P.S. The fact that it *didn't* look like the inverse operation for > > `int.from_bytes` was one advantage of calling the method > > `bytes.fromord` instead of `bytes.fromint`, but I'm still happy the SC > > is right that `bytes.fromint` is a more comprehensible method name > > overall. > > Perhaps we can call it `bytes.byte` to make it unambiguous? > > Regards > > Antoine. > > > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/WZUPBP4UASRCJLAKP6FMQJLLMYJY22CL/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Night gathers, and now my watch begins. It shall not end until my death. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/6W4G32NOBXAQ73VESVE4UL7AZIWUAD6A/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
On Thu, 9 Sep 2021 18:55:04 +1000 Nick Coghlan wrote: > > P.S. The fact that it *didn't* look like the inverse operation for > `int.from_bytes` was one advantage of calling the method > `bytes.fromord` instead of `bytes.fromint`, but I'm still happy the SC > is right that `bytes.fromint` is a more comprehensible method name > overall. Perhaps we can call it `bytes.byte` to make it unambiguous? Regards Antoine. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/WZUPBP4UASRCJLAKP6FMQJLLMYJY22CL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
Hum, it seems like this is a confusion between converting a whole bytes *string* to/from an integer, and converting a single *character* to/from an integer. I propose to rename PEP 467 method bytes.fromint(n) to => bytes.fromchar(n) <= to convert an integer to a single *character*: it fails if n is not in the [0; 255] range. "char" comes from "character", as "bchr()" means "bytes character". For C programmers, the usage of the "char" type is common for a single *character*. The char type is not treated as an integer, but part of a character string. All string functions take "char*" type (strcpy, printf, etc.). Converting an integer to a "char" in C: "int x = 1; char ch = (char)x;". I suggest to *not* add a builtin function bchr(), it's not common enough to justify to add it: it's trivial to create you own bchr() function: bchr = bytes.fromchar By the way, it's a little unfortunate that int methods have an underscore in their name (int.to_bytes, int.bit_length, int.as_integer_ratio), whereas bytes methods have no undersore in their name (bytes.removeprefix, bytes.islower). I guess that we should follow the trend of existing methods: so no underscore for bytes/bytearray methods. Victor On Wed, Sep 8, 2021 at 7:06 PM Brandt Bucher wrote: > > Steven D'Aprano wrote: > > To me, it sounds like should be the opposite of int.from_bytes. > > >>> int.from_bytes(b'Hello world', 'little') > > 121404708502361365413651784 > > >>> bytes.from_int(121404708502361365413651784, 'little') > > # should return b'Hello world' > > If that's not the API being suggested, that's going to be confusing. > > I'm a bit lost here... why are we convinced at all that we need a new way to > do this? Hasn't this functionality already existed for years? > > >>> x = int.from_bytes(b"*", "little") > >>> x > 42 > >>> x.to_bytes(1, "little") > b'*' > > Brandt > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/FMG5K4BOX5GSUR2KU3G5ZLBBUIC3EQKD/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Night gathers, and now my watch begins. It shall not end until my death. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/TGUWZ7FV7CA5LOCPIFOP3WUP6Z5NQDTD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 467 feedback from the Steering Council
On Thu, 9 Sept 2021 at 01:46, Ethan Furman wrote: > > On 9/7/21 10:39 PM, Steven D'Aprano wrote: > > On Tue, Sep 07, 2021 at 08:09:33PM -0700, Barry Warsaw wrote: > > > >> I think Nick is on board with bytes.fromint() and no bchr(), and my > >> sense of the sentiment here is that this would be an acceptable > >> resolution for most folks. Ethan, can you reconsider? > > > > I haven't been completely keeping up with the entire thread, so > > apologies if this has already been covered. I assume that the idea is > > that bytes.fromint should return a single byte, equivalent to chr() > > returning a single character. > > > > To me, it sounds like should be the opposite of int.from_bytes. > > > > >>> int.from_bytes(b'Hello world', 'little') > > 121404708502361365413651784 > > >>> bytes.from_int(121404708502361365413651784, 'little') > > # should return b'Hello world' > > That certainly makes sense to me. At this point, the only reason that would > not work is an arbitrary limit of 255 on > the input, and the only reason that limit is there is to have `bchr` be the > inverse of `ord`. Since `bchr` isn't going > to happen, I see no reason to have the 255 limit. `byteorder` can default to > None with a requirement of being set when > the integer is over 255. I've posted a PR removing bchr from the proposal: https://github.com/python/peps/pull/2068/files `bytes.fromint` is still the inverse of `ord` for bytes objects, even without the `bchr` builtin alias. The spelling of the trio is just `ord`/`bytes.fromint`/`chr` rather than `ord`/`bchr`/`chr`. The fact the method throws an exception for integers that won't fit in a single byte is an input data validation feature, not an undesirable limitation. As Brandt already noted, we don't need a new general purpose int to bytes converter as `int.to_bytes` already has that covered. Cheers, Nick. P.S. The fact that it *didn't* look like the inverse operation for `int.from_bytes` was one advantage of calling the method `bytes.fromord` instead of `bytes.fromint`, but I'm still happy the SC is right that `bytes.fromint` is a more comprehensible method name overall. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/2QO35ROTATWQWR6DMHY5BOS25QK2YLER/ Code of Conduct: http://python.org/psf/codeofconduct/
