[Python-ideas] Re: A memory map based data persistence and startup speedup approach
Thanks for your advice! We're looking for opinions about the overall idea and workflow, and welcome code reviews after we get our lawyers happy and can publish the code :) I'll check python-dev to see if there're some questions. Best, Yichen -- From:Guido van Rossum Sent At:2022 Feb. 21 (Mon.) 05:36 To:python-ideas Subject:[Python-ideas] Re: A memory map based data persistence and startup speedup approach > 严懿宸(文极) via Python-ideas writes: > > Currently, we’ve made it a third-party library and have been > > working on open-sourcing. Stephen J. Turnbull wrote: > Thank you! I guess "working on" means "the lawyers have it" so we'll > be patient. :-) > I'm not sure whether your purpose is to get code review, or general > exposure. If the former, you might get better results from the Speed > list (https://mail.python.org/mailman3/lists/speed.python.org/). If > the latter, you should also post to python-list > (https://mail.python.org/mailman/listinfo/python-list or > comp.lang.python on Usenet). I'm not sure whether the speed list is still active. I'd personally try python-...@python.org or the python-dev section on discuss.python.org. (Full disclosure: I have seen earlier versions of Yichen's group's work and I am very impressed.) --Guido ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/6543VS7PLYRSF3Q7GYGZZRAF5NT2KMCZ/ Code of Conduct: http://python.org/psf/codeofconduct/ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/HDQVM5T67VTDII4VWC5BTLECSGOYZE5F/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: CLI convenience?
On 21Feb2022 09:12, Steven D'Aprano wrote: >On Sun, Feb 20, 2022 at 09:56:18AM +0100, Eliot Lear wrote: >> [...] I wonder if there is a reason why certain functions are not >> linked to console_scripts. In particular I would think this would be >> good for >> json.tool (though I might call it something else, like pyjson_pp). >> with venv. I'm sure I'm missing something obvious. [...] > >[...] >1. Not all functions would be useful as command line tools. > >2. Nobody has done the work to make it possible. > >3. If a Python package already defines a `__main__.py` file in the > package, you can call it as a CLI tool with `python -m package`. > So making it a separate CLI tool is redundant. A fourth reason is that one shouldn't be too profligate with installing scripts in the command line path. That "space" includes not just Python tools but every other command you could invoke - as a global namespace it is easily polluted. The previously mentioned "python -m module_name" command line mode provides precision here, particularly if you adjust the word "python", without polluting the command line space. That said, it isn't always a bad thing to provide a script. I do it myself. Choosing an name which is (a) expressive and (b) less likely to conflict with other's choices is important though. Cheers, Cameron Simpson ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/HD6TQC22ORI3T6RPWDD7FQIIA57U236E/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make 10**400 / 1e200 work?
On Mon, 21 Feb 2022 at 09:53, Tim Peters wrote: > > Once you start using slippery-slope arguments, pretty soon you're using > > them for everything, and progress grinds to a halt... > > Curiously, that itself is a slippery-slope argument ;-) Be careful. Once you start calling people out for using slippery-slope arguments, pretty soon you're busy all over the internet, contributing nothing else to a discussion... ChrisA ... oh. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4BJ4VZB5RW3TOJNU2CCULJB6EUOXSFHI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make 10**400 / 1e200 work?
[Ben Rudiak-Gould ]
> ...
> Python follows the IEEE rounding model for float/float and int/int.
> Following it for float/int and int/float would be pretty easy since
> the hard work has already been done to support int/int.
It doesn't end there. Mark was asking about analogous behavior for
mixing Fraction and float, and after that's answered "yes", the same
for Decimal.
> Let's just do it,
Who is "us"? I await your comprehensive patch ;-)
> and not worry about whether it's hypocritical to fix this without fixing the
> bigger problem.
I'm not concerned with hypocrisy. I'm concerned that we'd be giving up
a simple-to-understand rule about how mixing floats with other types
works ("convert the other type to float, and if it's not representable
as a float raise an exception"), and adding piles of delicate new code
to cater to a "use case" that DOESN"T EXIST. In 3 decades. nobody ever
asked for this.Eveni in this thread, the OP was just idly curious -
they have no actual use for it either.
> Once you start using slippery-slope arguments, pretty soon you're using
> them for everything, and progress grinds to a halt...
Curiously, that itself is a slippery-slope argument ;-)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/DZG2PFI6RFEFKYKVNXBM3IYGVXFRK5LQ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Using "Get Satisfaction" for Python Suggestions
On Sun, Feb 20, 2022 at 04:38:37PM +0100, Gerrit Holl wrote: > A problem with most online votes is that participation is > self-selected. There is no way to measure turnout, and therefore, it > is impossible to tell how representative the voters are for the > community at large. I'm sure that Minecraft knows precisely how many subscribers they have. If they have a million subscribers and 999,999 votes for a feature and 1 against, I think they could probably guess that the Yes votes were representative of the community at large. Democracies deal with this all the time. Some, like Australia, have compulsory voting, and something like 95% turnout. Other democracies struggle to reach 50% turnout, with figures closer to 30% being more typical. Some democracies discourage voting, or have unequal votes. In a situation like Minecraft, where the software runs on their servers, they could (hypothetically) even weight the votes according to how many hours of game play the account has done. Or look at whether certain features were more popular among hard core gamers or casual gamers, whether votes were associated with how much money they spend, etc. Python cannot do anything like that, not even in principle. Unlike Minecraft, who can tell you precisely how many accounts there are (and make a reasonable estimate of how many unique human users are associated with each account), we can't even guess how many Python developers there are with any degree of certainty. What even counts as a Python developer? Some disinterested teen forced to learn it at school? Professional programmers? Sys admins who edit the occassional .py script? Web developers who use Python frameworks? > If voting is limited to a select group (which could be as small as > Python core developers, or as large as anyone who has ever had a pull > request merged into cpython, or something in-between), then a vote > could be a way to measure opinions after a lengthy discussion fails to > reach a consensus. Sure. But another argument is that if a lengthy discussion fails to reach a consensus, the status quo should win. https://www.curiousefficiency.org/posts/2011/02/status-quo-wins-stalemate.html -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/R4ZSIDXXUMBZSVXK3PGV7XWC7YJJM63K/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make 10**400 / 1e200 work?
On Sun, Feb 20, 2022 at 9:41 AM Tim Peters wrote: > It's a slippery slope, of scant discernible benefit, and still hackish. > For example, 10**600 / 1e200 / 1e200. > That's how IEEE arithmetic works: a/b is computed to infinite precision then properly rounded, but (a/b)/c isn't. Yes, it's not ideal, but it was doable, and was better than not even having consistent behavior for a/b, which was the state of things before the standard. Python follows the IEEE rounding model for float/float and int/int. Following it for float/int and int/float would be pretty easy since the hard work has already been done to support int/int. Let's just do it, and not worry about whether it's hypocritical to fix this without fixing the bigger problem. Once you start using slippery-slope arguments, pretty soon you're using them for everything, and progress grinds to a halt... ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/UJQWFDWOOGYQDWWDT5CVLF4HN3ML7NBU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: CLI convenience?
On Sun, Feb 20, 2022 at 09:56:18AM +0100, Eliot Lear wrote: > Hi everyone, > > I'm sure there's a clear answer, probably written some place obvious, > but I wonder if there is a reason why certain functions are not linked > to console_scripts. In particular I would think this would be good for > json.tool (though I might call it something else, like pyjson_pp). Same > with venv. I'm sure I'm missing something obvious. Hi Eliot, What do you mean by "linked to console_scripts"? Are you referring to the packaging feature? https://python-packaging.readthedocs.io/en/latest/command-line-scripts.html If you are, I expect that the answer for why some functions aren't linked to console_scripts could be that: 1. Not all functions would be useful as command line tools. 2. Nobody has done the work to make it possible. 3. If a Python package already defines a `__main__.py` file in the package, you can call it as a CLI tool with `python -m package`. So making it a separate CLI tool is redundant. In the case of packages that are part of the Python stdlib, linking them to a stand alone CLI tool is more of a decision for the OS than for Python itself. On Linux, I think that the Linux distribution decides whether or not to include CLI tools for Python, and what they are called (e.g. whether or not the commands "idle" and "pip" exist). I don't know what happens on Mac and Windows. There is some evidence that stand-alone scripts (such as pip, and idle) are harmful. If you have many different versions of Python installed, as some people do, calling pip is not guaranteed to install into the version you were expecting. Same for launching idle, which may not run the version of Python you were hoping for. For example, on my system, my preferred version of Python 3.10, but `pip` installs into 2.7, and `idle` doesn't exist at all. But I can run the correct versions with `python3 -m pip` and `python3 -m idlelib`. My guess is that you may get better answers to your question if you ask it on the Packaging Discussion forum: https://discuss.python.org/c/packaging/14 -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2GSX3KKDYP7RVPZM2PJOJKZGLQXPROMJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: CLI convenience?
> On 20 Feb 2022, at 08:56, Eliot Lear wrote: > > Hi everyone, > > I'm sure there's a clear answer, probably written some place obvious, but I > wonder if there is a reason why certain functions are not linked to > console_scripts. In particular I would think this would be good for > json.tool (though I might call it something else, like pyjson_pp). Same with > venv. I'm sure I'm missing something obvious. You can use from the CLI like this for modules that a __main__.py has been provided. This includes pip, json, venv, tarfile and zip file (off the top of my head). python -m pip list python -m json python -m venv etc. On windows you would use py not python for preference: py -m pip list etc. This is documented for the modules I named above. Is that what you are after? Barry ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/TQKG7LAO57YHPPPXJ2H7E2MSCA7UYU66/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: A memory map based data persistence and startup speedup approach
> 严懿宸(文极) via Python-ideas writes: > > Currently, we’ve made it a third-party library and have been > > working on open-sourcing. Stephen J. Turnbull wrote: > Thank you! I guess "working on" means "the lawyers have it" so we'll > be patient. :-) > I'm not sure whether your purpose is to get code review, or general > exposure. If the former, you might get better results from the Speed > list (https://mail.python.org/mailman3/lists/speed.python.org/). If > the latter, you should also post to python-list > (https://mail.python.org/mailman/listinfo/python-list or > comp.lang.python on Usenet). I'm not sure whether the speed list is still active. I'd personally try python-...@python.org or the python-dev section on discuss.python.org. (Full disclosure: I have seen earlier versions of Yichen's group's work and I am very impressed.) --Guido ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/6543VS7PLYRSF3Q7GYGZZRAF5NT2KMCZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] CLI convenience?
Hi everyone, I'm sure there's a clear answer, probably written some place obvious, but I wonder if there is a reason why certain functions are not linked to console_scripts. In particular I would think this would be good for json.tool (though I might call it something else, like pyjson_pp). Same with venv. I'm sure I'm missing something obvious. Thanks, Eliot OpenPGP_signature Description: OpenPGP digital signature ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/TJ6NLKIGM3BD7DI6GFDZX4N2X3VQHYDT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make 10**400 / 1e200 work?
[Mark Dickinson ] > Unrelated question: under this proposal, what would you want > `Fraction(10**400) / 1e200` to do? Should it also produce a > `float` approximation to 1e200, or is it okay for it to raise > `OverflowError` as it currently does? The principled alternative to the current "in mixed-type arithmetic involving a float, operands are converted to float first" is "all operations are computed internally as if with infinite precision, then if the result is within the range of representable floats, the result is rounded to the closest such". But you already knew that ;-) It's a slippery slope, of scant discernible benefit, and still hackish. For example, 10**600 / 1e200 / 1e200. If we just do the first division "as if with infinite ...", it still blows up, despite that the computation as a whole would not if done "as if with infinite ;...:". Floats are not the computable reals ;-) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/6YLJZKLRH2YQ6NJWOC573NNTMYS5TVU7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make 10**400 / 1e200 work?
Mark Dickinson wrote: > Unrelated question: under this proposal, what would you want > `Fraction(10**400) / 1e200` to do? Should it also produce a `float` > approximation to 1e200, or is it okay for it to raise `OverflowError` as it > currently does? Somehow that sounds like a trick question :-). I'd say 1e200, yes, although didn't think much about it. Btw the full error message I get for that is "OverflowError: integer division result too large for a float". Even for `Fraction(10**400, 3) / 3.14`. Saying "integer division" when neither operand is an integer and I'm also not using `//` feels suboptimal. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/YEGZVGP4REPRF7DSA7L7B54YOEXJVVMO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Using "Get Satisfaction" for Python Suggestions
On Sun, 20 Feb 2022 at 08:05, Steven D'Aprano wrote: > > There is no way to make a popular vote fair. > > That's an odd take. > > A better take is that, fair or not, popularity is not necessarily a good > judge of what works well in a language. Language design requires skill > and taste, and it is not obvious that the wisdom of the crowd extends > that far. A problem with most online votes is that participation is self-selected. There is no way to measure turnout, and therefore, it is impossible to tell how representative the voters are for the community at large. If voting is limited to a select group (which could be as small as Python core developers, or as large as anyone who has ever had a pull request merged into cpython, or something in-between), then a vote could be a way to measure opinions after a lengthy discussion fails to reach a consensus. Gerrit. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/FOGDUYDNLUIANM4GBOLKNHKANOIJQUHC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Using "Get Satisfaction" for Python Suggestions
Hey Christ, We can always think in terms of weighted vote, the more your account is "well-established" (either by being ancient or by contributing) the more it's vote has weight. Anyway, just a suggestion. Regards, -- SENHAJI RHAZI Hamza Le dim. 20 févr. 2022 à 09:43, Chris Angelico a écrit : > On Sun, 20 Feb 2022 at 18:05, Steven D'Aprano wrote: > > > > On Sat, Feb 19, 2022 at 06:04:28AM +1100, Chris Angelico wrote: > > > > > Popularity is a *terrible* way to judge ideas. I'm currently fighting > > > with another platform on that same topic. > > > > Can we ask which platform? > > Not on-list, out of courtesy. It's unrelated. > > > > All you can see from a system like that is how many of the popular > > > ideas get implemented. It says nothing about how many good ideas end > > > up languishing with a small number of votes, simply because they never > > > reach critical mass and not enough people see them. > > > > Rather like the way we tell people to publish on PyPI and see if it > > becomes popular. > > Yes and no. Python doesn't use PyPI download counts to decide what > gets added to the standard library, for instance. A package is not > judged solely on the basis of some form of upvote. We tell people to > publish and see, but even if it isn't popular, it's still on PyPI and > has whatever value it has. > > > > Does GetSatisfaction allow downvotes? If yes: how do you stop a vocal > > > few from shooting down any idea they don't like? > > > > Nothing like Python-Ideas then :-) > > > > Typically voting systems only allow logged-in users to vote, and you can > > only vote once. You can change your vote at any time, but a vocal few is > > limited to only downvoting once each, they can't vote a thousand times > > each and overwhelm the popular voice. > > > > Same applies to up-voting. > > Question: Do votes from newly-created accounts have as much weight as > those from well-established accounts? I can assure you, from > experience, that there is no correct answer to this question, and that > the vocal few can always shoot down ideas they don't like, if > downvoting is a possibility. > > > > There is no way to make a popular vote fair. > > > > That's an odd take. > > "Fair" is such an ill-defined concept that the statement is almost > vacuously true. But here's one simple example: Politics in the United > Kingdom can be seen to be somewhat England-dominated, due to the > population density. This can lead to Scotland being underrepresented. > Or does it? Maybe Scotland is represented precisely as much as it > deserves to be. Or maybe not. What is fair? > > (It's quite amusing playing a grand strategy game and having Scotland > conquer all of England by forming military alliances with Austria as > well as France. Yeah, who's underrepresented now, huh?) > > > A better take is that, fair or not, popularity is not necessarily a good > > judge of what works well in a language. Language design requires skill > > and taste, and it is not obvious that the wisdom of the crowd extends > > that far. > > Yes, this is also true. And on the rare occasions when a poll is > conducted, it is purely for information, and is never binding. > Citation: PEP 308. > > https://www.python.org/dev/peps/pep-0308/#detailed-results-of-voting > > The C-like question/colon syntax and a parenthesized form of if > statement were both significantly more popular than the syntax that > ended up implemented. If the matter had been "put to a vote", we'd > have had a quite different result. And honestly, I'm glad of it. > > ChrisA > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/LCJJ7MGBUBD6UEIZW3B2U4XT4EXQMMSU/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/I2WY6GLLEMSALT3RB26G5N4QVU3EEZMB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Please consider making dataclasses define an empty __post_init__
This was discussed here: https://bugs.python.org/issue46757 This came up because I had a dataclass subclass to flax.linen.Module that had its own post-init. When I figured out that I needed to call super, I did so. Later, when I refactored my code to remove the superclass, the super-call was broken. It have been much simpler to always call super in __post_init__ from the start. The proposal on the bug report was to get in the habit of doing: if hasattr(super(), "__post_init__"): super().__post_init__() or: try: post_init = super().__post_init__ except AttributeError: pass else: post_init() I think it will be difficult to convince projects to do this. Best, Neil ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/B77X2LJVQ4LEWEYL72AJSYQWKTYCII6A/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Irrelevant venv? [was: Requirements.txt inside virtual environment]
Steven D'Aprano writes: > On Sat, Feb 19, 2022 at 04:14:57PM +0900, Stephen J. Turnbull wrote: > > Steven D'Aprano writes: > > > > > by the time you have finished debugging the script, the reason for > > > creating the venv in the first place is no longer relevent. > > > > Eh? Would you be willing to unpack that reference to 'venv' > > specifically, or was that just your patent-pending snark? I can't > > recall a venv being obviated by later developments, > > You have never created a venv and then later decided that it wasn't > needed because the project was cancelled, the job fell through, somebody > solved the problem in another way, your client changed the project > specifications and you deleted the old venv and created a new one, you > decided to work on something else instead, the company went bust, > etc? Oh, sure, that happens. If most of a code base goes away, of course so does the venv. That's actually a feature! But the *reason* for a venv in the first place is to ensure that neither the system nor the project pollutes the other with the "wrong" version of some dependency. I thought *that* was the "reason" you referred to as becoming irrelevant. > we sure are touchy about any suggestion that pip and venvs aren't > the greatest tools ever made. Eh, no, I really wanted to know if the need for isolation that venvs provide somehow goes away and under what circumstances. I have nothing invested in pip or venvs that would prevent me from adopting (or even helping to develop) something better (at least for future projects). > Here's a hint for the future. When I follow a comment with a smiley > emoticon or emoji, or *wink*, it means that my comment isn't > intended to be taken too seriously. Well, yes, that's why I asked whether it was your patent-pending snark. Thank you for confirming that it was. > especially the tendency to spend more time automating a task than will > ever be saved by the automation. LOL. All of the automation using pip and venvs that I work with has more than paid back my investment (especially those that were developed by somebody else! :-) Yet-another-Steve-who-knows-how-when-and-why-to-use-smilies ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/MGZVFLUZILV6JBG7LLJEOMVUJAFNYU7S/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Make 10**400 / 1e200 work?
On Sat, Feb 19, 2022 at 1:37 PM Stefan Pochmann wrote: > So could/should 10**400 / 1e200 be implemented to do that instead of > raising the error? Or is it a too rare use case and not worth the effort, > or does something else speak against it? > For me, it's not so much that it's not worth the effort, but more that it's not worth disrupting the clean and easily-digestible mixed-arithmetic model that we currently have. Unrelated question: under this proposal, what would you want `Fraction(10**400) / 1e200` to do? Should it also produce a `float` approximation to 1e200, or is it okay for it to raise `OverflowError` as it currently does? -- Mark ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/NGGFY223OQTOVXBOWU6MW5GOVM3VC3IE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Using "Get Satisfaction" for Python Suggestions
On Sun, 20 Feb 2022 at 18:05, Steven D'Aprano wrote: > > On Sat, Feb 19, 2022 at 06:04:28AM +1100, Chris Angelico wrote: > > > Popularity is a *terrible* way to judge ideas. I'm currently fighting > > with another platform on that same topic. > > Can we ask which platform? Not on-list, out of courtesy. It's unrelated. > > All you can see from a system like that is how many of the popular > > ideas get implemented. It says nothing about how many good ideas end > > up languishing with a small number of votes, simply because they never > > reach critical mass and not enough people see them. > > Rather like the way we tell people to publish on PyPI and see if it > becomes popular. Yes and no. Python doesn't use PyPI download counts to decide what gets added to the standard library, for instance. A package is not judged solely on the basis of some form of upvote. We tell people to publish and see, but even if it isn't popular, it's still on PyPI and has whatever value it has. > > Does GetSatisfaction allow downvotes? If yes: how do you stop a vocal > > few from shooting down any idea they don't like? > > Nothing like Python-Ideas then :-) > > Typically voting systems only allow logged-in users to vote, and you can > only vote once. You can change your vote at any time, but a vocal few is > limited to only downvoting once each, they can't vote a thousand times > each and overwhelm the popular voice. > > Same applies to up-voting. Question: Do votes from newly-created accounts have as much weight as those from well-established accounts? I can assure you, from experience, that there is no correct answer to this question, and that the vocal few can always shoot down ideas they don't like, if downvoting is a possibility. > > There is no way to make a popular vote fair. > > That's an odd take. "Fair" is such an ill-defined concept that the statement is almost vacuously true. But here's one simple example: Politics in the United Kingdom can be seen to be somewhat England-dominated, due to the population density. This can lead to Scotland being underrepresented. Or does it? Maybe Scotland is represented precisely as much as it deserves to be. Or maybe not. What is fair? (It's quite amusing playing a grand strategy game and having Scotland conquer all of England by forming military alliances with Austria as well as France. Yeah, who's underrepresented now, huh?) > A better take is that, fair or not, popularity is not necessarily a good > judge of what works well in a language. Language design requires skill > and taste, and it is not obvious that the wisdom of the crowd extends > that far. Yes, this is also true. And on the rare occasions when a poll is conducted, it is purely for information, and is never binding. Citation: PEP 308. https://www.python.org/dev/peps/pep-0308/#detailed-results-of-voting The C-like question/colon syntax and a parenthesized form of if statement were both significantly more popular than the syntax that ended up implemented. If the matter had been "put to a vote", we'd have had a quite different result. And honestly, I'm glad of it. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/LCJJ7MGBUBD6UEIZW3B2U4XT4EXQMMSU/ Code of Conduct: http://python.org/psf/codeofconduct/
