Re: [Python-Dev] Yearly PyPI breakage
> > (Is cdecimal substantially different from the _decimal added in 3.5?) > AFAICT, they are unrelated codebases that do about the same thing with the same amount of performance, with the main exception that _decimal in 3.5 does not require one to change their import (or to compile the package themselves.) ___ 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
Re: [Python-Dev] Yearly PyPI breakage
Are you for real? I honestly do not understand your hostility. You posted a mean-spirited complaint about a policy that is nearly exactly two years old, to the wrong list, and call out the people calmly trying to explain what happened and why, and how you can mitigate it for your own work and organization. What do you intend to accomplish? * PyPI is no longer and index, it is a repository * The decision to disable the index-only features of PyPI were made 2 years ago, including pep438 - plenty of time to make alternate arrangements. * The tooling for hosting your own repository is available, should you actually need to host the files outside of PyPI * The tooling exists to use other indexes * The tooling exists to host your own index that serves your own packages (that you develop or third party packages that you package for your own use), that defaults to PyPI for packages not in your own repository I understand that you are upset that a feature you used was removed; posting with hostility to a list of people who do not even have control over the repository is not a legitimate way to solve your problems. > -Original Message- > From: Python-Dev [mailto:python-dev-bounces+tritium- > list=sdamon@python.org] On Behalf Of Stefan Krah > Sent: Wednesday, May 04, 2016 00:15 > To: python-dev@python.org > Subject: Re: [Python-Dev] Yearly PyPI breakage > > > > [cut overlong post] > > Glyph, > > nice sneaky way to try to divert from the original issue. Your whole post > is invalidated by the simple fact that the URL was protected by a hash > (which I repeatedly asked to be upgraded to sha256). > > This was the official scheme promoted by PEP-438, which you should know. > But of course your actual intention here is character assassination, > pretending to "rescue" cdecimal and trying to divert from the fact that > the transition to PEP 470 was handled suboptimally. > > > The very reason for this thread is that the security was silently disabled > WITHOUT me getting a notification. What is on PyPI *now* is not what I > configured! > > > Please believe me when I say I do not mean the following to be insulting -- > people who have done *actual* cryptography to varying degrees often tend > to focus on the important parts and aren't impressed by regurgitating > catch phrases like SSL and man-in-the-middle: > > http://cr.yp.to/ecdh.html > > > The amount of security "experts" in the Python community that pontificate > on any occasion is pretty annoying. What do you think djb thinks of Twisted? > > > > If anyone wants package-index access to this name to upload Windows or > manylinux wheels just let me know; however, as this is just a proof of > concept, I do not intend to maintain it long-term. > > That apparently all you can do: Move bits from place A to place B and not > care how long it took to produce them. > > You are a real hero. > > > > Stefan Krah > > > > > _______ > 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/tritium- > list%40sdamon.com ___ 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
Re: [Python-Dev] C99
> -Original Message- > From: Python-Dev [mailto:python-dev-bounces+tritium- > list=sdamon@python.org] On Behalf Of Sturla Molden > Sent: Sunday, June 5, 2016 10:29 PM > To: python-dev@python.org > Subject: Re: [Python-Dev] C99 > > Guido van Rossum wrote: > > > I'm talking about 3rd party extensions. Those may require source > > compatibility with older Python versions. All I'm asking for is to not > > require source-level use of C99 features. > > This of course removes a lot of its usefulness. E.g. macros cannot be > replaced by inline functions, as header files must still be plain C89. > > > Sturla Molden > I share Guido's priority there - source compatibility is more important than smoothing a few of C's rough edges. Maybe the next breaking change release this should be considered (python 4000... python 5000?) ___ 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
Re: [Python-Dev] C99
Doesn't Cygwin build against the posix abstraction layer? Wouldn't a python built as such operate as though it was on a unix of some sort? It has been quite a while since I messed with Cygwin - if it hasn't changed, it's not really an option, especially when we have native windows builds now. It would be too much of a downgrade in experience and performance. > -Original Message- > From: Python-Dev [mailto:python-dev-bounces+tritium- > list=sdamon@python.org] On Behalf Of Sturla Molden > Sent: Tuesday, June 7, 2016 3:37 PM > To: python-dev@python.org > Subject: Re: [Python-Dev] C99 > > Victor Stinner wrote: > > > Is it worth to support a compiler that in 2016 doesn't support the C > > standard released in 1999, 17 years ago? > > MSVC only supports C99 when its needed for C++11 or some MS extension > to C. > > Is it worth supporting MSVC? If not, we have Intel C, Clang and Cygwin GCC > are the viable options we have on Windows (and perhaps Embarcadero, but I > haven't used C++ builder for a very long time). Even MinGW does not fully > support C99, because it depends on Microsoft's CRT. If we think MSVC and > MinGW are worth supporting, we cannot just use C99 indiscriminantly. > > ___ > 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/tritium- > list%40sdamon.com ___ 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
Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview
> -Original Message- > From: Python-Dev [mailto:python-dev-bounces+tritium- > list=sdamon@python.org] On Behalf Of Nick Coghlan > Sent: Tuesday, June 7, 2016 5:40 PM > To: Barry Warsaw > Cc: python-dev@python.org > Subject: Re: [Python-Dev] PEP 467: Minor API improvements to bytes, > bytearray, and memoryview > > On 7 June 2016 at 14:31, Barry Warsaw wrote: > > On Jun 07, 2016, at 01:28 PM, Ethan Furman wrote: > > > >>* Add ``bytes.iterbytes``, ``bytearray.iterbytes`` and > >> ``memoryview.iterbytes`` alternative iterators > > > > +1 but I want to go just a little farther. > > > > We can't change bytes.__getitem__ but we can add another method that > returns > > single byte objects? I think it's still a bit of a pain to extract single > > bytes even with .iterbytes(). > > > > Maybe .iterbytes can take a single index argument (blech) or add a method > like > > .byte_at(i). I'll let you bikeshed on the name. > > Perhaps: > > data.getbyte(i) > data.iterbytes() data.getbyte(index_or_slice_object) ? while it might not be... ideal... to create a sliceable live view object, we can have a method that accepts a slice, even if we have to create it manually (or at least make it convenient for those who wish to wrap a bytes object in their own type and blindly pass the first-non-self arg of a custom __getitem__ to the method). > The rationale for "Why not a live view?" is that an iterator is simple > to define and implement, while we know from experience with memoryview > and the various dict views that live views are a minefield for folks > defining new container types. Since this PEP would in some sense > change what it means to implement a full "bytes-like object", it's > worth keeping implementation complexity in mind. > > Cheers, > Nick. > > -- > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > ___ > 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/tritium- > list%40sdamon.com ___ 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
Re: [Python-Dev] PEP 467: Minor API improvements to bytes, bytearray, and memoryview
Ignore that message. I hit send before brain and hands were fully in sync. > -Original Message- > From: tritium-l...@sdamon.com [mailto:tritium-l...@sdamon.com] > Sent: Tuesday, June 7, 2016 5:51 PM > To: 'Nick Coghlan' ; 'Barry Warsaw' > > Cc: python-dev@python.org > Subject: RE: [Python-Dev] PEP 467: Minor API improvements to bytes, > bytearray, and memoryview > > > > > -Original Message----- > > From: Python-Dev [mailto:python-dev-bounces+tritium- > > list=sdamon@python.org] On Behalf Of Nick Coghlan > > Sent: Tuesday, June 7, 2016 5:40 PM > > To: Barry Warsaw > > Cc: python-dev@python.org > > Subject: Re: [Python-Dev] PEP 467: Minor API improvements to bytes, > > bytearray, and memoryview > > > > On 7 June 2016 at 14:31, Barry Warsaw wrote: > > > On Jun 07, 2016, at 01:28 PM, Ethan Furman wrote: > > > > > >>* Add ``bytes.iterbytes``, ``bytearray.iterbytes`` and > > >> ``memoryview.iterbytes`` alternative iterators > > > > > > +1 but I want to go just a little farther. > > > > > > We can't change bytes.__getitem__ but we can add another method > that > > returns > > > single byte objects? I think it's still a bit of a pain to extract > single > > > bytes even with .iterbytes(). > > > > > > Maybe .iterbytes can take a single index argument (blech) or add a > method > > like > > > .byte_at(i). I'll let you bikeshed on the name. > > > > Perhaps: > > > > data.getbyte(i) > > data.iterbytes() > > data.getbyte(index_or_slice_object) ? > > while it might not be... ideal... to create a sliceable live view object, we > can have a method that accepts a slice, even if we have to create it > manually (or at least make it convenient for those who wish to wrap a bytes > object in their own type and blindly pass the first-non-self arg of a custom > __getitem__ to the method). > > > The rationale for "Why not a live view?" is that an iterator is simple > > to define and implement, while we know from experience with > memoryview > > and the various dict views that live views are a minefield for folks > > defining new container types. Since this PEP would in some sense > > change what it means to implement a full "bytes-like object", it's > > worth keeping implementation complexity in mind. > > > > Cheers, > > Nick. > > > > -- > > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > > ___ > > 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/tritium- > > list%40sdamon.com ___ 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
Re: [Python-Dev] File system path encoding on Windows
> -Original Message- > From: Python-Dev [mailto:python-dev-bounces+tritium- > list=sdamon@python.org] On Behalf Of Steve Dower > Sent: Wednesday, August 24, 2016 11:44 AM > To: Stephen J. Turnbull > Cc: Nick Coghlan ; Python Dev d...@python.org> > Subject: Re: [Python-Dev] File system path encoding on Windows > > On 23Aug2016 2150, Stephen J. Turnbull wrote: > > Steve Dower writes: > > > > > * Stephen sees "no reason not to change locale.getpreferredencoding()" > > > (default encoding for open()) at the same time with the same switches, > > > while I'm not quite as confident. Do users generally specify an encoding > > > these days? I know I always put utf-8 there. > > > > I was insufficiently specific. "No reason not to" depends on separate > > switches for file system encoding and preferred encoding. That makes > > things somewhat more complicated for implementation, and significantly > > so for users. > > Yes, it does, but it's about the only possible migration path. > > I know Nick and Victor like the idea of a -X flag (or a direct -utf8 > flag), but I prefer more specific environment variables: > > - PYTHONWINDOWSLEGACYSTDIO (for the console changes) > - PYTHONWINDOWSLEGACYPATHENCODING (assuming > getfilesystemencoding() is utf8) > - PYTHONWINDOWSLEGACYLOCALEENCODING (assuming > getpreferredencoding() is > utf8) Once you get to var lengths like that, arcane single character flags start looking preferable. How about "PYTHONWINLEGACY" to just turn it all on or off. If the code breaks on one thing, it obviously isn't written to use the other two, so might as well shut them all off. > I'm open to dropping "WINDOWS" from these if others don't think it's > necessary. Swap "LEGACY" for "UNICODE" if we just offer the option to > upgrade now rather than changing the default. > > (I could also see the possibility of PYTHONWINDOWSSTRICT* options to use > the default encoding but raise if decoding bytes fails - mbcs:strict > rather than mbcs:replace. For utf-8 mode I'd want to use surrogatepass > throughout, so it will always raise on invalid encoding, but there will > be far fewer occurrences than for mbcs.) > > I'll transform my earlier post into a PEP (or probably three PEPs - one > for each change), since it seems like the paper trail is going to be > more valuable than discussing it now. Without an actual build to test > it's pretty hard to evaluate the impact. > > Cheers, > Steve > > ___ > 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/tritium- > list%40sdamon.com ___ 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
Re: [Python-Dev] [Distutils] pythonhosted.org upload no longer works
> -Original Message- > From: Distutils-SIG [mailto:distutils-sig-bounces+tritium- > list=sdamon@python.org] On Behalf Of Guido van Rossum > Sent: Monday, October 10, 2016 12:27 PM > To: Donald Stufft > Cc: Distutils ; Giampaolo Rodola' > ; python-dev > Subject: Re: [Distutils] [Python-Dev] pythonhosted.org upload no longer > works > > Honestly I like readthedocs a lot, and I actually *don't* like docs > that look too much like the standard Python docs -- it should be clear > to readers (subliminally, through page style, not just be parsing the > URL) that they're reading third party docs. > That’s quite tangential to pythonhosted.org hosting documentation... But that is a consequence of the theme used by docs.python.org/2/ using the default sphinx theme. That problem was already solved for python3 docs - they don’t use the default theme. I really don’t see how this is related at all to the uploading of docs to pythonhosted.org. ___ 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
Re: [Python-Dev] Python FTP Injections Allow for Firewall Bypass (oss-security advisory)
Ask the infrastructure team for a tracker instance. That would probably be more fruitful of an outlet than in the thread of this one issue. (I'm not trying to be flippant, I think a private issue tracker for vulnerabilities is a really good idea, I just don't think that bemoaning the lack of one in a thread about an FTP issue is likely to get much done.) > -Original Message- > From: Python-Dev [mailto:python-dev-bounces+tritium- > list=sdamon@python.org] On Behalf Of Antoine Pitrou > Sent: Friday, February 24, 2017 5:02 AM > To: python-dev@python.org > Subject: Re: [Python-Dev] Python FTP Injections Allow for Firewall Bypass > (oss-security advisory) > > On Thu, 23 Feb 2017 23:51:45 -0800 > Benjamin Peterson wrote: > > > > Like all CPython developers, the Python security team are all > > volunteers. That combined with the fact that dealing with security > > issues is one of the least fun programming tasks means issues are > > sometimes dropped. > > > > Perhaps some organization with a stake Python security would like to > > financially support Python security team members. > > > > As for this, particular issue, we should determine if there's a tracker > > issue yet and continue discussion there. > > Just for the record, I find the mailing-list scheme used by PSRT quite > difficult to deal with. For many people it's easy to lose track of > e-mails received more than one week ago, so the necessary followup to > security issues received by e-mail suffers. > > It's a bit sad that regular issues benefit from a full-fledged > Roundup instance to allow for easy tracking of open issues (including > comments and proposed fixes), but security issues are restricted to such > a primitive communication setup which makes it so difficult to get work > done. > > AFAIK, other projects have full-fledged private bug trackers for their > security issues (or access-restricted sections in the main bug tracker, > where the software supports it). > > Regards > > Antoine. > > > _______ > 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/tritium- > list%40sdamon.com ___ 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
Re: [Python-Dev] Translated Python documentation
My gut splits the difference on this issue; I suggest an approach to meet in the middle – a version of the docs written in simplified English (Not quite Up Goer Five simplified, but simplified.) It has the practical benefit of having more eyes to look at the docs to check for accuracy, it targets both English learners and children, and is something the current contributors to the documentation can do. For any language you want to support other than English, you need a translator who is A: a python expert, B: fluent in English, and C: fluent in the target language. …And then you need another one to check what was written. These are practical problems. There are extant services to support this, they are expensive in either money or time, and the docs produced usually lag behind English quite a bit. From: Python-Dev [mailto:python-dev-bounces+tritium-list=sdamon@python.org] On Behalf Of Nick Coghlan Sent: Friday, February 24, 2017 5:02 AM To: Victor Stinner Cc: Antoine Pitrou ; Python Dev Subject: Re: [Python-Dev] Translated Python documentation On 23 February 2017 at 02:15, Victor Stinner mailto:victor.stin...@gmail.com> > wrote: 2017-02-22 16:40 GMT+01:00 Antoine Pitrou mailto:solip...@pitrou.net> >: > As long as you are asking for "moral" support and not actually > vouching for the accuracy of third-party translations, then +1 from me. The main complain about these translations is the accuracy. My bet is that making these translations "official" and more visible (at docs.python.org <http://docs.python.org> ) would make them more popular, and so indirectly help to recruit new contributors. Slowly, the number of translated pages should increase, but the overall translation quality should also increase. That's how free software are developed, no? :-) +1 from me for these reasons, and those Facundo gives: we want folks to be able to learn at least the basics of Python *before* they learn English (even if learning English remains a pre-requisite for tapping into the full capabilities of both the language and its ecosystem). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com <mailto:ncogh...@gmail.com>| Brisbane, Australia ___ 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
Re: [Python-Dev] Set program name through exec -a or environment variable
https://pypi.python.org/pypi/setproctitle From: Python-Dev [mailto:python-dev-bounces+tritium-list=sdamon@python.org] On Behalf Of Freddy Rietdijk Sent: Saturday, March 18, 2017 9:15 AM To: Python-Dev Subject: [Python-Dev] Set program name through exec -a or environment variable Hi, I would like to know if you're open to supporting `exec -a` or an environment variable for setting `argv[0]`, and have some pointers as to where that should be implemented. On Nixpkgs we typically use wrappers to set environment variables like PATH or PYTHONPATH for individual programs. Consider a program named `prog`. We move the original program `prog` to `.prog-wrapped` and then create a wrapper `prog` that does `exec -a prog .prog-wrapped`. Unfortunately `exec -a` does not work with Python. The process is still named `.prog-wrapped` (although that's not really a problem) but worse, `sys.argv[0]` is also `.prog-wrapped`. Currently we inject some code in programs that sets `sys.argv=[0] = "prog" but this is fragile and I would prefer to get rid of this. Kind regards, Frederik ___ 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
