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
> 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
>
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,
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
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
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
> 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++:
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
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
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
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
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"
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
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
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
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
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
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.
--
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 =
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
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
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
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
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
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)):
>
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,
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
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
28 matches
Mail list logo
