[Python-Dev] SSH to hg.p.o okay?

[Steve Dower]

Is hg.python.org okay for others? I'm getting the following output from all hg 
commands:

sending hello command
sending between command
abort: no suitable response from remote hg!

I don't know of any more verbose or debugging options than that (--debug, -v's 
added nothing). I can SSH normally into hg.p.o, not that there's anything I can 
do without a terminal, but I guess it's not completely down...
___
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] SSH to hg.p.o okay?

[Eric V. Smith]

I was intermittently getting that earlier. I didn't change anything on my side 
and it started working, maybe 5 minutes later. 

--
Eric.

> On Aug 7, 2015, at 11:19 PM, Steve Dower  wrote:
> 
> Is hg.python.org okay for others? I'm getting the following output from all 
> hg commands:
> 
> sending hello command
> sending between command
> abort: no suitable response from remote hg!
> 
> I don't know of any more verbose or debugging options than that (--debug, 
> -v's added nothing). I can SSH normally into hg.p.o, not that there's 
> anything I can do without a terminal, but I guess it's not completely down...
> ___
> 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

[Nick Coghlan]

On 8 August 2015 at 11: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".

Thanks you for your work on this - it's a very cool concept!

I've also now written and posted an initial draft of PEP 500, based
directly on PEP 498, which formalises the "__interpolate__" builtin
idea I raised in those threads, along with a PEP 292 based syntax
proposal that aims to be as simple as possible for the simple case of
interpolating existing variables, while still allowing the use of
braces to permit embedding of arbitrary expressions and formatting
directives.

it turned out this approach provided an unanticipated benefit that I
only discovered while writing the PEP: by defining a separate
"__interpolateb__" builtin, it's straightforward to define binary
interpolation in terms of bytes.__mod__, while still defining text
interpolation in terms of str.format.

The previously-redundant-in-python-3 'u' prefix also finds new life as
a way of always requesting the default string interpolation, even if
__interpolate__ has been overridden in the current namespace to mean
something else (like il8n string translation).

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/archive%40mail-archive.com

Re: [Python-Dev] SSH to hg.p.o okay?

[Steve Dower]

Eventually I updated Mercurial and then it worked, but that didn't make a whole 
lot of sense. Maybe I caught it during some maintenance?

Seems to be okay now though.

Cheers,
Steve

Top-posted from my Windows Phone

From: Eric V. Smith
Sent: ‎8/‎8/‎2015 1:34
To: Steve Dower
Cc: python-dev@python.org
Subject: Re: [Python-Dev] SSH to hg.p.o okay?

I was intermittently getting that earlier. I didn't change anything on my side 
and it started working, maybe 5 minutes later.

--
Eric.

On Aug 7, 2015, at 11:19 PM, Steve Dower 
mailto:steve.do...@microsoft.com>> wrote:

Is 
hg.python.org
 okay for others? I'm getting the following output from all hg commands:

sending hello command
sending between command
abort: no suitable response from remote hg!

I don't know of any more verbose or debugging options than that (--debug, -v's 
added nothing). I can SSH normally into hg.p.o, not that there's anything I can 
do without a terminal, but I guess it's not completely down...
___
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] SSH to hg.p.o okay?

[Eric V. Smith]

On 8/8/2015 9:15 AM, Steve Dower wrote:
> Eventually I updated Mercurial and then it worked, but that didn't make
> a whole lot of sense. Maybe I caught it during some maintenance?
> 
> Seems to be okay now though.

I didn't make any changes on my end when it started working. I'm
guessing maintenance.

Eric.
___
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

[Alexander Walters]

Please do not change the meaning of the vestigial U''.  It was re-added 
to the language to fix a problem, rebinding it to another meaning 
introduces new problems.  We have plenty of other letters in the 
alphabet to use.


On 8/8/2015 05:34, Nick Coghlan wrote:

On 8 August 2015 at 11: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".

Thanks you for your work on this - it's a very cool concept!

I've also now written and posted an initial draft of PEP 500, based
directly on PEP 498, which formalises the "__interpolate__" builtin
idea I raised in those threads, along with a PEP 292 based syntax
proposal that aims to be as simple as possible for the simple case of
interpolating existing variables, while still allowing the use of
braces to permit embedding of arbitrary expressions and formatting
directives.

it turned out this approach provided an unanticipated benefit that I
only discovered while writing the PEP: by defining a separate
"__interpolateb__" builtin, it's straightforward to define binary
interpolation in terms of bytes.__mod__, while still defining text
interpolation in terms of str.format.

The previously-redundant-in-python-3 'u' prefix also finds new life as
a way of always requesting the default string interpolation, even if
__interpolate__ has been overridden in the current namespace to mean
something else (like il8n string translation).

Cheers,
Nick.



___
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

[Nick Coghlan]

On 9 August 2015 at 00:05, Alexander Walters  wrote:
> Please do not change the meaning of the vestigial U''.  It was re-added to
> the language to fix a problem, rebinding it to another meaning introduces
> new problems.  We have plenty of other letters in the alphabet to use.

It's actually being used in the same sense we already use it - I'm
just adding a new compile time use case where the distinction matters
again, which we haven't previously had in Python 3. (The usage in this
PEP is fairly closely analogous to WSGI's distinction between native
strings, text strings and binary strings, which matters for hybrid
Python 2/3 code, but not for pure Python 3 code)

It would certainly be *possible* to use a different character for that
aspect of the PEP, but it would be additional work without any obvious
gain.

Cheers,
Nick.

P.S. I hop on the plane for the US in a few hours, so I'll be aiming
to be bad at responding to emails until the 17th or so. We'll see how
well I stick to that plan :)

-- 
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/archive%40mail-archive.com

Re: [Python-Dev] PEP-498: Literal String Formatting

[Nick Coghlan]

On 8 August 2015 at 19:34, Nick Coghlan  wrote:
> On 8 August 2015 at 11: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".
>
> Thanks you for your work on this - it's a very cool concept!
>
> I've also now written and posted an initial draft of PEP 500,

I've actually moved this to PEP 501, for reasons of liking a proposed
alternate use of PEP 500 :)

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/archive%40mail-archive.com

Re: [Python-Dev] PEP-498: Literal String Formatting

[Alexander Walters]

... Its adding meaning to something that was intentionally meaningless.  
Not using u'' has the obvious, immediate benefit of not caring what u'' 
means in python 3, so one can continue to write polyglot code.  Since 
you are adding new semantics to python 3, use a different letter so that 
it just breaks in python 2, instead of having different meanings between 
versions.


Python 2 is still the dominant python.

On 8/8/2015 11:07, Nick Coghlan wrote:

On 9 August 2015 at 00:05, Alexander Walters  wrote:

Please do not change the meaning of the vestigial U''.  It was re-added to
the language to fix a problem, rebinding it to another meaning introduces
new problems.  We have plenty of other letters in the alphabet to use.

It's actually being used in the same sense we already use it - I'm
just adding a new compile time use case where the distinction matters
again, which we haven't previously had in Python 3. (The usage in this
PEP is fairly closely analogous to WSGI's distinction between native
strings, text strings and binary strings, which matters for hybrid
Python 2/3 code, but not for pure Python 3 code)

It would certainly be *possible* to use a different character for that
aspect of the PEP, but it would be additional work without any obvious
gain.

Cheers,
Nick.

P.S. I hop on the plane for the US in a few hours, so I'll be aiming
to be bad at responding to emails until the 17th or so. We'll see how
well I stick to that plan :)



___
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

[Alexander Walters]

Wait a second, the pep itself does not use the vestigial u''... it uses 
i''.  where did u'' come from?


On 8/8/2015 11:07, Nick Coghlan wrote:

On 9 August 2015 at 00:05, Alexander Walters  wrote:

Please do not change the meaning of the vestigial U''.  It was re-added to
the language to fix a problem, rebinding it to another meaning introduces
new problems.  We have plenty of other letters in the alphabet to use.

It's actually being used in the same sense we already use it - I'm
just adding a new compile time use case where the distinction matters
again, which we haven't previously had in Python 3. (The usage in this
PEP is fairly closely analogous to WSGI's distinction between native
strings, text strings and binary strings, which matters for hybrid
Python 2/3 code, but not for pure Python 3 code)

It would certainly be *possible* to use a different character for that
aspect of the PEP, but it would be additional work without any obvious
gain.

Cheers,
Nick.

P.S. I hop on the plane for the US in a few hours, so I'll be aiming
to be bad at responding to emails until the 17th or so. We'll see how
well I stick to that plan :)



___
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

[Nick Coghlan]

On 9 August 2015 at 01:16, Alexander Walters  wrote:
> Wait a second, the pep itself does not use the vestigial u''... it uses i''.
> where did u'' come from?

The only difference in the PEP is the fact that the iu"" variant calls
a different builtin (__interpolateu__ instead of __interpolate__).
There's no change to the semantics of u"" - those remain identical to
"".

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/archive%40mail-archive.com

Re: [Python-Dev] PEP-498: Literal String Formatting

[Alexander Walters]

As written in the pep, where i'' means 'I have the __interpolate__' 
method, and iu'' means 'i have the __interpolateu__' method (or that 
translators should call these methods), is fine, as the meaning of u ('I 
am unicode, yeah you already knew that') isn't changed.


On 8/8/2015 11:07, Nick Coghlan wrote:

On 9 August 2015 at 00:05, Alexander Walters  wrote:

Please do not change the meaning of the vestigial U''.  It was re-added to
the language to fix a problem, rebinding it to another meaning introduces
new problems.  We have plenty of other letters in the alphabet to use.

It's actually being used in the same sense we already use it - I'm
just adding a new compile time use case where the distinction matters
again, which we haven't previously had in Python 3. (The usage in this
PEP is fairly closely analogous to WSGI's distinction between native
strings, text strings and binary strings, which matters for hybrid
Python 2/3 code, but not for pure Python 3 code)

It would certainly be *possible* to use a different character for that
aspect of the PEP, but it would be additional work without any obvious
gain.

Cheers,
Nick.

P.S. I hop on the plane for the US in a few hours, so I'll be aiming
to be bad at responding to emails until the 17th or so. We'll see how
well I stick to that plan :)



___
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

[Brett Cannon]

Can the discussion of PEP 501 be done in a separate thread? As of right now
this thread has not been about PEP 498 beyond Eric's initial email.

On Sat, Aug 8, 2015 at 8:56 AM Alexander Walters 
wrote:

> As written in the pep, where i'' means 'I have the __interpolate__'
> method, and iu'' means 'i have the __interpolateu__' method (or that
> translators should call these methods), is fine, as the meaning of u ('I
> am unicode, yeah you already knew that') isn't changed.
>
> On 8/8/2015 11:07, Nick Coghlan wrote:
> > On 9 August 2015 at 00:05, Alexander Walters 
> wrote:
> >> Please do not change the meaning of the vestigial U''.  It was re-added
> to
> >> the language to fix a problem, rebinding it to another meaning
> introduces
> >> new problems.  We have plenty of other letters in the alphabet to use.
> > It's actually being used in the same sense we already use it - I'm
> > just adding a new compile time use case where the distinction matters
> > again, which we haven't previously had in Python 3. (The usage in this
> > PEP is fairly closely analogous to WSGI's distinction between native
> > strings, text strings and binary strings, which matters for hybrid
> > Python 2/3 code, but not for pure Python 3 code)
> >
> > It would certainly be *possible* to use a different character for that
> > aspect of the PEP, but it would be additional work without any obvious
> > gain.
> >
> > Cheers,
> > Nick.
> >
> > P.S. I hop on the plane for the US in a few hours, so I'll be aiming
> > to be bad at responding to emails until the 17th or so. We'll see how
> > well I stick to that plan :)
> >
>
> ___
> 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/brett%40python.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

[Brett Cannon]

On Fri, Aug 7, 2015 at 6:39 PM 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.
>

I fixed a grammar nit directly in the PEP, but otherwise I'm +1 on the
proposal.
___
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

[Tim Delaney]

On 8 August 2015 at 11: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.
>

I'd like to see an alternatives section, in particular listing alternative
prefixes and why they weren't chosen over f. Off the top of my head, ones
I've seen listed are:

!
$

Tim Delaney
___
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

[Raymond Hettinger]

> On Aug 7, 2015, at 6:39 PM, Eric V. Smith  wrote:
> 
> I'm open to any suggestions to improve the PEP. Thanks for your feedback.

Here's are few thoughts:

* I really like the reduction in verbosity for passing in the variable names.

* Because of my C background, I experience a little mental hiccup when using
  the f-prefix with the print() function:

 print(f"The answer is {answer}")

  wants to come out of my fingers as:

 printf("The answer is {answer}")

* It's unclear whether the string-to-expression-expansion should be arbitrarily
  limited to locals() and globals() or whether it should include __builtins__ 
and
  cell variables (closures and nested scopes).  Making it behave just like
  normal expressions means that there won't be new special cases to remember
  and that many existing calls to format() can be converted automatically:

w = 10
def f(x):
def g(y):
print(f'{len.__name__}{w}{x}{y}')

* Will this proposal complicate linters, analysis tools, highlighters, etc.?
   In a way, this isn't a small language extension, it is a whole new way
   to write expressions.

* Does it complicate situations where we would otherwise pass around
  templates as first class class objects (internationalization for example)?

 def welcome(name, title):
   print(_("Good morning {title} {name}"))   # expect gettext() 
substitution

* A related thought is that we normally like templates to live outside the 
  functions where they are used (separation of business logic and presentation
  logic).  Use of f-strings may impact our ability to refactor (move code up or
  down a chain of nested function calls), ability to pass in templates as 
arguments,
  storing templates in globals or thread locals so that they are shareable, or
  moving them out of our scripts and into files editable by non-programmers.

* With respect to learnability, the downside is that it becomes yet another 
thing
  to have to cover in a Python class (I'm already not looking forward teaching 
  star-unpacking generalizations and the restraint to not overuse them, and
  covering await, and single dispatch, etc, etc).  The upside is that templates
  themselves aren't being changed.  The only incremental learning task is the
  invocation becomes automatic, saving us a little typing.

The above above are random thoughts based a first quick read.  Don't take
them too seriously. Some are just shooting from the hip and are listed as food
for thought.


Raymond
  

___
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

[Nikolaus Rath]

On Aug 08 2015, Nick Coghlan  wrote:
> On 8 August 2015 at 11: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".
>
> Thanks you for your work on this - it's a very cool concept!
>
> I've also now written and posted an initial draft of PEP 500,
[...]

I think what that PEP really needs is a concise summary of the
*differences* to PEP 498. 

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«
___
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

[Nikolaus Rath]

On Aug 08 2015, Nikolaus Rath  wrote:
> On Aug 08 2015, Nick Coghlan  wrote:
>> On 8 August 2015 at 11: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".
>>
>> Thanks you for your work on this - it's a very cool concept!
>>
>> I've also now written and posted an initial draft of PEP 500,
> [...]
>
> I think what that PEP really needs is a concise summary of the
> *differences* to PEP 498.

I should probably elaborate on that.

After reading both PEPs, it seems to me that the only difference is that
you want to use a different prefix (i instead of f), use ${} instead of
{}, and call a builtin function to perform the interpolation (instead of
always using format). But is that really it? The PEP appears rather
long, so I'm not sure if I'm missing other differences in the parts that
seemed identical to PEP 498 to me.


Best,
-Nikolaus
-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«
___
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