Re: [Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

The problem is to improve https://github.com/django/django/blob/master/django/contrib/admin/options.py#L1477-L1493 Here's a suggestion. For each of four permissions, the code has an assignment such as has_add_permission = inline._has_add_permission(request, obj) and the function call

Re: [Python-ideas] Fwd: Add Unicode-aware str.reverse() function?

On Sun, Sep 9, 2018 at 6:08 AM, Jonathan Fine wrote: > Chris Angelico wrote: > >> Generally, problems with RTL text are *display* problems, and are not >> solved by reversing strings. > > I very much agree with this statement, with one exception. If you wish > to display RTL text on a LTR

Re: [Python-ideas] Pre-conditions and post-conditions

Michel Desmoulin wrote: > Isn't the purpose of "assert" to be able to do design by contract ? > > assert test, "error message is the test fail" > > I mean, you just write your test, dev get a feedback on problems, and > prod can remove all assert using -o. > > What more do you need ? Good

Re: [Python-ideas] Keyword only argument on function call

On Thu, Sep 06, 2018 at 07:05:57AM -0700, Anders Hovmöller wrote: > On Thursday, September 6, 2018 at 3:11:46 PM UTC+2, Steven D'Aprano wrote: [...] > > But why should I feel bad about failing to > > use the same names as the functions I call? > > Yea, why would you feel bad? If you should

Re: [Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

OK. Here's another piece of code to look at, from a URL that Kyle Lahnakoski posted to a different thread. https://github.com/django/django/blob/master/django/contrib/admin/options.py#L1477-L1493 def get_inline_formsets(self, request, formsets, inline_instances, obj=None):

Re: [Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

Hi Anders You wrote: > A dict merge is fairly trivial to implement to get even 2.7 support so no > need to be that restrictive. > This is a good fix for this case. I very much appreciate your openness to solutions other than the one you proposed. I like experts who are willing to change their

Re: [Python-ideas] Fwd: Add Unicode-aware str.reverse() function?

On 9/8/18 4:55 PM, Jonathan Fine wrote: > Chris Angelico wrote: > >> Improving a rendering engine or console so it's capable of correct RTL >> display is outside the scope of Python code, generally. > I agree with you, generally. > > But there are over 600 million people who speak a RTL language.

Re: [Python-ideas] Keyword only argument on function call

Le 06/09/2018 à 03:15, Anders Hovmöller a écrit : > I have a working implementation for a new syntax which would make using > keyword arguments a lot nicer. Wouldn't it be awesome if instead of: > > foo(a=a, b=b, c=c, d=3, e=e) > > we could just write: > > foo(*, a, b, c, d=3, e)

Re: [Python-ideas] Fwd: Add Unicode-aware str.reverse() function?

On Sat, Sep 8, 2018 at 11:41 PM, Jonathan Fine wrote: > M.-A. Lemburg wrote: > >> Most likely yes, but they would not render RTL text by first >> switching the direction and then printing them LTR again. >> >> Please also note that switching from LTR to RTL and back again >> is possible within a

Re: [Python-ideas] Fwd: Add Unicode-aware str.reverse() function?

Please involve those with more knowledge on the subject. Thanks. On Saturday, 8 September 2018 13:13:05 UTC+1, Jonathan Fine wrote: > > Paddy wrote > > > I would like to propose that Python add a Unicode-aware str.reverse > method. > > The problem is, I'm a Brit, who only speaks English and only

Re: [Python-ideas] Keyword only argument on function call

I agree that this is a familiar pattern, but I long since forgot the specifics of the domain it happens in.  I borrowed your code, and added filename tracking to see what source files had high `could_have_been_a_matched_kwarg`.  Here is the top one:

Re: [Python-ideas] Add Unicode-aware str.reverse() function?

Thanks for your replies. After reading them,, although I seem to have a brain freeze at the moment and cannot think of an algorithm; I think it plausible, just in the ASCII world for someone to want to iterate through characters in a string in reverse order - maybe to zip with another

Re: [Python-ideas] Keyword only argument on function call

> > I disagree. Those are examples of people being used to *positional > arguments* and this expecting that order to carry over. I don’t think > that’s a good argument because it presupposes that a habit of positional > arguments is good. > If 99% of existing code uses: pd.read_csv(fname,

Re: [Python-ideas] Fwd: Add Unicode-aware str.reverse() function?

On Sun, Sep 9, 2018 at 6:55 AM, Jonathan Fine wrote: > Chris Angelico wrote: > >> Improving a rendering engine or console so it's capable of correct RTL >> display is outside the scope of Python code, generally. > > I agree with you, generally. > > But there are over 600 million people who speak

Re: [Python-ideas] Keyword only argument on function call

> > def foo(): > a, b, c = 1, 2, 3 > function(a=77, **use('b d')) > > foo() > You get the output “77 None 33 None”. So basically it doesn’t work at all. > For the reason I wrote clearly in my last mail. You have to dig through the > stack frames to make use() work. > OK, you are right.

Re: [Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

> > It’s obvious but there is one easy way to shorten the code: using > **kwargs. It’s way shorter but the down sides are: - the “real” function signature gets hidden so IDEs for example won’t pick > it up > - the error when you make a mistake when calling is not in your code > anymore but one

Re: [Python-ideas] Keyword only argument on function call

On Sat, Sep 08, 2018 at 09:54:59PM +0200, Anders Hovmöller wrote: [...] [Steven (me)] > > If we believe that this consistency is desirable then maybe this would > > be a good thing. Linters could warn when you use "name=spam" instead of > > "*, name"; style guides can demand that code always

Re: [Python-ideas] Keyword only argument on function call

The proposal is to eliminate the redundancy of writing name=name repeatedly. But IMHO it doesn't do that consistently. That is it allows both forms mixed together, e.g., f(*, a, b, c=x, d, e) I believe this is confusing in part because the * need not be near the arguments it affects. Consider

Re: [Python-ideas] Pre-conditions and post-conditions

Isn't the purpose of "assert" to be able to do design by contract ? assert test, "error message is the test fail" I mean, you just write your test, dev get a feedback on problems, and prod can remove all assert using -o. What more do you need ? Le 15/08/2018 à 23:06, Marko Ristin-Kaufmann

Re: [Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

>get_permissions(item, request, obj) > > and then simply write > >** get_permissions(item, request, obj) > > in the function call, to pass the permissions to the called function. > By the way, for ease of use this is relying on > >https://www.python.org/dev/peps/pep-0448/ #

Re: [Python-ideas] Fwd: Add Unicode-aware str.reverse() function?

Chris Angelico wrote: > Generally, problems with RTL text are *display* problems, and are not > solved by reversing strings. I very much agree with this statement, with one exception. If you wish to display RTL text on a LTR display, then a suitable reversing of strings is probably part of the

Re: [Python-ideas] Fwd: Add Unicode-aware str.reverse() function?

Stephan Houben wrote: To be honest, quite apart from the Unicode issue, I never had a need to reverse a string in real code. Yeah, seems to me it would only be useful if you were working on some kind of word game such as a palindrome generator, or if your string represents something other than

Re: [Python-ideas] Keyword only argument on function call

On Sat, Sep 08, 2018 at 12:05:33PM +0100, Jonathan Fine wrote: > Steve wrote: > > > With the usual disclaimer that I understand it will never be manditory > > to use this syntax, nevertheless I can see it leading to the "foolish > > consistency" quote from PEP 8. > > > "We have syntax to

Re: [Python-ideas] Add Unicode-aware str.reverse() function?

On Sat, Sep 08, 2018 at 04:33:07AM -0700, Paddy3118 wrote: > I wrote a blog post > nearly > > a decade ago on extending a Rosetta Code task example > to handle the correct >

Re: [Python-ideas] Keyword only argument on function call

> You have carefully avoided explicitly accusing me of making a straw man > argument while nevertheless making a completely irrelevant mention of > it, associating me with the fallacy. I read that as him accusing you very directly. > That is not part of an honest or open discussion. > >

Re: [Python-ideas] Keyword only argument on function call

Steve wrote: > With the usual disclaimer that I understand it will never be manditory > to use this syntax, nevertheless I can see it leading to the "foolish > consistency" quote from PEP 8. > "We have syntax to write shorter code, shorter code is better, > so if we want to be Pythonic

[Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

I thank Steve D'Aprano for pointing me to this real-life (although perhaps extreme) code example https://github.com/Tinche/aiofiles/blob/master/aiofiles/threadpool/__init__.py#L17-L37 def open(file, mode='r', buffering=-1, encoding=None, errors=None, newline=None, closefd=True,

[Python-ideas] Add Unicode-aware str.reverse() function?

I wrote a blog post nearly a decade ago on extending a Rosetta Code task example to handle the correct reversal of strings with combining characters. On checking my blog

[Python-ideas] Fwd: Add Unicode-aware str.reverse() function?

Paddy wrote > I would like to propose that Python add a Unicode-aware str.reverse method. > The problem is, I'm a Brit, who only speaks English and only very rarely > dips into Unicode. I don't know how useful this would be! Excellent post and piece of work. Well done! Here's someone who might

[Python-ideas] Fwd: Add Unicode-aware str.reverse() function?

Op za 8 sep. 2018 13:33 schreef Paddy3118 : > > I would like to propose that Python add a Unicode-aware *str.reverse *method. > The problem is, I'm a Brit, who only speaks English and only very rarely > dips into Unicode.* I don't know how useful this would be!* > To be honest, quite apart from

Re: [Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

It’s obvious but there is one easy way to shorten the code: using **kwargs. It’s way shorter but the down sides are: - the “real” function signature gets hidden so IDEs for example won’t pick it up - the error when you make a mistake when calling is not in your code anymore but one level down.

Re: [Python-ideas] Keyword only argument on function call

> To me, the "30% of all arguments" deserves more careful examination. > Does the proposal significant improve the reading and writing of this > code? And are there other, perhaps better, ways of improving this > code? Maybe my tool should be expanded to produce more nuanced data? Like how many

Re: [Python-ideas] Keyword only argument on function call

A finer grained analysis tool would be helpful. I'm -0 on the idea because I believe it would discourage more expressive names in calling contexts in order to enable the proposed syntax. But I also see a big difference between cases where all keywords match calling names and cases where only a few

Re: [Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

On Sat, Sep 8, 2018 at 10:21 PM, Anders Hovmöller wrote: > It’s obvious but there is one easy way to shorten the code: using **kwargs. > It’s way shorter but the down sides are: > > - the “real” function signature gets hidden so IDEs for example won’t pick it > up > - the error when you make a

Re: [Python-ideas] Keyword only argument on function call

On Fri, Sep 07, 2018 at 06:59:45AM -0700, Anders Hovmöller wrote: > Personally I think readability suffers greatly already at two arguments if > none of the parameters are named. *At* two arguments? As in this example? map(len, sequence) I'll admit that I struggle to remember the calling

Re: [Python-ideas] Keyword only argument on function call

On Fri, Sep 07, 2018 at 10:39:07AM +1200, Greg Ewing wrote: > As for whether consistent naming is a good idea, seems to > me it's the obvious thing to do when e.g. you're overriding > a method, to keep the signature the same for people who want > to pass arguments by keyword. You'd need to have a

Re: [Python-ideas] Keyword only argument on function call

> *At* two arguments? As in this example? > >map(len, sequence) > > > I'll admit that I struggle to remember the calling order of list.insert, > I never know which of these I ought to write: > >mylist.insert(0, 1) >mylist.insert(1, 0) > > but *in general* I don't think two

Re: [Python-ideas] Fwd: Add Unicode-aware str.reverse() function?

Stephan Houben wrote: > To be honest, quite apart from the Unicode issue, I never had a need to > reverse a string in real code. > > .ytilibigel edepmi ot sdnet yllareneg tI Sometimes we have to write 'backwards' to improve legibility. Odd though that may sound. Some languages are written from

Re: [Python-ideas] Add Unicode-aware str.reverse() function?

On 08.09.2018 13:33, Paddy3118 wrote: > I wrote a blog post > nearly > a decade ago on extending a Rosetta Code task example > to handle the correct > reversal of strings with

Re: [Python-ideas] Fwd: Add Unicode-aware str.reverse() function?

On 08.09.2018 15:00, Jonathan Fine wrote: > Stephan Houben wrote: > >> To be honest, quite apart from the Unicode issue, I never had a need to >> reverse a string in real code. >> >> .ytilibigel edepmi ot sdnet yllareneg tI > > Sometimes we have to write 'backwards' to improve legibility. Odd >

Re: [Python-ideas] Keyword only argument on function call

> A finer grained analysis tool would be helpful. I'm -0 on the idea because I > believe it would discourage more expressive names in calling contexts in > order to enable the proposed syntax. But I also see a big difference between > cases where all keywords match calling names and cases

Re: [Python-ideas] Add Unicode-aware str.reverse() function?

On 9/8/2018 7:33 AM, Paddy3118 wrote: I wrote a blog post nearly a decade ago on extending a Rosetta Code task example to handle the correct reversal of strings with

Re: [Python-ideas] Fwd: Add Unicode-aware str.reverse() function?

M.-A. Lemburg wrote: > Most likely yes, but they would not render RTL text by first > switching the direction and then printing them LTR again. > > Please also note that switching from LTR to RTL and back again > is possible within a Unicode string, so applying str.reverse() > would actually make

Re: [Python-ideas] Add Unicode-aware str.reverse() function?

Terry Ready wrote: > A python string is a sequence of unicode codepoints. String methods operate > on the string as such. We intentionally leave higher level methods to third > parties. One reason is the problem of getting such things 'right' for all > strings. What do we do with a leading

Re: [Python-ideas] Improving fn(arg=arg, name=name, wibble=wibble) code

On 9/8/2018 7:17 AM, Jonathan Fine wrote: I thank Steve D'Aprano for pointing me to this real-life (although perhaps extreme) code example https://github.com/Tinche/aiofiles/blob/master/aiofiles/threadpool/__init__.py#L17-L37 def open(file, mode='r', buffering=-1, encoding=None, errors=None,

Re: [Python-ideas] Keyword only argument on function call

On Sat, Sep 8, 2018 at 9:34 AM Anders Hovmöller wrote: > function(a=my_a, c=my_c, *, b, d) > function(*, b, c, d, a=my_a, c=my_c) > Yes, those look less bad. They are also almost certainly should get this message rather than working: TypeError: function() got multiple values for

Re: [Python-ideas] Keyword only argument on function call

I'm not sure whether my toy function is better to assume None for a name that is "used" but does not exist, or to raise a NameError. I can see arguments in both directions, but either behavior is a very small number of lines (and the same decision exists for the proposed syntax). You might also

Re: [Python-ideas] Keyword only argument on function call

On Sat, Sep 8, 2018, 6:34 AM Anders Hovmöller wrote: > > A finer grained analysis tool would be helpful. I'm -0 on the idea > because I believe it would discourage more expressive names in calling > contexts in order to enable the proposed syntax. But I also see a big > difference between cases

Re: [Python-ideas] Does jargon make learning more difficult?

o/ > IMHO a better usage of the PSF funding would be to organize some local > sprints to translate the Python documentation. That's what we're already doing here in France for the french translation, and the PSF is already fouding them (thanks!) in Paris [1] and the AFPy [2] is founding them