Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

bitecode.dev

Post reply on HN
Print view View original

111–120 of 123 posts

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

#111

Post by aftbit »

Karellen wrote: post #47
aftbit wrote: 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 still prefer to work with naive always-UTC datetimes. Why prefer to work with naive UTC datetimes, rather than explicit UTC datetimes? What's wrong with plain `datetime.datetime.now(datetime.UTC)`?

Datetimes are naive in my database. The fundamental problem with the change you recommend is that I cannot then compare those two different datetimes. For example, today I might do:

user_over_30d_old = user.created_at But in the future, I would need to do:

user_over_30d_old = user.created_at.replace(tzinfo=datetime.UTC) Which isn't any better than the solution I proposed above, of removing UTC from the now() datetime. Alternatively, I could modify my DAL code to promote datetimes from naive to timezoned in the database at the edge of the python layer, but that would have a lot of knock-on effects in things like isoformat() now appending timezone information, which has caused issues in other broken APIs that I use.

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

#112

Post by aftbit »

xorcist wrote: post #59
aftbit wrote: 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.…

And for no particularly good reason! Sure, it's not great, but lots of things aren't. It's at worst a possible footgun, otherwise mostly cosmetic. It should never be acceptable to break working software for anything else than critical security problems.

This is one small benefit to working on a lot of Python 2.7 software. It never breaks anymore. Of course the deps are no longer updated and security issues are starting to pile up, but if your software doesn't process the wrong kinds of untrusted input, it will sure be more reliably run in python 2.7 in 5 years than if you wrote it in some flavor of python 3.

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

#113

Post by Kwpolska »

notatallshaw wrote: post #107
Kwpolska wrote: post #95

Earlier quoted context omitted.

Adding 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.)

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

No 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-ap...

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

#114

Post by IshKebab »

failsecured wrote: post #110
IshKebab wrote: post #100

Earlier quoted context omitted.

I 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 company_secret_project_stuff` 3. pip dutifully goes and installs the hacker's version o…

2 pip installs can trivially solve this issue and I use this at work. One pip install only for private packages using the --index-url (NOT --extra-index-url) and then the other pip install for public packages no index modifiers needed.

I don't think that works if the private packages depend on public ones, which is quite likely.

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

#115

Post by woodruffw »

LtWorf wrote: post #84
woodruffw wrote: post #15

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…

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

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

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

#116

Post by woodruffw »

eesmith wrote: post #92
Kwpolska wrote: post #88

Earlier quoted context omitted.

Many people seem to believe that keeping your 2FA keys in an un-backupable mobile app and away from your computer is safer than keeping it in your backupable and multi-device password manager.

Unless you think PyPI is guided by that belief, that doesn't explain why they don't list desktop solutions.

PyPI doesn't list desktop solutions because I made that list back in 2019 and didn't think to list them. If you have some reputable desktop password managers that support TOTP that you'd like to see listed, you should open a PR for them!

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

#117

Post by a1o »

PartiallyTyped wrote: post #85
a1o wrote: post #58

Earlier quoted context omitted.

A good reason for enforcing some rule on git commit messages though is to have a message that helps when bisecting to find where an issue was introduced in the past. If the commit message is too meanless or too different from whatever is the convention, it makes you spend more time when tracking and solving issues.

If you’ve a test checking the regression you can use that directly to find where the regression occurred without relying on the message, no?

No, the message should tell the why of the change, if you don't know you risk doing a fix that is simply removing the change and then you are back at the issue that motivate such change in first place. This is even harder if the person put the commit along others that are merged separately or worse, work directly on the main/master branch. I've been there a lot, it's not hard to write a good commit message, if you're in a project and everyone does their part except that one programmer, you will notice a lot every time a bug turns out to be introduced by that one person.

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

#118

Post by failsecured »

IshKebab wrote: post #114
failsecured wrote: post #110

Earlier quoted context omitted.

2 pip installs can trivially solve this issue and I use this at work. One pip install only for private packages using the --index-url (NOT --extra-index-url) and then the other pip install for public packages no index modifiers needed.

I don't think that works if the private packages depend on public ones, which is quite likely.

You are completely correct. I neglected to mention that we mirror/cache the dependencies we need in our private index.

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

#119

Post by eesmith »

woodruffw wrote: post #116
eesmith wrote: post #92

Earlier quoted context omitted.

Unless you think PyPI is guided by that belief, that doesn't explain why they don't list desktop solutions.

PyPI doesn't list desktop solutions because I made that list back in 2019 and didn't think to list them. If you have some reputable desktop password managers that support TOTP that you'd like to see listed, you should open a PR for them!

You are certainly far more qualified than I to know which desktop password managers are reputable.

I only installed KeepassXC two weeks ago to try it out because several people here on HN mentioned it, and because it was free software not connected to for-profit companies.

It is the only one I've tried, and I've only used it once, to see what it was like.

I think your historical comment omits something. When I made this complaint back in 2019 you replied at https://news.ycombinator.com/item?id=20058199 saying "I've forwarded this thread along to others working on PyPI as part of the OTF grant, and we'll be figuring out how best to explain using TOTP without being too mobile-centric."

That mobile-centric list hasn't changed, and I still don't have, nor want, a smart phone.

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

#120

Post by notatallshaw »

Kwpolska wrote: post #113
notatallshaw wrote: post #107

Earlier quoted context omitted.

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

No 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-ap...

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

Post reply on HN