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

2015-08-31 Thread Nick Coghlan 
On 30 August 2015 at 23:41, Eric V. Smith  wrote:
> Note there's a companion PEP 501 which extends this idea by delaying
> converting the expression into a string. This allows for more control
> over how the expressions are converted in to strings, and allows for
> non-string conversions as well.

For the benefit of folks that weren't following the (many) iterations
on python-ideas: PEP 501's general purpose string interpolation
started out as a competitor to 498, but as the discussion continued
and my ideas started to converge more and more with Eric's, I
eventually realised it made more sense as an optional extension to PEP
498 that exposed the inner workings of the scope aware interpolation
machinery to Python code.

As part of that, I'm +1 on PEP 498's literal string interpolation syntax.

Regards,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
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: Literal String Interpolation

2015-08-31 Thread Yury Selivanov 



On 2015-08-31 9:10 AM, Nick Coghlan wrote:

On 30 August 2015 at 23:41, Eric V. Smith  wrote:

Note there's a companion PEP 501 which extends this idea by delaying
converting the expression into a string. This allows for more control
over how the expressions are converted in to strings, and allows for
non-string conversions as well.

For the benefit of folks that weren't following the (many) iterations
on python-ideas: PEP 501's general purpose string interpolation
started out as a competitor to 498, but as the discussion continued
and my ideas started to converge more and more with Eric's, I
eventually realised it made more sense as an optional extension to PEP
498 that exposed the inner workings of the scope aware interpolation
machinery to Python code.


If PEP 501 is an extension to PEP 498, then the proposal
is to add i'' prefix *in addition* to f'', right?

If so, I think it might be confusing to a lot of people on
what prefix should be used and when.  I think it's too easy
for an average user to write ``os.system(f'...')`` and think
that their code is fine, instead of ``os.system(i'...')``.
What's worse, is that there is no way for ``os.system()``
to reject the former use.

Second, given that we use "f" for "formatted", using "i"
for "interpolated template" is a bit confusing.  Can
we use "t" ("template strings")?

Yury
___
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: Literal String Interpolation

2015-08-31 Thread Eric V. Smith 
On 8/31/2015 4:08 PM, Yury Selivanov wrote:
> 
> 
> On 2015-08-31 9:10 AM, Nick Coghlan wrote:
>> On 30 August 2015 at 23:41, Eric V. Smith  wrote:
>>> Note there's a companion PEP 501 which extends this idea by delaying
>>> converting the expression into a string. This allows for more control
>>> over how the expressions are converted in to strings, and allows for
>>> non-string conversions as well.
>> For the benefit of folks that weren't following the (many) iterations
>> on python-ideas: PEP 501's general purpose string interpolation
>> started out as a competitor to 498, but as the discussion continued
>> and my ideas started to converge more and more with Eric's, I
>> eventually realised it made more sense as an optional extension to PEP
>> 498 that exposed the inner workings of the scope aware interpolation
>> machinery to Python code.
> 
> If PEP 501 is an extension to PEP 498, then the proposal
> is to add i'' prefix *in addition* to f'', right?

That would be my intention, yes. Your only other choice to get plain
strings from a template would be to always say format(i'{expression}'),
which I don't think is an improvement.

> If so, I think it might be confusing to a lot of people on
> what prefix should be used and when.  I think it's too easy
> for an average user to write ``os.system(f'...')`` and think
> that their code is fine, instead of ``os.system(i'...')``.
> What's worse, is that there is no way for ``os.system()``
> to reject the former use.

That's all correct. I have to say that I like PEP 501 mainly for its
non-string use cases. That is, interpolators that don't produce strings.
Note that this isn't possible with PEP 502's proposal.

> Second, given that we use "f" for "formatted", using "i"
> for "interpolated template" is a bit confusing.  Can
> we use "t" ("template strings")?

I don't really care so much about the prefixes. I'd be okay with PEP 498
being either 'f', 'i', or 't'. I could warm up to 't' easier than 'i'.

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] ZIP File Instead of Installer

2015-08-31 Thread Steve Holden 
Hi Alex,

Thanks for your email, and the suggestion. A couple of things …

First, as webmaster we are simply volunteers who try to accept and process 
feedback *about the python.org  web site*. We aren’t 
(mostly) actively involved in the development of the language, though we are 
all dedicated users - most of us either don’t have tie to take part in 
python-dev or feel we have already put our time in. So this isn’t the best 
channel for the particular inout you’re making.

Second, while it’s practical to put *most* of the stdlib in a zip file it may 
be impractical to put them *all* in there. I did some experiments (admittedly 
about eight years ago, so things may have changed) to enable an import 
mechanism that imported code from a relational database. Naturally there were 
modules that had to be loaded using the standard mechanisms - the ones I needed 
to import to enable my database imports! It’s a classical bootstrap problem.

Third, your idea would need considerable expansion before being actionable: 
consider the fact that there are millions of downloads of Python every month. 
Obviously there is huge amount of engineering detail to consider before 
releasing anything new - if an error only occurs one time in 100,000 that will 
lead to a substantial number of bug reports, so the dev tend to proceed fairly 
carefully and with much deliberation.

Fourth, I really like it that you are enthusiastic about Python, and would 
suggest you consider joining the python-dev mailing list. Start as a lurker, 
just reading what is said, and (since you are obviously thinking a lot as you 
learn Python) you will be surprised how much you pick up. The people on that 
list aren’t gods, they are just regular developers who happen to commit a lot 
of their time to Python’s development, and they rely on a continuous influx of 
new blood. So as long as you take your time getting to know the personalities 
involved and how the list works you are likely to find a welcome there. The day 
will arrive when you realize that rather to your surprise you have something to 
contribute.

There’s also the python-ideas list and, if you are nervous about just diving 
straight into python-dev, there’s the python-mentor list that was specifically 
designed to provide a sympathetic and uncritical response to enthusiasm such as 
you exhibit.

The caveat in all this is that as an old fart I haven’t actually been active on 
any of those lists for quite a while, so I am unsure how active they all are.

I hope this response is helpful. I’ve invested a lot of time in trying to make 
the Python ecosystem one that welcomes enthusiasm and energy, and lot of other 
people do the same, many of them more effectively than me. It seems to me that 
you have both enthusiasm and energy, which is why I’ve taken the time to 
encourage you to put it to use.

Good luck in your progress with Python.

regards
 Steve

PS: The mailing lists are all detailed on 
https://mail.python.org/mailman/listinfo 


> On Aug 31, 2015, at 9:48 PM, Alex Huffstetler  wrote:
> 
> I have an idea. I had a problem with installing Python because I’m not an 
> admin.
> My idea is you delete the installer and put all the files in a ZIP folder. It 
> can make download time faster.
> Also, I made the Python logo out off underscores and pipes.
> If it dosen’t look right, put it somewhere on the Internet and it’ll look 
> right.
>   _
>  | . |
> ___|___   |
> ||   |
> | _|   |
> ||   |
> |___|___|
>  | . |
>  |_|

-- 
Steve Holden [email protected] / +44 208 289 6308 / @holdenweb





___
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: Literal String Interpolation

2015-08-31 Thread Eric V. Smith 
On 8/31/2015 5:07 PM, Eric V. Smith wrote:
> That's all correct. I have to say that I like PEP 501 mainly for its
> non-string use cases. That is, interpolators that don't produce strings.
> Note that this isn't possible with PEP 502's proposal.

Let me rephrase that: with PEP 502, it must be possible to produce a
string from every e-string (as they're called there), and since
types.ExpressionString derives from str, it's even easier to misuse them
as strings and not provide the correct interpolator. This is as opposed
to PEP 501, where the equivalent type is not derived from str, and you
must call format() or a custom interpolator to get a str.

But back to PEP 498: I can't imagine accepting either PEP 501 or 502
without also accepting PEP 498. And once you've accepted 498, are i- or
e-strings sufficiently powerful and useful enough, and are they likely
to be used in the correct way? I think that's the question.

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: Literal String Interpolation

2015-08-31 Thread Nick Coghlan 
On 1 Sep 2015 07:35, "Eric V. Smith"  wrote:
>
> But back to PEP 498: I can't imagine accepting either PEP 501 or 502
> without also accepting PEP 498. And once you've accepted 498, are i- or
> e-strings sufficiently powerful and useful enough, and are they likely
> to be used in the correct way? I think that's the question.

Exactly, 498 should now be considered independently, with 501 & 502 as
potential answers to questions like:

* how can we mitigate the increased risk of code injection vulnerabilities
that comes with native interpolation support?
* how can we handle cases where delaying interpolation would be helpful,
like event logging or i18n?
* how can we support adaptation of the interpolation syntax to cases like
SQL Alchemy's "text" API, which consumes an SQL expression in text form and
converts it to SQL Alchemy objects?

Writing 501 has satisfied me that those questions *can* be addressed, *if*
we decide they should be, and that it can be done in such a way that it can
be presented to folks learning Python in the future as an implementation
detail of the native string formatting support (that is, folks would be
taught formatted strings early, and only later be taught that you can use
an interpolation template to split up the template interpolation and
template rendering steps.

That all adds up to thinking it's fine to defer answering those questions
to later, rather than expecting 498 to address them immediately. We have
plenty of time until 3.6 rolls around :)

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