Re: [Python-Dev] PEP 467: Minor API improvements for bytes & bytearray
On Aug 17, 2014, at 09:39 PM, Antoine Pitrou wrote: >> need for a special case for a single byte. We already have a perfectly >> good spelling: >> NUL = bytes([0]) > >That is actually a very cumbersome spelling. Why should I first create a >one-element list in order to create a one-byte bytes object? I feel the same way every time I have to write `set(['foo'])`. -Barry ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
On Aug 17, 2014, at 06:02 PM, Guido van Rossum wrote: >I'm unsure about what's the single biggest pain moving to Python 3. In the >past I would have said that it's for sure the bytes/str split (which both >the biggest pain and the biggest payoff). > >But if I look carefully into the soul of teams that are still on 2.7 (I >know a few... :-), I think the real reason is that Python 3 changes so many >different things, you have to actually understand your code to port it >(unlike with minor version transitions, where the changes usually spike in >one specific area, and you can leave the rest to normal attrition and >periodic maintenance). The latter is a good point, and sometimes it's a huge challenge to understand the code being ported. A good test suite (and dare I say, doctests :) help a lot with this. I've ported a ton of stuff, and failed at a few. I think all the little changes are mostly tractable, and we've assembled a pretty good stack of documents to help[*]. Sometimes a seemingly easy and mechanical port will produce odd failures, where more domain expertise needs to be brought to bear to get just the right bilingual invocation. But if the underlying code does not itself have a clear bytes/str distinction, then you're doomed. One of my failures was a Python binding for a large C++ project that deeply conflated data and text. Another was a pure Python library that essentially did the same. In both cases, I ended up in a situation where some core types could be neither str nor bytes without some part of the test suite failing miserably. Those are the types of projects that largely get left unported since it's much harder to justify the costs vs. benefits. Cheers, -Barry [*] https://wiki.python.org/moin/PortingToPy3k/BilingualQuickRef signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: PEP 467: Minor API improvements for bytes & bytearray
On Aug 17, 2014, at 09:48 PM, Donald Stufft wrote: >from __future__ import bytesdoneright? :D Synonymous to: bytes = bytesdoneright or maybe from bytesdoneright import bytes :) -Barry ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Review needed for patch for issue #12067
Hello, a patch for issue #12067 (targeting Py 3.5) is available since a few weeks and is ready for review. From my perspective, it is ready for commit. Could the community please review the patch? https://bugs.python.org/issue12067 Thanks, Andy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
[Moderately off-topic] On Sun, Aug 17, 2014 at 3:39 AM, Steven D'Aprano wrote: > I used to refer to Python 4000 as the hypothetical compatibility break > version. Now I refer to Python 5000. > I personally think it should be Python 500, or Py5M. When we come to create the mercurial branch, that should of course, following tradition, be called p5ym. -- Mark ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
Le 18/08/2014 13:22, Mark Dickinson a écrit : [Moderately off-topic] On Sun, Aug 17, 2014 at 3:39 AM, Steven D'Aprano mailto:[email protected]>> wrote: I used to refer to Python 4000 as the hypothetical compatibility break version. Now I refer to Python 5000. I personally think it should be Python 500, or Py5M. When we come to create the mercurial branch, that should of course, following tradition, be called p5ym. I would suggest "NaV", for "not-a-version". It would compare greater than all other version numbers (in the spirit of Numpy's "not-a-time", slightly tweaked). Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: PEP 467: Minor API improvements for bytes & bytearray
On Sun, Aug 17, 2014 at 2:41 PM, Barry Warsaw wrote: > I think the biggest API "problem" is that default iteration returns > integers > instead of bytes. That's a real pain. > what is really needed for this NOT to be a pain is a byte scalar. numpy has a scalar type for every type it supports -- this is a GOOD THING (tm): In [53]: a = np.array((3,4,5), dtype=np.uint8) In [54]: a Out[54]: array([3, 4, 5], dtype=uint8) In [55]: a[1] Out[55]: 4 In [56]: type(a[1]) Out[56]: numpy.uint8 In [57]: a[1].shape Out[57]: () The lack of a character type is a major source of "type errors" in python (the whole list of strings vs a single string problem -- both return a sequence when you index into them or iterate over them) Anyway, the character ship has long since sailed, but maybe a byte scalar would be a good idea? And FWIW, I think the proposal does make for a better, cleaner API. Whether that's worth the deprecation is not clear to me, though as someone whose been on the verge of making the leap to 3.* for ages, this isn't going to make any difference. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected] ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: PEP 467: Minor API improvements for bytes & bytearray
On 8/18/2014 12:04 PM, Chris Barker wrote: On Sun, Aug 17, 2014 at 2:41 PM, Barry Warsaw mailto:[email protected]>> wrote: I think the biggest API "problem" is that default iteration returns integers instead of bytes. That's a real pain. what is really needed for this NOT to be a pain is a byte scalar. The byte scalar is an int in range(256). Bytes is an array of such. numpy has a scalar type for every type it supports -- this is a GOOD THING (tm): In [53]: a = np.array((3,4,5), dtype=np.uint8) In [54]: a Out[54]: array([3, 4, 5], dtype=uint8) In [55]: a[1] Out[55]: 4 In [56]: type(a[1]) Out[56]: numpy.uint8 In [57]: a[1].shape Out[57]: () The lack of a character type is a major source of "type errors" in python (the whole list of strings vs a single string problem -- both return a sequence when you index into them or iterate over them) This is exactly what iterbytes would do -- yields bytes of size 1. Anyway, the character ship has long since sailed, but maybe a byte scalar would be a good idea? And FWIW, I think the proposal does make for a better, cleaner API. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] https:bugs.python.org -- Untrusted Connection (Firefox)
Firefox does not want to connect to https:bugs.python.org. Plain bugs.python.org works fine. Has the certificate expired? -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] https:bugs.python.org -- Untrusted Connection (Firefox)
On Mon, Aug 18, 2014 at 04:12:22PM -0400, Terry Reedy wrote: > Firefox does not want to connect to https:bugs.python.org. Works for me (FF 31). Oleg. -- Oleg Broytmanhttp://phdru.name/[email protected] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] https:bugs.python.org -- Untrusted Connection (Firefox)
It uses a CACert certificate, which your system probably doesn't trust. On Mon, Aug 18, 2014, at 13:12, Terry Reedy wrote: > Firefox does not want to connect to https:bugs.python.org. Plain > bugs.python.org works fine. Has the certificate expired? > > -- > Terry Jan Reedy > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/benjamin%40python.org ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] https:bugs.python.org -- Untrusted Connection (Firefox)
On Mon, Aug 18, 2014 at 3:22 PM, Benjamin Peterson wrote: > It uses a CACert certificate, which your system probably doesn't trust. > > On Mon, Aug 18, 2014, at 13:12, Terry Reedy wrote: >> Firefox does not want to connect to https:bugs.python.org. Plain >> bugs.python.org works fine. Has the certificate expired? >> >> -- >> Terry Jan Reedy >> >> ___ >> Python-Dev mailing list >> [email protected] >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/benjamin%40python.org Benjamin that looks accurate. I see the same thing as Terry (on Firefox 31) and the reason is: bugs.python.org uses an invalid security certificate. The certificate is not trusted because no issuer chain was provided. (Error code: sec_error_unknown_issuer) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] https:bugs.python.org -- Untrusted Connection (Firefox)
On Mon, Aug 18, 2014 at 03:26:48PM -0500, Ian Cordasco wrote: > On Mon, Aug 18, 2014 at 3:22 PM, Benjamin Peterson > wrote: > > It uses a CACert certificate, which your system probably doesn't trust. > > > > On Mon, Aug 18, 2014, at 13:12, Terry Reedy wrote: > >> Firefox does not want to connect to https:bugs.python.org. Plain > >> bugs.python.org works fine. Has the certificate expired? > > Benjamin that looks accurate. I see the same thing as Terry (on > Firefox 31) and the reason is: > > bugs.python.org uses an invalid security certificate. The certificate > is not trusted because no issuer chain was provided. (Error code: > sec_error_unknown_issuer) Aha, I see now -- the signing certificate is CAcert, which I've installed manually. Oleg. -- Oleg Broytmanhttp://phdru.name/[email protected] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.walk() is going to be *fast* with scandir
Indeed - my suggestion is applicable to people using the library -Rob On 10 Aug 2014 18:21, "Larry Hastings" wrote: > On 08/09/2014 10:40 PM, Robert Collins wrote: > > A small tip from my bzr days - cd into the directory before scanning it > > > I doubt that's permissible for a library function like os.scandir(). > > > */arry* > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/robertc%40robertcollins.net > > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: PEP 467: Minor API improvements for bytes & bytearray
On Mon, Aug 18, 2014 at 1:06 PM, Terry Reedy wrote: > The byte scalar is an int in range(256). Bytes is an array of such. > then why the complaint about iterating over bytes producing ints? Ye,s a byte owuld be pretty much teh same as an int, but it would have restrictions - useful ones. numpy has a scalar type for every type it supports -- this is a GOOD >> THING (tm): >> In [56]: type(a[1]) >> Out[56]: numpy.uint8 >> >> In [57]: a[1].shape >> Out[57]: () >> >> >> The lack of a character type is a major source of "type errors" in >> python (the whole list of strings vs a single string problem -- both >> return a sequence when you index into them or iterate over them) >> > > This is exactly what iterbytes would do -- yields bytes of size 1. as I understand it, it would yield a bytes object of length one -- that is a sequence that _happens_ to only have one item in it -- not the same thing. Note above. In numpy, when you index out of a 1-d array you get a scalar -- with shape == () -- not a 1-d array of length 1. And this is useful, as it provide s clear termination point when you drill down through multiple dimensions. I often wish I could do that with nested lists with strings at the bottom. [1,2,3] is a sequence of numbers "this" is a sequence of characters -- oops, not it's not, it's a sequence of sequences of sequences of ... I think it would be cleaner if bytes was a sequence of a scalar byte object. This is a bigger deal for numpy, what with its n-dimensional arrays and many reducing operations, but the same principles apply. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected] ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
