Just ask it to rewrite the shitty code you wrote in a language you barely understand to “follow standard best practices in <language>” or something like that and it will add advanced typing features, functional programming for iterables, advanced exception handling, proper concurrency handling, optimize control flows, use better equivalent functions, etc.

As long as you understand the foundations of these concepts in at least one language anybody can become pretty close to an expert in most languages instantly. Especially since most of them are C based and pretty similar

The output will sometimes change the logic but I mean that’s pretty easy to catch and fix

Rip C++ nerds that memorize the entirety of each releases manual to shave off 3ms in every single function

  • footfaults@lemmygrad.mlEnglish
    2·
    3 days ago

    It’s technically operator overloading, the wacky thing that Python allows you to do, is overload operators for base types like int which I’m not sure if other languages allow you to do for base types.

    • invalidusernamelol [he/him]@hexbear.netEnglish
      2·
      3 days ago

      That’s what I meant, you can modify the behavior of code by directly over riding the operator implementation for base types. What it really reveals is that Python int is not at all a C int or really any other int.

      Directly translating syntax without knowing that the Python type is so vastly different from say, the C type is a recipe for latent disaster.

        • invalidusernamelol [he/him]@hexbear.netEnglish
          1·
          3 days ago

          My favorite weird Cpython implementation detail is that -5 to 256 are pre-cached when the interpreter is initialized. So identity checks using those numbers return True, but return False for other numbers:

          >>> x = 1
>>> y = 1
>>> x is y
True

>>> x = 100000
>>> y = 100000
>>> x is y
False

          At least in newer versions of Python it screams at you for doing identity checks with integers

          • footfaults@lemmygrad.mlEnglish
            2·
            2 days ago

            Yes, but that is a common optimization, caching primitive types and common values. I believe the JVM has that behavior, as well as a couple Ruby implementations (MRI, possibly YARV but it’s been a while since I looked at Ruby implementations)

            • invalidusernamelol [he/him]@hexbear.netEnglish
              2·
              2 days ago

              Yeah, cashing the 8 bit values means using integer flags is a lot faster. Implementation details like that are always a kicker. Especially when Python’s syntax kinda makes you want to say “val is 1” since it’s more “human readable” than “val == 1”.

              This is actually abused for True and False too which are a subclass of integer with Sentinel values equal to 0 and 1.

              Since they’re technically different objects, True is 1 is False, but int(True) is 1 is True. True == 1 is True though.

              Basically every language with an interpreter will do stuff like this, but it’s usually not super well documented behavior as it’s considered implementation detail or private API stuff.

              • footfaults@lemmygrad.mlEnglish
                2·
                2 days ago

                Python’s syntax kinda makes you want to say “val is 1”

                I have absolutely had issues with this. My editor configuration python-mode raises an error about this via flake8 but ruff doesn’t didn’t raise an error about this (and I have enabled experimental settings) so my co-worker added code like this and it slipped through.

                Ruff now has a rule for it but I think I was a very early adopter where this hadn’t been implemented yet.

                https://docs.astral.sh/ruff/rules/is-literal/

                • invalidusernamelol [he/him]@hexbear.netEnglish
                  1·
                  2 days ago

                  Python 3.13 3.8+ now spits out a warning to stdout when you do this, it was a big enough issue that they had to bake a warning into the CPython interpreter lol.

                  But because it’s a big enough issue, it also means there’s probably tons of examples online of people writing code this way and that’ll be something you have to be actively watching for when using generated code.

                  The reasoning models would probably ping on some forum post about it, but because it’s technically valid Python code, there’s a good chance that it would see enough identity comparisons to integer literals to think it’s okay.

                  The hard part of programming always ends up being the undocumented implementation details like that. Syntax is easy once you can understand the structure, but it so easy to write something that technically works and passes the tests that will eventually fail spectacularly and be hard to find.

                  • footfaults@lemmygrad.mlEnglish
                    2·
                    2 days ago

                    100% agree with everything you’ve said. I think it really illustrates how Python has not really done a good job around memory management.

                    By which I mean, it has done it well enough where you don’t have to think about memory management normally and that actually ends up hurting you because the identity operator explicitly is about checking if two references point to the same object and people forget that, and then some interpreter optimizations around small integers make it so the is operator and equality operator behave the same for small values and people get a wrong impression about the identity operator.

                    I have the same problem with Python’s “pass by assignment” way of doing things where it’s not explicit enough for my liking. Don’t get me wrong, I understand what it is doing after 20 years using the language but I sort of appreciate C like languages where references vs values are more explicit with things like ponters.

                    Zig has been interesting to me, for this reason.