#off-topic
1 messages · Page 2 of 1
Only two officially, heh
Simple skill issue
All it takes is a quick trip to the records office, and you can have as many names as you want.
Put them all in the middle and you don't even have to change your paperwork!
Or for me, just have your parents do it for you:)
No skill required
Most of my team at $WORK use GUI for git, guess who is a go-to man when they break stuff...
How many hours do you think you've spent fixing other people's git messes?
It reminds me of this
//
// Dear maintainer:
//
// Once you are done trying to [teach someone git],
// and have realized what a terrible mistake that was,
// please increment the following counter as a warning
// to the next guy:
//
// total_hours_wasted_[because_of_git] = 42
//
42 might be a bit low ...
I'd need at least a 16-bit integer...
Lets make it a 64-bit 🙂
Fun fact: The A stands for A-a-ron, which is not-uncommon internationally but relatively rare in the US, especially around the time I was born, whereas the girl's name Erin (pronoucend the same) was much more common. I was originally supposed to be named "Aaron Christopher" but when I was born, my then-6 year old cousin told my parents "You can't call him Erin, that's a GIIIIIIRLLLL's name!!!" so they swapped it a few days after I was born. My mom also added the "Manning" a few days before the 1-year-old deadline for having to go through a whole process to do so before a judge (it was her last name, but my middle name).
And as they say, the rest is history.
Wait did Aaron Carter fell into obscurity so fast?
Who's that?
Hah I guess he did. He’s the younger brother of Nick Carter, a member of the Backstreet Boys. Think Justin Bieber but 2000.
Oh, were they a boy band like the Jonas brothers?
Yeah something like that except he’s not actually part of that band
A-a-ron
@muted whale you've invoked https://www.youtube.com/watch?v=Dd7FixvoKBw
I miss that show. they ended while it was still great like Seinfeld and Breaking Bad did
Yup, heh. I actually only first saw it in the last few years, funnily enough.
And like Chappelle and the Muppets show...both ended while they were on top of the world
Fantastic Defunctland documentary series on Jim Henson and the Muppets Show, BTW https://www.youtube.com/watch?v=P5jJQ2IeDvE&list=PLplWWKocAfTYIGzH8eQ0x0kEQgoV9CpYm&index=3
(And of course, the obligatory https://www.youtube.com/watch?v=9yjZpBq1XBE)
Things like this are probably what subconsciously influenced/made me decide to write:
oh god that's both amazing and terrible 😅 ... 🙃
I find it quite rare to have to document an elaborate explanation of some code, but that is a great example of such a case
this bit of logic I kept doubting because folks kept asking how it worked so I had to extract it to its own function and write a comment explaining (to myself as well) https://github.com/DataDog/integrations-core/blob/9b711c127afce08e7ce5ee94b0deb7e8e12b0589/datadog_checks_base/datadog_checks/base/utils/common.py#L48-L76
Oooo. It reminds me of how 8% of 25 is tricky but 25% of 8 is not; and they're both the same.
In any case, that comment is out of date; coz Sphinx 4.4 fixed things.
@silk jungle pipe as Union is also available with from __future__ import annotations, so that isn't that bad
Yea I stay away from that future mostly because of the future of the future is not certain (i'm sorry)
What is even the situation between that PEP and the alternative? I haven't looked into it in a while.
what PEP? 🤔
if you have isort, adding/removing that import is quite simple and would take like 5-10min, so I don't think it's crucial to look that far into the _future_
https://peps.python.org/pep-0649/ (__co_annotations__)
https://peps.python.org/pep-0563/ (__annotations__)
In fact, seems like it would take way less than 5-10 minutes to change add to remove in the add_imports = from __future__ import annotations line in your .isort.cfg (plus re-running isort, in case you aren't already just using it via pre-commit like I am)...
yeah, I added time to make a commit, PR and merge it 😄
PEP 563, stringified annotations https://peps.python.org/pep-0563 (the current from __future_ import annotations) vs. PEP 649. deferred evaluation of annotations https://peps.python.org/pep-0649
Ah, ofc 😆
AFAIK It is not official yet, but it looks like PEP 649 will be accepted IIRC in favor of 563
which one?
- sorry
Ah here is the official annoucement; it was in the wrong category so I didn't find it initially https://discuss.python.org/t/pep-649-deferred-evaluation-of-annotations-tentatively-accepted/21331
It's not clear right now how the whole __future__ situation will be handled, but it seems likely the old __future__ import will stick around at least until the new annotations are availible on all supported Python releases. For now I'm just continuing to use from __future__ import annotations.
Oh wow. Reminds me to when I started to use Git. Several clones were hurt in the process 😂
(BTW, sorry for coming late to this conversation, but I've been really busy outside of the PyPA org)
Absolutely no reason to apologize! We can't make you or ask you to be always available, nevermind for some off-topic chit-chat. We're a loosely bound organisation anyway.
We aren't some corporate entity trying to mandate "team-building" activities :)
That's why I always try to come here, you are a nice community 🙂
Wait, what? The Python Packaging Authority isn't really an authority? 🤯
I wouldn’t object if someone wants to host some PyPA team building activities, they are fun to attend
Perhaps that pycon, but aren't summits basically a team building activity where we try to convince people outside of the packaging group that we know what we are doing 😅
Maybe not trust falls with rival build backend maintainers tho 😅
You worried I will let you fall?
Hahaha nah, but who knows? Maybe if I put too many annoying requirements in PEP 639 hehe (which I'm working on further simplifying the spec language of, BTW)
I understand the "Authority" thing in PyPA was intended to be a joke, right?
'cause we don't look too authoritative
As long as they were available for members around the world 😅
I'm not the authority on that, but AFAIK yeah it was supposed to be an in joke because it has no hard authority
Yup
But unsurprisingly, it can result in rather misleading expectations for anyone not "in" on the joke
IMO, it would be worth changing to "Association", but predictably no one could agree on it
Yeah... a while ago, if I remember correctly, there was a discussion about that
Yeah, on Discourse, and I'm pretty sure there were others
Oh yes, I think I even saved that Discourse thread
You know what they say about the two hardest problems in programming...
Just replace "cache invalidation" with "packaging"
At least these days
- Naming things
- Cache invalidation
- Off-by-one errors
Well, it kinda has
Huh, I always thought our two chief weapons problems are fear, surprise, and ruthless efficiency?
Er, I mean aren't our three chief weapons problems fear, surprise, ruthless efficiency and an almost fanatical devotion to the Pope?
I hereby pronounce you are the authority on the Authority of the Python Packaging Authority
But on what authority do you make that pronoucement? 😂
which joke name came first? PyPA, PyCQA or PyCA?
2011: PyPA. "Ministry of Installation" was also suggested 😄 https://gist.github.com/jezdez/6222d1ba8b10d734d003492e58041687
2014: PycQA, after PyPA and PyCQA https://mail.python.org/pipermail/code-quality/2014-September/000355.html
but it can be renamed before we add any repos to it since it can sound rather presumptuous to some (even though it's mostly in jest).
IIRC PyPA was first
I mean if you think virtual environments as some sort of on-disk cache for requirements file -> runtime imports (Poetry do store them in the cache directory!) packaging is basically a subset of caching
Seems like auditwheel, delocate, delvewheel all do the same thing for different platforms. It's a pain when cross compiling. Thinking about making one repairwheel that just mixes all three and works cross-platform.
"any wheel, anywhere"
I think the main problem is administrative, the three really aren’t that interested in other platforms. A wrapper project combining them and helps redirect issues to relevant parties (important) would be useful, sure
More than a wrapper, unfortunately. auditwheel for instance fails explicitly if sys.platform != 'linux', which makes sense given its scope. Its cross-platform gap is pretty small, though, and I will probably work around it with some monkey patching to start. And I think delvewheel is already platform-agnostic.
I have considered doing that but I lack time
after I get meson-python in a good state, I can see if work thinks it's a beneficial enough issue to work on
biggest gap I think is codesign on for delocate. But I think maybe ldid can replace it for delocate's purposes. It only ever does ad-hoc signing. https://github.com/tpoechtrager/ldid
Everything else in auditwheel + delocate can be handled by LIEF, I think, which ships wheels for multiple platforms
dependencies for this tool is't a big concern as it is intended to be ran on dev environments
true but no environment other than macos can have codesign
Hey guys having some issues with my private pypi server (devpi) on the server everything works great with the global index set to http://localhost:3141/root/zeuspi/+simple/ but on other machines I can't get pip to work. I have tried http://root:****@172.31.94.115:3141/root/zeuspi/+simple/ and http://172.31.94.115:3141/root/zeuspi/+simple/ but both fail with the error
ERROR: No matching distribution found for six```
The package install works fine on the server. For authentication it is default username of root with no password since the network is isolated. Not sure if this is something wrong I have on my devpi server or the client machine
Are you sure you've configured devpi to listen on some other interface than just localhost?
Check with e.g. lsof, or look at whatever the devpi default is
Also, check what pip install -vvv says
Also also, just because something's on a private network, doesn't mean it's safe to not have authentication
@junior narwhal https://discuss.python.org/t/how-hard-is-it-to-get-cpython-build-with-rust/22759/6?u=jelle was pretty funny 😄
Well, if someone doesn't know all core devs by name, it's an easy mistake to make (I understood it this way too, lol)
And Skip's technically a retired core dev, though FWIW his name is listed at the top of his post (which is why IMO signatures are rather redundant in this context to begin with). I read it as intended, but that's because I've interacted with Skip a fair amount so I was used to his signature, and also knew he wasn't someone who'd respond like that. Ironically, Skip was recently on the other end of such an unnecessarily dismissive exchange with another core developer on a PR of his, and (alongside myself and others involved) expressed disappointment that it was handled in that way.
FYI, Skip was one of the OG20: https://legacy.python.org/workshops/1994-11/attendees.pics.html
fully compressed gifs 🙂
What I wouldn't give to have all that hair back. Ponytail FTW!
aww you look so happy in that picture
Uncle Barry is always cheery ^_^
On one hand, it's weird to think that all happened a few months before I was born. On the other hand, it's weird to think in "just" the time I've been alive, Python (and you all) grew up from where it was then to the respected status of today.
I love the spam fill-in photo.
And the backstory too
Im wondering, is there any library that has as a target building semi-cacheable from a given set of requirements (like tox and hatch and pre-commit)
I need something similar for execnet remote bootstrapping and absolutely hate the idea of reinventing yet again
All I can say is that time flows quickly and life is precious. Spend every minute consciously and engaged. I guarantee that everyone in that picture knew Python was special but had no idea 30 years on that it would have the influence and reach it does today.
Wise words as always, and ones I will certainly keep close to mind. Thanks!
offshoot of @muted whale's post on the A in PyPA being a problem. Man it does not feel good to read the linked HN thread.
I'm not even one of the core PyPA members and yet seeing all of that frustration at once was not pleasant. I get it, there's a lot of things we need to improve, I guess it just feels like a hose.
Not to say they're being unreasonable, but yeah...
Pretty random I know, but I'm probably not the only one feeling this way from time to time.
The blog post itself had, surprisingly, some of the most extreme language, e.g. "The PyPA should be destroyed."
I haven't read that, and I probably shouldn't (right now at least).
I was gonna say HN is a nest of self-aggrandising negativity (which it usually is), but the replies honestly aren't that bad - it's mostly people coming out in favour of more centralisation or complaining about things that are mostly outside PyPA's control (e.g. venvs)
lol, just spotted https://iblueit.dev/ in blue's docs
what HN post is this
also it'd be great if we got to a point that what the A stood for is the most pressing problem in packaging 😛
Aren't we at that point now?
Strong disagree. The bad advice (even from official-ish sources!) is still a major problem.
Sorry for my misunderstanding, but what is HN, and what's the post we're talking about?
Ohh, I see
My mother always says: "when they criticize you, be respectful, take what's useful to improve and drop everything else"
@analog oyster TOML allows for non-data information, like comments and whitespace between data tables. most libraries, like tomli (called tomllib in stdlib) only read data and discard comments and whitespace. "full" library like tomlkit, while slower, do read whole file and preserve information about comments and whitespace
gotcha. interesting. makes sense. is tomllib the library that recently was absorbed by the standard lib? i feel like i remember reading about a pep about toml
yeah, tomllib is in stdlib since Python 3.11
nice. ok its clicking
but it only reads data
not comments/whitespace
it doesn't allow for data dump
btw thanks for explaining
tomllib was known (and still is) as tomli package. there is also "write" version, tomli_w
gotcha
this is interesting
I do wonder if this is just about types
maybe
i.e. keys in toml are strings so having ints as keys in a dict would be invalid input
not saying that this specific example would be problematic
but I just wonder if it's just about these sort of things
well, that would be easy to overcome, you can just "1" iirc (or just sanitize and raise exception before dumping). My guess would be some custom classes without __str__ or a way to dump to dict easily
>>> import tomli_w
>>> tomli_w.dumps({-123.0: "value"})
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/tmp/tomli_w_test/.venv/lib/python3.10/site-packages/tomli_w/_writer.py", line 39, in dumps
return "".join(gen_table_chunks(__obj, ctx, name=""))
File "/tmp/tomli_w_test/.venv/lib/python3.10/site-packages/tomli_w/_writer.py", line 73, in gen_table_chunks
yield f"{format_key_part(k)} = {format_literal(v, ctx)}\n"
File "/tmp/tomli_w_test/.venv/lib/python3.10/site-packages/tomli_w/_writer.py", line 152, in format_key_part
if part and BARE_KEY_CHARS.issuperset(part):
TypeError: 'float' object is not iterable
welp, that fails to serialize but still, maybe it's something else with types
floats are not suported as keys, but the error could be nicer
Yeah, I was playing with it to see when tomli-w could produce invalid TOML
I just came across this, in case anyone is using it https://github.com/python-versioneer/python-versioneer/pull/359
FYI I won't be available for questions tomorrow I'm taking that open source day off, I got the new covid booster today and it is wrecking me
Hope you feel better soon!
I wish you have a speedy recovery!
I've been sick for the past week, not pleasant.
Get well soon!
@nocturne swallow if you are around I can maybe avoid to open an issue in the tox issue tracker. 🙂 I have this in the config of a tox environment:
install_command =
python -m pip install --no-deps {opts} {packages}
In tox3 this leads to the behavior, that the package under test was installed, but neither its direct nor its transient dependencies. Since tox4 the direct dependencies are installed as well (but not its transient deps). According to the docs (https://tox.wiki/en/latest/config.html#install_command) the tox4 behavior is expected.
I wonder if the behavior in tox3 was never intended? Is there a way in tox4 to only install the package under test but not its dependencies?
the isort pre-commit hook is blowing up, ugh
I'm still mildly annoyed that pre-commit doesn't let Python hooks use wheels from PyPI. I understand the reasoning, but it would save me a lot of trouble.
the reasoning
what is the reason?
pre-commit will only ever operate with git repos
pre-commit is supposed to be language agnostic and I'd imagine the maintainers wouldn't approve of adding features that are very specific to a single language
Im pretty sure Anthony would love to have a good one, but that currently does not exist
how about doing it in a way that is language agnostic then
just allow .pre-commit-hooks.yaml (not .pre-commit-config.yaml) to specify cwd so that whatever command it runs to install the repo runs from that directory
The only tool that can roughly do that is nix, and that's not exactly something most want to use or can nicely ude
rather than the root of the repo
then you can have a subdirectory within the base repo where you create whatever you would previously create in a mirror repo
Well, it's easy to make a insecure exploitable mess that does what you describe, it's hard to do it secure
As for subfolders and other stuff, the tradeoff between having a maintainable tool and having bells and whistles is real
One gotta respect that Anthony errs on not having to maintain debts others would like him to pay for, features spike the rent
you won't know if he's open to it until you ask is all I'm saying
He's not open to it unless it's a implementation that won't shit his future self in the face, i tracked that stuff a while, its far from easy to get to the point where it would be ok, and i got better things to do than getting a halfway thing rejected
Might we worth telling the Poetry folks?
isort already fixed it fwiw
I'm currently trying to finish preparations for Black 23.1.0 which is due later today sooo I'm a little busy 😅
it's not really our fault, isort had malformed extra spec and we now validate it, so it started to blow up
Ah, fair!
It's gonna be "fun" when pip starts rejecting invalid versions in 3-6 months; depending on how the maintainers' time ends up...
well, not gonna lie, I will be happy to see PEP 517 builds default in pip, it will take sooo many issues from Poetry's repo.
Just to confirm, packages that don't have pyproject.toml will no longer build?
I thought they will but will default to isolated build
the ones that don't have [build-system] info (if I understand the whole picture correctly)
@hexed briar could you verify our assumptions?
I've lost track of all of the moving parts. I'm just asking because a transitive dep of requests doesn't have a pyproject.toml file yet !!!
No, they'll build with setuptools.build_meta.__legacy__
Right okay, so pip will still offer a fallback pyproject.toml.
Effectively, yes.
not providing a fallback seems like it would have been way too big a breakage
- pep 517 highly suggests having the fallback
I wanted to say it requires it but it doesn't say MUST anywhere as far as I can tell
From https://peps.python.org/pep-0517/#source-trees:
If the pyproject.toml file is absent, or the build-backend key is missing, the source tree is not using this specification, and tools should revert to the legacy behaviour of running setup.py (either directly, or by implicitly invoking the setuptools.build_meta:legacy backend).
I was hoping for "break things, make people take real action", but I understand why it has to work
It was always intended to be backwards compatible.
I was going to ask more questions, but I'm just making myself more confused :)
on the bright side, this should mean that adding pyproject.toml without build-system no longer changes how pip behaves
looks at flake8
go for it, lets untangle this mess 😄
"only 4 years late" -- every black user from a few years ago
not that he uses flake8 anymore now that ruff is a thing
Ruff now exists and is better
yep
that's what I was going to say XD
lol
Happy to answer questions about pip's plans for doing pyproject.toml-based builds by default, over on #pip. 😉
I would say ruff is 1-2 plugins away from being adopted in Poetry projects
which plugins
Yea, in my limited experience, if you mention something to Charlie, he'll have implemented it 4 hours later. 😅
ikr lol
flake8-use-fstrings - I have to verify if existing ruff rules are enough to drop this
flake8-typing-imports - ruff doesn't cover the rule 1 fully (already reported in ruff issue tracker)
you better buy new disk space for ruff on PyPI lol, with the amount of releases, it might be needed soon
Are they releasing daily?
yes
that's what I was reffering to 🤣
I dunno if the space limitation on pypi are really providing much value anymore tbh
well, I guess it's a good blocker for people not to flood PyPI with spam packages
in theory the idea was to keep the storage requirements from getting out of hand so that something like bandersnatch could work out of the box without like a large raid array behind it
Me neither; but I dunno what constraints PyPI is operating with. :)
if there would be an action to be taken, I think going with "verified"/unverified" projects, where "unverified" are limited in space and "verified" are unlimited, would be a safer option
So originally the file size was just a nginx limit that nginx had built in as a default
and when I implemented uploading on Warehouse I just copied that behavior
LOL
that's the per file size limit
mostly as a sanity check to make sure people weren't uloading like, pirated movies or something
Well, this might be a topic for discussion amongst the PyPI admins. 😉
then a bunch of ML packages started taking up like
all the space
and making bandersnatch mirrors run out of space
so we added the project limits to try and stop that
but I dunno, it feels like it's inherently in opposition to how the wheel spec works
maybe default limits make sense, but just have a boolean flag like @onyx spindle said that's just "hey we made sure this project is doing semi reasonable things" that opens it up
dunno
random thoughts (tm)
there is that $10k / month bill for storage that Google Cloud donates...
that's mostly bandwidth IIRC
4.64 TB of 13.8 TB is the top 100 projects today (based on https://pypi.org/stats/)
how many TB is Ruff? 😉
(top 100 of the largest packages, not top 100 of most downloaded)
yeah, just based on the same issue form as it is now. "I want to submit my project for verification to get access to unlimited space". I doubt this will be required by the amount of projects that would slam admins with requests
of cours like half of those is the same project uploading to different names for GPU nonsense
what's the current tensorflow's project limit lol
can a package maintainer check how much space their releases take up?
Yes, on manage page
oh is there?
There is!
i wonder if it makes sense to go back to index semantics for large files (like put al lthe large binary wheels into github release artifacts or something similar
it's been brought up before, I dunno
it doesnt' really solve the bandersnatch problem
which idk might be unsolvable without making bandersnatch just smarter by default to not mirror the world
links take less space than full files
And pip install's flakiness is now a sum total of pypi.org flakiness + whatever host flakiness
it's something we'd have to sit down and really think about and nobody's really had the time
true , its a can of cans of worms
there's also that discussion about release immutability
just for funsies, 100TB of GCP storage using their standard storage class is like 2700/mo
which is like 10x our current size
well 9x
whatever
many x's
7.2 but whatever
math is hard ok
there's a few different tensorflow packages, one has 200 GB, another 150 GB... https://github.com/pypi/support/issues?q=is%3Aissue+tensorflow+is%3Aclosed+label%3A"limit+request"+sort%3Acreated-desc
it's not like I'm sitting at a computer that can do it for me
but part of me is like "yo guys, machine learning models are not package data, don't use pypi as your backwater cdn
current size of tensorflow project is 266.4GB so it must be bigger
and CUDA is massive
Yea, it's GPU-specific binaries and whatnot.
they have t obundle CUDA for... I think Nvidia reasons
or they might be real reasons
- the wheel spec
which doesn't allow linking to external things anyways even if the nvidia/possibly real reasons were fixed
so much duplication 😅
side note: it's always funny for me when I see "CUDA" mentioned, cause in Polish, "CUDA" means "miracles", which is kinda what ML is all about lol
hmm, so those coudl possibly safe space by better dedup/split but stuf is a mess
I think a better wheel spec that's optimized for compression saves a signifcant amount of space too
but that's a whole extra can of worms
^ +++
let's wait another decade before we go and change the spec, ok? 🙏
my mind pronounces it like that but interprets it as CUDA not cuda at least
Ahahah
requests:
current: 57k
tar+xz: 44k
tar+zstd: 45k
pip:
current: 1.4M
tar+xz: 914k
tar:zstd: 960k
tensorflow:
current: 402M
tar+xz: 126M
tar+zstd: 141M
from like 2 or 3 years ago
calls in for earthworm jim with the can opener gun
oh that's not really tar though
sorry that's misleading
current: The existing wheel format current+bzip2: The existing wheel format, using ZIP_BZIP2 instead of ZIP_DEFLATED current+lzma: The existing wheel format, using ZIP_LZMA instead of ZIP_DEFLATED tar+gz: A new format that keeps using the existing format for .dist-info directories, but puts all the “data” into a tarball and compresses with gzip tar+bz2: The above new format, but using bz2 tar+lzma: The above new format, but using lzma tar+zstd: The above new format, but using zstd tar+brotli: The above new format, but using brotli
... why do you have that handy but not a calculator!?
my brain is good at remembering nonsense I've typed into the void at some point in time, not good at doing math okay
I don't know how often CUDA updates but even if it was as often as once per every tensorflow release and you were required to push the resource at least once to PyPI, that's still 4x less disk space used per release due to the dup requires by providing wheels for 4 different Python versions
OK, I can relate to that
quite ridiculous
if we ever do a new install format, can we please make sure dist info folders drop the version metadata from the dist info folder name
so I dunno, 30% file sizes for our largest packages seems like a good reason to do a new spec
at least to me
the real trick is just wrapping all of the data up until an inner zip file, that doesn't use compression, and storing that inside the wheel as data.compression.zip
or CUDA could be shipped as separate package and not be bundled within a release (might be totally stupid idea, never looked into it)
that's where most of your savings come from
+++
lol yeah
output/current: 402M
output/current+bzip2: 314M
output/current+lzma: 136M
output/tar+brotli: 148M
output/tar+bz2: 309M
output/tar+gz: 396M
output/tar+xz: 126M
output/tar+zstd: 122M
tensorflow
You need to link against it -- there is some efforts toward that.
interesting that not changing the format, but using lzma does so much better
hmm, im totally ofr lzma wheels
I think that's mostly because tensorflow's fiel size is a single massive .so
well, I guess someone smart would find a way to do it right. they just don't have to because the way it is today, works
so the fact zip compression is per file doesn't really matter
well doesn't matter much
lzma isn't in the stdlib, is it?
Oh, then we have an option...
it's "optional", so if your python wasn't compiled with support for it then you won't have it
but the same is true for zlib
just zlib is more universal
the problem with lzma is mostly that it's kind of slow and can be memory intensive
Isn't zlib accepted under manylinux?
I can imagine this could be problematic
so installing from wheels currently relies on the optional zlib stdlib support being enabled
if we did lzma wheels it would instead rely on the optional lzma stdlib support being enabled
the only real difference is it's basically illegal to have a computer without at least 17 copies of zlib
Or... useless. :P
lzma has some downsides
abstract question: what would it take to make this "mandatory"? I mean, I can smell issues every time I hear that something is going to be based on something optional
I think it's slower, and more memory intensive
zstd is much better in that regards
but isn't in the stdlib
I mean, "you can't install wheels without it" more or less makes it defacto mandatory for the bulk of the ecosystem
the same way zlib is defacto mandatory now, it's just technically optional
While dreaming about plans to standardize sdists, I have been thinking about how sdists are strongly tied to gzipped tarballs and wheels to zip files (although obviously more wheels than sdists). I view this as unfortunate as it means neither build artifacts could take advantage of e.g. zstd for compression and speed benefits. I noticed that co...
the whole discussion 🙂
you know that TI-84 calculator with Python? Maybe it doesn't need zlib 😄
though that one might not be Python up to its spec, Idk
but there's probably someone out there!
[insert relevant xkcd]
since lzma is basicially more than 20 years old, it seems like its ok to require it
IME you only end up with a python without zlib by mistake because you're custom compiling and forgot to install zlib headers
PTSDs to issues with Debian distutils hacks
hmm, maybe a pep is needed for mandatory zlib/lzma
I don't think we really need lzma to be mandatory for Python to make it mandatory for wheels
like there are use cases for Python that don't require installing things from wheels
and there's not a lot of reason to put undue burden on them
there would maybe be a bit of a transitionary period where common distributors have to make sure their Python has lzma support by default
but I think that's fine
it would be cool to try and get zstd into the stdlib, but I have like no motivation to actually do that, but I think if we did most of the arguments for lzma go away and zstd is the clear winner
how long until 3.12 would be the minimal version?
well you also don't need it in every version of python you support
you can just say that new style wheels are only supported on python X
3.12 or whatever
presumably old style wheels would be supported near forever anyways
it's nice of course if you can just support every version right away 🙂
which is a definite point in lzma's favor
I suspect most packages wouldn't want to switch to a new style wheel right away anyways, until support in the packaging tools was "old enough"
Or, hear me out, lets double the amount of wheels a project has to make! F*ck storage ||/jk||
is lzma supportable offthe bat ? ifit works for the intensive ones, then lets give it a go
um
I'm not sure
I think regardless it might require tooling changes to support LZMA wheels
certainly if we want to do the inner compressed data.zip.xz it would
If we want to just allow wheels to use LZMA compression, which would help for wheels like tensorflow... I'm not actually sure if tools would support that natively right now or not
I think pip etc might if they're using the built in zipfile module and Python has lzma support
obviously the build tools that build the wheels would need to grow support for it, but that's a shorter thing than consumers
If it's just changing the compression lib, it shouldn't be a big problem
this is pip FWIW
output/current: 1.4M
output/current+bzip2: 1.3M
output/current+deflate: 1.4M
output/current+lzma: 1.3M
output/tar+brotli: 910K
output/tar+bz2: 1.0M
output/tar+gz: 1.2M
output/tar+xz: 914K
output/tar+zstd: 959K
so just swapping compression to LZMA doesn't really help much, but doesn't hurt either
I guess the change might be more significant in bigger packages
yea this is tensorflow
output/current: 402M
output/current+bzip2: 314M
output/current+lzma: 136M
output/tar+brotli: 148M
output/tar+bz2: 309M
output/tar+gz: 396M
output/tar+xz: 126M
output/tar+zstd: 122M
that mostly gets big savings because the bulk of tensorflow's size comes from a single large file
I haven't done extensive research to know if the big packages are big because of a single file
or because of lots of files
that would be an interesting thing to figure out though
As it happens, here's a proposal to make zlib mandatory https://discuss.python.org/t/lets-make-zlib-required-rather-than-optional-to-build-cpython/23062?u=hugovk. No PEP in sight
Black 23.1.0 is now available!
https://ichard26.github.io/blog/2023/01/black-23.1.0/ https://github.com/psf/black/releases/tag/23.1.0
Black 23.1.0 introduces an updated stable style, improved inference of the default target version(s), and other QOL improvements.
The link to alpha is not working
I should run a linkchecker on the post 😅 Gimme a second.
what the hell was I thinking?
https://ichard26.github.io/blog/2022/12/black-23.1a1/ it's fixed now, thank you for letting me know!
(this is partially why I make my first announcements for a new release here, it's low pressure compared to everywhere else :P)
Cool
The target version inference looks useful! https://ichard26.github.io/blog/2023/01/black-23.1.0/#better-default-for---target-version-if-pep-621-python-requires-is-available
but what about us poor Poetry users 😛
Poetry is actively working on enabling pep 621 metadata spec
@silk jungle seems somehow the newer black does not recognizes trailing commas in literals 🤔
when there's a single element
nm 🙂
actually is https://github.com/psf/black/issues/3542
This is as intended. See https://ichard26.github.io/blog/2022/12/black-23.1a1/#ignore-magic-trailing-comma-for-single-element-subscripts. Also: https://github.com/psf/black/issues/2918
Also minor correction, this only applies to single item subscripts, not lists. That would indeed be a big problem.
But still a regression no?
I mean we use this for generating easy to diff literals that start with one element but will grow
I guess black doesn't know if is tuple or Literal so can't handle it differently no?
Because I agree for tuples makes sense but not sure if it does for Literals 😅
Well it's probably possible but that's kinda ugly
metaphorically / from a purity standpoint, not a style standpoint 😅
🤔 well let me know how strong you feel
Because for now we pinned as it breaks one of our projects, but if this is how it's going to be going ahead, we'll just have to live with it 😅
You can say it’s technically a regression, but Black changes its formatting rules quite often so it makes sense it’s not a bug
Well I meant more like I don't think this should happen for Literals while I agree makes sense kinda for tuples 😅
Not that I agree with the change, just that it makes sense from Black’s perspective
We're trying to do better. We have a stability policy which means we don't make changes to the stable (default) style more often than yearly.
Called me old school, I like my formatter black 😅
I like it's zero configuration style, while ruff has a lot of knobs for my taste for now 😅 so didn't adopted it anywhere yet...
Tbf, nobody would probably use linters as comprehensive as ruff without a way to disable rules 😄
But it could use with more rules in the out-of-the-box experience which is planned through categorization and stuff I think
Similar to how isort has profiles would be nice
Personally I would prefer less configuration, profile feels like a step backward after we have black
Linters are all about all kinds of conventions. But the auto-formatting stuff in ruff is opinionated towards Black
People also said formatters are about all kinds of conventions (oldies probably still remember yapf?), until Black took over.
It would force Ruff to either limit scope of its rules significantly to be of use to anyone or be a dead tool that nobody wants to use because it's way too strict with all of the rules it keeps on adding
sane defaults imo are enough for a linter; it allows them to be widely used by people who either don't want to bother with configuration or are less experience with Python and are looking for a tool that nudges them in the right direction while appeasing a very big audience of projects with different requirements
It’s the tool’s choice I guess. Black is Black because Lukasz doesn’t care if people want to use it and effectively it’s his way or the highway, and people (surprisingly?) bought it
But I understand not every tool wants to be like that
I treat formatters as different kind than linters (though the latter can nudge you about what the former automatically fixes)
a certain level of opinionated is important else a tool adds fog instead of value, a key feature of black is that you cant do whatever you want and that creates synergy for everyone, every time one starts to give everyone all the bells and whistles one gets excess diversity - which when it comes to adding cognitive load on how to format is a problem - i prefer people figure more important things than where exactly to put a comma ^^
FWIW I consider myself close to an autoformatter purist 😅
I think it's natural for people to someone start on a new autoformatter, and see it as an opportunity to do something very different from Black (e.g. something highly configurable), but I don't really want to go in that direction
I do plan to make indentation and quote style configurable which is perhaps controversial
its against the zen of python ^^ there should be preferably one way to do things
so configruable formatters 🫰
We need to go back and remove tabs from the grammar... it's the only way
or maybe... remove spaces from the grammar
quote style would be very nice
how about... just remove spaces from supported indentation, not all spaces
Come on... unnecessary! 🙂
although removing support for all spaces would certainly limit your choices with available formatting
😄
actually, from disk space and accessibility point of view tabs > spaces
in general I agree with that principle but in this case I view it differently: I think Ruff should keep adding rules based on user demands and a wrapper like Hatch would have a default rule set
oh hell no, single quote strings are confusing when you use languages other than python
Instead of arguing tab vs space people should all use U+3000 Ideographic space for indentation. Fixes all the problems.
We'll also be enforcing CR line endings sadly
blasphemy
from __future__ import braces
CRLF is obviously the only correct way, you need to go down one line (line feed) and return to the beginning of the line (carriage return)
So that your code only runs on Commodore and very old macOS versions
Na we're doing CR! Not even CRLF
😄
ideal case would be programming languages go away from text based syntax and use a serialized ast, that only allows syntactically correct programs to be saved, then rendering them however way user wants to see them
but until then, hell no to bells and wistles, everyone gets the same format so that one doesn't have to switch format style familiarity between projects
with AI now English is the best programming language
would such ast contain info about empty lines between lines within a block
that as a concept is nonsensical
because that's not what AST typically has while preserving some of the empty lines is crucial part of auto-formatter
one wold certainly need a syntax concept for ligical groups
yes, I don't mean empty lines specifically
but thats not empty lines, its a contextual group
but info that would allow you to differ
those would need ast nodes
syntax concept for ligical groups
As in… braces? shudder
doesn't have to be braces, can be dedicated keywords for start and end of section
like in pascal, bash, or whatever
@boreal bramble first error, a grup is a collection, nto a start/end marker
we are talking about a ast here, not tokens
I meant from how you would type this
not from how it would be stored in the actual file
one would not type this
one would select a number of statements, then tell the editor to put them in a group

The point being most languages do have an ast node for contextual groups (some of them e.g. C merge the concept with variable scope but the two are conceptually different, JavaScript aimed to separate those but it implemented the separation too awfully for it to be accepted)
no progamming language has a concept for a "functional group" of statements as in a text file one would just use white-space, and it wouldn't even appear in the ast
I’d argue it’s the other way around, most programming language designers never bother to introduce statement grouping to ast because people like to just use whitespace
thats a strawman, - if the ast comes from lossy parsing of a text format, then making use of properties of the text format by accident is the starting point
if one cannot use that as a starting point, then naturally one must express something that was simply hidden by layering explicitly
it does seem to imply certain strictness on what you actually type so that it ends up represented in a file properly so that other's people editors show it properly too
yeah, no more wsgiref in the stdlib having randomly 20 lines of space becasue the implementor used a strange editor and nobody fixed it
alltho i never checked if they fixed it after the initial addition
This discussion makes me think though, the entire premise is people want to have a syntax-free ast and be free to choose whatever frontend to use. But if history can offer a hint (you know, this is a packaging Discord), if you actually try to do that, people would beg whatever Authority to officially bless one of the frontends and we’re back to where we are in reality
i recommend the cobol lookalike as official frontend for the python in ast language
another problem, how do you represent strings in AST to account for the fact that you can't fully automatically wrap long arbitrary text and still have it look good no matter what text it actually is. How do you do this abstractly to not include opinionated formatting into the format while still representing some additional information about what that text is so that it can be displayed appropriately by the editor
tpe annotations as prose from an mba wil lave a never to forget taste
long docstrigns can just be embedded restructuredtext files (potentially also speudo ast)
as for long text, give some examples
embedded restructuredtext files
Not afraid to make enemies I see!
I'll be at FOSDEM, if anyone is also there and wants to meet just lmk
without enemies, who to play klingon with
I want it on record that I appreciate @vast wren's GIFs!
Also, today's the first time I've actively gone ahead and told discuss.python.org to not show me a person's posts!
Sigma move
(you can too, if you go a users' profile -- it's near the top right corner)
yeah it's certainly a balancing act, I think this year I'm also going to associate less with people that are not at least moderately optimistic/encouraging
For me, I think this is a case of saying "this person will never say something useful for me" -- or, at least, that the benefit of even reading things they'd write is less than 0 overall.
Besides, there's a marker that I can click on to show it still; in the right spot.
something I learned over the past few years that makes me genuinely bummed out is that, contrary to my pretty hard-core stance on open discourse/dialogue, some people really have nothing useful to contribute or can in fact negatively impact a discussion with relative ease
nods.
The corollary that I've tried to remember, but am maybe not very good at yet, is that not every comment demands a reply
Huh. Packaging can't be uninstalled from the system Python on docker alpine. https://github.com/psf/black/issues/3544 Is this worth flagging to the maintainers?
yeah I don't think it's worth it, as far as I know the standard practice is to still use virtual environments in containers
To add to that
apt-listchanges: News
---------------------
python-pip (23.0+dfsg-1) unstable; urgency=medium
This version of pip introduces PEP 668 support. Debian's python3.11
interpreter will soon (>= 3.11.1-3) declare the installation to be
EXTERNALLY-MANAGED, instructing pip to disallow package installation outside
virtualenvs.
See: https://peps.python.org/pep-0668/
Practically, this means that you can't use pip to install packages outside a
virtualenv, on a Debian system, any more.
See /usr/share/doc/python3.11/README.venv for more details.
If that isn't available yet, check:
https://salsa.debian.org/cpython-team/python3/-/blob/master/debian/README.venv
-- Stefano Rivera <stefanor@debian.org> Wed, 01 Feb 2023 19:14:08 -0400
oh, nice!
Huh, I always felt resistance to that. I still view containers as one unified environment containing everything needed to run something with no extra complexity.
I feel like for containers, all separation that’s needed is that the system package manager manages things in /usr/, while programming language package managers install to /usr/local/
Which maintainers? :P
FOSDEM
@onyx spindle re:German I think there’s a difference between the “German sounds aggressive” meme (which really is just about an abundance of hard consonants in the language) and what @frank path and me were talking about. And I think you’re completely correct about it @frank path: I think people growing up in the US get taught to add more “politeness phrases” to everything, and paragraphs missing them are interpreted as blunt.
The American “Hihowareyou” isn’t a statement in German, it’s a question to which you expect an answer: From strangers usually a “Great, Good, OK, or ‘could be better’” without expanding on it, from friends anything from one word to a therapy session.
And there’s non-verbal components too: Russians think you want something when you smile at them, Germans rarely smile in everyday interactions (but when they do you know they’re just happy), and Americans smile when they feel any emotion other than miserable.
(I’m talking about Americans because I have most experience with them, but to a degree, I think most cultures are more like the American than the German one)
Americans smile when they feel any emotion other than miserable
ouch, true lol
Don’t even get me started on Japanese smiles 😆
Mm, so...do you think it's more cultural (or maybe stylistic) than grammatical?
It’s 100% cultural, but that doesn’t mean the way it expresses itself isn’t also 100% through grammar. I said “politeness phrases” but it could just as well be exactly what you said and be all through sentence structure or so.
An alternative to harsh german is also viennese german 😉 , which can have the same chanson cadence as french when a particular heavy version of it is used.
The „how are you“ can also be quite aggravating for austrians or viennese, as we know they dont really care for an answer and that is insincere for us.
We would only ask how are you, when we actually want to know and this mostly is done to people that are close. So the question can insinuate a closeness that we dont see.
This can even be a problem between austrians and germans (divided by a common language). Germans often use „Hallo“ as greeting to everyone, in austria it is only used if you also are close enough to use „Du“ or if you are a child, as in close enough to not use courtesy variants. Entering a shop and getting greated with „hallo“ can be quite off putting for an austrian. (Not always and less so in younger generations).
PS: That whole thing is why I am a fan of pre-defined "tags" in stuff like code review. It takes the cultural part out of the conversation and is from what I heard also a boon for people with ASD (but no real experience).
what I mean is something like <opinion> I would do this via a list and not a custom object </opinion> (example)
where opinion is predefined as:
This is how I would do it, but this is not meant as critic or requirement.
Does not mean, the current code is bad or so.
Then people can decide to use the tags to have the intent explicitly defined.
I know it gets close to handling conversations like it is a programming language, but I just have seen to many conflicts from misunderstandings where one party assumes the intent behind a comment and becomes defensive and vice versa.
oooh, I love this type of inclusion. while I am not diagnosed in any way, I find it difficult to communicate with people and this is just great solution
@junior narwhal that blog post on cli in rust is quite lovely, but i do wonder if there could be an equivalent of typedsettings for it
In this post I’ll walk through the setup of an example project to show how to build a modern CLI in Rust.
I miss those macros pulling values from Cargo.toml into the CLI, I hope Python could have something similar. Those things you can only get when there’s a compilation step.
examples ?
let's wait and see what mypyc evolves into, since it's basically Python compiler
https://docs.rs/clap/2.33.3/clap/macro.crate_version.html
The example code would render the help message as something like app 1.0 with the version part automatically sync-ed from Cargo.toml, so when you bump the version in Cargo.toml the final build automatically contains the same version. Also macros to pull in name, author, etc.
API documentation for the Rust crate_version macro in crate clap.
There's no reason you can't do this in Python
we have a compilation step if you're packaging up your software
it's just typically the compilation step is "copy these files"
setuptools_scm + the package metadata does that easily
There’s no reason you can’t technically, but Python has a user problem. Once you rely on the packaging step someone’s going to complain the code doesn’t work when they clone and run directly.
it just working for basically anything in cargo.toml without needing to figure out much is really nice though 🙂
I blame the interpreter being too easy to run, everyone and their pets use Cargo not just because Cargo is nice, but also compiling Rust code without Cargo is horrible.
pythonhas all the metadata avaliable, so i sdone see a issue
I suspect if we made the default tool expect something like a cargo run, we'd end up in a state where most people expect to do that too tbh
Yes
thanks!
time for Python packaging macros?
I still prefer dynamic = ['version', ...]
my dream would be that editable installs recompute metadata automatically
Pulling metadata from code imposes restrictions to the code base. Existing tools either performs static analysis to the code base (restricts the syntax) or actually imports code (restricts module layout and more). It’s possible to work around but IMO objectively worse. With pulling metadata into code not being possible, I’d personally prefer to rely on tools like pre-commit to automatically keep the different version declarations in sync.
But I understand people prefer workarounds than being theoretically superior (which is a good thing, please don’t be like me). Editable install is another one of those things I personally think don’t need to exist to begin with, since you still miss auto metadata computation, but if you implement that, you can rebuild the entire project and can use regular installs anyway…?
FWIW, you can do that today.
https://github.com/mesonbuild/meson-python/ has editable installs that recompile your module on the first import with sys.executable.
Meson PEP 517 Python build backend. Contribute to mesonbuild/meson-python development by creating an account on GitHub.
it's not sys.executable, that'd make things more complicated
it's sys.ececutable from the PEP 517 hooks
also, editable installs only in the pre-release
they work but debugging via code editors is broken, because we do not actually use the path they try to set breakpoints on 🤣
In find it intriguing an Indian native living in the UK is using a baseball reference! https://discuss.python.org/t/23442/6
If former Hubbers are starting to announce it I feel fine breaking the news.
GitHub is laying off 10% of their employees between today and FY23 (I assume this means by July 1st).
They are moving to remote-only and not renewing office leases.
Remote-only, huh
Nice
AI and hands (and teeth), name a better nightmare fuel couple!
hmm, still better artist than me ^^
We enabled it on warehouse today
It seems to work pretty nicely
Don’t have a ton of experience with it yet though
we're considering enabling it for CPython: https://discuss.python.org/t/enabling-github-merge-queue/23736?u=hugovk
Im on my phone but as far as in know it’s a different event then pull requests
So you could run buildbots on the merge queue safely
And get pre-merge protections from the buildbot fleet
this makes perfect sense, but I never realized it https://textual.textualize.io/blog/2023/02/11/the-heisenbug-lurking-in-your-async-code/
and now an intermittent bug I've been trying to investigate is fixed... 😅
TIL Heisenbug
So, it points to task group as a fix, bug from the way I see it, tasks without a reference are often used for fire and forget tasks. With those the TaskGroup is not really a solution unless you wrap your whole programm in a TaskGroup.
I feel there is a need for a thing that wnables fire and forget. Of the top of my head just a container that keeps referencen and on adding new tasks, it checks all stored for completion and just removes those, but this would be a problem because it will stay constant if you never add one again.
Maybe just check if completed from time to time,… and we are again at fire and forget tasks 🙂
(The implementation example is somewhat of a straw man, I know and the usage of those tasks could be a huge discussion about code design and anti patterns)
The create_task interface never really makes sense to me, I’ve always wanted something like asyncio.queue(coro) that I can just send something to the loop to run
asyncio has the major blunder of starting out without a async syntax, now it carries the callback hell plus the low hanging good ansyc api fruits
trio did so much right there
asyncio had yield from which I think is enough to invent trio, albeit not quite as nice version of trio without async with statements and the such.
It’s just before trio callbacks and unstructured async was state of the art
@vast wren async iteration and async contextmanager are a must have for composable bits,
@vast wren without the patterns that enable easy and fun apis, one descends into the madness part too easy
like context managers are largely just sugar over:
yield from ctx.__enter__()
try:
...
finally:
yield from ctx.__exit__()
that's still better than callbacks
having the syntax that allows makes it usable,
like it's not like callbacks have a better answer to that problem
@vast wren but that goes from knowing the new api towards how the abomination would look if the new style as not possible
nobody in their right mind would write a networkign famework where the users of the lib would have to do manual yield from context managers (fearfully looks into the direction of dabez)
I mean, that's what the callback API required
Well, the callback api was so terrible it made me like twisted
Twisted deferred and protocol concepts Brough a number of things well together
That’s Rusts’s BORS, integrated into upstream. Very nice!
@onyx spindle you really nerd sniped me on GHstats 😅. I didn't like how the front-end was made by manually copying and pasting HTML and JS. Added jinja2 templating so it can be handled automatically too.
it gets even fancier lol
Nice
So, it asks the questions and generates website or is it just for data download?
so setup + add-repository handle the GHstats configuration, and then generate-html generates the web directory which will be used during deployment
the issue data was already handled by pre-existing scripts and CI
add-repository will invoke the generate-html command after it's done running
Nice
@onyx spindle alright instructions are up, you can try setting up your own instance: https://github.com/ichard26/ghstats
Let me know if anything goes wrong :)
FYI the setup command doesn't handle any optional configuration, only the bare minimum. The configuration I'm using contains some optional features. In particular, the author object configures the content in the footer.
Hmm, I keep forgetting that DMs are a thing. I basically never use them. Probably should change that though 😅
looks good!
I tried in on python-pillow/Pillow, then started a local web server with python -m http.server --directory web , but at http://[::]:8000/Pillow/ the charts don't load and the console says:
Uncaught TypeError: Failed to resolve module specifier "luxon". Relative references must start with either "/", "./", or "../".
https://github.com/zloirock/core-js/blob/master/docs/2023-02-14-so-whats-next.md a sad piece on what is wrong with open source
Open source Was never designed to ensure work is paid fairly, freedom of the users, not sustenance of the developers
It was always about the freedom to use, never about the freedom to get good money for good work
If opensource enabled sustenance in any meaningful way I'd probably be working as full-time pytest maintainer and trainer while trying to upstream key bits to cpython
But I wouldn't be able to contribute to the sustenance of my family then
"Maybe we made the world wrong"
https://shopdinosaur.com/collections/maybe-we-made-the-world-wrong/products/maybe-we-made-the-world-wrong-1 if you want that on a cup.
Not drop-proof.
Shocking
the vibranium cups where not well received, unfathomable cost and breaking any flooring if you drop them ^^
Yeah, it's not meant to be directly served using http.server.
It's built using Vite. The deployment + the issue data is handled by a GHA workflow which deploys to a production branch. It's a stupid design I'll admit but I've spent way too much time into it already to be bothered to clean it up anymore...
fair enough! looks good though 🙂
It would probably make more sense to generate the web assets at build/deployment time and hide it all away from the end user (ie. handle it the same way the issue data is). That makes tweaking on the front-end harder though as vite devwouldn't be usable any longer.
wow
Would be nice if that turned out to be a success
I don't see how a library can make any money vs something like docker or elasticsearch which can be offered as a PaaS
According to the article they are indeed offering PaaS. No idea how that would work.
“We’re building cloud services, and we’ll have a generous free tier and usage-based pricing after that,” Colvin continued.
I'm not really surprised to see a maintainer of a popular library to take that popularity and convince a VC that it's somehow something that they can build into a platform. ⛄
this is actually really nice situation compared to what was happening with core-js drama
and I guess Samuel had a good pitch for investors to give him the money. I doubt anyone would invest in something that wasn't going to be a success
at least potentially
I don't really care if they make a usable PaaS, I'm 90% sure that Sequia and friends won't care if this is one of the dud startups that just breaks even or even makes a loss forever, and if it means Samuel gets to work on making pydantic better in the open (like we have with Textual + Rich), all is good. As long as these folks don't turn evil or have like something bad happen to them circa VCs wanting an ROI.
well, I guess that last part is for lawyers to figure out in contracts
Yea, exactly. And, I'd hope these folks are smart enough to run this by lawyers and reduce any personal liability if things go poorly.
I doubt anyone would invest in something that wasn't going to be a success
at least potentially
heh
I just learned on the pip tracker that chatgpt actually reads the suggestions we make in our deprecation messages. There is hope. 😆 https://github.com/pypa/pip/issues/11813
I’m not sure if I should be happy that computers can read error messages intended for humans, or sad by the fact that aspiring programmers read errors worse than a computer.
Maybe both? 🙃
there always have been people that read errors worse than computers, now if all of those sad people ask chatbots instead f wasting maintainer time, its a net win
Oh wow, that's hilarious.
@ionic tulip I saw https://twitter.com/ossronny/status/1630491958962450438
Im starting to consider #python #ruff an antipattern , whenever I see it added somewhere there is loads of custom settings and noise
The key win of the other tools was converge in style, now we get a speedrun to divergence, disheartening
soon Hatch will take care of this
in the coming releases I will add commands that other package managers like Cargo have, in this case a top-level command for formatting which will manage an isolated virtual environment populated with Ruff and Black and will have predefined "good" config that will be used in lieu of user config
when that happens Hatch will rely on that forever and put nothing in pyproject.toml except for maybe an override or 2
@vernal hornet does Ruff merge configuration from multiple sources?
Sort of. We support picking up different pyproject.toml files within a single ruff invocation. So for each Python file, we find the nearest pyproject.toml ancestor in its path, and use that to determine the settings for that file (which is important for monorepos).
(Happy to help with this and support your work here of course.)
I've been thinking a lot about this... I was hoping to better understand the critique. Most Ruff migrations tend to be 1:1 ports from [Flake8 + plugins + isort + some pre-commit hooks] to Ruff, so the end state is often “the same”. Increased divergence or customization isn’t an intended goal, so if that's being felt, I'd love to hear more. But OP is under no obligation to engage, all good regardless.
I happy to elaborate
I don’t agree with the criticism but I think it’d be nice to have recommended presets a la eslint. I think that’s already been suggested
having recommended presents that build on top of each other and promote convergence would be absolutely fantastic - from what i understand right now that would completely elevate the "issues" i take right now
just foud the libseccomp maintainer is also called Paul Moore 🤣
Thanks, this is really helpful to hear! (I also replied on Twitter)
As good a time as any for this I guess
Maybe a little input from a place that may be underepresented here. Single maintainer/programmer (I mean, on my projects I 99% work alone on everything)
Customization is really nice and one of the big reasons, I do not use black.
Generally, why should I use something that makes things harder for me to understand my own code after some time (formatter) or that makes me ignore warnings/errors in general (linter). Normally there is the huge benefit of helping to work together with others, but my projects and probably most python projects are single maintainer with no real possibility of having more maintainer in the future.
I would argue that the amount of stuff done with python, that have more than a single person working or looking at it, is probably less than single digit percent.
(Sorry for run on sentences, it was rather hard for me to formulate it differently)
key reason is use black is that it streamlines contribution - it completely anhillates and discussion about code style - for example for projects at the size of pytest tis a huge win
another key win of the lack of configuration is that every single project using black will have the same style, so no more getting used to the styles
for me those points are massive wins in terms of cohesion and project mobility, they enable and support broad collaboration
i add them to all of my projects, even the small ones, as its excellent for setting up contributor expectations
I am all for a default config, but please do not take away options for people like me.
A lot of pip (see packaging discussion) and libraries already seems to cater to the minority that write big projects with many people, this would just increase that.
Side-point to this discussion:
Is the formatting done on commit? ala commit hook?
There were many times, where I wanted to contribute somewhere, but even setting up the no-config-env was a pain. Like setting up black, setting the project level vscode options to use it. Then setting up tox, no nox, no it is tox again, no just plain pytest,... made me not contribute before even trying.
I agree with Ronny's points, but if you don't like Black/autoformatters, that's fine, there's absolutely no requirement to add it to your projects
yes, often formatting is done via pre-commit. the popular "pre-commit" tool can also be run on the CI to check pushes made without pre-commit. and the pre-commit.ci service can automatically update PRs
different projects will set things up differently for their own needs
I was posting my block of text as preempt for ruff going down the black route, with less configuration in favor of standardized config.
ah right
I guess Ruff will be either be configurable to disable autoformatting, or it will be disabled and you need to configure to enable
auto formatters are great, no configuration options are great
one of the main things I even like about go is that go fmt is just more or less mandatory for everyone
Consistent format across community makes it easier for people to get into the project
I do hope nobody here has had the misfortune of having to deal with historical tz offsets (local mean times)
>>> datetime(1921, 9, 1, tzinfo=ZoneInfo('Asia/Nicosia')).isoformat()
'1921-09-01T00:00:00+02:13:28'
that's right, 2h 13m and 28s
thanks, I guess
yeah, paul gansle would have something to say about that probably 🤣
I've also been playing around Bing's AI, it's cool until it starts stating inaccuracies 🙄
But it's accurate most of the time 🙂
Oops?
REST is a style. There is no spec.
How does the above breaks any http spec?
you can have a body in an http get request
but you aren't supposed to
it is annoying for some badly implemented caches but those implementations are wrong
Isn’t the above the response’s body though? Ah I misunderstood, it is the request body
are you facing any real problem regarding this?
in this case I'm getting a 413 when I try to provide the body above
which is payload too large
payload is simply {"post_ids[]": 430} and I've also tried it without the []
can you provide the full request/response raw text?
GET https://discuss.python.org/t/963/posts.json HTTP/1.1
{"post_ids[]": 20}
HTTP/1.1 413 Payload Too Large
wow
I “reverse engineered” it https://meta.discourse.org/t/reverse-engineer-the-discourse-api/20576
(They try to make it sound cool but it’s basically opening the dev tool and go through the network tab…)
Discourse is backed by a complete JSON api. Anything you can do on the site you can also do using the JSON api. Many of the endpoints are properly documented in the discourse_api gem, however some endpoints lack documentation. To determine how to do something with the JSON API here are some steps you can follow. Example: recategorize a topic...
thanks for the help, but in the end it turns out that endpoint isn't even what I'm looking for, lol
FWIW I’m not even sure DIscourse itself uses that endpoint. From what I can tell its frontend only uses /t/{id}.json
yeah :(
I'm trying to turn eg https://discuss.python.org/t/pep-582-python-local-packages-directory/963/40 into the post it links to
which is on topic 963 as the 40th comment/reply/post/something
oh.
its the stream field
yay
I actually quite like how basically all of discourse is available as HTTP requests to get JSON blurbs.

I just hope this doesn't occur to me 
Oops.....
it's an out of date ruff schema on SchemaStore
Hello all, I've been working on Customs-Inspector, a poetry plugin that hooks into poetry update process and calculates the diff between package updates and asks you to audit the changes before continuing with the update. The goal is to eventually build something like https://mozilla.github.io/cargo-vet/ for federated auditing of packages. Here's the discussion I created: https://github.com/python-poetry/poetry/discussions/7715 . I would love to hear your thoughts as this is probably going to be my Bachelor's Thesis.
Customs inspector
This is a confusing thing where we want people to use C9 and C4 instead of C, because C9 and C4 map to different linters within Ruff ("comprehensions" and "complexity"), and each parent category is meant to map to one linter.
We special-case C in the code such that if you provide it, we expand it to C4 and C9 internally. It's probably worth marking them as acceptable in the JSON schema since this is clearly confusing.
@upper hill
1❯ ssh -T git@github.com
Hi ichard26! You've successfully authenticated, but GitHub does not provide shell access.
I'm using SSH now!
I'm waiting for my SSH public key to be deployed on the GCC Compile Farm machines so I can ssh into them. In meanwhile, I thought I'd try GitHub.
what algorithm did you use?
rsa
:(
❯ ssh ichard26@gcc13.fsffrance.org
ichard26@gcc13.fsffrance.org: Permission denied (publickey).
seems like this may take a few business days (unless I uploaded the wrong key)
rsa has been considered insecure for a while iirc
just for SSH keys or even GPG keys?
RSA isn’t insecure
Ecdsa / ed2559 is faster and let’s you get an equivalent amount of security with a smaller key
Elite now 😮
But yeah, use ed2559 these days in future 🙂
As Donald says
❯ ssh ichard26@gcc104.fsffrance.org
Last login: Sun Apr 9 13:57:19 2023 from <ip>
__ __ _ _ __ __ _
| \/ | __ _ ___ _ __ ___ (_)_ __ (_) | \/ / |
| |\/| |/ _` |/ __| | '_ ` _ \| | '_ \| | | |\/| | |
| | | | (_| | (__ | | | | | | | | | | | | | | | |
|_| |_|\__,_|\___| |_| |_| |_|_|_| |_|_| |_| |_|_|
___ ____
_ _ __ ___ __ _ ___ / _ \/ ___| Welcome to Darwin on
_| |_ | '_ ` _ \ / _` |/ __| | | \___ \ Apple Silicon (16GB)
|_ _| | | | | | | (_| | (__| |_| |___) |
|_| |_| |_| |_|\__,_|\___|\___/|____/ 2020 M1 Mac Mini
Hardware donated, hosted, Report issues here:
and managed by Adélie Linux. zv.io/contact
(1) respect resources; (2) usage monitored; (3) backup your data
***** For a temporary Homebrew environment, run 'homebrew' *****
gcc104:~ ichard26$
got access to the (most of the) farm now
I just went with the default ssh-keygen gave me. I didn't feel like digging into customization that much :)
Good to know for later!
Yeah, wonder when they plan to change the default
well many months later I finally got this sort of working over at https://github.com/jvolkman/repairwheel
with pure-python approximations of codesign, otool, install_name_tool, patchelf
cool! what does this allow one to do now?
basically rewrite wheel extensions and include shared library dependencies, but cross-platform
really only makes sense if you're cross-compiling wheels
Then it's https://xkcd.com/1172/
I debugged Chinese translation build for the whole night until I tracked that down...
that hit us at CPython docs too, we've (hopefully temporarily) switched tracebacks to text code blocks:
https://github.com/python/cpython/pull/103421
for other projects, I'd probably pin below the new pygments version
And a colossal thank you to Ruff, for setting off all our malware scanning services by leaving flake8-bandit in the package 😛
Importlib.metadata is confusing to use. The stdlib docs are surprisingly sparse. The external API reference on RTD is nice, but it doesn't list EntryPoint (or EntryPoints for that matter).
Not to detract from all of the hard work I'm sure goes into importlib.* (anything away from pkg_resources is great) but its docs could be easier to grok.
Hahahaha the “antivirus” industry is so pathetic!
Ok
I have a few more actual arguments supporting this if anyone cares, but right now I just found it funny that Ruff sets it off. It’s a linter. How in the world could it possibly trigger any heuristics?
I can’t see this conversation occurring in a way that brings us to a healthy conclusion. Flake8-bandit uses strings commonly used by threat actors in systems enumeration and data exfiltration. The presence of flake8-bandit, subsequently, was correctly identified by our solution based on the information present within.
How is that “correct”? Is Ruff malware? No, so it was a false positive. I can believe that it’s hard to actually do something smart here, and that erring on the side of caution is a nice thing, but it shows one more fundamental flaw with the approach.
What if Ruff now gets allowlisted (which it should!), but then something gets compromised and a new Ruff version contains actual malware? It’s now on an allowlist and therefore has a license to contain those “evil” signatures! If the heuristic would actually do its job, it wouldn’t have detected it in the first place.
It’s not on an allowlist.
We do not whitelist packages for any reason.
We’ve correctly identified and reported over 200 malicious packages, and our data ingest is something like ~10,000 packages per week. It’s incredibly difficult to mitigate false positives, but it is an iterative process.
Which means that Ruff or anything like flake8-bandit can’t be used, potentially weakening security.
Will the AV flag itself? It of course has all the signatures to be able to recognize them!
Not saying identifying malicious packages isn’t a great service, but false positives can do actual harm to users.
Erm, I’m not sure if you understand my background.
I run an assertive package scanning service; I do not maintain an antivirus service.
We scan new and updated packages for potentially malicious indicators, and manually evaluate the contents contained before reporting them.
If my post mislead you to believing that the package was legitimately malicious, I apologize.
No, but I did misinterpret your process. If false positives don’t actually reach users, I have no complaints 😃
My problem is with fully automated processes (like antivirus, that’s why I mentioned AV in my initial comment). Because that approach has a lot of problems that can in many ways reduce security instead of improving it.
I’ll take the feedback into account moving forward. Our underlying tools utilize many existing processes that have effective and proven track records.
Our entire process is currently closed source at the moment, and aside from manually discussing things like the inclusion of certain packages flagging rules unintentionally, there is no external transparency.
Unfortunately, with a team of 10 individuals, and out of pocketing all costs in pursuit of open source security, we can only move at the speed with which we’re able to develop and iterate on existent processes.
Well, my main gripes are with AV run on user PCs, which has a bunch of issues that scanning doesn’t have. (E.g. Increased attack surface through elevated permissions)
If scan results are not automatically published without review to wherever library users will likely see them, I believe it’s a good deed to do what you do. But I do think that if automated publishing of results would end up scaring users off libraries like ruff would be a counter productive outcome. Linters like ruff help with security!
I knew learning a language that incidentally shares a name with a snake species, as a ophidiophobe, was a mistake!
That’s code name of my Rust-based workflow tool (eventually decided I prefer to write specs more and leave the actual implementation to more capable people)
https://github.com/uranusjr/molt
I'm quite curious what others think about this https://news.ycombinator.com/item?id=35790223
Why aren't you honored that your product was good enough for Google to absorb and build off of? I'd be super proud.
I feel like I'm in a fever dream reading these comments from engineers lol
is my perception off and this practice is actually pretty much fine?
all of those licenses require attribution
at least in the sense of maintaining copyright statements
oh interesting, I didn't know that. they definitely didn't do that then
the code in question is MIT/Apache v2 Licensed AIUI, MIT license states:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
Apache v2 States:
You must give any other recipients of the Work or Derivative Works a copy of this License; and You must cause any modified files to carry prominent notices stating that You changed the files; and You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.
since it appears to be dual licensed MIT/Apache v2, if we assume google used the less onerous of those licenses to use the code under, the code would need to maintain the Copyright (c) 2020 Ofek Lev
as well as the rest of the MIT license stuff
They've also licensed their project under Apache v2, so if they're using the original work under the MIT license, they'll have to include that license as well, as the overall work will be licensed under the restrictions of both MIT and Apache at the same time (this is different than your dual license, which allows downstream to choose either license)
unless they choose to incorporate your code using the Apache v2 license, which would simplify the licensing for their project, but still requires them to retain the copyright statements
it's so odd to me to neglect attribution
like, clicking fork is in fact easier then copying the code to a new repo
beyond that, I couldn't even imagine not attributing work to others even after a significant rewrite (which this is not)
it would just feel terrible and wrong
as an example I maintain bindings to a cryptographic library and I rewrote everything except part of the build system and I acknowledged the original project's contribution to the build system
yea I mean, the license requires it, and personally even if it didn't I would try to show some kind of attribution
I agree.
I actually started a project last week and I was concerned I didn't add enough attribution.
Just "doesn't feel right" to not acknowledge other's efforts.
Speaking of, did I add enough attribution? The project is actually from here: https://github.com/letsbuilda/pypi-inspector.letsbuilda.dev
I cloned https://inspector.pypi.io/ because I wanted a starting point for testing some parsing of package contents.
But all I added was a single line to the README linking to the original license.
Is that enough?
that seems sufficient, and you are already one line ahead of Google 😜
oof, sorry this happened @junior narwhal, that sucks. I raised this internally to try get it fixed 🤞
huh, excuse me while I update some copyright for dervived code
oh I should be good then
I simply think they didn’t know the license needed attribution and were confidently incorrect about this, as usual on Reddit and HN.
Others made a case about “if you don’t want your code taken and incorporated into a commercial product, use AGPL”. That’s a valid point if you feel like they shouldn’t just have taken the code (ignoring the attribution)
I don't disagree that there is an inherent difference between "I legally grant permission to do x" and "I think it's better manners to do X"
I wanted to categorize the responses from HN first. Category 3/3 concerns attribution.
And as a scientist, I fully agree: It is a dick move
But I expect absolutely nothing from corporations.
They will do all the dick moves that could potentially save them money.
If you want to protect your rights, use a license that protects it. Scares them off sometimes. If you really want to protect your rights, do that and also be prepared to go to court.
I'm not sure anyone's out there to... objectively be sinister. Sometimes the simplest solution is someone was confused at some point. 🤷♂️
yea I doubt it was anything sinister
I was speaking generally! I think not knowing how to navigate licenses as a newish dev is common and excusable.
But my point stands: If a company can get away with something, and leadership thinks it might make money, assume they will do it.
In this case, of course, the fork is also open source, so there’s no incentive (therefore I also assume innocence). But if something is internal code that leadership thinks might give the company an edge? You better bet they steal code and slap it in there without asking.
most of the companies I've worked at, particularly at Google's size, takes license stuff pretty seriously, and generally ban the use of code that isn't permissively licensed, even if they could possible use it legally without a concern.
of course random devs within those companies will do whatever
Yeah. They think they can’t get away with it. Others do.
Ah, the devs here certainly seem to have not that much experience with licenses: they didn’t fill in the [yyyy]-[mm] placeholder in the license: https://github.com/GoogleCloudPlatform/gcs-fuse-csi-driver/blob/e094d6d5720a0da489ae0748f7d04597206e89e7/LICENSE#L189
Eh no you’re not supposed to “fill in” that part. The appendix is for teaching people reading the document how to use the same license for their work. It should be included verbatim as the rest of the document; they are doing it the right way.
I see, seems like I should not infer things from licenses that I've never fully read myself lol
Is anyone interested in joining up / forming a small (GH) org for maintaining some direct bindings to useful rust packages (via maturin)? In the past few months I've written initial bindings for 3 packages I needed (im-rc, rpds, and regress), all fairly mechanically, but seems like might be nice to collaborate.
I don't have very much experience with Rust, so I wouldn't be able to contribute much, but I do have experience with managing GitHub orgs and workflows and publishing, so I'd be happy to help with the admin side.
I don't have much experience myself 😄 -- I did find it quite easy to get into! But yeah that kind of help is super super valuable so certainly interested in help there.
I'm pretty good with Rust but I've never done Python bindings with it before, I wouldn't mind learning
OK I created a crate-py organization on GitHub (the best name I could think of in 13 seconds) @junior narwhal adding you to it -- @kind moon if you send me your GH username I can add you as well. I'll transfer the 3 bindings I made to the org.
If anyone else is interested feel free to ping me.
shenanigansd
sounds cool. this? https://github.com/crate-py
Yup. I haven't added any org readme explaining it or anything, just created it and done the transfer
I couldn't think of a decent name that gave homage to jazzband (unfortunately brassband is taken on GH)
is it kind of like a nursery for python interop?
Yeah think that's the idea (or to complete the jazzband reference -- a jazzband specifically for rust->python bindings)
of course with 1 millionth of the effort and thought Jannis has put into this :P, I just am selfishly hoping to distribute the load on maintaining these 3 packages
Yea that sounds really cool. I'd offer to help, but my plate is pretty full atm. I'll keep my eye on it. Sounds awesome.
Very fair!
Entertaining exchange with a PyPI malware author. Asked him to knock it off and... shockingly, he did.
Which, in hindsight, further reinforces my intuition that a non-small part of malware authors on PyPI are probably just... kids interested in Cybersecurity that don't really understand the implications of what they're doing.
steel-drum?
We could be a windband?
Windows will be the death of me. WSL randomly stopped working which broke Docker and my SSH, required a reinstall of everything and a Windows update
still better than macOS though
Frankly that's been a common issue lately, I wonder if... something goofy is going on. There are more than a few people in PyDis that have been experiencing issues specifically with Docker and WSL.
idk ive enjoyed macos much more than windows so far
is anyone online right now and can test something real quick on macOS?
sure
can you try the installer?
.dmg
just wondering if it works
I think I did everything correctly
does it install correctly and add ddqa to your PATH?
interesting, I'm not sure why that would be
I'm a Windows user so I'm unfamiliar but I thought it should move that directory to your Applications folder
➜ MacOS pwd
/Applications/Datadog QA.app/Contents/MacOS
➜ MacOS ./ddqa
ERROR: Could not find a version that satisfies the requirement ddqa==0.0.1.dev1 (from versions: 0.0.1, 0.1.0)
ERROR: No matching distribution found for ddqa==0.0.1.dev1```
that's expected!!!!!!!! nice it worked
I had to copy it manually to the applications folder
yeah np
With mac installers, that picture I pasted above, there's the app on the left and the applications folder on the right, you just drag and drop in that window to install.
oh okay, and that is not working with this right?
or double click and brings up a window that has an installer kinda of like windows, where you pick the location and click through to the end
correct, it's just the app on left side
I'm curious if you still have a moment about if this installer works for you https://github.com/indygreg/PyOxidizer/releases/tag/pyoxidizer/0.24.0
if so then I'll probably just adopt his script instead
A little backwards but this is what you normally see
It copies, but doesn't add to path
that's so interesting that his small script is working but this popular option is not https://github.com/create-dmg/create-dmg
I'm wondering if spaces are disallowed in the name of the app
oh wait I think I messed up the invocation, I think rather than targeting the app folder you have to target the parent directory of that
Never mind, figured out why he removed it. lol.
what's that?
There's a tidbit in the readme about 'OSX 10.5 or later'. But I believe it may be... some interesting wording by the author indicating that they don't support EARLIER versions of Mac OSX
Requirements
Nothing except a standard installation of macOS/OS X is required.
We think this works in OS X 10.6 Snow Leopard and later.
We'd like to keep it working in as many versions as possible, but unfortunately, we just don't have test boxes running old versions of OS X adequate to make this happen. Development and testing mostly happens in the last 3-5 years' worth of macOS releases; as of 2020, this means macOS 10.12 and later.
But if you find a bug in an older version, go ahead and report it! We'll try to work with you to get it fixed.
If you're running OS X 10.5 or later, you're SOL. That's just too hard to deal with in 2020. ;)
Mistook that to mean it was no longer supporting additional releases of Mac OSX, apologies for the confusion. Was following this issue passively and doing my own research.
Oh I see, yes that is poor wording lol
after I fix this invocation everything is pretty much set up for Hatch to copy this config and start distributing for every platform
I'm so happy
I've been following the project closely, cheering for ya'!
(deleted some messages, just a user error on the part of a few co-workers)
I was talking with a Windows expert at work just now about build stuff and he casually said something and I'm like what and yes ... apparently on Windows there is not just "the heap" every module has their own and cannot touch others'
I feel like my brain expanded by 10x today
Referring to segment heap?
the conversation was in reference to memory from one library being freed in another
interesting, never heard of this https://developer.apple.com/documentation/xcode/configuring-your-project-to-use-mergeable-libraries
Hey @robust sandal just curious, in regards to https://discuss.python.org/t/change-in-pypi-upload-behavior-intentional-accidental-pebkac/27707/ it looks like scikit-build-core normalizes wheel filenames following the wheel specs, but does not normalize sdist filenames at all per PEP 625 (same normalization as the wheel spec). Is there a plan to implement that, like all other backends do (except for Setuptools, but it appears they plan to soon)? I couldn't find an issue for that.
I can change it, I was matching setuptools originally, since scikit-build was based on setuptools. I could add a config option if there are any issues (I've run into issues before with the sdist names and setuptools vs. other backends, since some things care about the SDist name, hopefully those issues are gone now though)
Anyone going to SciPy? I was organizing a scientific Python packaging BoF and was wondering if anyone else was also planning on doing so, or at least was able to make it?
@valid rover congrats on becoming the Security DIR!!! I'm excited to see what great things you'll work on in this space 🐍
(for those out of the loop: https://sethmlarson.dev/security-developer-in-residence)
Congratulations Seth! Also very excited to see what happens with PyPI in the coming year! Wishing you all the best!
Congrats!!!!
I'm sure that you'll do an amazing job and I'm looking foward to hear out more about you! ❤️
I'll probably be there but exactly when is still a bit in the air. I'm teaching (a packaging tutorial) at INTERSECT here at Princeton on Monday of SciPy And I've got confernces (at Princeton) the week after, too. But I'll be at SciPy at least for sprints. Maybe all three confernces days, maybe less.
Thanks @silk jungle @shell oracle and @cobalt valley 🙏
is the second entry in these tuples correct? I don't have a way to test 32-bit architectures atm https://github.com/pypa/hatch/blob/python/src/hatch/python/distributions.py
I'm using python -c "import platform;print(platform.machine().lower())"
actually maybe Linux should be changed:
❯ docker run --rm python linux32 python -c "import platform;print(platform.machine().lower())"
i686
I wonder if that is correct still if running normally on 32-bit rather than emulation with linux32
ichard26@gcc45:~$ python3
Python 3.4.2 (default, Sep 16 2019, 12:55:35)
[GCC 4.9.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> platform.machine().lower()
'i686'
>>>
ichard26@gcc45:~$ uname -a
Linux gcc45 3.16.0-11-686-pae #1 SMP Debian 3.16.84-1 (2020-06-09) i686 GNU/Linux
seems like it?
oh cool thanks!
I am unable to articulate why I think this but I'm almost positive on Windows it will return i386 so I am keeping that until I am presented with proof from someone
Well I'm trying to give you a hand here but uh
Me and Windows are not agreeing with each other.
this is too real at 4:25 😂 https://youtu.be/BgxklT94W0I?t=265
Added a #scikit-build 🙂
@buoyant flame any thoughts on signing official pyinstaller binaries? https://github.com/psf/black/issues/3725
it seems like a lot of work for little gain, but I don't use Windows anymore so I don't really have a stake here :)
Yeah, if you can, then you should. Cost would be the main reason to avoid it, but pretty sure the PSF will give grants for the cost of certificates. (However, executables generated by pip entry_points cannot be signed. No way to deal with that, unfortunately, other than by doing a decent amount of work...)
~/programming/oss/mypy$ lexa temp | wc -l
73
@muted whale IIRC you were the one who suggested a temp folder that's gitignored globally. A long while later, it has accumulated a lot of experiments :P
that's an interesting approach
there's a lot of stuff here :)
what I do is just create random .py files in whatever directory I happen to be in at the time
this is not at all confusing
Nice
I eventually end up with a dedicated repo for assorted crap in all my orgs
Hmmm? I do actually do something like that, but could you trigger my memory on the context of me suggesting it?
I do [this] (https://github.com/pradyunsg/dotfiles/blob/e5e81cb5746b0e243612cd3724daa707c40627a1/src/git/symlink.gitignore#L12-L14) in a global gitignore:
# Makes it easier to ignore files that I don't want to commit by mistake
*.ignore
*.ignore.*
This lets me add arbitrary files and directories, with their name clearly indicating that it's ignored.
nice idea
I use .git/info/exclude if it's something more permanent, if it's not then I'm just going to delete it at some point or move it outside if it annoys me to have an untracked file. I do have global gitignore as well but nothing clever like that there, may try it
you mean like a feature built-in to GitHub?
yeah, like what gitlab has
Slack busted for anyone else? Their status page is a little empty
yes they have an ongoing issue
From https://discuss.python.org/t/pep-722-dependency-specification-for-single-file-scripts/29905/305
X (formerly Twitter)
This is the first time I've seen someone ask to reach out on X (what a terrible name) and it feels very weird to see language that I've only seen in journalism-spaces to reference it, on d.p.o
it's possible that some people have not yet heard of the rebranding so I've been calling it that for a little while (it's also what shows up everywhere)
as far as contact, it's a great platform for messaging actually! it's how I've messaged Hynek, Michael (Talk Python), Charlie (Ruff), Samuel (Pydantic), Sebastián (Fast API), etc.
Come to Mastodon! Most of those people are there, and lots of other Python people
I did consider that but I prefer just using one app for everything and if I want to keep up on news/what's next in the zeitgeist you basically have to be on Twitter still
I stopped using Twitter
Same, it's probably about time I not only stop using it but also plain delete the account, I no longer have it installed and don't go to the site so if anyone tries to reach me there they'll probably get no indication I'm not ignoring them.
Twitter is still fine if you don't really care about the meta conversation surrounding leadership
(I don't)
twitter being sold was my excuse to get off one more social media I suppose :)
also I like the fact that they are not stagnant anymore, even if every feature or improvement may not be noteworthy
I don't want to enumerate everything that has changed that I like lol but I will say one of the best things is their all-in approach to birdwatch/community notes
I've seen so much misinformation called out or context added to stuff, I've even done it myself and voted on community notes since I was a member early
from random individuals clipping a video to mislead to government officials stating actually wrong stuff, it's amazing
Twitter is still fine
ICYMI there is no Twitter anymore so I guess that’s not exactly fine? 🤪
It's fine other than adding 5s delays to links to certain sites like the NYT and competitors, removing the block feature, unbanning and paying extremists, sacking 80% of the company, a rise in hate speech, suing anti-hate speech researchers
But other than that, Mrs. Lincoln, how was the play?
removing the block feature
Seems to work for me?
it's planned:
The block function allows a user to restrict specific accounts from contacting them, seeing their posts or following them. “Block is going to be deleted as a ‘feature’, except for DMs [direct messages],” Musk said in a post on the platform, saying later: “It makes no sense.”
Yeah that. It’s very much not fine when the owner promotes an interview between Andrew Tate (proud misogynist and rapist) x Tucker Carlson (white supremacist and not-so-crypto fascist).
… and then goes on to reshape Twitter to further enable and accommodate people like this.
It doesn’t matter which individual changes are maybe not 100% as bad as they are painted. Musk makes it clear who the platform is for now, harassment statistics consequently go through the roof, and as a result it’s not a platform I feel even remotely comfortable on anymore.
I’m actively building and participating in communities that make sure that they side with the victims, not the bullies. X is not a place like that.
as far as the hate speech data, I think it's prudent to see more comprehensive studies over time because like it or not much of the current talk/studies about that are politically motivated. for example, (people outside the US might not know this) there was talk for years about a right wing pipeline that the YouTube algorithm promotes and that is actually totally false and in fact the opposite of detectable political bias https://academic.oup.com/pnasnexus/article/2/8/pgad264/7242446 (that is the newest one but most research indicates the same thing)
and then, which is really unfortunate, you have just poorly done studies which are referenced by large media institutions like this one that is most cited about hate speech data in relation to the acquisition https://ojs.aaai.org/index.php/ICWSM/article/view/22222/22001
I just re-read it and even the first two figures are startling. the first one shows a spike before any policy changes happened nor layoffs and the second shows an already upward trend and an example of the previous year with the same levels
(to be clear the authors were ethical and have a very good Limitations and Future Directions section)
well, it's not just internal changes that might've contributed to an increase in hate speech. For instance, hateful users might've been emboldened by Musk's acquisition. Either way, this isn't a causal study, so unless the statistical analysis is flawed, I don't see why it might've been "poorly done"
I view it as poorly done for not taking into account confounding variables like the hate speech words chosen, other current events that are happening, etc. for example the spike in the previous year they attributed to political protests in Canada but then didn't talk about events that were happening in the spike they wanted to shine a light on
I definitely agree that showing a causal relationship isn't a requirement for studies!
build backends used by the top 2500 pypi packages:
setuptools.build_meta: 452
hatchling.build: 110
poetry.core.masonry.api: 101
flit_core.buildapi: 79
maturin: 12
poetry.masonry.api: 11
pdm.backend: 6
mesonpy: 5
setuptools.build_meta:__legacy__: 4
jupyter_packaging.build_api: 3
backend: 3
poetry_dynamic_versioning.backend: 2
pdm.pep517.api: 2
flit_scm:buildapi: 1
pbr.build: 1
scikit_build_core.build: 1
hatchling.ouroboros: 1
sipbuild.api: 1
setup: 1
flit.buildapi: 1
sphinx_theme_builder: 1
source: https://old.reddit.com/r/Python/comments/166a9br/pyprojecttoml_buildbackend_statistics/jyn02k8/
Nice. Now I got to find those 11 projects using old Poetry build API and migrate them to build backend lol
down/codeowners-0.6.0.tar.gz: codeowners-0.6.0/pyproject.toml: build-backend = "poetry.masonry.api"
down/aioboto3-11.3.0.tar.gz: aioboto3-11.3.0/pyproject.toml: build-backend = "poetry.masonry.api"
down/colorclass-2.2.2.tar.gz: colorclass-2.2.2/pyproject.toml: build-backend = "poetry.masonry.api"
down/databricks_api-0.9.0.tar.gz: databricks_api-0.9.0/pyproject.toml: build-backend = "poetry.masonry.api"
down/fastapi-utils-0.2.1.tar.gz: fastapi-utils-0.2.1/pyproject.toml: build-backend = "poetry.masonry.api"
down/graphlib_backport-1.0.3.tar.gz: graphlib_backport-1.0.3/pyproject.toml: build-backend = "poetry.masonry.api"
down/quinn-0.10.0.tar.gz: quinn-0.10.0/pyproject.toml: build-backend = "poetry.masonry.api"
down/pytzdata-2020.1.tar.gz: pytzdata-2020.1/pyproject.toml: build-backend = "poetry.masonry.api"
down/strawberry_graphql-0.205.0.tar.gz: strawberry_graphql-0.205.0/pyproject.toml: build-backend = "poetry.masonry.api"
down/terminaltables-3.1.10.tar.gz: terminaltables-3.1.10/pyproject.toml: build-backend = "poetry.masonry.api"
down/url-normalize-1.4.3.tar.gz: url-normalize-1.4.3/pyproject.toml: build-backend = "poetry.masonry.api"
Thanks 😄
from the top 4k (downloaded on 2023-07-04)
setuptools.build_meta: 871
poetry.core.masonry.api: 212
hatchling.build: 156
flit_core.buildapi: 100
poetry.masonry.api: 35
maturin: 14
setuptools.build_meta:__legacy__: 13
pdm.backend: 8
pdm.pep517.api: 7
mesonpy: 6
backend: 4
jupyter_packaging.build_api: 3
sipbuild.api: 3
flit.buildapi: 3
sphinx_theme_builder: 3
poetry_dynamic_versioning.backend: 2
flit_scm:buildapi: 2
whey: 1
pbr.build: 1
hatchling.ouroboros: 1
scikit_build_core.build: 1
and from the top 8k (downloaded just now)
setuptools.build_meta: 1263
poetry.core.masonry.api: 389
hatchling.build: 243
flit_core.buildapi: 152
poetry.masonry.api: 72
maturin: 27
setuptools.build_meta:__legacy__: 18
pdm.backend: 12
pdm.pep517.api: 10
whey: 8
poetry_dynamic_versioning.backend: 7
flit.buildapi: 7
mesonpy: 7
jupyter_packaging.build_api: 5
sphinx_theme_builder: 4
backend: 4
flit_scm:buildapi: 3
scikit_build_core.build: 3
sipbuild.api: 3
cython_backend: 1
pep517_backend.hooks: 1
ext: 1
pbr.build: 1
setup: 1
hatchling.ouroboros: 1
pdm.backend.intree: 1
I switched away from xonsh to nushell today, it's so cool! like powershell but actually easy to use and intuitive
everything is structured and pretty and can be manipulated by other things
Oooooh pretty
This is the Rust one, right?
yeah
Things I did with my nushell setup:
- activate the carapace completer (described in comments in the default config) to get a lot of tools autocompleted
- added a command-not-found hook for Arch Linux
- added a bunch of aliases like
def 'pipx list' [] { ^pipx list --json | from json }
But it’s very usable without much fiddling. One just needs to learn its idioms (as with anything that’s new to you) and deal with the breaking changes (as with anything prerelease)
for RTD, is there any way to use the latest Python version automatically?
I don't think there is a way. Updating the Python versions every year or two isn't too that bad...
The docs say you can use "3" for the last stable CPython version:
https://docs.readthedocs.io/en/stable/config-file/v2.html#build-tools-python
this weekend I think I'm going to make a small docker image for folks. last night I got the logic right and I have a way to turn a file with a bunch of commands into a terminal session gif. I was showing the project to someone and they messaged back that it was hard to tell the high level view of what it does without an example to show and I was like, hmm I'll have to learn how, so now I know 😃
should one set TERM to xterm-256color or xterm-24bit nowadays?
ideally you would set it to something that represents the terminal you use exactly (TERM points to a terminfo file with details about your terminal which libraries such as ncurses can use to know what to do in the terminal it's running in) but that might not exist for your terminal (or if it does exist, it may not be provided with the system-provided terminfo database) or it may cause problems with apps/scripts that simply check for xterm- prefix to determine if something is not a dumb terminal
oh okay interesting, thanks
if selecting just from the two you mentioned, choose the one that matches the colors supported by your app, most of the scripts that check for xterm-specific TERM, should only check for xterm- prefix. I imagine there could be some that check specifically for xterm-256color but if they do, they probably just limit you to 8 colors rather than no colors at all
I was thinking in the context of a pseudo-terminal as I'm using to produce the GIF file for terminal sessions. I wonder if I could set the latter and then the output would be truecolor
there's actually another env var
COLORTERM
that can be set to truecolor for true color support
when in doubt about that kind of stuff, I always look into rich code 😄
this is supposed to allow you to set TERM to a more common value (perhaps xterm-256color) while still getting truecolor
since TERM is tied to terminfo files
actually, case in point, my system does not have a terminfo file named xterm-24bit and I'm running 22.04 which is not old at all
if a specific terminfo file is missing on the system you're using it, a lot of simple stuff will work badly
stuff like cursor movement/looking up history with arrows keys
and TERM gets propagated when you SSH into any server
so if the server doesn't have it, you get the weird behavior
based on your question, I assumed xterm-24bit is probably something widely accepted as a thing but I guess not 😄
it looks like an informal standard among modern terminal emulators https://github.com/alacritty/alacritty/issues/1526
if you click through a bunch of links you end up at https://github.com/termstandard/colors#truecolor-detection
I mostly know about those things because kitty terminal wants to do things more properly and actually chooses to define its own terminfo which has been a bit of an annoyance at times because it's generally not part of distro's base packages
xterm-kitty
arguably using xterm- prefix when kitty is not xterm is not ideal but it does mean that all the things that check for xterm in TERM work properly with it
it offers a copy/paste to check for 24 bit color
awk 'BEGIN{
s="/\\/\\/\\/\\/\\"; s=s s s s s s s s;
for (colnum = 0; colnum<77; colnum++) {
r = 255-(colnum*255/76);
g = (colnum*510/76);
b = (colnum*255/76);
if (g>255) g = 510-g;
printf "\033[48;2;%d;%d;%dm", r,g,b;
printf "\033[38;2;%d;%d;%dm", 255-r,255-g,255-b;
printf "%s\033[0m", substr(s,colnum+1,1);
}
printf "\n";
}'
looks like it is working with replay!
@boreal bramble thanks again for that environment variable tip!
np
can someone on a macOS please try something for a moment?
sure, what's up?
I'm on a SSH session to a macOS machine so if this relies on a well featured terminal, I can't help unfortunately FYI.
