Powerbank is a wrong keyword here, what you want to look for is something like “USB-C power supply with battery”, “USB-C uninterruptible power supply”, etc.

Lots of results on Ali for a query “usb-c ups battery”.

I wonder if it’s possible to compile Postgres directly into a Python extension instead of WASM. Just import it and go forth, no node dependency, nothing.

This is something I've explored as part of my work on PGlite. It's possible but needs quite a bit of work, and would come with some limitations until Postgres upstream make some changes.

You will need to use an unrolled main loop similar to what we have in PGlite, using the "single user mode" (you likely don't want to fork sub processes like a normal Postgres). The problems come with then trying to run multiple instances in a single process, Postgres makes heavy use of global vars for state (they can as they fork for each session), these would clash if you had multiple instances. There is work happening to possibly make Postgres multi-threaded, this will solve that problem.

The long term ambition of the PGlite project is to create a libpglite, a low level embedded Postgres with a C api, that will enable all this. We quite far off though - happy to have people join the project to help make it happen!

wow, thanks! it should be feasible! and as I recall there are such thing from some databases(chromadb, milvus-lite) in the py-first communities.

we could think big to someday do that within py-pglite project actually.

let me put it as the roadmap of v2(much more work to do!)

Can you explain this? What is the compilation target? What is the compiler? How does being a "python extension" help?

the target would be just baremetal binary with some changes needed and the purpose was just to be python dx optimized

This is a pretty simple and useful feature. I wouldn’t say that it bloats the language too much. Descriptors and metaclasses are much more complicated and have a lot more implications and have been in the language for a veeeeery long time. Is it decades already?

This feature is not complicated, but one must keep every feature that can possibly be seen in code in their head. Even if it is familiar now, what happens when you use the feature in the one small section of code where it fits, nowhere else, and then read that code 2 years later? This is the problem with adding useful features that are only used in a few key places. I'm not saying Go is a perfect language, far from it, but limiting # of features as a general goal is something more languages should strive for IMO.

I am not arguing against that language ideally should have less features. I am arguing with “Python is getting huge”, because it’s huge and has been for many-many years :)

True - cat is well out of the bag at this point

Yeah, Python hasn’t been a simple language for a long time, if ever. That’s probably the biggest misconception about the language - that its friendly syntax implies simple semantics. It’s not true at all.

I would say python in it's entirety is one of, if not the deepest and potentially most complex language I know. C++ is the other contender. The things you could do with metaclasses, multiple inheritance and operator overloading are quite staggering.

I'm just glad you don't have to think or even use this as a normal user of the language, most of the time or at all.

A lot of Python's complexity like descriptors and metaclasses and the so-called cooperative multiple inheritance come from an era where object orientation is gospel and yet people keep finding limitations to what can be accomplished in an OO paradigm and therefore they patch up the language to support ever more complicated use cases.

I have a feeling that if metaclasses and descriptors were to be proposed today it would be laughed out of the PEP process completely.

> I have a feeling that if metaclasses and descriptors were to be proposed today it would be laughed out of the PEP process completely.

I think you need at least one of these. Modern Python eschews metaclasses but descriptors are everywhere. Without them you couldn’t have @classmethod, @staticmethod nor @property - or at least, you couldn’t generalise custom method lookup and all three of those would need to be special cases.

The alternative approach is to drop descriptors and make method lookup much simpler, but then you need metaclasses (see: static methods in Ruby).

If descriptors didn't exist in the language, classmethod, staticmethod, and property would become keywords. Languages like Java and C++ already have static as a keyword; C++ also made its type system have a special pointer to member type; such behavior can be hardcoded without having a flexible descriptor mechanism.

Custom method lookup would just be the same as custom attributes, that is, by the user overriding __getattr__.

GP commenter complains that it’s not AI that came up with an idea and implemented it, but a human did.

In the few years we will see complaints that it’s not AI that built a power station and a datacenter, so it doesn’t count as well.

Some people already said it’s useless to learn to program because AI will do, that‘s the hype of AI not that AI isn’t useful as such like parent comment suggested.

They push AI into everything like it’s the ultimate solution but it is not instead is has serious limitations.

Just spent 10 minutes playing it, looks pretty fun!

If you formulate the warnings just right, you wouldn’t need to “force” it, as kids will be willing to look both sides themselves. They like to be alive.

Any age. There is no right age to jump out of the window on the 10th floor, no right age to cross a busy interstate by foot, no right age to set a bed on fire. You wouldn’t allow a kid to do it (and similar things) at any age. Would you? :)

Yep, it works for majority of children, but not for all of them. Folks that had a couple of kids with whom it did work spread it as a gospel.

You can try many other things, and maybe you’ll find something that works some of the time.

“What do you want?” can be “NOTHING!”, can be something. “You want this, but the reality is this and that. How can we deal with that?”

If kid is upset it usually helps to validate their feelings first.

Also, my kids are not yours, so take this with the grain of salt as well.

The world is much smaller than it was 200+ years ago.

I would argue that it was much bigger at that time. How many days of sailing would it take to cross the ocean? How undeveloped was the entirety of what we now have as the US?

Edit: I'm a fool and read the parent completely incorrectly. Ignore this comment.

That is the parent's meaning.

Thanks, I read it wrongly.

If the world is smaller today then it means it was bigger at that time. What are you confused about?

Thanks for pointing this out, I misread the parent comment.

That is a really neat library! Can see myself using it quite a lot.

Yep, it's quite handy for complex reporting. An original motivation was to disentangle a 1.5k lines (SQL + corresponding python code to assemble the query) of almost identical clickhouse queries. There were two big almost similar data tables with own dictionary relations. And there is a bunch of reporting with complex grouping and filtering. Around of 20 report instances. Each report was a separate monstrous SQL.

Schema changes were quite often and reports started to rot up to the point of showing wrong data.

After refactoring it became 200 lines and allows to query more reports due to increased generality.

Haven’t seen a mention in readme, but I’ve found in the sources some nicety for INSERT/VALUES too!

BTW, if you are interested there is an application of sqlbind in a non reporting context (https://github.com/baverman/wadwise/blob/main/wadwise/model....)

It's a small app with an attempt (and a goal) to model persistence without ORM. I think it suits quite well, could be fully type hinted (with some raw force though) and somewhat less verbose in this particular context.

But also I see how it could be a maintenance hell for a medium/large scale apps.

Yeah! With SQLAlchemy as a query builder I can easily find all usages of a particular column with Find Usages action in PyCharm. With strings it’s not as easy, and some columns are not really greppable (id, author_id, user_id, etc).

Also, haven’t seen how sqlbind handles optional JOINs and especially optional LATERAL.

In this case it's hard to make something fancy :)

    from sqlbind import WHERE, FIELDS, join_fragments

    q = Q()  # a QueryParams factory
    fields = []
    joins = []
    filters = []

    if some_condition:
        fields.append('sub_table.field')
        joins.append('INNER JOIN sub_table ON (subid)')
        filters.append(q.sub_table.date > since)

    sql = f'''\
    SELECT {FIELDS('table.field', *fields)}
    FROM table
    {join_fragments(' ', joins)}
    {WHERE(*filters)}
    '''

Personally I prefer this explicitness to ORM for complex queries which include recursive or multiple joins to the same table.

But I agree ORM shines with simple joins especially if models include proper relationship and there is no need to specify 'ON' condition every time.

Whenever we do recursive, or really long queries (not often), we’re dropping to basically raw SQL with sqlalchemy.text(). It’s really a lot to keep it wholly in SQLAlchemy: write a complex query in SQL, convert to SQLA, and remember how all the moving parts should be connected.

Should be much easier now with LLMs, though :)