Re: [Python-ideas] PEP 8 update on line length
I agree that 80 columns produces too much artificial wrapping that is not
more readable and harder to maintain. To that point see the bug in Chris
Barker's email :)
raise ValueError(f"Expected woozle to be between"
"{self.min_woozle} and {self.max_woozle}")
The missing f prefix on the second row is hard to spot.
In my work we have settled on 100 characters. It's below the practical
limitation where code review tools such as github pull request falls apart
and still easily allows side by side editing.
On Thu, Feb 21, 2019 at 3:20 PM wrote:
> Send Python-ideas mailing list submissions to
> python-ideas@python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.python.org/mailman/listinfo/python-ideas
> or, via email, send a message with subject or body 'help' to
> python-ideas-requ...@python.org
>
> You can reach the person managing the list at
> python-ideas-ow...@python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Python-ideas digest..."
> Today's Topics:
>
>1. Re: PEP 8 update on line length (pylang)
>2. Re: PEP 8 update on line length (Chris Barker)
>3. Re: Type hints for functions with side-effects and for
> functions raising exceptions (Juancarlo A?ez)
>
>
>
> -- Forwarded message --
> From: pylang
> To: Mike Miller
> Cc: "python-ideas@python.org"
> Bcc:
> Date: Thu, 21 Feb 2019 17:32:12 -0500
> Subject: Re: [Python-ideas] PEP 8 update on line length
> Some feedback:
>
> I code on a 13.5 inch laptop. I split my screen between my browser on the
> left half and editor on the right half of the screen.
> The 80 character suggestion has been helpful to me in reading code.
> Otherwise I'd use up time with random horizontal scrolling.
>
> On Thu, Feb 21, 2019 at 4:11 PM Mike Miller
> wrote:
>
>>
>> On 2/21/19 10:53 AM, Paul Ferrell wrote:
>> > I think the solution is for everyone to rotate their widescreen
>> monitors 90°
>> > into a really tall portrait mode. :)
>>
>> Yep, that's what I do, but would prefer a squarer monitor so I could get
>> two
>> windows side by side on that one also. My old 1600x1200 4:3 in portrait
>> allowed
>> that comfortably. 16:10 might.
>>
>> -Mike
>>
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
>
> -- Forwarded message --
> From: Chris Barker
> To: Python-Ideas
> Cc:
> Bcc:
> Date: Thu, 21 Feb 2019 17:06:51 -0800
> Subject: Re: [Python-ideas] PEP 8 update on line length
> On Thu, Feb 21, 2019 at 12:01 PM Raymond Hettinger <
> raymond.hettin...@gmail.com> wrote:
>
>> I concur. We now put expressions in f-strings and have assignment
>> expressions that easily spill over 80 characters if one uses all but the
>> most compact variable names. Comprehensions tend to make expressions
>> longer. Queries and filters in Pandas also easily spill over. The 80
>> character limit pre-dates these evolutions of the language.
>>
>
>
>> In particular, the case where I most want to let people run with long
>> lines is in forming messages to be displayed to a user.
>
>
> I agree here -- and if it's messages (also comments - a twenty char
> comment after a 70 char line should be fine!) then it's not part of the
> logic of the code -- so not as bd if there is some spill off the screen for
> those folks that do code on tablets ;-) Actually for me, the issue s comes
> up when I'm showing code on a projector -- I use a huge font so folks in
> the back can see)
>
>
>> class Frabawidget:
>> ...
>> @wozzle.setter
>> def (self, woozle):
>> if not (self.min_woozle < woozle < self.max_woozle):
>> raise ValueError(f"Expected woozle to be between
>> {self.min_woozle} and {self.max_woozle}")
>> self._wozzle = normalize(woozle)
>>
>
> That's 103 chars long -- and very readable. But, is this that much worse?
>
> class Frabawidget:
> ...
> @wozzle.setter
> def (self, woozle):
> if not (self.min_woozle < woozle < self.max_woozle):
> raise ValueError(f"Expected woozle to be between"
> "{self.min_woozle} and {self.max_woozle}")
> self._wozzle = normalize(woozle)
>
> (it IS harder to write, that's for sure)
>
> In doing code reviews, I see many fewer atrocities from long lines than I
>> do from weird line-wraps and from variable names that have been
>> over-shortened to make the line fit in 80 characters. To avoid these
>> issues, my clients typically set their line limits at 90 or 100
>
>
> and yet the above example was 103 ... you do need a limit somewhere.
>
> I actually would really like the "limit" to depend on what the line is --
> that is, it's OK to go longer if it's essentially text -- message to
Re: [Python-ideas] PEP 8 update on line length
> On Feb 21, 2019, at 5:06 PM, Chris Barker via Python-ideas
> wrote:
>
>
> class Frabawidget:
> ...
> @wozzle.setter
> def (self, woozle):
> if not (self.min_woozle < woozle < self.max_woozle):
> raise ValueError(f"Expected woozle to be between
> {self.min_woozle} and {self.max_woozle}")
> self._wozzle = normalize(woozle)
>
> That's 103 chars long -- and very readable. But, is this that much worse?
>
> class Frabawidget:
> ...
> @wozzle.setter
> def (self, woozle):
> if not (self.min_woozle < woozle < self.max_woozle):
> raise ValueError(f"Expected woozle to be between"
> "{self.min_woozle} and {self.max_woozle}")
> self._wozzle = normalize(woozle)
>
> (it IS harder to write, that's for sure)
Yes, it's worse. You introduced twos bugs. First the space between the two
fragments was lost. Second the f on the second f-string was dropped. I see
these kinds of line-wrapping errors frequently. The bugs are CAUSED by the
line length rule.
Also, in the case of multi-line templates, there is no way to wrap them without
getting very far from WYSIWYG:
def run_diagnostics(location, system, test_engineer):
...
if (failures):
print(dedent(f'''\
There were {num_failures) anomalies detected in the {location}
{system} at {event_time ::%I:%M:%S}}.
These anomalies were classified as {level}. Further action is {''
if escalate else 'not'} recommended.
''')
else:
print(dedent(f'''\
A total of {num_test_cases} diagnostics were run in the {location}
{system} as of {event_time::%I:%M:%S}}.
No anomalies were detected and further action is not required.
Test signed by {test_engineer.title()}.
...
Raymond
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 8 update on line length
On Thu, Feb 21, 2019 at 05:06:51PM -0800, Chris Barker via Python-ideas wrote: > To all the folks quoting theory: let's be honest. Yes, really long lines > are harder to read, but the 80 char limit comes from old terminals, NOT any > analysis that somehow that is optimum for readability. Chris, the convention to limit text to somewhere around 60-80 characters predates old terminals by *literally centuries*. I don't think it's *us* that needs to be told to "be honest". I don't know who first came up with this story that the 79 column limit is all about compatibility with old 80 char terminals, but it's just a story. (And did they ever stop to wonder why those old terminals standardized on 80 columns?) Compatibility with old terminals is "nice to have" if you ever need to ssh into a remote machine via an 80-column machine and edit code (and I know somebody who actually does that!), but that's not the reason why we should keep the 80 column limit as the default. (Many people have already spent a lot of words explaining some of the advantages of an 80 char limit, and I don't intend to go over them again. Go back and read the thread.) I've just grabbed a handful of books at random from my bookcase, and done a quick sample of number of chars per line: 42 letters plus whitespace = 52 characters 28 letters plus whitespace = 34 x 2 columns = 68 63 plus ws = 75 56 plus ws = 67 73 plus ws = 84 59 plus ws = 70 56 plus ws = 67 (another one!) I would be surprised if you found many books that reached 95-100 characters, and shocked if you found any at all that reached 120 characters. Based on this sample, I would say the typical line length for optimal reading of prose is about 60-70 chars. Call it 65. Add four leading idents of four spaces each, and our optimum is about 81 columns. The difference between that and PEP 8's 79 columns is not significant. (I for one would not fail your code in a review merely for reaching 81 or even 82 columns.) Now, it does have to be admitted that prose does not have the same characteristics as source code. Prose tends to have solid paragraphs of the same width, and we typically read large blocks of text in full. Whereas source code tends to have lots of short lines, and a few very long lines. We typically skim most of the text, then focus in tightly to study in detail a small section of the text at a time. And any limit we choose is going to be a compromise between the need to avoid giant one-liners and the nuisance value of splitting a conceptual line of code over multiple physical lines. Being a compromise, there will always be cases where it is sub-optimal. Nevertheless, we can say this about typical Python source code: 1. 79 characters is *very generous* for most lines of code; I did a quick sample of code and found an average of 51 columns including the leading indents. This is, of course, an imperfect and biased sample because long lines have been split to keep the 79 char limit, but even a brief glance at the std lib shows that most lines of code tend to fit within 50-60 characters. 2. When a single line goes beyond 80 columns, it often wants to go a long way beyond. Perl-ish one-liners are merely a extreme case of this. 3. Such long lines are often complex, which makes them hard to read and hard to debug. Opinion: we really shouldn't be encouraging people to write long complex lines of code. If a single line has more than a dozen method calls in it, it might be a tad too complex for one physical line regardless of how wide your monitor is :-) Splitting such complex expressions over multiple lines, or even multiple statements, can have advantages beyond merely keeping to the 79 column limit. It can often result in better code that is easier to understand, debug and maintain. 4. But one notable exception to this is the case where you have a long format string, often passed to "raise Exception", or print. They're rarely complicated or hard to read: at worst, substituting a few variables into a format string. These are often indented four or five levels deep, and they really are a pain-point. They're sometimes hard to split over multiple lines. And not only are they conceptually simple, but we rarely need to read them in detail. Its the surrounding code we need to read closely. (Raymond's post singles these kinds of lines out as especially problematic, and his observations agree with my experience.) Opinion: common sense should prevail here. If you have a line "raise ValueError(...)" which would reach 80 or even 90 characters, don't let PEP 8 alone tell you otherwise. It's just a rule, not a law of physics. We have rules so that you *think before you break them*. But if you have a more substantial code that exceeds 80 columns, that's a code smell and you ought to think long and hard before breaking it. Proposal: - keep PEP 8's current recommendation; - but remind people that the rule can be relaxed for
Re: [Python-ideas] PEP 8 update on line length
On 2/21/19 7:06 PM, Chris Barker via Python-ideas wrote:
> On Thu, Feb 21, 2019 at 12:01 PM Raymond Hettinger
> wrote:
>> class Frabawidget:
>> ...
>> @wozzle.setter
>> def (self, woozle):
>> if not (self.min_woozle < woozle < self.max_woozle):
>> raise ValueError(f"Expected woozle to be between
>> {self.min_woozle} and {self.max_woozle}")
>> self._wozzle = normalize(woozle)
>>
> That's 103 chars long -- and very readable. But, is this that much
> worse?
> class Frabawidget:
> ...
> @wozzle.setter
> def (self, woozle):
> if not (self.min_woozle < woozle < self.max_woozle):
> raise ValueError(f"Expected woozle to be between"
>"{self.min_woozle} and {self.max_woozle}")
> self._wozzle = normalize(woozle)
I remain against longer lines. I break 80 characters extremely rarely,
if ever, and at times start breaking long lines before that. I find
Chris's code more readable.
I'm even more against for backwards incompatibility and hard-to-read
exception messages. ;-)
Chris's code doesn't quite match Raymond's; Chris lost a space between
(ironically) "between" and "{self.min_woozle}."
Dan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions
On Fri, Feb 22, 2019 at 2:27 PM Juancarlo Añez wrote:
> Then, if exceptions are going to be part of a type, there should be a way to
> express the semantics of them (like in Eiffel), so stack.pop();stack.push(x)
> doesn't have to catch StackFullException.
>
That assumes atomicity. If you want an atomic "replace top of stack"
that can never raise StackFullException, it's probably best to express
it as stack.replacetop(x) rather than having something that might be
interrupted.
> Newer languages like Go and Swift shy away from exceptions because of the
> tendency to:
>
> try:
># something
> except:
> print('oops!)
>
People do dumb things with exceptions, yes. Why does this mean that
they are bad? I don't understand this. Exception handling (and stack
unwinding) gives an easy and clear way to refactor code without having
to daisychain error handling everywhere. How is throwing that away
going to help people write better code?
But then, Golang also decided that Unicode wasn't necessary, and we
should all deal with UTF-8 encoded byte sequences instead of text
strings, so I'm fairly sure there are no ten foot barge poles long
enough for me to touch it with. There are languages that have problems
because of history (*cough*JavaScript*cough*), but for a new language
to make multiple poor decisions just means it's one to avoid.
ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions
On Thu, Feb 21, 2019 at 10:34 PM Ben Rudiak-Gould
wrote:
> > It's well documented how checked exceptions lead to bad code.
>
> Please cite a paper. I know "everyone knows" that they're bad, but
> "everyone knows" a lot of things.
>
This is one of the original interviews touching why checked exceptions were
not made part of C#:
https://www.artima.com/intv/handcuffs.html
The problem is that a code fragment should only catch exceptions that it
expects, because it won't know what to do anything else but to wrap the
exception into one of the enclosing type.
But if every type has to define a SomethingWentWrongInTypeException wrapper
exception, it's logical that all of them inherit from a standard
SomethingWentWrongException. Having done that, the type-specific generic
exceptions are of no value, because any code wanting to guard against the
unexpected will just catch SomethingWentWrongException. And that brings us
back to square one, which is letting unexpected exceptions through to
wherever a clean shutdown or restart of the subsystem can be done.
Then, if exceptions are going to be part of a type, there should be a way
to express the semantics of them (like in Eiffel), so
stack.pop();stack.push(x) doesn't have to catch StackFullException.
In the end, I think that allowing type-hints about exceptions that may be
raised is quite useful, as long as they are not checked/enforced (in the
style of Java). Many times I've missed a PyCharm hint me about the actual
exceptions a given call may actually raise.
Newer languages like Go and Swift shy away from exceptions because of the
tendency to:
try:
# something
except:
print('oops!)
--
Juancarlo *Añez*
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions
> It's well documented how checked exceptions lead to bad code. Please cite a paper. I know "everyone knows" that they're bad, but "everyone knows" a lot of things. Here's a recentish proposal by Herb Sutter to add a kind of checked exception to C++: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf He talks about some of the same issues I've talked about in this thread: in particular, that the farther exceptions propagate, the less likely that they can be handled in a precise way. In practice, exceptions are either handled early or they are handled generically (e.g. by printing a traceback). > Exceptions may be logically thought as of part of the type of a method, Yes, exceptions designed to be caught and handled by the caller are essentially alternate return values. Examples are KeyError for mapping lookups, FileNotFoundError for open(), etc. They are part of the method's interface whether they are encoded in a type system or not. > but that requires that the type catches every exception that may be raised > from the implementation and either handles it, or translates it to one > belonging to the type. What you're describing is strong static typing. Yes, it is a hassle. It means you have to do a lot of up-front work proving that your program will handle *every* case before the implementation will permit you to run it on *any* case. A lot of programmers don't like that. They want to write code that works for the cases they care about in the moment, and think about the other cases "later" (which in practice often means "after the product has shipped and someone files a bug report"). > It's a lot of work, it's cumbersome, and it is fragile, as the exception > handling may need to change over minor implementation changes. Yes, it's a lot of work and cumbersome. In exchange for this extra effort, you get static guarantees that make it easier to reason about the behavior of the program. > The strategy of catching only exceptions of interest and letting others pass > produces less fragile and easier to test code. It is less of a hassle to write unchecked code. I don't know if it's easier to test, but maybe. It isn't less fragile, at least not in the way I understand "fragile." Fragile code isn't code that is prone to compile-time type errors when it's changed. Fragile code is code that's prone to crashes or other broken behavior at runtime when it's changed, because of hidden constraints that weren't expressible in the type system. At least, that's what "fragile" means in "fragile base class problem." ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] add fluent operator to everything
On 2019-02-20 10:10, Steven D'Aprano wrote:
> Or if you're worried about the line length:
> result = function(mystr.strip()
>.expandtabs()
>.lower()
>.replace('ham', 'spam')
> I think
It seems that this fluency discussion, and the vector discussion is
similar; I made a toy class [1] to demonstrate. It is much like
DavidMertz's vector [2], but focused on chained methods .
The `vector()` method lets us enter "vector mode". There are methods
that act on elements (eg. map), methods that act on the whole (eg.
sort), and methods that exit vector mode (eg. list).
output = vector([3, 2, 1]).append(4).sort().limit(10).list()
Fluency can be had by entering vector mode on a singleton list:
output = (
vector([mystr])
.strip()
.expandtabs()
.lower()
.replace("ham", "spam")
.map(function)
.first()
)
Given vector() is quite succinct, and Numpy and Pandas do vector
operations elegantly already, I do not think there is need for
vectorized operators or fluency operators in Python.
[1] My toy class -
https://github.com/klahnakoski/mo-vector/blob/master/mo_vector/__init__.py
[2] DavidMertz vector 0-
https://github.com/DavidMertz/stringpy/blob/master/vector.py
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions
On Thu, Feb 21, 2019 at 6:28 PM Ivan Levkivskyi wrote: > The idea about "checked exceptions" appeared several times in various > places. I used to think that this would be hard to support for any > realistic use cases. But now I think there may be a chance > to turn this into a usable feature if one frames it correctly (e.g. the > focus could be on user defined exceptions, rather than on standard ones, > since there is no way we can annotate every function in typeshed). > It's well documented how checked exceptions lead to bad code. That's why C#, which came after Java, didn't include them. Exceptions may be logically thought as of part of the type of a method, and of the type of the method's class, but that requires that the type catches every exception that may be raised from the implementation and either handles it, or translates it to one belonging to the type. It's a lot of work, it's cumbersome, and it is fragile, as the exception handling may need to change over minor implementation changes. If dependencies don't treat the exceptions that may escape from them as part of the type, then our own types will need to be changes every time a dependency changes its implementation. The strategy of catching only exceptions of interest and letting others pass produces less fragile and easier to test code. -- Juancarlo *Añez* ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 8 update on line length
On Thu, Feb 21, 2019 at 12:01 PM Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
> I concur. We now put expressions in f-strings and have assignment
> expressions that easily spill over 80 characters if one uses all but the
> most compact variable names. Comprehensions tend to make expressions
> longer. Queries and filters in Pandas also easily spill over. The 80
> character limit pre-dates these evolutions of the language.
>
> In particular, the case where I most want to let people run with long
> lines is in forming messages to be displayed to a user.
I agree here -- and if it's messages (also comments - a twenty char comment
after a 70 char line should be fine!) then it's not part of the logic of
the code -- so not as bd if there is some spill off the screen for those
folks that do code on tablets ;-) Actually for me, the issue s comes up
when I'm showing code on a projector -- I use a huge font so folks in the
back can see)
> class Frabawidget:
> ...
> @wozzle.setter
> def (self, woozle):
> if not (self.min_woozle < woozle < self.max_woozle):
> raise ValueError(f"Expected woozle to be between
> {self.min_woozle} and {self.max_woozle}")
> self._wozzle = normalize(woozle)
>
That's 103 chars long -- and very readable. But, is this that much worse?
class Frabawidget:
...
@wozzle.setter
def (self, woozle):
if not (self.min_woozle < woozle < self.max_woozle):
raise ValueError(f"Expected woozle to be between"
"{self.min_woozle} and {self.max_woozle}")
self._wozzle = normalize(woozle)
(it IS harder to write, that's for sure)
In doing code reviews, I see many fewer atrocities from long lines than I
> do from weird line-wraps and from variable names that have been
> over-shortened to make the line fit in 80 characters. To avoid these
> issues, my clients typically set their line limits at 90 or 100
and yet the above example was 103 ... you do need a limit somewhere.
I actually would really like the "limit" to depend on what the line is --
that is, it's OK to go longer if it's essentially text -- message to the
user, comment, etc., rather than part of the code logic.
In fact, now that I write that, I think I actually DO do that -- and even
add a # noqa sometimes so my linter will stop bugging me. A smart linter
would be nice here.
PEP 8 is mostly about readability. However, the line length limit often
> seems to cause less readable code.
>
So what do you suggest? simply increase the recommended line length? Or
would softening the language about extending it be enough?
Maybe something along the lines of:
A line length limit should be well defined for each project / organization
-- 80 char per line is safest for all users, but anything up to 100 is
appropriate if the team maintaining the code agrees.
Raymond: As a core dev -- are suggesting extending the line limit for the
standard library?
To all the folks quoting theory: let's be honest. Yes, really long lines
are harder to read, but the 80 char limit comes from old terminals, NOT any
analysis that somehow that is optimum for readability.
-CHB
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR(206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
chris.bar...@noaa.gov
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 8 update on line length
Some feedback: I code on a 13.5 inch laptop. I split my screen between my browser on the left half and editor on the right half of the screen. The 80 character suggestion has been helpful to me in reading code. Otherwise I'd use up time with random horizontal scrolling. On Thu, Feb 21, 2019 at 4:11 PM Mike Miller wrote: > > On 2/21/19 10:53 AM, Paul Ferrell wrote: > > I think the solution is for everyone to rotate their widescreen monitors > 90° > > into a really tall portrait mode. :) > > Yep, that's what I do, but would prefer a squarer monitor so I could get > two > windows side by side on that one also. My old 1600x1200 4:3 in portrait > allowed > that comfortably. 16:10 might. > > -Mike > > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions
On Tue, 19 Feb 2019 at 21:07, 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. > The idea about "checked exceptions" appeared several times in various places. I used to think that this would be hard to support for any realistic use cases. But now I think there may be a chance to turn this into a usable feature if one frames it correctly (e.g. the focus could be on user defined exceptions, rather than on standard ones, since there is no way we can annotate every function in typeshed). But this is probably not the best place to the start the discussion (we may come back here if we will have a proposal). I would recommend to post either on typing GitHub tracker, or mypy GitHub tracker, or on typing SIG mailing list. IMO the part about side effects is a non-starter. -- Ivan ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 8 update on line length
On 2/21/19 10:53 AM, Paul Ferrell wrote: I think the solution is for everyone to rotate their widescreen monitors 90° into a really tall portrait mode. :) Yep, that's what I do, but would prefer a squarer monitor so I could get two windows side by side on that one also. My old 1600x1200 4:3 in portrait allowed that comfortably. 16:10 might. -Mike ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 8 update on line length
I think the solution is for everyone to rotate their widescreen monitors 90° into a really tall portrait mode. :) On Thu, Feb 21, 2019, 11:44 AM Mike Miller wrote: > > On 2/18/19 8:37 PM, Simon wrote: > > I'd like to propose an update to PEP8. Indeed, the 80 characters per > line > > guideline is, I feel, outdated. > > Hi, I don't agree it is outdated. As someone who has a second 4k monitor > in > portrait mode to minimize scrolling (recommended), the ~80 char line limit > avoids the need for horizontal scrolling as well. This isn't your > father's > Oldsmobile, haha. > > When in landscape on the go I can have two windows open side by side, say > an > editor and documentation/mail at the same time, aka multitasking. Not as > good > as a second monitor, but better than nothing. > > Other folks have chimed in on how newspapers and magazines limit line > length for > readability purposes. > > I suppose if you code fullscreen (or near it) on a 16:9 monitor, longer > lines > might be desirable. Worked at a place where a co-worker frequently > produced > code with ~200 character lines despite calls to cease and desist. Looked > over > once, and sure enough a full+widescreen editor. Nostalgic for DOS, or > focused > like a laser? Not sure. > > The issue is unfortunately exacerbated by the monitor industry forcing us > all to > 16:9 aspect ratios, outside of the MacBook and tablets. That was a > regression > in my opinion. > > -Mike > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 8 update on line length
On 2/18/19 8:37 PM, Simon wrote: I'd like to propose an update to PEP8. Indeed, the 80 characters per line guideline is, I feel, outdated. Hi, I don't agree it is outdated. As someone who has a second 4k monitor in portrait mode to minimize scrolling (recommended), the ~80 char line limit avoids the need for horizontal scrolling as well. This isn't your father's Oldsmobile, haha. When in landscape on the go I can have two windows open side by side, say an editor and documentation/mail at the same time, aka multitasking. Not as good as a second monitor, but better than nothing. Other folks have chimed in on how newspapers and magazines limit line length for readability purposes. I suppose if you code fullscreen (or near it) on a 16:9 monitor, longer lines might be desirable. Worked at a place where a co-worker frequently produced code with ~200 character lines despite calls to cease and desist. Looked over once, and sure enough a full+widescreen editor. Nostalgic for DOS, or focused like a laser? Not sure. The issue is unfortunately exacerbated by the monitor industry forcing us all to 16:9 aspect ratios, outside of the MacBook and tablets. That was a regression in my opinion. -Mike ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] add fluent operator to everything
On Thu, 21 Feb 2019, 16:44 Rhodri James, wrote: > On 21/02/2019 15:31, Robert Vanden Eynde wrote: > > In funcoperators, because the dot operator is just syntaxic sugar for > > functions getattr and setattr with a string, > [snip hideousness] > > I have to say, that's a pretty strong argument for not touching > funcoperators with a ten foot bargepool. > What do you mean ? I don't mind touching funcoperators, I try to understand the need and find solutions using existing tools. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] add fluent operator to everything
On 21/02/2019 15:47, Robert Vanden Eynde wrote: On Thu, 21 Feb 2019, 16:44 Rhodri James, wrote: On 21/02/2019 15:31, Robert Vanden Eynde wrote: In funcoperators, because the dot operator is just syntaxic sugar for functions getattr and setattr with a string, [snip hideousness] I have to say, that's a pretty strong argument for not touching funcoperators with a ten foot bargepool. What do you mean ? I don't mind touching funcoperators, I try to understand the need and find solutions using existing tools. (I meant bargepole, not bargepool, obviously. Sorry about the typos, I have two other projects crowding my brain at the moment and may not make a great deal of sense.) I mean it looked horrible. If someone put code like that in front of me, I would assume that the writer was being clever for the sake of being clever and rewrite it in a way that I would probably be able to read later without half an hour of puzzling first. I flat out do not see the need for fluent operators. What the heck is wrong with putting separate operations on separate lines? It's easier to read, and gives you shorter lines into the bargin (see the 80-column argument going on elsewhere). -- Rhodri James *-* Kynesim Ltd ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] add fluent operator to everything
On 21/02/2019 15:31, Robert Vanden Eynde wrote: In funcoperators, because the dot operator is just syntaxic sugar for functions getattr and setattr with a string, [snip hideousness] I have to say, that's a pretty strong argument for not touching funcoperators with a ten foot bargepool. -- Rhodri James *-* Kynesim Ltd ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] add fluent operator to everything
In funcoperators, because the dot operator is just syntaxic sugar for
functions getattr and setattr with a string,
a.hello.world
# can be implemented using infix
a -o- 'hello' -o- 'world'
# or using postfix
a |dot('hello') |dot('world')
# using
from funcoperators import postfix, infix
o = infix(getattr)
def dot(n):
return postfix(lambda x: getattr(x, n))
For methods, one could write :
a.upper().replace('x', 'y')
# can be implemented by
a |meth('upper') |meth('replace', 'x', 'y')
# using
def meth(x, *a, **b):
return postfix (lambda self: getattr(self, x)(*a, **b))
And one could do
upper = postfix(str.upper)
def replace(*a, **b):
return postfix(lambda self: self.replace(*a, **b))
# to be able to do :
a |upper |replace('a', 'b')
And of course you can create your own functions to have the behavior you
want.
robertvandeneynde.be
On Thu, 21 Feb 2019, 13:22 Steven D'Aprano, wrote:
> Correcting myself twice now, that's not a good sign... :-)
>
> On Thu, Feb 21, 2019 at 12:55:00PM +1100, Steven D'Aprano wrote:
>
> > But there's a deeper problem with this entire concept, regardless of
> > syntax, one which to my knowledge nobody has mentioned yet: it simply
> > isn't compatible with the way operators work in Python at the moment.
> > More on this in another post (coming soon).
>
> On further thought, I would like to withdraw that claim.
>
> Actual operators like + - etc of course are implemented using dunder
> methods, but "pseudo-operators" like the dot aren't. If we had such a
> fluent method chain operator, it would be more like dot than ordinary
> operators.
>
>
>
> --
> Steven
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 8 update on line length
On Thu, 21 Feb 2019 at 12:20, Paul Ferrell wrote: > > My linter is fine with a double indent after an 'if (A and'. I thought it > was in the standard. If I used a linter, I'd expect it to be fine with whatever I told it to be fine with :-) It's a linter's job to flag up violations of the coding style *I* choose to follow, not to impose a coding style on me that I don't agree with. Paul ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] add fluent operator to everything
Correcting myself twice now, that's not a good sign... :-) On Thu, Feb 21, 2019 at 12:55:00PM +1100, Steven D'Aprano wrote: > But there's a deeper problem with this entire concept, regardless of > syntax, one which to my knowledge nobody has mentioned yet: it simply > isn't compatible with the way operators work in Python at the moment. > More on this in another post (coming soon). On further thought, I would like to withdraw that claim. Actual operators like + - etc of course are implemented using dunder methods, but "pseudo-operators" like the dot aren't. If we had such a fluent method chain operator, it would be more like dot than ordinary operators. -- Steven ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions
On Thu, Feb 21, 2019 at 10:04 PM Steven D'Aprano wrote: > > On Thu, Feb 21, 2019 at 07:05:55PM +1100, Chris Angelico wrote: > > [Ben] > > > Other functions also conceptually have three ways of returning: > > > ordinary return with a value, a documented special return like > > > KeyError, and pass-through exceptions. If the pass-through exception > > > is KeyError, it gets conflated with the documented exceptional return, > > > but correct code should handle them differently. It doesn't matter > > > whether the syntax for the documented special return is "return x" or > > > "raise KeyError(x)". > > > > Not sure what you mean here. If the documented special return is > > "return x", then it's a value that's being returned. That's completely > > different from raising some sort of exception. > > I think I understand what Ben means, because I think I've experimented > with functions which do what he may be getting at. > > Remember that exceptions are not necessarily errors. So you might write > a function which returns a value in the standard case, but raises an > exception to represent an exceptional case. If this is not an error, > then the caller ought to be prepared for the exception and always catch > it. Yep, I understand that part (and mention KeyError specifically). What I don't understand is the documented special return of "return x". If there's a way to return a magic value, then it's still just a value. For the rest, yeah, there's the normal Python behaviour of signalling "nope" by raising a specific exception. And yes, leaking an exception of the same type from within that function is going to be interpreted as that "nope". That's important to the ability to refactor - you can have a helper function that raises, and then the main __getitem__ or __getattr__ or whatever will just propagate the exception. That's why "leaking" is such a hard thing to pin down. ChrisA ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions
On Thu, Feb 21, 2019 at 07:05:55PM +1100, Chris Angelico wrote: [Ben] > > Other functions also conceptually have three ways of returning: > > ordinary return with a value, a documented special return like > > KeyError, and pass-through exceptions. If the pass-through exception > > is KeyError, it gets conflated with the documented exceptional return, > > but correct code should handle them differently. It doesn't matter > > whether the syntax for the documented special return is "return x" or > > "raise KeyError(x)". > > Not sure what you mean here. If the documented special return is > "return x", then it's a value that's being returned. That's completely > different from raising some sort of exception. I think I understand what Ben means, because I think I've experimented with functions which do what he may be getting at. Remember that exceptions are not necessarily errors. So you might write a function which returns a value in the standard case, but raises an exception to represent an exceptional case. If this is not an error, then the caller ought to be prepared for the exception and always catch it. This could be considered an alternative design to returning a tuple: (True, value) # standard case (False,) # or raise an exception If this seems strange, it actually isn't *that* strange. It is very similar to the way iterators yield a value in the standard case, and raise StopIteration to signal the non-standard, non-erroneous but exception case of having reached the end of the iterator. Another potential example would be searching, where "Not Found" is not necessarily an error, but it is always an exceptional case. The built-ins raise KeyError or ValueError (for str.index) but they could have just as easily raise KeyNotFound and SubstringNotFound. So exceptions do not necessarily represent errors that should bubble up to the user, to be reported as a bug. They can also represent an alternative (if slightly clumsy) mechanism for passing information to the caller. -- Steven ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 8 update on line length
Brendan Barnwell wrote: I use an editor that VISUALLY wraps long lines and maintains the indentation on the wrapped portion, without changing the bytes in the file. I make my lines as long as I want, inserting linebreaks only where they have a semantic reason to be (such as between multiple long conditions in an "if"). I don't think that taking an excessively long line of code and mechanically wrapping it to a narrower width makes in any easier to read. Like you say, readability relies on making intelligent decisions about where to break lines based on their semantics. So even if everyone is equipped with an auto-wrapping code editor, there is still going to be code that really needs at least N characters of width to display properly, and looks terrible when wrapped to anything less. Think about how annoying it is when an email message gets re-wrapped to a slightly narrower width than it was originally written with -- and apply that to code. -- Greg ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 8 update on line length
Christopher Barker writes: > On Wed, Feb 20, 2019 at 11:51 PM Lele Gaifax wrote: > >> if ((condition1 >>and condition2 >>and condition3)): >> do_something() >> > > ouch! ehy not jsut do: > > if (condition1 > and condition2 > and condition3)): > do_something() > > (or any number of other options) > > and teach your linter that that's OK (or ignore your linter) Because I would first need to teach Emacs the aforementioned "indent-and-half" for continuation lines :-) ciao, lele. -- nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia. l...@metapensiero.it | -- Fortunato Depero, 1929. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions
On Wed, Feb 20, 2019 at 11:52 PM Ben Rudiak-Gould wrote: > Other functions also conceptually have three ways of returning: > ordinary return with a value, a documented special return like > KeyError, and pass-through exceptions. well, I wouldn't call that three ways of returning... But yes, there is no (easy) way to distinguish an Exception raised by the function you called, and one raised somewhere deeper that. And I have been bitten by that more than once. It makes "Easier to ask forgiveness than permission" kind of tricky. But I've found that good unit tests help a lot. And Exception handling is messy -- the point made by the OP, I'm not sure there's a better way to do it. -CHB -- 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 https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Type hints for functions with side-effects and for functions raising exceptions
On Thu, Feb 21, 2019 at 6:51 PM Ben Rudiak-Gould wrote:
>
> 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 exceptions, this isn't a problem.
>
> Other functions also conceptually have three ways of returning:
> ordinary return with a value, a documented special return like
> KeyError, and pass-through exceptions. If the pass-through exception
> is KeyError, it gets conflated with the documented exceptional return,
> but correct code should handle them differently. It doesn't matter
> whether the syntax for the documented special return is "return x" or
> "raise KeyError(x)".
Not sure what you mean here. If the documented special return is
"return x", then it's a value that's being returned. That's completely
different from raising some sort of exception.
You have a reasonable point about raising KeyError. It's hard to catch
bugs inside __getitem__ that result in the leakage of a KeyError. But
it's not uncommon to implement getitem over some other object's
getitem, which means that leakage is absolutely correct. I'm not sure
what could really be done about that, but I'm also not sure it's
necessary; those special methods tend to be very short. If you're
writing a large and complex __getitem__, it might be worth adding some
overhead to help with potential debugging, maybe wrapping most of your
logic in a generator and having "yield" become "return", "return"
become "raise KeyError", and "raise KeyError" become "raise
RuntimeError". Easy enough with a decorator if you want it.
Unnecessary overhead for most classes though.
ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP 8 update on line length
On Wed, Feb 20, 2019 at 11:51 PM Lele Gaifax wrote:
> that most annoys me is the "if" when the condition is very long, because my
> eyes suffer when I see the following:
>
yup -- "if (" is four spaces -- exactly one indentation level -- that is
really painful.
I've got to figure out how to get flake8 to stop yelling at me for making
that more readable :-)
of difference between the continued condition elements and the succeeding
> suite:
>
> if ((condition1
>and condition2
>and condition3)):
> do_something()
>
ouch! ehy not jsut do:
if (condition1
and condition2
and condition3)):
do_something()
(or any number of other options)
and teach your linter that that's OK (or ignore your linter)
-CHB
--
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
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
