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

Hi, thank for the replies. I searched on python-idea as Chris proposed me with "chain" and I've found 2 relevant discussions : * A  proposal from Cris Angelico ;-) https://mail.python.org/pipermail/python-ideas/2014-February/026079.html """Right. That's the main point behind this: it gives the

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

Chris Angelico wrote: if I'd been able to ascertain which functions were pure, or at least side-effect-free, it would have saved me a lot of hassle.) I'm not sure how useful such annotations would be in practice, though. They're only as good as the diligence of the author in using them

Re: [Python-ideas] About PEP-582

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 about the motivations behind pep-582. > In a word,

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

Brett Cannon writes: > 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 get the max. (Responding to the OP)

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

On Wed, Feb 20, 2019 at 11:19 AM Steven D'Aprano wrote: > > On Wed, Feb 20, 2019 at 01:41:27AM +1100, Chris Angelico wrote: > > > page_count will usually be unambiguous. You might need total_pages to > > mean "not the current section", thus leaving the shorter one available > > for the narrower

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

On Wed, Feb 20, 2019 at 01:41:27AM +1100, Chris Angelico wrote: > page_count will usually be unambiguous. You might need total_pages to > mean "not the current section", thus leaving the shorter one available > for the narrower use. Obviously questions like this can't be answered > without

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

On Tue, Feb 19, 2019 at 11:38:04AM +0100, Nicolas Rolin wrote: > I understand that the writer wants to have shorter names, but why would I > want more ambigious names as a reader ? > How would you rename number_of_pages_in_current_section such that the > reader is not left wondering what does

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

On Tue, Feb 19, 2019 at 05:29:33PM +, Jonathan Fine wrote: > Previously, Samuel wrote that he would leave the conversation, because > it was primarily opinion based, which he finds annoying. > > I then provided evidence (namely how black.py reformats a specific > code example). > > Samuel

[Python-ideas] About PEP-582

First attempt at this, so please be gentle. :) I am very interested in the overall goal of not needing virtualenvs, but I'm curious about the motivations behind pep-582. Could someone help me understand if this has previously been discussed and in that case why it was decided against? 1: Why only

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

On Wed, Feb 20, 2019 at 10:18 AM Steven D'Aprano wrote: > So the promises made will nearly always be incredibly weak: > > - raises(A) means "may raise A, or any other unexpected exception" > - sideeffects(True) means "may have expected side-effects" > - sideeffects(False) means "may have

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

On Tue, Feb 19, 2019 at 11:05:55PM +0200, Miikka Salminen wrote: > Hi! > > To help automatic document generators and static type checkers reason more > about the code, the possible side-effects and raised exceptions could also > be annotated in a standardized way. This is Python. Nearly

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

On Tue, Feb 19, 2019 at 02:13:24PM +, Paul Moore wrote: > Any linter or project that treats PEP 8 as mandatory has *already* > failed, as PEP 8 itself states that the rules can be broken as needed. > Of course individual projects are entirely allowed to impose whatever > draconian and

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

Heyy, it's funcoperators idea ! >>> [1,2,3].append(4)::sort()::max() +1 [1, 2, 3] |append(4) |to(sorted) |to(max) |to(plus1) You just have to : pip install funcoperators from funcoperators import postfix as to plus1 = postfix(lambda x: x+1) from funcoperators import postfix def append(x):

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

On Tue, Feb 19, 2019 at 6:23 AM Jimmy Girardet wrote: > Hi, > > There was the discussion about vector, etc... > > I think I have a frustration about chaining things easily in python in > the stdlib where many libs like orm do it great. > > Here an example : > > The code is useless, just to show

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

Samuel Colvin wrote: I just think that code with a 7 line function header is much harder to read and understand than code with a one line function header. But to me, a one-line function header that contains 7 lines worth of charaacters is *less* readable than a 7-line header, as long as it's

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

Samuel Colvin wrote: def resolve_annotations(*, raw_annotations: Dict[str, Type[Any]], module_name: Optional[str]) -> Dict[str, Type[Any]]: I don't see how anyone can say that would be more readable with a 80 character line limit. I would argue that it *is* more readable if it's not all on

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

Hi! To help automatic document generators and static type checkers reason more about the code, the possible side-effects and raised exceptions could also be annotated in a standardized way. I'll let some example code talk on my behalf. Here's a simple decorator for annotating exceptions: In

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

>> Maybe you know some grep magic I don't? Is there a way to do multi line grep >> that knows that open paren means to ignore new lines until the matching >> close paren? I'd love to hear about it! > > I probably don't know any more grep magic than you, I've just never had cause > to grep

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

Previously, Samuel wrote that he would leave the conversation, because it was primarily opinion based, which he finds annoying. I then provided evidence (namely how black.py reformats a specific code example). Samuel then wrote: > I'm afraid I'm not sure of your point here. I wasn't making a

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

On 2/19/19 11:06 AM, Anders Hovmöller wrote: > Maybe you know some grep magic I don't? Is there a way to> do multi > line grep that knows that open paren means to ignore new lines until > the matching close paren? I'd love to hear about it! At the risk of jumping in over my head with respect to

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

On 19.02.2019 18:06, Anders Hovmöller wrote: > > >> On 19 Feb 2019, at 17:36, Rhodri James wrote: >> >> On 19/02/2019 16:26, Anders Hovmöller wrote: If it were me, I'd probably write (or would have re-written when I added the type hints) that as follows: def

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

On 19/02/2019 17:06, Anders Hovmöller wrote: On 19 Feb 2019, at 17:36, Rhodri James wrote: On 19/02/2019 16:26, Anders Hovmöller wrote: If it were me, I'd probably write (or would have re-written when I added the type hints) that as follows: def resolve_annotations( *,

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

> On 19 Feb 2019, at 17:36, Rhodri James wrote: > > On 19/02/2019 16:26, Anders Hovmöller wrote: >>> If it were me, I'd probably write (or would have re-written when I added >>> the type hints) that as follows: >>> >>>def resolve_annotations( >>>*, >>>

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

On 19/02/2019 16:26, Anders Hovmöller wrote: If it were me, I'd probably write (or would have re-written when I added the type hints) that as follows: def resolve_annotations( *, raw_annotations: Dict[str, Type[Any]], module_name: Optional[str]

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

> If it were me, I'd probably write (or would have re-written when I added > the type hints) that as follows: > >def resolve_annotations( >*, >raw_annotations: Dict[str, Type[Any]], >module_name: Optional[str] >) -> Dict[str, Type[Any]]: I would

Re: [Python-ideas] Support localization of unicode descriptions

On 7/11/18 1:14 AM, Terry Reedy wrote: > On 7/10/2018 5:20 PM, David Mertz wrote: >> The problem with non-canonical translations of the Unicode character >> names is that there is not one unique possible rendering into >> language X. Equally, I could find synonyms in general English for the >>

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

I'm afraid I'm not sure of your point here. (By the way, that code is already run through black, just with a line length limit of 120) ___ Python-ideas mailing list

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

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: Dict[str,

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

> Nothing says that you have to write an entire function header on one line. Of course. I just think that code with a 7 line function header is much harder to read and understand than code with a one line function header. For example: it's less likely that two chunks of code I'm looking at are

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

On 2/19/19 8:28 AM, Samuel Colvin wrote: > Let's take a real life example from here > > (changed very slightly for this example), in tranitional python the > signature might be: > > def

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

On Wed, Feb 20, 2019 at 1:22 AM Jimmy Girardet wrote: > >>> a = [1,2,3] > >>> a.append(4) > >>> a.sort() > >>> c = max(a) + 1 > > 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 get the

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

I would suggest a small improvement: allow a trailing :: which is useful for when the last function does not return anything. So for example this [1,2,3].append(4)::sort() will evaluate to None, but [1,2,3].append(4)::sort():: would evaluate to the list. > On 19 Feb 2019, at 15:13, Jimmy

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

On Tue, Feb 19, 2019 at 9:38 PM Nicolas Rolin wrote: > I understand that the writer wants to have shorter names, but why would I > want more ambigious names as a reader ? > How would you rename number_of_pages_in_current_section such that the reader > is not left wondering what does this

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

Wow... Sorry about all my typos from autocorrect. I should not write a longish reply on my tablet, or should proofread and correct. On Tue, Feb 19, 2019, 9:30 AM David Mertz On Tue, Feb 19, 2019, 9:07 AM simon.bordeyne wrote: > >> I find that 100 to 120 characters is ideal as far as line length

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

On Tue, Feb 19, 2019, 9:07 AM simon.bordeyne I find that 100 to 120 characters is ideal as far as line length goes. > I very much hope no one else where had to read it review your code. In my opinion, splitting lines is much worse in terms of cognitive burden > than just a longer line. On top

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

I too would argue that it's time to reconsider line length limits. But the reason is not monitor changes, or any particularly strong personal opinion, but changes to python: Let's take a real life example from here

[Python-ideas] add fluent operator to everything

Hi, There was the discussion about vector, etc... I think I have a frustration about chaining things easily in python in the stdlib where many libs like orm  do it great. Here an example : The code is useless, just to show the idea >>> a = [1,2,3] >>> a.append(4) >>> a.sort() >>> c =

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

On Tue, Feb 19, 2019 at 3:07 PM simon.bordeyne wrote: > A good middle ground would be to enforce customization of that rule in the > most used python linters. A simple setting to set the number of characters > before a linting warning occurs would be acceptable. > Major linters already support

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

On Tue, 19 Feb 2019 at 14:08, simon.bordeyne wrote: > A good middle ground would be to enforce customization of that rule in the > most used python linters. A simple setting to set the number of characters > before a linting warning occurs would be acceptable. Any linter or project that

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

I find that 100 to 120 characters is ideal as far as line length goes. In my opinion, splitting lines is much worse in terms of cognitive burden than just a longer line. On top of that, it's not uncommon to reach 6, even 7 indentation levels. All it takes is a loop in a loop (looping through an

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

My two cents, because this is a subject about which I have a strong opinion: - Yes, VT100s and other green screen terminals have long since been out of fashion, but there are still some people, including myself, who like their xterms and iTerms in the standard size (80x24). Also, we sometime need

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

I don't think you will find an agreement to raise the number of line length (we didn't even manage to find an agreement at my job with less than 10 people), so I would suggest every reader not interested in the disscussion to put it into the bin directly, as no decision will emerge from here.

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

On Tue, Feb 19, 2019 at 05:37:29AM +0100, Simon wrote: > Hello, > > I'd like to propose an update to PEP8. Indeed, the 80 characters per line > guideline is, I feel, outdated. I know this is not precisely what you are arguing, but the thought of people arguing that the only problem with a

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

On 19Feb2019 00:09, Terry Reedy wrote: On 2/18/2019 11:37 PM, Simon wrote: I'd like to propose an update to PEP8. Indeed, the 80 characters per line guideline is, I feel, outdated. I understand the need for it, back when monitors were small, and everyone coded on terminals, but nowadays, I