[HN Gopher] What's up Python? Epic CPython commit, Django 5 and ...
___________________________________________________________________
What's up Python? Epic CPython commit, Django 5 and 2FA for PyPI
Author : BiteCode_dev
Score : 99 points
Date : 2023-12-27 18:18 UTC (4 hours ago)
(HTM) web link (www.bitecode.dev)
(TXT) w3m dump (www.bitecode.dev)
| scrapcode wrote:
| I'm excited about some of these Django updates - especially
| models.GeneratedField()
| evrimoztamur wrote:
| Is there a PEP 8106 alternative coming for the unittest module
| too? The naming scheme really looks odd.
| nerdponx wrote:
| Unlikely: https://discuss.python.org/t/enhance-logging-api-
| with-pep-8-...
| appplication wrote:
| It 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.
| ath0 wrote:
| If you read nothing else, the commit message adding JIT support
| is worth your time: https://github.com/python/cpython/pull/113465
| shevis wrote:
| Wow I underestimated how good it would be
| dist-epoch wrote:
| That's because it's not written by a human.
| simonw wrote:
| I'm certain it was.
| Arnavion wrote:
| I guess you didn't realize it's a riff on an existing poem.
|
| https://www.poetryfoundation.org/poems/43171/a-visit-from-
| st...
| vincnetas wrote:
| Yeah, 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 wrote:
| Me too. I suspect the poetry was GPT generated. So I asked
| GPT to summarize and remove the poetry:
|
| A new Just-In-Time (JIT) compiler was introduced to the
| codebase. The JIT compiler was implemented using mostly
| build-time Python with strict static typing for easy
| maintenance. It passed all tests and had no runtime
| dependencies. The JIT compiler was faster than interpretation
| and used a copy-and-patch approach for every stencil.
| However, the JIT compiler still needed optimization and the
| code it was JIT'ing needed thinning. Despite its large size
| and being parsed straight out of the ELFs, it was configured
| and built successfully with the flag --enable-experimental-
| jit. The JIT compiler was not much faster yet, but
| improvements were expected in the future.
| simonw wrote:
| I'm certain the poetry wasn't GPT generated.
| ajkjk wrote:
| Why do you suspect that? I really doubt it, because it's
| actually good. Do you think that nobody is able to write
| good poetry without help from machine? Like... I've written
| stuff like that in my life. It's not even particularly
| hard, if you believe you can do it and workshop it for a
| while.
| RheingoldRiver wrote:
| _No way_ an LLM came up with "Now cache away, cache away,
| cache away all!"
|
| https://chat.openai.com/share/9f701679-43b1-45b7-9f70-9b1c2
| 6...
| Uptrenda wrote:
| 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, performance issues, and general
| engineering problems with someone's code, etc.
|
| A BAD use of Git reviews is to spend the time making stylistic
| comments 'I would have written it like this, it looks much
| better', being overly pedantic about code formatting, or
| forcing your OCD on someone for their Git history. The reason
| people hate code reviews is somehow they're always done by this
| latter group of person.
|
| If you're forcing people to waste time for silly reasons then
| you can count that they'll eventually leave your silly company.
| I know I have. I was once about to work at a company but saw
| that they literally used a committee of people to review every
| commit message wherein they would force every engineer to
| rewrite code for reasons that seemed to make astrology seem
| like a hard science. Consider not doing that.
| niux wrote:
| Do we have any idea how the introduction of the JIT compiler in
| CPython 3.13 will impact the performance?
| acqq wrote:
| "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
|
| Slides (pg. 31 performance):
|
| https://github.com/brandtbucher/brandtbucher/blob/master/202...
| dralley wrote:
| I think that was a from an application of the technique to
| Lua from the original research paper.
| dataking wrote:
| The 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
| dist-epoch wrote:
| From the youtube talk it will be a small improvement (5-10%).
| It's more of a proof of concept for future things.
| japanman185 wrote:
| You know the old, right tool for the right job kinda thing. Why
| are we trying to force python to work as a general purpose
| programming language? It is a scripting language. I have seen
| many many many codebases in large orgs small orgs, faang,
| startups etc.. and any time I see python in the mix other than
| tooling config or orchestration I know I am in for a hard time.
| simonw wrote:
| What does the term "scripting language" mean to you?
| kstrauser wrote:
| To me, it means that the person who wrote "scripting
| language" probably doesn't know what they're talking about.
| wiseowise wrote:
| Probably something along the lines of "something I don't
| like, but don't have any objective reasons to prove why it is
| bad".
| grumpyprole wrote:
| Not 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.
| fasterik wrote:
| I 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.
| Uptrenda wrote:
| Python is like anything in that it rewards experience. If you
| know about asyncio you can write beautiful, performant code
| that can deal with networking, files, and other blocking
| resources without halting the program every time. If you know
| about processor executor pools -- you can easily execute CPU-
| intensive operations on different cores even though your main
| program is single-threaded. If you know a little about
| databases you can write highly portable and simple queries with
| SQLite.
|
| You can use Python in the same way that other languages allow
| you to write performant servers, desktop applications,
| websites, and even software that runs on phone. But you need to
| know what the best approaches are. The thing about Python is
| that its a very old language. It didn't always have things like
| asyncio which is now arguably the best approach for dealing
| with concurrency and the modern challenges of blocking I/O. New
| libraries appear all the time, and the language and tooling
| continue to evolve. I think older developers who may have only
| dabbled in Python might have out-dated views about the language
| because there definitely were times in Python's history where
| it lagged far behind other languages.
| pkkm wrote:
| Can you elaborate on the issues you've seen? Was the code
| haphazardly thrown together, or did it follow the usual modern
| practices (pip-tools or Poetry, dataclasses, type checking,
| Pydantic, etc.) and still suffer the problems?
| syndicatedjelly wrote:
| Python is not a scripting language, it's a weakly-typed
| general-purpose programming language. I too dislike the lack of
| strong-typing, but there are dozens of good options if that's
| what I need in a codebase.
|
| It sounds like your problem is with people who write Python,
| not Python itself. Not every person who writes code has the
| time or ability to learn all the nuances of strongly-typed
| functional languages. In my opinion, people outside of software
| engineering shouldn't bother with such esoteric domain
| knowledge. "Real" programmers like yourself are there for that
| reason - to rewrite their prototyped code in whatever style you
| see fit.
|
| Complaining that they don't know how to program is a great way
| to alienate smart people in other domains. Knowledge of
| computer science tends to blow up people's egos in a way that I
| have observed in few other fields.
| kstrauser wrote:
| Python's strongly, dynamically typed. Try adding "12"+3 and
| it will throw a TypeError at you.
| bityard wrote:
| Found the rust dev
| cuu508 wrote:
| If you use UUIDField and MariaDB >= 10.7, read Django 5 release
| notes carefully. Other than that, smooth upgrade :-)
| perlgeek wrote:
| The 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 wrote:
| Did 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?
| woodruffw wrote:
| 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 shared
| API token entirely[1].
|
| [1]: https://docs.pypi.org/trusted-publishers/
| IshKebab wrote:
| 2FA but still no namespaces? Dependency confusion attacks are
| still trivial on PyPI.
| woodruffw wrote:
| Namespacing 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 wrote:
| It 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 wrote:
| It 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.
| motiejus wrote:
| OK, 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 wrote:
| Similar 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.
| aftbit wrote:
| 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.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 wrote:
| Wouldn'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 wrote:
| 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=d
| atetime.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 wrote:
| 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?
| js2 wrote:
| [delayed]
| Karellen wrote:
| > 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)`?
| jurassic wrote:
| 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 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 wrote:
| You can have centralized TOTP too, I believe e.g. Vault or
| 1password can do that?
| jurassic wrote:
| Good 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 wrote:
| _financial_ security if you can pin it all on your paid
| password manager service and they remain solvent enough to
| juice
| coder543 wrote:
| No, 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 so does
| the additional risk 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 not using LastPass.
|
| 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.
| sakjur wrote:
| You should probably not do that, but as coder543 says in
| another comment, there are reasons why even that is
| preferable to not having TOTP. And assuming you enforce
| multi-factor authentication to access your vault, it is
| sort of transitively multiple factors (except for security
| vulnerabilities affecting the vault).
|
| It's not ideal, individual accounts seems like the only
| reasonable solution for legal and auditing reasons, but at
| least it's possible to conveniently share users with 2FA
| enabled if you need to.
___________________________________________________________________
(page generated 2023-12-27 23:00 UTC)