Python

A new, larger revision of the written content to cover the releases of Flask 3.0 and SQLAlchemy 2.0 (Yes, technically I'm releasing this update a month before 2024, in December 2023)

i was trying to parse a string with pyparsing so all the words were separated from the punctuation signs, i was using this expression to do it:

OneOrMore(Word(alphanums)) + OneOrMore(Char(printables))

But when i parse the following string with this expression:

return abc(1, ULLONG_MAX)

All the words inside the parentheses get split:

['return', 'abc', '(', '1', ',', 'U', 'L', 'L', 'O', 'N', '_', 'M', 'A', 'X', ')', ';']

But if i use this expression:

OneOrMore(Word(alphanums)) + OneOrMore(Char(string.punctuation))

Only a part of the string gets parsed:

['return', 'abc', '(']

What is wrong with those expressions?

Python's standard logging API violates PEP-8 and this #PEP proposes to fix this. Feedback and criticism of all sort is welcome.

I'm pretty new to Python and discovered the nicely presented PEP8 coding style guide linked in the post. Stumbling onto The Hitchhiker’s Guide to Python! has been a very helpful compliment to the official Python Documentaion

Hopefully this post will help others getting familiar with Python.

cross-posted from: https://programming.dev/post/6470590

This looks like a great starting point for people with little to no experience with programming to learn to program using Python.

Everything taught by futurecoder.io can be used locally on your own computer. But futurecoder.io doesn't show you how to install Python on your machine but you can fill in that gap with the information provided @ https://wiki.python.org/moin/BeginnersGuide/Download

Other resources are provided on the python.org Beginners Guide if needed.

any Insomnia alternatives which are not Postman? I need rest and graphql support.
Insomnia is getting worse and worse and I'm worried it won't be better.
#programming @python @golang
@opensource

Let's say I have the following structure:

my_module/
  __init__.py
  utilities.py

and __init__.py contains

from .utilities import SomeUtilityFunction

Is there a way to prevent or alert developers when they do

from my_module.utilities import SomeUtilityFunction

instead of

from my_module import SomeUtilityFunction

The problem arose when a few modules started using a function that was imported inside a module in which it wasn't used, while also being available on the module's __init__.py, so after linting the file and removing the unused import my tests started failing.

any other advice for situations like this?

via https://fosstodon.org/@tonybaloney/111427911923421383

In this blog post, I will look into the implementation details of CPython’s Global Interpreter Lock (GIL) and how they changed between Python 3.9 and the current development branch that will become Python 3.13.

The general approach is that a Python thread obtains the GIL when it starts executing Python bytecode. It will hold the GIL as long as it needs to and eventually release it, for instance when it is done executing, or when it is executing some operation that often would be long-running and itself does not require the GIL for correctness. This includes for instance the aforementioned file reading operation or more generally any I/O operation. However, a thread may also release the GIL when executing specific bytecodes.

This is where Python 3.9 and 3.13 differ substantially. Let’s start with Python 3.13, which I think roughly corresponds to what Python has been doing since version 3.10 (roughly since this PR). Here, the most relevant bytecodes are for function or method calls as well as bytecodes that jump back to the top of a loop or function. Thus, only a few bytecodes check whether there was a request to release the GIL.

In contrast, in Python 3.9 and earlier versions, the GIL is released at least in some situations by almost all bytecodes. Only a small set of bytecodes including stack operations, LOAD_FAST, LOAD_CONST, STORE_FAST, UNARY_POSITIVE, IS_OP, CONTAINS_OP, and JUMP_FORWARD do not check whether the GIL should be released.

For Python 3.13, this should mean that a function that contains only bytecodes that do not lead to a CHECK_EVAL_BREAKER() check should be atomic.

For Python 3.9, this means a very small set of bytecode sequences can be atomic, though, except for a tiny set of specific cases, one can assume that a bytecode sequence is not atomic.

Out of the core dev sprint. See mastodon thread for additional posts from the event: https://mastodon.social/@hugovk/111221035410194967

I like the focus on having a clean and simple build and implementation.

I’m unclear however on what kind of performance improvements can be expected. The speaker mentions a benchmark against luaJit that was 35% slower as well as some others, but I didn’t pick up on any estimates specific to Python. Maybe lua and Python are similar enough, I personally don’t know.

This is a discussion on Python's forums about adding something akin to a throws keyword in python.

I'll give you one advice, kids. Don't agree if someone offers you to work with odoo.
It's a fucking pain in development.

#python @python