Earlier quoted context omitted.
As a mathy person myself, I find the OOP leaning difficult to think about. Better equational reasoning, better lambdas, fewer side effects to worry about, avoiding mutation so that I can define something and still know what it is later during runtime, those are what help me think clearly. To me OOP is about the furthest paradigm from math that I’ve used.
Its quite easy to avoid OOP though.
I'm switching to Python and actually liking it
691–700 of 718 posts
Re: I'm switching to Python and actually liking it
#692Earlier quoted context omitted.
As a mathy person myself, I find the OOP leaning difficult to think about. Better equational reasoning, better lambdas, fewer side effects to worry about, avoiding mutation so that I can define something and still know what it is later during runtime, those are what help me think clearly. To me OOP is about the furthest paradigm from math that I’ve used.
Well it’s not about math. Stick to lines of code, functions and modules for that. Use it for abstract data types, frameworks and modeling.
Re: I'm switching to Python and actually liking it
#693"And guess what's the de facto programming language for AI? Yep, that sneaky one." Is this referring at all to to PyTorch. If not, any guesses what the author has in mind "Not only because the syntax is more human-friendly, but also because the Python interpreter is natively integrated in all Unix distros." Is this referring to GNU/Linux. UNIX (UNIX-like) includes more than Linux; some UNIX distributions do not inclu…
>I do not use Python for this; I use a 19-line shell script (ash not bash), its startup time is faster Ash doesn't do web requests unless you've implemented HTTP in ash. You're back to using 3rd party dependencies that aren't installed on all systems
The TCP networking is done with orginal netcat reading the HTTP from a pipe.
The TLS is handled by a TLS forward proxy listening on the loopback.
The orginal netcat and other TCP clients I use, like tcpclient from djb's ucspi or tcploop from haproxy, are not part of the NetBSD base system but are easily added when I compile the OS. For Linux I use a custom distribution I make myself, without LFS. Busybox has ash and nc together in the same binary.
These TCP client programs are stationary targets, they will work reliably year after year, and small enough that I can store and compile them quickly even on computers with modest resources. Python is constantly evolving, a moving target, and much larger.
I wrote a utility in C89 that "implements HTTP" called yy025. This is produced using GCC, specifically flex, which is intsalled on all systems I use. flex is part of the NetBSD toolchain. It's a requirement for compiling the OS. It's a requirement for building many GNU userland utilities. It's even a listed requirement when building the Linux kernel.
yy025 is what I normally use in shell scripts when I need to generate HTTP. It reads URLs on stdin and outputs customised HTTP to stdout. There is no "third party dependency" for HTTP. This is a "first party" program. I wrote it.
But this script to fetch YouTube metadata doesn't use yy025. It's just some printf statements.
Re: I'm switching to Python and actually liking it
#694Earlier quoted context omitted.
> Oddly enough It's not that odd, since it's the only situation where you cannot keep it bounded, unless you enjoy having variables that may or may not be defined (Heisenberg variable?), depending on whether the exception has been raised or not? Compare with the if statement, where the variable in the expression being tested will necessarily be defined.
Are you saying that this should result in a name error? if : x = 5 print(x) #
Re: I'm switching to Python and actually liking it
#695Earlier quoted context omitted.
You don't generally want API keys accidentally recorded into someone's bash history.
What exactly is your threat model, where the attacker can read ~/.bash_history but can't execute (or capture output from) /usr/bin/env?
Re: I'm switching to Python and actually liking it
#696Earlier quoted context omitted.
For this example, don't just command line arguments. There's an API key there, you don't want an API key visible in your cmdline.
Then how would you SET the API key in the first place? :) The argument doesn't make any sense at all.
Re: I'm switching to Python and actually liking it
#697Earlier quoted context omitted.
Typer has a great feature that lets you optionally accept argument and flag values from environment variables by providing the environment variable name: https://typer.tiangolo.com/tutorial/arguments/envvar/ It's especially nice for secrets. Best of both worlds :)
No, that's an anti-feature. :) Sibling comments here claim that command line arguments "leak" whereas environment variables does not. It's plain wrong. An attacker with access to arbitrary processes' cmdline surely also has access to their environ. Store secrets in files, not in the environment. Now you can easily change secret by pointing the --secret-file parameter to a different file. The only reason people use BL…
Environment variables are substantially more secure than plain text files because they are not persistent. There are utilities for entering secrets into them without leaking them into your shell history.
That said, you generally should not use an environment variable either. You should use a secure temporary file created by your shell and pass the associated file descriptor. Most shells make such functionality available but the details differ (ie there is no fully portable approach AFAIK).
The other situation that sometimes comes up is that you are okay having the secret on disk in plain text but you don't want it inadvertently commited to a repository. In those cases it makes sense to either do as you suggested and have a dedicated file, or alternatively to set an environment variable from ~/.bashrc or similar.
Re: I'm switching to Python and actually liking it
#698Re: I'm switching to Python and actually liking it
#699Earlier quoted context omitted.
>I do not use Python for this; I use a 19-line shell script (ash not bash), its startup time is faster Ash doesn't do web requests unless you've implemented HTTP in ash. You're back to using 3rd party dependencies that aren't installed on all systems
For this script I have "implemented HTTP" using printf, an ash builtin. The TCP networking is done with orginal netcat reading the HTTP from a pipe. The TLS is handled by a TLS forward proxy listening on the loopback. The orginal netcat and other TCP clients I use, like tcpclient from djb's ucspi or tcploop from haproxy, are not part of the NetBSD base system but are easily added when I compile the OS. For Linux I us…
One could thus argue that there is a TCP client "installed on every system".
For me, what is more important is an installed copy of GCC. I have yet to use a UNIX-like system that did not have the needed networking functions to create a basic TCP client.
Re: I'm switching to Python and actually liking it
#700Earlier quoted context omitted.
No, that's an anti-feature. :) Sibling comments here claim that command line arguments "leak" whereas environment variables does not. It's plain wrong. An attacker with access to arbitrary processes' cmdline surely also has access to their environ. Store secrets in files, not in the environment. Now you can easily change secret by pointing the --secret-file parameter to a different file. The only reason people use BL…
This is bad advice. Please don't make claims about security if you're making it up as you go. Environment variables are substantially more secure than plain text files because they are not persistent. There are utilities for entering secrets into them without leaking them into your shell history. That said, you generally should not use an environment variable either. You should use a secure temporary file created by…