HN user
OpenAI just acquired Astral who have an index service called pyx, so they would have a step up.
My understanding though is most corporations that take security seriously either build everything themselves in a sandbox, or use something like JFrog's Artifactory with various security checks, and don't let users directly connect to public indexes. So I'm not sure what the market is.
It does not work EXACTLY how pip works, big differences are covered here: https://docs.astral.sh/uv/pip/compatibility/
Some of these are uv following the standards while pip is still migrating away from legacy behavior, some of these are design choices that uv has made, because the standard is underdefined, it's a tool specific choice, or uv decided not to follow the standards for whatever reason.
PDM has plugins, such as being able to invoke conda commands: https://github.com/pdm-project/awesome-pdm
Otherwise I don't know what they're talking about, it is indeed a Python package manager.
If you're concerned about dependency confusion attacks you should host your own index and vet what goes on to it.
But there is a better solution coming, PEP 708 was developed for this and is in prototype on pypi.org, so it's an overstatement to say "don't even have a way to avoid dependency confusion attacks ".
It is, however, a non-trivial problem, and more solutions will likely come over the years, many Python packaging tools like uv and poetry (and likely others) have way to name indexes and pin specific packages to indexes, which appears to be a promising UX.
No, it looks like it's been available on GitHub for a while, but development wasn't done there: https://star-history.com/#nginx/nginx&Date
Thanks for the update, unfortunately I can no longer edit my top comment or title to reflect this.
Would be happy for admin to do so, if that's something that's done on this site.
The original text stated:
I don’t know much about voting systems, but I know someone who does. Unfortunately he’s currently banned. Maybe we can wait until his 3-month ban expires and ask him for advice?
Currently, the text reads:
This post was flagged by the community and is temporarily hidden.
Since it has been hidden for more than 24 hours, this suggests that a moderator action has marked it as permanently hidden. Due to a recent decision, this means no one outside of the moderators or admins can view it: https://discuss.python.org/t/moderated-posts-are-no-longer-p...
Edit: I meant to post slightly more direct link in title: https://discuss.python.org/t/should-we-consider-ranked-choic...
Edit 2: Some comments suggest that Guido was banned from posting, but this is not accurate. I have edited the title from "Guido van Rossum's Post Removed for Violating Python Community Guidelines" to "A Post by Guido van Rossum Removed for Violating Python Community Guidelines" to clarify what actually happened.
pip will not do that, it will attempt to use the latest version under the user requirements, only if there is a conflict between two packages will it backtrack on old versions of a package, uv does exactly the same.
Further, if a package index supports PEP 658 metadata, pip will use that to resolve and not download the entire wheel.
uv does the same but adds extra optimizations, both clever ones that pip should probably adopt, and ones which involve assumptions that don't strictly comply to the standards, which pip should probably not adopt.
I would say, as someone who works on performance of pip, no one else was able to reproduce OPs severe performance issue, not saying it didn't happen, just it was an edge case on specific hardware (I am assuming it was this issue https://github.com/pypa/pip/issues/12314).
Since it was posted a lot of work was done on areas which likely caused performance problems, and I would expect in the latest version of pip to see at least a doubling in performance, e.g. I created a scenario similar to OPs that dropped from 266 seconds to 48 seconds on my machine, and more improvements have been made since then. However OP has never followed up to let us know if it improved.
Now, that's not to say you shouldn't use uv, it's performance is great. But just a lot of volunteer work has been put in over the last year (well before uv was announced) to improve the default Python package install performance. And one last thing:
for a non-compiler language?
Installing packages from PyPI can involve compiling C, C++, Rust, etc. Python's packaging is very very flexible, and in lots of cases it can take a lot of time.
Write an issue on their GitHub if you don't already see one, they're very responsive
I doubt the typical LSP servers will be aware of dependencies specified in that way and so won't offer autocompletion etc for those libraries.
Given this is a recently accepted standard (PEP 723), why would language servers not start to support features based on it?
Maybe it’s the fact it can be done with multiple operators and strong encryption that is hard to grok, but at least here is a very simple example of a limited partially homomorphic encryption:
You have a 7-bit character representation (e.g. ASCII) and your encryption is to add 1 mod 128. E.g. 0 -> 1, 1 -> 2, ... 126 -> 127, 127 -> 0.
As it turns out, all your operations can be represented as adding or subtracting constants. You can now encrypt your data (+1), send it to a remote server, send all the adding and subtracting operations, pull back the processed data, decrypt the data (-1).
Of course, this example is neither useful encryption nor generally useful operation, but can be useful for grokking why it might be possible.
The people who say "just use pip and venv" don't understand the issue.
The people saying that say that because it works for them and it solved their problems.
setuptools is somewhat deprecated but not really
setuptools remains the default and most popular backend (the thing that builds your package). What was deprecated was calling it directly, instead you use pip or build or any other frontend.
Why? One reason is because it exposed lots of non-standard eccentricities that users would then start to rely on, breaking the effort of standardisation.
Or perhaps pyproject.toml? If the latter, flit, poetry and the 100 other frontends all have a different syntax.
They all use toml syntax, they all use the same build dependency standard, poetry does not use PEP 440 configuring version dependencies, but it does read PEP 440 dependencies from wheel metadata fine. I hope one day the version dependency spec can be updated with everything that has been learnt, from both Poetry and the rest of the ecosystem, but Python packaging is a slow moving beast.
Should you use pip? Well, the latest hotness are the search-unfriendly named modules "build" and "install", which create a completely isolated environment.
pip does this for you though, I'm not sure why most end users need to know "build" or "install" exist.
Which is the officially supported tool that will stay supported and not ripped out like distutils?
I'm not sure why you think any of these are "the officially supported tool", they are an attempt by various PyPA members to minimally and correctly implement the standards, but PyPA is a loose collection of volunteers.
Whereas, CPython core dev have a pretty clear arms length attitude towards all of packaging. This for me feels like the real contention in the Python packaging world.
Questions over questions. And all that for creating a simple zip archive of a directory, which for some reason demands gigantic frameworks.
Well the people using pip and venv didn't have any of these questions, they just got on with it because it solved everything for them.
Likely you want your package to figure something out as it’s being built, or have interesting metadata, or include binaries, or something else not on the happy path, and you want your build tool to "just work" even though chances are you’re doing something not that simple or what the tool creator thought. Otherwise, if you really just need a “simple zip archive of a directory” just write out the directory and call python -m zipfile.
There’s nothing wrong with lots of people needing specific use cases, but it does mean all these build tools need to add lots and lots of options to accommodate them all, and before you know it you're complaining of a "gigantic framework" (even though I wouldn't describe either setuptools or hatchling like that).
Is this comparable to Ibis or is it something that would be a backend for it?
Discussion on Python discuss: https://discuss.python.org/t/deprecating-utcnow-and-utcfromt...
I'm the one arguing against this move, I've already made my thoughts clear that it's a lot of churn, e.g. the PR to remove it from Pip literally caused Pip to have to do a bug release, and has valid use cases, e.g. modelling datetime data types from spreadsheets and databases that do not have timezones.
But I also accept I'm not the one maintaining Python, so I've updated my codebase appropriately (`datetime.datetime.now(datetime.UTC).replace(tzinfo=None)`). Python is not a backwards compatability language, and it's clearly not a strong motivation for most users as I don't see anyone attempting to write a backwards compatibility shim over the standard library, so no point complaining too much.
Python doesn't have a standards document. It has a reference implementation that defines the language.
That's not quite strictly true, Python does have a documented "Language Reference": https://docs.python.org/3/reference/index.html
If there is a contradiction between the Language Reference and CPython then one, or both, of them needs to be updated and it's treated on a case by case basis.
If an alternative Python implementation follows the Language Reference but chooses different details outside it, that doesn't stop it from being "Python". Of course practically speaking most alternative implementations are incentivized to closely follow CPython.
The main difference now is there is an actual standard rather than a de facto tool that becomes the standard.
The idea is that different tools may rise and fall in popularity but they should all be following the standard so the compatability breaks should be minimal.
Will it work? No idea, but it's the best attempt to make things work well for everyone yet.
Python 3.12 might be the biggest churn moment, but there are probably a few more down the road, such as dropping legacy version specifiers.
It's a single script
It's over 1200 lines of code, it's not like it's 100 lines of code and can fit on a single screen
Globals are fine--they're even marked as such
I would argue that globals in this context are not fine from a code maintainability point of view.
By using globals here it's hard to know from a function call if it's going to mutate global state or not. If all the functions were methods of the same class instance, and other functions were just functions or part of some other class, then it gives you a clear grouping of calls which are related to mutating that state.
In general I would argue if you are ever in the situation of "I have more than two or three functions that are related to each other and they all need to mutate the same state so I use a mutable global" or "I pass around the mutable state via arguments" then make a class! It creates an obvious semantic grouping of callables.
I don't think globals are so awful for certain things. I prefer a more functional approach where you have simple composable standalone functions instead of classes. Obviously classes have a role, but I find they sometimes overly complicate things and make the logic harder to follow and debug.
But "globals" and "composable standalone functions" are contradictory, if you're mutating global state your function is neither composable nor standalone.
What you've got is a poor mans class instance using global instead of self.
Quickly skimming some points that would irratate me if I had to maintain this script:
* Importing Paramiko but regularly call `ssh` via subprocess
* Unused functions like `execute_network_commands_func`
* Sharing state via a global instead of creating a class
Overall it's fit for purpose, but makes a lot of assumptions about the host and client machines. As you said in the thread you're running a very small number of servers (less than 30). I've written similiar things over the years and they are great for what you need.
When I heavily used Splunk (back in 2013) I was in an application production support team that managed over 100 productions servers for over a dozen applications, there were dozens of other teams in similar situations across the company. The Splunk instance was managed by a central team, minimal assumptions about the client environment, had well defined permissions, understood common and essoteric logging formats, and could reinterpret the log structure at query time. A script like this is not competiting in that kind of situation.
In practice wouldn't this just mean part nationalizing the bank so you can keep paying the salaries of all the various bank tellers, IT staff, and accountants to allow the depositors and bond holders to withdraw their money.
Given the retail bank is highly profitable wouldn't it make sense to then keep the whole thing going and figure out how to re-privatize it at a later date?
This is true, but now you're explicitly depending on all of your transitive dependencies
They're constraints not dependencies they don't need to be installed and you can just update your requirements as you need and regenerate them.
Also pip freeze does not emit a constraints file, it emits (mostly) a requirements file. This distinction is rarely important, but when it is, it can cause a lot of problems with this workflow. For example, a constraints file cannot include any information about which extras are installed, which pip freeze does by default
Pip freeze does not use extras notation, you just get extra packages listed as individual dependencies. Yes there is an important distinction between constraints and requirements but Pip freeze uses an intersecting subset of the notation.
You also can't have installed the current project in editable mode if you want the simple "pip freeze" workflow to work correctly
That's why the workflow I gave to generate the constraints didn't use the -e flag, you generate the constraints separately and then can install however you want, editable or not.
From my experience trying basically every single option in the packaging ecosystem, there aren't really any solutions here. Even Poetry, which is pretty much best-in-class for actually managing dependencies, struggles with workspace-like installations and more complicated build scripts. Which is why I think pretty much every project seems to have its own, subtly unique build/dependency system.
People have subtly different use cases that make a big impact on what option is best for them. But I've never been able to fit Poetry into any of my use cases completely, whereas a small shell script to generate constraints automatically out of my requirements has worked exceedingly well for pretty much every use case I've encountered.
The simple solution to this with pip is constraints file:
pip install <my_entire_universe_of_requirements>
pip freeze > constraints.txt
pip install <any_subset_of_requirements> -c constraints.txt
You can use pip-compile from pip-tools if you want the file to include exact hashes.
I know there's a large part of the Python community that loves Poetry but I've never understood why. It adds a lot of complexity and I've never found it does a good job of solving complex problems, where as requirements and constraints offered by Pip are simple and when you have complex problems provide just enough (and no more) functionality to solve them.
For very simply requirements you can just have a simple requirements file or setup.cfg that lists what packages you need and use pip install.
As your requirements get bigger you can start putting sensible lower bounds on everything. This can be achieved manually or if you're struggling to extend an existing environment run pip freeze and replace all the == with >=.
When you start wanting to have reproducible environments or you're having to keep multiple requirements in sync with each other such as prod requirements and development requirements you use a constraints file. Install all your requirements at once, run pip freeze and save the output as a constraints file, now always specify -c constraints.txt when you pip install in any environment unless you are updating the dependencies in your environment.
Better still, you want to add 1 package without changing an of your other dependencies, just run pip install new_package -c constraints.txt and you either install it or find out what it's not compatible with.
It's not perfect but in my experience other tools have always seemed to add a lot of complexity but only solve a narrow set of problems, which I can usually just workaround in some other way with Pip.
Yes, actually more like 2 generations once chips are commercially available, the Arizona factory has never been advertised as a cutting edge node.
But there are 100s of media headlines basically implying that by listing high profile customers and not mentioning the date of opening. Those customers will for the most part be using this factory for auxiliary chips.
I think it depends how you count it.
According to this setup their under load power consumption of the entire system was just shy of 700Ws https://pcper.com/2014/10/nvidia-gtx-980-3-way-and-4-way-sli...
Back then components didn't tend to be as power bursty so I think it matters whether you compare peak power consumption or average power consumption under "typical" load.
A wall load from a gaming PC with a 4090 and 13900k is definitely going to burst passed 700Ws, but average while playing a game is probably lower than that.
Okay but my most common case for datetime.utcnow() is that I want the time in UTC for an external system that doesn't understand timezones, you really want me to do datetime.now(tz=timezone.utc).replace(tz=None)?
The title is "Distinguished Engineer".
I have no idea of the pay but based on my research of salaries for getting a job this year I would wildly speculate high 6 digits to low 7 digits.
I don't disagree, but the positive thing about this is it's opt-in for extensions.
If extensions don't support it it means you just can't use that extension when trying to run multiple interpreters in the same process. Let's see if there's even a good use case for running multiple interpreters in the same process outside of embedded programming, it's not 100% clear yet.
Yes, he then retired, came out of retirement to work at Microsoft with a remit to work on whatever he wants, and decided the project he wanted to work on was make CPython faster.