Re: [Python-ideas] HTML Wrapper

[Christopher Barker]

This is very much the kind of thing that would belong in a library.

There's probably more than one out there right now. In fact, way back when
I started learning Python (almost 20 yrs ago!)), there was such a lib -- I
think it was called HTMLgen. However, since then, most people have decided
that templating is the way to accomplish this -- write the html with bits
of code in in, and have it generate the final html. There are many template
engines for/with Python.

Having said that, I actually use an OO  html generator as an assignment in
my training:

https://uwpce-pythoncert.github.io/PythonCertDevel/exercises/html_renderer.html

So you can write it yourself...

Using the approach in that assignment, you would write your example as:

selector = Selector(_class="eggs")
for i in range(3):
Selector.append(Option(f"Option {i}"))

selector.render()

-CHB



On Thu, Mar 14, 2019 at 3:43 PM Steven D'Aprano  wrote:

> Hi Vlad, and welcome!
>
> On Thu, Mar 14, 2019 at 10:00:03PM +0100, Vlad Tudorache wrote:
> > Hello,
> >
> > I'd like to know if there is a basic HTML wrapper for Python, like
> > TextWrapper but allowing the generation of HTML from strings or iterables
> > of strings.
>
> This list is for proposing and discussing ideas for new syntax or
> functionality for the Python language, not for asking basic support
> questions.
>
> Are you are proposing that Python gets a HTML wrapper?
>
> If so, it is up to you to do your research first, so that you know the
> answer to your question before you propose the idea. You should be able
> to tell us what options are available as language features or
> third-party libraries.
>
> If you don't know the answer, there are many places you can ask,
> starting with Google and other search engines:
>
> https://duckduckgo.com/?q=python+html+generator
>
> and others such as Reddit's /r/learnpython subreddit, Stackoverflow, the
> Python-List mailing list, the Python IRC channel, and more.
>
> https://mail.python.org/mailman/listinfo/python-list
> news:comp.lang.python
> https://www.reddit.com/r/learnpython/
> https://www.python.org/community/irc/
>
> If you still have a proposal after doing your research, we're happy to
> hear it.
>
>
> Regards,
>
>
>
> Steven
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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] Code version evolver

[Greg Ewing]

francismb wrote:

Yes a source transformer, but to be applied to some 3.x version to move
it to the next 3.x+1, and so on ... (instead of '2to3' a kind of
'nowtonext', aka 'python_next')

Couldn't that relax the tension on doing 'backward compatibility
changes' a bit ?


Not really. Having to translate all your source every time a
minor version update occurs would be a huge hassle.

--
Greg

___
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] Problems (and solutions?) in writing decorators

[Stephen J. Turnbull]

Sylvain MARIE via Python-ideas writes:

 > I totally understand your point of view. However on the other hand,
 > many very popular open source projects out there have the opposite
 > point of view and provide decorators that can seamlessly be used
 > with and without arguments (pytest, attrs, click, etc.). So after a
 > while users get used to this behavior and expect it from all
 > libraries. Making it easy to implement is therefore something quite
 > important for developers not to spend time on this useless
 > “feature”.

That doesn't follow.  You can also take it that "educating users to
know the difference between a decorator and a decorator factory is
therefore something quite important for developers not to spend time
on this useless 'feature'."

I'm not a fan of either position.  I don't see why developers of
libraries who want to provide this to their users shouldn't have "an
easy way to do it", but I also don't see a good reason to encourage
syntactic ambiguity by providing it in the standard library.  I think
this is a feature that belongs in the area of "you *could* do it, but
*should* you?"  If the answer is "maybe", IMO PyPI is the right
solution for distribution.

Steve

-- 
Associate Professor  Division of Policy and Planning Science
http://turnbull.sk.tsukuba.ac.jp/ Faculty of Systems and Information
Email: turnb...@sk.tsukuba.ac.jp   University of Tsukuba
Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN
___
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] Code version evolver

[Stephen J. Turnbull]

francismb writes:

 > Trying to keep a single code base for 2/3 seems like a good idea
 > (may be the developer just cannot change to 3 fast due how big the
 > step was) but that also have the limitation on how far you can go
 > using new features.

This doesn't work very well: you can't use 3 at all until you can use
3 everywhere.  So the evolutionary path is

0.  Python 2-only code base
1.  Part Python 2-only, part Python 2/3 code base (no new features
anywhere, since everything has to run in Python 2 -- may require
new test halters for component testing under Python 3, and system
test has to wait for step 2)
2.  Complete Python 2/3 code base
3a. Users use their preferred Python and developers have 2/3 4ever!
(All limitations apply in this case. :-( )
3b. Project moves to Python 3-only.

So what most applications did is branch 2 vs. 3, do almost all new
development on 3 (bugfixing on both 2 and 3 of course, and maybe
occasionally backporting a few new features to 2), and eventually
(often as soon as there's a complete implementation for Python 3!)
stop supporting Python 2.  Only when there was strong demand for Step
3a (typically for popular libraries) did it make sense to spend effort
satisfying the constraints of a 2/3 code base.

 > Once you're just on the 3 series couldn't such 2to3 concept also help to
 > speed up ? (due the 'backwards-compatibility issue')

Not really.  For example, addition of syntax like "async" and "yield"
fundamentally changes the meaning of "def", in ways that *could not*
be fully emulated in earlier Pythons.  The semantics simply were
impossible to produce -- that's why syntax extensions were necessary.

What 2to3 does is to handle a lot of automatic conversions, such as
flipping the identifiers from str to bytes and unicode to str.  It was
necessary to have some such tool because of the very large amount of
such menial work needed to change a 2 code base to a 3 code base.  But
even so, there were things that 2to3 couldn't do, and it often exposed
bugs or very poor practice (decode applied to unicode objects, encode
applied to bytes) that had to be reworked by the developer anyway.

The thing about "within 3" upgrades is that that kind of project-wide
annoyance is going to be minimal, because the language is mostly
growing in power, not changing the semantics of existing syntax.  Such
changes are very rare, and considered extremely carefully for
implications for existing code.  In a very few cases it's possible to
warn about dangerous use of obsolete syntax whose meaning has changed,
but that's very rare too.

In some cases *pure additions* to the core will be available via "from
__future__ import A", which covers many of the cases of "I wish I
could use feature A in version X.Y".  But this kind of thing is
constrained by core developer time, and developing a 3.x to 3.y
utility is (IMO, somebody else is welcome to prove me wrong! :-) way
past the point of zero marginal returns to developer effort.

It's an interesting idea, but I think practically it won't have the
benefits you hope for, at least not enough to persuade core developers
to work on it.

Steve


-- 
Associate Professor  Division of Policy and Planning Science
http://turnbull.sk.tsukuba.ac.jp/ Faculty of Systems and Information
Email: turnb...@sk.tsukuba.ac.jp   University of Tsukuba
Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN
___
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] Code version evolver

[Steven D'Aprano]

On Thu, Mar 14, 2019 at 09:33:21PM +0100, francismb wrote:

[...]
> > Do you mean something like 2to3? Something which transforms source code
> > written in Python?
> >
> Yes a source transformer, but to be applied to some 3.x version to move
> it to the next 3.x+1, and so on ... (instead of '2to3' a kind of
> 'nowtonext', aka 'python_next')
> 
> Couldn't that relax the tension on doing 'backward compatibility
> changes' a bit ?


Perhaps, but probably not.

The core-developers are already overworked, and don't have time to add 
all the features we want. Making them responsible for writing this 
source code transformer for every backwards incompatible change will 
increase the amount of work they do, not decrease it, and probably make 
backwards-incompatible changes even less popular.

For example: version 3.8 will include a backwards incompatible change 
made to the statistics.mode function. Currently, mode() raises an 
exception if the data contains more than one "most frequent" value. 
Starting from 3.8, it will return the first such value found.

If we had to write some sort of source code translator to deal with this 
change, I doubt that we could automate this. And if we could, writing 
that translator would probably be *much* more work than making the 
change itself.

Besides, I think it was Paul who pointed this out, in practice we found 
that 2to3 wasn't as useful as people expected. It turns out that for 
most people, writing version-independent code that supports the older 
and newer versions of Python is usually simpler than keeping two 
versions and using a translator to move from one to the other.

But if you feel that this feature may be useful, I encourage you to 
experiment with writing your own version and putting it on PyPI for 
others to use. If it is successful, then we could some day bring it into 
the standard library.




-- 
Steven
___
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] HTML Wrapper

[Steven D'Aprano]

Hi Vlad, and welcome!

On Thu, Mar 14, 2019 at 10:00:03PM +0100, Vlad Tudorache wrote:
> Hello,
> 
> I'd like to know if there is a basic HTML wrapper for Python, like
> TextWrapper but allowing the generation of HTML from strings or iterables
> of strings.

This list is for proposing and discussing ideas for new syntax or 
functionality for the Python language, not for asking basic support 
questions.

Are you are proposing that Python gets a HTML wrapper? 

If so, it is up to you to do your research first, so that you know the 
answer to your question before you propose the idea. You should be able 
to tell us what options are available as language features or 
third-party libraries.

If you don't know the answer, there are many places you can ask, 
starting with Google and other search engines:

https://duckduckgo.com/?q=python+html+generator

and others such as Reddit's /r/learnpython subreddit, Stackoverflow, the 
Python-List mailing list, the Python IRC channel, and more.

https://mail.python.org/mailman/listinfo/python-list
news:comp.lang.python
https://www.reddit.com/r/learnpython/
https://www.python.org/community/irc/

If you still have a proposal after doing your research, we're happy to 
hear it.


Regards,



Steven
___
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] HTML Wrapper

[Vlad Tudorache]

Hello,

I'd like to know if there is a basic HTML wrapper for Python, like
TextWrapper but allowing the generation of HTML from strings or iterables
of strings. Like:

make_select = HTMLWrapper(tag='select class="eggs"', indent='  ')
make_option = HTMLWrapper(tag='option')

Applying this like:

s = make_select([make_option('Option %d' % (i + 1), \
escape=False, strip=False) for i in range(3)])

should return s like (when printed):


  Option 1
  Option 2
  Option 3


Vlad Tudorache
___
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] Code version evolver

[francismb]

Hi Paul,

On 3/12/19 12:21 AM, Paul Moore wrote:
> That sounds very similar to 2to3, which seemed like a good approach to
> the Python 2 to Python 3 transition, but fell into disuse because
> people who have to support multiple versions of Python in their code
> found it *far* easier to do so with a single codebase that worked with
> both versions, rather than needing to use a translator.
Yes, the 2to3 idea was meant but for translations inside the 3 series
(from 3.x to 3.x+1).

Trying to keep a single code base for 2/3 seems like a good idea (may be
the developer just cannot change to 3 fast due how big the step was) but
that also have the limitation on how far you can go using new features.

Once you're just on the 3 series couldn't such 2to3 concept also help to
speed up ? (due the 'backwards-compatibility issue')

Thanks,
--francis
___
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] Code version evolver

[Chris Angelico]

On Fri, Mar 15, 2019 at 7:39 AM francismb  wrote:
>
> Hi Steven,
>
> On 3/12/19 12:25 AM, Steven D'Aprano wrote:
> > I don't know who you expect is using this: the Python core developers
> > responsible for adding new language features and changing the grammar,
> > or Python programmers.
> Python core devs should write the 'python_next' and 'is_python_code'
> parts that moves source code from the current version to the next if a
> backwards incompatible grammar change is needed.
>
> Python programmers may use the helpers to upgrade to the next version.
>
>
> > I don't know what part of the current code (current code of *what*?) is
> > supposed to be upgraded or evolved, or what you mean by that. Do you
> > mean using this to add new grammatical features to the interpreter?
> >
> > Do you mean something like 2to3? Something which transforms source code
> > written in Python?
> >
> Yes a source transformer, but to be applied to some 3.x version to move
> it to the next 3.x+1, and so on ... (instead of '2to3' a kind of
> 'nowtonext', aka 'python_next')
>
> Couldn't that relax the tension on doing 'backward compatibility
> changes' a bit ?

What happens when someone wants to support multiple Python versions?
"Requires Python 3.5 or newer" is easy. Forcing people to install the
correct one for each version isn't.

ChrisA
___
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] Code version evolver

[francismb]

Hi Steven,

On 3/12/19 12:25 AM, Steven D'Aprano wrote:
> I don't know who you expect is using this: the Python core developers
> responsible for adding new language features and changing the grammar,
> or Python programmers.
Python core devs should write the 'python_next' and 'is_python_code'
parts that moves source code from the current version to the next if a
backwards incompatible grammar change is needed.

Python programmers may use the helpers to upgrade to the next version.


> I don't know what part of the current code (current code of *what*?) is
> supposed to be upgraded or evolved, or what you mean by that. Do you
> mean using this to add new grammatical features to the interpreter?
>
> Do you mean something like 2to3? Something which transforms source code
> written in Python?
>
Yes a source transformer, but to be applied to some 3.x version to move
it to the next 3.x+1, and so on ... (instead of '2to3' a kind of
'nowtonext', aka 'python_next')

Couldn't that relax the tension on doing 'backward compatibility
changes' a bit ?


Thanks,
--francis
___
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] Problems (and solutions?) in writing decorators

[Sylvain MARIE via Python-ideas]

Thanks David

Sorry for not getting back to you earlier, I made a bunch of releases of 
makefun in the meantime. In particular I fixed a few bugs and added an 
equivalent of  `functools.partial` .

> One of the nice things in wrapt is that Dumpleton lets you use the same 
> decorator for functions, regular methods, static methods, and class methods.  
> Does yours handle that sort of "polymorphism"?

It should, but I will check it thoroughly – I’ll let you know

> I don't think I will want the specific with-or-without parens feature, since 
> it feels too implicit.  Typing `@deco_factory()` really isn't too much work 
> for me to use the two characters extra.

I totally understand your point of view. However on the other hand, many very 
popular open source projects out there have the opposite point of view and 
provide decorators that can seamlessly be used with and without arguments 
(pytest, attrs, click, etc.). So after a while users get used to this behavior 
and expect it from all libraries. Making it easy to implement is therefore 
something quite important for developers not to spend time on this useless 
“feature”.

Kind regards

Sylvain


De : David Mertz 
Envoyé : mardi 12 mars 2019 19:15
À : Sylvain MARIE 
Cc : Steven D'Aprano ; python-ideas 

Objet : Re: [Python-ideas] Problems (and solutions?) in writing decorators


[External email: Use caution with links and attachments]




One of the nice things in wrapt is that Dumpleton lets you use the same 
decorator for functions, regular methods, static methods, and class methods.  
Does yours handle that sort of "polymorphism"?

FWIW, thanks for the cool work with your libraries!

I don't think I will want the specific with-or-without parens feature, since it 
feels too implicit.  Typing `@deco_factory()` really isn't too much work for me 
to use the two characters extra.  But given that I feel the option is an 
antipattern, I don't want to add core language features to make the pattern 
easier.  Both you and Graham Dumpleton have found workarounds to get that 
behavior when it is wanted, but I don't want it to be "too easy."

FWIW... I think I'd be tempted to use a metaclass approach so that both the 
class and instance are callable.  The class would be called with a single 
function argument (i.e. a decorator), but if called with any other signature it 
would manufacture a callable instance that was parameterized by the 
initialization arguments (i.e. a decorator factory).  Actually, I haven't 
looked at your actual code, maybe that's what you do.

Best, David...

On Tue, Mar 12, 2019 at 12:44 PM Sylvain MARIE 
mailto:sylvain.ma...@se.com>> wrote:
Thanks David,

> I did write the book _Functional Programming in Python_, so I'm not entirely 
> unfamiliar with function wrappers.

Nice ! I did not realize ; good job here, congrats! ;)

--
I carefully read the documentation you pointed at, 
https://wrapt.readthedocs.io/en/latest/decorators.html#decorators-with-optional-arguments
This is the example shown by the author:

def with_optional_arguments(wrapped=None, myarg1=1, myarg2=2):
if wrapped is None:
return functools.partial(with_optional_arguments,
myarg1=myarg1, myarg2=myarg2)

@wrapt.decorator
def wrapper(wrapped, instance, args, kwargs):
return wrapped(*args, **kwargs)

return wrapper(wrapped)

As you can see:

  *   the developer has to explicitly handle the no-parenthesis case (the first 
two lines of code).
  *   And in the next lines of the doc you see his recommendations “For this to 
be used in this way, it is a requirement that the decorator arguments be 
supplied as keyword arguments. If using Python 3, the requirement to use 
keyword only arguments can again be enforced using the keyword only argument 
syntax.”
  *   Finally, but this is just a comment: this is not “flat” mode but nested 
mode (the code returns a decorator that returns a function wrapper)

So if I’m not misleading, the problem is not really solved. Or at least, not 
the way I would like the problem to be solved : it is solved here (a) only if 
the developer takes extra care and (b) reduces the way the decorator can be 
used (no positional args). This is precisely because I was frustrated by all 
these limitations that depend on the desired signature that I wrote decopatch. 
As a developer I do not want to care about which trick to use in which 
situation (mandatory args, optional args, var-positional args..). My decorators 
may change signature during the development cycle, and if I frequently had to 
change trick during development as I changed the