Re: [Python-Dev] What is the rationale behind source only releases?

What does “no release at all” mean? If it’s not released, how would people use it? —Chris On Tue, May 15, 2018 at 9:36 PM Alex Walters wrote: > In the spirit of learning why there is a fence across the road before I > tear > it down out of ignorance [1], I'd like to

Re: [Python-Dev] What is the rationale behind source only releases?

> On May 16, 2018, at 1:06 AM, Ben Finney wrote: > >> >> I'd like to know the rationale behind source only releases of cpython. > > Software freedom entails the freedom to modify and build the software. > For that, one needs the source form of the software. > >

Re: [Python-Dev] What is the rationale behind source only releases?

On Wed, May 16, 2018 at 3:06 PM, Ben Finney wrote: > "Alex Walters" writes: > >> I'd like to know the rationale behind source only releases of cpython. > > Software freedom entails the freedom to modify and build the software. > For that, one

Re: [Python-Dev] What is the rationale behind source only releases?

"Alex Walters" writes: > I'd like to know the rationale behind source only releases of cpython. Software freedom entails the freedom to modify and build the software. For that, one needs the source form of the software. Portable software should be feasible to build

[Python-Dev] What is the rationale behind source only releases?

In the spirit of learning why there is a fence across the road before I tear it down out of ignorance [1], I'd like to know the rationale behind source only releases of cpython. I have an opinion on their utility and perhaps an idea about changing them, but I'd like to know why they are done (as

Re: [Python-Dev] Looking for examples: proof that a list comp is a function

[ Tim, about the most version of the docs at https://docs.python.org/dev/reference/expressions.html#displays-for-lists-sets-and-dictionaries ] >> I say "pretty much" because, for whatever reason(s), it seems to be >> trying hard _not_ to use the word "function". But I can't guess what >>

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 2018-05-15 18:36, Petr Viktorin wrote: Naturally, large-scale changes have less of a chance there. Does it really matter that much how large the change is? I think you are focusing too much on the change instead of the end result. As I said in my previous post, I could certainly make

[Python-Dev] Making Tcl/Tk more suitable for embedding (was: [issue33479] Document tkinter and threads)

Subj is off topic for the ticket, so I guess this discussion is better continued here. On 15.05.2018 18:20, Mark Roseman wrote: Mark Roseman added the comment: Hi Ivan, thanks for your detailed response. The approach you're suggesting ("Since the sole offender is their

Re: [Python-Dev] [Python-checkins] bpo-33038: Fix gzip.GzipFile for file objects with a non-string name attribute. (GH-6095)

Sorry about approving this message (I'm a python-dev list moderator)! There will be a few more like it. Looking closer, it appears to be another variation of pure-nuisance spam that's been flooding all sorts of python.org lists. You've been spared many hundreds of those here, but since this one

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 2018-05-15 18:36, Petr Viktorin wrote: What is your ultimate use case? (I'll just answer this one question now and reply to the more technical comments in another thread) My ultimate use case is being able to implement functions and methods which are (A) equally fast as the existing

Re: [Python-Dev] [Python-checkins] bpo-33038: Fix gzip.GzipFile for file objects with a non-string name attribute. (GH-6095)

From: Serhiy Storchaka To: python-check...@python.org Sent: Wednesday, 9 May 2018, 10:14 Subject: [Python-checkins] bpo-33038: Fix gzip.GzipFile for file objects with a non-string name attribute. (GH-6095)

Re: [Python-Dev] [Python-checkins] bpo-33038: Fix gzip.GzipFile for file objects with a non-string name attribute. (GH-6095)

From: Serhiy Storchaka To: python-check...@python.org Sent: Wednesday, 9 May 2018, 10:14 Subject: [Python-checkins] bpo-33038: Fix gzip.GzipFile for file objects with a non-string name attribute. (GH-6095)

Re: [Python-Dev] [Python-checkins] bpo-33038: Fix gzip.GzipFile for file objects with a non-string name attribute. (GH-6095)

From: Serhiy Storchaka To: python-check...@python.org Sent: Wednesday, 9 May 2018, 10:14 Subject: [Python-checkins] bpo-33038: Fix gzip.GzipFile for file objects with a non-string name attribute. (GH-6095)

Re: [Python-Dev] Changes to configure.ac, auto-detection and related build issues

I didn't look at your PRs yet, but PR commits are squashed into a single commit. So it's better to have multiple PRs for different changes. Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev

Re: [Python-Dev] Changes to configure.ac, auto-detection and related build issues

On 15 May 2018 at 05:54, Ned Deily wrote: > On May 15, 2018, at 01:58, Eitan Adler wrote: >> On Monday, 14 May 2018, Victor Stinner wrote: >> Hi Eitan, >> >> 2018-05-15 0:01 GMT-04:00 Eitan Adler : >> > I am

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 05/15/18 05:15, Jeroen Demeyer wrote: On 2018-05-14 19:56, Petr Viktorin wrote: It does quite a lot of things, and the changes are all intertwined, which will make it hard to get reviewed and accepted. The problem is that many things *are* already intertwined currently. You cannot deal

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 2018-05-14 22:38, Petr Viktorin wrote: Why are these flags added? I made a minor edit to the PEP to remove those flags: https://github.com/python/peps/pull/649 ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] Changes to configure.ac, auto-detection and related build issues

On May 15, 2018, at 01:58, Eitan Adler wrote: > On Monday, 14 May 2018, Victor Stinner wrote: > Hi Eitan, > > 2018-05-15 0:01 GMT-04:00 Eitan Adler : > > I am working on updating, fixing, or otherwise changing python's > >

[Python-Dev] FINAL WEEK FOR 3.7.0 CHANGES!

This is it! We are down to THE FINAL WEEK for 3.7.0! Please get your feature fixes, bug fixes, and documentation updates in before 2018-05-21 ~23:59 Anywhere on Earth (UTC-12:00). That's about 7 days from now. We will then tag and produce the 3.7.0 release candidate. Our goal continues been to be

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 2018-05-14 19:56, Petr Viktorin wrote: It does quite a lot of things, and the changes are all intertwined, which will make it hard to get reviewed and accepted. The problem is that many things *are* already intertwined currently. You cannot deal with functions without involving methods for

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 2018-05-14 22:38, Petr Viktorin wrote: Why are these flags added? They aren't free – the space of available flags is not infinite. If something (Cython?) needs eight of them, it would be nice to mention the use case, at least as an example. What should Python do with a m_methods entry that

Re: [Python-Dev] Changes to configure.ac, auto-detection and related build issues

On Monday, 14 May 2018, Victor Stinner wrote: > Hi Eitan, > > 2018-05-15 0:01 GMT-04:00 Eitan Adler : > > I am working on updating, fixing, or otherwise changing python's > > configure.ac. This work is complex, (...) > > Is your work public? Is there an