@dansup@stickfog@Irishmasms That being said, *if* you did want to change Pixelfed to cater to the use case I have in mind, I think the two main changes that would make the difference for me are:
- Add some way to upload a large group of photos and mark them as thematically related (e.g. all coming from one event) - this could entail raising the limit on number of photos in a post, or adding an entirely separate concept of an "album" or some such thing. - Have a way for a viewer to easily see and browse all the photos from a profile, or from a post or "album" or whatever. For comparison, right now if I look at my profile I see a list of posts but there's only one visible photo per post. I would want an interface that surfaces photos, not posts.
P.S. Either way I haven't given up on Pixelfed, I'll continue to use it; it's just not often that I have a good opportunity.
Honestly, don't take what I said as an indication that you should be doing anything differently. I think the kind of service Pixelfed is trying to be is not the kind of service I want. I'm more interested in a service where I can upload a whole album of photos (whether that's 3 photos or 300+), optionally annotate them with captions and other metadata, and share links to specific photos or to the album, or to my profile which would display everything I've uploaded in a nice, easy-to-browse format. It seems like the Pixelfed experience (presumably like Instagram, and also like Mastodon and other vaguely Twitter-like services) is more about making posts which are meant to be enjoyed for a little while and then more or less forgotten - not that they become unavailable, they just become inconvenient to locate, share, and browse.
@stickfog@Irishmasms Same. Though to be fair I'm only an occasional user... I was never on Instagram, so I don't care about replacing it, and I have not found #Pixelfed to be a suitable substitute for Facebook photos (or, for what it used to be).
@nshephard@faassen@inthehands@grimalkina@jenniferplusplus I think it shouldn't be taken quite so literally, but my understanding is that's kind of the point. "Best practice" is supposed to mean that, to the best of your ability to determine, you are doing the thing in the best way it can be done.
The alternative is that you know of a better way it could be done, but you're not switching because you think the existing way is good enough, or because you don't have time, or don't care, or whatever. And I think that can sometimes be okay, but it's also not hard to imagine how it could go very wrong. Whereas if you're using the best practice, it can't really be argued that you should have been using a different practice instead which would have prevented the thing from going wrong. If that argument can be made, then it's essentially saying you weren't actually using the best practice.
(Of course the definition of "best" and "better" is often very sensitive to context)
@faassen@nshephard@inthehands@grimalkina@jenniferplusplus It depends. In some (many?) cases, yes, improvement is possible in the sense that you can find a way to prevent the thing that went wrong without significantly increasing the risk of other things going wrong, and thus the best practice evolves (what used to be the best practice is no longer the best practice because you found a better one). In other cases, it's not possible to change the practice in a way that would prevent whatever went wrong without making it easier for other things to go wrong, and that tradeoff may not be worth it. Although I suppose those latter cases are more rare than people often think they are.
But ultimately actions matter more than labels, and if a particular organization believes they're better off by not labeling things "best practice", then yes, they should go with that. (Their best practice is to not use the term "best practice" 😛)
@nazokiyoubinbou@mcc FWIW people often recommend using python -m because it ensures that you're running code from whatever (virtual or system) #Python environment is currently activated, whereas if you run an entry point directly, like just pdm, you might be running a script that happens to be on your PATH but which does not live in the active environment. I do think it's a useful recommendation in most cases to help people avoid accidentally running things from the wrong environment.
Stuff installed with pipx is the exception, of course, because you specifically *don't* want to run it from whatever env is currently activated. (In a sense pipx is made to provide you with the illusion that a Python program is a regular old executable that you drop into PATH, i.e. you don't have to know or care that it is written in Python and you can just run it the same way as anything else.)
@glyph In the not-so-distant past I've run into a site at work that has exactly that problem on its login page, such that our own gTLD fails validation 😂
@geofft@glyph@eb I'm certainly not disputing that it's a real problem that that doesn't happen more often, but isn't there some precedent for big tech companies hiring people to work on specific open source projects? So it's not totally unheard of
@leftpaddotpy No, it does matter how true the material is. It would be wrong to always ignore true and relevant information just because it happened to be revealed by a bad source.
I'm not saying the source doesn't matter; it *is* useful to know who publicized the info and what agenda they presumably had in doing so. But the information, as long as it's true, does stand on its own as well. (If it's not true, then that's a different story of course.)
But seriously though, I would say almost the exact opposite of this. The type system in #Python isn't perfect, sure, but for me it definitely helps readability and comprehension. It's useful enough that the ability to use a static type checker has probably been the single biggest productivity boost I've experienced in the entire time I've been using Python (or at least is on the short list for that title).
@meejah@isagalaev@mitsuhiko I see. I'm not convinced though. Like, if the thing you like most about Python is that it looks like pseudocode, then that's fine, but you can still write Python that looks like pseudocode if you want to because type hints are optional. We don't write complex libraries and applications in pseudocode, though. (Or, we shouldn't) In those situations, static type checking is a big part of what elevates Python beyond pseudocode and makes it suitable for building those complex systems. (1/2)
@jsbarretto That's true, but I bet there are also a lot of people who don't feel similarly and thus are not reacting to this post. Obviously I can only guess at the real numbers, but I would imagine that among programmers (or writers, organizers, etc) who have worked on #opensource projects, only a small fraction of them have had a meaningful impact on the world through those contributions.
Software engineer, former particle physicist, occasional blogger. I support the principle of cake.I typically don't boost posts with images unless they have #AltText.