On Sat, Jun 30, 2018 at 9:02 PM Alfred Perlstein wrote:
>
>
> On 6/30/18 4:20 PM, Greg Ewing wrote:
> > Alfred Perlstein wrote:
> >> I am asking if there's a way we can discourage the use of
> >> "signal(SIGPIPE, SIG_DFL)" unless the user really understands what
> >> they are doing.
> >
> >
[Nick Coghlan]
>>> "NAME := EXPR" exists on a different level of complexity, since it
>>> adds name binding in arbitrary expressions for the sake of minor
>>> performance improvement in code written by developers that are
>>> exceptionally averse to the use of vertical screen real estate,
> >>>
On 6/30/18 4:20 PM, Greg Ewing wrote:
Alfred Perlstein wrote:
I am asking if there's a way we can discourage the use of
"signal(SIGPIPE, SIG_DFL)" unless the user really understands what
they are doing.
Maybe there's some way that SIGPIPEs on stdout could be handled
differently by default,
On 1 July 2018 at 02:37, Tim Peters wrote:
> [Nick Coghlan]
>
>> ...
>
>> "NAME := EXPR" exists on a different level of complexity, since it
>
>> adds name binding in arbitrary expressions for the sake of minor
>
>> performance improvement in code written by developers that are
>
>> exceptionally
Alfred Perlstein wrote:
I am asking if there's a way we can discourage the use
of "signal(SIGPIPE, SIG_DFL)" unless the user really understands what
they are doing.
Maybe there's some way that SIGPIPEs on stdout could be handled
differently by default, so that they exit silently instead of
Hi,
PEP 544 specifies this address as "Discussions-To" so I hope I'm at the
right address.
I think protocols as defined in the PEP are a very interesting idea and I'm
thinking of ways of applying them. The first use case is in the context of
attrs.
attrs has a number of functions that work only
On 6/30/2018 5:35 AM, Steven D'Aprano wrote:
I've given reasons why I believe that people will expect assignments in
comprehensions to occur in the local scope. Aside from the special case
of loop variables, people don't think of comprehensions as a separate
scope.
I think this is because
On Sat, Jun 30, 2018 at 9:43 AM Tim Peters wrote:
> The attractions are instead in the areas of reducing redundancy, improving
> clarity, allowing to remove semantically pointless indentation levels in
> some cases, indeed trading away some horizontal whitespace in otherwise
> nearly empty lines
[Nick Coghlan]
> > ...
> > "NAME := EXPR" exists on a different level of complexity, since it
> > adds name binding in arbitrary expressions for the sake of minor
> > performance improvement in code written by developers that are
> > exceptionally averse to the use of vertical screen real
Hello,
I'm looking for someone in the python community to help with a problem
of anti-patterns showing up dealing with SIGPIPE.
Specifically I've noticed an anti-pattern developing where folks will
try to suppress broken pipe errors written to stdout by setting
SIGPIPE's disposition to
(sorry for the double post, looks like maybe attachments are dropped,
inlined the attachment this time.)
Hello,
I'm looking for someone in the python community to help with a problem
of anti-patterns showing up dealing with SIGPIPE.
Specifically I've noticed an anti-pattern developing where
On 30 June 2018 at 19:35, Steven D'Aprano wrote:
> So I think Q1 is the critical one. And I think the answer is, no,
> they're conceptually bloody simple. They evaluate the expression on the
> right, assign it to the name on the left, and return that value.
And the proposed parent local scoping
On Thu, Jun 28, 2018 at 03:42:49PM -0700, Chris Barker via Python-Dev wrote:
> If we think hardly anyone is ever going to do that -- then I guess it
> doesn't matter how it's handled.
That's how you get a language with surprising special cases, gotchas and
landmines in its behaviour. (Cough PHP
On Sat, Jun 30, 2018 at 06:30:56PM +1000, Nick Coghlan wrote:
> The significant semantic differences between "{x : 1}" and "{x := 1}"
> are also rather surprising :)
*Significant* and obvious differences are good. It's the subtle
differences that you don't notice immediately that really hurt:
On 30 June 2018 at 09:49, Chris Barker - NOAA Federal via Python-Dev
wrote:
>> On Jun 28, 2018, at 8:21 PM, Tim Peters wrote:
>
> Seems it’s all been said, and Tim’s latest response made an excellent
> case for consistency.
>
> But:
>
>> Regardless of how assignment expressions work in listcomps
On 29 June 2018 at 08:42, Chris Barker via Python-Dev
wrote:
> On Thu, Jun 28, 2018 at 9:28 AM, Tim Peters wrote:
>> Did adding ternary `if` (truepart if expression else falsepart) complicate
>> the language significantly?
>
>
> I don't think so -- no. For two reasons:
>
> 1) the final chosen
On Wed, Jun 27, 2018 at 09:52:43PM -0700, Chris Barker wrote:
> It seems everyone agrees that scoping rules should be the same for
> generator expressions and comprehensions,
Yes. I dislike saying "comprehensions and generator expressions" over
and over again, so I just say "comprehensions".
On 28 June 2018 at 08:31, Guido van Rossum wrote:
> So IIUC you are okay with the behavior described by the PEP but you want an
> explicit language feature to specify it?
>
> I don't particularly like adding a `parentlocal` statement to the language,
> because I don't think it'll be generally
On 28 June 2018 at 09:11, Guido van Rossum wrote:
> Well, with that, I am hereby accepting PEP 561.
>
> Ethan has done a tremendous job writing this PEP and implementing it, and I
> am sure that package and stub authors will be very glad to hear that there
> are now officially supported ways
19 matches
Mail list logo
