Finally got to a Python question

On Nix(OS) can i setup a python development environment from requirements files without ruffling the package managers feathers?

When ready to create a wheel, python -m build, how does Nix(OS) want the python package to be built to gain all the benefits of Nix(OS) build reproducibility?

Eww eww eww, I have a good one!

function argument: params vs **params

Assume both are the same Mapping.

The former can update in-place. The later, nope.

If the function is a generic function or one of the overloads. Wait what's that? It's the term used by functools.singledispatch to describe the fallback function when no overload function handles the case.

Anyway

Any param to either singledispatch generic or an overload, Whatever you throw at it, won't be in-place updatable.

Awesome, thank you for your insights!

Being able to have different package versions live side by side, is mind blowing. Most people would resort to flatpak or docker to contain that packages dependencies and transitive dependencies. But the amount of redundant packages must be mind blowing.

To not need all those redundant packages is an impressive feat!

The term is used by the trio package author. You are in for a treat! Go read the docs for trio right now! Then anyio.

Take what the trio author has to say very very seriously.

The term colored function means, in order to support concurrency, needing to modify a function with special language syntax, in this case, async.

I've been using asyncio for a few years now and this article had stuff I haven't even thought about, very useful!

Now I'm curious what differences you are talking about, because I'm no Python expert, but I can't think of any. If you mean identity representation, no, it's not different:

>>> a = 65535
>>> b = 65535
>>> a is b
False

True. Since it's all interpreted, it doesn't act like primitives in things like C and everything is an object, that is a ref of some sort. However, there is a difference between how Python "primitives" and Python collections work within the language syntax.

I think he means this https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/

I admit that I haven’t read the whole article but could you please clarify what kind of issue is described?

Also, what do you mean by colored functions? The term seems ambiguous

Every variable in Python is actually a reference (maybe optimized out, but still logically a reference). There's no difference.

Numbers, booleans, and None won't give you that kind of problem only because you can't change them.

Everything's an object. A variable is a pointer to an object. var1 is a pointer to the object 1 (which is an integer). var2 is also a pointer to the same object. If you point var1 to a different object (the integer 2), that doesn't change var2. list1 is a pointer to the list object you defined. list2 is a pointer to the same object. If you change the object, both pointers still point to it.

At least that's my understanding of the whole business. If I got anything wrong, in sure somebody will point it out.

in first case it is pass by value. for list you are passing a reference.

https://www.geeksforgeeks.org/python/pass-by-reference-vs-value-in-python/

This. Collections (lists, dicts, tuples) behave a little differently than primitives.

It won't (using your example explicitly) but in general what you've discovered is that:

1. Variables hold values
2. Some of those values are references to shared mutable objects.

Lists fall into the second category. There are ways to copy lists if you want distinct behaviour.

list2 = list1[:]

will perform a "shallow copy". If you have a list of lists, however, the nested lists are still shared references. There is copy.deepcopy available to make a complete clone of something (including all its nested members).

Hum... No it won't.

It's something you only really learn from C or Rust, but your operations will set both to the same list. If you go and change the list, you will change both, but if you set one to a different list, you won't change the other list.

In other words, if you do list1.push(4), you will change list2. But list1 = [3, 2, 1] won't.

I'll preface that NixOS may not be for everyone, as deviating from a conventional hierarchical file system is a radical departure from conventional distributions; but for those that want precise control over their system environment, it has a good deal of appeal.

For example, I appreciate being able to use the latest bleeding release of a number of tools while sticking with older trusted versions of other utilities, but if both relied upon different versions of similar dependencies, such package conflicts can be troublesome to resolve, as few Linux package managers gracefully deal with multi version installs.

For NixOS using the nix store, installing leaf packages that traditionally conflict is trivial, and as a user, I can spend less time managing every transitive dependency in order to use the software I want. Not having to wait for a disjointed ecosystem of packages to synchronize around dependencies, or resorting to compromise in package version selection is very liberating.

• https://nixos.org/guides/how-nix-works/

The functional language and documentation for nix itself is a bit quirky, as I wish it was stronger typed, but being able to declaratively express and version control my setup across workstations has been a time saver; installing/configuring something once and then have-done with it.

ok fine lets talk about this Linux distro

Don't want to be a package manager database on my off hours. Why is having users manage every transitive dependency a good design?

I'm asking i really don't understand the merits of adopting this heavy burden

thank you for the history lesson

trio and anyio fixes that

One phrase not found in the article, colored functions

I would have liked the PyCon25 talk directly, but I don't think the recordings have been published yet:

https://slides.com/bittner/pycon25-nixos-for-python-developers#/2/4

Hopefully the presenter discusses more on their later slides in using python on NixOS and working around python packaging's use of dynamic linking.

This is a Linux post. Has nothing to do with Python

Yeah, a more modern take on mutexes (as boxes for values) and support for structured concurrency would be fabulous. Those are somewhat orthogonal to the goal of being able to write straight-line code without function colouring. Long ago, eventlet provided something like this [although it had smoe subtle and deep bugs that took a long time to track down].

Potentially, a major stumbling-block would be providing machinery so that interleaved FFI & python calls can cooperate (if that's determined as being in-scope, which it ultimately should be).

Free threaded came on the scene and packages slowly added support. So there is a will to gravitate towards and adopt what works. Albeit gradually.

I prefer typing_extensions over typing and collections.abc

With typing_extensions, new features are always backported. With Python features, have to continuously upgrade Python. Whatever you upgrade to is already guaranteed to be very temporary. It's much easier to upgrade a package.

For the same reasoning would prefer Trio over asyncio.TaskGroup.

Which leads to the question Trio vs asyncio.TaskGroup?

asyncio.TaskGroup is a py311 feature with context kwarg added in 3.13. The documentation is very terse and i'm unsure what guarantees it has, besides strong. Missed opportunity. Could have used the adjective, Mickey mouse. Both are essentially the same, useless.

Having to upgrade to 3.13 is what i call failure to backport or simply, failure or that's what failure looks like.

Give a free pass to free threading, but everything else, no!

Having to upgrade Python to have access to sane structured concurrency is silly. Have the exact same complaints about Package Managers.

The writer is not wrong about the awful ergonomics of having to deal with async. Project Loom took a long time to land but it really demonstrates how to do this kind of thing right.

This looks like the author wants Go's concurrency framework (i.e. green threads), with Rust's mutex system. I think that would be awesome!

My main concern is that it would require a massive reworking of Python's internals to provide concurrency-friendly IO. The author mentioned the example of OS files, but there are plenty of others, especially with third party libraries using native extensions.