Python etc

2021-06-30 20:33:43 Modules have a magic attribute called __path__. Whenever you're doing subpackage imports, __path__ is being searched for
that submodule.

__path__ looks like a list of path strings, e.g ["foo/bar", "/path/to/location"].

So if you do from foo import bar, or import foo.bar, foo's __path__ is being searched for bar. And if found - loaded.

You can play around with __path__ to test it out.

Create simple Python module anywhere on your system:


$ tree
.
└── foo.py

$ cat foo.py
def hello():
return "hello world"

Then, run the interpreter there and do the following:
python
>>> import os
>>> os.__path__ = ["."]
>>> from os.foo import hello
>>> hello()
'hello world'

As you can see, foo is now available under os:
python
>>> os.foo

1.5K views17:33

Open / Comment

2021-06-16 15:33:30 by @PavelDurmanov Open / Comment

2021-06-16 15:33:29 Have you ever wondered how do relative imports work?


Im pretty sure that you've done something like that at some point:


from . import bar
from .bar import foo



It's using a special magic attribute on the module called __package__.
Lets say you have the following structure:


foo/
__init__.py
bar/
__init__.py
main.py



The value of __package__ for foo/__init__.py is set to "foo", and for foo/bar/__init__.py its "foo.bar".


Note that for main.py __package__ isn't set, that's because main.py is not in a package.


So when you're doing from .bar import buz within foo/__init__.py, it simply appends "bar" to foo/__init__.py's __package__ attribute, esentially it gets translated to from foo.bar import buz.


You can actually hack __package__, e.g:


>>> __package__ = "re"
>>> from . import compile
>>> compile

7.7K viewsedited  12:33

Open / Comment

2021-06-08 21:12:27 This guest post is written by Pythonic Attacks channel. Open / Comment

2021-06-08 21:12:27 Some operators in Python have special names.
Many Pythonistas know about the notorious "walrus" operator (:=), but there are less famous
ones like the diamond operator (<>) — it's similar to the "not equals" operator but written in SQL style.
The diamond operator was suggested in PEP 401 as one of
the first actions of the new leader of the language Barry Warsaw after Guido went climbing Mount Everest.
Luckily, it was just an April Fool joke and the operator was never really a part of the language.
Yet, it's still available but hidden behind the "import from future" flag.

Usually you compare for non-equality using !=:

>>> "bdfl" != "flufl"
True


But if you enable the "Barry as FLUFL" feature the behavior changes:

>>> from __future__ import barry_as_FLUFL
>>> "bdfl" != "flufl"
File "", line 1
"bdfl" != "flufl"
^
SyntaxError: with Barry as BDFL, use '<>' instead of '!='
>>> "bdfl" <> "flufl"
True


Unfortunately, this easter egg is only working in interactive mode (REPL), but not in usual *.py scripts.

By the way, it's interesting that this feature is marked as becoming mandatory in Python 4.0.

6.8K viewsedited  18:12

Open / Comment

2021-05-06 18:01:06 Since Python doesn't have a char type, an element of str is always str:

'@pythonetc'[0][0][0][0][0]
# '@'

This is an infinite type and you can't construct in a strictly typed language (and why would you?) because it's unclear how to construct the first instance (thing-in-itself?). For example, in Haskell:

Prelude> str = str str

:1:7: error:
• Occurs check: cannot construct the infinite type: t1 ~ t -> t1

7.2K viewsedited  15:01

Open / Comment

2021-05-04 18:00:43 Python has a built-in module sqlite3 to work with SQLite database.

import sqlite3
conn = sqlite3.connect(':memory:')
cur = conn.cursor()
cur.execute('SELECT UPPER(?)', ('hello, @pythonetc!',))
cur.fetchone()
# ('HELLO, @PYTHONETC!',)

Fun fact: for explanation what is SQL Injection the documentation links xkcd about Bobby tables instead of some smart article or Wikipedia page. Open / Comment

2021-04-29 18:00:06 If any function can modify any passed argument, how to prevent a value from modification? Make it immutable! That means the object doesn't have methods to modify it in place, only methods returning a new value. This is how numbers and str are immutable. While list has append method that modifies the object in place, str just doesn't have anything like this, all modifications return a new str:

a = b = 'ab'
a is b # True
b += 'cd'
a is b # False

This is why every built-in collection has an immutable version:

+ Immutable list is tuple.
+ Immutable set is frozenset.
+ Immutable bytearray is bytes.
+ dict doesn't have an immutable version but since Python 3.3 it has types.MappingProxyType wrapper that makes it immutable:

from types import MappingProxyType

orig = {1: 2}
immut = MappingProxyType(orig)

immut[3] = 4
# TypeError: 'mappingproxy' object does not support item assignment

And since it is just a proxy, not a new type, it reflects all the changes in the original mapping:

orig[3] = 4
immut[3]
# 4 Open / Comment

2021-04-27 18:00:41 Multiline string literal preserves every symbol between opening and closing quotes, including indentation:

def f():
return """
hello
world
"""
f()
# '\n hello\n world\n '

A possible solution is to remove indentation, Python will still correctly parse the code:

def f():
return """
hello
world
"""
f()
# '\nhello\n world\n'

However, it's difficult to read because it looks like the literal is outside of the function body but it's not. So, a much better solution is not to break the indentation but instead remove it from the string content using textwrap.dedent:

from textwrap import dedent

def f():
return dedent("""
hello
world
""")
f()
# '\nhello\n world\n' Open / Comment

2021-04-22 18:00:07 Let's have a look at the following log message:

import logging
logger = logging.getLogger(__name__)
logger.warning('user not found')
# user not found

When this message is logged, it can be hard based on it alone to reproduce the given situation, to understand what went wrong. So, it's good to provide some additional context. For example:

user_id = 13
logger.warning(f'user #{user_id} not found')

That's better, now we know what user it was. However, it's hard to work with such kinds of messages. For example, we want to get a notification when the same type of error messages occurred too many times in a minute. Before, it was one error message, "user not found". Now, for every user, we get a different message. Or another example, if we want to get all messages related to the same user. If we just search for "13", we will get many false positives where "13" means something else, not user_id.

The solution is to use structured logging. The idea of structured logging is to store all additional values as separate fields instead of mixing everything in one text message. In Python, it can be achieved by passing the variables as the extra argument. Most of the logging libraries will recognize and store everything passed into extra. For example, how it looks like in python-json-logger:

from pythonjsonlogger import jsonlogger

logger = logging.getLogger()

handler = logging.StreamHandler()
formatter = jsonlogger.JsonFormatter()
handler.setFormatter(formatter)
logger.addHandler(handler)

logger.warning('user not found', extra=dict(user_id=13))
# {"message": "user not found", "user_id": 13}

However, the default formatter doesn't show extra:

logger = logging.getLogger()
logger.warning('user not found', extra=dict(user_id=13))
# user not found

So, if you use extra, stick to the third-party formatter you use or write your own. Open / Comment