On Fri, Jan 15, 2021 at 10:13 PM Rob Cliffe via Python-Dev
wrote:
>
>
>
> On 12/01/2021 15:53, Mark Shannon wrote:
> > Hi everyone,
> >
> >
> >
> > In master we convert `if x: pass` to `pass` which is equivalent,
> > unless bool(x) has side effects the first time it is called. This is a
> >
On 12/01/2021 15:53, Mark Shannon wrote:
Hi everyone,
In master we convert `if x: pass` to `pass` which is equivalent,
unless bool(x) has side effects the first time it is called. This is a
recent change.
Suppose x is not a currently valid variable name at runtime. Will the
NameError
Hello,
On Thu, 14 Jan 2021 22:05:37 +1100
Steven D'Aprano wrote:
> On Wed, Jan 13, 2021 at 08:17:26PM +0300, Paul Sokolovsky wrote:
>
> > > Besides, we probably don't want to prohibit side-effects in
> > > `__bool__`. That would prohibit useful tricks such as putting
> > > logging calls into a
On Wed, Jan 13, 2021 at 08:17:26PM +0300, Paul Sokolovsky wrote:
> > Besides, we probably don't want to prohibit side-effects in
> > `__bool__`. That would prohibit useful tricks such as putting logging
> > calls into a method you are trying to debug.
>
> Surely, if we do that, we wouldn't use
Hello,
On Thu, 14 Jan 2021 23:00:06 +1300
Greg Ewing wrote:
> On 14/01/21 3:32 pm, Terry Reedy wrote:
> > I say 'yes', because the purpose of logging is to document what
> > happens, and if nothing happens, there is nothing to document.
> > Wrapping a .__bool__ in a logging decorator might be
On 14/01/21 3:32 pm, Terry Reedy wrote:
I say 'yes', because the purpose of logging is to document what happens,
and if nothing happens, there is nothing to document. Wrapping a
.__bool__ in a logging decorator might be part of testing it.
Or it might be something else.
It would be fine to
On 1/13/2021 8:56 PM, Greg Ewing wrote:
On 14/01/21 1:13 pm, Paul Sokolovsky wrote:
But nobody talked about optimizing away generic "pure"-annotated
functions (which would differ from "mathematical" definition of
purity), only about optimizing "pure" *dunder* methods
The same thing applies.
On 14/01/21 1:13 pm, Paul Sokolovsky wrote:
But nobody talked about optimizing away generic "pure"-annotated
functions (which would differ from "mathematical" definition of
purity), only about optimizing "pure" *dunder* methods
The same thing applies. If we decide that print() is pure,
then a
Hello,
On Thu, 14 Jan 2021 12:45:11 +1300
Greg Ewing wrote:
> On 14/01/21 6:17 am, Paul Sokolovsky wrote:
> > For
> > example, print() would be considered "pure", as its purpose is to
> > provide program output, not arbitrarily change program state
>
> That definition of purity wouldn't
On 14/01/21 6:17 am, Paul Sokolovsky wrote:
For
example, print() would be considered "pure", as its purpose is to
provide program output, not arbitrarily change program state
That definition of purity wouldn't really help with optimisations,
though, because optimising away a print() call would
On 14/01/21 5:29 am, Steven D'Aprano wrote:
No, I don't think it is possible to enforce lack of side-effects. Not
without rebuilding the language from the ground up with a clear,
definitive and enforcable distinction between pure and impure functions.
(I think Haskell does something like that.
Hello,
On Thu, 14 Jan 2021 03:29:35 +1100
Steven D'Aprano wrote:
> On Wed, Jan 13, 2021 at 02:08:01AM -0800, Emily Bowman wrote:
> > Even if you define __bool__() as returning a bool, and
> > error/undefined behavior otherwise, that doesn't eliminate side
> > effects. Is it even possible to
On Wed, Jan 13, 2021 at 02:08:01AM -0800, Emily Bowman wrote:
> Even if you define __bool__() as returning a bool, and error/undefined
> behavior otherwise, that doesn't eliminate side effects. Is it even
> possible to nail down a definition to the point that you can say, "Thou
> shalt not mutate
On Wed, Jan 13, 2021 at 08:27:46PM +1100, Chris Angelico wrote:
> It's a lot faster for C-implemented functions to require positional
> parameters. A number of functions had help text that implied that they
> accepted keyword-or-positional args, but if you tried to call them
> with keyword args,
Hi Rob,
On 13/01/2021 12:18 pm, Rob Cliffe wrote:
On 12/01/2021 15:53, Mark Shannon wrote:
In master we convert `if x: pass` to `pass` which is equivalent,
unless bool(x) has side effects the first time it is called. This is a
recent change.
Can you please confirm that this optimisation
Hello,
On Wed, 13 Jan 2021 02:08:01 -0800
Emily Bowman wrote:
> Even if you define __bool__() as returning a bool, and
> error/undefined behavior otherwise, that doesn't eliminate side
> effects. Is it even possible to nail down a definition to the point
> that you can say, "Thou shalt not
On 1/12/21 11:27 PM, Chris Angelico wrote:
The language can also be defined in an optimization-friendly way,
though. Consider how we got positional-only arguments in Python: first
they existed in C-implemented functions in CPython, even though they
couldn't exist in pure Python code, and then
On Wed, Jan 13, 2021 at 9:08 PM Emily Bowman wrote:
>
> Even if you define __bool__() as returning a bool, and error/undefined
> behavior otherwise, that doesn't eliminate side effects. Is it even possible
> to nail down a definition to the point that you can say, "Thou shalt not
> mutate or
Even if you define __bool__() as returning a bool, and error/undefined
behavior otherwise, that doesn't eliminate side effects. Is it even
possible to nail down a definition to the point that you can say, "Thou
shalt not mutate or cause anything" and have it meaningfully enforced in
the compiler
On Wed, Jan 13, 2021 at 8:02 PM Ethan Furman wrote:
>
> On 1/12/21 11:27 PM, Chris Angelico wrote:
> > On Wed, Jan 13, 2021 at 6:11 PM Ethan Furman wrote:
>
> >> Optimizations are an implementation detail, and implementation details
> >> should not change the language.
> >>
> >
> > The language
On 1/12/21 11:27 PM, Chris Angelico wrote:
On Wed, Jan 13, 2021 at 6:11 PM Ethan Furman wrote:
Optimizations are an implementation detail, and implementation details should
not change the language.
The language can also be defined in an optimization-friendly way,
though. Consider how we
Hello,
On Wed, 13 Jan 2021 18:27:07 +1100
Chris Angelico wrote:
[]
> > Optimizations are an implementation detail, and implementation
> > details should not change the language.
>
> The language can also be defined in an optimization-friendly way,
> though. Consider how we got
On Wed, Jan 13, 2021 at 6:11 PM Ethan Furman wrote:
>
> On 1/12/21 10:37 PM, Chris Angelico wrote:
> > On Wed, Jan 13, 2021 at 5:05 PM Steven D'Aprano wrote:
> >>
> >> On Wed, Jan 13, 2021 at 04:47:06AM +1100, Chris Angelico wrote:
> >>
> >>> That'd leave open
> >>> the option for "foo() if x
On 1/12/21 10:37 PM, Chris Angelico wrote:
On Wed, Jan 13, 2021 at 5:05 PM Steven D'Aprano wrote:
On Wed, Jan 13, 2021 at 04:47:06AM +1100, Chris Angelico wrote:
That'd leave open
the option for "foo() if x else foo()" to be optimized down to just
"foo()", although I don't think that
On Wed, Jan 13, 2021 at 5:05 PM Steven D'Aprano wrote:
>
> On Wed, Jan 13, 2021 at 04:47:06AM +1100, Chris Angelico wrote:
>
> > That'd leave open
> > the option for "foo() if x else foo()" to be optimized down to just
> > "foo()", although I don't think that particular one is needed.
>
> That
On Wed, Jan 13, 2021 at 04:47:06AM +1100, Chris Angelico wrote:
> That'd leave open
> the option for "foo() if x else foo()" to be optimized down to just
> "foo()", although I don't think that particular one is needed.
That would be an unsafe optimization. Not all objets are representable
as
On Tue, Jan 12, 2021 at 9:51 AM Chris Angelico wrote:
> On Wed, Jan 13, 2021 at 4:24 AM Richard Damon
> wrote:
> >
> > On 1/12/21 10:53 AM, Mark Shannon wrote:
> > > Hi everyone,
> > >
> > > Should the optimizer eliminate tests that it can prove have no effect
> > > on the control flow of the
On Wed, Jan 13, 2021 at 4:24 AM Richard Damon wrote:
>
> On 1/12/21 10:53 AM, Mark Shannon wrote:
> > Hi everyone,
> >
> > Should the optimizer eliminate tests that it can prove have no effect
> > on the control flow of the program, even if that may eliminate some
> > side effects in __bool__()?
On 1/12/21 10:53 AM, Mark Shannon wrote:
> Hi everyone,
>
> Should the optimizer eliminate tests that it can prove have no effect
> on the control flow of the program, even if that may eliminate some
> side effects in __bool__()?
>
> For several years we have converted
>
> if a and b:
>
Hi everyone,
Should the optimizer eliminate tests that it can prove have no effect on
the control flow of the program, even if that may eliminate some side
effects in __bool__()?
For several years we have converted
if a and b:
...
to
if a:
if b:
...
Ah never mind. Seems to be a real bug -- thanks for reporting!
On Mon, Jan 11, 2021 at 2:57 PM Mats Wichmann wrote:
> On 1/11/21 1:00 PM, Guido van Rossum wrote:
> > All that said (I agree it's surprising that 3.10 seems backwards
> > incompatible here) I would personally not raise
On 1/11/21 1:00 PM, Guido van Rossum wrote:
All that said (I agree it's surprising that 3.10 seems backwards
incompatible here) I would personally not raise AttributeError but
TypeError in the `__bool__()` method.
eh, that was just me picking a cheap something to demo it. the program
raises
I've raised: https://bugs.python.org/issue42899.
The triggering commit was: c71581c7a4192e6ba9a79eccc583aaadab300efa
bpo-42615: Delete redundant jump instructions that only bypass empty blocks
(GH-23733)
On Mon, Jan 11, 2021 at 8:04 PM Guido van Rossum wrote:
> All that said (I agree it's
All that said (I agree it's surprising that 3.10 seems backwards
incompatible here) I would personally not raise AttributeError but
TypeError in the `__bool__()` method.
On Mon, Jan 11, 2021 at 11:51 AM Pablo Galindo Salgado
wrote:
> This may be related to the changes in
This may be related to the changes in https://bugs.python.org/issue42246.
Could you open a new issue and add Mark Shannon to it if that turns to be
the case?
Pablo
On Mon, 11 Jan 2021 at 19:36, Chris Angelico wrote:
> On Tue, Jan 12, 2021 at 6:00 AM Mats Wichmann wrote:
> >
> >
> > On 1/8/21
On Tue, Jan 12, 2021 at 6:00 AM Mats Wichmann wrote:
>
>
> On 1/8/21 4:31 PM, Mats Wichmann wrote:
> >
> >
> > Someone reported a testsuite break on stuff I work on (scons) with
> > 3.10a4, and it looks similar to this which appears in the changelog at
> >
> >
On 1/8/21 4:31 PM, Mats Wichmann wrote:
Someone reported a testsuite break on stuff I work on (scons) with
3.10a4, and it looks similar to this which appears in the changelog at
https://docs.python.org/3.10/whatsnew/changelog.html#changelog
bpo-23898: Fix inspect.classify_class_attrs() to
37 matches
Mail list logo
