29 ms·

I'm switching to Python and actually liking it

• elemcontrib 1y ago
  I don't see how the OP layering utilities on top of python remediates on the claim that the language is not "production ready". Which it clearly is.
• messe 1y ago
  > the Python interpreter is natively integrated in all Unix distros It's included in the default install of most desktop/server Linux distros (with plenty of exceptions), but I don't believe any of the BSDs ship it in their base system. IIRC macOS used to have python 2 in its default install, but I vaguely recall that being deprecated and removed at some point. My only Mac is on the other side of the country at the moment, so I can't check myself.
  • blitzar 1y ago
    I dont think python is pre-installed on macOS now. (uv has replaced it for me) Edit: Unlike older versions of macOS that came with Python 2.7 pre-installed, newer macOS versions (Catalina and later) no longer include Python pre-installed.
    • oneeyedpigeon 1y ago
      macOS dropped PHP recently too—doing a wonderful job of losing all that developer share that Apple was slowly building up.
      • frizlab 1y ago
        Why? Installing python and php can be done in 2 seconds with brew, and you have control over what you install instead of using whatever is in the system, with deprecated versions, etc. It is actually much better now. System tool should be left to the system.
      • est 1y ago
        if you install commandline tools there's /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/
      • wiseowise 1y ago
        Virtually zero professional developers that I know use built in Python or PHP. Maybe it’s good enough for occasional scripting purposes, though.
      • stby 1y ago
        I much prefer installing it myself, with the required version for my project and at a known and common location.
        • oneeyedpigeon 1y ago
          That's fair enough. It may be less of an issue for experienced developers, but for those looking to learn the craft, it's one more barrier.
      • comradesmith 1y ago
        I think it’s better for developers to not have conflicting system distributions. Though for a while there having built in interpreters was great for kids and learners.
    • latexr 1y ago
      Technically macOS doesn’t come with Python pre-installed, but it does provide you with a simple path to do it. https://news.ycombinator.com/item?id=44580198 https://news.ycombinator.com/item?id=44580198 The removal was in Monterey. Catalina and its successor Big Sur very much still had it. Catalina was the one that removed 32-bit support.
      • tovazm 1y ago
        I think they realised the security implications, you could just take a random person macbook, open the terminal and launch python3 -m http.server 3000 --directory ~ then on the local network you could download all his files
        • latexr 1y ago
          If you have access to their MacBook and can open a terminal, even `rsync` (which comes preinstalled) would do the job. It seems much more likely to me they were just tired of having to manage the languages (and being constantly criticised they were behind) and simply chose to remove them.
        • icedchai 1y ago
          This doesn't make much sense. With physical access, I could easily just download python and do the same thing. Or anything else.
  • latexr 1y ago
    Python 2 was removed in Monterey 12.3, which was incredibly stupid and disruptive as it caught everyone by surprise. We all knew Apple said they would remove it, but everyone was expecting them to be sensible and do it on a new major OS release, like they did with PHP, not mid-cycle. https://developer.apple.com/documentation/macos-release-notes/macos-12_3-release-notes#Python https://developer.apple.com/documentation/macos-release-note... I wonder if that kerfuffle is why they ended up not removing Ruby and Perl yet, despite the same promise. macOS’ Ruby is around 2.6. Perl I somehow doubt they’ll get to, as it’s such an important part of Unix admin I bet they themselves use it somewhere. There is still a /usr/bin/python3 which is a shim. When you call it, if you don’t have the Xcode Developer Tools you’ll be asked to install them (it’s a non-scary GUI dialog which takes two clicks) and then you’re set. That is also a few versions behind the cutting edge, but it does get updated sometimes.
    • WesolyKubeczek 1y ago
      I think that by now we shouldn’t take a .0 major release as a sign of what is really going to be present in macOS and what’s not. The OS stabilizes around .4 or so, and in the meantime some deprecated things may get removed, too. They also have a habit of sometimes add or change some APIs mid-cycle, so you may see requirements for the latest Xcode being a mid-cycle version of the OS. Or how was it with Mac App Store, that not only itself, but the relevant APIs for programs distributed in it appeared in 10.6.4?
    • icedchai 1y ago
      /usr/bin/python3 is showing 3.9.6 on my Sequoia 15.5. That seems... ancient. I'm using 3.13 for all my work and personal projects.
    • zahlman 1y ago
      > [Software that was officially EOL and no longer supported by the developer as of January 1, 2020 — even though they went back on that with an emergency patch in April] was removed in [an OS released on October 25, 2021], which was incredibly stupid and disruptive as it caught everyone by surprise [despite the fact that the intent to EOL that software was declared many years ahead of time, and that sunset date already represented an extension of multiple years to the usual release schedule]. I will never understand this. But then, I've been using Python 3 since 3.2 and my first reaction to that was a sigh of relief, and by the time I updated to 3.4 I was already wondering why everyone else was lagging behind on the switch.
• v5v3 1y ago
  "the second best language for any job"
  • tim-kt 1y ago
    Meaning the first best language depends on the job?
    • stefcoetzee 1y ago
      Of course :)
  • bravesoul2 1y ago
    There are many jobs where the .Net/Java/Go triad would be in the top 3. I lump them together as typed languages that are mainstream, performant, have a GC and a featured library.
    • eurekin 1y ago
      I'm at a java shop. All customer facing apps are in java. Our tools and glue code is mostly in python. Similar for data processing workflows
      • bravesoul2 1y ago
        Yes that might demonstrate the point. Would Python be your second choice for the customer facing apps?
        • eurekin 1y ago
          Unfortunately, might not be easy in practice. It took years of effort to pass some certifications and audits and I don't think adding another language could be recouped now
• reedf1 1y ago
  > Python has done a good job of hiding its legacy ugliness (such as __init__, __new__, and similar aberrations), swettening its syntax to accomodate developers with good taste. What exactly is the problem with __init__ or __new__? @dataclass is very nice syntactic sugar, but are we arguing here that having access to initializer/allocator/constructor dunder methods is "legacy ugliness"? This is the core of pythonic built-in aware python. Bizarre.
  • wiseowise 1y ago
    Bizarre is that you don’t consider it ugly. Kotlin: constructor is either part of class definition or keyword constructor. Ruby: initialize JS: constructor Python: ______new______, _______init_______ Literally this meme: https://knowyourmeme.com/memes/three-headed-dragon https://knowyourmeme.com/memes/three-headed-dragon
    • reedf1 1y ago
      I had honestly not considered that the author might have been talking about the visual aesthetic of the dunder methods themselves. Honestly that has me a bit stumped; all I can say is that if you don't like underscores, don't pick python.
    • t43562 1y ago
      You don't call __init__ directly so the ugliness is limited to the definition which seems fairly minimal to me. It seems to be a naming convention for methods that are not invoked by name anywhere and that's at least informative when you're reading the class definition. IMO this is less horrendous than e.g. go's insistence that exported functions are indicated by a capital letter - that really affects code using the module not just the definition.
    • NoboruWataya 1y ago
      I like that magic method names generally all follow the same form so it's obvious that they are magic methods and not intended to be part of the public API. Whether that form uses double underscores or something else doesn't really matter to me as they are not being called directly.
• smcleod 1y ago
  Python as a language is nice. Python's version and package management is nothing short of a nightmare.
  • est 1y ago
    Python's package management is OK. The main culprit is .so libraries Think JNI or cgo management.
    • t43562 1y ago
      Yes, I've never really understood the complaint about python packaging - building native code is not something that is ever easy to guarantee across multiple distributions and operating systems. Those native packages can be in any language and require any odd combination of tools to build. Who has truly solved that problem?
      • nikisweeting 1y ago
        wheels, conda, docker, firecracker, unikernel, flatpak
        • t43562 1y ago
          flatpak, docker ? i.e. include an almost complete distribution just to make one package work? but what if you want that package to work in the distribution you have now? What if you need 2 different packages that are in different flatpacks or different docker images?
          • staunton 1y ago
            Set them up, each in its own container, and use GRPC to communicate between them... (Not even kidding, I've seen people do this)
            • t43562 1y ago
• polotics 1y ago
  It's funny, I'm the opposite: LLMs have made it easy to draft something in Python, then translate to a more appropriate language for the target problem-domain, for example Go.
  • brabel 1y ago
    Agree . We had training to learn how LLM applications can be developed and it was obviously in Python. Never liked Python but between dependencies issues (the demo project used uv but somehow the author forgot to declare some dependencies which she probably had installed globally) which cost hours of everyone’s time, and the persistent magic going on (pipe operators that do nothing similar to unix pipes, wtf!, puydantic shit just to declare a data type with metadata and lots of things like this) nearly everyone immediately switched to a typed language like Kotlin (they have a nice AI framework) as soon as we got the basics of how things work.
  • LtWorf 1y ago
    Is go the language that doesn't include a module to do mmap and doesn't include a module to place binary data into a struct? If you want to read binary files, you can use C or python, but not go (unless you use segfault prone 3rd party libraries of very dubious quality, of course).
• revskill 1y ago
  So, i don't get it, now i still need to have a uv venv ?
  • akkad33 1y ago
    The principle of uv as much as I understand is to not tinker with virtual environments. With commands like uv run, uv sync etc you shouldn't have to worry about the virtual env and whether it's activated etc. if you are in a project, it will automatically pick up the right Python version . However if you want to do something not possible through those commands you can still get down to the virtual env. Plus for auto complete in IDEs you generally need to select the venv
    • mpeg 1y ago
      I use this vscode extension called "python envy" that changes venv automatically depending on which folder of a monorepo you are in, it's great! Wish vscode had it built-in
      • akkad33 1y ago
        Never heard of it, will try. Thanks
  • blitzar 1y ago
    You install uv not python, you use "uv run <file>" instead of "python <file>", you dont think about anything else.
  • Vaslo 1y ago
    If you are working in Data Science/ML its the best bet for handling dependencies in your project compared to the rest of the tools. Its use has exploded, especially because you can do ‘uv pip whatever’ if you insist on using pip.
  • zahlman 1y ago
    There's only one kind of Python virtual environment, and both uv and the standard library `venv` module make them (as does third-party support like `virtualenv`). The differences are in what gets put in them (aside from the actual packages you explicitly install), and in the interface for configuring that. In particular, the standard library defaults to bootstrapping pip, but you can easily skip that. And of course uv does not bootstrap pip, because it does pip's job (and much more).
• andrewstuart 1y ago
  Said with a note of surprise? Made me think this is probably normally a Ruby developer indoctrinated against Python. The article doesn’t seem to say what they have come from.
  • riffraff 1y ago
    It's in the footnotes, they're a java/javascript/R dev.
  • drewcoo 1y ago
    > Ruby developer indoctrinated against Python Ruby devs think about code differently. Like Perl, they embrace TIMTOWTDI. https://perl.fandom.com/wiki/TIMTOWTDI https://perl.fandom.com/wiki/TIMTOWTDI Also, there's a pride in writing elegant code as opposed to following "Pythonic" conventions. Excellence is not conformity. I use Python a lot more often now because it's seen as simpler and more approachable and easier to force compliance. I miss Ruby.
    • t43562 1y ago
      IMO "pythonic" is mostly about using the features the language has rather than trying to treat it as if it was Java or C++. Having said that, in reviews you do get lazy comments like "not pythonic" or "not best practises" which often boil down to the reviewer just not liking something and being too much of an *** to say why. This is supposed to be a total shutdown that you cannot argue with and it's the kind of thing that might put you off the term "pythonic" for life. "There should be one-- and preferably only one --obvious way to do it." This is probably the core thing you might have issue with but I think its not really about conforming in how you write your own code but about the thing you make being easy for others to use.
      • greener_grass 1y ago
        I love this sentiment: > There should be one-- and preferably only one --obvious way to do it. But I often don't think the Pythonic way is a very good way to do it. And this leaves you a bit stuck!
• bravesoul2 1y ago
  I like Python for the language, and for a lot of jobs the threading model limitations do not matter. Its a great language to get stuff done. I find the package management story challenging but I will try uv next time!
  • sudosays 1y ago
    If you haven't already you should check out uv: https://github.com/astral-sh/uv https://github.com/astral-sh/uv It solves a lot of the package management headaches for me.
  • rich_sasha 1y ago
    I resisted pipx, poetry, anaconda and probably some other things, as I didn't see the point over venv+pip. But uv is just so damn good, there's no going back.
    • gjvc 1y ago
      pipdeptree is all you need for many things, but uv is such a joy to use it's hard to resist, sure.
    • bootsmann 1y ago
      Feel like pipx walked so uv could run, it popularized the idea of abstracting the environment management away from the user.
      • zeppelin101 1y ago
        pipx is still the best tool for standalone utility type of packages: "yt-dlp", "glances" (like htop), etc.
        • asa400 1y ago
          You can, however, use uv for this, e.g., `uvx yt-dlp` works like it would in pipx. https://docs.astral.sh/uv/guides/tools/ https://docs.astral.sh/uv/guides/tools/
• Roark66 1y ago
  From what? It would be useful to mention towards the front of the post so we know what is the context in which you approach python. I've switched to python primarily (from perl) in early 2010s (I think my first "seriously" used version was 2.6. This is mostly for system management, monitoring, and data transformation /visualisation. Nothing fancy like AI back then in a work setting. I found the biggest impact was not so much on writing code but on it remaining readable for a very long time, even if it was created hastily "just get this working now" style. Especially in a team. Python is still one of my favourites and the first tool I reach if bash is not enough for what I'm trying to do.
• pyman 1y ago
  From what I was told, Python was originally seen as a Swiss Army knife for sysadmins. It started gaining more traction when Canonical adopted it as the main language for Ubuntu 4.10 in 2004. Then, in 2005, Guido van Rossum was hired by Google to work on Google Cloud. That opened the door for wider adoption in academia, since Python had strong math libraries and integrated well with tools researchers were already using, like Hadoop, right around the time big data and ML were starting to take off. Also, between 2005 and 2006, two important things happened: Ruby on Rails came out and inspired Django, which was starting to gain popularity, and web developers were getting tired of Perl's messy syntax. That's how Python quickly became a solid choice not just for server-side scripts, but for building proper web apps. In the meantime, another language that could be embedded directly into HTML was storming the web: PHP. Its syntax was similar to JavaScript, it was easy to pick up, lowered the barrier to entry for software development, worked straight out of the box, and didn't require thousands of print statements to get things done. The 3 Ps made history. According to programmers from 20 years ago, they were like religions. Each had its own philosophy and a loyal group of followers crusading online, getting into heated debates, all trying to win over more adopters. The new generation of devs is more pragmatic. These days it's less about language wars and more about picking the right tool for the job.
  • darkstar_16 1y ago
    > These days it's less about language wars and more about picking the right tool for the job You should talk to the Java advocates in my company :) The language wars are still around, it's just Java vs the rest now.
    • pyman 1y ago
      One of my colleagues, a retired programmer who spent 20 years at Microsoft, told my students that it used to be Java vs Visual Basic, until Microsoft brought in the big guns, like Anders Hejlsberg. That's when it turned into Java vs .NET, and things really started to heat up :)
      • wiseowise 1y ago
• t43562 1y ago
  I'm glad someone else discovered they can like python. I got forced to learn it for a project where I was proposing Ruby and the customer insisted on Python. This was years ago when Ruby was much slower. I was annoyed but I got used to it and here I am enjoying it many years later. I take issue with the description and use of make though! :-D What is the point of it if you're not going to use dependencies? One might as well just write a script with a case statement..... I'm adding smileys because I don't mean to be all that serious but I really do think that the failure of the youth of today to get to grips with Make is a sad reflection on our culture....... and get off my lawn, ok? :-)
  • pphysch 1y ago
    > One might as well just write a script with a case statement..... I started with this and evolved into simple flat Makefiles, because they're basically the same but Make feels more standard (there's a Makefile here vs. there's a random bash script here).
  • shmerl 1y ago
    Ruby's syntax is much nicer. I just can't stand the idea of using whitespace for scope delimiting.
    • dapperdrake 1y ago
      Ron Garrett noticed that emacs can use "pass" like a closing brace for auto-indenting. Genius.
    • pzo 1y ago
      I wish python had support for optional braces. Maybe time I copy some snippet or integrate some other project into mine and have to worry if someone using 2 spaces, 4 spaces or tabs.
      • shmerl 1y ago
        Yeah, but they seem to think it's a feature, not a hindrance. I don't really understand the idea.
• DataDaoDe 1y ago
  Python has done an impressive job over the years of making steady robust improvements. The typing and tooling has just gotten better and better. There are still plenty of problems though, imho async is still a much bigger pain than it should be (compared to other runtimes with a very nice experience like go or elixir, even dotnet has been less pain in my experience). Overall I like python, but it mainly boils down to the robust libraries for things I do (ML, Data munching/analysis)
  • dmz73 1y ago
    I don't know what I am doing wrong but nothing written in Python has ever worked for me. I download the .py repo from from github or wherever and try to run it - errors. I try to install missing libraries pip this and that - errors. I battle fixing endless error with dependencies and when the .py finally runs - errors - wrong version of whatever library or wrong patch of this or that or the "production ready" .py does not work correctly on Windows or single file script uses excel library that has changed in incompatible ways 3 times in 2 years. I Download all the files from the flashy looking web site and follow all the instructions to the letter - errors. Python is anything but "robust". It is the most fragile environment in the universe, worse than c, c++ and javascript put togeter, at least this is my experience with it.
    • vrighter 1y ago
      This is exactly my experience too. I avoid python software like the plague, because even when it does work, I can not rely on it continuing to work when python gets updated on my system.
      • zeppelin101 1y ago
        This is where uv comes in to save the day.
      • fastasucan 1y ago
        Ofcourse you can if you just learn to use it properly.
• latexr 1y ago
  > I started to code more in Python around 6 months ago. Why? Because of AI, obviously. It’s clear (to me) that big money opportunities are all over AI these days. I find this depressing. Not only are LLMs covertly reducing our ability to think and make decisions, they’re now also making people voluntarily conform to some lower common denominator. It’s like humanity decided to stagnate at this one point in time (and what a bad choice of point it was) and stop exploring other directions. Only what the LLM vomits is valid.
  • mrpopo999999 1y ago
    humanity tried to save time and allocate it to other pursuits, don't worry
  • bb88 1y ago
    Eh, I just wrote a chrome extension for the first time through AI. If it automates the boring stuff for us, I'm more okay with this than not.
• taosx 1y ago
  Unpopular opinion: I think I’m going to wait for version 4 /jk. But honestly, I’ve been spoiled by modern languages like Rust, Go, and even TypeScript with modern tooling, strong typing, stability, and performance out of the box. Right now, I’m just interacting with LLMs, not building them. That said, I remember writing myself a note a few years ago to avoid Python projects. I had to clean up code from all over the company and make it ready for production. Everyone had their own Python version, dependencies missing from requirements.txt, three way conflicts between 2 dependencies and the python version, wildly different styles, and a habit of pulling in as many libraries as possible [1]. Even recalling those memories makes my stomach turn. I believe constraints make a project shine and be maintainable. I'd prefer if you throw at me a real python instead of a python project. [1] Yes, I'm aware of containers, I was the unlucky guy writing them.
  • bigiain 1y ago
    > Unpopular opinion: I think I’m going to wait for version 4 In my personal timeline, people giving up waiting for Perl 6 were a huge source of early Python developers.
  • 1ncunabula 1y ago
    What makes TypeScript better than Python? I don't get it..
    • Philpax 1y ago
      Much more capable and reliable type system, paired with comparatively sane package management. This is getting better in the Python world (thank you Astral), but it's still not anywhere near the same.
      • Arch-TK 1y ago
        Not sure if it's worth selling your soul to Microsoft. I will stick to other languages when I need a better type system.
  • theLiminator 1y ago
• Surac 1y ago
  have fun!
• CoolCold 1y ago
  > Not only because the syntax is more human-friendly, but also because the Python interpreter is natively integrated in all Unix distros That's kind of very optimistic evaluation - literally anything beyond "import json" will likely lead you into the abyss of virtual envs. Running something created with say Python 3.13.x on Ubuntu 22.04 or even 24.04 (LTSs) / Rocky 9 and the whole can of worms opened. things like virtual envs + containers (docker like)/version managers become a must quickly.
  • nikisweeting 1y ago
    this is solved by uv
    • CoolCold 1y ago
      > things like virtual envs I consider my point as still valid with UV, what you wanted to express? On UV specifically - say 'asdf' compiles python right on your system from official sources - means using your ssl libs for example. UV brings Python binary - I feel worried on this.
      • charliermarsh 1y ago
        uv works just as well with whatever Python you want to bring -- you're not required to use the Pythons that uv is capable of installing on your machine.
    • jauntywundrkind 1y ago
      uv really is working super super super hard to absolve decades of sins and blood in the python world. and doing a good job at redemption.
  • acdha 1y ago
    “import json” is the kind of thing which requires picking and installing libraries in batteries-not-included languages, and it’s just one of many modules which are in the standard library. That’s not a compelling basis for large projects but over the years I’ve shipped a ton of useful production code which never needed more than the stdlib and thus spent no time at all thinking about deployment or security patching. Also, it’s not the 2000s any more. Using venv to isolate application installs is not very hard anymore and there have been decent package managers for a long time.
• igor47 1y ago
  Good write up, and solid choices. As someone primarily working in python in the last few years, I have a very similar stack. Two additional suggestions: * mise to manage system dependencies, including uv version and python itself * just instead of make; makefile syntax is just too annoying. Mise actually has a command runner as well which I haven't tried yet, and might work better for running commands in the context of the current environment. It's pretty nice when your GitHub actions workflow is just: * Install mise * mise install everything else
• flyinghamster 1y ago
  I've avoided Python for a long time, but I'm getting roped in myself, mainly because certain tasks seem to require a lot less code than Java or Perl. That said, call me old-fashioned, but I really take issue with "curl $URL | bash" as an installation method. If you're going to use an install script, inspect it first.
  • limagnolia 1y ago
    If your going to execute the code anyway, you either have to inspect everything or trust whoever is providing it. There is nothing special about bash that makes it more dangerous to execute than python.
    • flyinghamster 1y ago
      My issue is with $URL potentially getting hijacked, or even something like the kerfluffle over the PuTTY SSH client not residing at putty.org.
  • drdrey 1y ago
    do you also inspect binary installers?
• Mawr 1y ago
  Just a small note on the code in the linked script: API_KEY = os.environ.get("YOUTUBE_API_KEY") CHANNEL_ID = os.environ.get("YOUTUBE_CHANNEL_ID") if not API_KEY or not CHANNEL_ID: print("Missing YOUTUBE_API_KEY or YOUTUBE_CHANNEL_ID.") exit(1) Presenting the user with "Missing X OR Y" when there's no reason that OR has to be there massively frustrates the user for the near zero benefit of having one fewer if statement. if not API_KEY: print("Missing YOUTUBE_API_KEY.") exit(1) if not CHANNEL_ID: print("Missing YOUTUBE_CHANNEL_ID.") exit(1) Way better user experience, 0.00001% slower dev time.
  • casper14 1y ago
    [flagged]
    • deleted 1y ago
      [deleted]
    • johnisgood 1y ago
      [flagged]
    • wiseowise 1y ago
      I hope you’ll be stuck debugging “error happened” without stuck trace and “x, y or z” are missing forever.
      • 20k 1y ago
        My forever favourite error message is iverilog encountering a problem and simply printing: I give up
        • nyarlathotep_ 1y ago
          >> long running batch job 'process exited with status 1'
    • franktankbank 1y ago
• firecall 1y ago
  “I started to code more in Python around 6 months ago. Why? Because of AI, obviously. It’s clear (to me) that big money opportunities are all over AI these days. And guess what’s the de facto programming language for AI? Yep, that sneaky one.” Why is that? Why Python for AI?
  • johnisgood 1y ago
    Possibly because many available LLMs run your Python code in a sandbox, which means less friction for vibe coders, or it may be a contributing factor at the very least.
    • AlexeyBrin 1y ago
      > Because many available LLMs run your Python code in a sandbox, which means less friction for vibe coders. This is false, a lot of non "vibe coders" are using Python for AI because of PyTorch and a many other AI libraries have first class Python support.
      • johnisgood 1y ago
        How do you know that it is not the reason or not ONE of the reasons? Seems pretty reasonable to me to use ChatGPT, Claude, or whichever one supports it. I am pretty sure some people (maybe this individual, too) may be using Python because their scripts can be executed in a sandbox on one of these websites. Heck, if it was as good at Factor or Forth as it is at Python, I would be writing more of them, too. In any case, you cannot claim that it is not one of the reasons. Can you?
        • AlexeyBrin 1y ago
          I read your initial message, now edited, as this is THE reason. Of course it can be one of the reasons for which the author chose Python. Also the vibe coding part gave me the impression that you were implying that people that use/chose Python for AI are all vibe coders which is again false. Sorry if I misunderstood you, but this is what I got from your initial message.
• Hizonner 1y ago
  I wonder what the poor guy is switching from.
  • deleted 1y ago
    [deleted]
  • troad 1y ago
    Java, JavaScript, and R, according to a footnote in the article. Which - to be entirely honest - sharply coloured my view of the preceding article. "I went from being fully covered in mud to only being half covered in mud, and it's great! I don't understand why people complain about being half covered in mud."
• moribvndvs 1y ago
  I don’t understand “switching” to anything. The job picks the tool, not the other way around.
  • Bridged7756 1y ago
    I think it's mostly boredom-driven career choices.
• 1vuio0pswjnm7 1y ago
  "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 include Python in the base system Where it is left as choice to the user whether to install it I know this because I use such distributions and, unless some software needs it, I do not install Python In such case, when I am done using that software I uninstall it^1 For example, he mentions retrieving YouTube channel metadata I do not use Python for this; I use a 19-line shell script (ash not bash), its startup time is faster Unlike Python, it is included in the base system of the UNIX distributions (both Linux and BSD) that I use But if I need to test something using yt-dlp, then I might temporarily install Python 1. I compile Python from source and one annoying aspect of the project , in addition to the slow startup time, is their failure to include an uninstall target in their Makefile
  • deleted 1y ago
    [deleted]
  • megaloblasto 1y ago
    "And guess what's the de facto programming language for AI? Yep, that sneaky one." He's referring to Python in general "Not only because the syntax is more human-friendly, but also because the Python interpreter is natively integrated in all Unix distros." I think he means that its available or readily available in many major linux distributions like Ubuntu, Fedora, NixOS, etc. I don't think native is the right word. I use bash too but Python is amazing. You're right, there are problems related to packaging and speed, but it is still very often the right tool for the job. It's powerful, easy to use, and open source.
    • 1vuio0pswjnm7 1y ago
      "I use bash too but Python is amazing." I do not use bash. I use ash. Bash is too slow for me, like Python.
  • 1y ago
• ic_fly2 1y ago
  pydantic basemodel has made dataclasses redundant.
  • _Wintermute 1y ago
    Dataclasses have the one massive benefit of not being an additional dependency.
    • ddejohn 1y ago
      This. You also don't really need Pydantic unless you're de/serializing data from external sources. A dataclass is perfectly cromulent if you're just passing around data internally.
• yomismoaqui 1y ago
  Python is the 2nd best language at everything.
  • nilamo 1y ago
    And the first best is python3!
• catlover76 1y ago
  [dead]
• runjake 1y ago
  I really don't find the Python language elegant at all. I prefer the Ruby syntax. But Python's tooling, particularly with what Astral is doing (uv, ruff, ty), is so good, I'm always using Python and virtually never using Ruby. And yeah, the rich libraries, too.
  • machiaweliczny 1y ago
    Jupyter is also great thing in python ecosystem + colab etc.
• Arch-TK 1y ago
  Ubiquitous VSCode - honestly a tragedy.
• Night_Thastus 1y ago
  I love writing Python. However, there are caveats: 1: I don't like dealing with language crossing boundaries with it - it's painful, especially if to/from a compiled language - there's just too much friction. It's easy to write but hard to maintain. 2: Debugging python can be...painful. If you have a pure perfect environment dedicated to pure python and all the tooling set up, it can be breezy. But if you have something messier like C++ that calls Python or vice-versa and are using an editor not made for Python like QTCreator then suddenly it becomes hell. Who owns this data!? Where was this initialized!? What calls this function!? What type is this data!?!?!?!? These questions are so effortless in C++ for me and so very painful in Python. It slows efforts to a crawl. It feels exhausting to have to go back to print statements, grep, and hand-drawing a graph that shows what functions call what just to figure out WTF went wrong. It's painful to a degree that I avoid it as much as possible. ...and don't even get me started on dealing with dependency problems in deployments...
  • gh02t 1y ago
    I've long lusted after a smooth debugging workflow writing Cython that would let you seamlessly debug between Python and C/C++. I think there are some hacks to do it, but nothing really well integrated.
  • miguel_martin 1y ago
    Python debugging is great when you're strictly debugging Python code. Placing a `breakpoint` or spinning up an IPython instance to investigate the issue via `import IPython; IPython.embed()` makes life breezy. For neovim, you can send code to the ipython REPL easily via vim-slime. I've never found myself debugging the underlying C++ code unless developing a C++ extension. But is it really that hard? Just point lldb to the python process and run your script in lldb. If the C++ is not yours & assuming it's a mature lib (e.g. PyTorch): it's probably an error caused by you in Python land.
    • Night_Thastus 1y ago
      Both the C++ and Python are mine. I have cases of both C++ calling Python, and Python calling C++. Problems could be on either side. The problem is how to step into one from the other, you really can't as far as I know. The python parts aren't standalone enough that it could just be run on its own, there's so much setup involved prior to that point that it can really only be run from the top-level user controls.
• jlarocco 1y ago
  When did Python go out of fashion? This is the second article I've seen talking about it as if it's some kind abomination. I get that it's not the shiny new thing, but I don't understand people hating on it. Is this just junior devs who never learned it, or is there some new language out that I missed? (And please don't tell me Javascript....)
  • wk_end 1y ago
    Yes, I'd say Python's crown as the go-to lightweight scripting and web development language was mostly ceded to JS. It's still reigning champion of data science, and of course it has a huge number of uses and users still around, but it's not really cool or in vogue outside of those circles.
    • jraph 1y ago
      Do people really turn to JS (instead of Python) for lightweight scripting? Are we talking about the "better Bash" use case?
      • tempest_ 1y ago
        JS devs do, and there are a lot of them
      • ajkjk 1y ago
        that would be very surprising
      • roflchoppa 1y ago
        I mean if its really light weight, and I want to avoid bash, then JS is not too bad. The downside being that the built-ins are not really there compared to Python. The famous answer.... _it depends_.
      • machiaweliczny 1y ago
        I use "tsx script.ts" often and it's very nice good due to gradual typing you can use (plus I know lang well)
• whinvik 1y ago
  Out of curiosity, why would I use Dataclass vs a Pydantic Basemodel. If we did not have a PyDantic dependency I could imagine wanting to use Dataclass. But if I have it, why not use everywhere?
  • rsyring 1y ago
    To help answer your question, here's a detailed comparison from the attrs project: https://www.attrs.org/en/stable/why.html https://www.attrs.org/en/stable/why.html There's some obvious potential for bias there, but I thought most of the arguments were well reasoned. Edit: found another that I thought was helpful: https://threeofwands.com/why-i-use-attrs-instead-of-pydantic/ https://threeofwands.com/why-i-use-attrs-instead-of-pydantic...
  • intalentive 1y ago
    Performance hit from data validation at construction time. I like msgspec which is much leaner and faster.
  • lysecret 1y ago
    Main reason is (used to be) performance. But since pydantic 2.0 it’s not an issue anymore I default to use pydantic for everything.
  • maleldil 1y ago
    Unnecessary baggage if you don't need validation or serialisation. My rule of thumb is to use Pydantic if I need serialisation, otherwise I default to dataclasses.
    • globular-toast 1y ago
      This and not just for the performance reasons. A Pydantic model represents an I/O boundary of a program. This conveys a lot of information to a programmer reading the code. It would be quite misleading to find it's actually only passed around internally and never used for I/O. A bit like using an int type to store a Boolean value. On the other hand if I see a dataclass I can tell what it's purpose is by whether it's frozen or not etc. Always strive for self-documenting code.
• simonw 1y ago
  > I would like to have a tool that generates the project structure for me, but I haven’t found one that fits me yet. I recommend cookiecutter for this. I have a few templates I've built with that which I use frequently: python-lib: https://github.com/simonw/python-lib https://github.com/simonw/python-lib click-app: https://github.com/simonw/click-app https://github.com/simonw/click-app datasette-plugin: https://github.com/simonw/datasette-plugin https://github.com/simonw/datasette-plugin llm-plugin: https://github.com/simonw/llm-plugin https://github.com/simonw/llm-plugin You can run them like this: uvx cookiecutter gh:simonw/python-lib
  • timkpaine 1y ago
    Copier is the new hotness for this https://copier.readthedocs.io/en/stable/ https://copier.readthedocs.io/en/stable/
    • deleted 1y ago
      [deleted]
  • oezi 1y ago
    My take on this (using Ruby) is https://github.com/coezbek/baker https://github.com/coezbek/baker It doesn't copy template repos, but rather creates a list of imperative steps to perform. Steps can be both manual (obtain an API key and store it here) and automatic (run 'uv init'). Markdown syntax, ruby string interpolation and bash. It came from a deep hate for yml based configs.
  • mmcnl 1y ago
    Am I the only one who actually likes setting up new projects? I don't want to automate that.
    • serial_dev 1y ago
      It depends on your work, though… If you work at an agency or as a freelancer and you build various similar apps with similar tooling and base setup, being able to scaffold and have them all setup quickly, not having to do it manually and waste hours id important. Similarly, if you work on various small open source packages, you want the tooling to be the same, READMEs look the same, etc, a script or tool to “spit out” the basic structure can be nice. On the other hand, if you set up the app or larger open source package and you’ll work only on that project for potentially years, setting up a project individually, organically makes a lot of sense.
• manofmanysmiles 1y ago
  I make projects following almost identical patterns. It's a little uncanny. Maybe the people in the python developer ecosystem are converging on a pretty uniform way to do most things? I though some of my choices were maybe "my own", it seeing such consistency makes me question my own free will. It's like when people pick a "unique" name for their baby along with almost everyone else. What you thought was a unique name is the #2 most popular name.
  • bobson381 1y ago
    as though subsurface pilot waves in every spectrum hold human egos as constituent particles - becoming-being lol
    • dapperdrake 1y ago
      It is the side of ice cream that makes all the difference for the improbability drive.
  • solumos 1y ago
    This sort of architecture has been in favor with python for at least 10 years or so, but I think you're right — the structure just makes sense, so many reasonable engineers converge on using it.
• vpShane 1y ago
  I recently switched to python as well, I went pure nodejs because JS is everywhere and its handy to know. Doing frustratingly, front and back end dev on personal projects gave me a lot of frustration and living in a firefox/chromium Console I asked Gemini code to generate the same skeleton stuff I was coding in nodejs, and did it perfectly in 1/8 of the code required. python's been maintained for years and is honestly a really easy syntax. for OS level things, python makes sense and is the defacto. right now I vibe code and skeletons and then determine what I want to add and add it manually. I'm enjoying the switch, maybe not as hardcore of a dev as many of you but it gives me the fix of having an engineering mind and being able to test things on the fly since I live in a terminal anyways. I agree with all the points. I do like however that I can do: def functionHere(something: str, someNumberOrSomething: int) Seeing all the "uv has made me want to use python again" posts got me in to it. glad I did.
• 0xbadcafebee 1y ago
  Maybe I'm the only one that finds Python simultaneously verbose and lacking? Either you need 500 dependencies to do something in a simple way, or you need dozens (if not hundreds) of lines to do trivial things. I avoid writing Python because there's so much bullshit to add. Much prefer Perl, I can actually get things done quickly. Python feels like programming for the sake of programming.
  • supportengineer 1y ago
    dang the backend is leaking old comments from 2007
  • mystifyingpoi 1y ago
    Could you share an example, where Perl is quicker to use and more powerful?
    • lucb1e 1y ago
      And not write-only (https://handwiki.org/wiki/Write-only_language https://handwiki.org/wiki/Write-only_language)
    • const_cast 1y ago
      Using it as a replacement for Bash. No environment required, Perl is already installed on every computer on earth. Perl is generally quicker to write for string-oriented workflows - which is what Bash is. Regex is quick and easy. Perl falls apart when you need structure and even small projects. For short scripts meant to do what you would use Bash for, it's a godsend. Safer, more portable, less friction.
      • 0xbadcafebee 1y ago
        Perl does not fall apart when you need structure, it's OO. In fact it's better structured than Python (hello, PyPI? It's CPAN calling, we wanted to let you know hierarchical packages are a thing). If you mean "forcing people to program in an opinionated manner", it doesn't do that by default, but that's what linters and formatters are for (like the ones Python programmers use)
• CraigJPerry 1y ago
  I keep meaning to write something like this but exploring the “how simple can you make it” angle - a lot of my world is kube (which is great in the right scenario) but could you shave complexity out of a stack designed for solo dev rapid iteration: e.g. rather than: > It’s important not to do any heavy data processing steps in the project-ui … we keep the browser application light while delegating the heavy lifting and business logic to the server Chomp the complexity, serve HTML from the backend directly > ty Im curious where ty goes but for a min-complexity stack i couldnt spend complexity tokens on pre release tools > pydantic … dataclasses One or the t’other, plus i’ll forever confuse myself: is it post_init (dataclasses) or is it post_model_init (pydantic) - i had to check! > docker if we already have uv, could we get away without docker? uv sync can give an experience almost akin to static compiled binaries with the right setup. Its not going to handle volumes etc so if you're using docker features, this concept isnt going to fly. If you're not wedded to docker though, can you get away with just uv in dev and prod? in an enterprise prob not, i wouldn't expect to be able to download deps in prod. For flying solo though… > compose You’ve a frontend, a backend and presumably a database. Could you get away with just uv to manage your backend and a local sqlite db? So a broadly feature comparable stack for rapid iteration with less complexity but still all the bells and whistles so you dont need to cook everything yourself, might look like: - uv - fastapi + jinja + htmx + surreal + picocss - sqlite You could probably sketch a path to hyper scale if you ever needed it: - v1 = the above stack - v2 = swap sqlite for postgres, now you unlocked multiple writers and horizontal scaling, maybe py-pglite for test envs so you can defer test-containers adoption for one more scaling iteration. WAL streaming would add some complexity to this step but worth it - v3 = introduce containers, a container registry and test-containers. I dont think you really unlock much in this step for all that additional complexity though… - v4 = rke2 single node cluster, no load balancer needed yet - v5 = scale to triple node, we need a load balancer too - v6 = add agent nodes to the rke cluster - v7 = can you optimise costs, maybe rewrite unchanging parts in a more resource efficient stack …
  • jackbravo 1y ago
    if you want to serve HTML from the backend, why not use FastHTML then ;-)
• mmcnl 1y ago
  Ofcourse the most used programming language in the world is not a pain to use. How could it be #1 if it was?
• callc 1y ago
  Funnily enough, I made the opposite switch recently, and am also liking it. My thoughts about python here: https://calvinlc.com/p/2025/06/10/thank-you-and-goodbye-python.html https://calvinlc.com/p/2025/06/10/thank-you-and-goodbye-pyth... Next time I get into Python I’ll try uv, ruff, ty.
  • frollogaston 1y ago
    I switched from Python to JS for backend stuff a while back, thoroughly enjoying it. I agree that "Python installation and package management is broken," but the async stuff was the biggest improvement to productivity. Yes I know Python got asyncio, but there's a big difference between having one well-accepted way of doing things vs multiple competing, incompatible ways, where the good one has the least momentum. The rest is small stuff that adds up like Py whitespace scoping, or Py imports somehow not taking relative paths, or JS object syntax is nicer: https://news.ycombinator.com/item?id=44544029 https://news.ycombinator.com/item?id=44544029
  • BiteCode_dev 1y ago
    ty is still in alpha, I wouldn't recommend it yet. It's fast but has many false positives. In the words of charlie himself: https://bsky.app/profile/crmarsh.com/post/3lp2xikab222w https://bsky.app/profile/crmarsh.com/post/3lp2xikab222w uv + ruff (for formatting AND linting) is a killer combo, though. And the more you use uv, the most you discover incredible stuff you can do with it that kills so many python gotchas like using it in the shebang with inline deps or the wonders of "--with": https://www.bitecode.dev/p/uv-tricks https://www.bitecode.dev/p/uv-tricks
• frollogaston 1y ago
  I was like, switched from what, then eventually found a footnote "I used to be mostly a Java/JavaScript/R kind of guy"
• osigurdson 1y ago
  >> I prefer to use a monorepo structure There is nothing more annoying than tons of little repos all of which containing tiny projects with a few hundred lines of code but (of course) you need most / all of them to do anything. Use a mono repo until there is some obvious reason to split it up imo.
  • sethammons 1y ago
    in my experience, repo by "area" works the best. This usually means by team, but you don't want a team restructure to cause code relocation issues. And, yes, only when the org pressures push for it. On the flip side, we have an org with 50+ teams and our operations team is pinning for a monorepo. They are just fine with one team's push forcing N teams to have an unexpected deploy and recycling of caches, connections, etc. Not to mention what will happen when team A doesn't have time to deal with team B's merge due to other org pressures.
    • osigurdson 1y ago
      Why do they want a mono repo though? What are the problems with the current situation.
      • sethammons 1y ago
        consistent CI/CD, code discovery and sharing, and (I contend falsely) protection against backward compatibility issues.
  • MonkeyClub 1y ago
    I got the impression that TFA speaks of a monorepo in the sense of not splitting the backend and the frontend into two different repos. For personal projects, though, I get the value of an actual small projects monorepo.
    • osigurdson 1y ago
      I'm not talking about personal projects. If you have <100 people, mono repo imo.
• bognition 1y ago
  I’m on board with most of this. The one suggestion I’d add is to replace “make” with “just”
  • underdeserver 1y ago
    I hear about it every now and again and I can't seem to grok the benefit. What's the killer feature over make?
    • BeetleB 1y ago
      If you're an expert in make and already have a Makefile, I would not recommend switching to just for that project. The benefit of just is that it's designed to be a command runner, whereas make is designed to be a build tool. justfile syntax is much simpler and more ergonomic. It also has nice features: Private recipes, submodules, recipes that you can specify to run only in a particular OS (we use the same justfile for both Windows and Linux), writing your recipes in a language other than your shell language, and many many other niceties. A new user can start doing "advanced" stuff in just in a couple of hours. They'll take a lot longer if trying to do it via make.
    • kstrauser 1y ago
      First, I grok make. I'm saying this from a position of familiarity, not of ignorance and fear. Make is great at compiling code in languages that don't have bespoke build systems. If you want to compile a bunch of C, awesome. For building a Rust or JavaScript project, no way. Those have better tooling of their own. So for the last 15 years or so, I've used make as a task runner (like "make test" shelling out to "cargo test", or "make build" calling "cargo build", etc.). As a task runner... it kinda sucks. Of course it's perfectly capable of running anything a shell script can run, but it was designed for compiling large software projects and has a lot of implicit structure around doing that. Just doesn't try to be a build system. It's optimized for running tasks. Here, that means it provides a whole lot of convenient functions for path manipulation and other common scripty things. It also adds dozens of quality-of-life features that devs might not even realize they wanted. For example, consider this trivial justfile: # Delete old docs clean: rm -rf public # This takes arguments hello name: @echo Hello, {{name}} If you're in a directory with it and run `just --list`, it'll show you the list of targets in that file: $ just --list Available recipes: clean # Delete old docs hello name # This takes arguments That second recipe takes a required command line argument: $ just hello error: Recipe `hello` got 0 arguments but takes 1 usage: just hello name $ just hello underdeserver Hello, underdeserver You can do these things in make! I've seen it! Just doesn't add things that were impossible before. But I guarantee you it's a lot harder to implement them in make than it is in just, where they're happy native features. There are a zillion little niceties like this. Just doesn't try to do everything make does. It just concentrates on the smaller subset of things you'd put in .PHONY targets, and makes them really, really ergonomic to use. You wouldn't use just to replace make in a large, complicated build. I would unhesitatingly recommend it for wrapping common targets in repos of newer languages, so that `just clean build test` does the same things whether you're in Python or TS or Rust or whatever, and you don't want to hack around all of make's quirks just to build a few simple entry points.
• tk90 1y ago
  Is there a Rust equivalent to this? I'd like to dive into a rust "api_starter" as someone with mostly NodeJS experience!
• noncoml 1y ago
  Switched to python from what? R? Java? Javascript?
• yunwal 1y ago
  For me, python is the closest thing to writing pseudocode that functions. Every time I have the instinct to gloss over a thing when writing it down (because it feels obvious in my head), it turns out that python has an intuitive abstraction for it. Coming from a mathy background I found it incredibly satisfying, although I’ve come around to other languages since.
  • odyssey7 1y ago
    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.
    • dapperdrake 1y ago
      OOP, especially the modern take, feels pretty far from just about anything. Inheritence should have stayed esoteric. Composition is closer to reality. Relations and functions and values are way closer to applications than OOP seems to be.
    • aryehof 1y ago
      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.
      • odyssey7 1y ago
        You’re right, it’s not good for math, but unfortunately we have the legacy of AI / ML being entrenched into that ecosystem, with no clear leaders as alternatives.
    • fastasucan 1y ago
      Its quite easy to avoid OOP though.
• Quitschquat 1y ago
  Which package manager should I be using in my Python? I only just heard of UV
• deepsun 1y ago
  > I prefer to use a monorepo structure Worked at a company where that approach lead to huge unwieldy structure that no one dared to touch to not break anything other teams are working on. The problem was not so much the repo, but dependencies structure (like single requirements.txt for the whole repo) and build scripts. In theory it should've worked great -- you only need to update a dependency once and be sure all the code has the most recent security patches. In reality everyone was afraid to touch it, because it will break someone's else code. Monorepos work great only if you have serious NIH syndrome (Google). I actually started appreciating damned micro-services there, as long as each service just reflects organization team structure. https://en.wikipedia.org/wiki/Conway's_law https://en.wikipedia.org/wiki/Conway's_law
  • nijave 1y ago
    Sounds more like a monolith. You can do microservices with separate requirements in a monorepo. We have one setup at work using pantsbuild (eh the tool is a bit quirky) but it's much nicer than constantly spinning up new git repos and CI pipelines for small services/utilities That said, I think service-per-team is a good pattern
• luxuryballs 1y ago
  switching from what?
• Ohkay 1y ago
  > So yeah, Python is powerful, and it couples very well with the now ubiquitous VSCode editor. I always found vscode lacking for Python and C compared to pycharm and clion. The latter just work without fiddling with config files.
  • PNewling 1y ago
    Funny enough I feel the other way about JetBrains IDEs. They * seem * super powerful, but there is always a lot of config that needs to go into them if I'm doing app, infra, and pipeline work. (Edit, not saying they aren't powerful, just more that as coming into them I'm never sure how to wield it the best out of the box) In my experience (not saying this is universal), the folks that like JetBrains IDEs came from java/intellij backgrounds, where I hear it really shines. This all might be a skill issue, as almost all my professional projects have been VSCode based, but since I've only worked at smaller places I definitely can't rule out this was because it was easier to set things up than to fight for Fin to get us all licences. In your opinion, what makes PyCharm (or CLion if you want to add that in) 'just work'? Do you think it is because you've used it for so long and just know the ins-and-outs? Or is there something you see that they have and VSCode doesn't? I've always been curious about this as someone who hasn't had a lot of professional exposure to the JetBrains world.
    • Ohkay 1y ago
      The things that just work that I look for are mouseover to get info on an identifier (local or external), right click to go to the definition, and running code in the debugger with a click. Maybe I just don’t know how to set that up in vscode; I’m a company of one and don’t have a coworker to ask how to do it. My Python work was just making requests, analyzing the data and outputting results to csv’s. This was replaced by Rust and then C. And the C is 60k loc as it does much more. In Clion when you open a cmake project it automatically understands your project structure from the cmake files and provides those need-to-have features I listed.
    • dapperdrake 1y ago
      Jet brains was so slow on my machines that I got to experience the speed of a physical teletype, decades after they went out of fashion.
• indigodaddy 1y ago
  > And guess what’s the de facto programming language for AI? I thought nodejs/typescript seemed to be the default that most LLMs choose? Or is that just v0/lovable/replit? (although replit seems better about going non-js sometimes)
• ropable 1y ago
  I came to this comment thread expecting developer bikeshedding and I was not disappointed. More seriously: it's fascinating and interesting to see how closely this article mirrors my own Python project layout. The tools and practices have come a long way over the last decade and good developer standards have a way of becoming the defacto in organic fashion. IMO uv has won the race to be the new standard for Python environment management (Poetry gave it a solid try, but lost on speed).
• tomku 1y ago
  If you use Make as a task runner like in the article, please make sure that you're also declaring your tasks as .PHONY targets: https://www.gnu.org/software/make/manual/html_node/Phony-Targets.html https://www.gnu.org/software/make/manual/html_node/Phony-Tar... Otherwise, the existence of a file or folder with the same name as your task ("test", for example) will stop that task from being run, which might be very annoying if you're using the Makefile as part of a script or CI or something where you won't notice the "Nothing to be done for..." message.
  • dapperdrake 1y ago
    Oh, is that the actual reason it’s for? IIRC the info pages just say that it is for targets that lack a file. This is way easier to remember.
• kjgkjhfkjf 1y ago
  Nice article, but this command doesn't activate the venv that's managed by uv. uv venv activate The command actually creates a new venv in a dir called "activate". The correct way to activate the venv is like this: source .venv/bin/activate
  • globular-toast 1y ago
    One of the key principles of uv is you don't activate the venv. You just run everything through uv every time, e.g `uv run pytest` or whatever.
• nikolayasdf123 1y ago
  YAML, Python, Make... — only I see issues and a pattern with this choice of toolset?
  • IshKebab 1y ago
    They occupy a space where things work most of the time but jank and footguns are a way of life. That seems to be where most people live unfortunately.
• seydor 1y ago
  It feels like most people are coming into python from other languages. Wonder what is the emigration rate.
• darkoob12 1y ago
  If you're working on machine learning the most economic choice is Python. But weiting a processing pipeline with Python is frustrating if you have worked with C# concurrency. I figured the best option is Celery and you cannot do it without an external broker. Celery is a mess. I really hate it.
  • nijave 1y ago
    Agree. I think it's improved a bit but Celery is frustrating as the defacto job/queue solution. A lot of the defaults make it unreliable (it can lose jobs if workers crash or don't shutdown cleanly) I'm hoping the existence of free-threading will push for more first-class concurrency primitives. Concurrent Futures is nice until you need a concurrent-safe data structure besides a queue
  • machiaweliczny 1y ago
    Agree that celery is a mess and it doesn't work well with async (Asyncio) python. I think version 6 maybe will support it sometime. I also had a lot of problem due to async primitives with sqlalchemy - there's some tricky stuff with asyncio.gather vs TaskGroup and how sqlalchemy session works with it to be able to compose code easily.
• bvan 1y ago
  What was your language of choice prior to Python?
• mark_l_watson 1y ago
  I get the “actually liking it part.” I have been enjoying Lisp languages since the late 1970s, and today it makes me happy using Common Lisp and Racket in the same way as when I stood in a forest very early this morning drinking coffee makes me happy. But, Python is also a fun language and phrases like “good enough” and “actually liking it” are valid.