Live data from Hacker News

Python string literals are kinda funny

sebsite.pw

61–67 of 67 posts

Re: Python string literals are kinda funny

#61

Earlier quoted context omitted.

It's been a long time since I've had to SSH into a box to fix an issue in production. But it is comforting to know that I _could_. VI (not even VIM) on minimal Debian installs does not have syntax highlighting.

How often do you have SSH access to a box but don't have SFTP access? Most IDEs support editing files on a remote machine through SFTP.

It would be scp, not sftp, but I often don't know what I'm about to edit until I get in there and dig around.

Re: Python string literals are kinda funny

#62

Earlier quoted context omitted.

How often do you have SSH access to a box but don't have SFTP access? Most IDEs support editing files on a remote machine through SFTP.

It would be scp, not sftp, but I often don't know what I'm about to edit until I get in there and dig around.

No, I was talking about SFTP, not scp. OpenSSH server has SFTP enabled by default. You can mount it using sshfs or browse it using any SFTP client (or any program with embedded SFTP client, which is most IDEs).

So, if "digging around" means looking at folders' structure, you can do it through SFTP without copying everything (unlike scp or rsync).

And if digging around means running commands, nothing prevents you from having a session for running commands open in parallel.

Re: Python string literals are kinda funny

#63
post #6
post #4

Whenever I'm building a JSON document, I revert to the old %s syntax just because it's more tidy than an f-string.

Am I understanding that you’re building JSON with string interpolation? If so any special reason you wouldn’t build a dict and json.dumps() it?

When there is a multiline template, you can make it look natural within

json_doc = '''{}''' % some_dictionary

and then populate json_doc via %(some_dictionary_key)s values inside of the brackets.

I find it more readable.

Furthermore, json_doc can now live elsewhere, if sizeable, and get imported.

I guess that template strings may be the newer way to do this, but this is very backward compatible.

Re: Python string literals are kinda funny

#64

Earlier quoted context omitted.

It would be scp, not sftp, but I often don't know what I'm about to edit until I get in there and dig around.

No, I was talking about SFTP, not scp. OpenSSH server has SFTP enabled by default. You can mount it using sshfs or browse it using any SFTP client (or any program with embedded SFTP client, which is most IDEs). So, if "digging around" means looking at folders' structure, you can do it through SFTP without copying everything (unlike scp or rsync). And if digging around means running commands, nothing prevents you from…

I block [s]ftp at the firewall and disable it. I also keep ssh open only after port knocking. After reading logs and such, it's easier to open files with copy and paste via screen or tmux. Or even `Atl-.` depending on what I'm doing, framework, etc.

Re: Python string literals are kinda funny

#65

Earlier quoted context omitted.

No, I was talking about SFTP, not scp. OpenSSH server has SFTP enabled by default. You can mount it using sshfs or browse it using any SFTP client (or any program with embedded SFTP client, which is most IDEs). So, if "digging around" means looking at folders' structure, you can do it through SFTP without copying everything (unlike scp or rsync). And if digging around means running commands, nothing prevents you from…

I block [s]ftp at the firewall and disable it. I also keep ssh open only after port knocking. After reading logs and such, it's easier to open files with copy and paste via screen or tmux. Or even `Atl-.` depending on what I'm doing, framework, etc.

How exactly do you block sftp at the firewall if it uses the same port as ssh? From the firewall's perspective it is just some encrypted traffic inside ssh tunnel. I think that you might be mistaking sftp with ftps (ftp through ssl/tls tunnel), these are different protocols. I suggest you try connecting to any box you have access to using Sftp protocol and ssh credentials and see the result.

Re: Python string literals are kinda funny

#66

Earlier quoted context omitted.

I block [s]ftp at the firewall and disable it. I also keep ssh open only after port knocking. After reading logs and such, it's easier to open files with copy and paste via screen or tmux. Or even `Atl-.` depending on what I'm doing, framework, etc.

How exactly do you block sftp at the firewall if it uses the same port as ssh? From the firewall's perspective it is just some encrypted traffic inside ssh tunnel. I think that you might be mistaking sftp with ftps (ftp through ssl/tls tunnel), these are different protocols. I suggest you try connecting to any box you have access to using Sftp protocol and ssh credentials and see the result.

I completely forgot that sftp is on 22. Like I said, I block the port until it is properly knocked. In any case, I usually don't need the convenience of an IDE. It's much easier for me to just do everything over ssh. My IDEs (Jrtbrains, VS Code) use VIM keybindings too. And I could just as easily apt get vim on the server.

In any case, it's literally been years since I've had to.

Re: Python string literals are kinda funny

#67
In his 2017 PyCon Israel keynote, "The Fun of Reinvention", Dave Beazley made a wonderfully mischievous case for taking advantage of new Python features instead of making every new project carry the accumulated baggage of old Python versions.

Talking about Python 3.6, he said it was "probably one of the most major Python releases that has ever been made." His demonstration intentionally used new features that made the code incompatible with older interpreters. This was a prototype, so why not use the interesting new tools?

He was especially enthusiastic about f-strings: "F-strings are just awesome."

I was originally skeptical about them, but he convinced me to reconsider. One implementation detail that later helped win me over was that CPython 3.6 added dedicated FORMAT_VALUE and BUILD_STRING opcodes for f-strings. That does not mean an f-string is faster than simply doing a + b when both values are already strings -- simple concatenation usually wins that particular race -- but f-strings are generally cleaner, and often faster than older formatting machinery such as str.format().

I agree with his argument. There are vanishingly few situations in which a new project genuinely must support ancient Python releases. If your employer refuses to let you use a reasonably current version without a concrete technical reason, that is a warning sign. Life is too short to program indefinitely for obsolete interpreters.

The keynote:

https://www.youtube.com/watch?v=js_0wjzuMfc

Beazley's other talks:

https://www.dabeaz.com/talks.html

Post reply on HN