Re: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions

On Tue, Feb 19, 2019 at 3:19 PM Steven D'Aprano wrote: > And I note that in Java, where the idea of checked exceptions > originated, it turned out to be full of problems and a very bad idea. What should be the default behavior of a language when the programmer doesn't explicitly handle an error?

Re: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions

On Wed, Feb 20, 2019 at 9:09 PM Ben Rudiak-Gould wrote: > That problem, of an inadvertently leaked implementation detail > masquerading as a proper alternate return value, used to be a huge > issue with StopIteration, causing bugs that were very hard to track > down, until PEP 479 fixed it by tran

Re: [Python-ideas] About PEP-582

On Wed, Feb 20, 2019 at 4:49 AM Brett Cannon wrote: > On Tue, Feb 19, 2019 at 3:29 PM Philip Bergen via Python-ideas < > python-ideas@python.org> wrote: > >> First attempt at this, so please be gentle. :) >> I am very interested in the overall goal of not needing virtualenvs, but >> I'm curious a

Re: [Python-ideas] add fluent operator to everything

On 2/20/19 1:58 AM, Jimmy Girardet wrote: You're right on it. The str class is a  straightforward swiss army knife with methods you can chain. list or dict do not fit this idea. Python strings are immutable. Python lists and dicts are not. Both classes are straightforward. __

Re: [Python-ideas] add fluent operator to everything

On Tue, Feb 19, 2019 at 01:52:34PM -0800, Brett Cannon wrote: > On Tue, Feb 19, 2019 at 6:23 AM Jimmy Girardet wrote: [...] > > I would be happy to have > > > > >>> [1,2,3].append(4)::sort()::max() +1 > > > > It makes things very easy to read: first create list, then append 4, > > then sort, then

Re: [Python-ideas] add fluent operator to everything

On 2/20/19 9:10 AM, Steven D'Aprano wrote: > That's possibly a matter of familiarity. I'd be very surprised if you > preferred this: > > mystr = mystr.strip() > mystr = mystr.expandtabs() > mystr = mystr.lower() > mystr = mystr.replace('ham', 'spam') > result = function(m

Re: [Python-ideas] add fluent operator to everything

Here's a syntax that solves this using the new operators _:= and ,_ a = [1,2,3] (_:=a,_.append(4),_.sort()) Personally, I find this a bit harder to read on one line and would break it up like this: (_:=a ,_ .append(4) ,_ ..sort() ) --- Bruce _

Re: [Python-ideas] add fluent operator to everything

There's a problem with introducing ,_ as a new operator. $ python3.6 Python 3.6.2 (default, Jul 29 2017, 00:00:00) [GCC 4.8.4] on linux Type "help", "copyright", "credits" or "license" for more information. >>> 2 + 2 4 >>> 4 ,_ + 6 (4, 10) Hint: >>> _ (4, 10) >>> 3 ,_ (3, (4, 10)) -- Jonathan _

Re: [Python-ideas] add fluent operator to everything

On Wed, Feb 20, 2019 at 10:34 AM Jonathan Fine wrote: > There's a problem with introducing ,_ as a new operator. > I should have put "new" in scare quotes to be more clear as it's not really new. As you've observed this is already implemented. For it to work as in my example you also need to use

Re: [Python-ideas] add fluent operator to everything

I think this >>> a = [1,2,3] >>> _ = a >>> ( _ .append(4), _ .sort()) (None, None) is clearer than a = [1,2,3] (_:=a,_.append(4),_.sort()) And it works in every version of Python3 (and Python2 I expect). -- Jonathan _

Re: [Python-ideas] add fluent operator to everything

On 20/02/2019 18:24, Bruce Leban wrote: Here's a syntax that solves this using the new operators _:= and ,_ a = [1,2,3] (_:=a,_.append(4),_.sort()) I'm not sure what problem you are solving here, but if that's the solution I'd rather have the problem. There is ab

Re: [Python-ideas] add fluent operator to everything

On Wed, Feb 20, 2019 at 11:03 AM Rhodri James wrote: > On 20/02/2019 18:24, Bruce Leban wrote: > > a = [1,2,3] > > (_:=a,_.append(4),_.sort()) > > I'm not sure what problem you are solving here, but if that's the > solution I'd rather have the problem. There is absolu

Re: [Python-ideas] PEP 8 update on line length

I wrote: def resolve_annotations(raw_annotations: Dict[str, AnyType], module_name: Optional[str]) -> Dict[str, AnyType]: pass After using https://black.now.sh/ def resolve_annotations( raw_annotations: Dic

Re: [Python-ideas] PEP 8 update on line length

Steven D'Aprano wrote: > > I wasn't making a point. I was providing evidence. > > Evidence of what? > > What was the point of this evidence? > > If it was to demonstrate that it is possible to reformat function > parameter lists to split over multiple lines, we already knew that. > > If it was to

Re: [Python-ideas] PEP 8 update on line length

On Thu, Feb 21, 2019 at 6:48 AM Jonathan Fine wrote: > Here's a suggestion, at least for people projects that use black.py > (such as Samuel's). It is to use black.py with a line-length of say 80 > characters for code that is saved in version control. And when editing > code, use whatever line-len

Re: [Python-ideas] PEP 8 update on line length

Opinion first - I don't see a need to change PEP 8. I recommend 100 char width for Python, which is acceptable under PEP 8 anyway. I think the real limit should be around 70 characters per line, not including leading white-space, but I realize that's impractical. I work mostly at 100 character lin

Re: [Python-ideas] PEP 8 update on line length

[Samuel Colvin] > > I don't see how anyone can say that would be more readable with a 80 > character line limit. For starters, type annotations don't add anything that good documentation would have required before. In most docstring style guides that I know of, the arguments list is supposed to b

Re: [Python-ideas] PEP 8 update on line length

Thankfully, style guidelines are based upon the limitations of humans like the size of the fovea and the general ability for people to follow long lines, NOT on the limitations of tools like grep. On Tue, Feb 19, 2019 at 10:29 AM Anders Hovmöller wrote: > > If it were me, I'd probably write (or

Re: [Python-ideas] PEP 8 update on line length

[simon.bordeyne] > I find that 100 to 120 characters is ideal as far as line length goes. Your finding goes against a long history of people attempting to present text in the most readable way possible. AFIK, the human fovea hasn't grown much larger in recent years. [simon.bordeyne] > On top o

Re: [Python-ideas] PEP 8 update on line length

On Thu, Feb 21, 2019 at 11:09 AM Abe Dillon wrote: > > [simon.bordeyne] >> >> I find that 100 to 120 characters is ideal as far as line length goes. > > Your finding goes against a long history of people attempting to present text > in the most readable way possible. > AFIK, the human fovea hasn'

Re: [Python-ideas] PEP 8 update on line length

First of all, thank you so much for taking the time to do some actual analysis! I only have one thing to add: [Paul Ferrell] > 3 - function calls > Function calls, even with the arguments put one per line, often exceed 80 > (and sometimes 100) character limit. The issue tends to be a combination

Re: [Python-ideas] PEP 8 update on line length

On Wed, Feb 20, 2019 at 07:53:21PM +, Jonathan Fine wrote: > Steven D'Aprano wrote: > > > > I wasn't making a point. I was providing evidence. > > > > Evidence of what? > > > > What was the point of this evidence? > > > > If it was to demonstrate that it is possible to reformat function > > pa

Re: [Python-ideas] PEP 8 update on line length

[Chris Angelico] > > And this is always cited as the "obvious" solution. Yes. I think simon even referred to this "obvious" solution in his post when he said, "...which is a very common ocurence, *and doesn't warrant refactoring*" So, my comment may have been unwarranted. [Chris Angelico] > The

Re: [Python-ideas] PEP 8 update on line length

On Thu, Feb 21, 2019 at 12:26 PM Abe Dillon wrote: > You don't need to know EVERYTHING about how block_fork works to debug that > failure. You > probably don't need to know EVERYTHING about how random.choice works either. > You don't > need to know about how most of the functions in the code wor

Re: [Python-ideas] add fluent operator to everything

TL;DR: When talking about all this, there are two distictions that should be considered: mutating operations vs copying operations functions vs methods. This has a lot of impact on the design, and it's very important that any final syntax makes these distinctions clear. On Wed, Feb 20, 2019 at

Re: [Python-ideas] add fluent operator to everything

On Wed, Feb 20, 2019 at 10:24:25AM -0800, Bruce Leban wrote: > Here's a syntax that solves this using the new operators _:= and ,_ Be careful about making such dogmatic statements. Language design is not a matter of picking random syntax and claiming that it solves the problem -- especially whe

Re: [Python-ideas] PEP 8 update on line length

[Chris Angelico] > Not about HOW it works. That's irrelevant. You DO need to know about > what it does, which is what I said. So it is. I'm sorry I misread your comment. [Chris Angelico] > In the case of random.choice, that's very clearly defined by its > documentation: it chooses a random > e

Re: [Python-ideas] PEP 8 update on line length

Most of this thread is all just so much opinion, so I have avoided chiming in -- but as for opinion: A better way to list arguments is only one indentation level above the > current: > > variable = some_class.method( > argument=value, > argument2=value) > God no! I HATE that style -- fo

Re: [Python-ideas] add fluent operator to everything

On Thu, Feb 21, 2019 at 12:55:00PM +1100, Steven D'Aprano wrote: > On Wed, Feb 20, 2019 at 10:24:25AM -0800, Bruce Leban wrote: > > > Here's a syntax that solves this using the new operators _:= and ,_ > > Be careful about making such dogmatic statements. Ah, I have just spotted your later expla

Re: [Python-ideas] add fluent operator to everything

On 2/20/19 7:46 PM, Christopher Barker wrote: > mutating operations vs copying operations > > functions vs methods. > > This has a lot of impact on the design, and it's very important that > any final syntax makes these distinctions clear. Absolutely. > On Wed, Feb 20, 2019 at 8:33 AM Dan Somme

Re: [Python-ideas] PEP 8 update on line length

[Christopher Barker] > God no! I HATE that style -- for me, it makes it MUCH harder to read -- > even more so if the variable names are a bit longer. > But if you are going to do it, for the love of god, use more than four > spaces! four spaces is one indentation, one indentation is how a code blo

Re: [Python-ideas] PEP 8 update on line length

On 2019-02-20 18:41, Christopher Barker wrote: God no! I HATE that style -- for me, it makes it MUCH harder to read -- even more so if the variable names are a bit longer. But if you are going to do it, for the love of god, use more than four spaces! four spaces is one indentation, one indentati

Re: [Python-ideas] PEP 8 update on line length

Abe Dillon writes: > A better way to list arguments is only one indentation level above the > current: > > variable = some_class.method( > argument=value, > argument2=value) > > Trying to match the indentation of the opening line is less readable and > less robust to refactoring: > > vari

Re: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions

On Wed, Feb 20, 2019 at 2:43 AM Chris Angelico wrote: > That's because a generator function conceptually has three ways to > provide data (yield, return, and raise), but mechanically, one of them > is implemented over the other ("return" is "raise StopIteration with a > value"). For other raised e

Re: [Python-ideas] PEP 8 update on line length

On Wed, Feb 20, 2019 at 10:57 PM Abe Dillon wrote: > I wish you would have watched the video I linked > > that is an hour and 7 minute video! And I did watch some of it, and do agree with much of it. By the way, everyone should watch one of