[Python-ideas] Re: Is possible some day add Uniform Function Call Syntax (UFCS) in Python like Dlang?

[Steven D'Aprano]

On Sun, Jun 28, 2020 at 02:23:38PM -, marc...@email.com wrote:
> Is possible some day add Uniform Function Call Syntax (UFCS) in Python like 
> Dlang?
> 
> Example: https://tour.dlang.org/tour/en/gems/uniform-function-call-syntax-ufcs

That converts calls like:

a.fun()

to

fun(a)

I don't think that will be a good match for Python. In D, the compiler 
can decide at compile time:

- the instance `a` has no `fun` method;
- there is a global function `fun`;
- which takes a single parameter that matches the type of `a`;

and so convert the method call to a function call at compile time, with 
no loss of efficiency or safety.

But in Python, none of that information is available until runtime:

- the compiler doesn't know what type `a` will have;
- whether or not it has a `fun` method;
- whether or not there is a global function `fun`;
- and whether it takes an argument matching `a`.

So all of that would have to happen at run time. That means that using 
UFCS would make slow code. The interpreter would have to try calling 
`a.fun()`, and if that failed with an AttributeError, it would then try 
`fun(a)` instead.





-- 
Steven
___
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/TGGNWJPMKBYYTENDMGYYV2I5QEBTNJGP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] MODERATOR - in re "Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments"

[C. Titus Brown via Python-ideas]

Hello everyone,

the above referenced thread is getting heated and unfriendly; I’ve already 
rejected a message as inappropriately ad hominem. Please take some time to 
(re)consider the content of your e-mails before sending them. We may turn on 
default moderation if it continues.

As a reminder:

The code of conduct that governs this list (and all Python spaces) is here, 
https://www.python.org/psf/conduct/.

If you want to discuss the python code of conduct and its applicability to this 
thread (or anything else), python-ideas is not the place to do so. You may do 
so privately with the moderators (python-ideas-ow...@python.org should reach 
us), or with the CoC working group, at conduct...@python.org.

thanks,
—titus

___
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/YDE3PDS24UX352RA3MUK47IX3N2R4WNU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Access (ordered) dict by index; insert slice

[Neil Girdhar]

Can you use SortedDict.peekitem(index): 
http://www.grantjenks.com/docs/sortedcontainers/sorteddict.html ?

As other people are saying, the computational complexity of CPython's dict 
is linear for this operation.  SortedDict does it in logarithmic time.

On Friday, June 26, 2020 at 1:32:58 PM UTC-4, Hans Ginzel wrote:
>
> Date: Fri, 26 Jun 2020 18:47:44 +0200 
> From: Hans Ginzel > 
> To: Hans Ginzel > 
> Subject: Access (ordered) dict by index; insert slice 
>
> Hello, 
>
> thank you for making dict ordered. 
> Is it planned to access key,value pair(s) by index? See 
> https://stackoverflow.com/a/44687752/2556118 for example. Both for 
> reading and (re)writing? 
> Is it planned to insert pair(s) on exact index? Or generally to slice? See 
> splice() in Perl, https://perldoc.perl.org/functions/splice.html. 
>
> Use case: Represent database table metadata (columns). It is useful as to 
> access columns both by name and by index as to insert column on specific 
> position, https://dev.mysql.com/doc/refman/8.0/en/alter-table.html, 
> “ALTER TABLE ADD COLUMN [FIRST |AFTER col]” (consider default order or 
> table storage size optimisation by aligning). 
>
> Thank you in advance, 
> Hans 
> PS1: Named tuples cannot be used, are immutable. 
> PS2: See 
> https://metacpan.org/pod/perlref#Pseudo-hashes:-Using-an-array-as-a-hash
> ___
> Python-ideas mailing list -- python...@python.org 
> To unsubscribe send an email to python-id...@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/S7UMTWK65X6BJDYZ3SSU7I7HOIASDMMJ/
> 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/OFTBN3Y5PYGBJ6IMEQB75ZDZAUMQS5A4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Access (ordered) dict by index; insert slice

[Christopher Barker]

Perhaps a NamedList would be helpful here?

One could write one fairly easily.

-CHB


On Fri, Jun 26, 2020 at 6:13 PM Steven D'Aprano  wrote:

> On Fri, Jun 26, 2020 at 10:45:07AM -0700, Brett Cannon wrote:
>
> > Why can't you do `tuple(dict.items())` to get your indexable pairs?
>
> I don't think that an immutable copy is going to help Hans with his
> use-case, since he already mentions that tuples don't solve his problem.
>
> Swapping to a list gives you a mutable sequence that makes inserting
> columns easy, but now lookups by column name are O(N) instead of O(1).
>
> Hans, I think that a dict is probably not the best solution here, but
> you can use a dict in an augmented data structure. I would consider
> keeping your columns in a list, indexed by position, and keeping a table
> of columns to index in a dict. Whenever you insert or remove a column,
> you can update the table.
>
> If this sounds like a lot of work, yes, it probably is, and making dicts
> perform that work for *every single dict* would slow down the language a
> lot. Dicts are critical for speed and performance because they are used
> so extensively. Globals, builtins, almost every module, class and
> instance use dicts internally, so they need to be as fast as possible.
>
> If your experience with Perl tells you differently, please explain to us
> how Perl hashes work in order that they support both fast hash indexing
> and positional indexing at the same time.
>
>
> --
> Steven
> ___
> 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/POHINM764UHZKVXK3GWOYIJPF525IDCS/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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/YE7NC54KA4J7ESZRM4ZFE472QFGNYVEY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Is possible some day add Uniform Function Call Syntax (UFCS) in Python like Dlang?

[Steele Farnsworth]

In theory it could be checked to see if a given function exists in the same
namespace as a given variable if it doesn't exist in it that variable's
object's method resolution order and try calling it using the syntax
described here, but I don't think it affords the language any added
elegance or communicative power.

It would have to be determined which takes precedence when a class has a
certain method that shares a name with one in the same namespace as an
instance. If a method with a given name is not part of a class, the
proposed syntax would cause what function calls are valid for a given
instance to sometimes be context dependent rather than dependent only on
the definition of the class. I'm concerned about what this would mean for
language learning and debugging.

The potential use case seems to be tied to nested function calls that take
one argument in the innermost call. If we were to change the syntax to
streamline these constructions, I'd want to see composite functions with @
revisited.

Steele

On Sun, Jun 28, 2020, 11:00 AM  wrote:

> Is possible some day add Uniform Function Call Syntax (UFCS) in Python
> like Dlang?
>
> Example:
> https://tour.dlang.org/tour/en/gems/uniform-function-call-syntax-ufcs
> ___
> 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/UBGJ7K5YAYZSREN2QSTUEMLAS4JMYUCU/
> 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/X5XZYNJN5T4C2R2XZE6LTYKW3WSGSUDD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

[Paul Sokolovsky]

Hello,

Shouldn't such feedback be also cross-posted to the python-dev mailing
list? Also note the original pull request,
https://github.com/python/peps/pull/1470, and differences of what was
written in the pull request description and what went in the commit
message.


On Sun, 28 Jun 2020 22:10:14 +0200
"Giampaolo Rodola'"  wrote:

> From:
> https://github.com/python/peps/commit/0c6427dcec1e98ca0bd46a876a7219ee4a9347f4
> 
> > Instead of requiring that comments be written in Strunk & White
> > Standard  
> English, require instead that English-language comments be clear and
> easily understandable by other English speakers. This accomplishes
> the same goal without upholding relics of white supremacy. Many
> native English speakers do not use Standard English as their native
> dialect, so requiring conformation to Standard English centers
> whiteness in an inappropriate and unnecessary way, and can alienate
> and put up barriers for people of color and those whose native
> dialect of English is not Standard English. This change is a simple
> way to correct that while maintaining the original intent of the
> requirement.
> 
> This has nothing to do with making the wording "clear and
> understandable" (I agree on that). It's about, once again, bringing
> race-based politics into Python, and spreading hate towards a
> specific group of people: whites. Whether you're aware of it or not,
> there is a term for this: it's racism. I want to remind everyone that
> most of us here simply want to contribute code. We do it for free,
> and don't want to be involved in "this", because frankly it's
> disgusting. Doing something out of passion and for free, and at the
> same time seeing these sorts of things happening on a regular basis,
> looks and feels like an insult, and will only lead to people leaving
> this place.
> 
> On Fri, Jun 26, 2020 at 11:27 PM Keara Berlin 
> wrote:
> 
> > Hi all, this is a very small change, but I thought I would field it
> > here to see if anyone has suggestions or ideas. Instead of
> > requiring that comments be written in Strunk & White Standard
> > English, PEP-8 should require instead that English-language
> > comments be clear and easily understandable by other English
> > speakers. This accomplishes the same goal without alienating or
> > putting up barriers for people (especially people of color) whose
> > native dialect of English is not Standard English. This change is a
> > simple way to correct that while maintaining the original intent of
> > the requirement. This change may even make the requirement more
> > clear to people who are not familiar with Strunk & White, since for
> > programmers, the main relevant aspect of that standard is "be clear
> > and concise;" simply saying that instead of referencing Strunk &
> > White may communicate this more effectively. Here is the current
> > line in PEP-8: "When writing English, follow Strunk and White."
> > I propose changing this line to "When writing English, ensure that
> > your comments are clear and easily understandable to other English
> > speakers." ___
> > 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/AE2M7KOIQR37K3XSQW7FSV5KO4LMYHWX/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> >  
> 
> 
> -- 
> Giampaolo - gmpy.dev 



-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
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/66T2R6G3YMX25LYVBHVLGGCREP2AYA7R/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

[Giampaolo Rodola']

From:
https://github.com/python/peps/commit/0c6427dcec1e98ca0bd46a876a7219ee4a9347f4

> Instead of requiring that comments be written in Strunk & White Standard
English, require instead that English-language comments be clear and easily
understandable by other English speakers. This accomplishes the same goal
without upholding relics of white supremacy. Many native English speakers
do not use Standard English as their native dialect, so requiring
conformation to Standard English centers whiteness in an inappropriate and
unnecessary way, and can alienate and put up barriers for people of color
and those whose native dialect of English is not Standard English. This
change is a simple way to correct that while maintaining the original
intent of the requirement.

This has nothing to do with making the wording "clear and understandable"
(I agree on that). It's about, once again, bringing race-based politics
into Python, and spreading hate towards a specific group of people: whites.
Whether you're aware of it or not, there is a term for this: it's racism.
I want to remind everyone that most of us here simply want to contribute
code. We do it for free, and don't want to be involved in "this", because
frankly it's disgusting. Doing something out of passion and for free, and
at the same time seeing these sorts of things happening on a regular basis,
looks and feels like an insult, and will only lead to people leaving this
place.

On Fri, Jun 26, 2020 at 11:27 PM Keara Berlin  wrote:

> Hi all, this is a very small change, but I thought I would field it here
> to see if anyone has suggestions or ideas. Instead of requiring that
> comments be written in Strunk & White Standard English, PEP-8 should
> require instead that English-language comments be clear and easily
> understandable by other English speakers. This accomplishes the same goal
> without alienating or putting up barriers for people (especially people of
> color) whose native dialect of English is not Standard English. This change
> is a simple way to correct that while maintaining the original intent of
> the requirement. This change may even make the requirement more clear to
> people who are not familiar with Strunk & White, since for programmers, the
> main relevant aspect of that standard is "be clear and concise;" simply
> saying that instead of referencing Strunk & White may communicate this more
> effectively.
> Here is the current line in PEP-8: "When writing English, follow Strunk
> and White."
> I propose changing this line to "When writing English, ensure that your
> comments are clear and easily understandable to other English speakers."
> ___
> 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/AE2M7KOIQR37K3XSQW7FSV5KO4LMYHWX/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Giampaolo - gmpy.dev 
___
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/J2LC553NWBTANBRIPI52CQW53JXCCUTH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

[David Mertz]

On Sun, Jun 28, 2020, 10:19 AM Jeff Allen
> Now the commit message is the thing that causes me to write. It contains
a long justification for the change. It need only have said that we've
decided not to enforce S rules. It is somewhat offensive, since it
asserts as fact an opinion the community evidently does not hold
universally, which is that the recommendation to use a standard form of
English is "upholding relics of white supremacy".

The commit message is simply silly. It introduces numerous contentious and
false claims that have nothing whatsoever to do with the small wording
change. It misunderstands how language, culture, history, and indeed white
supremacism, work.

I would recommend amending the commit message.

The underlying change itself is reasonable, and to my mind a small
improvement. There was unnecessary specificity in using Strunk and White as
reference, and not, say, William Zinsser's _On Writing Well_, which is
almost as well known. In the concrete, it would be exceedingly rare for
these to provide conflicting advice on a specific code comment.
___
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/N7Z4HDYP7CV75GRCBLMZGSFEDZTFIVQF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

[MRAB]

On 2020-06-28 13:25, Jeff Allen wrote:
[snip]
And the conclusion is right, but the argument is better than he makes 
it. I've no idea what a Weegie is, but Brum is just up the road from 
where I write, and I can tell you only about 60% of Brummies class 
themselves as white. A high proportion of those that don't are yet 
native speakers of English, often in the distinctive Black Country 
accent that some scholars think was Shakespeare's. Those who hope to be 
understood widely, in my experience, moderate their use of regional 
words, but it's grand to add a bit of local colour now and then.



I suspected that "Weegie" was Glaswegian. I quick search confirmed that.

[snip]
___
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/BA2S6NN6ZJWAFLP2SW63TI7OIV2WIW22/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Is possible some day add Uniform Function Call Syntax (UFCS) in Python like Dlang?

[marcone]

Is possible some day add Uniform Function Call Syntax (UFCS) in Python like 
Dlang?

Example: https://tour.dlang.org/tour/en/gems/uniform-function-call-syntax-ufcs
___
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/UBGJ7K5YAYZSREN2QSTUEMLAS4JMYUCU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

[Jeff Allen]

On 27/06/2020 10:35, Stephen J. Turnbull wrote:

Keara Berlin writes:

  > Here is the current line in PEP-8: "When writing English, follow
  > Strunk and White."  I propose changing this line to "When writing
  > English, ensure that your comments are clear and easily
  > understandable to other English speakers."

That's the same thing ("clear and understandable writing" is the
purpose of _The Elements of Style_), except that Strunk and White
provide guidelines as to *how* to make your writing "clear and easily
understandable".  This is useful to non-native speakers, and perhaps
to others.


It is useful to recommend a guide to plain, comprehensible writing. 
Other guides are available (I've a soft spot for Gowers). Guido informs 
us S rules were not being enforced as a requirement by reviewers, and 
we've all been ok with that. I don't think anyone on the thread said 
they should. So that is the argument for removal of the requirement.



... the reference to Strunk and White is
the kind of quirky thing that endears Python to me, beyond it being a
great community and a language full of wonders and practical use.  I
would be sad to see it deleted.


Then be sad. Turns out we are discussing a new idea: "Recommend a guide 
to writing clear comments in PEP-8". Fait accomplis:


https://github.com/python/peps/commit/0c6427dcec1e98ca0bd46a876a7219ee4a9347f4)

Steven D'Aprano writes:

   """Language that is clear and understandable to a Geordie, Brummie or
   Weegie could be incomprehensible to others. I've intentionally used only
   examples of white people here because this issue is not about "people of
   color" and it transcends parochial concerns about race."""

And the conclusion is right, but the argument is better than he makes 
it. I've no idea what a Weegie is, but Brum is just up the road from 
where I write, and I can tell you only about 60% of Brummies class 
themselves as white. A high proportion of those that don't are yet 
native speakers of English, often in the distinctive Black Country 
accent that some scholars think was Shakespeare's. Those who hope to be 
understood widely, in my experience, moderate their use of regional 
words, but it's grand to add a bit of local colour now and then.


Now the commit message is the thing that causes me to write. It contains 
a long justification for the change. It need only have said that we've 
decided not to enforce S rules. It is somewhat offensive, since it 
asserts as fact an opinion the community evidently does not hold 
universally, which is that the recommendation to use a standard form of 
English is "upholding relics of white supremacy".


I get that S is a bit American, but recommending this or another 
resource does not make someone a white supremacist. I regret that this 
disagreeable view has made its way into the record. Arguments have been 
made in this thread that taking care to be clear in our writing is an 
inclusive act, and in fact the paragraph that follows the amended one 
makes a similar point.


That so many of us speak and read some form of English at all is a relic 
of British supremacy and an effect of recent American supremacy. It is 
unfortunate, from the perspective of universal communication, that other 
languages exist at all, although enriching in other ways. It's just 
history and where we are.


PEP-8 chooses to require English in comments [1]. In view of this, the 
use in the amended text of "other speakers of the language you are 
writing in" is needlessly complicated. It contains, let's remember, 
"coding conventions for the Python code comprising the standard library 
in the main Python distribution", for which English has been chosen, and 
those who use it for something else should adapt it. I know that in 
Python sometimes you have to be Dutch, but fortunately not when writing 
comments: that would be a barrier to contributing. I'm in luck.


There is a lot of righteous anger just now about a class of 
long-standing injustices world-wide, and recent ones in the US, that 
colours the discussion. It is very difficult to address any argument, 
however weak, that starts from this anger, because of the risk it will 
be construed as disagreeing with the starting point, but please try to 
be tolerant of reason. I do not disagree with the values motivating 
efforts to be more inclusive.


The Python community is exemplary in its intention to be inclusive, but 
here we are made afraid to say directly "please write in English and 
here is as a guide to doing so clearly", apparently because it is 
"putting up barriers for people whose native dialect of English is not 
Standard". There is no one standard English, but there is a range of 
broadly accepted, educated English. The guide is cheap, so the 
accusation of exclusivity must be the assumed cultural imperialism of 
asking people to write this educated English. The argument leads to 
"everyone should be free to write in their own variant of English, with 
no