[Python-Dev] How are we merging forward from the Bitbucket 3.5 repo?
So far I've accepted two pull requests into bitbucket.com/larry/cpython350 in the 3.5 branch, what will become 3.5.0rc2. As usual, it's the contributor's responsibility to merge forward; if their checkin goes in to 3.5, it's their responsibility to also merge it into the hg.python.org/cpython 3.5 branch (which will be 3.5.1) and default branch (which right now is 3.6). But... what's the plan here? I didn't outline anything specific, I just assumed we'd do the normal thing, pulling from 3.5.0 into 3.5.1 and merging. But of the two pull requests so far accepted, one was merged this way, though it cherry-picked the revision (skipping the pull request merge revision Bitbucket created), and one was checked in to 3.5.1 directly (no merging). I suppose we can do whatever we like. But it'd be helpful if we were consistent. I can suggest three approaches: 1. After your push request is merged, you cherry-pick your revision from bitbucket.com/larry/cpython350 into hg.python.org/cpython and merge. After 3.5.0 final is released I do a big null merge from bitbucket.com/larry/cpython350 into hg.python.org/cpython. 2. After your push request is merged, you manually check in a new equivalent revision into hg.python.org/cpython in the 3.5 branch. No merging necessary because from Mercurial's perspective it's unrelated to the revision I accepted. After 3.5.0 final is released I do a big null merge from bitbucket.com/larry/cpython350 into hg.python.org/cpython. 3. After your push request is merged, you pull from bitbucket.com/larry/cpython350 into hg.python.org/cpython and merge into 3.5. In this version I don't have to do a final null merge! I'd prefer 3; that's what we normally do, and that's what I was expecting. So far people have done 1 and 2. Can we pick one approach and stick with it? Pretty-please? //arry/ ___ 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] updating ensurepip to include wheel
On 8 August 2015 at 04:53, Nick Coghlan wrote: >> I do however think it would make ensurepip itself better, so I’m not dead >> set against it, mostly just worried about ramifications. > > I'd advise against letting concerns about Linux distro politics hold > you back from making ensurepip as good as you can make it - if nothing > else, the developer experience folks at commercial Linux vendors are > specifically paid to advocate for the interests of software developers > when it comes to the Linux user experience (that's part of my own day > job in the Fedora/RHEL/CentOS case - I moved over to the software > management team in RHEL Developer Experience at the start of June). > > That means that while I will have some *requests* to make certain > things easier downstream (like going through the PEP process to figure > out an upstream supported way to omit the build-only dependencies when > running ensurepip), I also wholeheartedly endorse the idea of having > the default upstream behaviour focus on making the initial experience > for folks downloading Windows or Mac OS X binaries from python.org as > compelling as we can make it. python-dev needs to put the needs of > Python first, and those of Linux second. > > This does mean that any Linux distro that can't figure out how to > provide a better open source developer experience for Pythonistas than > Windows or Mac OS X is at risk of falling by the wayside in the Python > community, but if those of us that care specifically about the > viability of desktop Linux as a platform for open source development > stand by and let that happen, then we'll *deserve* the consequences. Sorry I'm late to this, but I would very much like to see wheel installed with ensurepip on at least Windows. (I don't see any reason why OSX would not be similar, but as I'm not an OSX user I can't say for certain). If Linux distros have issue with this, then maybe we need to do something different there (I like Nick's comments, and would rather we didn't make the Linux situation worse due to distro politics, but that's not my call) but that shouldn't affect Windows/OSX. There's a certain irony to me in the fact that we're reaching a point where the Windows experience is the benchmark Linux users need to aim for, but I'll avoid saying anything more on that one ;-) Paul ___ 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-committers] How are we merging forward from the Bitbucket 3.5 repo?
I presume the issue here is that Hg is so complicated that everyone knows a different subset of the commands and semantics. I personally don't know what the commands for cherry-picking a revision would be. I also don't know exactly what happens when you merge a PR using bitbucket. (I'm only familiar with the GitHub PR flow, and I don't like its behavior, which seems to always create an extra merge revision for what I consider as logically a single commit.) BTW When I go to https://bitbucket.org/larry/cpython350 the first thing I see (in a very big bold font) is "This is Python version 3.6.0 alpha 1". What's going on here? It doesn't inspire confidence. On Sun, Aug 16, 2015 at 10:13 AM, Larry Hastings wrote: > > > So far I've accepted two pull requests into bitbucket.com/larry/cpython350 > in the 3.5 branch, what will become 3.5.0rc2. As usual, it's the > contributor's responsibility to merge forward; if their checkin goes in to > 3.5, it's their responsibility to also merge it into the > hg.python.org/cpython 3.5 branch (which will be 3.5.1) and default branch > (which right now is 3.6). > > But... what's the plan here? I didn't outline anything specific, I just > assumed we'd do the normal thing, pulling from 3.5.0 into 3.5.1 and > merging. But of the two pull requests so far accepted, one was merged this > way, though it cherry-picked the revision (skipping the pull request merge > revision Bitbucket created), and one was checked in to 3.5.1 directly (no > merging). > > I suppose we can do whatever we like. But it'd be helpful if we were > consistent. I can suggest three approaches: > >1. After your push request is merged, you cherry-pick your revision >from bitbucket.com/larry/cpython350 into hg.python.org/cpython and >merge. After 3.5.0 final is released I do a big null merge from >bitbucket.com/larry/cpython350 into hg.python.org/cpython. >2. After your push request is merged, you manually check in a new >equivalent revision into hg.python.org/cpython in the 3.5 branch. No >merging necessary because from Mercurial's perspective it's unrelated to >the revision I accepted. After 3.5.0 final is released I do a big null >merge from bitbucket.com/larry/cpython350 into hg.python.org/cpython. >3. After your push request is merged, you pull from >bitbucket.com/larry/cpython350 into hg.python.org/cpython and merge >into 3.5. In this version I don't have to do a final null merge! > > I'd prefer 3; that's what we normally do, and that's what I was > expecting. So far people have done 1 and 2. > > Can we pick one approach and stick with it? Pretty-please? > > > */arry* > > ___ > python-committers mailing list > python-committ...@python.org > https://mail.python.org/mailman/listinfo/python-committers > > -- --Guido van Rossum (python.org/~guido) ___ 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-498: Literal String Formatting
On 8 August 2015 at 02:39, Eric V. Smith wrote:
> Following a long discussion on python-ideas, I've posted my draft of
> PEP-498. It describes the "f-string" approach that was the subject of
> the "Briefer string format" thread. I'm open to a better title than
> "Literal String Formatting".
>
> I need to add some text to the discussion section, but I think it's in
> reasonable shape. I have a fully working implementation that I'll get
> around to posting somewhere this weekend.
>
def how_awesome(): return 'very'
> ...
f'f-strings are {how_awesome()} awesome!'
> 'f-strings are very awesome!'
>
> I'm open to any suggestions to improve the PEP. Thanks for your feedback.
In my view:
1. Calling them "format strings" rather than "f-strings" is sensible
(by analogy with "raw string" etc). Colloquially we can use f-string
if we want, but let's have the formal name be fully spelled out. In
particular, the PEP should use "format string".
2. By far and away the most common use for me would be things like
print(f"Iteration {n}: Took {end-start) seconds"). At the moment I use
str,format() for this, and it's annoyingly verbose. This would be a
big win, and I'm +1 on the PEP for this specific reason.
3. All of the complex examples look scary, but in practice I wouldn't
write stuff like that - why would anyone do so unless they were being
deliberately obscure? On the other hand, as I gained experience with
the construct, being *able* to use more complex expressions without
having to stop and remember special cases would be great.
4. It's easy to write print("My age is {age}") and forget the "f"
prefix. While it'll bug me at first that I have to go back and fix
stuff to add the "f" after my code gives the wrong output, I *don't*
want to see this ability added to unprefixed strings. IMO that's going
a step too far (explicit is better than implicit and all that).
5. The PEP is silent (as far as I can see) on things like whether
triple quoting (f"""...""") is allowed (I assume it is), and whether
prefixes can be combined (for example, rf'{drive}:\{path}\{filename}')
(I'd like them to be, but can live without it).
6. The justification for ignoring whitespace is weak (the motivating
case is obscure, and there are many viable workarounds). I don't think
it's worth ignoring whitespace - but I also don't think it's worth a
long discussion. Just pick an option (as you did) and go with it. So I
see no need for change here,
Apologies for the above being terse - I'm clearing a big backlog of
emails. Ask for clarification if you need it!
Paul
___
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-committers] How are we merging forward from the Bitbucket 3.5 repo?
On 2015-08-16, at 16:08 , Guido van Rossum wrote: > I presume the issue here is that Hg is so complicated that everyone knows a > different subset of the commands and semantics. > > I personally don't know what the commands for cherry-picking a revision would > be. graft > I also don't know exactly what happens when you merge a PR using bitbucket. > (I'm only familiar with the GitHub PR flow, and I don't like its behavior, > which seems to always create an extra merge revision for what I consider as > logically a single commit.) Same thing IIRC, I don't think there's a way to "squash" a merge via the web interface in either. > BTW When I go to https://bitbucket.org/larry/cpython350 the first thing I see > (in a very big bold font) is "This is Python version 3.6.0 alpha 1". What's > going on here? It doesn't inspire confidence. It's the rendered content of the README file at the root of the repository, same as github.___ 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-committers] How are we merging forward from the Bitbucket 3.5 repo?
On 16.08.2015 16:08, Guido van Rossum wrote: > I presume the issue here is that Hg is so complicated that everyone knows a > different subset of the commands and semantics. > > I personally don't know what the commands for cherry-picking a revision > would be. > > I also don't know exactly what happens when you merge a PR using bitbucket. > (I'm only familiar with the GitHub PR flow, and I don't like its behavior, > which seems to always create an extra merge revision for what I consider as > logically a single commit.) > > BTW When I go to https://bitbucket.org/larry/cpython350 the first thing I > see (in a very big bold font) is "This is Python version 3.6.0 alpha 1". > What's going on here? It doesn't inspire confidence. You are probably looking at the default branch within that repo fork. This is the 3.5 branch: https://bitbucket.org/larry/cpython350/branch/3.5 > On Sun, Aug 16, 2015 at 10:13 AM, Larry Hastings wrote: > >> >> >> So far I've accepted two pull requests into bitbucket.com/larry/cpython350 >> in the 3.5 branch, what will become 3.5.0rc2. As usual, it's the >> contributor's responsibility to merge forward; if their checkin goes in to >> 3.5, it's their responsibility to also merge it into the >> hg.python.org/cpython 3.5 branch (which will be 3.5.1) and default branch >> (which right now is 3.6). >> >> But... what's the plan here? I didn't outline anything specific, I just >> assumed we'd do the normal thing, pulling from 3.5.0 into 3.5.1 and >> merging. But of the two pull requests so far accepted, one was merged this >> way, though it cherry-picked the revision (skipping the pull request merge >> revision Bitbucket created), and one was checked in to 3.5.1 directly (no >> merging). >> >> I suppose we can do whatever we like. But it'd be helpful if we were >> consistent. I can suggest three approaches: >> >>1. After your push request is merged, you cherry-pick your revision >>from bitbucket.com/larry/cpython350 into hg.python.org/cpython and >>merge. After 3.5.0 final is released I do a big null merge from >>bitbucket.com/larry/cpython350 into hg.python.org/cpython. >>2. After your push request is merged, you manually check in a new >>equivalent revision into hg.python.org/cpython in the 3.5 branch. No >>merging necessary because from Mercurial's perspective it's unrelated to >>the revision I accepted. After 3.5.0 final is released I do a big null >>merge from bitbucket.com/larry/cpython350 into hg.python.org/cpython. >>3. After your push request is merged, you pull from >>bitbucket.com/larry/cpython350 into hg.python.org/cpython and merge >>into 3.5. In this version I don't have to do a final null merge! >> >> I'd prefer 3; that's what we normally do, and that's what I was >> expecting. So far people have done 1 and 2. >> >> Can we pick one approach and stick with it? Pretty-please? >> >> >> */arry* >> >> ___ >> python-committers mailing list >> python-committ...@python.org >> https://mail.python.org/mailman/listinfo/python-committers >> >> > > > > > ___ > python-committers mailing list > python-committ...@python.org > https://mail.python.org/mailman/listinfo/python-committers > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 16 2015) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> mxODBC Plone/Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2015-08-12: Released mxODBC 3.3.4 ... http://egenix.com/go80 2015-08-22: FrOSCon 2015 ...6 days to go : Try our mxODBC.Connect Python Database Interface for free ! :: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] updating ensurepip to include wheel
On Sun, Aug 16, 2015 at 02:17:09PM +0100, Paul Moore wrote: > Sorry I'm late to this, but I would very much like to see wheel > installed with ensurepip on at least Windows. I seem to be missing something critical to this entire discussion. As I understand it, ensurepip is *only* intended to bootstrap pip itself. So the idea is, you install Python, including ensurepip, use that to install the latest pip *including wheel*, and Bob's your uncle. At worst, you install pip, then install wheel. So what is the benefit of including wheel with ensurepip? -- 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/archive%40mail-archive.com
Re: [Python-Dev] updating ensurepip to include wheel
On August 16, 2015 at 10:41:42 AM, Steven D'Aprano (st...@pearwood.info) wrote: > On Sun, Aug 16, 2015 at 02:17:09PM +0100, Paul Moore wrote: > > > Sorry I'm late to this, but I would very much like to see wheel > > installed with ensurepip on at least Windows. > > I seem to be missing something critical to this entire discussion. > > As I understand it, ensurepip is *only* intended to bootstrap pip > itself. So the idea is, you install Python, including ensurepip, use > that to install the latest pip *including wheel*, and Bob's your uncle. > > At worst, you install pip, then install wheel. > > So what is the benefit of including wheel with ensurepip? > pip has an optional dependency on wheel, if you install that optional dependency than you’ll get the implicit wheel cache enabled by default which can drastically improve installation speeds by caching built artifacts (i.e. ``pip instal lxml`` multiple times only compiles it once). The goal is to get more people getting the benefits of that by default instead of requiring them to know they need to ``pip install wheel`` after the fact. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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] updating ensurepip to include wheel
On Sun, Aug 16, 2015 at 10:52:00AM -0400, Donald Stufft wrote: > > So what is the benefit of including wheel with ensurepip? > > pip has an optional dependency on wheel, if you install that optional > dependency than you’ll get the implicit wheel cache enabled by default > which can drastically improve installation speeds by caching built > artifacts (i.e. ``pip instal lxml`` multiple times only compiles it > once). The goal is to get more people getting the benefits of that by > default instead of requiring them to know they need to ``pip install > wheel`` after the fact. Thanks for the explanation. And ensurepip couldn't install wheel as part of the process of installing pip? -- 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/archive%40mail-archive.com
Re: [Python-Dev] How are we merging forward from the Bitbucket 3.5 repo?
On Sun, 16 Aug 2015 00:13:10 -0700, Larry Hastings wrote: > > > So far I've accepted two pull requests into > bitbucket.com/larry/cpython350 in the 3.5 branch, what will become > 3.5.0rc2. As usual, it's the contributor's responsibility to merge > forward; if their checkin goes in to 3.5, it's their responsibility to > also merge it into the hg.python.org/cpython 3.5 branch (which will be > 3.5.1) and default branch (which right now is 3.6). > > But... what's the plan here? I didn't outline anything specific, I just > assumed we'd do the normal thing, pulling from 3.5.0 into 3.5.1 and > merging. But of the two pull requests so far accepted, one was merged > this way, though it cherry-picked the revision (skipping the pull > request merge revision Bitbucket created), and one was checked in to > 3.5.1 directly (no merging). > > I suppose we can do whatever we like. But it'd be helpful if we were > consistent. I can suggest three approaches: > > 1. After your push request is merged, you cherry-pick your revision > from bitbucket.com/larry/cpython350 into hg.python.org/cpython and > merge. After 3.5.0 final is released I do a big null merge from > bitbucket.com/larry/cpython350 into hg.python.org/cpython. > 2. After your push request is merged, you manually check in a new > equivalent revision into hg.python.org/cpython in the 3.5 branch. > No merging necessary because from Mercurial's perspective it's > unrelated to the revision I accepted. After 3.5.0 final is released > I do a big null merge from bitbucket.com/larry/cpython350 into > hg.python.org/cpython. > 3. After your push request is merged, you pull from > bitbucket.com/larry/cpython350 into hg.python.org/cpython and merge > into 3.5. In this version I don't have to do a final null merge! > > I'd prefer 3; that's what we normally do, and that's what I was > expecting. So far people have done 1 and 2. > > Can we pick one approach and stick with it? Pretty-please? Pick one Larry, you are the RM :) The reason you got different things was that how to do this was under-specified. Which of course we didn't realize, this being a new procedure and all. That said, I'm still not sure how (3) works. Can you give us a step by step like you did for creating the pull request? Including how it relates to the workflow for the other branches? (What I did was just do the thing I normally do, and then follow your instructions for creating a pull request using the same patch I had previously committed to 3.4.) --David ___ 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] How are we managing 3.5 NEWS?
The 3.5.0 patch flow question also brings up the question of how we are managing NEWS for 3.5.0 vs 3.5.1. We have some commits that are going in to both 3.5.0a2 and 3.5.1, and some that are only going in to 3.5.1. Currently the 3.5.1 NEWS says things are going in to 3.5.0a2, but that's obviously wrong. Do we relabel the section in 3.5.1 NEWS as 3.5.1a1? That would leave us with the 3.5.1 NEWS never having the last alpha sections from 3.5.0, which is logical but might be confusing (or is that the way we've done it in the past?) Do we leave it to the RM to sort out each individual patch when he merges 3.5.0 into the 3.5 branch? That sounds like a lot of work, although if there are few enough patches that go into the alphas, it might not be too hard. Either way, that final 3.5.0 merge is going to require an edit of the NEWS file. Larry, how do you plan to handle this? --David PS: We'll also need an answer to this question for the proposed new NEWS workflow of putting the NEWS items in the tracker. We'll probably need to introduce x.y.z versions into the tracker. ___ 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-committers] How are we merging forward from the Bitbucket 3.5 repo?
On Sun, 16 Aug 2015 11:24:32 -0400, "R. David Murray" wrote: > On Sun, 16 Aug 2015 00:13:10 -0700, Larry Hastings wrote: > > 3. After your push request is merged, you pull from > > bitbucket.com/larry/cpython350 into hg.python.org/cpython and merge > > into 3.5. In this version I don't have to do a final null merge! > > > > I'd prefer 3; that's what we normally do, and that's what I was > > expecting. So far people have done 1 and 2. Thinking about this some more I realize why I was confused. My patch/pull request was something that got committed to 3.4. In that case, to follow your 3 I'd have to leave 3.4 open until you merged the pull request, and that goes against our normal workflow. Maybe my patch will be the only exception... --David ___ 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] updating ensurepip to include wheel
On August 16, 2015 at 11:26:08 AM, Steven D'Aprano (st...@pearwood.info) wrote: > On Sun, Aug 16, 2015 at 10:52:00AM -0400, Donald Stufft wrote: > > > > So what is the benefit of including wheel with ensurepip? > > > > pip has an optional dependency on wheel, if you install that optional > > dependency than you’ll get the implicit wheel cache enabled by default > > which can drastically improve installation speeds by caching built > > artifacts (i.e. ``pip instal lxml`` multiple times only compiles it > > once). The goal is to get more people getting the benefits of that by > > default instead of requiring them to know they need to ``pip install > > wheel`` after the fact. > > Thanks for the explanation. > > And ensurepip couldn't install wheel as part of the process of > installing pip? > > That’s the proposal here, ensurepip only installs things it has bundled inside of it, so we’d add a .whl file for wheel and slightly tweak ensurepip so it also installs wheel. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ 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-498: Literal String Formatting
Thanks, Paul. Good feedback.
Triple quoted and raw strings work like you'd expect, but you're right: the PEP
should make this clear.
I might drop the leading spaces, for a technical reason having to deal with
passing the strings in to str.format. But I agree it's not a big deal one way
or the other.
I'll incorporate the rest of your feedback (and others) when I get back to a
real computer.
--
Eric.
Top-posted from my phone.
> On Aug 16, 2015, at 10:21 AM, Paul Moore wrote:
>
>> On 8 August 2015 at 02:39, Eric V. Smith wrote:
>> Following a long discussion on python-ideas, I've posted my draft of
>> PEP-498. It describes the "f-string" approach that was the subject of
>> the "Briefer string format" thread. I'm open to a better title than
>> "Literal String Formatting".
>>
>> I need to add some text to the discussion section, but I think it's in
>> reasonable shape. I have a fully working implementation that I'll get
>> around to posting somewhere this weekend.
>>
> def how_awesome(): return 'very'
>> ...
> f'f-strings are {how_awesome()} awesome!'
>> 'f-strings are very awesome!'
>>
>> I'm open to any suggestions to improve the PEP. Thanks for your feedback.
>
> In my view:
>
> 1. Calling them "format strings" rather than "f-strings" is sensible
> (by analogy with "raw string" etc). Colloquially we can use f-string
> if we want, but let's have the formal name be fully spelled out. In
> particular, the PEP should use "format string".
>
> 2. By far and away the most common use for me would be things like
> print(f"Iteration {n}: Took {end-start) seconds"). At the moment I use
> str,format() for this, and it's annoyingly verbose. This would be a
> big win, and I'm +1 on the PEP for this specific reason.
>
> 3. All of the complex examples look scary, but in practice I wouldn't
> write stuff like that - why would anyone do so unless they were being
> deliberately obscure? On the other hand, as I gained experience with
> the construct, being *able* to use more complex expressions without
> having to stop and remember special cases would be great.
>
> 4. It's easy to write print("My age is {age}") and forget the "f"
> prefix. While it'll bug me at first that I have to go back and fix
> stuff to add the "f" after my code gives the wrong output, I *don't*
> want to see this ability added to unprefixed strings. IMO that's going
> a step too far (explicit is better than implicit and all that).
>
> 5. The PEP is silent (as far as I can see) on things like whether
> triple quoting (f"""...""") is allowed (I assume it is), and whether
> prefixes can be combined (for example, rf'{drive}:\{path}\{filename}')
> (I'd like them to be, but can live without it).
>
> 6. The justification for ignoring whitespace is weak (the motivating
> case is obscure, and there are many viable workarounds). I don't think
> it's worth ignoring whitespace - but I also don't think it's worth a
> long discussion. Just pick an option (as you did) and go with it. So I
> see no need for change here,
>
> Apologies for the above being terse - I'm clearing a big backlog of
> emails. Ask for clarification if you need it!
>
> Paul
> ___
> 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/eric%2Ba-python-dev%40trueblade.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-498: Literal String Formatting
On Sun, Aug 16, 2015 at 8:55 PM, Eric V. Smith wrote:
> Thanks, Paul. Good feedback.
>
Indeed, I smiled when I saw Paul's post.
> Triple quoted and raw strings work like you'd expect, but you're right:
> the PEP should make this clear.
>
> I might drop the leading spaces, for a technical reason having to deal
> with passing the strings in to str.format. But I agree it's not a big deal
> one way or the other.
>
Hm. I rather like allow optional leading/trailing spaces. Given that we
support arbitrary expressions, we have to support internal spaces; I think
that some people would really like to use leading/trailing spaces,
especially when there's text immediately against the other side of the
braces, as in
f'Stuff{ len(self.busy) }more stuff'
I also expect it might be useful to allow leading/trailing newlines, if
they are allowed at all (i.e. inside triple-quoted strings). E.g.
f'''Stuff{
len(self.busy)
}more stuff'''
> I'll incorporate the rest of your feedback (and others) when I get back to
> a real computer.
>
Here's another thing for everybody's pondering: when tokenizing an
f-string, I think the pieces could each become tokens in their own right.
Then the rest of the parsing (and rules about whitespace etc.) would become
simpler because the grammar would deal with them. E.g. the string above
would be tokenized as follows:
f'Stuff{
len
(
self
.
busy
)
}more stuff'
The understanding here is that there are these new types of tokens:
F_STRING_OPEN for f'...{, F_STRING_MIDDLE for }...{, F_STRING_END for
}...', and I suppose we also need F_STRING_OPEN_CLOSE for f'...' (i.e. not
containing any substitutions). These token types can then be used in the
grammar. (A complication would be different kinds of string quotes; I
propose to handle that in the lexer, otherwise the number of open/close
token types would balloon out of proportions.)
--
--Guido van Rossum (python.org/~guido)
___
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-498 & PEP-501: Literal String Formatting/Interpolation
On Sun, Aug 9, 2015 at 3:25 PM Brett Cannon wrote:
>
> On Sun, Aug 9, 2015, 13:51 Peter Ludemann via Python-Dev <
> python-dev@python.org> wrote:
>
> Most of my outputs are log messages, so this proposal won't help me
> because (I presume) it does eager evaluation of the format string and the
> logging methods are designed to do lazy evaluation. Python doesn't have
> anything like Lisp's "special forms", so there doesn't seem to be a way to
> implicitly put a lambda on the string to delay evaluation.
>
> It would be nice to be able to mark the formatting as lazy ... maybe
> another string prefix character to indicate that? (And would the 2nd
> expression in an assert statement be lazy or eager?)
>
>
> That would require a lazy string type which is beyond the scope of this
> PEP as proposed since it would require its own design choices, how much
> code would not like the different type, etc.
>
> -Brett
>
Agreed that doesn't belong in PEP 498 or 501 itself... But it is a real
need.
We left logging behind when we added str.format() and adding yet another
_third_ way to do string formatting without addressing the needs of
deferred-formatting for things like logging is annoying.
brainstorm: Imagine a deferred interpolation string with a d'' prefix..
di'foo ${bar}' would be a new type with a __str__ method that also retains
a runtime reference to the necessary values from the scope within which it
was created that will be used for substitutions when iff/when it is
__str__()ed. I still wouldn't enjoy reminding people to use di''
inlogging.info(di'thing happened: ${result}') all the time any more than I
like reminding people to undo their use of % and just pass the values as
additional args to the logging call... But I think people would find it
friendlier and thus be more likely to get it right on their own. logging's
manually deferred % is an idiom i'd like to see wither away.
There's also a performance aspect to any new formatter, % is oddly pretty
fast, str.format isn't. So long as you can do stuff at compile time rather
than runtime I think these PEPs could be even faster. Constant string
pep-498 or pep-501 formatting could be broken down at compile time and
composed into the optimal set of operations to build the resulting string /
call the formatter.
So far looking over both peps, I lean towards pep-501 rather than 498:
I really prefer the ${} syntax.
I don't like arbitrary logical expressions within strings.
I dislike str only things without a similar concept for bytes.
but neither quite suits me yet.
501's __interpolate*__ builtins are good and bad at the same time. doing
this at the module level does seem right, i like the i18n use aspect of
that, but you could also imagine these being methods so that subclasses
could override the behavior on a per-type basis. but that probably only
makes sense if a deferred type is created due to when and how interpolates
would be called. also, adding builtins, even __ones__ annoys me for some
reason I can't quite put my finger on.
(jumping into the threads way late)
-gps
>
> PS: As to Brett's comment about the history of string interpolation ... my
> recollection/understanding is that it started with Unix shells and the
> "$variable" notation, with the "$variable" being evaluated within "..." and
> not within '...'. Perl, PHP, Make (and others) picked this up. There seems
> to be a trend to avoid the bare "$variable" form and instead use
> "${variable}" everywhere, mainly because "${...}" is sometimes required to
> avoid ambiguities (e.g. "There were $NUMBER ${THING}s.")
>
> PPS: For anyone wishing to improve the existing format options, Common
> Lisp's FORMAT
> and Prolog's format/2
>
> have some capabilities that I miss from time to time in Python.
>
> On 9 August 2015 at 11:22, Eric V. Smith wrote:
>
> On 8/9/2015 1:38 PM, Brett Cannon wrote:
> >
> >
> > On Sun, 9 Aug 2015 at 01:07 Stefan Behnel
> > > wrote:
> >
> > Eric V. Smith schrieb am 08.08.2015 um 03:39:
> > > Following a long discussion on python-ideas, I've posted my draft
> of
> > > PEP-498. It describes the "f-string" approach that was the subject
> of
> > > the "Briefer string format" thread. I'm open to a better title than
> > > "Literal String Formatting".
> > >
> > > I need to add some text to the discussion section, but I think
> it's in
> > > reasonable shape. I have a fully working implementation that I'll
> get
> > > around to posting somewhere this weekend.
> > >
> > > >>> def how_awesome(): return 'very'
> > > ...
> > > >>> f'f-strings are {how_awesome()} awesome!'
> > > 'f-strings are very awesome!'
> > >
> > > I'm open to any suggestions to improve the PEP. Thanks for your
> > feedback.
> >
> > [copying my comment from python-ideas here]
> >
> >
Re: [Python-Dev] [python-committers] How are we merging forward from the Bitbucket 3.5 repo?
On 08/16/2015 07:08 AM, Guido van Rossum wrote: I presume the issue here is that Hg is so complicated that everyone knows a different subset of the commands and semantics. I personally don't know what the commands for cherry-picking a revision would be. There are a couple. The command you'd want for this use case is probably "hg transplant", because it lets you pull revisions from a different repo. Note that "transplant" is an extension; it's distributed with Mercurial but is turned off by default. (Presumably because it's an "unloved" feature, which seems to translate roughly to "deprecated and only minimally supported".) The Mercurial team recommends "graft", and they also provide "rebase", but neither of those can pull revisions from another repo. Since all revisions committed to 3.5.0 should be merged into 3.5.1 sooner or later, personally I don't see the *need* for cherry-picking. I also don't know exactly what happens when you merge a PR using bitbucket. (I'm only familiar with the GitHub PR flow, and I don't like its behavior, which seems to always create an extra merge revision for what I consider as logically a single commit.) Bitbucket doesn't appear to create any extraneous merge revisions. Of the two PRs I've accepted, only one created a merge, and that was sensible. BTW When I go to https://bitbucket.org/larry/cpython350 the first thing I see (in a very big bold font) is "This is Python version 3.6.0 alpha 1". What's going on here? It doesn't inspire confidence. It was displaying the readme from the default branch. We use the 3.5 branch. I just went and looked, and there's a "default branch" option for the repo on Bitbucket. I changed it from "default" to "3.5" and now it displays "This is Python version 3.5.0 release candidate 1". Hopefully that inspires more confidence! / /arry/ ___ 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-committers] How are we merging forward from the Bitbucket 3.5 repo?
On Sun, Aug 16, 2015 at 7:08 AM, Guido van Rossum wrote: > (I'm only familiar with the GitHub PR flow, and I don't like its behavior, > which seems to always create an extra merge revision for what I consider as > logically a single commit.) For whatever it's worth, this is a "feature": the extra merge revision serves as a record of the fact that a PR was merged, who merged it, and what the state of the branch was before and after the merge (useful in case the PR contains multiple revisions that are all getting merged together). These are all things that git makes impossible to reconstruct after the fact otherwise, because it stores no metadata about which branch each revision started out in. But if you consistently make a merge commit every time, then 'git log --first-parent' will reliably show one entry per merged PR. -n -- Nathaniel J. Smith -- http://vorpus.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] PEP-498: Literal String Formatting
2015-08-16 7:21 GMT-07:00 Paul Moore :
> 2. By far and away the most common use for me would be things like
> print(f"Iteration {n}: Took {end-start) seconds"). At the moment I use
> str,format() for this, and it's annoyingly verbose. This would be a
> big win, and I'm +1 on the PEP for this specific reason.
You can use a temporary variable, it's not much longer:
print("Iteration {n}: Took {dt) seconds".format(n=n, dt=end-start))
becomes
dt = end - start
print(f"Iteration {n}: Took {dt) seconds")
> 3. All of the complex examples look scary, but in practice I wouldn't
> write stuff like that - why would anyone do so unless they were being
> deliberately obscure?
I'm quite sure that users will write complex code in f-strings.
I vote -1 on the current PEP because of the support of Python code in
f-string, but +1 on a PEP without Python code.
Victor
___
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-498 & PEP-501: Literal String Formatting/Interpolation
How is this proposal of di"..." more than a different spelling of lambda
i"..."? (I think it's a great idea — but am wondering if there are some
extra semantics that I missed)
I don't think there's any need to preserve the values of the {...} (or
${...}) constituents — the normal closure mechanism should do fine because
logging is more-or-less like this:
if :
if callable(msg):
log_msg = msg(*args)
else:
log_msg = msg % args
and so there's no need to preserve the values at the moment the
interpolated string is created.
Perl allows arbitrary expressions inside interpolations, but that tends to
get messy and is self-limiting for complex expressions; however, it's handy
for things like:
print("The {i+1}th item is strange: {x[i]})
On 16 August 2015 at 13:04, Gregory P. Smith wrote:
>
>
> On Sun, Aug 9, 2015 at 3:25 PM Brett Cannon wrote:
>
>>
>> On Sun, Aug 9, 2015, 13:51 Peter Ludemann via Python-Dev <
>> python-dev@python.org> wrote:
>>
>> Most of my outputs are log messages, so this proposal won't help me
>> because (I presume) it does eager evaluation of the format string and the
>> logging methods are designed to do lazy evaluation. Python doesn't have
>> anything like Lisp's "special forms", so there doesn't seem to be a way to
>> implicitly put a lambda on the string to delay evaluation.
>>
>> It would be nice to be able to mark the formatting as lazy ... maybe
>> another string prefix character to indicate that? (And would the 2nd
>> expression in an assert statement be lazy or eager?)
>>
>>
>> That would require a lazy string type which is beyond the scope of this
>> PEP as proposed since it would require its own design choices, how much
>> code would not like the different type, etc.
>>
>> -Brett
>>
>
> Agreed that doesn't belong in PEP 498 or 501 itself... But it is a real
> need.
>
> We left logging behind when we added str.format() and adding yet another
> _third_ way to do string formatting without addressing the needs of
> deferred-formatting for things like logging is annoying.
>
> brainstorm: Imagine a deferred interpolation string with a d'' prefix..
> di'foo ${bar}' would be a new type with a __str__ method that also retains
> a runtime reference to the necessary values from the scope within which it
> was created that will be used for substitutions when iff/when it is
> __str__()ed. I still wouldn't enjoy reminding people to use di''
> inlogging.info(di'thing happened: ${result}') all the time any more than
> I like reminding people to undo their use of % and just pass the values as
> additional args to the logging call... But I think people would find it
> friendlier and thus be more likely to get it right on their own. logging's
> manually deferred % is an idiom i'd like to see wither away.
>
> There's also a performance aspect to any new formatter, % is oddly pretty
> fast, str.format isn't. So long as you can do stuff at compile time rather
> than runtime I think these PEPs could be even faster. Constant string
> pep-498 or pep-501 formatting could be broken down at compile time and
> composed into the optimal set of operations to build the resulting string /
> call the formatter.
>
> So far looking over both peps, I lean towards pep-501 rather than 498:
>
> I really prefer the ${} syntax.
> I don't like arbitrary logical expressions within strings.
> I dislike str only things without a similar concept for bytes.
>
> but neither quite suits me yet.
>
> 501's __interpolate*__ builtins are good and bad at the same time. doing
> this at the module level does seem right, i like the i18n use aspect of
> that, but you could also imagine these being methods so that subclasses
> could override the behavior on a per-type basis. but that probably only
> makes sense if a deferred type is created due to when and how interpolates
> would be called. also, adding builtins, even __ones__ annoys me for some
> reason I can't quite put my finger on.
>
> (jumping into the threads way late)
> -gps
>
>>
>> PS: As to Brett's comment about the history of string interpolation ...
>> my recollection/understanding is that it started with Unix shells and the
>> "$variable" notation, with the "$variable" being evaluated within "..." and
>> not within '...'. Perl, PHP, Make (and others) picked this up. There seems
>> to be a trend to avoid the bare "$variable" form and instead use
>> "${variable}" everywhere, mainly because "${...}" is sometimes required to
>> avoid ambiguities (e.g. "There were $NUMBER ${THING}s.")
>>
>> PPS: For anyone wishing to improve the existing format options, Common
>> Lisp's FORMAT
>> and Prolog's format/2
>>
>> have some capabilities that I miss from time to time in Python.
>>
>> On 9 August 2015 at 11:22, Eric V. Smith wrote:
>>
>> On 8/9/2015 1:38 PM, Brett Cannon wrote:
>> >
>> >
>> > On Sun, 9 Aug 2015 at 01:07 St
