#off-topic
1 messages · Page 1 of 1 (latest)
How about a new package named something like "pip-api" that provides access to select internals
And then you can have a lite compatibility policy on that
I've not
Yeah I saw it now
what's the benefit/use case now that pip can do more things like resolve?
pip-compile generates a lockfile and pip-sync matches an environment with the lockfile.
You can't do either with pip directly.
Is pip resolve deterministic when you only install wheels?
iff deleting artifacts were banned and you had a timestamp of the resolution you could rebuild a lock file from an .in file and some sdist deltas
Then that gets you multi-environment lock files
there's also a pip-compile like app that uses poetry to generate requirements files instead
and can generate those properly with cross-platform environment markers using metadata
it's still in a somewhat early development phase:
https://gitlab.com/mitchhentges/pip-compile-cross-platform
Yeah I've got one of these as a bash script
But ideally I'd just keep an index timestamp and then store deltas from a deterministic resolution
does anyone know what this is referring to? I can't find much https://groups.google.com/g/django-developers/c/_bublVB5dcw/m/v20wW_4sAQAJ
I am referring to the multiple occasions on which black's approach to packaging caused installation of the package, via pip, to fail in often mysterious ways.
This is something that's documented in the history of their issue tracker, and that the maintainers have since apologized for and adopted policies to try to prevent in the future.
maybe something to do with the setuptools-scm extension?
There were some bugs related to that due to lack of pins of setuptools-scm version in the build-system.requires on black's side
and it's really annoying because user cannot do anything about faulty version of build tool being pulled
or maybe there is a way (I honestly don't know) but it is not easy to find
Technically a non-issue as long as you use wheels but I guess there can be scenarios where you have to use sdist and therefore actually build during instalation? I don't know.
There's also another thing with Black being lenient about its own dependencies such as click which makes it possible for it to not work properly once a major update is released. This is done because while Black is an app, it's often installed as part of dev requirements of the package and so it has to be compatible with package's own requirements.
But I don't know if that really applies to the problem they're describing
black uses setup.py configuration so the whole premise that black is an early adopter of new packaging "things" is bogus
I think they're referring to the fact black was an early adopter of the pyproject.toml file which caused pip to enable the new build flow which caused some breakage for projects using black
black was never particularly modern in terms of how it's packaged though so not sure what they mean either
I understand that need to be compatible but it's annoying when black isn't. I feel if black doesn't support newer versions of click it may be useful to find a way to vendor the package, or just lock that requirement down
Things like that happen sometimes. It's not feasible to make a new release any time new version of a dep comes up so that you can mark Black as compatible with it.
And this was not even a major version bump for which the often used restrictions on major versions would work because it broke due to usage of some private attribute in click.
Truth is that the user is the one that should be locking requirements if they want to ensure that their thing continues to work.
Doesn’t help that there’s no lockfile standard. I wonder what can get that discussion unstuck: https://discuss.python.org/t/pep-665-take-2-a-file-format-to-list-python-dependencies-for-reproducibility-of-an-application/11736/143
Honestly, I think the key think is for any new PEP to start from a very clear and well-defined list of scenarios that it is designed to support/address. This was where I felt PEP 665 fell down, it focused on reproducibility, rather than on specific use cases. And as a result, it was extremely hard to determine whether it intended to handle parti...
that Black+Click thing was just a bug (and a reminder not to use _internal things from other packages) and fixed in record time (my timezone):
20:59 issue reported
21:30 PR created
22:01 PR merged
22:09 fix released
how do you all manage your 2FA recovery keys? I've always just put them in my password manager but that strikes me as defeating the point? But now I don't know where else to put them
depending on the password manager, putting them into a different location/vault may be a option
does the recovery key work without a password reset email?
I'm finally learning C
Rust is for next year 😄
Rust makes me excited again
https://github.com/ichard26/masml <- my second project in C (the first one is a WIP naturally)
Why do you want to learn C?
I'm bad at finishing projects 😅
C is bad, but it's useful to know 😛
it'd be useful with my work on mypyc
I've been contributing some minor patches to mypyc, but I haven't contributed anything major yet, would like to change that eventually
C CPython Extensions are cool
every new hire, embed, or intern on my team I have install Rust then use Cargo to get ripgrep, bat, tokei, etc.
& we don't use Rust lol
I mostly refuse to use cargo as a generalized package manager, I use Brew Linux for the most part lol
I just stick with ubuntu's apt
and manually compile CPython, I am yet to use pyenv 😅
seeing successful builds produce a cli on PATH makes ppl happy though
I forgot how fast our response was
I'm still annoyed we didn't catch the busted try except
pyenv
that one tool has caused me so much grief over the years debugging others' issues
I've heard of lots of happy users ¯_(ツ)_/¯
I switched to use asdf and direnv
asdf uses pyenv under the covers, but with direnv it doesn't pollute your path
which is mostly the problem with pyenv/asdf, is the swrapper scripts are really slow
*asdf uses python-build
I just stick to a single virtual environment name venv and then have a actenv shell alias
that being said what pyenv does is very simple and issues relating to it are usually user error
(granted the mental model is not 100% what people intuit which is where a lot of pyenv confusion comes from)
I'm one of those people who likes to keep things quite simple
how slow?
uh, I don't remember numbers, it was really noticeable if you used python in your prompt afterwards
the problem is the stubs do a bunch of work to determine what version of python should be used, including abunch of stat calls
that's fair
in my prompts I go to major efforts to use built-ins and very fast to start binaries only (e.g. tmux-cpu-mem-load)
oof that sucks
https://github.com/asdf-community/asdf-direnv is what Iuse to get asdf managed stuff in my projects, without messing with path outside of that, and that, instead of having stubs that determien the resolution, ti does it once when you CD into that directory
I’ve been looking into Zig. Still quite unstable (you basically always want to use HEAD instead of an actual release…) and lacks a dependency management story, but pretty easy to learn and still useful in certain contexts (e.g. writing CPython extension)
pyenv is pain in the ass when it comes to installing it and that caused us so many grievances in support channels 😄
probably not the best case for using pyenv, the upside of it is that it streamlines the build process
I've never personally used it because it doesn't really solve any problems for me, I prefer to just use Python shipped with apt
pyenv is overkill (and just brings trouble) if your just want a Python somewhere
along with Anthony's great deadsnakes repo
It contains a command called python-build that is extremely useful for this use case though, it’s unfortunate very few people know about it
Hmm, that's standalone?
It’s just a bunch of shell scripts and can totally run on its own
https://github.com/pyenv/pyenv/tree/master/plugins/python-build
I don't think it's probably worth my effort to switch the remaining documentation to use that but good to know in case I need it in the future 😄
like, the only remaining documentation that uses it is CentOS 7 and Debian/RPi OS 10
hopefully there are not many users running those OSes nearing their EOL
A lot to worry about for those systems, installing Python is probably the easy part hah
I mean, once you have Python, you just run the app so
Yeah I meant they probably have more pressing issues than to run a Python app :p
a lot of our users are not very technical so they might not even be aware of those pressing issues though 🙃
but yeah, you're right
I like my current setup which is .venv being a symlink to .venvs/3.7 or whatever Python is the the minimum supported version
I also am curious what tools I'm going to break by using a symlink
Likely none, virtual environments (on POSIX systems at least) rely a lot on symbolic links in the first place
Your .venvs/3.7/bin/python is a symbolic link
I know, doesn't mean that there can't be tools out there that wouldn't expect the dir to be a symlink :P
I guess symlinks are pretty transparent so maybe nothing will break but it is a bit untypical setup so I sort of expect there will be some tools that did not handle such edge case lol
I don't use apt based Python because apt is for packages I don't care about, and also it's very useful to have the ability to test spefici patch versions
yeah, I don't have a use for that myself but testing specific patch versions definitely is a very good feature
For me apt is for packages where I don't care about having all the latest features. Python technically doesn't fall into that but deadsnakes mostly solves this
though the Python shipped in Canonical's repos generally doesn't have the latest patch
they only cherry-pick some fixes
I've moved #pycon-us-2022 and #resources into their own "archive" (read-only; reactions still allowed tho) category since a) they aren't needed anymore and shouldn't get new messages, and b) for #resources specifically, it got pretty off-topic and the name is kinda meaningless now 😅
We could delete / hide them to normal users fully, but I didn't want to delete message history without asking for input so that's why I just chose to move them down and mark them as read-only.
Hello! I'm looking into an alternative solution for mirroring pypi in an offline development environment. Bandersnatch has worked for us for the last 4 or so years but lately it's been more difficult for us to maintain. I'm wondering if there is an avenue to purchase a harddrive(s) that contain the mirror and who I could get in contact with?
I'll be in london next week (flying in tomorrow), if anyone wants to have a beer/coffee, let me know
Oh hey, I'll be around.
Has anyone managed to redeem the titan promo code?
google just tells me the code isn't valid
you need to order 2 IIRC
indeed, that works, thanks
it still wants a credit card though, and I don't have one
oh well..
try normal debit card
that requires the official banking android app, which doesn't work on lineageos sadly (but thanks for the tip)
got it working with a different phone now
thanks everyone
lol, it turns out no one on black's core team has control over the black project on TestPyPI which is both awkward and annoying. currently reaching out to them here: https://github.com/ichard26/black-mypyc-wheels/issues/18
I'll file a PEP 541 request if I don't get a response in a few days I guess, I don't believe I should have to actually wait six weeks so the (lack of) reachability requirement is fulfilled given the circumstances here.
is this just for CI?
Yup, I want to test out some changes to the current release automation black has
i.e. I'm upstreaming the mypyc wheel workflow I've been running in a personal repo for the past few months
I just switched to devpi in ci
Well I want to be able to download after the fact too since I don't have access to a machine running macOS
ignore nginx bits: https://github.com/pypa/hatch/tree/master/tests/index/server
Uh, presumably I'd have to host my own copy of devpi somewhere?
Yea, or run it in CI and attach the final artifacts to the CI job
use artifacts ^
Fair enough, I might as well reuse https://github.com/ichard26/black-mypyc-index lol
With the exception of that one case presented in one of the packaging tutorials, it really does seem like it shouldn't be used for all the other stuff people use it for lol. I guess at some point the draft releases will be a proper replacement
Making your first package or sth like that
That's like the only time I used test pypi
This is neat, but this feels overkill to just test out a simple twine command (the main benefit over using a static PEP 503 mirror on GH pages)
I would just teach pypi to understand name spaces or something and just let people use that, or maybe a ephemeral flag you can pass when you create it that'll auto destruct it in 12h or something
or both
I was hoping to use TestPyPI to also host the experimental wheels so I could bug the rest of the core team to test out the wheels
The problem is that you can't re-upload using the same version number
TestPyPI's original purpose was a staging environment for PyPI, because PyPI had no tests and didn't really run locally at all, we don't use it for that anymore though
so it's just kind of there
being bad at things
I know, I was going to ignore black's versioning
like I was planning to use 0.0.1 or something
That was actually to Donald
Like, when I first made a package i didn't really know how all that works so I needed to upload my 0.1.0 a few times probs
this is technically what post-releases are for, but yeah testpypi sucks right now lol
You can't reuse numbers on test pypi either but once you figure it out, you can just do it cleanly instead of already having alpha number 5
I also have no clue what my password on test pypi is, I literally only used it for my first package 
I'm surprised to learn it's not in my password manager, maybe it was before I started using it
It's also near impossible to use testpypi safely unless you're super careful, since there's no guarentee that a name on testpypi maps to a name on pypi, and lots of people just do stuff like pip install --extra-index-url https://test.pypi.org/simple/
hope whoever has urllib3 or something else fun on test pypi is nice :V
righhhhht, I forgot about that, actually testpypi isn't going to work for me anyway then cause not all of Black's runtime deps are on TestPyPI
you can kind of get around it using uh
--find-links https://test.pypi.org/simple/black/
Isn't that what extra index url option is for
Like, the primary index is still the main one
the problem with that is you're just hoping that all your deps are registered by people who aren't malicious
There is no such thing as the “main” index, all indexes are equal
there's like almost no benefit over using a static PEP 503 mirror tho
It has to try them in some order though?
test pypi bad
I guess it's a tiny bit more streamlined
lol
I like kt
The idea that is lmao
Not the test pypi
The ordering logic is probably not what you expect
pip IIRC says the order is undefined, but even if it wasn't, you could just release requests v99999999
Welp
ah supply-chain attacks, our good ol' pal
pretty much test pypi still exists because there is still some use cases that it's slightly better than nothing for
Time to rewrite packaging tutorial to use the simple pypi server package
and people yell a lot when we delete things
This reminds me, does PyPI support uploading a version with epoch?
it should
pretty sure the only thing we check is no local versions and valid pep 440
So at least an attacker can’t release 1!0.0.0 and trump any version on PyPI
they can do that
unless you mean permanetly trump
or something
I wonder if anyone has ever actually used epochs
to psql!
Yeah I mean it wouldn’t cause as big a problem as… well something else
Welp, at least the packaging tutorial uses --no-deps
My employer (Astronomer) uses epoch to ensure our commercially maintained Airflow fork is distributed to the customers
I wonder how many people are using testpypi as a free way to redistribute their internal / personal tools or whatever lol
'cause people already do that on the main pypi
warehouse=> SELECT COUNT(*) FROM releases WHERE version LIKE '%!%';
count
-------
210
neat
Why is that bad?
In general, not with test pypi specifically
they seem like the sort of people who'd yell the most if testpypi got rm-ed
Why use TestPyPI if you can just as easily use the real one to distribute your junk? 😆
fair counter-point :p
But then you can't name your junk "black"
Okay, I don't actually know if black on test pypi is junk lol
it's not, just really outdated lol, 18.9b0 or something
https://gist.github.com/dstufft/f66409fa81efa054d895c20c35bc8206 in case anyone was curious
amazing
ah the joys of versioning😆
reminds me of TeX
In his seminal text layout system, TeX, and his equally brilliant typeface design system, METAFONT, Donald uses a versioning number system that asymptotically approaches perfection. The version numbers of TeX approach π (the current version is 3.14159265) and the version numbers of METAFONT approach e. It has been prophesied that the last change not be made until after the day Donald ascends to heaven on a shining cloud. At that point, Donald will make one last ssh connection down from heaven to his server at Stanford University and set the version number unto π exactly. At that point all remaining bugs will be declared features, and the output from TeX will remain the same for all eternity.
(Donald Knuth obfc, not me)
what the-
TIL GHA runners come with pipx pre-installed, such a nice little QOL improvement 😄
They also have gh CLI installed, but I guess it’s more common knowledge than pipx (makes me wonder if they detect languages of the project or just throw tooling for every language they can)
So basically they just have it all. Makes sense
my goal is after 2 more features to get Hatch on there so OOTB you have building, env management, publishing, etc.
honestly, i'm not sure that's a great decision
these versions are typically pinned, not updated often
nvm i'm wrong
How much do you trust software maintainers? 😆
a lot actually! maybe too much
turns out compiling CPython with -O3 and LTO while trying to answer SO questions is not a great idea, my laptop has turned into a potato
@vast wren @onyx sphinx @fierce horizon @boreal bramble @shadow zealot @onyx spindle @quartz yew Continuing the discussion over here as requested by @hexed briar ...
FWIW, I know @fierce horizon will disagree, but I'm actually not personally into the "all config in one file" approach myself (though I certainly respect why others do), nor do I actually disagree with Anthony on many of his other more controversial design decisions—I'm actually a big fan of many of his projects. However, what does deeply trouble me his long, repeated and unrepentant history of hostile, even vengeful interactions toward others in the community, not only people like us but the many newer contributors who may never return at all because of it, and the fact that behavior is condoned and rewarded (e.g. PSF fellowship) which normalizes it and encourages other maintainers to behave likewise.
I haven't had any direct interactions with them personally, so take this with a grain of salt, but I have heard from a number of other people that they've had very negative experiences with Sigma, and I also recall them being banned from another org due to repeated CoC violations, but unfortunately I can't recall the exact details. However, they seem very like-minded to Anthony.
At the end of the day, if the keyholders of the PyCQA and the community disagree on what's reasonable, there's not much that can be done except for the community to stop using PyCQA projects and create their own alternatives, and stop providing space for them.
@vast wren I've actually considered this myself, as have others, but the problem with this is that when people have tried to fork his projects in the past and maintain them separately under a different name, with appropriate licensing and attribution, Anthony has resorted to legal threats, bullying and a coordinated smear campaign to intimidate them into not doing so.
Oh this is the before-commit fork?
Well now I'm blocked on Twitter I think for liking @hexed briar message
I also didn't know how many people were being blocked by sigmavirus24 and Anthony from the pycqa
Since this is off-topic channel anyway, I'd like to state I don't really care about all config in one file that much either 😄 I don't agree with all of Anthony's takes but in this case I certainly find it a compelling reason against supporting pyproject.toml as the only format if it forces the build isolation on you. I'm not saying pip should be doing it differently but I understand why flake8 doesn't want to switch to it due to this.
I only joined in the conversation because I was surprised to see getting blocked by Anthony on Twitter
I think the config thing is a red herring
It's not forcing build isolation on users -- it's users who already have that, who'd like to keep configuration in the same file. Besides, the plan is for pip to enforce build isolation always. The only blocker is that I've not finished the build isolation cleanup yet, that would let me make that unconditional in pip.
FWIW I completely understand the flake8 config issue, and think his position is reasonable. IMO pip shouldn't be switching the build process by the mere presence of the pyproject.toml file, only if the build backend table is set. So yeah, I have no problem with that. As I said before, the actual issue is how he interacts and deals with people, which IMO is kinda toxic and is definitely not creating an open and respectful community.
Well, it would be forcing flake8 users if they want to switch, not add it as second format
(FWIW, I agree that presence of pyproject.toml shouldn't force this either, but the ship on that sailed... years ago -- and I pushed for it to be different even then)
if it were about adding it as second format (which is maintenance burden they don't want and that also seems reasonable) then that would be a different argument
but yeah, the config thing is a red herring but it's #off-topic so I off-topiced the off-topic
:)
touché
It's forcing build isolation when you combine it with the fact that, afaict, flake8 wants to only support one location for config
not forcing build isolation means that flake8 would have to support 2 locations indefinitely
but I agree it's a red herring 😛
https://github.com/PyCQA/meta/issues/54 probably this is where energy can be focused?
Well, I'm pretty sure we'll force build isolation on everything sometime in the near future. 🤷🏻♂️
@kindred pivot cc
I wonder if this could be why Anthony is writing his own pip now...
Ooh, fascinating. I welcome folks to do stuff like that. Got a link?
it's not yet on GH, he works on it on streams (and writes it in Rust, cause #speed)
Ah, right. There's a bunch of folks who've written these at various points.
It's always interesting to see tools so close to Python but written in non-Python languages. pyright surely comes to mind
That + the PSF and/or the PyCQA CoC is probably the best avenues for things. The PyPA has basically no power here 😛
++
I mean, Python AST parser written in TypeScript!
That's why I pushed it to over to #off-topic. :P
Because VSCode
I find it fascinating
I know Donald and Nathaniel had worked on Rust-based Python packaging tools, at different points in time.
I have a half done reimplementation of pip in rust 😛 well, not exactly a reimplementation of pip, but something in the same space
I honestly think that pyright needs more community awareness
because when you think of Python typing you think mypy
Well, what kind? :P
it's attractive to write it rust less for speed, and more because it produces a static binary that operates independently of python
I mean that Python community should be made more aware that it exists
and is actually a very good tool
I wanted to go with such project, but need of reimplementation of some packages and ways packaging and Python stuff works, seemed like too much work
Which would be great, if Python freaking had a good upstream distribution story, where you could just unpack and use it. :)
pyoxidizer is pretty cool
Well, that's good, because its a non-Python tool specifically built for a particular corperate-backed non-Python IDE that already gets plenty of use built right in. Versus MyPy is the only community-developed alternative in that space (the other three are all built by the big tech giants) and is seriously constrained by lack of resources.
https://github.com/njsmith/posy/blob/main/pybi/README.md is cool, too bad not enough people are interested in it. :)
it's bad because due to it being constrained by lack of resources, it falls shorts in many places in comparison to pyright
Because it doesn't have a big corporation backing it that can use it as leverage to monopolize the editor/IDE space, and then extend and extingiush with the proprietary-only Pylance
(/rant)
I don't have a better way of phrasing this but it can make people think Python typing in general is worse than it is. I know there are mypy maintainers here so I just want to say that this is not your fault, you don't have the funding that Microsoft can offer.
There's a lot of well-justified skepticism toward pyright.
Not least because it's a corporation-backed OSS project.
Each of the big giants funds their own tool instead, leaving MyPy with the crumbs. Corperate-backed tools are an important part of a healthy ecosystem, but so is a viable community alternative. Same thing with community FF vs Big Tech-controlled Chrome, Edge and Safari
my problem is that people are simply not aware that anything but mypy exists
well, the same can be said about any open source project (the funding-time ratio part)
or dismiss pyright outright because it's not written in Python
Its simply not healthy for anyone if one tool leverages integration with others to become a monopoly/monoculture, e.g. Windows with IDE, Google with Chrome, Windows with Word, VSCode with Pyright
pyright is a standalone tool. VS Code ships pylance which uses pyright.
it being not written in Python makes it harder for Python people to work on, since you have to take on another language
VScode is by far the most popular editor/IDE in Python, see the latest survey. Only PyCharm, with their own proprietary type checker, even comes close. Therefore, Pyright already has a big built-in userbase without users even knowing it
Besides, it's an important bootstrapping concern. pip install pyright isn't owned by Microsoft, and... it's readme has this wonderful snippet:
This project works by first checking if node is in the PATH. If it is not, then we download node at runtime using nodeenv and then install the pyright npm package using npx.
(granted, that's how sphinx-theme-builder works)
although I guess this is also how pre-commit supports javascript based hooks? (i.e. prettier)
Yup.
nodeenv or whatever it's called
pre-commit uses nodeenv as well.
The reason MS created Pyright when Pytype, Pyre and MyPy already existed was so they'd have control over it and be able to bundle it with VSCode, and by extension Pylance, which is proprietary and they can then lock people in to and upsell. If one tool, especially corperate backed has dominient marketsthare, they can dictate standards by fiat rather than communiy consensus. Just like IE in the old days, and Chrome now. Pyright already has a massive built in advantage over every other type checker, we don't need to give them free advertising to push them even harder.
Anyway, I rest my case
Yup, and last I checked, pylance is built on top of pyright because they wanted something that they could pull into a VS Code extensions more easily and make changes in a codebase they control unilaterally.
Pyright is an open source project with it's license. It's not a project that has multiple stakeholders deciding its directions though -- just one: Microsoft. They have, somewhat famously, pulled amazingly stupid things around what they provide in a proprietary tooling vs OSS code.
That's not strictly true -- pyright devs are certainly active and positive members of the typing community; and the standards processes around it.
Oh sure, absolutely—but if they end up monopolizing it enough that it becomes closer to a monoculture, like Chrome with the web, then why go to all the work to make it a community standard when you can just implement it right it Pyright and be an exclusive feature? It changes the value proposition enourmously once a tool gains enough of the market
I wonder how much better mypy could be if instead of competing with it, companies like Microsoft would put people to work on it
I'm looking at it from the angle of people that are looking to type everything. Especially library devs who often have more complicated code bases to allow user's codebase to be simpler. Typing in general has some shortcomings already but then you get more of those piled on as you try to get your to be fully typed and compliant with mypy. Very often you'll end up on a bunch of issues that have been unresolved for a long time (not mypy's fault but it doesn't change how user will perceive it) and then you get the general opinion of "Python typing sucks".
I don't mean to bad-mouth the Pyright devs at all, and I'm sure its a great tool, but I'm concerned about the externalities and the long term effects on the ecosystem. Just like we all saw with IE, and just like we can see right now with Chrome
FWIW, if you haven't already, give the following a read: https://dusted.codes/can-we-trust-microsoft-with-open-source
I'm guessing around 20%. 😉
points at Faster CPython
Yeah, but except for one small problem...they are a for profit buisness that has a fiduciary obligation to their shareholders to make as much money as they can. Sometimes those intersts can align with the greater good of open source, but certainly not always the case.
But there's no incentive for a for-profit corporation to do that.
Exactly. Whereas they know how much even a relatively small investment in Faster CPython (just a couple devs) will save them millions of dollars of server time, plus generate a lot of goodwill
Without having to maintain their own fork like cinder, nogil, e tc
Yeah, I get that. I don't know if mypy would be able to keep development at same pace as pyright's if Microsoft put people to work on it but it would be better. I'm just looking at this from the perspective of how today Python typing is perceived in general and how this perception could shift if community would be aware of more than just one tool.
Eric's awesome
re Faster CPython: It's a team of 5+ people and a manager, and the entire chain above that -- it's a decent number of people, not "a couple"
lol
There is a cost to ensuring your type hints follow the standards and work generally across tools, but there's also a benefit—you're not locked into one type checker. Just like with PEP 517/518/621 for build tools
but this is not the problem of not following standards
The free market only works if you are free to choose alternatives
pyright follows standards
mypy just doesn't have the capacity
funding, funding, funding :(
This isn't true BTW, for profit businesses have no legal requirement to make as much money as they can
The limitation with MyPy is not will, its simply developer resources. But the risk is if any one corporate backed type checker, like Pyright, gains a critical mass, they can simply ignore standards deliberately and there will be little incentive to follow them
Which the supreme court has upheld multiple times
I greatly simplified terminology, but a publicly held corporation does have a fiduciary responsibility to maximize value to shareholders (which may not be maximization of short term profit, but that is typically how it works out in practice)
one could argue that properly typed codebase can also reduce cost, since later, devs spend less time debugging issues caused by dynamic typing, but I get what you mean
pyright already goes out of its way to make standards rather than do plugins like mypy for example
e.g. dataclasses typing PEP
I could just be naive though, perhaps they would simply ignore standards if they gained critical mass
Again, I'm not arguing that they aren't doing so now, just like Chrome was at the forefront of pushing standards for a long time, but if any one tool gains too much of the market, especially a corporate backed one, there is the serious risk of them not seeing the value in doing so in the future. Not only that, but there's a strong incentive for other tools, applications, plugins, etc. to interoperate only with that tool, and not with the standards, if doing so is easier in the short term. We've seen exactly that happen with WebRTC, using Chrome's bespoke implementation rather than following standards, which is why stuff like Slack and many others only work with Chrome (and Chromium-based engines).
That's true, though they are still surely paying far less than they would save long term on server, hosting, electricity, etc. costs
There's no law that requires "maximizing value to shareholders" either, corporate law states that CEOs and company directors must "act in the interest of the business itself", which is just about vague enough to mean anything at all (and in fact the business judgement rule pretty much means that as long as there wasn't a conflict of interest and the directors/ceo made a reasonable attempt to stay informed, that the courts will assume they were acting in the interests of the business itself).
And the hiring + perception benefits. ;)
This is mostly important because I think letting companies hide behind "but the law say...." lets them scape goat the law 😛
They're making a choice to do X, there's no legal compulsion forcing them to
@muted whale I have a bone to pick with you -- why do I see that every conversation you're involved in ends up having a discussion about legality of things, or correctness of processes, or something like that? 😛
This was threatened re @sealed
Meet works with Firefox and Waylaid
@onyx sphinx re. #general message what happened? I'm happy to chat in DMs if it's better that way. Curious since isidentical is a maintainer of black
(if we chat here, I'd suggest a thread as to not derail the main convo here)
funnily enough, I was discussing Pyright with attrs' devs earlier today: https://github.com/python-attrs/attrs/issues/996#issuecomment-1210715336
plugins are a workaround, not a proper solution
they're specific to each type checker
I'm actually surprised at the "nobody uses mypy" bit, it really feels to me like the opposite is true.
I guess collectively with pylance that makes sense though
I wonder how true that statement would be if not for vs code
well, creating a plug-in for attrs is a lot cheaper than extending the type system
to do it properly you are gonna need intersections for class composition and mapped types for the attributes, and I don't know what else
it's a process that's gonna take years
and that no one in their right mind is gonna take on without funding
The issue does a really good and interesting job describing the status quo; in particular that Pyright (via Pylance) is widely deployed as a Editor/IDE/code analysis tool (on the individual developer side), whereas MyPy is dominant as a linting tool (on the project side)
Fruedian slip?
I see; I apologize for being misinformed—I suppose serves me right for leaning too heavily on what I've gleaned from Wikipedia, Leonard French and skimming a couple suit filings rather than actual legal opinions on that specific topic
AFAIK, the primary driver is largely C*O compensation is heavily tied to stock performance, so they are incentivized to maximize short term profits (and then those compensation structures ultimately come from the shareholders, via the board)
plus it tends to be easier to make it look like you're doing something good if the share prices go up
Ah yes indeed, very true...I was confusing that with corporate law (and the contrast with public-benefit corporations)
(and then those priorities end up filtering down through the org)
CAM Gerlach9960 I have a bone to pick
IMHO Pyright upstreaming dataclass transforms has done immense damage
It's one of those working solutions that prevent good solutions
It added at least a decade to better programmatic type annotation lifting
Lifting?
Practically it's applying transformed type annotations of one entity to another
Ah markshannon's hygienic macros?
Not necessarily macros but putting transformed type annotations onto other entities
yay I finally got access to DALL·E 2
that's adorable awwww :)
yesssss 🐍
maybe also try to generate a more stylized version for favicon and similar uses
Precious! 🐍
Cute!
There's one major barrier to this: the copyright/legal situation is very tricky https://www.technollama.co.uk/dall·e-goes-commercial-but-what-about-copyright . The actual copyright status of AI generated works is unclear and varies by jurisdiction; in some jurisdictions (like the US) it seems they may likely be public domain but there is no clear precedent yet; in others (UK and most EU) it seems they likely are copyrightable with the copyright falling to the image creator. However, on top of that, DALL E's ToS and policies attempt to use contract rather than copyright law to enforce themselves, and furthermore assert that if the images are copyrightable, copyright is assigned to them , but DALL E's ToS then assigns that copyright to them, with no clear (much less FOSS-compatible) license.
Therefore, this results in a potentially problematic situation using it with a FOSS project like this. If its included in part of a larger FOSS work, like a website, docs or particularly Hatch itself, it makes the license situation for the combined work more complicated, as its legal status varies across jurisdictions and there is no clear FOSS license terms, with OpenAI's contract law mechanisms being an additional potential problem for you (but not your users). Yet, in many jurisdictions others may be able to use it as their own with no attribution or even permissive license.
Note that the colored boxes on the bottom right is a watermark and must be kept I think.
I couldn't find any policy referring to the watermark in their various policies, and this thread https://www.reddit.com/r/dalle2/comments/wl4fwu/how_to_remove_the_dalle_watermark_guide/ states that they have explicitly stated that it is allowed. Furthermore, not being able to do so would be a very serious problem for using the image, since it would prevent you from knocking out the huge white BG, which would make the image useless as a logo in most contexts.
However, I myself am not a licensed copyright attorney, so I suggest getting some actual legal advice here from one familiar with open source
On a technical note, if you use it I also suggest palettizing it to ≈64 colors—this will avoid any fingerprinting they may be doing, and also massively reduces file size by nearly 20 times (!) (480 -> 26 kB, and that's not counting optipng optimization) with minimal visible quality loss except on the shell, which you could either accept or flatten to fit with the flat tone of the rest of the logo
this is GPT-3/text and not DALL·E/image but: https://web.archive.org/web/20220604004120/https://twitter.com/AlSweigart/status/1532395818694606848
@quartz yew Where does Arch Linux store its patches to pip and Python?
Or are there none?
we don't patch python, there's just a minor thing but that looks to me like an upstream bug
the only patch in pip is setting the debundled variable
the guidelines say we should debundle dependencies if we can
there are many reasons I think, but one of the most relevant is to allow us to keep track of CVEs and be able to deploy security patches easily
Same rationale as Debian. After doing that for several years, we came to the conclusion that it wasn't true that "we can" (without a lot more volunteer time than it was getting)
What's the best way for a project to send a message to debundlers and vendorers
Also I've noticed a significant step change in communications from debundlers (distributors? What's the preferred name) in dealing with issues caused by running our test suites incorrectly
Like y'all now hide the tracebacks in little html Twistie buttons (which I didn't know you could do) and put a nice bit of flavor text and solutioneering
I use Refined GitHub chrome extension which adds a lot of QoL improvements one of which is adding the button for this to the editor (unless that's a part of regular GitHub?)
And now it's like "hey we ported your project to 3.11.a2 and it sprayed an endless stream of tracebacks from the test suite, it seems to be an interaction with x and y" and followed by a per category series of tracebacks hidden in Twistie buttons
Then I can just say "oh that's a 3.11 bug" and rage close the ticket 😉
Yeah I use GitHub refined too
But still didn't know about this as like "a thing you could do". It's just plain html so I did know really I just didn't make the connection
Huh, I didn't know this is just part of html
Maybe I thought it's a custom XHTML tag styled by GitHub's stylesheet? Idk lol
I never really thought about it
Changelog entry? That's what I read, when updating a library.
Yeah I guess that makes the most sense
It does look cool and well supported as open source https://github.com/refined-github/refined-github project.
Oh, Refined GitHub is awesome.
Refined GitHub FTW...though to be fair, it has so many features it can do a ton of things I don't know about, and GitHub has also been (eventually) adding a lot of them to regular GitHub, like move tracking (finally).
It does freeze Firefox sometimes
Like it does a huge amount of crunching to make the blame view work correctly
But when you're looking at 10yo+ project that's been ported between 3 VCS it just grinds to a halt
I have seen this, though on a pretty old downclocked laptop and on very large commits/PRs—though I can always temporarily stop it if nessesary, and I probably don't need all of several hundred individual features turned on, heh
Yeah don't avoid it because of the odd freeze
Just prepare for it and know it's worth it
Hmm haven’t noticed it freezing up my Firefox. Maybe you could try turning off some of the features (I only have a small number of them turned on)
😦 but what if I miss a feature I didn't know I needed
they have a cool find feature button
so you can just use that to figure out which feature is causing freezes
a'la git-bisect
The bisecting is somewhat fun too. :)
it used to not be under show debugging tools button and just shown without having to click
It seems there isn't a #meta / etc. channel, so I'll ask here — <@&815744082823348274> s, have you thought about role tags for the PyPA project users are a developer of? That would be super helpful IMO for keeping track of who's who, who's the expert at what, and what perspectives people are bringing to the table in a discussion
I've thought of doing that and I'm in favour, but it felt wrong to just assign a role to someone without them knowing at all
I don't know why I didn't think to ask/let them know afterwards ¯_(ツ)_/¯
We have that, it’s just not been applied consistently
any admins can do that and I do encourage people to do so
currently any maintainer of a project is also admin, if I omitted someone let me know
Go for it @silk jungle :P
annnnd now the audit log is like 50% me 😄
anyway, I went down the list of PyPA projects that have a channel here and created a role for the project (maintainers) if there's at least one maintainer in this server. (i.e. I didn't make a role for #pyproject-hooks )
I cross-referenced the PyPA GitHub teams to figure out who is a maintainer of what, please holler if I got something wrong!
actually I went ahead and made a role for packaging too even though there's no channel for it here because I felt bad leaving Brett uncoloured :p
here is something I implemented for a single guild bot in a different community.
The roster gets updated if any role on the server changes (some gets a role, someone loses one, one is created), so it is always up to date.
Just to give you ideas maybe
Edit: Exporting messed up the formatting so I also grabbed a screenshot directly
are you suggesting a #info channel or something?
in the other guild it is a channel called Team-Roster under the Information-category, where no one except the bot has write privileges
FWIW I'm not sure it would be necessary, since folks can just scroll the memberlist and see the colors, no? My original request was more about interacting with people in a discussion, when I can see their role directly. But that's just my personal take
I guess that could be useful for other PyPA members, but they should already have access to this information via GH (tbf they'd have to know/guess the discord account). For other users, I mean meh? It sounds like something that'd turn into regular users pinging maintainers for support
completely understandable, just wanted to show what is possible not necessary suggest it
yes that was always the fear, but we also found out that user that would just ping maintainer for something like that, are not the kind of users that would even look into the channel 😄
Edit: Exporting messed up the formatting so I also grabbed a screenshot directly
Is that why there's Korean writing? :P
you actually made me go through the image to find messed up chars, I guess you mean the anonymization 🙂
yeah, that character is Korean k
or were you referring to the blurred text?
I meant the ㄱ
ohhh, no, I actually played around with unicode chars, and must have selected a korean one.
I mostly used that char because it gives the impression of a isometric cube border in the discord UI.
You can see in the first image (the screenshot) how it looks in the app and not exported
Kind of ignorant of me, should probably change that, but interesting that this is up for a year now and no one said anything
Holler? 😆
YES 😛
That's gonna be a lot of work, especially to keep up to date.
Yeah...that would seem to be the main obstacle, unless someone makes a bot like @arctic copper mentions that automatically assigns/removes the roles based on team/repo permissions retrieved via the GitHub API...which would be non-trivial
# via pygithub library
import github
from pprint import pprint
org_identifier: str = "I AM THE LAST PART OF THE URL OF THE ORG PAGE"
token = "GET ME FROM ENV-VARS AND DONT REALLY STORE ME HERE IN THE SCRIPT"
client = Github(token)
org = client.get_organization(org_identifier)
all_write_permission_per_repo = {}
for repo in org.get_repos():
try:
contributors = repo.get_collaborators()
# get_collaborator_permission() just returns a string, which is in my opinion funny in an library like pygithub that has a million classes.
all_write_permission_per_repo[repo.name] = [user for user in contributors if repo.get_collaborator_permission(user) in {"write", "admin"}]
except github.GithubException:
continue
pprint(all_write_permission_per_repo)
def get_all_discord_user_with_role(bot,guild_id:int, role_id:int)->list:
guild = bot.get_guild(guild_id)
role = guild.get_role(role_id)
return role.members
# to assign a role
await member.add_roles(role_id, reason="For the discord logs")
# unassign
await member.remove_roles(role_id, reason="For the discord logs")
Only problem would be to associate the GitHub user with a discord user, but this could be handled, by having the bot just ask an Admin via DM for the users Discord-ID if the bot encounters someone he does not know.
Then store the GitHub identifier and discord identifier in a simple key-value thing (SQLite, json, maybe even just csv) and also use that thing to check if the bot already knows the user.
Then the discord part, get all user with that specific role, every user that has the role on discord but not on GitHub, loses the role on discord and vice-versa, if you want a snippet for the discord role assignment, I can post it, just let me know.
EDIT: added the discord interaction snippet, how to correlate a github user to a discord user is something that can be done in a lot of ways, so I did not add it here
good catch @errant spade , I somehow missed CIBW when assigning project roles 😅
at work the Director of Technical Community and Open Source was very nice and said will take a look tomorrow at the ToS and overall legal aspect
he said as far as he understands it is actually fine 🎉
https://openai.com/blog/dall-e-now-available-in-beta/
Starting today, users get full usage rights to commercialize the images they create with DALL·E, including the right to reprint, sell, and merchandise. This includes images they generated during the research preview.
Users have told us that they are planning to use DALL·E images for commercial projects, like illustrations for children’s books, art for newsletters, concept art and characters for games, moodboards for design consulting, and storyboards for movies.
someone from design ops at work is helping with logo checklist 🙂
In light of yesterday’s phishing attack, we have updated the eligibility requirements for our security key giveaway.
Any maintainer of a critical project, regardless of whether they already have TOTP-based 2FA enabled, is now eligible:
now I don't feel bad anymore that I disabled 2FA temporarily to get a free key 😛
I forgot I had this open, if anyone wants to upvote https://github.com/vinta/awesome-python/pull/2014
or rather, approve it says
I don't understand why it was limited in the first place
it makes sense for people who had 2FA with an hw key, but not for just regular 2FA
Yeah, I don't really either. Like I said on the Discourse thread: https://discuss.python.org/t/fishing-attempt-pypi-package-validation/18450/8
How come maintainers of critical projects who have previously gone to the effort to enable 2FA (like myself) aren’t eligible for the free hardware security key, only those who have haven’t yet bothered to not do so? I know that wasn’t the intent, but it feels like it penalizes maintainers who take the effort to proactively implement good security practices while rewarding those who haven’t.
Additionally, especially if simply disabling 2FA after already having it enabled made the code show up as reported here (which I naively assumed it wouldn't), it actually created a perverse incentive for people to disable 2FA in order to work around the system and get a hardware key, which actually weakens security overall.
Also, the brings up a related concern of people just claiming the free keys and then selling them, giving them away or letting them collect dust and eventually enabling TOTP instead. Perhaps users who claimed that offer should be required to use 2FA with a hardware key once it starts being required, after a couple months or so, to ensure they actually use their key for their intended purpose?
I don't think that's a good idea, I think it's great that PyPI managed to allow more people to see for themselves whether security keys are right for them but if it turns out they're not then not allowing to switch to TOTP would be annoying
Yeah, I could definitely see a number of edge cases with it. Maybe I'm taking a too much of a game theory approach in it by assuming too much untrustworthyness in the actors involved
I think it's possible someone will do this, I don't think it's that big of an issue
If someone already has a hardware key, they can claim another here too and then your solution wouldn't help either
and there must be some way to emulate a hardware key, right
people will always find a way to game the system
hurting fair players in the process is not great
pfft, emulation is the hard option here lol
PyPI supports WebAuth so you can just use your phone as your security key
It was limited because we weren't sure how many people were going to claim a key, and we didn't want people who already had TOTP enabled to snap up all the keys, and prevent someone with no 2FA at all from getting one
we had a finite number of keys to give away, so prioritizing the people they'd have the biggest impact on (for some definition of biggest impact) was the motivation
since going from no key to u2f is a much bigger security win then going from TOTP to u2f
I suspect the people who didn't had any 2FA at all wouldn't care that much
I think that getting free stuff is great way to convince people
people who didn't have any 2FA might not have known they can set up 2FA on PyPI too
Maybe they wouldn't have cared, maybe not
it was a strategic decision to ensure the biggest impact first
I guess, but if they hadn't TOTP which is essentially free I think it is fair to assume they either don't care or think it's too much of a burden 😅
the jump to 2FA is big
Dustin had been talking about relaxing it for a bit now, since we had plenty of token codes left over, and the phishing attack was just the final straw
that makes sense
and anyway, thank you so much for doing all that work
I was just nitpicking 😅
(I had almost nothing to do with it besides shitposting on Twitter after the fact)
would it be useful for PyPA members to have a 1Password team account?
maybe on a per project level? I cant' think of any pypa wide secrets
API keys and role accounts kinda removed the need
And if we'd must I'd prefer the OSS https://bitwarden.com/help/getting-started-organizations/ over the corporate/Mac friendly 1password
Python tooling could be much, much faster. To prove it, I'm releasing ruff, an extremely fast Python linter. ruff is 10-100x faster than existing solutions.
Ruff currently implements a small subset of flake8 rules
I’ve never understood how those tools written in foreign languages (as in not the language used by the community they serve) sustain. Python tools already have few enough contributors.
This project specifically is fresh out of the oven (like a month old) so I don't know if it will sustain. But tbh,as long as people don't burn out, you don't necessarily need that many, I guess.
Flake by itself is not enough, real power is in plugins
Rust is the next big thing so people using all kinds of languages are interested in it, I don't know how long that will work though :)
I only use the base flake8 myself
I once looked through a lot of flake8 plugins but a lot of them are just wrappers of other tools and I don't need that
there seems like there's only a few that offer lint rules
flake8-bugbear
I feel like most people that use flake8 don't actually use any plugins aside from the default ones (pyflakes, pycodestyle)
not to say the plugin system isn't great, I just don't think it's required for most people to consider the new tool as a replacement
as long as people don't burn out
Not something I’d bet my money on tbh. Implementing fast tools with foreign languages is definitely not a bad idea and I’d encourage anyone to try it out, but I’d caution against overexcitement.
Well, I'm partially posting it here because of the debate we had about flake8 and its authors here not so long ago :P
and hey, gotta be excited about something
I do also wonder how some tools written in foreign languages sustain but to be fair, parts of the Python community have to know other languages anyway to say, write CPython, pyodide. These are of course much bigger projects so it's easier to find people interested but I don't want to cross it out just because of the language it's written in not aligning with the language it's written for
I have high hopes in Zig, it seems like a language Python programmers can pick up fairly easily. But their packaging story is… well they have the excuse of being new.
There's a lot of projects that go public too early and that's honestly my bigger fear for projects like this.
Yeah same, I kind of sense some said overexcitement from the early publication which worries me
A lot of Rust projects specifically suffer from this too 😄
ooo relevant convo. im building a package manager with rust hehe. but for fun really more than anything else.
ruff looks nice. ill def check this out 🙂
$ black src/build/
No Python files are present to be formatted. Nothing to do 😴
$ ls src/build
__init__.py __main__.py __pycache__/ env.py py.typed util.py
I guess "build" is in Black's default excludes
the new ideas forum on the Python discourse is even less pleasant than the mailing list it replaced
quite the feat
Web has less entrance barriers than mailing lists, so you catch more pain
does pylint have anything like eslint's shareable configs, or rule categories you can manipulate? It's got a horrific amount of rules and a lot of them are just noise. You could disable=all and then enable the rules which aren't purely stylistic one by one but I don't think there's enough hours in the day month
guess not, found https://github.com/PyCQA/pylint/issues/7120
You could enable all Fs and disable everything else for starters
And then go from there as the time goes
thanks, I tried:
[tool.pylint.main]
disable = "all"
enable = ["F", "E"]
and all I got was a handful of false positives mostly relating to typing/stringified annotations on a code base of some 6k LOC. I'll do W next and see if that yields anything actionable
Oh yeah, I meant all Es
my bad 😄
I confused the naming
Es are errors Ws are warnings, everything else is at least partially a convention
some of those conventions make more sense than others depending on what you're looking for really
not to say that some of Ws aren't in some way stylistic but they're way less opinionated I would say. E.g. there's a good reason for using %-formatting in logging but you could say it is a convention
btw, here's a table that may be somewhat useful to determine which of the messages to disable by checking the "disable by default" column
https://github.com/PyCQA/pylint/issues/3512
thanks 🙂
There's going to be a 3.11 release stream in roughly 20 minutes FYI. https://twitter.com/pyblogsal/status/1584489542157205504
Do you want to watch how we release Python 3.11 live? 🐍🎉 Join us in the 3.11 release party organised with the good people of @PythonDiscord at 17:00 UTC+0! 📆 We will talk about some of the new cool features and a sneak peek into what's coming in 3.12 👀 https://t.co/nMvsEIdjoE
so, I'm embedding on one of our Vector (Rust) teams for 4 weeks
is pure magic
puts everything else to shame
c++ in visual studio, pycharm, goland, everything
Oh yea, I love the IDE experience with Rust.
ppl have been asking for monorepo support in Hatch
my plan now is to simply copy Rust's workspace concept
rust workspaces are pretty good
also I'm quite impressed by Clap (the Rust version of Click)
yes please.
or use maven for inspiration. maven is boring tech but it just works.
This new GitHub search and file view UI is nice, but it's such a pain to get used to
I'm used to using the search box to jump to other repos, but now the command pallet is the only usable option
Also the new file view header consumes a lot of vertical space, wish I could hide it
I shrink github with ublock origin custom css/js
filter:
github.com#$#body{ max-width: 1280px !important; margin-right: auto !important; margin-left: auto !important; }
I'm perpetually plagued by Windows issues https://github.com/actions/runner-images/issues/6561
my first blog post 🙂 https://ofek.dev/words/guides/2022-11-19-writing-a-cli-in-rust/
In this post I’ll walk through the setup of an example project to show how to build a modern CLI in Rust.
you can
scroll down to the bottom of the left pane:
They should add a way to hide it in the new code view
oh wait, the vertical space
i got confused and was thinking of the sidebar
and the sidebar is hideable anyways (as i just learned)
Opting out is meh solution if you enjoy at least some of the improvements
but i like the new top header, its quite nice on long files to be able to see what file I'm currently viewing, or press blame/raw/copy raw
I don't entirely like the new ctrl+f experience
I like the features but it feels slow
Anyhow, those kind of things should really be sent as feedback to GitHub
So they can improve some of this at least
i didn't like the old one :^)
The one built into browser?
Agreed
I just want to be able to find a thing
I don't need to see the symbols -- I just need to find my function
no, there was a regexish search they had built in which it would default to when i used ctrl f
i swear it wasn't always the editor 🤔
Pretty sure it was
But yeah, the code view's new search isn't as fast as the browser's one which annoys me but it does have cool features
I just wish it would somehow postpone loading them all until the base search happens to make it smoother or sth like that
I know I can still use browser search but I would prefer if I didn't have to do that for smooth experience
fair
@cold estuary Is organisation billing for GitHub Codespaces enabled on the psf organisation? I'll probably try out Codespaces on psf/black, but I don't want to accidentally incur a charge on PSF's dime.
hmm, I'm surprised they don't tell you who's going to be billed for the codespace you create, like at all
They do
I guess this means my personal account will be billed?
Should be, yeah
Create one, and then go to https://github.com/codespaces, and you'll be able to see if it's owned by you or the org
Would the organisation be billed if I simply create one without doing anything else?
No. ....but don't quote me on that.
But you can see that the pricing on mine is all still zeros, because it wasn't even around long enough to count towards it
Billing reference: https://docs.github.com/en/billing/managing-billing-for-github-codespaces/about-billing-for-github-codespaces
I'm just hesitant and prefer playing it safe since I am an (outside) collaborator on the repository.
Ah, yeah, you guys are actually excluded by default
Also how does billing for forks of repos owned by an org?
But this is all just my orgs, I have no idea what y'all've setup
If you want to be sure, then no harm in just waiting a bit
Ah neat, but yeah I'll wait.
Usage of codespaces created from a forked repository will be billed to your personal account unless the upstream (or parent) repository is in an organization that has allowed you - as a member, or outside collaborator, of the organization - to use codespaces at the organization's expense.
There's no rush, my laptop is more than powerful enough, but I'm curious if I could use codespaces for when I'm not home.
when the link is as long as the text
Ah that makes sense.
I initially read that as in anyone, member / outside collaborator or not, can incur charges at the org's expensive if the repo is owned by it
... which makes no sense now I think about it since that'd be highly problematic for public repos
problems is that don't always show it
does it at least show that it will bill the org if you do it from here?
or is it inconsistent too
Damn, even the dual-core machine is 50% faster than my laptop (this takes a minute locally).
Immediately? They've just acquired it.
it's the choice to acquire a team that hasn't been able to make their core product less buggy
Maybe they plan on reworking the team? Add other people, shift focus?
hopefully it improves 🙂
I'm currently of the impression that sentry can turn it around, but it's going to be a tough pill of debt
@muted whale Would you know why the Python 3.11.0 docs are displaying enum.auto's documentation from https://github.com/python/cpython/pull/99149 ?
that PR is a backport of the original https://github.com/python/cpython/pull/99148 into the 3.11 branch
the author wanted it backported to 3.11:
https://github.com/python/cpython/pull/99149#issuecomment-1304685357
But there hasn’t been a Python release with that change yet, it’ll be in 3.11.1
So someone who’s browsing the docs today will be misled (as I was)
ah right, I see the confusion. it even says 3.11.0 at the top
I think this is definitely worth a versionchanged note, people often browse the latest docs and will happily assume that it works in earlier (minor and major) versions
Seems like Hugo answered your original question, but I posted on the backport PR about your concerns
well, I was mostly surprised that the change would be published, without realising that the Python docs aren't versioned that way.
They aren't versioned down to the patch level of granularity, as the great majority of docs changes in patch versions are just fixes/improvements to the existing docs, rather than changes in Python's behavior. We generally try to keep the bugfix supported versions up to date with the docs changes that aren't specific to a change in the current branch.
yeah, that's why my suggestion was to add a version note, unless you can think of a better way to handle this, without changing the docs "regime"?
Per the suggestion, added in https://github.com/python/cpython/pull/99997
regarding coverage: per release notes, PEP 657 (improved error locations) will add the necessary info to get subexpression location into coverage data. That’ll make code coverage so much better once it’s implemented!
OK, color me impressed.
It's objectively wrong, but it did get the PEP number right.
And, it's possible to spoof it.
But still, that's cool.
(and it's not build metadata, though I understand the confusion)
Is that GitHub Copilot or something?
Whatever it is, that's...pretty cool. But also a little creepy...
ChatGPT
Ah, I actually tabbed over here to ask if it was ChatGPT instead
Had a brain fart there
That's very impressive, but that's the scary part—with human answers, you can often tell just by skimming it that an inaccurate answer is low-quality, as there are other signals that tend to correlate strongly with it—short, bad writing, wonky formatting, obvious mistakes, poor tone, and just overall pattern. But those written by ChatGPT tend to mostly lack those obvious signals, and the clues that they are likely inaccurate or generated by an AI are much more subtle, and I expect to see a proliferation of such misleading content on Stack Overflow and across the web on blogs and content farms that are already bad enough already. Which it seems is already happening on SO https://meta.stackoverflow.com/questions/421831/temporary-policy-chatgpt-is-banned?cb=1 .
The challenge is how to actually detect that an answer is written by ChatGPT...you almost need another NLP model for that, which could breed an AI arms race between generators and detectors.
Yea, I saw the ban and the most upvoted answer to that is a bit... eerie in terms of how good the generated responses are.
Yeah, lol...
#354619224620138496 message as well (Python discord)
Where I could see it potentially having value is partially automating the ceaseless task of asking issue reporters for more information and to try some basic troubleshooting steps, to then be escalated to a human
Oh I'm not on that one; what does it say?
We've seen increasing use of ChatGPT, a new chatbot, in our help channels. The use of automated tools is not allowed for producing answers in our help system. This includes chatbots, code generation tools, and copy/pasting answers from search engines (as an answer itself, obviously it's fine to include external sources as part of your answer). Our help system is not intended to be an intermediary between help seekers and an external platform.
We would also encourage people not to use chatbots on their own as an educational source; they are a text extrapolation tool and the semantics of their responses are only meaningful insofar as they're correlated with the semantics of the texts they've seen. We've observed answers from ChatGPT that are inaccurate, but which are presented as authoritative.
As always, our help system is intended for questions that benefit from dialogue. Rapidly responding to questions with links to Stack Overflow or documentation pages, without any question-specific guidance, is also a misuse of the system and will be considered spam.
(formatting was lost, and I dropped a couple of lines above and below)
Seems like it isn't happy about it https://meta.stackoverflow.com/a/421850
Yea. XD
😂
I love how SO meta bubbles up an equal mix of (a) really smart replies or (b) really funny jokes.
That, or if its a post about company stuff, like Articles™ or Collectives™ , everyone just goes to town on it.
List of new possibly ChatGPT generated answers https://stackoverflow.com/search?tab=newest&q=is%3Aanswer It looks like the issue&s=cc170b18-d28f-46a8-8df7-dbe2294d0c27 ... a lot of them are not, but the first one definitely is
It's terrifying in a way tbh
AI destroying civilization not with guns and bombs, but by dissolving our ability to rely on the accuracy of our written knowledge.
(And, to be clear, that's hyperbole, to serve the point)
music is next
I hope not! I wasn't impressed with ChatGPT's ability to help me write lyrics
not sure if im relieved or terrified that country music will be the first victim hides
when I have free time I wanna set up OpenAI's Whisper to increase my productivity (typing without auto-complete like here or Slack is really taxing on me)
it needs better surrounding tooling and you better have a good gpu - im running it local on cpu to transcribe some interviews my wife did and its rather slow (a few hours when using a accurate model against about a hour of interview)
are you using the new one? https://huggingface.co/openai/whisper-large-v2
woah their social card renderings are slick
@junior narwhal nah. only medium, its accurate enough and the larger they are, the slower they run as far as i understood
my entire life I've been frustrated with the accuracy of Dragon NaturallySpeaking
so just refused
i can understand that, someone in a similar position onc showed me his frustrations in person, most infurating
music is next
To be fair, computers were doing that 65 years ago...https://en.wikipedia.org/wiki/Illiac_Suite
Illiac Suite (later retitled String Quartet No. 4) is a 1957 composition for string quartet which is generally agreed to be the first score composed by an electronic computer. Lejaren Hiller, in collaboration with Leonard Isaacson, programmed the ILLIAC I computer at the University of Illinois at Urbana–Champaign (where both composers were profe...
Technology is doing a 180 for artists. It removed the requirement to work a major enough label to help you produce and promote your track, with YouTube/SoundCloud/Spotify/TikTok kickstarting new artists left and right. Now it might be soon stealing the attention of consumers...
If you use Black, we are looking for your feedback on the proposed 2023 stable style. As per our stability policy, Black 23.1.0, due by the end of January next year, will format your code differently out of the box — no --preview flag needed.
https://ichard26.github.io/blog/2022/12/black-23.1a1/
https://github.com/psf/black/issues/3407
great lesson on how to not do open source https://github.com/aws/sagemaker-python-sdk/pull/3529#issuecomment-1358685376
for a second I thought you were saying I messed up really badly- 😅
Yeah, first part of any project is a whole lot of setups of basically everything lol
Black has no branch protection if you can believe it
I always worry when I push to main locally. I always run git push -u origin main to avoid pushing to upstream, but yeaa
You need to fix that
Don't want this happening to you
Even I've done it
Get the protection rejection and oops, let me make a branch real quick
Is there a reason for that? I can totally see that different projects have different opinions on some of the different branch protection settings—some projects don't require checks to pass, some don't require at least >=one approval and some don't even require PRs at all and allow devs to push directly to main, which is outside the norm of what I'd be comfortable with personally either as a contributor or maintainer, but I could still potentially see some justification for it on a small project where it's the familiar workflow.
But I'm not sure I'm aware of any reason to not enable at least basic branch protection on your main branch, given all it prevents without enabling any of the individual options is force-pushing main or deleting it, which I cannot imagine you'd ever want to do (and you could always temporarily allow it if you did), and it only takes a few seconds to set up—click this link: https://github.com/psf/black/settings/branches , click Add rule, type in main and click Save at the bottom.
I've mentioned it before and the general sentiment from the others was that it wasn't necessary /shrug
I could see why some people could potentially not want to have the options enabled to require PRs or things like that, but all that the default branch protection does is prevent you from force-pushing or deleting main, which I can't imagine anyone would ever want to do absent an extraordinary emergency.
Last time it was discussed: #846434317021741086 message. In general I would be in favour of locking down access to potentially dangerous actions (setting up a branch protection rule and setting up GH environments for our release CD to require a review)
I was going to do a security posture assessment for Black earlier this year, but that fell off my radar.
That's pretty bad, but seeing as it's AWS, I can't say I'm entirely surprised given their other high-profile Git and packaging follies...
Currently anyone with write access to the Black repository can effectively publish a release to PyPI.. which isn't ideal
Yea I agree. I can bring it up again w/ other suggestions later
Wait, I'm curious!
Unfortunately, I can't find a good unique search query that brings up any of the particular issues and discussions I was thinking of, but I seem to recall when they released v2 of I think awscli they completely stopped doing Git tags for releases for a while which made a lot of people frustrated, and also they decided to completely stop publishing PyPI packages and requiring that people download their binary installers, which a lot of folks were very unhappy with, and some other things I can't remember off the top of my head.
Ah, fun.
Wow, we've all taught them well 😆
I didn't expect it to auto-complete the URL tho, that was creepy.
I wonder if it's picking it up from another draft post I have?
OpAqUe SyStEmS
Talk to Tim Peters about that!
TIL they were acquired by Microsoft!
One big family 😄
The whole AWS ecosystem is embrace-extend-???. They take MIT/BSD licensed things, do a hostile fork, and sell it. No wonder they don't give a fuck about being a good Python ecosystem citizen, it's probably deeply ingrained into work culture there to never give back to open source when you can get away with it.
AWS paid me to work on PyPI part time for 2 years or so
I know multiple people who work / worked at AWS, who invested a non-trivial amount of their "work" time improving Python ecosystem stuff.
I've heard bad things about their culture and don't like how their sales strategy interacts with open source either; but... like... as a C corporation in the US where the only thing they're supposed to care about shareholder value, I don't see any way that their behaviour is "wrong" given the incentive structure the broader org operates with. 🤷🏻♂️
AWS business plan:
- Embrace
- Extend
- ??????
- PROFIT
In other news... [Python Packaging Authority]’s Technical Steering Group was something that GitHub Copilot suggested to me today.
I... chuckled uncomfortably. 😅
Seems like my theory was wrong then!
Oh for sure! Capitalism will always make a farce of any moral commitments that companies pay lip service to, as long as there's no legal obligations to uphold it. That's why the only structure (which I know and) that I can possibly trust is Mozilla's “nonprofit entity owns/directs for-profit entity”. And of course that's also far from perfect.
Luckily some companies have understood that happy, motivated software engineers do a better job, and that allowing them to contribute to open source on the side helps with that.
I just didn't expect AWS to allow that, since their business model is so clearly based on selling open source products as a service.
I respect Hashicorp's model a lot
also tbh Microsoft's mission nowadays seems to totally align with open source, public interest esp. for research, etc.
e.g. afaik they're donating most of OpenAI's compute
M$ still has a lot of dark patterns, that Minecraft vs Minecraft for window (which runs on android but not desktop Linux) really got to me
Don't forget Pylance and the whole ..NET 6 hot reload fiasco...
any idea why they might have chosen not to open source Pylance?
or what they are using ONNX for for that matter
I suspect the two are related
For everyone who celebrates something this time of year, merry christmas and happy holidays!
the temptation to add :this: as as emoji here because I'm too used to it from the Python Discord server ... >.>
You mean
?
I don't have nitro okie?
Then add it
dew it

🎉
I may have been struggling a little bit, the audit log is a bit embarassing haha
Is that why you won't make me admin?
Too embarrased?
||(/s)||
to those on the east coast best coast, happy new year's!
anyone aware of tools to make zipapps from a set of wheels ? i want to ship a set of python libraries (pure pytohn) a a single application that runs on anything that has the required python versions
Looks interesting, unfortunately it has a nin self cleaning cache
also https://github.com/pantsbuild/pex expands on that concept
pex inspired shiv. We used pex for a long while but wanted something more modern and without the baggage so one of our devs wrote shiv. The cache improves hot performance considerably and as you know you have to unpack zipapps to the fs if they have any shared libraries. (I still can't understand why dlopen() doesn't support loading from memory, esp. given that Google contributed that to glibc ages ago).
my kingdom for a dlopen with offset
that one is a bit overkill, im trying to create sometihng that given a minimal python can ease the bootstrap/startup of execnet on remotes in a more viable manner (aka push minimal wheels to some type of cache, then bootstrap into them instead of doing the dance with python scripts via cmdline args and stdin) instead of the rest
in my case, i want to avoid unpacking&co as i push pure python to bootstrap stuff, impot performance is not the primary consideration, but rather how ba cleanup will be
There are definitely solutions if you don't need extension modules. And even if you do, something like PyOxidizer might fit the bill for you. I actually played around with that a few years ago for $work, but had trouble integrating it into our workflows. I'm sure it's much improved since then.
yes I can confirm it's quite good now
whenever I have time in the next few months I plan on making a Hatch builder plug-in for PyOxidizer
@junior narwhal hope you don't mind a random ping on some issue I see you on --
do you know if https://github.com/python/mypy/issues/7511#issuecomment-689642560 is still broken
or can I just literally not figure out how to do what it's recommending
i.e. how do I tell mypy "good lord stop complaining about return without return None
warn_no_return = false doesn't seem to do it, which one of the last commenters I think was also pointing out, so it seems this still doesn't work?
[tool.mypy]
warn_no_return = false
seems to work for me… or at least I have that configured 😅
weeeeeeird
I still get
referencing/jsonschema.py:22: error: Return value expected [return-value]
which is wrong
but ok bleh I basically give up
well I trust you then, it must not actually be working for me either
I think they only "half fixed it"
they fixed implicit returning
but they didn't fix ```
def test() -> int | None:
if stop_telling_me_how_to_write_code():
return
return 12
which still complains on the return
and tries to force you to write return None
or at least that's the behavior I observe
I don't mind writing there return None in spirit of explicit better than implicit 😄
sure, I don't doubt some people don't mind doing so
but it's dumb that mypy tries to enforce one
we'll need to agree to disagree there to 😄
wow it's so interesting reading what the old me wrote https://github.com/python/mypy/issues/7511#issuecomment-636570274
it's true I was so against that I just was not using types
that was the comment that made me ping you 🙂
since I sympathized (I'm always close to throwing mypy away anyhow, so every papercut is always fun)
if Mypyc didn't exist I actually would use the one that Microsoft uses in VSCode
but I like performance...
hm, maybe I should give pyright another shot
I couldn't use it for other existing projects but this one is from-scratch so maybe...
I wish typing could distinguish between return None and return (maybe -> Void?)
-> None means you should just do return, -> None | other_type means you should do return None
I don't know if it's part of any PEP but type checkers seem to enforce that, no?
it definitely makes sense since explicit return None makes sense when you can return something else while return makes sense if you never return anything
Not sure about type checkers off the top of my head, but linting tools (e.g. PyLint) warn if you aren't consistent with that
looks like mypy enforces the latter case, pyright doesn't enforce either
Not the type checker’s job to enforce code style, pyright got it right
Exactly. return and return None are and always will be semantically identical, therefore I agree completely.
It does give the type checker the opportunity to detect when one forgets that the function is supposed to return something
Saying something returns None is saying it can return None even in a union IMO, the type checker has no way of knowing you didn't return to return None, so it should say nothing, it's purely a code style thing, which the type checker shouldn't have any opinions on
But yeah I'm gonna try pyright out, glad to hear it does this better
Cool, I suppose that was roughly painless -- https://github.com/python-jsonschema/referencing/commit/3ec760f6685be9d69e799e254ed009ff1e7e1916 -- only ~30 minutes fighting with understanding dataclass_transform, call it a win 🙂
have you noticed any difference in how fast it executes?
you probably wanna turn on strict type checking since you had that for mypy
I considered turning on strict
But it seemed to spit out lots of spurious errors
Will try it again, thanks for the rec
I haven't measured yet, we're in the "get it working" phase of this library, but will do so
also be aware that this switch might preclude the use of Mypyc fully because the type checking is different (as you've seen) in some cases
I am quite likely to re-rewrite this lib in rust at some point
So I'm perhaps less worried there
But we shall see if I bite my words
I guess in few years, Python devs will have to know Rust too if they want to help in open source
Substitute Rust with C and that prediction was reasonable ten years ago. I suspect in a few years a new language would emerge and the cycle starts all over again.
yeah, probably. However, Rust seems to be more widely adopted than C
There are also like two orders of magnitude more Python packages now
I suspect in a few years a new language would emerge and the cycle starts all over again
I would bet heavily against that notion. I think Rust is actually "the end"; I don't see anything surpassing it in terms of performance, ease of use/learning, safety guarantees, Python FFI interoperability, etc.
there will be innovation, new (somewhat better) languages will show up
the question is how much they'll stick
Perhaps an AI language 😅
If Rust is the end of the line, I hope it gets easier over time, since I (in 3-4 tries) have seemed to not be smart enough to write it for sufficiently complex programs :D, or at least not sufficiently motivated to really learn about how the borrow checker works.
It's slightly fun though in a nostalgic Pythonesque way.
I am in the same boat
most of the stuff I write doesn't need a low level language though
and the ones that do, are mostly microntroller related, where using rust is very annoying due to lack of support
and me not having the enough knowledge to just add the missing pieces to the ecosystem
so I haven't progressed much in learning rust
I actually feel the borrow checker is arguably an easy part of Rust, but Rust in general is indeed already too hard as a non-primary language
yeah, I agree
And it is literally getting harder by the day
I may not even be Rust-smart enough to know when it's not the borrow checker complaining then!
But I get stuck on silly things like "I have a serde_json value as an instance variable on some other type of object, and now everything's unhappy and wants me sprinkling lifecycle parameters everywhere, and trying to get the right ones
and then reading long pages trying to explain to me how to do so correctly
I had hopes for rust, i don't atm
I guess I'm the odd one out here but I find Rust to be much easier than C or Java
You're not. I prefer 1000× to use a language that doesn't randomly blow up with a cryptic segfault. Rust has a steep learning curve, but once you're past the hump it's really enjoyable. You write something and it either works immediately or after fixing like
1-2 logic bugs. That's just not something you get anywhere else.
(to be clear I'm definitely not smart enough for C, but no one is, so I just don't feel bad on that one :D)
why not?
C memory errors are quite fun annoying to debug, I haven't touched Rust but being able to trust the borrow checker so completely sounds really nice.
ASAN and UBSAN exist among other sanitizers. They've made C a lot nicer to work with and debug, but they are reactive. They don't help you prevent memory violations or UB.
people complain that Rust takes more time to compile, but hell, if I can trust the compiler to catch all the places that could explode in runtime, let it be 100x slower than other compilers.
if err != nil
nightmare inducing ^
I have a hotkey that types that because you have to use it so frequently, no joke
and although it is bad practice it's not entirely uncommon from what I've seen to ignore errors
is it worse than handling NULL constantly in C?
also the entire ethos of Go is incredibly off-putting to me, I'll try to find the quote from one of the creators...
The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.
That is an awful way to design a language that's memory unsafe. Want a language for those developers? Use Python. It won't blow up nearly as much in a security risky way.
I feel like it's a fancy way to say that developers are stupid and can't learn programming language
It's more and more turning into something that feels c++ ish
Slow, excessive complicated, but still hard with certain low level details while high level is subject to pain from lack of language features
C-like memory management is not as easy or simple as that quote makes it sound, luring developers with a false sense of security memory-safety-wise is not going to end well.
I've personally seen so many segfaults in software written in Go by extremely competent engineers e.g. at work, almost all tools from Hashicorp, etc.
Go is a failed experiment
It was really popular for a failed experiment
still is
to add to the pile of WTF of Go, the repository URLs as imports are another thing I don't get
is it possible to import from the filesystem?
don't know, never worked with Go past "hello world"
fair enough haha
I also dislike the VCS as dependency model but it actually makes sense if it was written "for Google" since they have a monorepo
Found 83 errors in 2 files (checked 109 source files)
thanks mypy.
tbf, I need to merge in main, I'm working on a 1.5 years old checkout of mypy 👀
solve all ur mypy probs with this 1 cool trick: put all ur code in 1 module so you can type: ignore comments just in one place
y'know what's funny, 99% of the errors are these:
mypy/visitor.py:363: error: Missing return statement [empty-body]
def visit_mypy_file(self, o: mypy.nodes.MypyFile) -> T:
@junior narwhal i partially wish non faang languages had more resources, experiments like factor, zig, nim, do look interesting, but they move in slow motion and lack integration
people: use mypy in their code
mypy: points out mistakes
people: 😱
ignoring the spurious errors that are my fault for refusing to merge in main, mypy did catch a few errors
I meant more as an answer to Julian
I mean clearly I was shitposting 😛
But more seriously, I indeed have never had mypy (or any type checker) find a real problem
So if/when it does, I may convert!
Mypy found real problems in all pytest core projects we applied it to
feel free to steal this 😄
I know, but I have seen way too much code with typing.Any and # type: ignore all over
I mean it seriously seems to be "recommended advice" by lots of people "big iNtO TyPinG"
you run into some slightly non-trivial typing thing
an expert basically tells you "yeah add type: ignore"
the one I keep coming back to personally is how difficult it seems to be to properly document public API types
which for me is literally the top (only?) thing I care about
Wtf, that's where you refractor and find bugs, shitty experts are a pain
and which potentially/often leads to types which differ between the annotation of some parameter and what you internally treat the type as
and the solution to that from what I heard is indeed "yeah use type: ignore"
Type ignores are a red flag 🙂
honestly, I find typing more difficult for pre-existing code than for new code. when writing code with typing in mind, you automatically think about code differently
(also probably I've had enough typing complaining for one day, so I may go have a beer instead :D, but will read whatever your comments are telling me I'm wrong later.)
mypyc/test/test_run.py::TestRun::run-sets.test::testPrecomputedFrozensets PASSED
wrote a new test and it worked on second attempt (I forgot a not in the test data), feels good 🎉
no one puts a frozenset in a set literal, right? I'm using GitHub code search to find any instances, but honestly it feels like the sort of thing no one but CPython itself would do
you mean like
s = {frozenset(['a', 'b', 'c'])}
?
I wasted too much time trying to add in optimization support for nested frozensets in set literals to mypyc lol
Yup
It's rare enough that mypyc doesn't need to optimize for that
I mean, I can see a reason to use this kind of data structure, but I agree, it would be rare
ah well I already deleted the extra code that handles nested sets
on the other hand, if you already did the leg work to implement it, why remove it? it's rare, but can happen
oh
it's also broken, I forgot you have to use frozenset() inside of a set literal and the patch assumed nested set literals are fine (eg. {{"a", "b", "c"}}) which is invalid Python!
I'm sure I could get mypyc to recognize nested frozenset calls as frozenset literals when appropriate, but that sounds overkill
well, I guess there are many other more important things to do in mypyc
yeah
This has become quite involved and I'm still not done 😅
impressive
@silk jungle were you the one who said/wrote to never do -> Generator[T, None, None]? if so, what should the return type of generators be?
I don't remember saying that, but it does sound like something I'd say :)
In general you shouldn't type return types as Generator[...] because the fact your function is a generator becomes part of that function's contract / the API. Iterator[T] works the most of the time (although IIRC Asottile did bring an edge case typing a generator function w/ Iterator[T] in the typeshed repo)
cool ty, will change
typing APIs is a mix of being as accurate as possible but also formally stating the contract/expectations your users can have about the function, often times it's better to give yourself some wiggle room and keep the specified type more flexible (and less specific)
before:
running in_set
..........
interpreted: 0.491995s (avg of 5 iterations; stdev 1.7%)
compiled: 0.815844s (avg of 5 iterations; stdev 1.5%)
compiled is 0.603x faster
after:
running in_set
..........
interpreted: 0.509823s (avg of 5 iterations; stdev 4%)
compiled: 0.341116s (avg of 5 iterations; stdev 0.28%)
compiled is 1.495x faster
well at least the first part of the patch paid off 🎉
nice!
now I need to fix one more bug and optimize for ... in <set-literal>: ...
Hello
https://github.com/darbiadev/darbiadev-utilities/pull/35
Please review
Thanks
I still don't like it
I feel like it loses some of the semantics
That's the point. If these are internal APIs then Generator is fine. The advice to prefer Iterator is mostly applicable to libraries and those who write them :)
Am library writer
It's about trading specificity for flexibility, your call.

But actually -- Did I do it right?
Just swapping them out?
You can really overthink this. If you're the only user of this library, maybe you'd prefer specificity more than if you were writing a library for general consumption. However, I can't make that decision for you.
Yes.
anyone aware on shared work on composite build/deploy pipelines for simple pure python projects (stuff like generating python version matrixes based on metadata, testing the artifacts that will go to pypi, token based upload as a all in one)
here's one I helped with: https://github.com/wpilibsuite/sphinxext-opengraph/blob/main/.github/workflows/workflow.yml
has an initial job to build an sdist and wheel, which are then uploaded as GitHub artifacts. then the (hardcoded matrix) downloads and installs the same wheel and runs tests.
finally there's a publish job that only runs on tags, and publishes the sdist/wheel artifacts to PyPI
@dreamy hatch i want to enable having something like that as reusable workflow and/or action (so that most simple python projects that use tox or hatch can have a massivley trimmed down ci pipeline)
yep, I saw Anthony has recently switched from Azure Pipelines to GHA, and reuses a workflow
e.g. https://github.com/asottile/all-repos/blob/main/.github/workflows/main.yml
jobs:
main:
uses: asottile/workflows/.github/workflows/tox.yml@v1.0.0
with:
env: '["py38", "py39", "py310"]'
uses https://github.com/asottile/workflows/blob/main/.github/workflows/tox.yml
that one looks pretty neat, but im avoiding tox on gha these days (my ideal would be something that installs build artifacts and runs tests againstthem in some sensible manner using shallow checkouts, but its a pain to set up
@nocturne swallow can to be passed a dist to use instead of one it builds in isolation?
I think you could pretty easily replace tox with pytest or whatever around here: https://github.com/asottile/workflows/blob/33e61164ddac055efec0febe7aaa0065ba374e9f/.github/workflows/tox.yml#LL56C12-L56
each job is running in a fresh env anyway, with a single Python version:
https://github.com/asottile/all-repos/actions/runs/3803095419/jobs/6469206480
@dreamy hatch atm im jsut being a bit nitpicky - the pain point i still havent spend time is stuff like effectively mapping requires-python to github python versions and making fi matrixes/dependenc graphs/cache usage
I'm bad at typing. Cooper can confirm :p
https://github.com/python/mypy/pull/14409/commits/1b75b7de473dd8550f2e17b9c9f04034be6ecfcc importing typing broke the build 🙃
you're better than me... when debugging I either force push to PRs or commit message is .
This is a public PR now so I try to avoid force pushing. However when I'm on a private branch, I set new records for the number of times I run git fix && git push -f
git fix is an alias to git commit -S --amend --no-edit
I also have git amend (drops the --no-edit flag so I can edit the message too) and git reword
I do git add --all && git commit --amend --no-edit
pretty sure that would lead to a git nope => (rm -rf .git && shutdown)
:)
I would add this as part of prompt, just a random chance to call this 🤣
Heh, that's totally me—I try to be extremely circumspect with commit messages and pushing on public PRs, but on private branches I've worn out my keyboard with how much I git fixup -a && git push -f ( where git fixup is git commit --amend --no-edit, like yours)
My working directory is constantly dirty so git add -A doesn't really work for me 😅
More like git ragequit
Untracked files:
(use "git add <file>..." to include in what will be committed)
.diff
.vimrc
bm.py
boom.py
check-build/
crash.cpython-38-x86_64-linux-gnu.so
crash.py
exercise_ops.py
fwdref.py
fwdref_stress.py
mod.py
profile.pstats
profile.svg
set.cpython-38-x86_64-linux-gnu.so
set.py
test.py
unary.py
wat.c
A reading from the first book of Linus:
And the LORD said "Let there be
.gitignore"...
How much of that is generated?
"yeah let's just .gitignore all Python files, time to rewrite everything in Rust, heck yea!"
2, the rest I've created
Heh, well I have a temp.py in my global .gitignore just to dump stuff like that in since I do it so often, heh
I might create a temp folder and gitignore that. Smart idea.
The Church of Rust BTW approves this message
I would drive myself nuts having to manually add stuff all the time and inevitably make a mistake, though I have gotten in the habit of always using git add instead of -a as I would often add the latter habitually after spending 10 minutes carefully curating my commits with git add -p
Personally, I was always a believer in R lord and savior
I almost never use --patch. I just let my commits suffer and banish atomic commits to the shadow realm :P
Funny enough, at the lab I was at literally everyone used Python except for me and we were always bantering about Python vs. R. Now look at me, defected to the dark side..."You were supposed to destroy the Python, not join them!"
I need to learn to use patch
I either just make smaller edits, and commit them one at a time, or just dump them all together like @silk jungle
I make too many mistakes to make clean atomic commits, okay?
I also have a habit of forgetting about cleaning up my "[wip] i did something" commits
I don't do it as much now that I'm contributing mostly to repos that squash merge everything anyway (which was not the case back in the day), but still even have a bit of a Sienfield-like obession with commit hygene.
My only saving grace is that I try to write good commit messages. Although even here I'm inconsistent...
Yea, most repos use squash merges these days, although a rebase merge can be nice if you have a really clean commit history.
rebase merge can be nice
What did rebasing do to you?
huh, interesting how remote got a new commit while you were fixing your branch locally
Reminds me of this https://github.com/python/cpython/pull/98883#issuecomment-1296490071
I so remember reading that oh my gosh that was a good read. I can't promise I read the whole thing though.
Woah
@Robin get in here
You thought mine was a lot? Check this out

how dare you blame the user!?!?!?
It's always the tools fault!!11!!!111
For me git rebase was very intimidating until I got used to using it regularly, at which point it becomes a breeze. It's just that getting to that point is...not. Especially since its a really bootstrap problem.
Rebase is great once you understand how git actually works
I approve a love of NTSB accident reports. Haven't read any but I have seen way too many Air Crash Investigations episodes.
It also helps that once I did slowly start to figure it out, I became the go-to CAM for helping other devs fix their git problems, which greatly accelerated my own learning and made it much easier to recognize others' problems quickly (and my own). But it's just that getting to that starting point that can be a challenge.
Oh - CAM is a title?
No haha, that was just a dumb pun ("go-to man").
Only 30 minutes!? Nice! That's pretty quick!

