It is recommended for any #python beginner to be aware of the location you execute your file from. The way interpreter indexes modules or the way libraries like pathlib work with paths will vary. Believe me, you don't want your database to be created elsewhere. And I saw such confusions a lot during my tutoring practice.
#sqlite made several choices in order to prove itself actually "light". For example, I spotted that both #python and sqlite are UTF-8 based. Though Python can apply case transitions to languages like Armenian. But not sqlite. In slightly more than short - here's WHY. In short - it would make sqlite like... sqheavy.
In modern #python the most basic way you can manage, store and access context-local state is with the API provided by the contextvars module. It is similar to thread-local storage (TLS), but, unlike TLS, it also allows correctly keeping track of values per asynchronous task, e.g. asyncio.Task. Corresponding rationale could be find in the related PEP 567. Some nice and short explanations can be found in THIS article.
Python documentation
contextvars — Context Variables
This module provides APIs to manage, store, and access context-local state. The ContextVar class is used to declare and work with Context Variables. The copy_context() function and the Context clas...
Want to really get maximum in #python with the requests in the async style? There is the httpx module worth checking. Key features ON TOP of the requests include:
- A broadly requests-compatible API.
- Standard synchronous interface, but with async support if you need it.
- HTTP/1.1 and HTTP/2 support.
- Ability to make requests directly to WSGI applications or ASGI applications.
- Strict timeouts everywhere.
- Fully type annotated.
- 100% test coverage.
- A broadly requests-compatible API.
- Standard synchronous interface, but with async support if you need it.
- HTTP/1.1 and HTTP/2 support.
- Ability to make requests directly to WSGI applications or ASGI applications.
- Strict timeouts everywhere.
- Fully type annotated.
- 100% test coverage.
The recordclass library in #python is an interesting concept of providing data-like classes to avoid cyclic garbage collection mechanism. Leaving only reference counting in play. Without the PyGC_Head prefix meant for the object in the memory - you receive a decreased size and a slightly faster performance.
PyPI
recordclass
Mutable variant of namedtuple -- recordclass, which support assignments, compact dataclasses and other memory saving variants.
If you are curious on how the #python Garbage Collector is designed - I advise to check out the Pablo Golindo article.
Consider the #python code on the attached image. How do you think, why do we see only the return from the finally block?
Well, the official documentation has us covered. It's as simple as:
If the try statement reaches a break, continue or return statement, the finally clause will execute just prior to the break, continue or return statement’s execution.
Well, the official documentation has us covered. It's as simple as:
If the try statement reaches a break, continue or return statement, the finally clause will execute just prior to the break, continue or return statement’s execution.
👍2
One of my favorite tricks in #python which really enhances the classes understanding - is the imitation of Java/JavaScript like increment operator.
Take a look at the code on the attached photo.
So, the increment operator "++" adds one to the number. This is an inplace operation in Javas. In my simple example it is not, but using the idea I show it is pretty manageable.
How it works: I create two secondary classes and inherit from the usual integer. I make a pos dunder for both. Which stands for positive unary operation: https://docs.python.org/3/reference/datamodel.html#object.__pos__ and is activated each time there is a plus before the object in the code, but without the second object to use the add instead.
So, if a plus sign appears before my Int object - the pos dunder method is fired. And just returns the _Second_Plus_Int. This way we are protected from adding a value if the plus sign is single. But the _Second_Plus_Int also checks for signs before it. And if it found something - well, it's at least the second plus in a row, time to increment the value.
As the prints show - those classes swap while using plusses to activate the pos dunder one by one.
Take a look at the code on the attached photo.
So, the increment operator "++" adds one to the number. This is an inplace operation in Javas. In my simple example it is not, but using the idea I show it is pretty manageable.
How it works: I create two secondary classes and inherit from the usual integer. I make a pos dunder for both. Which stands for positive unary operation: https://docs.python.org/3/reference/datamodel.html#object.__pos__ and is activated each time there is a plus before the object in the code, but without the second object to use the add instead.
So, if a plus sign appears before my Int object - the pos dunder method is fired. And just returns the _Second_Plus_Int. This way we are protected from adding a value if the plus sign is single. But the _Second_Plus_Int also checks for signs before it. And if it found something - well, it's at least the second plus in a row, time to increment the value.
As the prints show - those classes swap while using plusses to activate the pos dunder one by one.
❤1
I found myself frequently looking for set operations symbols in #python so I made a bizarre looking cheat-sheet.
❤1
Do you like the #python iterator mechanism as much as I do?
Shortly: sequences and (sometimes) containers can be iterated over. The built-in function "iter" converts those objects into the "Iterator" object. By applying the "next" built-in function to such "Iterator" - you can get the next value inside the iterable. Once the object is exhausted of values - the StopIteration error is raised.
But why do we need that?
Let's think about efficiency. Take a look at the first lines of the picture, where I demonstrate the concept by shadowing the built-in "zip" function. The "repeat" function of the itertools module will indefinitely provide the value if the second argument is not provided. And imagine that each test case, each list inside is millions items long. It would be a great waste of memory to manipulate those objects in whole. Thankfully we can operate with their values one step at a time. That's why functions like "zip" return generators instead of actual results. And it is for you to decide - do you want to traverse the output with the "next" approach or to convert the output into, let's say, tuple and let the iteration machinery do the work for you under the hood.
About the attached picture.
I declare the TEST_CASES global constant, each row represents a specific set of sequences to "zip". Later I provide the shallow shadow of the original "zip" function without some features like the "strict" parameter. I pack all the input objects into the "args" variable. I initialize all "Iterator" objects on the line 12-th with a list comprehension and in the infinite loop I request "next" values from each of those "Iterators" at once. And pack those into the tuple. Once ANY of the "Iterators" is exhausted - I intercept the exception. Otherwise - time to "yield" the current pack of values. That's the keyword which makes my function a generator. And lastly starting from the line 21-st I just compare the output of my imitation with the glorious origin.
Shortly: sequences and (sometimes) containers can be iterated over. The built-in function "iter" converts those objects into the "Iterator" object. By applying the "next" built-in function to such "Iterator" - you can get the next value inside the iterable. Once the object is exhausted of values - the StopIteration error is raised.
But why do we need that?
Let's think about efficiency. Take a look at the first lines of the picture, where I demonstrate the concept by shadowing the built-in "zip" function. The "repeat" function of the itertools module will indefinitely provide the value if the second argument is not provided. And imagine that each test case, each list inside is millions items long. It would be a great waste of memory to manipulate those objects in whole. Thankfully we can operate with their values one step at a time. That's why functions like "zip" return generators instead of actual results. And it is for you to decide - do you want to traverse the output with the "next" approach or to convert the output into, let's say, tuple and let the iteration machinery do the work for you under the hood.
About the attached picture.
I declare the TEST_CASES global constant, each row represents a specific set of sequences to "zip". Later I provide the shallow shadow of the original "zip" function without some features like the "strict" parameter. I pack all the input objects into the "args" variable. I initialize all "Iterator" objects on the line 12-th with a list comprehension and in the infinite loop I request "next" values from each of those "Iterators" at once. And pack those into the tuple. Once ANY of the "Iterators" is exhausted - I intercept the exception. Otherwise - time to "yield" the current pack of values. That's the keyword which makes my function a generator. And lastly starting from the line 21-st I just compare the output of my imitation with the glorious origin.
❤2
Once upon a time I stumbled upon a philosophical dispute whether do coders need #math. I do believe that math is a niche must have, though in mass it is not required. Honestly, very little math were involved while I set up #APIs, created #databases, routed messages and operated with json files.
Though math deserves its credit for shaping the way developer thinks. For abstraction skills. And, in my opinion, it really shines if you have to optimize #efficiency.
For example, take a look at a puzzle I just solved in #python on #CodeSignal. Image attached. Straightforward approach would be to simulate the whole situation with loops. Which is O(n) #complexity at best. But by applying math ideas - I was able to dramatically speed up to the glorious O(1), constant time. Just 11 arithmetical operations for ANY valid input.
In the comment section of the code you'll find my notes representing my thought process. I imagined the result in the 3d space and started to think how could I sum up different parts of the shape. I easily applied the sequence sum school formula, though needed some googling in order to remember how to sum the sequence of squares.
Though math deserves its credit for shaping the way developer thinks. For abstraction skills. And, in my opinion, it really shines if you have to optimize #efficiency.
For example, take a look at a puzzle I just solved in #python on #CodeSignal. Image attached. Straightforward approach would be to simulate the whole situation with loops. Which is O(n) #complexity at best. But by applying math ideas - I was able to dramatically speed up to the glorious O(1), constant time. Just 11 arithmetical operations for ANY valid input.
In the comment section of the code you'll find my notes representing my thought process. I imagined the result in the 3d space and started to think how could I sum up different parts of the shape. I easily applied the sequence sum school formula, though needed some googling in order to remember how to sum the sequence of squares.
So, which is faster in #python for strings - reverse function approach or negative step slicing?
Origin of the dispute: Didier Flamm comment to 🐍 Dorian Turba post
As it turns out in my speed-test - [::-1] is almost x7 times faster. Which makes sense. Indexing is a low-level single step optimized operation. While reversed-join path struggles from midway type casting and two step operation.
Origin of the dispute: Didier Flamm comment to 🐍 Dorian Turba post
As it turns out in my speed-test - [::-1] is almost x7 times faster. Which makes sense. Indexing is a low-level single step optimized operation. While reversed-join path struggles from midway type casting and two step operation.
I made a short fun project dedicated to the "[Br]eaking [Ba]d" series: br-badizer of texts!
You can play with it here: https://rioran.github.io/breaking-badize/main.html
Source code to be found here: https://github.com/Rioran/breaking-badize
Made with #python and #pyscript thanks to PyScript for a nice tool!
You can play with it here: https://rioran.github.io/breaking-badize/main.html
Source code to be found here: https://github.com/Rioran/breaking-badize
Made with #python and #pyscript thanks to PyScript for a nice tool!
#python 3.12 final version is expected to arrive in October 2023. Along other changes we are to embrace the "Syntactic formalization of f-strings", which includes:
1) Quotes reuse inside f-strings, which makes it possible to have nested f-strings further than 4 levels deep.
In my humble opinion f-strings nesting presents unnecessary cognitive complexity and should be avoided in production. Though developers decided to ignore such concerns to focus on the parser technically and wish for linters to handle the situation.
2) Multi-line expressions and comments will be allowed.
Which IMO could make complex f-strings easier to read. Though preparing it's parts elsewhere is more likely to be easier to read.
3) Backslashes inside f-strings will be allowed.
Which will make it possible to use escaping and all related mechanisms like working with the newlines or emoji (Unicode escaped sequences). Though escaped braces are still disallowed intentionally, at least "for the time being" (c).
More details could be red in PEP-701.
Reasoning behind the f-strings formalization includes:
- lowering the maintenance cost of the CPython parser;
- allowing the new PEG parser to apply improved error messages;
- making f-strings a part of the "official Python grammar" so that other Python implementations can be sure they implemented f-strings correctly;
The mechanism behind the changes introduces 3 new tokens for the parser to work with: FSTRING_START, FSTRING_MIDDLE, FSTRING_END. So, the tokenizer won't be able to produce a single token for f-strings anymore, will need more.
1) Quotes reuse inside f-strings, which makes it possible to have nested f-strings further than 4 levels deep.
In my humble opinion f-strings nesting presents unnecessary cognitive complexity and should be avoided in production. Though developers decided to ignore such concerns to focus on the parser technically and wish for linters to handle the situation.
2) Multi-line expressions and comments will be allowed.
Which IMO could make complex f-strings easier to read. Though preparing it's parts elsewhere is more likely to be easier to read.
3) Backslashes inside f-strings will be allowed.
Which will make it possible to use escaping and all related mechanisms like working with the newlines or emoji (Unicode escaped sequences). Though escaped braces are still disallowed intentionally, at least "for the time being" (c).
More details could be red in PEP-701.
Reasoning behind the f-strings formalization includes:
- lowering the maintenance cost of the CPython parser;
- allowing the new PEG parser to apply improved error messages;
- making f-strings a part of the "official Python grammar" so that other Python implementations can be sure they implemented f-strings correctly;
The mechanism behind the changes introduces 3 new tokens for the parser to work with: FSTRING_START, FSTRING_MIDDLE, FSTRING_END. So, the tokenizer won't be able to produce a single token for f-strings anymore, will need more.
❤2