[Python-Dev] Which thing is "Development Mode"
As of 3.7, there is now a python feature called Development Mode: https://docs.python.org/3/library/devmode.html#devmode Which has a confusingly similar and nearly identical name to a setuptools feature: https://packaging.python.org/guides/distributing-packages-using-setuptools/#working-in-development-mode It seems like a bit of bikeshedding could create a name for one of them that disambiguates them. Best, coyot ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/42NQQHQEQ4FTRP5CKI5XSKD3GA6L5IIT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Which thing is "Development Mode"
On 2/26/21 13:49, Steven D'Aprano wrote: Hi Coyot, and welcome! Can you explain the circumstances where a developer, or an end user, might be confused as to which development mode is meant? "Dev mode" is a very common term: Windows 10 has a development mode. So does the X-Box and the Samsung Galaxy phone. Ruby on Rails also has a development mode. So does the Opera web browser. I'm sure that with a bit of googling, we could come up with a dozen more examples. Normally, the context is all we need to disambiguate the different dev modes, and if not, we can disambiguate the two by using fully qualified names: "Galaxy dev mode" and "X-Box dev mode". Under what circumstances is that not sufficient for Python dev mode and setuptools dev mode? Hi, Steven, and thanks for the kind welcome. As a senior engineer, I occasionally mentor newer engineers and it frequently reminds me that what is obvious to me is not obvious to those starting out. This is one of those cases, where those of us who have been around Python for awhile can perhaps infer from context which his meant, but the phrase "put your Python project into development mode" is ambiguous in a way that is different from your example. This is because both dev modes are a part of Python, unlike operating systems and platforms. That is, Samsung Galaxy and Windows 10 are very different ecosystems, but setuptools and Python features are part of the same ecosystem and often, the same context. Best, coyot P.S. Got a giggle out of Victor's color suggestion, taking bikeshedding literally. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HTHJ2UPQZKMGN4WZNYXNI432EGRNDRCY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Which thing is "Development Mode"
On 3/1/21 08:49, Paul Moore wrote: On Mon, 1 Mar 2021 at 16:25, Coyot Linden (Glenn Glazer) wrote: This is one of those cases, where those of us who have been around Python for awhile can perhaps infer from context which his meant, but the phrase "put your Python project into development mode" is ambiguous in a way that is different from your example. The commonly used packaging terminology is actually "editable mode" (at least in the sense that that's what most people seem to call it, so knowing and using that term will get better results from Google ;-)). If you feel inclined to raise a PR against the pip documentation to prefer that term, it can be discussed over there (but note that the underlying setuptools command is `setup.py develop` and that's not likely to change, as it's hard-coded in a number of applications, including pip). But ultimately, I think the reality is that there *are* terminology confusions all over the place in computing, much like in any other discipline (I'm currently teaching someone music, and the number of terms that get re-used in different contexts there is even worse than computing!) So I think that ultimately, beginners simply need to get used to understanding that terms can be context-dependent. It's not easy, and as teachers we can do what we can to make things clearer, but we can't ever completely make such problems go away. Paul I think we have fundamentally different worldviews, Paul. Just because something is bad or even often bad, is no reason to let it stay that way or to not try and make things better. Engineering almost never makes any problem completely go away, the perfect can't be the enemy of the good. Personally, since it is newer and not stuck with the problems you mention, I would prefer to change the name of the new Python runtime option than mess with the setuptools mess. Best, coyot ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/GXTDS5OMQW66HSZ3JRKZM6WVQKEC6AXY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]
On Sun, Mar 27, 2022 at 3:08 AM Paul Moore p.f.mo...@gmail.com wrote: ... exactly - let's say someone needs to write some JSON for the first time. With the json package included, all they need to do is `import json`. If that wasn't there, they's look in PyPi for a JSON implementation, and find an absolutely astonishing number of options. I just did a search for "JSON" on PYPI, and it's HUGE -- most of them are for specialized JSON-using protocols of some sort. I was actually really surprised that couple I know about of the top of my head (ujson, orjson) are actually hard to find. "You can just pip install it" is really not a good solution. In fact, this is an example, I think, of where we should put some effort into making the included batteries better -- it's great to have a JSON lib built in, but it's too bad that it's not best-of-bread by pretty much any definition (speed, memory performance, flexibility) -- there are quite a few feature requests open for it -- it would be nice to actually implement some of those. (but yes, that's a lot of work that someone(s) would have to do) Back to the topic at hand, rather than remove urllib, maybe it could be made better -- an as-easy-to-use-as-requests package in the stdlib would be really great. -CHB Strong plus one to this. Part of Python's huge attraction and widespread adoption is that one doesn't need a lot of formal training or engineering experience to just dive right in. Having a rich set of libraries only helps this, forcing newbies to pip/PYPI is a great way to lose them. I also completely agree that the right answer is to make the standard libraries better, not throw them away. And for those that don't use them, ignore them. Best, coyot P.S. There are uses for urllib outside of standard web programming. I recently needed to handle strings in query parameter format (`?...&...&...`) and found urllib parse() the easiest way of doing that even though I wasn't taking them in as a webservice. Deleting the library would break this code. :( ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/Z7YNNVZKXBQO4QL2W2RYPDSTLEZZXNVV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Descriptions in unittest and avoiding confusion
I would like to point out another use case of triple quotes outside of
docstrings. We do a lot of SQL here and so doing a parameterized query like:
"""SELECT foo
FROM bar
WHERE baz = %s"""
is a whole lot cleaner and more natural than
("SELECT foo" +
"FROM bar" +
"WHERE baz = %s")
For this toy example, one could just put it all on one line, but for
rather more complicated SQL, it becomes a readability (and thus
maintainability) factor to preserve SQL's one keyword per line
formatting. So, yes, all of our SQL statements wind up in the parse tree
and that's not optimal, but the suboptimality there is less for us than
the suboptimality of the second form above.
I would welcome a multiline comment format that didn't involve docstrings.
Best,
coyot
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/6MKP4IR5STLNDPZKU6H5AVTZ7F3XAHYX/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Descriptions in unittest and avoiding confusion
I would welcome a multiline comment format that didn't involve docstrings. Err, sorry, I meant multiline string format. Best, coyot ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ZTUB6DTJOSER5PVRPJFLPA4VJ3EOD2JH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Descriptions in unittest and avoiding confusion
On 4/4/22 09:25, Paul Moore wrote: On Mon, 4 Apr 2022 at 17:22, Coyot Linden (Glenn Glazer) wrote: I would welcome a multiline comment format that didn't involve docstrings. Err, sorry, I meant multiline string format. I'm confused, what's wrong with """..."""? Triple quoted strings are not exclusively for docstrings... Paul That isn't my reading of PEP 257, I would be happy to be wrong about this. Best, coyot ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/54UQZCQOOIWXTLUKND7VJTFX5VUP7NMH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Descriptions in unittest and avoiding confusion
"Well, that escalated quickly." :-) How did we get from a specific issue with docstrings and the unittest package's test reporting to multi-line comments? If this was Discourse that entire subdiscussion would have been flagged as off-topic and moved to its own thread. Apologies, as I said earlier, I meant to write multiline string, not multiline comment and it wasn't my intention to derail the thread but rather provide a different use case for multiline strings which seems, TIL, to be the accepted usage. So I thank the community for that input and will refrain from commenting further on this. Best, coyot ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/2COAF7RAC4PNP7SS5DDNZANHFAMQ3DZM/ Code of Conduct: http://python.org/psf/codeofconduct/
