[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: PEP 671 proof-of-concept implementation
On Fri, 29 Oct 2021 at 11:10, Steven D'Aprano wrote:
> Obviously you need a way to indicate that a value in __defaults__ should
> be skipped. Here's just a sketch. Given:
>
> def func(a='alpha', b='beta', @c=expression, d=None)
>
> where only c is late bound, you could have:
>
> __defaults__ = ('alpha', 'beta', None, None)
> __late_defaults__ = (None, None, , None)
Why not define an object for that?
__defaults__ = ("alpha", "beta", _delayed, None)
In this example I don't mean a fancy new delayed evaluation type such
as has been discussed elsewhere, but just a sentinel so Python knows
it has to look into __late_defaults__ at all (I'm probably missing
something, and I didn't read all prior emails on this, but why
wouldn't this type contain a reference to the code object directly,
negating the need for __late_defaults__...?).
Regards,
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/G4R5X7G5MFYOPJOCUWASVRLR2O7MCUL6/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: allow initial comma
Hi,
On Fri, 12 Mar 2021 at 15:12, Paul Moore wrote:
> This layout style is not something I've ever seen used in "real life",
> and I don't think it's something that should be encouraged, much less
> added to the language.
> More likely because there are two common schools of thought - lists
> have punctuation *separating* items, and lists have punctuation
> *terminating* items. I don't even know a commonly used term for the
> idea of having something *before* each item.
If Roland wants to prepend each item of his list, he can always write
>>> yaml.load(io.StringIO("""
... - a
... - b
... - c"""))
giving ["a", "b", "c"] ;-)
The point being: it's actually very common to prepend each item of a
list with a character, arguably more common than after each item.
That character may be '-', '•', '∗', but I've never seen ',' used. In
most cases, each item in such lists appears on a separate line. Apart
from the YAML example given above, this style is used in many
ReST/Markdown/ASCIIdoc/wikitext flavours and on whiteboards and
notebooks in English, Russian, Swahili, and Volapük around the world.
Regards,
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/UG32SOALEP5IVGTKGPQMJC54ASH7EH3F/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 472 -- Support for indexing with keyword arguments
On Sat, 18 Jul 2020 at 18:31, MRAB wrote: > [snip] > I haven't followed this thread for a while, but, to me, it seems that > the simplest option would be to pass the keyword arguments as a dict: > > obj[a, b:c, x=1] does obj.__getitem__((a, slice(b, c)), dict(x=1)) > > If there are no keyword arguments, then there's no dict. Could the entire argument be turned into a namedtuple? obj[a, b:c] does obj.__getitem__((a, slice(b, c)) or obj.__getitem__(namedtuple(_0=a, _1=slice(b, c))) obj[a, b:c, d=e:f] does obj.__getitem__(namedtuple(_0=a, _1=slice(b, c), d=slice(e:f))) it would seem a namedtuple is a more natural extension of the current tuple, fully backward compatible (for sane code), while allowing for keywords that are valid identifiers (which should be an acceptable limitation). The other restriction would be that the keyword-indexing cannot use all-numeric identifiers prepended by an underscore. 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/ZZDIVLUFIM2B45BRVQAZ5EMFKJQ6IJTL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 472 -- Support for indexing with keyword arguments
On Mon, 20 Jul 2020 at 04:27, Jonathan Goble wrote: >> One use case that comes up in xarray and pandas is support for indicating >> indexing "modes". For example, when indexing with floating point numbers >> it's convenient to be able to opt-in to approximate indexing, e.g., >> something like: >> array.loc[longitude, latitude, method='nearest', tolerance=0.001] > > I had to stare at this for a good 30 seconds before I realized that this > wasn't a function/method call. Except for the square brackets instead of > parentheses, it would be. > > Honestly, this whole idea smells to me like just wanting another type of > function call with different semantics. > > IMHO the above example would be better spelled as: > > array.loc.get(longitude, latitude, method='nearest', tolerance=0.001) > > Pros: Much more obvious, perfectly legal today, zero backward compatibility > issues, probably the way many libraries with such functionality are doing it > now. > Cons: A few extra characters (depending on the method name; here it's only > four) and a couple of taps on the Shift key (but you're already used to that). Cons - cannot assign to method call - cannot use slicing syntax With PEP: array[lon=0:10, lat=0:10, method="nearest", tolerance=0.001] = 42 Without PEP (syntactically valid, although not valid xarray API): array[K(lon=slice(0, 10), lat=slice(0, 10), method="nearest", tolerance=0.001)] = 42 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/JF5SSNHIETRJKBM2ADEOCFGTJVD3XMWW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Equality between some of the indexed collections
On Sat, 2 May 2020 at 15:06, Ahmed Amr wrote:
>
> I'd like to take your opinion on modifying some of the indexed collections
> like tuples, lists, arrays to evaluate its equality to True when having the
> same items in the same indexes.
> Currently, when comparing a list of items to an array of the same items for
> equality (==) it returns False, I'm thinking that it would make sense to
> return True in that context, as we're comparing item values and we have the
> same way of indexing both collections, so we can compare item values.
>
> So what do you think about applying such behavior on collections that can be
> indexed the same way such as tuples, lists, and arrays?
>
> Example: (Current)
>
> import array
> tuple_ = (1.1, 2.2, 3.3)
> list_ = [1.1, 2.2, 3.3]
> array_ = array.array('f', [1.1, 2.2, 3.3])
>
> # all of the following prints False.
> print(tuple_ == list_)
> print(tuple_ == array_)
> print(array_ == list_)
>>> import numpy as np
>>> np.array_equal((1.1, 1.2, 1.3), [1.1, 1.2, 1.3])
True
___
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/3L7URUZIBQIXNZOBXS77ROUHGJJKLG6J/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] PEP 9999: Retire animal-unfriendly language
(needs a sponsor) latest version at https://github.com/gerritholl/peps/blob/animal-friendly/pep-.rst PEP: Title: Retire animal-unfriendly language Author: Gerrit Holl Discussions-To: python-ideas@python.org Status: Draft Type: Informational Content-Type: text/x-rst Created: 01-Apr-2020 Post-History: 01-Apr-2020 Sponsor: Abstract Python has long used metasyntactic variables that are based on the consumption of meat and dairy products, such as "spam", "ham", and "eggs". This language is not considerate to pigs or chicken and violates the spirit of the Code of Conduct. This PEP proposes to retire the use of those names in official Python documentation and source code and to recommend users of Python to do the same. Motivation and Rationale Estimates for the number of animals slaughtered for meat every year vary, but `worldindata`_ estimates around 80 billion individuals. Farmed animals are often kept in small cages with little to no access to daylight, suffer stress during life and slaughter, or are otherwise systematically mistreated. The `Python Code of Conduct`_ describes that community members are open, considerate, and respectful. The Python standard library and documentation contain numerous references to meat or dairy based food products that are not respectful to our fellow inhabitants of planet Earth. Examples include "spam", "bacon", and "eggs". To align the language use in the standard library and documentation with the Code of Conduct, use of such language should be retired. Current practice There is a widespread tradition in the Python standard library, the documentation, and the wider community, to include references to Monty Pythons Flying Circus. The use of "spam", "bacon", "sausage", and "eggs" can be traced back to the `"Spam" sketch`_ originally broadcast by the British Broadcasting Corporation (BBC) on 8 September 1972. In this sketch, a couple are trying to order food in a diner where all items contain spam. The woman does not like spam and wants to order food without spam. A group of horned vikings then sing about the wonderful spam. To get an overview of the usage in the current standard library, the command ``cat $(find . -name '*.py') | grep -oi term | wc -l`` was used. This showed 2615 occurences for spam, 593 for ham (this include some false positives, among other reasons due to references to people whose name innociously contains the substring ham), 517 for eggs, 57 for bacon, and 10 for sausage. Searching ``*.rst`` in the documentation revealed 391 occurrences for spam, 82 for ham, 96 for eggs, 28 for bacon, and 10 for sausage. The source code for cpython revealed just 2 usages for spam and 1 for eggs. Proposed alternatives = Keeping with the good practice of referencing sketches from Monty Python's Flying Circus, this PEP proposes to adopt the fruits mentioned in the `"Self-Defence Against Fresh Fruit" sketch`_: * raspberry (not currently in use) * banana (68 times in standard library) * apricot (not currently in use) * pineapple (8 times in standard library) * peach (once in standard library) * redcurrant (not currently in use) * damson (not currently in use) * prune (23 times in standard library) Other possible alternatives keeping with food items: * salad (occurs once in standard library) * aubergine (referred to in the spam sketch) * shallot (the same) * tofu (vegan protein alternative) Specification = For the reasons mentioned in the rationale, all references to meat or dairy products shall be removed from the Python standard library, the documentation, and the cpython source code. The wider Python community is recommended to follow this practice. In core Python: * Programmers SHALL NOT use the metasyntactic variables "spam", "ham", "bacon", or "sausage", neither as variable names, nor in example strings, nor in documentation. * Programmers SHALL NOT use the metasyntactic variable "eggs" in context with food items, but may still use it in context of other body parts. Prohibited: ``["salad", "eggs"]``. Allowed: ``["ovaries", "pouch", "eggs"]``. * Programmers SHALL NOT use any other metasyntactic variable that is unfriendly to animals. The wider Python community is encouraged to adopt these practices as well, but the continued use of animal-unfriendly metasyntactic variables will not be considered a violation of the code of conduct. Rejected ideas == The authors carefully considered the widespread use of the word "bug" in the meaning of a source code error. Insects including bugs play a crucial role in ecosystems around the world, and it is not fair to blame them for an error that can only be t
