Live data from Hacker News

What's up Python? Epic CPython commit, Django 5 and 2FA for PyPI

bitecode.dev

71–80 of 123 posts

Re: What's up Python? Epic CPython commit, Django 5 and 2FA for PyPI

#71

I'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 sh…

Will PyPi Passkey sign in be supported?

Edit: Thank you!

Re: What's up Python? Epic CPython commit, Django 5 and 2FA for PyPI

#72
post #40

While 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…

You can have centralized TOTP too, I believe e.g. Vault or 1password can do that?

You can do the same with passkeys with something like Vaultwarden/Bitwarden, as well.

Re: What's up Python? Epic CPython commit, Django 5 and 2FA for PyPI

#73
post #56

Earlier quoted context omitted.

That 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?

I 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 [2]: https://docs.pytest.org/en/6.2.x/monkeypatch.html

I disagree in general. A big part of gevent's raison d'etre was patching the stdlib to be async, so if a user read its docs at all, they’d be warned that it was making deep changes to the runtime. It's also very widely used and tested, so its changes are well exercised. Pytest helps you monkey patch code that can't easily be mocked in a different way, but it also helps you un-patch the code after your tests have finished. (Side note: if you find yourself patching a whole lot of things with pytest, it's probably time to look into techniques like dependency injection that can help free you from the need to patch in the first place.)

But if you're not writing gevent or pytest, you should probably avoid it. It's much better to explicitly import or create the modified version of the code inside your own namespace, like:

  from helpers import my_datetime_utcnow
or

  import datetime as dt
  def my_datetime_utcnow(): return dt.datetime.whatever...
If you're going out of your way to patch the `datetime` namespace in such a way that other modules importing it get your patched version, it's quite likely that all hell will break loose when you least expect it.

Re: What's up Python? Epic CPython commit, Django 5 and 2FA for PyPI

#74

I'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 sh…

Will PyPi Passkey sign in be supported? Edit: Thank you!

It should already be (we support passkeys as an MFA method, but not as a password replacement yet).

Re: What's up Python? Epic CPython commit, Django 5 and 2FA for PyPI

#75
post #40

While 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…

You can have centralized TOTP too, I believe e.g. Vault or 1password can do that?

you can also just screenshot the QR code they give you to register your TOTP authenticator, and share it with the other maintainers.

sites implementing 2fa don't make it easy to share the keys (because they shouldn't, that's bad!) but a shared totp key is better than no key.

Re: What's up Python? Epic CPython commit, Django 5 and 2FA for PyPI

#76
post #41

Earlier quoted context omitted.

Another 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())

That 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?

[deleted]

Re: What's up Python? Epic CPython commit, Django 5 and 2FA for PyPI

#77

While 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…

You were not forced to do that because TOTP is manageable via password manager.

TOTP and yubikey are excellent technologies that way. They allow two-factor authentication without breaking privacy.

Everyone within the sound of my voice: get a password manager. It sounds like a hassle but it makes your life infinitely better. It allows you to keep your life private and more secure than it was while providing more convenience than you had before.

I recommend KeepassXC. Open source, audited, fully featured, and can be paired with one of several different kinds of syncing technologies depending on your risk appetite.

Re: What's up Python? Epic CPython commit, Django 5 and 2FA for PyPI

#78
post #5

If you read nothing else, the commit message adding JIT support is worth your time: https://github.com/python/cpython/pull/113465

To the guy who said the pull was horrible: IMO, the most important thing about a pull request is to... actually be productive. I've worked with people in the past who would nit-pick my commit messages wanting me to waste hours of my time trying to use arcane Git commands. Any of which might and probably will clobber my work. If you're doing Git reviews a good use of resources is to look for security problems, perform…

If someone who made the changes can't explain things clearly, I'd even wager that they didn't understand what they're changing properly. A good commit message is needed as the author might be gone but software is maintained for decades. Productivity is easy, writing a good message isn't, as the latter seems to be hard for many and it's telling of their understanding of systems they change.

Re: What's up Python? Epic CPython commit, Django 5 and 2FA for PyPI

#79
post #4

Is there a PEP 8106 alternative coming for the unittest module too? The naming scheme really looks odd.

Unlikely: https://discuss.python.org/t/enhance-logging-api-with-pep-8-...

That 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.

Re: What's up Python? Epic CPython commit, Django 5 and 2FA for PyPI

#80
post #34

I'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.…

I share your sentiment. I prefer naive datetimes that are always UTC. Fortunately I wrapped all of these methods in a core utility module ages ago so changing it won’t be very hard for our project… but still feels like a silly thing to deprecate for seemingly no reason.
Post reply on HN