Re: [Python-Dev] Proposing the deprecation of the pyvenv script
Terry Reedy writes: > Am I correct in guessing that on Windows, at least, R and Emacs do *not* > run in Command Prompt? I'm not sure what you mean by that. Of course they do run under Command Prompt, but the limitations of the command window are so severe that almost nobody ever does that, they click on an icon to start. Nevertheless the basic interactions that are always available are command-shell-like (as in IDLE), although there are icon- or menu- driven GUI shells or modes available for each. In Emacs, the basic interface is the "list-packages" command, which brings up a (text) menu of installed and available packages on the ELPA package repository. In R, it's the package.install() function, which I think has a subfeature that will list the packages available from the CRAN package repository (but I always just go to the website). ___ 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] Proposing the deprecation of the pyvenv script
On 19.09.2015 07:24, Stephen J. Turnbull wrote: Barry Warsaw writes: > One thing that came up in a similar discussion is pip, and the > suggested move to `python -m pip`, which makes a lot of sense. > However, *inside* a virtualenv, there's no ambiguity about the > Python version associated with direct `pip` invocation, so it still > makes sense to install that there. And then the poor newbie who's just following orders (eg, in mailman3/src/mailman/docs/INSTALL) will try pip'ing outside of the virtualenv for some reason, and have a WTF experience. I think we should KISS the pip command good-bye. The only question I have: is there a particular reason (not technical one) why there are many pips on my PC? I would imagine 1 pip for the whole OS, that is capable to install packages inside arbitrary venvs AND handles different versions of Python. Best, Sven ___ 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] PEP 498 (interpolated f-string) tweak
While finishing up the implementation of PEP 498, I realized that the
PEP has an error. It says that this code:
f'abc{expr1:spec1}{expr2!r:spec2}def{expr3:!s}ghi'
Is equivalent to:
'abc' + expr1.__format__(spec1) + repr(expr2).__format__(spec2) + 'def'
+ str(expr3).__format__('') + 'ghi'
But that's not correct. The right way to call __format__ is:
type(expr1).__format__(expr1, spec1)
That is, the lookup of __format__ is done on the type, not the instance.
Instead of calling __format__, I've changed the code generator to call
format(expr1, spec1). As an optimization, I might add special opcodes to
deal with this and string concatenation, but that's for another day (if
ever).
I've posted a new version of the code in issue 24965. I'll update the
PEP itself sometime this weekend.
___
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] Proposing the deprecation of the pyvenv script
On 19 September 2015 at 10:12, Sven R. Kunze wrote: > The only question I have: is there a particular reason (not technical one) > why there are many pips on my PC? That's not an unreasonable question, but (IMO) most of the answers are technical, or amount to "why would you think that's wrong". So apologies, I do know this isn't a direct answer to your question. 1. There are a lot of ways in which pip's implementation assumes it's installing modules for the Python installation that is running it. 2. We have no installation process or path management to allow you to install a Python package *outside* of a Python installation and run it with the user's choice of Python. 3. You've got lots of pythons on your PC (otherwise you wouldn't have lots of pips!) so why do you think it's *not* equally reasonable to have lots of pips? 4. The "py" launcher (on Windows) manages your multiple Pythons for you - it can also manage pip if you don't mind using "py -m pip" to invoke pip. You can of course alias this (wrap it in a powershell function, bat file, shell script or whatever) as you choose. So, to directly answer: Because there are technical challenges that no-one has stepped up to solve. I would assume you're thinking of a "single pip" in the same way that the py.exe launcher is a "single python". Assuming so, then the "single pip" solution is "py -m pip" (leveraging py.exe's options for picking which Python to use). I don't know if there's a Unix equivalent to the launcher - if not, then maybe there should be? Paul ___ 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] Proposing the deprecation of the pyvenv script
On 19 September 2015 at 06:49, Terry Reedy wrote: > On 9/19/2015 1:24 AM, Stephen J. Turnbull wrote: >> >> Barry Warsaw writes: >> >> > One thing that came up in a similar discussion is pip, and the >> > suggested move to `python -m pip`, which makes a lot of sense. >> > However, *inside* a virtualenv, there's no ambiguity about the >> > Python version associated with direct `pip` invocation, so it still >> > makes sense to install that there. >> >> And then the poor newbie who's just following orders (eg, in >> mailman3/src/mailman/docs/INSTALL) will try pip'ing outside of >> the virtualenv for some reason, and have a WTF experience. I think we >> should KISS the pip command good-bye. >> >> A somewhat different way I look at it: the OS provides a shell, and >> you invoke aptitude (CLI) or synaptic (from clickety-clickety GUI >> shell) from that OS shell to manage OS packages. By analogy (always >> slippery but this one feels good to me), to manage python packages you >> should be working in the Python "shell". > > > It is somewhat possible to do this by importing pip.main and translating pip > command line calls to main() calls. I reported proof-of-concept experiments > on issue 23551. To be practical, this should be wrapped in a tkinter gui. > Once written, I will add it to the Idle menu. Other gui shells, could and > probably would do the same. I've raised https://github.com/pypa/pip/issues/3121 as a starting point for discussion on how pip could support a high-level Python API (i.e. make pip.main a bit less "you're on your own"). I don't have any plans right now to work on it, but it provides somewhere to centralise any discussion (and of course, if anyone *else* feels like contributing patches, that'd be great too ;-)) Paul ___ 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] My collection of Python 3.5.0 regressions
On 19 Sep 2015 15:40, "Stephen J. Turnbull" wrote: > > Mark Lawrence writes: > > > I agree very strongly with your point here. Raising umpteen issues > > over installation failures when a full release comes out strikes me > > as below the belt when there have been multiple previous releases > > without a squeak. > > Raising issues is always useful and appropriate. It's up to Larry > Hastings to decide whether he personally needs to do more work. > > I suspect he probably will, though. I knew these changes were risky > on the lead time given, even though I don't do Windows, and I'm not a > core Python developer. I would hope that Steve Dower and Larry were > at least as well aware of what they were getting into, and there are a > lot of Windows users we *want* to support well. (*Not* "have to", and > YMMV. But the Python developer community clearly has a working > consensus on supporting Windows well.) There were some pretty big changes on the Windows side of things for Python 3.5.0 - not just porting the installer to the Wix toolset and migrating to a new of Visual Studio, but also adjusting to some fairly major underlying changes to the way the Microsoft C runtime works in general. As part of all that, I believe we also finally switched to being a well behaved Windows citizen and now default to installing into Program Files rather than the root of C:\. With the wide variety of system configurations out there, that degree of change from past practices was always going to encounter some teething troubles. Fortunately, we're unlikely to ever have to go through a shift like this again, and are now in a situation where our installation practices not only better align with Microsoft's recommendations, but are able to benefit from future evolution in the Wix toolset rather than necessarily having to track changes to Microsoft's recommendations directly. Cheers, Nick. ___ 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 498 (interpolated f-string) tweak
Good catch, Eric.
For those who wonder what the difference is or why it matters, it's what we
do for all dunder operators: the magic method is looked up on the class,
not on the instance. This means you can't e.g. override + on a per-instance
basis by having an instance variable named '__add__' pointing to some
function. That's a rare use case, it's pretty obfuscated, it would slow
down everything, and if you really need that pattern, there are other ways
to do it (you could have a regular instance method __add__ on the class
that looks for an instance variable, e.g. named _add, and call it if it
exists -- otherwise call super().__add__).
--Guido
On Sat, Sep 19, 2015 at 4:03 AM, Eric V. Smith wrote:
> While finishing up the implementation of PEP 498, I realized that the
> PEP has an error. It says that this code:
>
> f'abc{expr1:spec1}{expr2!r:spec2}def{expr3:!s}ghi'
>
> Is equivalent to:
>
> 'abc' + expr1.__format__(spec1) + repr(expr2).__format__(spec2) + 'def'
> + str(expr3).__format__('') + 'ghi'
>
> But that's not correct. The right way to call __format__ is:
>
> type(expr1).__format__(expr1, spec1)
>
> That is, the lookup of __format__ is done on the type, not the instance.
>
> Instead of calling __format__, I've changed the code generator to call
> format(expr1, spec1). As an optimization, I might add special opcodes to
> deal with this and string concatenation, but that's for another day (if
> ever).
>
> I've posted a new version of the code in issue 24965. I'll update the
> PEP itself sometime this weekend.
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
___
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] Proposing the deprecation of the pyvenv script
On 19.09.2015 14:44, Paul Moore wrote: On 19 September 2015 at 10:12, Sven R. Kunze wrote: The only question I have: is there a particular reason (not technical one) why there are many pips on my PC? That's not an unreasonable question, but (IMO) most of the answers are technical, or amount to "why would you think that's wrong". So apologies, I do know this isn't a direct answer to your question. 1. There are a lot of ways in which pip's implementation assumes it's installing modules for the Python installation that is running it. We need to cope with that in some way. 2. We have no installation process or path management to allow you to install a Python package *outside* of a Python installation and run it with the user's choice of Python. I wouldn't go so far so put the installation somewhere else. The current site-packages is good enough (although, it's a somewhat strange name). But what I would love to see is a real package management, where installing packages is safe (asking when overriding existing files), where I can have proper upgrading/downgrading, query dependencies, query installed files/scripts/data, query redundant packages and so on and so forth. Just like zypper, apt-get or its kind. We get there but I fear it will be a long time before Python gets the package management it deserves. pip = Python installs Python. That's how it started; however, real package management is far more. 3. You've got lots of pythons on your PC (otherwise you wouldn't have lots of pips!) so why do you think it's *not* equally reasonable to have lots of pips? pip happens to use Python but both serve different purposes. Why it's not reasonable? Good question, the best answer I can come up with is that "just invoking pip" does not tell you what Python it is going to un-/install packages for. You see it (when it's installing), but would be step forward to be asked kindly if I am okay with the installation location (and user+group permissions) and if not I could change it. Something like this. I think it's the usability I am really concerned with. 4. The "py" launcher (on Windows) manages your multiple Pythons for you - it can also manage pip if you don't mind using "py -m pip" to invoke pip. You can of course alias this (wrap it in a powershell function, bat file, shell script or whatever) as you choose. Interesting. So, py knows the location of all Python installations. What about py knows about all venvs? Then it could manage them in one place. So, to directly answer: Because there are technical challenges that no-one has stepped up to solve. Let's solve them. :) Best, Sven ___ 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] Proposing the deprecation of the pyvenv script
On 19 September 2015 at 18:15, Sven R. Kunze wrote: >> So, to directly answer: >> >> Because there are technical challenges that no-one has stepped up to >> solve. > > > Let's solve them. :) I thought my point was "yes, go for it - your code contribution would be appreciated" :-) Paul ___ 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] Proposing the deprecation of the pyvenv script
On 19.09.2015 19:19, Paul Moore wrote: I thought my point was "yes, go for it - your code contribution would be appreciated" :-) Paul Well, before coding shouldn't we have vision and a plan for pip somehow and pinpoint it somewhere where everybody who's willing to contribute can see it? Don't get me wrong, I'd be glad to contribute code (what I've already done to other open-source projects), but I feel somewhat disoriented when in comes to "Python core". Best, Sven ___ 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] Proposing the deprecation of the pyvenv script
Guys, this thread is about removing the pyvenv script, not pip. If you want to start a discussion about pip and its command structure that should probably happen on pip's issue tracker or over at distutils-sig. On Sat, 19 Sep 2015 at 10:37 Sven R. Kunze wrote: > On 19.09.2015 19:19, Paul Moore wrote: > > I thought my point was "yes, go for it - your code contribution would > > be appreciated" :-) Paul > > Well, before coding shouldn't we have vision and a plan for pip somehow > and pinpoint it somewhere where everybody who's willing to contribute > can see it? > > Don't get me wrong, I'd be glad to contribute code (what I've already > done to other open-source projects), but I feel somewhat disoriented > when in comes to "Python core". > > Best, > Sven > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/brett%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] PEP 498 (interpolated f-string) tweak
On 19.09.15 14:03, Eric V. Smith wrote:
While finishing up the implementation of PEP 498, I realized that the
PEP has an error. It says that this code:
f'abc{expr1:spec1}{expr2!r:spec2}def{expr3:!s}ghi'
Is equivalent to:
'abc' + expr1.__format__(spec1) + repr(expr2).__format__(spec2) + 'def'
+ str(expr3).__format__('') + 'ghi'
But that's not correct. The right way to call __format__ is:
type(expr1).__format__(expr1, spec1)
That is, the lookup of __format__ is done on the type, not the instance.
Instead of calling __format__, I've changed the code generator to call
format(expr1, spec1). As an optimization, I might add special opcodes to
deal with this and string concatenation, but that's for another day (if
ever).
Concatenating many strings is not efficient. More efficient way is to
use string formatting. Why not translate f-string to
'abc%s%sdef%sghi' % (format(expr1, spec1),
format(repr(expr2), spec2), expr3)
or even to
'abc{:spec1}{!r:spec2}def{!s}ghi'.format(expr1, expr2, expr3)
?
___
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 498 (interpolated f-string) tweak
On 9/19/2015 3:22 PM, Serhiy Storchaka wrote:
> On 19.09.15 14:03, Eric V. Smith wrote:
>> While finishing up the implementation of PEP 498, I realized that the
>> PEP has an error. It says that this code:
>>
>> f'abc{expr1:spec1}{expr2!r:spec2}def{expr3:!s}ghi'
>>
>> Is equivalent to:
>>
>> 'abc' + expr1.__format__(spec1) + repr(expr2).__format__(spec2) + 'def'
>> + str(expr3).__format__('') + 'ghi'
>>
>> But that's not correct. The right way to call __format__ is:
>>
>> type(expr1).__format__(expr1, spec1)
>>
>> That is, the lookup of __format__ is done on the type, not the instance.
>>
>> Instead of calling __format__, I've changed the code generator to call
>> format(expr1, spec1). As an optimization, I might add special opcodes to
>> deal with this and string concatenation, but that's for another day (if
>> ever).
>
> Concatenating many strings is not efficient. More efficient way is to
> use string formatting. Why not translate f-string to
>
> 'abc%s%sdef%sghi' % (format(expr1, spec1),
> format(repr(expr2), spec2), expr3)
As the PEP says, the expression with '+' is illustrative, not how it's
actually implemented. The implementation currently uses ''.join,
although I reserve the right to change it.
> or even to
>
> 'abc{:spec1}{!r:spec2}def{!s}ghi'.format(expr1, expr2, expr3)
That's surprisingly difficult to get right. I've implemented the code at
least 3 different ways, and the current implementation seems the most
straightforward. I might add a special opcode to use a _PyUncode_Writer,
though.
Eric.
___
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] Proposing the deprecation of the pyvenv script
On 19 September 2015 at 19:37, Brett Cannon wrote: > Guys, this thread is about removing the pyvenv script, not pip. If you want > to start a discussion about pip and its command structure that should > probably happen on pip's issue tracker or over at distutils-sig. Sorry, good point. Back to the original question, I'm +1 on deprecating pyvenv as described. Paul ___ 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 498 (interpolated f-string) tweak
On 9/19/2015 3:36 PM, Eric V. Smith wrote: > On 9/19/2015 3:22 PM, Serhiy Storchaka wrote: >> On 19.09.15 14:03, Eric V. Smith wrote: >>> Instead of calling __format__, I've changed the code generator to call >>> format(expr1, spec1). As an optimization, I might add special opcodes to >>> deal with this and string concatenation, but that's for another day (if >>> ever). >> >> Concatenating many strings is not efficient. More efficient way is to >> use string formatting. Why not translate f-string to >> >> 'abc%s%sdef%sghi' % (format(expr1, spec1), >> format(repr(expr2), spec2), expr3) > > As the PEP says, the expression with '+' is illustrative, not how it's > actually implemented. The implementation currently uses ''.join, > although I reserve the right to change it. I should also note: an earlier version of the PEP showed the ''.join() version of the equivalent code, but the feedback was that it was confusing, and the '+' version was easier to understand. And another reason that I don't use %-formatting or ''.format() as the implementation is for performance: the parser spends a lot of effort to parse the f-string. To then put it back together and have ''.format() immediately re-parse it didn't make much sense. And I'm not convinced there aren't edge cases where the f-string parser and the ''.format() parse differ, especially when dealing with nested format_specs with funky characters. Instead, I generate two additional AST nodes: ast.FormattedValue and ast.JoinedStr. JoinedStr just has list of string expressions which get joined together (as I said: currently using ''.join()). FormattedValue contains the expression and its optional conversion character and optional format_spec, which get formatted into a string (currently using the builtin format()). Eric. ___ 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 498 (interpolated f-string) tweak
On Sun, Sep 20, 2015 at 5:36 AM, Eric V. Smith wrote:
> As the PEP says, the expression with '+' is illustrative, not how it's
> actually implemented. The implementation currently uses ''.join,
> although I reserve the right to change it.
>
>> or even to
>>
>> 'abc{:spec1}{!r:spec2}def{!s}ghi'.format(expr1, expr2, expr3)
>
> That's surprisingly difficult to get right. I've implemented the code at
> least 3 different ways, and the current implementation seems the most
> straightforward. I might add a special opcode to use a _PyUncode_Writer,
> though.
Since this is entirely under the control of the parser, there's no
particular reason to promise anything about the implementation or its
performance metrics. The semantics won't change if CPython 3.7.4
decides to change to using ''.join() instead of concatenation.
Let's not bikeshed the implementation details. I'm sure Eric knows
what he's doing.
ChrisA
___
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] Make stacklevel=2 by default in warnings.warn()
For now the default value of the stacklevel parameter in warnings.warn() is 1. But in most cases stacklevel=2 is required, sometimes >2, and I don't know cases that need stacklevel=1. I propose to make the default value of stacklevel to be 2. I think that unlikely this will break existing code. But rather can fix existing bugs. If stacklevel=1 is required (I don't know cases), it can be explicitly specified. ___ 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] Make stacklevel=2 by default in warnings.warn()
On Sat, Sep 19, 2015 at 11:44 PM, Serhiy Storchaka wrote: > For now the default value of the stacklevel parameter in warnings.warn() is > 1. But in most cases stacklevel=2 is required, sometimes >2, and I don't > know cases that need stacklevel=1. I propose to make the default value of > stacklevel to be 2. I think that unlikely this will break existing code. But > rather can fix existing bugs. If stacklevel=1 is required (I don't know > cases), it can be explicitly specified. +1 I don't have enough fingers to count how many times I've had to explain how stacklevel= works to maintainers of widely-used packages -- they had no idea that this was even a thing they were getting wrong. OTOH I guess if there is anyone out there who's intentionally using stacklevel=1 they might be reasonably surprised at this change. I guess for some kinds of warnings stacklevel=2 is not obviously correct -- the one that comes to mind is "warning: the computer on the other end of this network connection did something weird, continuing anyway". OTOOH in this case I'm not sure stacklevel=1 is any better either, since the thing being warned about has nothing to do with the current call stack at all. -n -- Nathaniel J. Smith -- http://vorpus.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
