Re: [Python-ideas] Looking for input to help with the pip situation

On Tue, Nov 14, 2017 at 6:38 PM, Chris Angelico wrote: > On Tue, Nov 14, 2017 at 5:47 PM, Michel Desmoulin > wrote: >> Proposal B: >> >> >> Make pip and venv part of the standard and request debian that they >> provide it. >> >> Pros:

Re: [Python-ideas] Looking for input to help with the pip situation

On Tue, Nov 14, 2017 at 5:47 PM, Michel Desmoulin wrote: > Proposal B: > > > Make pip and venv part of the standard and request debian that they > provide it. > > Pros: straight forward. > > Cons: holy war in the making. If this would really cause such

Re: [Python-ideas] Looking for input to help with the pip situation

General summary so far ### This debate has been very civil so far and quite productive, so thanks to everyone involved. Several issues and solution proposals have been mentioned, so I will make a summary here. Issue 1: running Python is a different command different OS when

Re: [Python-ideas] Looking for input to help with the pip situation

Le 12/11/2017 à 19:02, Stephan Houben a écrit : > > 2017-11-12 13:20 GMT+01:00 Paul Moore >: > > On 12 November 2017 at 06:19, Michel Desmoulin > > wrote: > > > Well,

Re: [Python-ideas] Looking for input to help with the pip situation

On 14 November 2017 at 13:08, Nathaniel Smith wrote: > On Nov 13, 2017 6:47 PM, "Nick Coghlan" wrote: > > On 14 November 2017 at 11:51, Nathaniel Smith wrote: > > What if instead of installing a standard entry point, the pip > > executable

Re: [Python-ideas] Looking for input to help with the pip situation

On Nov 13, 2017 6:47 PM, "Nick Coghlan" wrote: On 14 November 2017 at 11:51, Nathaniel Smith wrote: > What if instead of installing a standard entry point, the pip > executable was installed as > > #!/bin/sh > exec python -m pip "$@" > > on Unix-likes It

Re: [Python-ideas] PEP 560 (second post)

On 14 November 2017 at 09:41, Guido van Rossum wrote: > On Fri, Nov 10, 2017 at 8:54 AM, Ivan Levkivskyi > wrote: >> >> On 10 November 2017 at 17:43, Guido van Rossum wrote: >>> >>> There seem to be some action items from this thread

Re: [Python-ideas] Looking for input to help with the pip situation

On 14 November 2017 at 11:51, Nathaniel Smith wrote: > What if instead of installing a standard entry point, the pip > executable was installed as > > #!/bin/sh > exec python -m pip "$@" > > on Unix-likes It would technically be enough to make the shebang line `#!/usr/bin/env

Re: [Python-ideas] A proliferation of (un-)Pythonically programmatic pragmas

Gregory P. Smith wrote: > fwiw, we're going to need the tool name in any pragma anyways so the > existing thing that should be common is: > > # tool-name: meaningfultoken > > It seems like the only convention that makes sense to me. One of the things that bother me about end-line comments is

Re: [Python-ideas] venv *is* provided in the standard Python install on Debian/Ubuntu

On Mon, Nov 13, 2017, 00:01 Stephan Houben, wrote: > Hi all, > > Related to this text on https://docs.python.org/3/library/venv.html : > > > > Note > The pyvenv script has been deprecated as of Python 3.6 in favor of > using python3 -m venv to help prevent

Re: [Python-ideas] A proliferation of (un-)Pythonically programmatic pragmas

On 11/13/17 2:10 PM, Barry Warsaw wrote: I love many of the ancillary tools that help improve the quality of my Python code, including flake8, coverage, and mypy. Each of these usually produces some great diagnostics, but none of them are perfect, so they also produce false positives that have

Re: [Python-ideas] A proliferation of (un-)Pythonically programmatic pragmas

On Mon, Nov 13, 2017, 15:55 Steven D'Aprano, wrote: > On Mon, Nov 13, 2017 at 06:37:05PM -0500, Barry Warsaw wrote: > > Brett Cannon wrote: > > > > > And possibly the easiest way to reach them is on the pyqa-dev mailing > list. > > > > What's that? I can't find it on

Re: [Python-ideas] A proliferation of (un-)Pythonically programmatic pragmas

On 11/13/2017 4:58 PM, Paul Moore wrote: On 13 November 2017 at 20:43, MRAB such as: 1. There can be multiple pragmas in a comment, separated by semicolons: if you don't recognise it, skip past the semicolon. 2. A pragma can be prefixed with the name of the tool, e.g. "# flake8.noqa: F401":

Re: [Python-ideas] A proliferation of (un-)Pythonically programmatic pragmas

On Mon, Nov 13, 2017 at 06:37:05PM -0500, Barry Warsaw wrote: > Brett Cannon wrote: > > > And possibly the easiest way to reach them is on the pyqa-dev mailing list. > > What's that? I can't find it on python.org, Gmane, or the Googles. Brett may have meant

Re: [Python-ideas] PEP 560 (second post)

On Fri, Nov 10, 2017 at 8:54 AM, Ivan Levkivskyi wrote: > On 10 November 2017 at 17:43, Guido van Rossum wrote: > >> There seem to be some action items from this thread that I haven't seen >> reflected in the PEP source code yet. >> [...snip...] >> Then

Re: [Python-ideas] A proliferation of (un-)Pythonically programmatic pragmas

Brett Cannon wrote: > And possibly the easiest way to reach them is on the pyqa-dev mailing list. What's that? I can't find it on python.org, Gmane, or the Googles. -Barry ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] A proliferation of (un-)Pythonically programmatic pragmas

fwiw, we're going to need the tool name in any pragma anyways so the existing thing that should be common is: # tool-name: meaningfultoken It seems like the only convention that makes sense to me. When I saw your flake8 example of "# noqa: F401" I wanted to rip my eyes out. Because it didn't

Re: [Python-ideas] A proliferation of (un-)Pythonically programmatic pragmas

On 2017-11-13 19:10, Barry Warsaw wrote: I love many of the ancillary tools that help improve the quality of my Python code, including flake8, coverage, and mypy. Each of these usually produces some great diagnostics, but none of them are perfect, so they also produce false positives that have

Re: [Python-ideas] Looking for input to help with the pip situation

Hi Chris, +1 to all three of these proposals! Stephan 2017-11-13 19:57 GMT+01:00 Chris Barker : > This has gotten to be a big thread, and it's a pretty intractable problem, > but I think there are a few fairly small things that could be done to at > least make it a bit

Re: [Python-ideas] Complete typing.Union with the rest of set-like functions

Intersection has already been proposed, see https://github.com/python/typing/issues/213 But it is not yet implemented. You can show your use cases on the typing issue tracker, maybe they can be covered by Intersection (which will be most probably added at some point). -- Ivan On 13 November

Re: [Python-ideas] A proliferation of (un-)Pythonically programmatic pragmas

Off the top of my head there's: - Offer a standard pragma-parser in the standard library's ast module that allows multiple pragmas per line. This is kind of the reason there's the weird ast vs typed_ast discrepancy right now, too. - Create a custom pragma syntax that doesn't use comments. Maybe

[Python-ideas] Complete typing.Union with the rest of set-like functions

I needed to declare a type that would mean "Any but None" and didn't find how. Current implementation allows to expand set of allowed types, not narrow it. Perhaps typing needs the rest of set operators in addition to Union? Best Regards, Ilya Kulakov

[Python-ideas] A proliferation of (un-)Pythonically programmatic pragmas

I love many of the ancillary tools that help improve the quality of my Python code, including flake8, coverage, and mypy. Each of these usually produces some great diagnostics, but none of them are perfect, so they also produce false positives that have to be suppressed. Each of these tools

Re: [Python-ideas] Looking for input to help with the pip situation

This has gotten to be a big thread, and it's a pretty intractable problem, but I think there are a few fairly small things that could be done to at least make it a bit easier: 1) Add python2.exe and python3.exe files to the Windows installers -- am I insane or did Windows used to have that? I

Re: [Python-ideas] Looking for input to help with the pip situation

On Sun, Nov 12, 2017 at 3:18 PM, Nick Coghlan wrote: > P.S. As a user, it's also genuinely irritating to have to always type > the "python -m " prefix when inside an active virtual environment, as > in that case, there isn't any ambiguity about which environment pip > should

Re: [Python-ideas] venv *is* provided in the standard Python install on Debian/Ubuntu

On 13 November 2017 at 20:43, Antoine Pitrou wrote: > On Mon, 13 Nov 2017 11:17:54 +0100 > Petr Viktorin wrote: >> > >> > Wow. I had forgotten Debian could be such a user-hostile >> > distribution. I'm not sure what the reason would be to use it as a >>

Re: [Python-ideas] venv *is* provided in the standard Python install on Debian/Ubuntu

On Mon, 13 Nov 2017 11:17:54 +0100 Petr Viktorin wrote: > > > > Wow. I had forgotten Debian could be such a user-hostile > > distribution. I'm not sure what the reason would be to use it as a > > basis for a training course in Python programming, then (other than the > >

Re: [Python-ideas] venv *is* provided in the standard Python install on Debian/Ubuntu

On 11/13/2017 11:05 AM, Antoine Pitrou wrote: On Mon, 13 Nov 2017 12:32:06 +1000 Nick Coghlan wrote: On 13 November 2017 at 04:38, Antoine Pitrou wrote: On Sun, 12 Nov 2017 12:20:45 + Paul Moore wrote: Well, not exactly.

Re: [Python-ideas] venv *is* provided in the standard Python install on Debian/Ubuntu

On Mon, 13 Nov 2017 12:32:06 +1000 Nick Coghlan wrote: > On 13 November 2017 at 04:38, Antoine Pitrou wrote: > > On Sun, 12 Nov 2017 12:20:45 + > > Paul Moore wrote: > >> > >> > Well, not exactly. Do you do python -m venv, or

Re: [Python-ideas] venv *is* provided in the standard Python install on Debian/Ubuntu

On 13 November 2017 at 17:46, Stephan Houben wrote: > 2017-11-13 3:32 GMT+01:00 Nick Coghlan : >> So technically it's ensurepip that's broken by default, but that >> translates to venv also being broken by default. >> >> I haven't worked out what the

Re: [Python-ideas] venv *is* provided in the standard Python install on Debian/Ubuntu

Hi all, Related to this text on https://docs.python.org/3/library/venv.html : Note The pyvenv script has been deprecated as of Python 3.6 in favor of using python3 -m venv to help prevent any potential confusion as to which Python interpreter a virtual environment will be