[Python-Dev] Re: Please do not remove random bits of information from the tutorial
On 11/9/20 12:46 PM, Mike Miller wrote: On 2020-11-09 10:44, Simon Cross wrote: That's quite subjective. Personally I prefer a more complete tutorial which explains many details so that I don't immediately run into fundamentals I don't understand when I start using what I've learned. K&R was very popular, so I don't think I'm alone in this. Indeed. A common problem with a lot of platform documentation I've experienced is that tutorials are "fluff" for absolute beginners, complemented with terse, dense reference material for experts. There is too often very little in-between to get you to the intermediate level. That's why the current tutorial is fantastic, imho. It doesn't skip the all-important middle part of the journey, and gets you to near-intermediate within a few hours if you've programed before. Perhaps the first step is too high, however. How about a new Section 0: Absolute beginners guide, for those new to programming? Just 2 cents' worth, the difficulty this discussion exposes is things In The Wrong Place (subjective), and maybe not all of the required places actually complete. I thought the following was a pretty good discussion of the overall problem of documenting a complex ecosystem: https://documentation.divio.com/ If people think that model is reasonable, we sort of have most of it - we have Reference; HowTos and Explanations (mixed together in https://docs.python.org/3/howto/index.html); and Tutorial. _Some_ people think the tutorial has too much stuff that belongs in the HowTos and Explanations buckets, and that's probably where things should be built up. e.g. @raymondh has been working on the Descriptor Howto, which is a good example of more detailed material not getting stuffed in the tutorial :) ___ 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/GBPCAGDXYLZPKK3BH2MGSGTS3IO3CO5H/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Please do not remove random bits of information from the tutorial
On Tue, Nov 10, 2020 at 8:07 AM Mats Wichmann wrote: > On 11/9/20 12:46 PM, Mike Miller wrote: > > > > On 2020-11-09 10:44, Simon Cross wrote: > >> That's quite subjective. Personally I prefer a more complete tutorial > >> which explains many details so that I don't immediately run into > >> fundamentals I don't understand when I start using what I've learned. > >> K&R was very popular, so I don't think I'm alone in this. > > > > > > Indeed. A common problem with a lot of platform documentation I've > > experienced is that tutorials are "fluff" for absolute beginners, > > complemented with terse, dense reference material for experts. There is > > too often very little in-between to get you to the intermediate level. > > > > That's why the current tutorial is fantastic, imho. It doesn't skip the > > all-important middle part of the journey, and gets you to > > near-intermediate within a few hours if you've programed before. > > > > Perhaps the first step is too high, however. How about a new Section 0: > > Absolute beginners guide, for those new to programming? > > Just 2 cents' worth, the difficulty this discussion exposes is things In > The Wrong Place (subjective), and maybe not all of the required places > actually complete. I thought the following was a pretty good discussion > of the overall problem of documenting a complex ecosystem: > > https://documentation.divio.com/ > > Daniele Procido who is involved with Divio has shared this with us when we were planning a workgroup. It's excellent content and guidelines. > If people think that model is reasonable, we sort of have most of it - > we have Reference; HowTos and Explanations (mixed together in > https://docs.python.org/3/howto/index.html); and Tutorial. _Some_ > people think the tutorial has too much stuff that belongs in the HowTos > and Explanations buckets, and that's probably where things should be > built up. e.g. @raymondh has been working on the Descriptor Howto, > which is a good example of more detailed material not getting stuffed in > the tutorial :) > > I agree. I wouldn't suggest a major refactor of the existing tutorial right now (next 1-2 years). Instead, new beginner tutorial pages targeted at user groups (primary school students, scientists, web developers, etc.) would make sense to supplement the existing tutorial. I suspect that future documentation will have "How Tos" being more often written to cover more technical topics in detail. These more standalone "How Tos" can then be linked to from contents and search pages. > ___ > 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/GBPCAGDXYLZPKK3BH2MGSGTS3IO3CO5H/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ 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/SN3AVFNFVNNR3DWB7EE432OAM6P7TTPS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: My thoughts on Pattern Matching.
On Mon, Nov 9, 2020 at 10:40 PM Tobias Kohn wrote: > Hi Thomas, > > Thank you very much for your carefully worded and thoughtful email. I > feel, however, that many of your concerns are based on an idealised > picture of a future Python language that will never actually > materialise. > > As I understand it your main point is that the concept of patterns > might---or even should---be retro-fitted to general assignments. Just > as we have borrowed from and expanded on the idea of iterable > unpacking in assignments, so should assignments then pick up the > concepts introduced in pattern matching. Indeed, assignments of the > form ``Viking(spam, ham) = ...`` are not only appealing but can be > found in various languages with pattern matching. So, why would we > not want to have consistent concepts and symmetric (orthogonal) > structures across all of Python? > > Unfortunately, such consistency or symmetry comes at a high cost---too > high as far as I am concerned. > > One of the simplest patterns is without doubt the literal pattern that > essential only matches itself (e.g., ``case 123:`` or ``case > 'abc':``). Any future unification of patterns and assignments would > therefore necessarily allow for statement such as:: > > 1 = x > I don't think that's true. There isn't anything that "necessarily" *has* to happen; practicality beats purity. Thomas' statement is more about the fact that there are so *many *concepts fully contained within the world of pattern matching which do not apply outside of it. He didn't seem to imply to me that *all* concepts had to be brought out to the general language, just that there were ones that seem to make sense to pull out for assignment unpacking. -Brett > > This is essentially equivalent to ``assert(x == 1)``. Indeed, > _Elixir_ [1] uses such syntax for exactly this semantics. However, > knowing how much novice programmers struggle with understanding that > assignments are right-to-left (i.e. ``x = 1`` and not ``1 = x``), > including such syntax would immediately raise the learning curve > significantly. In short, a very common students' mistake will take > them to error messages and concepts they could not possibly understand > without a basic comprehension of pattern matching. > > And this is probably where it becomes most obvious how our views of > pattern matching differ. The pattern matching as we propose it in > PEPs 634/635/636 is guarded by a keyword needed to activate these > features. Unless you start your statement with ``match my_data:``, > you can easily pretend as if pattern matching did not exist: it will > not, cannot affect your code. This encapsulation is intentional and > by design. > > As far as I am aware, those languages that support syntax like > ``Viking(spam, ham) = ...`` only allow this in combination with > variable _declaration_, i.e. you actually have to write ``let > Viking(spam, ham) = `` or ``var Viking(spam, ham) = ...`` or similar. > Without such a marker, this syntax quickly descends into unreadable > gibberish. As noted in the original section of rejected ideas in PEP > 622, we had originally considered adding 'one-off pattern matching': > pattern matching with only a single case that must succeed, very much > like normal assignments do. But our approach was always guarded by a > keyword, be that ``case`` or ``if``---in line with the ``var`` or > ``let`` found in other languages. Even in that case, patterns would > not leak into the language outside pattern matching. > > Finally, there is already a necessary inconsistency between iterable > unpacking and pattern matching. By their very nature, patterns > express a _possible_ structure, whereas iterable unpacking imposes a > _necessary_ structure. So, when dealing with iterators, it is safe to > 'unpack' the iterator in iterable unpacking. If the expected and > actual structures differ, it is an error, anyway. In pattern > matching, however, we have to be more conservative and careful, > exploring options rather than certanties. Hence, even if all other > concerns were wiped away, the closest we could come to an entirely > symmetric and consistent language is one with some subtle differences > and thus prone for bugs and errors. > > PEPs 634/635/636 are the result of a long and careful design process > where we sought to appeal to the intuition of the Python programmer as > much as possible, without betraying the differences and new concepts > that pattern matching necessarily introduces. Readability was always > one of our main concerns and we believe that having a clear context > where patterns occur greatly helps writing readable and consistent code. > > So, long story short, I am afraid I would question the very premise > upon which your concerns are founded: that it would ever be a good > idea to expand patterns to assignments in general. Although such a > unification was in principle possible, it would rob Python of one of > its greatest and strongest
[Python-Dev] Configure Python initialization (PyConfig) in Python
Hi, If you embed Python in Python, I would like your opinion on https://bugs.python.org/issue42260 issue which adds a way to configure the Python initialization in Python. I'm looking for feedback from people who embed Python and have issues to configure Python as they wish. Simple example (just to show how the API would look like) setting the the bytes_warning option: import _testinternalcapi import sys assert sys.flags.bytes_warning == 0 config = _testinternalcapi.get_config() # Copy PyConfig config['bytes_warning'] = 1 # regular Python dict _testinternalcapi.set_config(config) # Update PyConfig and sys assert sys.flags.bytes_warning == 1 The example already works in the current master branch! The PyConfig structure has 53 members (+ 4 private members). You can configure many things: sys.argv, sys.path, stdout encoding, disable user site directory, etc. In Python 3.8, I implemented PEP 587 "Python Initialization Configuration" which is the concrete implementation of the first half of PEP 432 "Restructuring the CPython startup sequence". Python now provides a C API to configure every option of its initialization: https://docs.python.org/dev/c-api/init_config.html Nick Coghlan recently withdrew his PEP 432 since PEP 587 was rejected. It made me sad :-( I tried to implement the second half of the PEP 432: * [DONE] Introduce the most limited "core" initialization phase where Python only has builtin types and builtin modules (implemented as a provisional C API in the PEP 587, I fixed some issues recently). sys module is only partially initialized (no sys.path, no sys.stdout). Python should not access the file system in his phase. * [DONE] Only compute the Python path configuration during the main initialization, not during the core initialization. * [DONE] Ability to configure the Python initialization in Python. * [WIP] Rewrite Modules/getpath.c (1600 lines of C code) to Lib/_getpath.py (700 lines of Python code) See https://bugs.python.org/issue42260 for the work-in-progress. In Python 3.9, it's already possible to configure PyConfig in C. The idea here is to give the ability to do it in Python, but also to reimplement the old Modules/getpath.c as modern Python code. In my WIP PR 23169, I reimplemented getpath.c in two parts: * _getpath Python module: logic to build sys.path * _cgetpath C extension used by _getpath: minimum C code to expose Py_DecodeLocale() function and some constants in Python It will be easier to maintain and evolve _getpath.py, but also to write a test suite (right now, getpath.c has almost no test, see test_embed). Later, the idea would be to let applications embedding Python to execute their own code to configure Python initialization options (PyConfig) in Python between the "core" initialization phase and the "main" initialization (Python fully initialized). It should not be run after the main initialization, since the configuration is used to configure Python during the main initialization. >From a practical point of view, executing Python code to initialize Python requires freezing this code as a frozen module (as I did for _getpath.py in my PR). I don't know if it's easy to do that in an application embedding Python right now. My remaining problem is that my PR changes PyConfig_Read(): it no longer computes the Python Path Configuration, since it is now implemented in Python. IMO it's an acceptable drawback compared to the benefit of these new features. Victor -- Night gathers, and now my watch begins. It shall not end until my death. ___ 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/HQNFTXOCDD5ROIQTDXPVMA74LMCDZUKH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: When to remove BytesWarning?
> I'm quite sure that almost nobody uses -b or -bb when running their test suite or to develop I noticed this thread and just thought I'd give one example of someone who does use -bb: https://github.com/johnthagen/python-blueprint/blob/210b89fe011d172104e9f1ba2553e4245f76a77b/tox.ini#L44 I admit I am in a very small minority however. That being said, I have discovered a few minor bugs in my code or in third party libraries over the years using -bb. But I would understand still wanting to remove this feature to lower maintenance burden. ___ 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/QZYDKPEDN6FKJ4ZRPOUS6D6HACCGMW7O/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: When to remove BytesWarning?
On Wed, Nov 11, 2020 at 10:19 AM John Hagen wrote: > > I admit I am in a very small minority however. That being said, I have > discovered > a few minor bugs in my code or in third party libraries over the years using > -bb. > But I would understand still wanting to remove this feature to lower > maintenance burden. Which warning helped you? str(bytes)? bytes == str? or bytes == int? I am not much concerned about removing str(bytes) warning anytime soon. Only bytes== warning is significant maintenance burden. Regards, -- Inada Naoki ___ 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/KROXMCDQGYAJDFH7ZSMZG2SW22TTWJ4Y/ Code of Conduct: http://python.org/psf/codeofconduct/
