13 ms·
What's up Python? Epic CPython commit, Django 5 and 2FA for PyPI
- scrapcode 3y agoI'm excited about some of these Django updates - especially models.GeneratedField()
- evrimoztamur 3y agoIs there a PEP 8106 alternative coming for the unittest module too? The naming scheme really looks odd.
- nerdponx 3y agoUnlikely: https://discuss.python.org/t/enhance-logging-api-with-pep-8-compliant-aliases/40067/5 https://discuss.python.org/t/enhance-logging-api-with-pep-8-...
- appplication 3y agoIt is interesting to see just how conservative the core devs are against even the most benign way forward (including more consistent aliases without immediate deprecation). Indeed, not a hill worth dying on either way but it’s a little wild the counter argument is “increased support costs” when, let’s be real, there is no significant increased support beyond the initial scope of work. If core Python ever plans on consistency, introducing these aliases early is the main way for them to achieve it. Even if there is no direct plan for deprecation. Something something about the best time to plant a tree.
- nerdponx 3y agoAs much as I like to defend Python against the "Python bad!!" nonsense here on HN, I agree with this, and with similar complaints about naming in the 'datetime' module.
- ssl232 3y agoThe time to have done it was the first release of Python 3 when everything else was breaking anyway. The ship has sailed.
- Kwpolska 3y agoAdding new aliases to be consistent with Python's prevalent coding style? Increased support costs, not worth it. Deprecating often-used APIs like datetime.datetime.utcnow() because they're ugly? Sure, we'll do that, that won't cause anyone problems unless their code is wrong. (At least they didn't set the removal date to be +2 releases = +2 years, as they usually do.)
- notatallshaw 3y agoThe Python standard library is primarily managed by volunteers, and different sections have distinct maintainers, resulting in diverse choices. When there's no strong advocate for a module, implementing changes becomes a challenging task. However, modules with dedicated champions, such as datetime by Paul Ganssle or pathlib by Barney Gale, may undergo significant modifications after consideration and discussion. Not everyone in the broader Python community will be pleased with these alterations, but they aren't made hastily. I suggest we show empathy towards those who willingly take on the responsibilities of being open-source maintainers, it's a fiery task. While I've personally expressed dissatisfaction with the utcnow change on the Python discussion page, I also acknowledge that I'm not responsible for maintaining this module. Consequently, I've updated my code in a completely backwards compatible way: datetime.datetime.utcnow() -> datetime.datetime.now(datetime.UTC).replace(tzinfo=None).
- Kwpolska 3y agoNo matter how many maintainers there are, the policy to eagerly deprecate and quickly remove things is something common to all of stdlib. And I think that’s not a good policy for a programming language. If you look at Java, for example, only very few APIs were removed between Java 9 and 20, many of which minor or broken/useless (Pack200, RMI): https://docs.oracle.com/en/java/javase/20/migrate/removed-apis.html https://docs.oracle.com/en/java/javase/20/migrate/removed-ap...
- notatallshaw 3y agoThere has been a recent push to remove completely unmaintained modules with PEP 594, but the steering council has made it clear that PEP was an exception and all future module deprecations will have to be done on a case by case basis. The PEP 594 modules were discussed for well over two years before the PEP was accepted, and includes unmaintained modules that were technically deprecated as of Python 2.0. I also rarely see methods removed at all, which is why the utcnow one sticks out so sharply for myself and others. I can't reconcile this with the statement of "policy to eagerly deprecate and quickly remove things", but maybe you have some evidence? Further there is a clear path discussed on the Python board of how to move any pure Python modules to PyPI for any part of the community that wish to maintain them. In the earlier years of Python it was not a serious option to ask everyone to use third party libraries, but now for almost all use cases it is a reasonable option.
- fbdab103 3y agoThat was painful to read. Logging definitely rates as the least favorite module I have to regularly use. The Java ancestry is obvious, and making some free incremental improvements should have been done a decade ago.
- ath0 3y agoIf you read nothing else, the commit message adding JIT support is worth your time: https://github.com/python/cpython/pull/113465 https://github.com/python/cpython/pull/113465
- shevis 3y agoWow I underestimated how good it would be
- dist-epoch 3y ago[flagged]
- mgaunard 3y ago[flagged]
- vincnetas 3y agoYeah, I'm getting old. I would prefer TLDR formal version and then the fun xmas version for people that feel festive. But hey I'm not paying for this so who am I to complain :)
- dist-epoch 3y ago[flagged]
- 3y ago
- niux 3y agoDo we have any idea how the introduction of the JIT compiler in CPython 3.13 will impact the performance?
- acqq 3y ago"Only 35% slower overall than LuaJIT" as per video from a month ago. No idea which kind of tests are these "overall" though. https://www.youtube.com/watch?v=HxSHIpEQRjs https://www.youtube.com/watch?v=HxSHIpEQRjs Slides (pg. 31 performance): https://github.com/brandtbucher/brandtbucher/blob/master/2023/10/10/a_jit_compiler_for_cpython.pdf https://github.com/brandtbucher/brandtbucher/blob/master/202...
- dralley 3y agoI think that was a from an application of the technique to Lua from the original research paper.
- dataking 3y agoThe paper on copy-and-patch compilation [0] may give you a general idea although they didn't apply their technique to CPython. [0] https://fredrikbk.com/publications/copy-and-patch.pdf https://fredrikbk.com/publications/copy-and-patch.pdf
- dist-epoch 3y agoFrom the youtube talk it will be a small improvement (5-10%). It's more of a proof of concept for future things.
- japanman185 3y ago[flagged]
- simonw 3y agoWhat does the term "scripting language" mean to you?
- kstrauser 3y agoTo me, it means that the person who wrote "scripting language" probably doesn't know what they're talking about.
- wiseowise 3y agoProbably something along the lines of "something I don't like, but don't have any objective reasons to prove why it is bad".
- grumpyprole 3y agoNot the original poster, but to me it usually refers to a language that is expressive and high-level but usually not fast or efficient enough to implement the actual heavy lifting. It seems fair to call Python a scripting language. This is not a derogatory term, rather it actually describes a great way to build software and explains Python's success.
- japanman185 3y ago[dead]
- fasterik 3y agoI prefer compiled and statically typed languages myself, but it seems a bit absurd to not consider Python a general purpose programming language. It's Turing complete, has one of the most fully-featured standard libraries in existence, and can interface with native libraries.
- 3y ago
- cuu508 3y agoIf you use UUIDField and MariaDB >= 10.7, read Django 5 release notes carefully. Other than that, smooth upgrade :-)
- perlgeek 3y agoThe deprecation of "crypt" could have been handled a bit better, IMHO. It recommends to use "hashlib" instead, which isn't API compatible to crypt, and if you load it on a new enough python... triggers a deprecation warning about "crypt" being deprecated. Oh, and it seems unmaintained.
- ptx 3y agoDid you mean "passlib", the third-party module they link to? The built-in "hashlib" doesn't generate any warnings for me on Python 3.11 and is presumably maintained as part of Python. Anyway, the PEP mentions that "crypt" is not secure, not thread-safe, not cross-platform and not useful for modifying the system password database... so it sounds like you really shouldn't use it for much of anything. What's your usecase?
- perlgeek 3y agoYes, passlib, sorry for the confusion. > What's your usecase? We need to store hashed passwords that are then used by third-party programs (like Apache or exim) to authenticate users, so we need to generate salts and hashes in formats compatible to them. It works with passlib after some fiddling, it was just way more fiddly than I'd expect from python.
- woodruffw 3y agoI'm very excited to see 2FA become mandatory. It's worth noting that that 2FA requirement will have (virtuous) knock-on effects: package uploads will require an API token instead of allowing a password, meaning one less place where a user can accidentally expose control over their entire account. For packages published through GitHub Actions, PyPI's Trusted Publishing goes a step further and removes the need for a shared API token entirely[1]. [1]: https://docs.pypi.org/trusted-publishers/ https://docs.pypi.org/trusted-publishers/
- toomuchtodo 3y agoWill PyPi Passkey sign in be supported? Edit: Thank you!
- woodruffw 3y agoIt should already be (we support passkeys as an MFA method, but not as a password replacement yet).
- LtWorf 3y agoTo create a new package, you MUST generate a global token that can also do whatever on all existing packages on the account. How many people do you think will bother to delete the global token after having used it, and then generate a scoped one? 1%? Probably much less than that.
- woodruffw 3y agoYou can create a new package via a "pending publisher"[1], which does not require a user-scoped token. (Note: even though PyPI calls them "user-scoped tokens," they have less access than a password does, since they can't manage the user's account itself. So, while not ideal, they are still a better choice than a user/pass combination.) [1]: https://docs.pypi.org/trusted-publishers/creating-a-project-through-oidc/ https://docs.pypi.org/trusted-publishers/creating-a-project-...
- 3y ago
- IshKebab 3y ago2FA but still no namespaces? Dependency confusion attacks are still trivial on PyPI.
- woodruffw 3y agoNamespacing does not prevent (or even significantly complicate) dependency confusion, unless we think that there's some difference in confusability between these two errors: requestss and requestss/requests (I think namespacing is a good idea in general, but dependency confusion is mostly a disjoint namespaces problem, not a depth problem. Python could solve the former by doing what Go does and make the source repository itself be the namespace, but this a significant incompatible breakage.)
- tczMUFlmoNk 3y agoIt helps in some cases. If I type `npm i @google/cloud-sotrage`, I'm still safe. Same with `@google/gcs` (typo vs. misremembering the name). I just have to get the organization name right.
- ptx 3y agoIt does help in some cases. For example, I know that "kotlin-stdlib-jdk8" in Maven Central is the official package for Kotlin standard library, but what about "kotlin-stdlib-wasm-wasi", "kotlin-jdk-annotations" and "kotlin-native-compiler-embeddable"? Here it helps to know that they're all in the "org.jetbrains.kotlin" group.
- IshKebab 3y agoI think you have the wrong idea of what dependency confusion is. Here's the scenario: 1. Company develops package `company_secret_project_stuff` and publishes version 1 on their internal private PyPI instance. 2. They tell their employees to install it via `python3 -m pip install --extra-index-url https://pypi.intranet.company.com https://pypi.intranet.company.com company_secret_project_stuff` 3. pip dutifully goes and installs the hacker's version of `company_secret_project_stuff` (version 999999) from the global PyPI index. I know for a fact that my company is vulnerable to this. The only solution currently is for the company to also register `company_secret_project_stuff` on the global PyPI. But you can guess how happy they were about exposing internal package names. They opted to remain vulnerable instead (yes; stupid decision but I can kind of see their point). Namespaces trivially fix this. You just register the `@company` namespace on the global PyPI index and then make sure all your private packages are in that namespace. Attackers can't publish packages with the same name as yours, and you don't need to make them all public.
- motiejus 3y agoOK, a Django update from me. I heavily used Django since version 0.96 (2007) until 1.5 (2014) (with Python 3)! Then came a long break with lower-level infrastructure work: linux kernel, perf tuning, some C, some Go and zig. Last week I picked up Django again. After 10 years (!!!) of not even looking at it. It felt like meeting a good old friend: they are the same, but older and more mature. Conversations are the same. But better. Things change in the tech world, often for the worse. Django changes, as it matures, for the better. The website layout, tutorial, colors, excellent release notes, `./manage.py runserver` are all the same as I remember them. Except today it's easier, since I am much wiser in deploying and maintaining things than I was a decade ago. :)
- tcdent 3y agoSimilar experience. Started on 0.96, used daily until about 2.x and then took a break. Came back last year and was delighted to find most of the API remained stable. Before reading the release notes for Django 5 I was expecting at least a few breaking changes for my 4.2 apps, but there's almost none. Part of the reason I took a break from tech in the first place was the relentless upgrade cycle. Thrilled that we've solved at least a few of the problems in sustainable ways.
- mrweasel 3y agoSame experience from me. I stopped working with Django around 2016 and then picked up a project last year where we picked Django as the framework and it was like I never left. They added new features, improved documentation and all that, but it was so amazingly easy to come to. It probably does help that we stick to Django 3.X as that's what's currently in Debian. I do like the smaller frameworks like Flask or Bottle, but if I need a database or anything remotely more complex than answering a few API calls, then I don't see a reason to not pick Django.
- aftbit 3y agoI'm still annoyed that they are deprecating datetime.datetime.utcnow(). I have over 1000 references to that function in my projects folder. I understand the footguns that naive datetimes present to the unwary, and yet I still prefer to work with naive always-UTC datetimes. Alas I will end up doing some kind of crazy find-and-replace (at least in the Python 3 code) to something like `datetime.datetime.now(tz=datetime.UTC).replace(tz=None)`. Then of course I'll have to track down all of the bugs from other people doing `from datetime import datetime` and refactor so I now import the whole module just to get a reference to UTC. Grr.
- dragonwriter 3y agoWouldn't it be easier just to write a utcnow() function of your own in a support module and do a find-and-replace to use that?
- amelius 3y agoAnother solution is to make a file called "my_patches.py": import datetime class my_datetime(datetime.datetime): @staticmethod def utcnow(): return datetime.datetime.now(tz=datetime.timezone.utc).replace(tzinfo=None) datetime.datetime = my_datetime And then in your codebase make sure you import my_patches whenever you use datetime. E.g.: import my_patches import datetime print(datetime.datetime.utcnow())
- kstrauser 3y agoThat solves the specific problem, but if you were my coworker, I’d have to toss you off the nearest bridge. Don’t monkeypatch Python, m’kay?
- js2 3y agoI think it's fine and pythonic[1,2] to monkey patch when used in moderation and done explicitly: from my_patches import monkey monkey.patch_datetime_utcnow() I wouldn't do it as a side-effect of an import. Down that path lies Ruby. :-) [1]: https://www.gevent.org/api/gevent.monkey.html https://www.gevent.org/api/gevent.monkey.html [2]: https://docs.pytest.org/en/6.2.x/monkeypatch.html https://docs.pytest.org/en/6.2.x/monkeypatch.html
- jurassic 3y agoWhile I'm not against security and 2FA in general, making PyPI 2FA mandatory ahead of any kind of org support is a major pain for big projects with more than one maintainer. This week I was forced to link my company's pypi account to a personal device to unblock our latest release and now none of the dozen other maintainers I work with can get access. Things will get spicy if someone in my position were to die, leave the company on bad terms, etc and a big project can no longer be managed. PyPI announced orgs back in April, but it seems they still haven't figured out the details on pricing, etc. No telling when those will roll out, but I sure hope it's soon. I'm cynical, but the sequencing of work here very much feels like somebody at Google (or wherever) wanted to push a big open source security project to advance their personal promo case rather than thinking through the needs of serious project maintainers.
- sakjur 3y agoYou can have centralized TOTP too, I believe e.g. Vault or 1password can do that?
- jurassic 3y agoGood to know, I wasn't aware. But if you're storing passwords, TOTP seed, and recovery codes all in the same shared password vault, it's not really multi-factor anymore. It's security theatre.
- xkcd-sucks 3y agofinancial security if you can pin it all on your paid password manager service and they remain solvent enough to juice
- coder543 3y agoNo, it’s not theater. 2FA was not created as a defense against password manager compromise. That is not its purpose. It protects against password reuse attacks and helps to protect against total compromise of people who have been phished. Even better, a password manager can avoid giving up a TOTP code to a phisher in the first place because it is checking the domain. If your password manager is compromised, you’ve got big problems regardless of 2FA tokens being in there or not. The extremely marginal security benefit of storing the 2FA tokens separate from your password manager is just not even worth discussing in most scenarios. It exists, but doing that causes the additional risks of losing access to your 2FA token or having your 2FA code phished, both of which seem a lot more likely than your password manager being compromised. At least, as long as you’re using any halfway decent password manager. Long term, the goal is to get rid of passwords and 2FA altogether by switching to Passkeys. Each Passkey will naturally be stored in a single place, since they can’t be split into multiple parts anyways.
- hyuuu 3y agodjango's main advantage is how consistent the API is, which enables a lot of plugins and libraries to be built around it and they stay valid for a very long time. This makes development to be insanely productive, I joke that to create a new feature in django is "pip install <new feature>", check out your options here: https://djangopackages.org/ https://djangopackages.org/
- globular-toast 3y ago> It's also a good time to remind you once again that 3.13 will deprecate a lot of things People get this wrong more often than they should. The link says things will get removed in 3.13, not just deprecated. So many people seem to think deprecate is just some fancy word for remove. I really don't get it. Remove means remove. Deprecate does not mean remove.