On 10 September 2016 at 22:09, Sven R. Kunze wrote:
> Is going deep really necessary at all?
>
> People program for different reasons, to have fun, to create value for
> others, to educate, or for reasons we both cannot even think of. Why should
> they leave their level? Because of you or me? Beca
On Sat, Sep 10, 2016 at 6:02 PM, David Mertz wrote:
> What I was getting at with "essentially" was that it would *do the same
> thing* that an AttributeError does. That is, if `x.foo` can't be evaluated
> (i.e. x doesn't have an attribute 'foo'), then access is informally "an
> error." The hypo
For kicks I looked at the code in a commercial product that we are open
sourcing very soon at Continuum Analytics. It has about 27k lines of
Python and Cython. I checked it just by running `grep -C3 'if.*None'` over
the source code and eyeballing.
Obviously, this code might be refactored if othe
On Sat, Sep 10, 2016, at 20:15, David Mertz wrote:
> On Sep 10, 2016 4:45 PM, "Guido van Rossum" wrote:
> >
> > There seems to be a major misunderstanding here. A None-coalescing
> > operator is not for catching AttributeError, it's a shortcut similar
> > to "a or b" except that it checks for "a i
On Sat, Sep 10, 2016, at 19:38, David Mertz wrote:
> x2 = x?.foo
>
> x3 = x?.bar?.baz?[x2]
A. if you're doing three different things with x, why are you using this
instead of wrapping it in an if statement?
B. Under some of the proposals, unless x.bar might be None independently
of x not
How much of the time is a branch of the None check a single fallback value
or attribute access versus how often a suite of statements within the
not-None branch?
I definitely check for None very often also. I'm curious what the breakdown
is in code I work with.
On Sep 10, 2016 7:10 PM, "Guido van
To the contrary. I read and write code that performs explicit checks
for None all the time. Catching AttributeError is often a code smell
or at least a measure of last resort.
On Sat, Sep 10, 2016 at 6:46 PM, David Mertz wrote:
> Ok, I have been thinking of the behavior too broadly. I realize now
Ok, I have been thinking of the behavior too broadly. I realize now that
`x?.foo` might still simply raise an AttributeError if x is neither None
nor a thing with a foo attribute.
The class I wrote is definitely too aggressive for the behavior described.
On the other hand, by being narrower in beh
On 2016-09-11 02:02, David Mertz wrote:
On Sat, Sep 10, 2016 at 5:23 PM, Guido van Rossum mailto:gu...@python.org>> wrote:
No. PEP 505 actually solves the problem without ever catching
AttributeError. Please read it.
I read it again (I did a year ago, but reviewed it now). I hadn't be
On Sat, Sep 10, 2016 at 5:23 PM, Guido van Rossum wrote:
> No. PEP 505 actually solves the problem without ever catching
> AttributeError. Please read it.
>
I read it again (I did a year ago, but reviewed it now). I hadn't been
thinking that the *mechanism* of a new None-coalescing operator wou
No. PEP 505 actually solves the problem without ever catching
AttributeError. Please read it.
On Sat, Sep 10, 2016 at 5:15 PM, David Mertz wrote:
> On Sep 10, 2016 4:45 PM, "Guido van Rossum" wrote:
>>
>> There seems to be a major misunderstanding here. A None-coalescing
>> operator is not for c
On Sep 10, 2016 4:45 PM, "Guido van Rossum" wrote:
>
> There seems to be a major misunderstanding here. A None-coalescing
> operator is not for catching AttributeError, it's a shortcut similar
> to "a or b" except that it checks for "a is None" rather than bool(a).
That's exactly what the wrapper
There seems to be a major misunderstanding here. A None-coalescing
operator is not for catching AttributeError, it's a shortcut similar
to "a or b" except that it checks for "a is None" rather than bool(a).
On Sat, Sep 10, 2016 at 4:38 PM, David Mertz wrote:
> Sorry, I sent this accidentally as p
On Sat, Sep 10, 2016 at 4:27 PM, Chris Angelico wrote:
> On Sun, Sep 11, 2016 at 9:10 AM, Guido van Rossum wrote:
>> So you're offering `NoneCoalesce(x).bar` as less-ugly alternative to
>> `x?.bar`... Color me unconvinced.
>
> As a syntactic form? Not interested. But what if it's the underlying
>
Sorry, I sent this accidentally as private reply, then tried to fix it on
phone. The latter produced horrible formatting. Please just read this
version.
On Sat, Sep 10, 2016 at 4:10 PM, Guido van Rossum wrote:
> So you're offering `NoneCoalesce(x).bar` as less-ugly alternative to
> `x?.bar`...
On Sat, Sep 10, 2016 at 4:10 PM, Guido van Rossum wrote:
>
> So you're offering `NoneCoalesce(x).bar` as less-ugly alternative to
> `x?.bar`... Color me unconvinced.
No, I'm offering a more realistic use pattern:
> for x in get_stuff():
>
> x = NoneCoalesce(x)
>
> # ... bunch of st
On Sun, Sep 11, 2016 at 9:10 AM, Guido van Rossum wrote:
> So you're offering `NoneCoalesce(x).bar` as less-ugly alternative to
> `x?.bar`... Color me unconvinced.
As a syntactic form? Not interested. But what if it's the underlying
implementation? We have "yield from X" as a tidy syntax for roug
So you're offering `NoneCoalesce(x).bar` as less-ugly alternative to
`x?.bar`... Color me unconvinced.
On Sat, Sep 10, 2016 at 4:06 PM, David Mertz wrote:
> Actually, I guess the example I liked was from the year ago discussion. And
> it didn't do *exactly* what I think a wrapper should. What I
Actually, I guess the example I liked was from the year ago discussion.
And it didn't do *exactly* what I think a wrapper should. What I'd want
would be like this:
class NoneCoalesce(object):
"Standard operations on object for 'is not None'"
def __init__(self, obj):
self.obj = obj
https://github.com/kirbyfan64/_frozensafemockobjectimplementation
In all seriousness, though, I really feel like that would be the ultimate
bug magnet, since it'd be easy to forget to un-wrap the object afterwards.
--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
progr
I find the '?.' syntax very ugly, much more so in the examples of chained
attributes.
A much better way to handle the use case is to wrap objects in a class that
gives this "propagating None" behavior with plain attribute access. A nice
implementation was presented in this thread.
On Sep 10, 2016
On Sat, Sep 10, 2016, at 13:26, Guido van Rossum wrote:
> The way I recall it, we arrived at the perfect syntax (using ?) and
> semantics. The issue was purely strong hesitation about whether
> sprinkling ? all over your code is too ugly for Python
I think that if there's "strong hesitation" about
On Sat, Sep 10, 2016 at 4:56 PM, Guido van Rossum wrote:
> Another issue already discussed in PEP 505 is a conflict with IPython
> (Jupyter Notebook), which uses ? and ?? as custom syntax to request
> help. But maybe it can be taught to only recognize those when they're
> the last character(s) on
On Sat, Sep 10, 2016 at 11:09 AM, MRAB wrote:
> On 2016-09-10 18:44, Paul Moore wrote:
>>
>> On 10 September 2016 at 18:26, Guido van Rossum wrote:
>>>
>>> IMO the key syntax is
>>> simply one for accessing attributes returning None instead of raising
>>> AttributeError, so that e.g. `foo?.bar?.b
In eGenix PyRun we expose a new helper in the sys module
for this:
--- ./Python/sysmodule.c 2015-12-07 02:39:11.0 +0100
+++ ./Python/sysmodule.c2016-05-03 19:22:35.793193862 +0200
@@ -1205,6 +1205,50 @@
Return True if Python is exiting.");
+/*** PyRun Extension *
On 2016-09-10 18:44, Paul Moore wrote:
On 10 September 2016 at 18:26, Guido van Rossum wrote:
IMO the key syntax is
simply one for accessing attributes returning None instead of raising
AttributeError, so that e.g. `foo?.bar?.baz` is roughly equivalent to
`foo.bar.baz if (foo is not None and fo
On 10 September 2016 at 18:26, Guido van Rossum wrote:
> IMO the key syntax is
> simply one for accessing attributes returning None instead of raising
> AttributeError, so that e.g. `foo?.bar?.baz` is roughly equivalent to
> `foo.bar.baz if (foo is not None and foo.bar is not None) else None`,
> e
On 10.09.2016 19:14, Random832 wrote:
As I remember the discussion, I thought he'd more or less conceded on
the use of ? but there was disagreement on how to implement it that
never got resolved. Concerns like, you can't have a?.b return None
because then a?.b() isn't callable, unless you want to
The way I recall it, we arrived at the perfect syntax (using ?) and
semantics. The issue was purely strong hesitation about whether
sprinkling ? all over your code is too ugly for Python, and in the end
we couldn't get agreement on *that*. Another problem is PEP 505 -- it
is full of discussion but
On Sat, Sep 10, 2016, at 12:48, Stephen J. Turnbull wrote:
> I forget if Guido was very sympathetic to null-coalescing operators,
> given somebody came up with a good syntax.
As I remember the discussion, I thought he'd more or less conceded on
the use of ? but there was disagreement on how to imp
If people are curious as to where import makes its decision as to what
bytecode to load based on the optimization level, see
https://github.com/python/cpython/blob/ad3b9aeaab5122b22445f9120a6ccdc1987c15cc/Lib/importlib/_bootstrap_external.py#L292
.
On Sat, 10 Sep 2016 at 04:53 Nick Coghlan wrote
Steven D'Aprano writes:
> As Zach and MRAB mention, this was discussed last year. If I recall
> correctly, the discussion fizzled out without a solid conclusion. I
> think there's a PEP -- if not, there should be.
The problem, as I recall, was that there was a conclusion that
'maybe_None if ma
On 08.09.2016 04:00, Steven D'Aprano wrote:
On Wed, Sep 07, 2016 at 11:43:59PM +0200, Sven R. Kunze wrote:
>BUT experienced devs also need to recognize and respect the fact that
>younger/unexperienced developers are just better in detecting
>inconsistencies and bloody work-arounds.
That is not
On 10 September 2016 at 03:20, Brett Cannon wrote:
> I don't know if it's been discussed, but I have thought about it in context
> of PEP 511. The problem with swapping optimization levels post-start is that
> you end up with inconsistencies, e.g. asserts that depend on other
> asserts/__debug__ t
On 10 September 2016 at 03:01, Steven D'Aprano wrote:
> In particular, I expect that some time soon somebody will propose at
> least one more optimization:
>
> - remove annotations
>
>
In process of developing the implementation of variable annotations
this idea already appeared (I even did some
On 09/10/2016 02:04 AM, Damien George wrote:
What is to stop you from adding this to micropython as a library
extension?
That's what I would like to do, and usually we do just go ahead and
add our own extensions, trying to be Pythonic as possible :)
But we do that a lot and sometimes I think i
It is PEP 505.
I agree we should resume the discussion on this PEP though (for 3.7), I'm
not completely sure why it stalled.
Ralph
On Sat, 10 Sep 2016, 02:50 Steven D'Aprano, wrote:
> On Fri, Sep 09, 2016 at 10:01:44PM +0200, Arek Bulski wrote:
> > Sometimes I find myself in need of this nice o
2016-09-10 2:56 GMT-04:00 Andrew Svetlov :
> There are also peephole optimization.
> Removing it may prevent false positives for coverage tool
> http://bugs.python.org/issue2506
My PEP 511 adds "-o noopt" to disable the peephole optimizer ;-)
"PEP 511 -- API for code transformers"
www.python.org/
38 matches
Mail list logo
