[Python-Dev] Re: Switching to Discourse
On Fri, Jul 15, 2022 at 9:33 AM Skip Montanaro wrote: > Email protocols were long ago standardized. As a result, people can use > any of a large number of applications to read and organize their email. To > my knowledge, there is no standardization amongst the various forum tools > out there. > While I understand and somewhat agree with you, Skip, there is a "hidden" feature of Discourse that does make it a little easier to track many different forums: You can add ".rss" to various URLs and get an RSS feed for that topic/channel/etc. e.g. the WebAssembly group is: https://discuss.python.org/c/webassembly/28 And its corresponding RSS feed is: https://discuss.python.org/c/webassembly/28.rss Cheers, Peter ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/MZMYCTFGLUKFD5JGE7XC5JGQ6NAIDTY3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?
On Wed, Feb 24, 2021 at 8:50 PM Mike Miller wrote: > I never understood the fear around version conflicts. With binary extension modules, version conflicts lead to (at best) runtime segfault and (at worst) subtle *data* bugs that return incorrect results. There are also deeper concerns around security and reproducibility. > Perhaps it has to do with > the decline of sys-admin skills over the years? Many millions of users of new Python users show up every year, using the language and its powerful ecosystem for data analytics and scientific computing, and they have no hope of having sys-admin skills. -Peter ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/TYZ6QT4BVQY7SVXV6E63YKNV6SCNFZ7V/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Thank you Larry Hastings!
Thank you Thank you, Larry! 3.4 and 3.5 were so critical to getting the scientific & pydata data community over the 2to3 hump. -Peter On Mon, Oct 5, 2020 at 1:43 PM Barry Warsaw wrote: > They say being a Python Release Manager is a thankless job, so the Python > Secret Underground (PSU), which emphatically does not exist, hereby > officially doesn’t thank Larry for his years of diligent service as the > Python 3.4 and 3.5 release manager. > > On the other hand, the Python Steering Council, Python Software > Foundation, and worldwide Python community, all of which emphatically *do* > exist, all extend our heartfelt thanks to Larry for his excellent > stewardship of Python 3.4 and 3.5! > > Python 3.4 and 3.5 were both pivotal releases. While the features of > these two releases are too numerous to mention here, they introduced such > staples as: > > * asyncio > * enum > * pathlib > * async and await keywords > * matrix multiplication operators > * typing and zipapp modules > > and so much more. For details, see: > > * https://docs.python.org/3/whatsnew/3.4.html > * https://docs.python.org/3/whatsnew/3.5.html > > Larry’s first official release of 3.4.0a1 was on 2013-08-03 and his last > Python 3.5.10 release was 2020-09-05. That’s 7 years of exemplary release > managing! > > Larry, from all of us, and from me personally, thank you so much for your > invaluable contributions to Python. Enjoy your retirement! > > Cheers, > -Barry (on behalf of the PSC and PSF) > > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/QGIHFU64TBYT56K6M5A5LYTYTSVFKHWQ/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/4CUKCSEICPIWWE4SDGLZU37VGYOUH3DP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Should set objects maintain insertion order too?
On Thu, Dec 19, 2019 at 9:57 PM Tim Peters wrote: > > It's not obvious to me that insertion order is even the most obvious or > > most commonly relevant sort order. I'm sure it is for Larry's program, > but > > often a work queue might want some other order. Very often queues > > might instead, for example, have a priority number assigned to them. > > Indeed, and it makes me more cautious that claims for the _usefulness_ > (rather than just consistency) of an ordered set are missing an XY > problem. The only "natural" value of insertion-order ordering for a > dynamic ordered set is that it supports FIFO queues. Well, that's one > thing that a deque already excels at, but much more obviously, > flexibly, and space- and time- efficiently. I agree with Tim and David. Furthermore, I'd like to point out that the core built-in types are frequently archetypes or foundational paradigms for many derived concepts in 3rd-party libraries. Despite the fact that they have implementations, they also form a basis set of interfaces which are part of the lexicon of "Pythonic-ness". Something like a "set" is a very very common and useful base interface for programming. If we were to cloud or confound the (relatively clean) semantics around sets & set algebra by introducing ordinality, that same cloudiness will spread throughout the ecosystem. Unlike dict()s, which are a more computer science-y data structure with lots of details, sets are simple things with mathematical algebraic properties. These allow the user to compactly specify *what* they want done, without delving into the details of *how*. In my experience, this is always preferable, for ease of use, ease of learning, and correctness. Adding orderedness as a concern now imposes an additional cognitive burden onto the coder because they must be concerned with *how*. Ultimately, even if we establish that there is major utility in insertion-ordered sets, unordered sets also clearly have utility as well (as a more relaxed interface, with fewer promises). So in that case, which do we want as the default? I think about it like this: In a future time when sets maintain insertion order by default, every time I see library docs that require casting sets via collections.unordered_set() will feel like sand in the semantic vaseline. I would much rather have things the other way around. I don't really have a horse in this race, and I'm sure the dev community will arrive at a good resolution to this issue. However, I would just encourage folks to think less about "utility of the implementation", and more about "economy of semantics". As Larry pointed out earlier, ordered dicts posed a problem for MicroPython. This actually isn't a minor issue -- in the long run, forked semantics are a Bad Thing for the language (even for a language that is incorrectly eponymized with snakes!). -Peter ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/EDWT5S3YIQ5UUEFDEWZHTV6YZJ3BNNKL/ Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-Dev] Increasing the C-optimized pickle extensibility
I strongly second not breaking backwards compatibility and interoperability, especially for persistent artifacts, unless there is a *REALLY* good reason. A potential unintended side effect of such breakages is that it slows down adoption of the new version. -Peter On Fri, Apr 26, 2019 at 10:27 AM Guido van Rossum wrote: > I think it's better not to introduce a new opcode, for the reason you > stated -- you don't want your pickles to be unreadable by older Python > versions, if you can help it. > > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] "Deprecation" of os.system in favor of subprocess?
On Wed, Oct 24, 2018 at 3:31 PM Steven D'Aprano wrote: > On Wed, Oct 24, 2018 at 09:34:34AM -0400, Calvin Spealman wrote: > > > Simply put, there is no valid use case for os.system over subprocess > > If you depreciate and then remove os.system, all you will do is force > people to re-invent it, badly and inefficiently. Indeed. Usability counts, as does not arbitrarily breaking vast amounts of existing code that Just Works. Every code-breaking deprecation is an invitation for unseen thousands or millions to ponder, "Hm, this script doesn't work anymore. Maybe now is the time to look at Node or Rust." -Peter ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Distutils] PEP 365 (Adding the pkg_resources module)
On Mar 20, 2008, at 11:31 AM, Martin v. Löwis wrote: I'll note that I use easy_install *only* to work in *non-system* locations: if I want to install Python packages to /usr/lib/ python2.x/, I use the standard system installer, e.g. 'apt-get install python-frobnatz'. This is probably not the Windows way of doing things (at least not how I use Windows). Windows doesn't really have the notion of system location (or multiple levels of them, where \Windows and \Windows\system32 is more system than \Program Files, say). Windows users typically view the entire system as theirs, and have no concerns at all about putting things into Program Files, system32, or, for that matter, \python25. In fact, they don't care or even know where stuff ends up - they expect that the system will find it, and they expect that they can remove anything they installed even without known where it is - because there is a standard place to look for uninstalling things. While these observations are accurate for most home users, it is worth noting that many IT departments deploy locked-down versions of windows that either have fine-grained group policies to forbid modifications to the system disk (and require the user to write things to a mounted network home directory), or that give write access to the system disk but then re-image it upon reboot. IT departments that deploy this sort of setup usually have the hostile user mentality, and that is strongly correlated, in turn, with users that are reluctant to engage IT to allow them install an app. We have run into this a few times, and it would be good to keep this scenario in mind. -Peter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
