Not true. Some LLM implementations can parse your prompt, choose search terms from it, search, read results, and parse results into a response.

https://www.technologyreview.com/2024/10/31/1106472/chatgpt-now-lets-you-search-the-internet/

search for w3schools

There's the Cpython Internals book, as well as Brett Cannon's Syntatic Sugar which I think might help with some of your questions (though admittedly, I'm just interested in data sciencey stuff)

An LLM doesn't do search. It regurgitates the statistically most likely next words based on its training data.

Do you mean function definitions? They are executable statements after all. Yes the Python environment is just a bunch of nested dictionaries. Whether there is bytecode is up to the implementation. If you want to understand how CPython works, the source code is not terribly mysterious if you know C. You will want to read the API document first.

For the language itself, the reference manuals are reasonably good.

For validation and/or (de)serialization: pydantic.

Otherwise, dataclasses.

I also like to replace tuples with NamedTuple, but I tend to use tuples a lot in the first place. It’s generally recommended to use dataclasses instead if you don’t specifically need tuple-like behavior.

I was going to comment this too

Depends on what you are trying to accomplish, pydantic is great for encoding/decoding

If you don't need that go with dataclasses

Keep it simple, stupid.

I'd use the built-in dataclass (or something even simpler) where possible. Only when I need more functionalities (e.g. validation) would I switch to using Pydantic model.

In terms of the standard principal programming paradigms, Python is on the right-hand side in the "Shared state" column. Note two interesting things: first, Python's box is represented by Java and OCaml; second, the box has two labels, "Sequential object-oriented programming" and "Stateful functional programming". Python is technically a prototype-based language like ECMAScript, but it can be seen as either object-oriented or functional depending on whether we think of prototypes as classes or closures respectively.

Note that unlike "Imperative programming", represented by Pascal and C, Python has closures. It does have closure quirk, also called lambda quirk, which ruins an otherwise-lexically-scoped language, but folks with lots of Python experience are used to working around closure quirk. Python functions are not procedures; they are sugar for objects with a .__call__() method.

If this is your first time with the principal paradigms, please keep in mind the following quotes. First, from the associated book:

More is not better or worse than less, just different.

That is, Turing-completeness doesn't have a canonical set of computational features. Second, from the chart PDF:

Two languages that implement the same paradigm can nevertheless have very different "flavors" for the programmer, because they make different choices on what programming techniques and styles to facilitate.

There is an expression, Linux isn't free it costs you your time.

Just because someone said it does not make it true and certainly, I don't have to live after that expression. It kind of is a catch all phrase to justify (or not to justify) everything. It could also be used as an argument for "Vibe Coding" (I hate that term...).

I mean this argument about Linux does not apply to every single application (you apply it right now here to some random Python script). In example Windows, MacOS, Android, nothing is free and costs you your time. The question is, how you want spent your time. And I enjoy writing programs and scripts for various reasons.

I personally think reinventing the wheel is great. Why? It makes you learn and do it. It makes you less dependent. The end result might not be the most polished one, but also if nobody reinvents the wheel, then we have no competition. Sure you should not reinvent everything, there is a balance act to make. And this balance is different for everyone else.

There is an expression, Linux isn't free it costs you your time. Which might be a counter argument against always using only what is built in.

I'm super guilty of reinventing the wheel. But writing overly verbose code isn't fun either. Never seem to get very far.

BTW, I'm not saying the way I am going and doing this is the right one. In the end I use additional packages when needed, BeautifulSoup as an example to make life really easier. But that is something specific to that script. Stuff like click and argparse is more than a single script, because when I switch to click then all my future scripts would depend on it. And I feel more comfortable with a solution that is already built-in (stdlib) if its not too bad.

I don't see click as a required package that I really need. And that is also true for many other packages, such as requests one.

people are forced to install dependencies

This ^^.

If possible, Python dependency management is a burden would prefer to avoid. Until can't, then be skilled at it!

disclosure: i use/wrote wreck for Python dependency management.

Compiled languages should really live within containers. At all cost, would like to avoid time consuming system updates! I can no longer install C programs cuz on OS partition ran out of hard disk space. Whereas Python packages can be installed on data storage partitions.

for Python, I usually deliver the script as a single .py file I'm sure you are already aware of this. So forgive me if this is just being Captain Obvious.

Even if the deliverable is a single .py file, there is support for specifying dependencies within module level comment block. (i forget the PEP #).

I don’t like that (unless its a shell script, but that is by its nature a dependency hell) You and i could bond over a hatefest on shell scripts, but lets leave this as outside the discussion scope

And your argument As the complexity of a .py script grows, very quickly, comes to a point the deliverable becoming a Python package. With the exceptions being projects which are: external language, low level, or simple. This .py script nonsense does not scale and is exceedingly rare to encounter. May be an indication of a old/dated or unmaintained project.

From a random venv, installed scripts:

_black_version.py
appdirs.py
cfgv.py
distutils-precedence.pth
mccabe.py
mypy_extensions.py
nodeenv.py
packaging_legacy_version.py
pip_requirements_parser.py
py.py
pycodestyle.py
pyi.py
six.py
typing_extensions.py

It's also a good way to structure your code to effectively model your problem domain.

And there are also many cases where that's not true, so use it where it makes sense and don't use it where it doesn't.

Could you elaborate on how information is the noumena?

Ah yeah I agree. Misread your comment.

Used it a ton in the art departments of vfx and game dev. Im talking about the tools that make assets, not the game engine or a runtime scripting language. More like the stuff launching and running in Maya, or Houdini, or Substance, etc.

Most of this is already highly OO, and there's a lot of interaction with C++. Python is the perfect language for this. There's a lot of rapid interation and gluing many different services and data together. Also you're waiting on file IO or some massive scene graph update all the time so having the tools be slightly slower doesn't matter. Also, at least in vfx, there's mixed Linux/Windows/Mac and it's great for that. ALSO art teams (unlike the programming team) have people who may not be super technical, and Python let's them write tools and scripts more easily. They don't even have to understand OO but you can say "copy this class template and implement these two methods" and they can write tools that "work" in the pipeline.

It's honestly a godsend. Before the industry settled on Python, every program had its own proprietary scripting language and some were quite limited. Their C++ APIs are all different, of course. So now everyone just ships with a Python interpreter, you manage launching each app so you can control PYTHONPATH and you're golden.

Python is good if you need to write a hundred or two or maybe three lines of code

Sooooo, any language?

Most of my objects are actually dataclasses.

My issue with Python is that so many "pythonic" practices lead to horrible-to-read code. List comprehensions are nice, except for when they go more than one level deep. kwargs leads to horrible code. Lots of valid Python code cannot be typed correctly, which makes editor inference far worse. Don't get me started on metaclasses and the like.

Python right now is basically what JavaScript was before TS.

I rarely use inheritance. Like i said, I see OOP mainly as a way to achieve cleaner code structure and better readability. That last point is really my main concern.

Python is good if you need to write a hundred or two or maybe three lines of code.

Its not good for large programs.

Conversely its good for large systems. Facebook makes all its microservices in python because the data model and how that scales along with data safety matters much more than a microservice taking 10-100 times as long to execute.

I consider it a scripting language. Just one without integer++ for some goddamn reason.

I like the cut of your jib