[Python-ideas] Re: Template Literals for Python (easy and save creation of HTML)

[Thomas Güttler]

Am Fr., 3. Sept. 2021 um 16:53 Uhr schrieb Damian Shaw <
damian.peter.s...@gmail.com>:

> I am not convinced of tying `backticks` for a single markup language.
> Different markup languages presumably have different escape methods? Is
> Python supposed to be explicitly an HTML based language like many of the
> design choices of JavaScript?
>
>
My proposal does not suppose that Python will get explicitly an HTML based
language. I am sorry if you understood this.

Template Literals can be used for any sort of use case. My use case is
HTML. The PEP uses HTML as an example. But the implementation
would not be about HTML at all. Any kind of escaping could be done. This is
up to the user of the Template Literals.



> It also seems like a lot to ask to introduce yet another way of quoting
> strings which doesn't fit with the existing pattern of string quoting.
> Python already has single quotes, double quotes, triple single quotes,
> triple double quotes, and all of these can have an r or f placed in front
> of them to modify their behavior.
>
> I see you have a section on not using the "i" prefix, but I don't
> understand the sentence "This is an handy feature, which would not work
> reliably if there are two different prefixes". What is it trying to say?
> What would not work reliably and why?
>
>
Some lines above your quote I wrote:

"Some IDEs detect that you want use a f-string automtically".

At the moment there is only the "f" prefix. The automatic detection would
not work anymore if there would be two prefixes.
Please speak up again, if you need further explanation.



> I would like to see this PEP have a section on handling security, this PEP
> implies the Python standard library will safely escape HTML for you which
> presumably has security implications? And a section on how it will be
> updated when/if the HTML specification gets updated that may introduce new
> ways HTML can/must be escaped. And a section on what are the valid versions
> of HTML it supports? HTML5 only or does it explicitly support older
> versions of HTML?
>
>
Thank you very much!

That's a good point. I updated the PEP:

{{{
Out of scope: Save escaping of HTML
===

Template Literals are about creating a data structure.

The user of Template Literals could use this data structure for any fancy
kind
of computation.

We estimate most users will use the data structure to create HTML.

Nevertheless, how the user processes the data strucure is up to the user.

Escaping HTML and related security implications are out of scope of this
PEP.

}}}

What do you think about this section. Do you agree? If not, then please
speak up and tell
me what's wrong.

Thank you for your feedback!

  Thomas

>
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EFKYD22FWSIS3WDRD4JWNCW64ZIQFEPN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Template Literals for Python (easy and save creation of HTML)

[Thomas Güttler]

Some weeks ago I started the idea of Template Literals for Python:

https://github.com/guettli/peps/blob/master/pep-.rst

I just switched to a new company (descript.de) and diving into their context
will need some time.

This means I won't work on the Template Literals PEP.

If you like the idea, then it would be great if you work on it.

Regards,
  Thomas
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/BZWBK2PFBFUXU5PEP7UZORHL23RQVHE4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Looking for a PEP sponsor

[Thomas Güttler]

Am Mi., 14. Juli 2021 um 19:56 Uhr schrieb Bruce Leban :

> On Wed, Jul 14, 2021 at 8:50 AM Nick Humrich  wrote:
>
>>
>>
[cut]


>  At the very least your PEP should discuss the alternatives such as
>>
>
> f"{!!html}..."   # html escapes every string before inserting
> f"{!!foobar}..." # applies the function 'foobar' to every string
> before inserting
> f"...{url!!foobar}"  # applies the function 'foobar' to this string value
>
> and any others that have been proposed and weigh the pros and cons.
>
>
>
These "!!" look like Perl to me. I hope we find a neat and clean syntax.

Regards,
  Thomas
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/V2PR7PYP374WK4W4MKGE6POQ3BB7FAAQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: writelines2?

[Thomas Güttler]

Am Di., 13. Juli 2021 um 15:02 Uhr schrieb :

> Right now, writelines is a very big misnomer to many python developers,
> especially beginners who would expect writelines to put new lines at the
> end of every element in the list
>
> My suggestion is to have either a writelines2 or a newline kwarg which
> does put new lines automatically at the end of every line written
>
>
I like the idea of having a kwarg for writelines
.

Do you want a boolean like "append_newlines=True" or a string like
"append_string='\n'"

Regards,
  Thomas
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/KXJD6XCKV3AMUQMDRL2RVFLMV76KXRFQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

[Thomas Güttler]

Am Fr., 2. Juli 2021 um 12:06 Uhr schrieb Nick Coghlan :

>
>
> On Fri, 2 Jul 2021, 5:12 pm Thomas Güttler, 
> wrote:
>
>> Hi Nick and all other Python ideas friends,
>>
>> yes, you are right. There is not much difference between PEP-501 or my
>> proposal.
>>
>> One argument why I would like to prefer backticks:
>>
>> Some IDEs detect that you want to use a f-string automatically:
>>
>> You type:
>>
>> name = 'Peter'
>> print('Hello {name...
>>
>> and the IDE automatically adds the missing "f" in front of the string:
>>
>> name = 'Peter'
>> print(f'Hello {name...
>>
>> This is a handy feature (of PyCharm), which would not work reliably if
>> there are two different prefixes.
>>
>> ---
>>
>> You mentioned these things:
>>
>> eager rendering: I think deferred rendering would increase the complexity
>> a lot. And I think it is not needed.
>>
>
> Eager rendering is f-strings. Any templating proposal necessarily involves
> a delayed rendering step, when the template is combined with the
> interpolated values.
>
> runtime value interpolation: It is up to the receiver of
>> types.InterpolationTemplate to handle the data structure.
>>
>
> I really meant runtime template parsing here (i.e. str.format).
>
>
> dedicated templating libraries: One temp after the other. I think HTML and
>> SQL libraries would adapt as soon as the foundation
>> is available.
>>
>
> The existence of i-strings likely wouldn't change the syntax of jinja2
> templates, Django templates, SQL Alchemy, pandas, etc.
>
> I would be happy if PEP-501 would come true.
>>
>
> So would I, but I still don't have a compelling answer to the "but it's
> yet another subtly different way to do it" objection.
>


Today I read the replies to this thread again.

Of course there where some "-1" replies, but overall there was positive
feedback.

Today I played with template literals from Javascript:

[image: image.png]

I like it.

Nick, would you be open to adapting to the JS syntax for PEP-501?

I propose `...{var} ...`

This means backticks, but without the dollar sign.

I would make it like in JS: The string in backticks can span several lines.

So what is the next step now?

Regards,
  Thomas
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NRJ7NBRF6KTFWP6SFQLH4FIEK3P2W2AT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

[Thomas Güttler]

Hi Nick and all other Python ideas friends,

yes, you are right. There is not much difference between PEP-501 or my
proposal.

One argument why I would like to prefer backticks:

Some IDEs detect that you want to use a f-string automatically:

You type:

name = 'Peter'
print('Hello {name...

and the IDE automatically adds the missing "f" in front of the string:

name = 'Peter'
print(f'Hello {name...

This is a handy feature (of PyCharm), which would not work reliably if
there are two different prefixes.

---

You mentioned these things:

eager rendering: I think deferred rendering would increase the complexity a
lot. And I think it is not needed.

runtime value interpolation: It is up to the receiver of
types.InterpolationTemplate to handle the data structure.

dedicated templating libraries: One temp after the other. I think HTML and
SQL libraries would adapt as soon as the foundation
is available.

I would be happy if PEP-501 would come true.

Regards,
  Thomas Güttler

Am So., 27. Juni 2021 um 06:45 Uhr schrieb Nick Coghlan :

> Stephen J. Turnbull wrote:
> > But a
> > PEP 501 i-string "just works" nicely:
> > load_warning = i'Load is too high: {load}'
> > while (theres_work_to_do_matey):
> > if load > max_load:
> > logging.warn(load_warning)
> > (This assumes a future version of logging.warn that calls str() on the
> > first argument if it is an InterpolationTemplate.)
>
> A "Why this rather than PEP 501's interpolation templates?" is the main
> thing I was looking for in the PEP and I didn't find it.
>
> If the proposal is just a variant on PEP 501 with the syntax changed from
> i"template" to \`template\` and the template type name changed from
> InterpolationTemplate to TemplateLiteral, it doesn't need to be a new PEP,
> I can just explicitly reject those spelling options in PEP 501. (The
> reasons for that PEP's deferral unfortunately still hold, though - eager
> rendering, runtime value interpolation, and dedicated templating libraries
> together cover enough cases that the motivation for introducing the
> semantic complexity of yet another templating option gets weakened
> dramatically).
>
> If the differences between the proposals run deeper than that, then the
> proposed new PEP needs to spell them out.
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/XSGJO3VX3HBSGESRUFDTMI2LTJFNRY66/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/O6H6NLNJJDNUUDXREIURHVCXX4ZNBYAW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

[Thomas Güttler]

Am Mo., 14. Juni 2021 um 01:25 Uhr schrieb Chris Angelico :

>
> I'd love to have some sort of generic interpolation construct, but the
> use-cases all seem really weak...
>
>
It depends on your daily work. If you create many small methods returning
small HTML fragments,
then it really helps if you can avoid some extra typing. But maybe it is
not about typing.
Maybe it is about reading. Passing variables via `foo=foo, bar=bar`
contains no value.
This means your eyes need to parse information which has little value. I
would like to
avoid that.

f-strings are great. Unfortunately they do too much.

Regards,
  Thomas
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IXVIRB75RT6ISETC5GS7STULJ3DOXWYE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

[Thomas Güttler]

Am Mo., 14. Juni 2021 um 11:12 Uhr schrieb J. Pic :

> On Thu, Jun 10, 2021 at 8:34 AM Thomas Güttler 
> wrote:
>
>>
>> This solution has two drawbacks:
>>
>>1. It is too verbose. Typing "conditional_escape(...)" again and
>>again is cumbersome.
>>
>> from django import conditional_espace as esc
> f'''
> Hi {esc(name)}
> Your messages: {esc(messages)}
> '''
>
>>
>>1. If a conditional_escape() gets forgotten Cross-site scripting
>>attacks could be possible, since malicious users could inject HTML.
>>
>> This is specific to Django and other frameworks out there which accept
> anything as user input by default, that's an anti-pattern which OWASP
> recommends against because obviously it opens a wide range of attack
> vectors, absolutely no security audit would ever validate the default
> validation of a CharField or a TextField.
>
>
You are right. Validating user input is an important topic. But it is a
different topic, which should be discussed at a different time.



> Another problem I see with this proposal is how do you actually use safe
> HTML in variables?
>
> msgs = [f'{msg}' for msg in messages]
> f'''
> Hi {name}
> Your messages: {msgs}
> '''
>
> Will output:
>
> Hi Your name
> Your messages: <li>Your message</li>
>
> Instead of what we would want in this situation:
>
> Hi Your name
> Your messages: Your message
>
> Otherwise good idea, it's an issue we have, even though the first
> immediate fix needed is Django's default input validation which is just
> openbar.
>

Thank you for your feedback James.

The "magic" is done in conditional_escape():
https://github.com/django/django/blob/824981b2dc61a76a59d0e470bed6e61626a44ccf/django/utils/html.py#L92

I updated the PEP so that it contains a hyperlink to the github repo.

Regards,
  Thomas
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/U5FB7XCLWD6FIZTW6WIDSZQWM4CZLESH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

[Thomas Güttler]

Am Fr., 11. Juni 2021 um 14:51 Uhr schrieb Ricky Teachey :

> I think this idea is promising but instead of doing it by adding new
> syntax and a totally different object, why not attach a __templates__
> dunder member to every string but only OPTIONALLY populate it when a string
> is formatted?
>
>
I am very happy that you think this is promising.

Changing the interface of every string in Python feels much too big for me.
I don't dare to think about it.
I have concerns that it could have negative impacts on parts which I am not
aware of.



> For every regular string it would just be None:
>
>  >>> "".__template__
>  >>>
>
> But if you create a string using an f string, you can provide a directive,
> as part of the format specification mini language, to store it:
>
>  >>> s = f"{foo!t}"
>
> ...or a directive at the front of the string to store all the f string
> arguments:
>
>  >>> s = ft"{foo}"
>
> This would save the values marked for storage as a tuple of Template
> arguments in the __templates__ member for later. It may also be desirable
> for the Template object to store the name foo and the position in the
> string the foo object was formatted.
>
>
The "t" prefix makes sense.

I would reduce it from ft'...' to t'...'. But it looks good. This is in the
"alternatives":
https://github.com/guettli/peps/blob/master/pep-.rst#alternative-ideas

I am happy with backticks and/or t'...'. Backticks look a bit "cleaner" to
my eyes, but I
am fine with the "t" prefix, too.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XYGGM6O5YMFLNOY4ADCTNFUJIUCQN5PV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

[Thomas Güttler]

Am Fr., 11. Juni 2021 um 11:10 Uhr schrieb Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp>:

> Thomas Güttler writes:
>  > Am Fr., 11. Juni 2021 um 03:17 Uhr schrieb Stephan Hoyer <
> sho...@gmail.com>:
>
>  > > Unevaluated f-strings is a nice way to think about this
>  > > functionality.
>
> But they're not "unevaluated" in a lot of important ways.  A better
> term might be "pre-assembled". :-)
>
>  > > Another use-case that comes to mind is logging. The Google Python
> style
>  > > guide says not to use f-strings, for example, because it wants to be
> able
>  > > to collect the unexpanded pattern strings and not waste time rendering
>  > > unlogged messages:
>  > > https://google.github.io/styleguide/pyguide.html#3101-logging
>  >
>  > Thank you Stephan for this feedback. I added Logging to the draft:
>  > https://github.com/guettli/peps/blob/master/pep-.rst#logging
>
> If this does solve the logging problem, it would be a killer app (but
> that still might not be enough, given that PEP 501 couldn't clear the
> bar and logging was a leading application for that PEP).  Perhaps you
> should focus on that rather than the HTML escaping problem.
>
>
Hi Stephen,

I can't solve a problem which I don't know. Logging plays no big role
in my development tasks any more. I use checks, metrics and sentry.
In the past logging was important for me, but this changed.

But I am sure that the proposal can be used to improve logging.

Regards,
  Thomas
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YEYP2POOB5S5DULJKIQKB3O75RBWUM7Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

[Thomas Güttler]

Am Do., 10. Juni 2021 um 17:56 Uhr schrieb Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp>:

> Thomas Güttler writes:
>
>  > This really helps developers to avoid cross-site-scripting attacks
>  > by enabling a secure escaping of all strings which are not
>  > explicitly marked as safe.
>
> Frameworks can already do this by unconditionally applying a function
> like conditional_escape to all evaluated template variables.  (If
> that's too drastic for your taste, there could be a pragma
> %conditional_escape_everything to turn it on.)  Why don't they?  If
> it's not "they just didn't think of it", and there's a real reason,
> why doesn't that reason apply to your template literals?
>
>
I don't understand what you mean with "pragma
%conditional_escape_everything".
Could you please elaborate?




> Note that str has no "safe" attribute, and attributes defined by a
> framework are not known to Python.  You need to explain how you can
> Python-evaluate an expression to a str as your template literal does,
> and still preserve the "safe" mark that I presume is an attribute of a
> class defined by the framework.
>
>
That "safe" attribute is outside the scope of the PEP.

At least in Django there is a way to handle this.


I guess the problem of accessing the framework's attribute can be
> solved by delegating that to the __format__ method of the framework
> type, and maybe preserving it can be handled by having that __format__
> method return a subclass of str.
>
>



> But this reintroduces a strong possibility of programmer error,
> because any function that constructs and returns a new str will strip
> the "safe" mark.  This happens *before* the __format__ method can be
> invoked -- str's __format__ does not check for a safe mark -- so it's
> a real problem.


In Django this is solved via mark_safe(), conditional_escape() and
fomat_html().



> This might dramatically reduce the utility of these
> template literals because it's simply not safe to allow the full range
> of expressions that f-strings allow.  (That could be a YAGNI, but you
> need to explain and if possible document that.)  Also, this means that
> frameworks can no longer just inherit from str: they need to
> reimplement literally every method that returns str, or prohibit its
> use in templates.
>
> Note that 'is_literal' is not the same as "safe".  Based on the
> example, this is intentional: is_literal simply means that this isn't
> the value of an expression, simplifying implementation of the internal
> function that evaluates the template string to a TemplateLiteral.  But
> this means that the function joining a TemplateLiteral needs to
> consider both is_literal (which is safe but apparently unmarked) and
> the 'safe' attribute.  This seems more complicated than it needs to
> be.
>
>
conditional_escape() escapes everything which is not marked "safe".
The body of the template is considered safe.

Please provide an example how to simplify
`template_literal_to_safestring()` of
the draft:
https://github.com/guettli/peps/blob/master/pep-.rst#specification




> TemplateLiteral is not a good name for that type.  The backtick
> construct is a literal (except it's really not ;-), the
> TemplateLiteral is a constructed value.  TemplateValue or
> TemplateTokenSequence or something like that might be a better name.
> In any case it's a little confusing that both the syntax and the value
> are called "literal".  It's not impossible to understand, but at least
> for me I have to think "is this the syntax or is this an object?"
> every time I see it.
>
>
Thank you for the idea for alternative names. I added them
to the PEP. I am open, and think that finding the right name
is important.

I guess the average user won't notice the word "literal" at all.

He/she will see: `Hello {name}` is the way to create
a HTML fragment and he/she will do so.


Thank you for your feedback,
  Thomas
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/LJWBFYHK4GDF35C65YXLCBGC4QQDZCR7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

[Thomas Güttler]

Am Fr., 11. Juni 2021 um 03:17 Uhr schrieb Stephan Hoyer :

> On Thu, Jun 10, 2021 at 7:10 AM Chris Angelico  wrote:
>
>> This proposal is basically for a way to take an f-string-like
>> construct and, instead of calling format() on each of the values and
>> joining them together into a string, you do something else with it. Or
>> from a language perspective, you package it all up and hand it to a
>> custom function.
>>
>> So it's basically an f-string minus the final step - which is why PEP
>> 501 described f-strings in terms of interpolated strings.
>>
>
> Unevaluated f-strings is a nice way to think about this functionality.
>
> Another use-case that comes to mind is logging. The Google Python style
> guide says not to use f-strings, for example, because it wants to be able
> to collect the unexpanded pattern strings and not waste time rendering
> unlogged messages:
> https://google.github.io/styleguide/pyguide.html#3101-logging
>


Thank you Stephan for this feedback. I added Logging to the draft:
https://github.com/guettli/peps/blob/master/pep-.rst#logging

Regards,
  Thomas
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SNVRBK645PHEVBPNZI4OULLWXP37C54P/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

[Thomas Güttler]

Am Fr., 11. Juni 2021 um 00:10 Uhr schrieb Christopher Barker <
python...@gmail.com>:

> There may well be use cases for this, but one thing struck me. From the
> PEP:
>
> "Template Literals provide an easy way to access the local and global
> variables (like f-strings), so that passing a dictionary to the Template is
> not necessary."
>
> This seems to be crossing the line between "data" and "code" -- that's a
> line that can get pretty fuzzy in Python, but it's still a distinction I
> find helpful to think about.
>
> f-strings provide an easy way to build strings with stuff stored in code:
> local variables. This makes them very helpful for things like building
> Exception messages and the like, or showing the results of computation.
>
> But for the most part, populating a template is likely to be done from
> data, rather than code -- results of a database query, or what have you. So
> this kind of template building is usually very well suited to passing a
> dictionary around, rather than using the local namespace.
>
>
If you don't create HTML with Python daily, then you might not feel the
pain.

If you create many HTML strings daily, then you will be typing `foo=foo,
bar=bar` (to pass the variables
into the template) over and over again.

I would reduce cognitive load if you could avoid reading/writing `foo=foo,
bar=bar`.

My goal is to have a super reduced syntax, so that developers need only a
few characters
to create save (properly escaped) html with Python.

In the past people created whole HTML pages. There it made sense to use a
template language.

But if you use FrOW, then you will create many small methods returning
small fragments, and
then this small extra work of passing in variables gets  (please insert
your favorite negative  adjective).

Back your point "data vs code".

The new class types.TemplateLiteral is pure data. It is up to the consumer
to process the data.

Of course I am biased, since my main concern is creating HTML. But I guess
there are several other
use-cases where a TemplateLiteral could be used.



> Even if you are using Python objects to model your data (e.g. dataclasses
> and the like) -- you still have:
> a) one object to pass in to your template builder
> and/or
> b) an easy way to make a dict out of the object to pass into a template.
>
> I could be missing something, but I just don't see the benefits of having
> f-string like access to local variables in this context.
>
> -CHB
>
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/3PFAMX2GDHUB4UUSXVNTBSGPUSHIVGPA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

[Thomas Güttler]

Am Do., 10. Juni 2021 um 16:04 Uhr schrieb Chris Angelico :

> On Thu, Jun 10, 2021 at 11:50 PM Thomas Güttler 
> wrote:
> >
> What's the advantage of htmx? When I want to build a good interactive
> web site, my general pattern is a back end with a well-defined API,
> and a front end in JavaScript that makes use of this API. That API is
> usually going to be based on either a RESTful (or roughly REST-like)
> JSON transactional system, or something like websockets, again
> carrying JSON payloads. HTML is the realm of the display, not the back
> end.
>
>
It depends on the use-case. If you want to create a "real" application like
gmail, then
it is ok to let the user wait 3 seconds until the page is loaded.

But if you want your page to load fast, then the current best practice is
server-side-rendering.

I personally was a big fan of the "backend for frontend" solutions like
GraphQL. But my mind
changed. I prefer SQL+ORM and server side rendering today.
HTMX gives you a way to create fast loading pages which are interactive.

If you write many small methods returning small html snippets, then a
f-string like solution
with conditional_escape() support would be super cool.

I held a talk about htmx at DjangoCon EU, here are the slides:
https://docs.google.com/presentation/d/1Gx1UGVAgD2ALLOucsIm9myF5mDflbP06-M6_d-RdZAY/edit#slide=id.p

But this is getting off-topic.

Regards,
  Thomas Güttler
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/FSW3HWXGCIK54ESCOBBZH7QX6GXU4JVU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

[Thomas Güttler]

Am Do., 10. Juni 2021 um 15:48 Uhr schrieb Felipe Rodrigues <
fel...@felipevr.com>:

> Well, I share Rob's concern but I do see the point of this:
>
> > Template Literals only make sense if you want to escape values like in
> HTML, XML or SQL templates.
>
> Maybe they should have a name to better reflect this intended use case?
> Safe Templates, Escaped Strings, I don't know, I'm terrible at naming
> things but I do think this would be a nice modification.
>
>>
>>
 Thank you Felipe for looking into this. Yes, you are right. A better
heading might make sense.

I just copied the name (Template Literals) from JavaScript.

I am not good at naming either.

Maybe someone else has an idea how to name this?

Regards,
  Thomas
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RERKZZZY2HBFZ5XUTXV5H7H5XZLSHESO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

[Thomas Güttler]

Am Do., 10. Juni 2021 um 15:33 Uhr schrieb David Mertz :

> Strong -1
>
> As others noted in prior discussion, even if this existed, it works be an
> anti-pattern for SQL. So basically, it's just baking in an HTML-only
> template language into the language syntax.
>
> Python already had excellent HTML templating in libraries. The fact Django
> has a function with a long name just suggests importing it with a shorter
> name.
>
>


> Python has many uses having nothing to do with web pages. This could make
> sense for PHP (does anyone use that still?). It's a poor for for Python.
>

PHP is very productive. The majority of sites are written in PHP.

The only thing which PHP has not: Respect.

It does not get respect since it is too easy.

Python is getting pushed into the backend during the last years, while web
frontend is mostly done in Javascript.

I think this is the wrong direction.

Together with tools like htmx (fragments over the wire), I would rather
choose PHP than Javascript.

PHP is great for creating HTML. I know that the easy solution does not get
much respect,
but maybe you understand that making it easy to create HTML would be a
major benefit for Python.

Regards,
  Thomas
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SYBCB36TRONZ4VXTSU6PDM5SNZWLZUVA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Pre PEP: Python Literals (was custom strings before)

[Thomas Güttler]

Am Do., 10. Juni 2021 um 14:42 Uhr schrieb Rob Cliffe via Python-ideas <
python-ideas@python.org>:

> I am concerned that we have too many string formatting methods:
> % formatting
> .format()
> f-strings
> string templates
> (are there others I've missed?).
> And now we have another proposed one.
> It's all getting a bit much.  And IMO a turnoff for people learning Python
> (which one should I use, and why?).
> Best wishes
> Rob Cliffe
>

I can feel with you. There are some new things in Python which make it
harder to learn. I personally
don't see a need for the walrus operator.

But on the other hand you can't compare Template Literals with normal
string handling.

This really helps developers to avoid cross-site-scripting attacks by
enabling a secure
escaping of all strings which are not explicitly marked as safe.

 Template Literals only make sense if you want to escape values like in
HTML, XML or SQL templates.

Regards,
  Thomas
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/EYO6IZIJXVJZLZ5CVBVZR2PE574Y6Z4G/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Pre PEP: Python Literals (was custom strings before)

[Thomas Güttler]

Thank you Guido, Chris, Matt and Richard for your feedback to my last email.

Here is an updated version called "Template Literals".

I am looking for a core developer who can sponsor this PEP.

Please speak up if you want to help me.

Regards,
  Thomas Güttler

Source and updates: Pre-PEP 
<https://github.com/guettli/peps/blob/master/pep-.rst>

PEP: 
Title: Template Literals
Author: Thomas Güttler 
Sponsor: TODO
Status: Draft
Type: Standards Track
Content-Type: text/x-rst 
Created: 08-Jun-2021
Python-Version: TODO
Post-History: 08-Jun-2021
--

Contents

   - Abstract <#abstract>
   - Motivation <#motivation>
   - Rationale <#rationale>
   - Specification <#specification>
   - Security Implications <#security-implications>
   - Reference Implementation <#reference-implementation>
   - Alternative Ideas <#alternative-ideas>
   - Rejected Ideas <#rejected-ideas>
   - Open Issues <#open-issues>
   - References <#references>
   - Copyright <#copyright>

Abstract <#id6>

This PEP adds Template Literals to Python.

To avoid code injection like XSS or SQL-injection Template Literals can
help you to write save Python code.

Template Literals provide an easy way to access the local and global
variables (like f-strings), so that passing a dictionary to the Template is
not necessary.
Motivation <#id7>

In the context of web development Python can do more than providing REST
APIs via http. With the trend to Server-Side-Rendering, we face a
fundamental question:

How to create HTML with Python?

If you use the FrOW pattern (HTML fragments over the wire) [1] <#frow>,
then you will be writing small methods returning small HTML fragments.

As a developer I want to pass escaped data into template literals to be as
simple as possible.
Rationale <#id8>

Imagine you want to create a small HTML fragment in Python, and return it
as HTTP-Response:

   HttpResponse(f'''
Hi {name}
Your messages: {messages}''')

The problem in above example is, that no escaping gets done.

In above example "name" and "messages" should be treated differently.

The variable "name" should get escaped. For example if the name is "Mary &
Bob", the result should be "Mary & Bob".

The variable "messages" contains HTML which is already escaped. It should
not be escaped again.

Most frameworks have a way to do this conditional escaping.

For example Django uses conditional_escape()
<https://docs.djangoproject.com/en/3.2/ref/utils/#django.utils.html.conditional_escape>
 [2] <#id2>

With the help of conditional_escape() the above problem could be solved
like this:

HttpResponse(f'''
Hi {conditional_escape(name)}
Your messages: {conditional_escape(messages)}''')

This solution has two drawbacks:

   1. It is too verbose. Typing "conditional_escape(...)" again and again
   is cumbersome.
   2. If a conditional_escape() gets forgotten Cross-site scripting attacks
   could be possible, since malicious users could inject HTML.

Specification <#id9>

Template Literals use backticks (like JavaScript Template Literals
<https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals>
 [3] <#id4>)

Example:

name = 'Mary & Bob'
messages = `message1message2`
return HttpResponse(`
Hi {name}
Your messages: {messages}

Today: {datetime.date.today()}`)

Expressions within curly braces get handled liked in f-strings (PEP-498).

The Template Literal creates an instance of the new class
types.TemplateLiteral.

types.TemplateLiteral has two attributes:

   - template: The raw string inside the backticks.
   - tokens: A list of tuples: (value, is_literal).

For above example this would mean:

template = '''
Hi {name}
Your messages: {messages}

Today: {datetime.date.today()}'''

tokens = [
('\nHi ', True),
('Mary & Bob', False),
('\nYour messages: ', True),
(message1message2">, False),
('\n\nToday: ', True),
(, False)
]

It is outside this PEP how a consumer of TemplateLiteral handles this data
structure.

For example the Django web framework could transform a TemplateLiteral to a
SafeString like this:

def template_literal_to_safestring(template_literal):
return mark_safe(
''.join(
[
conditional_escape(value) if not is_literal else value
for (value, is_literal) in template_literal.tokens
]
)
)

This PEP is not related or constraint to the Django framework. It is even
not related to HTML. It can be used for any kind of templating.
Security Implications <#id10>

Template Literals

[Python-ideas] tagged templates like in JavaScript

[Thomas Güttler]

Tagged templates in JavaScript look interesting[1]

foo`...${bar} ...`

Where `foo` is an arbitrary method provided by the user.

But somehow I think general purpose string interpolation (PEP501)
is enough.

At least my use-case: Get something like this format_html() but with the
power of f-strings,
PEP501 would be enough.

What do you think?

Regards,
  Thomas

[1]:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#tagged_templates




Am Fr., 4. Juni 2021 um 23:39 Uhr schrieb Guido van Rossum :

> On Fri, Jun 4, 2021 at 3:08 PM Thomas Güttler 
> wrote:
>
>>
>>
>> Am Fr., 4. Juni 2021 um 19:20 Uhr schrieb Guido van Rossum <
>> gu...@python.org>:
>>
>>> PEP 501 is unlikely to be accepted *as is*. But it’s still a good
>>> starting point.
>>>
>>>
>> OK, before starting a new project, it maybe makes sense to finish the
>> first.
>>
>> Why not reject PEP-501 officially? Maybe with a reason. Then we know
>> what's wrong with it.
>>
>
> You'd have to ask its author. Most likely he'll just withdraw the PEP
> completely without telling you anything more.
>
> In short, I don't think you're going to get much out of trying to get
> anyone to say anything "official" about PEP 501.
>
> If you really want to know more, you could probably dig up the discussions
> around that PEP and learn from that.
>
>
>> After that is done, we can think about a new start.
>>
>
> There's no need to wait for that.
>
>
>> What do you think?
>>
>>
>>
>>
>>
>>> Personally I would look for inspiration towards JavaScript template
>>> literals (
>>>
>>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals),
>>> combined with f-string-like interpolation.
>>>
>>>
>> I personally really would like to avoid the dollar sign which gets used
>> in JS template literals.
>>
>
> Well of course. The Python equivalent would use the exact same
> interpolation syntax as f-strings (and before it, str.format()).
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YSY4HOGJMFCV3CPYI2PEDSPXXFHUL2PZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Custom-Strings: Combine f-strings and condtional_escape()

[Thomas Güttler]

Am Fr., 4. Juni 2021 um 19:20 Uhr schrieb Guido van Rossum :

> PEP 501 is unlikely to be accepted *as is*. But it’s still a good starting
> point.
>
>
OK, before starting a new project, it maybe makes sense to finish the first.

Why not reject PEP-501 officially? Maybe with a reason. Then we know what's
wrong with it.

After that is done, we can think about a new start.

What do you think?





> Personally I would look for inspiration towards JavaScript template
> literals (
>
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals),
> combined with f-string-like interpolation.
>
>
I personally really would like to avoid the dollar sign which gets used in
JS template literals.


Regards,
  Thomas Güttler
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZBZOKYSVB63A3F7KN66LPEWTXVBJGG6X/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Custom-Strings: Combine f-strings and condtional_escape()

[Thomas Güttler]

Am Fr., 4. Juni 2021 um 15:42 Uhr schrieb Richard Damon <
rich...@damon-family.org>:

> I think one fundamental problem is that you can’t detect programmatically
> if a string needs to be escaped or not.
>
> For instance, the sequence & might be an already escaped & or it might
> be the text to tell you how to escape an ampersand and needs to be
> converted to &
>
>
That's a problem which Python can't solve. This is up to the consumer
of InterpolationTemplate.

In the django world, it is solved via conditional_escape():
https://github.com/django/django/blob/3.2.4/django/utils/html.py#L92


Regards,
  Thomas



> Promoting sloppy coding by handling the most common cases is the way to it
> easier to create security vulnerabilities.
>
> Maybe if escaped strings had a different type than unescaped strings, but
> then you need a bunch of different types for different rules for escaping.
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YQIONRVFKONSW3YO23KVHMJNFHQNLSRW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Custom-Strings: Combine f-strings and condtional_escape()

[Thomas Güttler]

Thank you for this hint. PEP-501 looks very good.

But how to get this dream come true?

Regards,
  Thomas


Am Fr., 4. Juni 2021 um 14:39 Uhr schrieb Chris Angelico :

> On Fri, Jun 4, 2021 at 10:02 PM Thomas Güttler 
> wrote:
> >
> > Hi,
> >
> > I have a crazy idea how to extend Python for web development.
> >
> > What do you think? What are the next steps?
> >
> > [chomp details]
>
> Something like this - but more generic - has been proposed already:
>
> https://www.python.org/dev/peps/pep-0501/
>
> There've been a few variants on the idea, but I think PEP 501 is the
> best summary.
>
> If you want to press forward with this, I think that would be the best
> starting point.
>
> ChrisA
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/WZHFKMUKSSS6LLJGQUX7DVGP5EOL7M46/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/XTYDGSO5R5T2U2I57I6SEOVX3X4OWHMQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Custom-Strings: Combine f-strings and condtional_escape()

[Thomas Güttler]

Hi,

I have a crazy idea how to extend Python for web development.

What do you think? What are the next steps?

Original: https://github.com/guettli/python-custom-strings

Python Custom Strings

Python Custom Strings want to combine two great things:

   - Python's f-strings
   

   - Django's conditional_escape()
   


Python Custom Strings is a proposal to enhance Python, to give developers
new ways to create escaped strings.

The Python Custom Strings proposal is not related to Django or HTML. This
text uses HTML and Django just as an example.

Motivation

I could create HTML in Python with the help of Django's format_html()

like
this:

html = format_html('''
 Hi {username}
 Your messages: {messages}''',
 username=username,
 messages=messages
 )

With "username" being a simple string that gets quoted. For example Mary &
Bob will get Mary & Bob.

With "messages" being a previously escaped string. For example
line1line2. It does not get escaped, since it is
already escaped.

This "magic" detection whether escaping should be done or not gets handled
by conditional_escape()

.

Goal

I would like to shorten the above code to something similar to this:

html = h'''
 Hi {username}
 Your messages: {messages}'''

The developer should not need to type these line:

 username=username,
 messages=messages

These lines are meaningless and distracting. Avoiding them reduces the
cognitive load, especially for the reader of the code.

Customization

To make this customizable, the user needs to define the methods which
should get used.

In the above example the h prefix of this snippet:

html = h'''
 Hi {username}
 Your messages: {messages}'''

Should be executed like

html = mark_safe('''
 Hi {username}
 Your messages: {messages}''',
  username=conditional_escape(username),
  messages=conditional_escape(message))

Python does not know about these methods mark_safe() and
conditional_escape().

So we need a way to define that.
Defining
custom strings

Somehow, there needs to be a definition of the custom strings. Up to now I
open concerning "how to define custom strings?".

The syntax could look like this:

register_custom_string('h', pre_return, pre_insert)

With pre_return() and pre_insert() being methods which get executed to
create the custom string.

In the above example you would use this:

register_custom_string('h', mark_safe, conditional_escape)

This is just a first idea. I guess there are better ways to define both
methods. Please speak up if you have a better idea.

The letter h is just an example. The developer should be able to choose his
prefered character. Replacing the already used letteres like r, b, u is not
possible and results in an exception.

TODO: What should happen if register_custom_string() gets called twice for
the same character?
What
is inside curly braces?

In the above example, we just use a variable name. But having more is
better.

Custom strings are meant for developers, so arbitrary code execution is
fine.

Arbitrary code in curly braces should be allowed:

html = h'''...{my_object.my_method(some_arg)}...'''

Why
not just this hack?

Instead of h'...' you could use this hack to get the desired implementation:

def h(html):
"""
Django's format_html() on steroids
"""
def replacer(match):
call_frame = sys._getframe(3)
return conditional_escape(
eval(match.group(1), call_frame.f_globals, call_frame.f_locals))
return mark_safe(re.sub(r'{(.*?)}', replacer, html))

The above implementation has one big drawback:

IDEs and linters don't know that variables get used inside the custom
string.

This means IDEs and linters think variables (or imports) don't get used and
act accordingly.

Nevertheless it makes no sense to type myvar=mvar again and again, just to
make IDEs/linters happy.

Concerns

"Custom strings will downgrade Python to the level of PHP".

I think Separation of Concerns makes sense. But sometimes Locality of
Behaviour  makes more sense.

It really

Re: [Python-ideas] kwargs for return

[Thomas Güttler]

Wow, thank you very much for all those answers and hints to my message.

David opened my eyes with this: Functions return a single value, period.

Yes, this means my question is not about a function, it is about assignment.

Dictionary unpacking could be used for my use case.

Since it does not exist, I will look at dataclasses.

Thank you very much for your feedback.

  Thomas Güttler


Am 26.01.19 um 14:04 schrieb Thomas Güttler Lists:

I know this is going to get rejected, but I want to speak out the idea 
nevertheless:

I love kwargs and named arguments from the beginning (roughly 18 years now)

I guess you came across this several times before:

In the first version of the API one variable gets returned:

Example:


     status = backend.transmit_data()

But later you want to add something to the API.


For the input part of a method this is solved. You
can add an optional kwarg.

But for the output part of a method, there you can't change
the interface easily up to now.

Use case: you want to add an optional list of messages which
could get returned.

You want to change to

     status, messages = backend.transmit_data()

If you have 10 different backend implementations,
then you need to change all of them.

This is difficult, if the backends reside in different
repos and maybe you even don't own some of these repos.

Current draw-back: you need to change all of them at once.

Of course you could work around it be using this

    status_messages = backend.transmit_data()

And then do some fancy guessing if the variable contains
only the status or a tuple containing status and messages.

Some days ago I head the idea that kwargs for return would
help here.


This should handle both cases:

Case1: The old backend returns only the status, and the caller
wants both status and messages. Somehow the default
for messages needs to be defined. In my case it would
be the empty list.


Case2: The new backends returning the status
and messages. The old caller just gets the
status. The messages get discarded.

Above is the use case.

How could kwargs for return look like?

Maybe like this:

.

Sorry, I could not find a nice, clean and simple syntax
for this up to now.

Maybe someone else is more creative than I am.

What do you think about this?


Regards,
   Thomas Güttler


--
Thomas Guettlerhttp://www.thomas-guettler.de/
I am looking for feedback:https://github.com/guettli/programming-guidelines


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/



--
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] kwargs for return

[Thomas Güttler Lists]

I know this is going to get rejected, but I want to speak out the idea 
nevertheless:


I love kwargs and named arguments from the beginning (roughly 18 years now)

I guess you came across this several times before:

In the first version of the API one variable gets returned:

Example:


    status = backend.transmit_data()

But later you want to add something to the API.


For the input part of a method this is solved. You
can add an optional kwarg.

But for the output part of a method, there you can't change
the interface easily up to now.

Use case: you want to add an optional list of messages which
could get returned.

You want to change to

    status, messages = backend.transmit_data()

If you have 10 different backend implementations,
then you need to change all of them.

This is difficult, if the backends reside in different
repos and maybe you even don't own some of these repos.

Current draw-back: you need to change all of them at once.

Of course you could work around it be using this

   status_messages = backend.transmit_data()

And then do some fancy guessing if the variable contains
only the status or a tuple containing status and messages.

Some days ago I head the idea that kwargs for return would
help here.


This should handle both cases:

Case1: The old backend returns only the status, and the caller
wants both status and messages. Somehow the default
for messages needs to be defined. In my case it would
be the empty list.


Case2: The new backends returning the status
and messages. The old caller just gets the
status. The messages get discarded.

Above is the use case.

How could kwargs for return look like?

Maybe like this:

.

Sorry, I could not find a nice, clean and simple syntax
for this up to now.

Maybe someone else is more creative than I am.

What do you think about this?


Regards,
  Thomas Güttler


--
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] name2type mapping

[Thomas Güttler]

Am 25.10.18 um 22:34 schrieb Steven D'Aprano:

On Thu, Oct 25, 2018 at 10:04:05PM +0200, Thomas Güttler Lists wrote:

I created a first draft of the name2type mapping which was discussed
here some days ago:


Since this is not a language feature, please take the discussion to a
more appropriate forum such as this:

https://mail.python.org/mailman/listinfo/code-quality


The discussion was already taken to a an other forum: 
https://github.com/guettli/python-name2type-mapping

I feel where proud and happy since Guido created an issue there.

Regards,
  Thomas Güttler



--
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] name2type mapping

[Thomas Güttler Lists]

I created a first draft of the name2type mapping which was discussed 
here some days ago:



https://github.com/guettli/python-name2type-mapping/blob/master/README.rst


Feedback is welcome.


Regards,

  Thomas Güttler


--
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] TypeHinting: From variable name to type. Yes: no change to language, just convetion

[Thomas Güttler]

Am 21.10.18 um 16:44 schrieb David Mertz:

On Fri, Oct 19, 2018 at 3:18 AM Thomas Güttler mailto:guettl...@thomas-guettler.de>> wrote:

Now my idea: Per module and/or per file type hinting from variable name.
Maybe a magic docstring in the __init__.py file:
variable-name-mapping:
   {
     request: django.http.HttpRequest,
}


In general, I like this idea; but really only on a per-file basis.  A short header at the top would be easy enough for 
an IDE or linter to scan.  But imposing the conventions project-wide feels too broad.


There might, of course, be cases where the same name is used for different purposes in the same file.  But the tool can 
alert the developer of that... and in that one file, she could either remove the header of refactor the names used, as 
made sense for that particular code.


This is certainly not something that requires language support.  It can easily be purely a convention, as long as 
different IDEs, linters, type checkers, etc. agree on what the convention is.  Maybe at some point in the future, if the 
convention becomes adopted, there might be some help in having a standard library module, or even minimal language 
recognition, of the convention.  But let's work on adopting a convention first.


Yes, this sounds good. There is no need to change the python language, it is 
should be a convetion.

Regards,
  Thomas Güttler


--
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] TypeHinting: From variable name to type

[Thomas Güttler Lists]

Am 19.10.18 um 12:15 schrieb Steven D'Aprano:

On Fri, Oct 19, 2018 at 09:18:02AM +0200, Thomas Güttler wrote:


Imaging you are developing in the django context.

Everytime you use a variable named "request" or "response" your human brains
knows that this is a subclass of  django.http.HttpRequest and
django.http.HttpResponse.

Not *my* human brain.



I know that I know nothing, or at least not much. My laptop does compute 
much faster than I do




I've seen far too many variables called (let's say) "mylist" which
actually hold a dict or a tuple (or in one memorable case, a string!) to
unconditionally believe the name.

But I'll accept that given the context, there's a very strong likelihood
that a variable called "request" might be a HttpRequest object, and one
called "response" might be a HttpResponse object.



Great, we agree here.




How to give the IDE this knowledge?

One solution is the do typehinting everywhere the veriable gets used.

You shouldn't need to. Your IDE or type-checker should be able to do
type-inference and infer the type. You only need to add a hint if it
cannot infer the type.

If your IDE doesn't do type inference, get a better IDE *wink*



I use the free community version of pyCharm, and it often does not know

which type a variable has. A simple name2type mapping would improve

the situation a lot.





But why does the human brain not need this?

Because it is intelligent?

Yes.

  

I would not call this intelligence. There is a simple
dictionary in the brain of the developer, which maps:

variable-name --> Type

Is that a fact? How do you know?

How does the information in this dict get filled in?



as I already said before a docstring in the __init__.py file would

be a pragmatic solution.



I think it is FAR more likely that it is intelligence: the human
programmer understands the *meaning of the code* and would equally
recognise that

 myresponse
 response2
 reply
 answer
 rspns



I try to use the same variable name again and again. I guess in my

code base in 95% an instance of HttpRequest is stored in a variable 
called "request".


You say:  the human programmer understands the *meaning of the code*

Great if that is the case for you. I often look at the code and don't 
get it at all.


I wrote the lines two years ago, and today I don't understand why they 
exist.


This does not happen daily, but at least once a month.



In other words, we *read* and *understand* the code, not just
mechanically map names to types. That's why we have no problem with
dynamically typed languages like Python were the one name can refer to
objects of many different types.

When the context is different, we interpret the name differently:

 response = input("Continue? Y/n ")

 response = chatbot.lookup(question)

 response = mapping[challenge]


would all be interpreted differently, even if the module used Django. I
doubt any reasonable programmer would imagine that they were
HttpResponse objects.


relax. I mean this like I said. Please relax.

Imagine you have this: reposense = obj.get_response()

First: if the variable is the return value of a method, and the method

has type-annotated the return value, then this type information gets used.

End of type detect.

If the type information can't be found from the method, then use the 
name2type


mapping which I suggest in this mail.








And this mapping dict exists once per library.

Or more likely, doesn't exist at all.



If you are developing in the requests http lib, then
there is a different mapping. Then "response" means
type requests.Response.

What if you are using *both* django and requests in the same module? You
could have both of these:

 response = something_returning_requests_Response()

 response = something_returning_django_HttpResponse()

in the one module.



Do you really care for this edge-case? I don't.

The way to get the type info is the same: Check the method,

if it has it use this. Do not use name2type mapping. End of type detection.

Then check the current file or the above __init__.py of the code. Take

name2type mapping from there.


Regards,

  Thomas Güttler


--
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] TypeHinting: From variable name to type (IDE Support only)

[Thomas Güttler]

Am 19.10.18 um 11:42 schrieb Ivan Levkivskyi:

On Fri, 19 Oct 2018 at 08:19, Thomas Güttler mailto:guettl...@thomas-guettler.de>> wrote:

[...]
This makes the type mapping available for all files in this directory (or 
sub-directories).
What do you think?


I don't think this should be a language feature. _Maybe_ it can be some kind of 
an agreed format between IDEs.
But in any case I would first discuss this on PyCharm and VScode 
(IntelliSense?) trackers.

Also I don't think it is a good fit for mypy (and probably other type checkers, 
but better ask pytype and pyre devs).
I would rather expect that IDEs auto-add annotations using some guided 
heuristics, and then type checkers can verify them.



I agree. For me IDE support is all I need.

Regards,
  Thomas Güttler

--
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] TypeHinting: From variable name to type

[Thomas Güttler]

Am 19.10.18 um 10:22 schrieb Robert Vanden Eynde:
That would be a feature in my "python dialect" future library. Taking one valid python program and producing another 
python program :


def f(request):
     return HttpResponse('ok')

→

def f(request: HttpRequest):
return HttpResponse('ok')

The dialect options would include "all top functions in this module" for example, and parameters about the naming 
convention (explicit list of conversion or rules to create the mapping).



I think creating source code from source code is most of the time not the best 
solution.
Except you call the result not "source code" but "binary executable code". [1]

I think it would be great if this could work for local variables (which are not 
in the arg/kwargs of the method), too:

Example:

def foo():
response = get_response_from_paradise()

If `get_response_from_paradise()` has not spec for the return type, then it 
would be great to guess
the return type from the general "wisdom".

Regards,
  Thomas





[1]: 
https://github.com/guettli/programming-guidelines/blob/master/README.rst#source-code-generation-is-a-stupid-idea





--
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] TypeHinting: From variable name to type

[Thomas Güttler]

Imaging you are developing in the django context.

Everytime you use a variable named "request" or "response" your human brains
knows that this is a subclass of  django.http.HttpRequest and 
django.http.HttpResponse.

How to give the IDE this knowledge?

One solution is the do typehinting everywhere the veriable gets used.

But why does the human brain not need this?

Because it is intelligent?

I would not call this intelligence. There is a simple
dictionary in the brain of the developer, which maps:

variable-name --> Type

And this mapping dict exists once per library.

If you are developing in the requests http lib, then
there is a different mapping. Then "response" means
type requests.Response.


Now my idea: Per module and/or per file type hinting from variable name.

Maybe a magic docstring in the __init__.py file:

"""
variable-name-mapping:
 {
   request: django.http.HttpRequest,
 ...
}
"""

This makes the type mapping available for all files in this directory (or 
sub-directories).

What do you think?




Disclaimer: For reasons I don't want to explain in detail, I am not allowed to
do implement things like this. This is just an idea. I would feel proud and 
thankfull
if someone likes it that much, that he implements it.




--
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Preemptive multitasking and asyncio

[Thomas Güttler]

Am 24.01.2018 um 17:59 schrieb Steven D'Aprano:

On Wed, Jan 24, 2018 at 05:46:29PM +0100, Thomas Güttler wrote:

I found a question and answer at Stackoverflow[1] which says
that asyncio/await is like cooperative multitasking.

My whish is to have preemptive multitasking: The interpreter
does the yielding.


Isn't that what threading and multiprocessing do?


Hmmm, yes, you are right.

I guess I have not understood something up to now.
If async/await is the answer. What was the question?
AFAIK it can help to solve the c10k problem.

If I don't have the c10k problem, then what is the benefit of async/await?

If it is only about IO, there are python bindings for libraries like libuv.

I guess this whole topic is too ...(I am missing the right term here)... for
average developers like me.

Regards,
  Thomas Güttler


--
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Preemptive multitasking and asyncio

[Thomas Güttler]

I found a question and answer at Stackoverflow[1] which says
that asyncio/await is like cooperative multitasking.

My whish is to have preemptive multitasking: The interpreter
does the yielding. The software developer does not need to
insert async/await keywords into its source code any more.

AFAIK the erlang interpreter does something like this.

I guess it is impossible to implement this, but it was
somehow important for me to speak out my which.

What do you think?

Regards,
  Thomas Güttler


[1] 
https://stackoverflow.com/questions/38865050/is-await-in-python3-cooperative-multitasking


--
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Adding new lines to "Zen of Python"

[Thomas Güttler]

Am 08.09.2017 um 14:47 schrieb Thomas Güttler:

I curious if there are any plans to update the "Zen of Python".

What could be added to the "Zen of Python"?

What do you think?



I like this one:

"Bad programmers worry about the code. Good programmers worry about data structures and their relationships." (Linus 
Torvalds)



Regards,
  Thomas Güttler

--
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Adding new lines to "Zen of Python"

[Thomas Güttler]

I curious if there are any plans to update the "Zen of Python".

What could be added to the "Zen of Python"?

What do you think?

Regards,
  Thomas Güttler




--
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] socket module: plain stuples vs named tuples - Thank you

[Thomas Güttler]

thank you! I am happy that Guido is open for  a pull request ... There were +1 votes, too (and some concern about python 
startup time).



I stopped coding in spare time, since my children are more important at the moment .. if some wants to try it ... go 
ahead and implement named tuples for the socket standard library - would be great.


Just for the records, I came here because of this feature request:

   https://github.com/giampaolo/psutil/issues/928

Regards,
  Thomas Güttler

PS: For some strange reasons I received only some mails of this thread. But I 
could
find the whole thread in the archive.

Am 20.06.2017 um 04:05 schrieb INADA Naoki:

Namedtuple in Python make startup time slow.
So I'm very conservative to convert tuple to namedtuple in Python.
INADA Naoki  


On Tue, Jun 20, 2017 at 7:27 AM, Victor Stinner
 wrote:

Oh, about the cost of writing C code, we started to enhance the socket
module in socket.py but keep the C code unchanged. I am thinking to the
support of enums. Some C functions are wrapped in Python.

Victor

Le 19 juin 2017 11:59 PM, "Guido van Rossum"  a écrit :


There are examples in timemodule.c which went through a similar conversion
from plain tuples to (sort-of) named tuples. I agree that upgrading the
tuples returned by the socket module to named tuples would be nice, but it's
a low priority project. Maybe someone interested can create a PR? (First
open an issue stating that you're interested; point to this email from me to
prevent that some other core dev just closes it again.)

On Mon, Jun 19, 2017 at 2:24 PM, Victor Stinner 
wrote:


Hi,

2017-06-13 22:13 GMT+02:00 Thomas Güttler :

AFAIK the socket module returns plain tuples in Python3:

   https://docs.python.org/3/library/socket.html

Why not use named tuples?


For technical reasons: the socket module is mostly implemented in the
C language, and define a "named tuple" in C requires to implement a
"sequence" time which requires much more code than creating a tuple.

In short, create a tuple is as simple as Py_BuildValue("OO", item1,
item2).

Creating a "sequence" type requires something like 50 lines of code,
maybe more, I don't know exactly.

Victor
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/





--
--Guido van Rossum (python.org/~guido)



___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/



--
Thomas Guettler http://www.thomas-guettler.de/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] socket module: plain stuples vs named tuples

[Thomas Güttler]

AFAIK the socket module returns plain tuples in Python3:

  https://docs.python.org/3/library/socket.html

Why not use named tuples?

Regards,
  Thomas Güttler

-- 
I am looking for feedback for my personal programming guidelines:
https://github.com/guettli/programming-guidelines
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Smoothing transition: 'unicode' and 'basestring' as aliases for 'str'?

[Thomas Güttler]

Thank you for guiding me, Mike. We see us on CLT this weekend :-)

Regards,
  Thomas Güttler

Am 06.03.2017 um 12:01 schrieb Mike Müller:

Am 06.03.17 um 11:12 schrieb Thomas Güttler:

yes, you are right. It's better to leave Python3 clean (without "basestring").

I see two ways now.


six


six.string_types  # replacement for basestring

Source
https://docs.djangoproject.com/en/1.10/topics/python3/#string-handling-with-six


future
--

from past.builtins import basestring   # pip install future

Source http://python-future.org/compatible_idioms.html#basestring


I have no clue which one I should use.


I would recommend future. It gives you a Python-3-like experience in Python 2.
Once you fully transition to Python 3, you only need to remove the future
imports and you don't have any dependency on it any more.

For example:

from builtins import bytes, str

gives you Python 3 bytes and strings in Python 2. Now, you can replace
basestring with str and it works the same in Python 2 and 3.
Maybe this works for you.

I am pretty happy with future.

Best,
Mike

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/



--
Thomas Guettler http://www.thomas-guettler.de/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Smoothing transition: 'unicode' and 'basestring' as aliases for 'str'?

[Thomas Güttler]

yes, you are right. It's better to leave Python3 clean (without "basestring").

I see two ways now.


six


six.string_types  # replacement for basestring

Source 
https://docs.djangoproject.com/en/1.10/topics/python3/#string-handling-with-six


future
--

from past.builtins import basestring   # pip install future

Source http://python-future.org/compatible_idioms.html#basestring


I have no clue which one I should use.

Regards,
  Thomas

Am 03.03.2017 um 16:43 schrieb Joao S. O. Bueno:

I see no reason to introduce clutter like this at this point in time -
 code needing to run in both Py 2 nd 3, if not using something like
"six" could do:

compat.py
try:
 unicode
except NameError:
 unicode = basestring = str

elsewhere:
from compat import unicode, basestring


Or rather:

try:
unicode
else:
str = basestring = unicode

and
from compat import str
# therefore having Python3 valid and clear code from here.

On 3 March 2017 at 11:37, Ryan Birmingham  wrote:

The thread is here in the archive
(https://mail.python.org/pipermail/python-ideas/2016-June/040761.html) if
anyone's wondering context, as I was.

In short, someone wanted an alias from string to basestring.
 This is addressed in the "What's new in Python 3.0"
(https://docs.python.org/3/whatsnew/3.0.html) page:


The built-in basestring abstract type was removed. Use str instead. The
strand bytes types don’t have functionality enough in common to warrant a
shared base class. The 2to3 tool (see below) replaces every occurrence of
basestring with str.


Personally, I have no issue with leaving an alias like this in 2to3, since
adding it to the language feels more like forced backwards compatibility to
me.

That said, there are more related subtleties on the "What's new in Python
3.0" page, some of which seem less intuitive, so I understand where a desire
like this would come from. Would more specific and succinct documentation on
this change alone help?

-Ryan Birmingham

On 3 March 2017 at 06:44, Thomas Güttler 
wrote:


I found this in an old post:


Maybe too late now but there should have been 'unicode',
'basestring' as aliases for 'str'.


I guess it is too late to think about it again ...

Regards,
  Thomas Güttler


--
Thomas Guettler http://www.thomas-guettler.de/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/




___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


--
Thomas Guettler http://www.thomas-guettler.de/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Smoothing transition: 'unicode' and 'basestring' as aliases for 'str'?

[Thomas Güttler]

I found this in an old post:

> Maybe too late now but there should have been 'unicode',
> 'basestring' as aliases for 'str'.

I guess it is too late to think about it again ...

Regards,
  Thomas Güttler


--
Thomas Guettler http://www.thomas-guettler.de/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 525: Asynchronous Generators

[Thomas Güttler]

Am 10.08.2016 um 19:17 schrieb Sven R. Kunze:

On 09.08.2016 05:23, Nick Coghlan wrote:

On 9 August 2016 at 08:37, Sven R. Kunze mailto:srku...@mail.de>> wrote:

From what I've heard in the wild, that most if not all pieces of async are 
mirroring existing Python features. So,
building async basically builds a parallel structure in Python resembling 
Python. Async generators complete the
picture. Some people (including me) are concerned by this because they feel that 
having two "almost the same
pieces" is not necessarily a good thing to have. And not necessarily bad 
but it feels like duplicating code all
over the place especially as existing functions are incompatible with async.


It's a known problem that applies to programming language design in general 
rather than being Python specific:
http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/



If it's a such well-known **problem**, why does it even exist in Python in the 
first place? ;-)

I don't buy that one couldn't have avoided it.


Lately, I talked to friend of mine about async and his initial reaction was like 
"hmm that reminds me of early
programming days, where you have to explicitly tell the scheduler to get control 
back". He's much older than me, so I
think it was interesting for him to see that history is repeating again.


Up to now there is only one answer to the question "Is `await` in Python3 
Cooperative Multitasking?"

http://stackoverflow.com/questions/38865050/is-await-in-python3-cooperative-multitasking

The user there writes: [about await] That sounds quite like Cooperative 
multitasking to me.

In 1996 I was a student at university and was told that preemptive multitasking 
is better.

Since tools like http://python-rq.org/ can be implemented in Python2.7 I ask 
myself: why change the language?

My opinion: if you want to do parallel processing, use a tool like python-rq or 
celery.

Regards,
  Thomas Güttler



--
Thomas Guettler http://www.thomas-guettler.de/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/