You mean softwares VLC, Linux, Python all came out of a monopoly position?

Or maybe you mean great greater than life concepts like the press, the Web or vaccines have been invented by big monopolistic entities?

Or do you mean unicorns like Google, Amazon and Facebook were born out of monopoly?

Managing multiple windows, copy/pasting, using shortcuts from muscle memory and things like instant middle mouse click are terrible experiences on any tablet or phone.

Just opening a new tab on a browser is tedious, and if you deal with a lot of intranet tools, this is the very basics of productivity.

> terrible experiences on any tablet or phone

It sometimes feel like an unspoken taboo, but windows tablets are a thing. Or Chromebooks if there is a strong need for mobile app support.

> using shortcuts from muscle memory

This statement is true if you use any machine other than the one you are used to, so this makes little sense. My Windows shortcuts and Linux shortcuts do not match my MacOS shortcuts. I have to use all three OSes at my job.

Well yeah, but consider that Apple has complete control over both systems. I also bought into the ‘iPad for days full of meetings’ idea and found that if I can’t reliably cmd-tab and browse through some files in a non-iCloud folder the whole experience is garbage. The fact that they bolted on some MacOS features afterwards only makes it all the more ludicrous that they didn’t go for parity from the moment they started with those shitty plastic keyboards.

>Just opening a new tab on a browser is tedious

There is a persistent top-level button in Safari's toolbar to open a new tab. I don't know how tedious that is.

I was wondering was was this for Rust.

Then I realized with maturin, that was Python :)

Nice. I should use a similar id with ULID.

Although, if stored in a DB, I would probably split the tag and the id in 2 separate columns, because DBMS often have a dedicated efficient UUID field type.

A little client code wrapper can make that transparent.

That's more of a cultural thing. Because Python is easy to get into, and you can be productive very fast, a lot of people with little experience in programming start to build things that are out of their reach.

They just don't know it, and the people hiring them don't either.

It's not a new phenomenon, we got the same when Java arrived, then PHP, etc.

Every time something makes things easier, you get a wave of beginners set to create things they are not qualified to do. And because you now need software for everything, leaders also get into positions where are not qualify to make some decisions about it. You pair unqualified leaders with unqualified devs, and you get this.

And it's now easier than ever to be in this position, also you are more pressured than ever to get into this position.

I've worked on plenty of big Python systems myself, it's not the tech per se (it has the usual pros and cons game like every language), but Python is the language used "when you don't know programming".

Which is ironic, because when I started to use it in Python 2.4, only passionate devs used it because it was niche, and we had the opposite effect.

> Every time something makes things easier, you get a wave of beginners set to create things they are not qualified to do. And because you now need software for everything, leaders also get into positions where are not qualify to make some decisions about it. You pair unqualified leaders with unqualified devs, and you get this.

How easy it is to call other people not qualified because they have different opinions.

I've seen more projects failed because the only thing the devs cared about was an abstract code correctness, which made even basic PRs getting polished for weeks. I don't think you need to worry too much about types or tests if you are just doing a prototoype to validate ideas or your user base is 0.

It is BASIC all over again.

I get where the author comes from, but my definition of simple doesn't include anything with the word "smart" in it.

I have simple watches. They are casio.

I have an Auriol. (I don't know for certain, but I like to imagine the brand is named after French rally driver Hubert Auriol.) It has a monochrome face, twelve simple hour demarcations, and two hands.

In its own way(s), that is actually quite a smart watch.

It also uses the file as a module, not a script, which means suddenly relative imports works the root dir and the cwd are the same, and it is added to sys.path.

This prevents a ton of import problems, albeit for the price of more verbose typing, especially since you don't have completion on dotted path.

It is my favorite way of running my projects.

Unfortunalty it means you can't use "-m pdb", and that's a big loss.

> which means suddenly relative imports works

Not just relative imports but also (properly formed) absolute imports. For example, if you have a directory my_pkg/ with files mod1.py and mod2.py, then

    # In my_pkg/mod2.py
    import my_pkg.mod1

will work if you run `python -m my_pkg.mod2` but will fail if you run `python my_pkg/mod2.py`

However, the script syntax does work properly with absolute paths if if you set the enviornment variable `PYTHONPATH=.` (I don't know about relative paths - I don't use those). That would presumably allow pdb to work (but, shame on me, I've never tried it).

I also develop and run projects this way. I really, really enjoy it. It's a very pleasant experience, on both the development side and execution side.

I'm relatively new to Python (used it for ~1 year in 2007/2008, again briefly in 2014 -- which is when I believe I picked this module trick up -- and then didn't touch it again until March of this year). It's made an impression on my team and we're all having a good time developing code this way. I do wonder, though, what other shortcomings might exist with this approach.

You can use pdb

Just

python -m pdb -m module

Damn, 15 years of python and I learn you can use -m twice. I've never even tried, didn't occur to me it would be supported.

EDIT: it support other options as well, like -c. That deserves an alias:

    debug_module() {
        if python -c "import ipdb" &>/dev/null; then
            python -m ipdb -c c -m "$@"
        else
            python -m pdb -c c -m  "$@"
        fi
    }

There's no magic, only layers. `python -m pdb <args>` runs pdb with the rest of the arguments. pdb handles the second `-m`.

If you have a fancy IDE feature, open a new python file, type "import pdb", use go to definition on pdb to jump to that file in the standard library, and read its main function - it handles -m explicitly :)

Speaking of pdb.. maybe someone knows why pdb has some issues with scope in its REPL that are resolved in VSCode's debugger and PyCharm?

Multiline statements are not accepted, nor things like if/for

Even list comprehensions and lambda expressions have trouble loading local variables defined via the REPL

Are there workarounds? It would reduce the need for using IDEs. People who have experience with Julia and Matlab are very used to a trial and error programming style in a console and bare python does not address this need

Not supporting multi-line statements is just because pdb doesn't bother to parse the statement to work out if it is an incomplete multi-line statement. That could be easily fixed (I have a prototype patch for that using `code.compile_command`).

The scope problems are more fundamental:

The pdb REPL calls[1] the exec builtin as `exec(code, frame.f_globals, frame.f_locals)`, which https://docs.python.org/3/library/functions.html#exec documents as:

"If exec gets two separate objects as globals and locals, the code will be executed as if it were embedded in a class definition."

And https://docs.python.org/3/reference/executionmodel.html#reso... documents that:

"The scope of names defined in a class block is limited to the class block; it does not extend to the code blocks of methods - this includes comprehensions and generator expressions since they are implemented using a function scope."

This is a fundamental limitation of `exec`. You can workaround it by only passing a single namespace dictionary to exec instead of passing separate globals and locals, which is what pdb's interact command does[2], but then it's ambiguous how to map changes to that dictionary back to the separate globals and locals dictionaries (pdb's interact command just discards any changes you make to the namespace). This too could be solved, but requires either brittle ast parsing or probably a PEP to add new functionality to exec. I'll file a bug against Python soon.

[1]: https://github.com/python/cpython/blob/25a64fd28aaaaf2d21fae...

[2]: https://github.com/python/cpython/blob/25a64fd28aaaaf2d21fae...

Oh, and multi-line statements will be supported from Python 3.13 (https://github.com/python/cpython/issues/103124)

There are not workaround, pdb is a rustic tool.

Since I still enjoy a cmdline debugger more than a graphical one, I use ipdb, which doesn't suffer from the multiline limitation.

However, scoping issues with lambda and comprehension are actually a Python problem, not a pdb problem.

After triggering pdb by having "breakpoint()" in tour python code and dropping in the debugger you can type "interactive" in the console to enter multiline strings.

TIL again. Very good thread!

It's "interact" though, not "ive".

You can exit it to carry on with the regular pdb.

Thanks. I make that mistake every time I use it:)

to be fair, it was only added in 3.7

Like whats the general usage though?

python -m http.server is the most I have done.

-m pdb is post mortem debugging, it drops you in the debugger when it encounters the first unhandled exception. This is much easier than trying to pin point where to put a breakpoint.

I've always been curious how that mechanism works exactly what is it about that invocation technique that satisfies the relative imports? I think it changes the pythonpath somehow right in a way related to the module being ran, something like appending the basedir where the module is saved to the PYTHONPATH?

I've taken to adding a --pdb option to my scripts.

What does it do? Just `import pdb; pdb.set_trace()`?

Or `breakpoint()` after 3.7 (better because the user can override pdb with ipdb or other with `PYTHONBREAKPOINT`)?

Either breakpoint() or setting sys.excepthook to call the postmortem debugger.

You started with the worse ORM in existance.

There are ORM with good pros/cons ratios out there. Python has espacially good ones:

- Django comes with a clunky and poor performing one, but it's very well integrated, super practical, productive and has nice ergonomics.

- Peewee gives you an ORM in a small package, which makes writing those little programs a joy when you don't need anything fancy, but feel lazy.

- SQLAlchemy requires a lot more investment, but is very flexible, generates clean SQL and has extremely correct behavior. It also exposes a lower level query builder for when you don't want the OOP paradigm and wish to express idiomatic SQL behavior, but abstracted away with Python.

This becomes a standard engineering decision, where you analyze the ROI.

I absolutely hated having to deal with SQLAlchemy. It took me days to get through the ugly documentation to a level where I could more or less competently use it, and for what? The code is harder to understand than just writing SQL and the performance is worse. I have yet to learn of a single advantage of ORMs that don't boil down to developers not wanting to deal with SQL.

Currently have to use sqlalchemy on an existing project, and while I am not necessarily disagreeing with you on ORMs or performance, just wanted to add that chatgpt has been able to reduce my time fighting with their documentation by what I estimate of 90+%. To be fair, if I would have written pure sql, I might not have needed chatgpt at all, but i also would have to learn pythons database connector calls for the umpteenth time.

ChatGPT can write SQL too.

Yeah, the productivity and performance with the Django ORM is amazing. I have trouble using any other web framework now...

The thing people are missing is relations. The most important aspect of your application is how data is related to each other. A good ORM makes that easy.

+1 on that. Handling relationships like parent.child.other_children when writing your own SQL is not trivial at all.

Two join clauses in a statement is not trivial? We apparently have different definitions for "trivial".

But if you want hierarchy (in Postgres), to_jsonb(…) is your friend.

It's much, much slower productivity wise than using the orm. Like 10x slower.

Why TF would I use json? There's a reason I picked a relational database. Nonsense.

It's so nice to use, espacially in a shell.

And also such a performance trap.

Yeah, but once it's a performance issue you're making $$$ and you can add some indexes or write a little SQL in the few places that need it :P

Also child.parents[0].user.username :)

Ruby on rails with active record is absoutly amazing. and anyone who hasn't tried it, haven't used a great ORM

Elixir’s Ecto smokes AR all day and every day. I never want to go back.

I love it.

Doctrine sucks too. Glad I'm using Django.

Yes, starting with Hibernate as a idea of what ORM provides is terrible.

ORM have plenty of flaws, but it's like buying screws on wish and saying using a screwdriver is a terrible experience.

Hibernate is not that bad. The problem with ORMs in the Java web space is lots of people used them as an 'extreme DRY' solution to link database 'objects' to the front-end which breaks separation of concerns and forces you to use the same model or resort to ugly hacks for further mapping. In a properly separated application it works fine.

It's an android app, not iOS.

Ah, got tricked by the quote that was comparing safari on ios with kiwi on one plus 6.

Once Apple becomes flexible on the web engine, it will be nice to see Kiwi go to iOS