Show HN: A Python Job Board for Python Developers
Article URL: https://www.pycareer.io

Comments URL: https://news.ycombinator.com/item?id=36860953

Points: 574

# Comments: 1 ⌘ Read more

@prologic@twtxt.net It was super useful if you needed to do the sorts of things it did. I’m pretty sad.

At its core was Sage, a computational mathematics system, and their own version of Jupyter notebooks. So, you could do all kinds of different math stuff in a notebook environment and share that with people. But on top of that, there was a chat system, a collaborative editing system, a course management system (so if you were teaching a class using it you could keep track of students, assignments, grades, that sort of thing), and a bunch of other stuff I never used. It all ran in a linux container with python/conda as a base, so you could also drop to a terminal, install stuff in the container, and run X11 applications in the same environment. I never taught a class with it but I used to use it semi-regularly to experiment with ideas.

Quiero mantener una sesión por largo plazo (para no tener que estar poniendo el Password todo el tiempo).

Debido a que esta herramienta de twtxt tiene la intención de que cualquier persona pueda auto-hospedar su propio twtxt.txt, ví que lo más ‘fácil’ y universal es tener un servidor con PHP 7.3+, como un Shared Hosting.

Despliegues con Python, Go, etc. podrían requerir más configuración.

Quiero mantener una sesión por largo plazo (para no tener que estar poniendo el Password todo el tiempo).

Debido a que esta herramienta de twtxt tiene la intención de que cualquier persona pueda auto-hospedar su propio twtxt.txt, ví que lo más ‘fácil’ y universal es tener un servidor con PHP 7.3+, como un Shared Hosting.

Despliegues con Python, Go, etc. podrían requerir más configuración.

bueno, me he entretenido un montón creando un CLI en Python para los OTP pues el que usaba hecho en Go, se ha quedado muy corto.

Con ayuda de ChatGPT para encender una chispa, y unas búsquedas para corregir cosas, ha quedado en una hora. 🤔

bueno, me he entretenido un montón creando un CLI en Python para los OTP pues el que usaba hecho en Go, se ha quedado muy corto.

Con ayuda de ChatGPT para encender una chispa, y unas búsquedas para corregir cosas, ha quedado en una hora. 🤔

According to the RedMonk programming language rankings from Jan 2023, Go and Scala are tied at 14th place 😏

1 JavaScript
2 Python
3 Java
4 PHP
5 C#
6 CSS
7 TypeScript
7 C++
9 Ruby
10 C
11 Swift
12 Shell
12 R
14 Go
14 Scala
16 Objective-C
17 Kotlin
18 PowerShell
19 Rust
19 Dart

Image

The EU’s Proposed CRA Law May Have Unintended Consequences for the Python Ecosystem (as well as the entire free software movement).

I played around with parsers. This time I experimented with parser combinators for twt message text tokenization. Basically, extract mentions, subjects, URLs, media and regular text. It’s kinda nice, although my solution is not completely elegant, I have to say. Especially my communication protocol between different steps for intermediate results is really ugly. Not sure about performance, I reckon a hand-written state machine parser would be quite a bit faster. I need to write a second parser and then benchmark them.

lexer.go and newparser.go resemble the parser combinators: https://git.isobeef.org/lyse/tt2/-/commit/4d481acad0213771fe5804917576388f51c340c0 It’s far from finished yet.

The first attempt in parser.go doesn’t work as my backtracking is not accounted for, I noticed only later, that I have to do that. With twt message texts there is no real error in parsing. Just regular text as a “fallback”. So it works a bit differently than parsing a real language. No error reporting required, except maybe for debugging. My goal was to port my Python code as closely as possible. But then the runes in the string gave me a bit of a headache, so I thought I just build myself a nice reader abstraction. When I noticed the missing backtracking, I then decided to give parser combinators a try instead of improving on my look ahead reader. It only later occurred to me, that I could have just used a rune slice instead of a string. With that, porting the Python code should have been straightforward.

Yeah, all this doesn’t probably make sense, unless you look at the code. And even then, you have to learn the ropes a bit. Sorry for the noise. :-)

On the topic of Programming Languages and Telemetry. I’m kind of curious… Do any of these programming language and their toolchains collect telemetry on their usage and effectively “spy” on your development?

• Python
  
• C
  
• C++
  
• Java
  
• C#
  
• Visual Basic
  
• Javascript
  
• SQL
  
• Assembly Language
  
• PHP

Estoy practicando Ruby con el libro Head First (muy recomendado), y me doy cuenta que es bastante diferente a otros lenguajes que conozco y me gustan como Python, JS, C#. Le estoy apostando sobre Go, PHP y otros. Espero sea buena decisión

@prologic@twtxt.net Error handling especially in Go is very tricky I think. Even though the idea is simple, it’s fairly hard to actually implement and use in a meaningful way in my opinion. All this error wrapping or the lack of it and checking whether some specific error occurred is a mess. errors.As(…) just doesn’t feel natural. errors.Is(…) only just. I mainly avoided it. Yesterday evening I actually researched a bit about that and found this article on errors with Go 1.13. It shed a little bit of light, but I still have a long way to go, I reckon.

We tried several things but haven’t found the holy grail. Currently, we have a mix of different styles, but nothing feels really right. And having plenty of different approaches also doesn’t help, that’s right. I agree, error messages often end up getting wrapped way too much with useless information. We haven’t found a solution yet. We just noticed that it kind of depends on the exact circumstances, sometimes the caller should add more information, sometimes it’s better if the callee already includes what it was supposed to do.

To experiment and get a feel for yesterday’s research results I tried myself on the combined log parser and how to signal three different errors. I’m not happy with it. Any feedback is highly appreciated. The idea is to let the caller check (not implemented yet) whether a specific error occurred. That means I have to define some dedicated errors upfront (ErrInvalidFormat, ErrInvalidStatusCode, ErrInvalidSentBytes) that can be used in the err == ErrInvalidFormat or probably more correct errors.Is(err, ErrInvalidFormat) check at the caller.

All three errors define separate error categories and are created using errors.New(…). But for the invalid status code and invalid sent bytes cases I want to include more detail, the actual invalid number that is. Since these errors are already predefined, I cannot add this dynamic information to them. So I would need to wrap them à la fmt.Errorf("invalid sent bytes '%s': %w", sentBytes, ErrInvalidSentBytes"). Yet, the ErrInvalidSentBytes is wrapped and can be asserted later on using errors.Is(err, ErrInvalidSentBytes), but the big problem is that the message is repeated. I don’t want that!

Having a Python and Java background, exception hierarchies are a well understood concept I’m trying to use here. While typing this long message it occurs to me that this is probably the issue here. Anyways, I thought, I just create a ParseError type, that can hold a custom message and some causing error (one of the three ErrInvalid* above). The custom message is then returned at Error() and the wrapped cause will be matched in Is(…). I then just return a ParseError{fmt.Sprintf("invalid sent bytes '%s'", sentBytes), ErrInvalidSentBytes}, but that looks super weird.

I probably need to scrap the “parent error” ParseError and make all three “suberrors” three dedicated error types implementing Error() string methods where I create a useful error messages. Then the caller probably could just errors.Is(err, InvalidSentBytesError{}). But creating an instance of the InvalidSentBytesError type only to check for such an error category just does feel wrong to me. However, it might be the way to do this. I don’t know. To be tried. Opinions, anyone? Implementing a whole new type is some effort, that I want to avoid.

Alternatively just one ParseError containing an error kind enumeration for InvalidFormat and friends could be used. Also seen that pattern before. But that would then require the much more verbose var parseError ParseError; if errors.As(err, &parseError) && parseError.Kind == InvalidSentBytes { … } or something like that. Far from elegant in my eyes.

JavaScript : web apps

wut?! 😳 seriously?! 🤦‍♂️

Python : small tools

Okay 👌

Go: micro services

Umm bad generalization 🤣 – Example yarnd that powers most of Yarn.social 😂

Java: enterprise software

Yes! Oh gawd yes! 🤣 And Java™ needs to die a swift death!

C: crimes

Hmmm? 🤔 I feel this one is going to have some backslash and/or go the way of “Hacker” being misconstrued to mean entirely different/incorrect things as is what’s happening in the media (for various definitions of “media”).

@movq@www.uninformativ.de I would not mind keeping a diff, if you tell me where to make the changes! I know nothing of Python, and I have spent already a couple of hours trying to make sense. I know it is there, in front of me, if only I knew Python. 😩

friendship ended with python, sed is my new best friend

@lyse@lyse.isobeef.org (#hut4mnq) I am so sorry for you. I left my Java job for Go. Though through “restructuring” its become a Python job.