Re: Start Python programming
On Tue, 27 Apr 2021 17:32:22 +, Gazoo wrote: > I'd like to start learning Python programming. What sites/tutorials > could you recommend for beginner, please. Have you tried this book? https://greenteapress.com/wp/think-python-2e/ It is a good book, written by Allan B. Downey, which is available for free in HTML or PDF. If you wish, you can buy a copy on Amazon as well. - Abrantes -- https://mail.python.org/mailman/listinfo/python-list
Re: Not found in the documentation
Le mardi 27 avril 2021 à 01:44:04 UTC+2, Paul Bryan a écrit : > From > https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy > > : > > > The string representations of the numeric classes, computed > > by__repr__() and __str__(), have the following properties: > > * They are valid numeric literals which, when passed to their > > class constructor, produce an object having the value of the > > original numeric. > > * The representation is in base 10, when possible. I realize that these basic informations have been very recently added to the Language Reference document as they are missing from the 3.8.5 version (July 2020) as you can check here: https://docs.python.org/release/3.8.5/reference/datamodel.html#index-8 -- https://mail.python.org/mailman/listinfo/python-list
Re: Start Python programming
On 28/04/2021 05.32, Gazoo wrote: > > > I'd like to start learning Python programming. What sites/tutorials > could you recommend for beginner, please. Start with the Python Tutorial (https://docs.python.org/3/tutorial/index.html), thereafter there are other 'docs' at the same site. There are plenty of books and both $free and paid courses available on-line, to suit many preferred ways of learning, and covering many specialised applications of the language. -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
Start Python programming
I'd like to start learning Python programming. What sites/tutorials could you recommend for beginner, please. -- Gazoo -- https://mail.python.org/mailman/listinfo/python-list
Re: Not found in the documentation
> The *Language Reference* is designed to be much more formally defined, and > favors correctness and completeness over being easy to access by less > technical readers. > Not really my opinion. Language Reference (LR) style is still written in a conversational style, giving examples instead of definition. Typically consider this paragraph from the LR: begin excerpt --- The value of some objects can change. Objects whose value can change are said to be mutable; objects whose value is unchangeable once they are created are called immutable. (The value of an immutable container object that contains a reference to a mutable object can change when the latter’s value is changed; however the container is still considered immutable, because the collection of objects it contains cannot be changed. So, immutability is not strictly the same as having an unchangeable value, it is more subtle.) An object’s mutability is determined by its type; for instance, numbers, strings and tuples are immutable, while dictionaries and lists are mutable. end excerpt --- The explanations inside the parenthensis is a by-the-way explanation, a mark of conversional style not to say tutorial style. Before parenthensis, we are talking about value of **any kind** of object and changeability in general. Now, the parenthensis is refering to immutable container as an illustration. The same for last sentence : "for instance ..." The problem is that the documentation doesn't define what the value of an object is, what means changing the value. The documentation doesn't explain **how** mutability is determined by the type of the object. By the way, how the docs define a container? Answer: "Some objects contain references to other objects; these are called containers". So to summarize : "a container contains", what a great definition! You said that LR is designed to be much more formally defined, and favors correctness and completeness. Good, so can you answer this question after reading the LR : what is a "token"? Did't find a definition. Is the "is not" operator a token? > There's an argument to be made that the description of the expected > __str__() behavior of ints is not easy to find within section 3 of the > language reference, and I imagine that a reasonable proposed change to this > wording would be considered favourably. (python is accepting pull requests > when they pass review :). > A drop in the ocean, sorry but Python docs are irrecoverable. -- https://mail.python.org/mailman/listinfo/python-list
Re: Ad-hoc SQL query builder for Python3?
On Mon, 27 Apr 2021, Robert Latest via Python-list wrote: In case nobody mentioned it before, don't forget to take a look at SQLAlchemy. The object-relational-mapper (ORM) creates a 1:1 mapping of Python objects to SQL table rows. Robert, Yes, I've known of SA for years. I want something that can be embedded in the application so the user doesn't need to install another dependentcy package and maintain it. Regards, Rich -- https://mail.python.org/mailman/listinfo/python-list
Re: Not found in the documentation
On Tue, Apr 27, 2021 at 12:52 PM elas tica wrote: > > > However, in this case, the general information in the docs is > > absolutely sufficient, and the basic principle that the repr should > > (where possible) be a valid literal should explain what's needed. > > > This is a subjective statement. Recall: explicit is better implicit. Alas, > many parts of the Python docs are written in a conversational style, full > of implicit and fuzzy meanings. > The general rule of thumb that I use is: The *Library Reference* section of the Python docs contains info that cover 90% of use-cases and questions. (note built-in types are a section in the library reference, despite being built-in to the interpreter and not really part of the standard library, but this makes sense if you consider the library reference to be more 'friendly' documentation that tries to balance verbosity and covering every corner case explicitly against readability and approachability. This could be considered a 'conversational' style, but that style is generally considered a feature in the library reference section. The *Language Reference* is designed to be much more formally defined, and favors correctness and completeness over being easy to access by less technical readers. In this case, subjectively, I (and I think Chris agrees here) feel that python's behavior with calling str() is suitably non-surprising (especially when compared to almost every other modern language) that being described in the language reference seems entirely reasonable. There's an argument to be made that the description of the expected __str__() behavior of ints is not easy to find within section 3 of the language reference, and I imagine that a reasonable proposed change to this wording would be considered favourably. (python is accepting pull requests when they pass review :). Steve > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Not found in the documentation
On Tue, Apr 27, 2021 at 9:51 PM elas tica wrote: > > > > However, in this case, the general information in the docs is > > absolutely sufficient, and the basic principle that the repr should > > (where possible) be a valid literal should explain what's needed. > > > This is a subjective statement. Recall: explicit is better implicit. Alas, > many parts of the Python docs are written in a conversational style, full of > implicit and fuzzy meanings. Is there an actual problem here, or are you just looking for something to pick a hole in? Are you asking if a hypothetical alternate Python implementation is allowed to have int(16) return "0x10" ? Common sense should be a thing. Use it. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Not found in the documentation
> However, in this case, the general information in the docs is > absolutely sufficient, and the basic principle that the repr should > (where possible) be a valid literal should explain what's needed. This is a subjective statement. Recall: explicit is better implicit. Alas, many parts of the Python docs are written in a conversational style, full of implicit and fuzzy meanings. -- https://mail.python.org/mailman/listinfo/python-list
Re: Not found in the documentation
On Tue, Apr 27, 2021 at 6:11 PM elas tica wrote: > > > > Python has this thing called interactive mode that makes it possible to > > discover answers even faster than looking in the docs > > To go further : > Python has this thing called source code that makes it possible to discover > answers even faster than looking in the docs > Hmm, that's a bit of a trap. CPython has source code, but the Python language specification is not the CPython source code. There is definitely value in having certain behaviours documented, as it allows other Python implementations to know what's part of the language definition and what's an implementation detail of CPython. However, in this case, the general information in the docs is absolutely sufficient, and the basic principle that the repr should (where possible) be a valid literal should explain what's needed. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Not found in the documentation
> Python has this thing called interactive mode that makes it possible to > discover answers even faster than looking in the docs To go further : Python has this thing called source code that makes it possible to discover answers even faster than looking in the docs -- https://mail.python.org/mailman/listinfo/python-list
Re: Not found in the documentation
On 27/04/2021 11:24 am, elas tica wrote: Le mardi 27 avril 2021 à 01:44:04 UTC+2, Paul Bryan a écrit : From https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy : Thanks for the reference. I was expecting to find this information in the Built-in Types section from the PSL documentation. The representation returned by str over a complex number is not stated. The same for fraction objects. All the docstrinds are meaningless, showing : Try ... >>> help(int) and any other built-in type __str__(self) str(self) (END) not very informative. -- Signed email is an absolute defence against phishing. This email has been signed with my private key. If you import my public key you can automatically decrypt my signature and be sure it came from me. Just ask and I'll send it to you. Your email software can handle signing. OpenPGP_signature Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Not found in the documentation
On 4/26/2021 7:24 PM, elas tica wrote: Python documentation doesn't seem to mention anywhere what is the str value of an int: is it right? the same for float, Fraction, complex, etc? Not worth to be documented? Perphaps str(42) returns "forty two" or "XLII" or "101010" ... Python has this thing called interactive mode that makes it possible to discover answers even faster than looking in the docs (which can get out of date when things change, as they have for floats). str(12345) '12345' repr(12345) '12345' str(1+1*j) Traceback (most recent call last): File "", line 1, in if True: NameError: name 'j' is not defined str(1+1j) '(1+1j)' repr(1+1j) '(1+1j)' str(.999) '1.0' str(0xff34) '65332' -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
