Chris Angelico wrote:
Yes. You could tweak that by looking at cls.__module__ and grab it
from sys.modules, but I kept the example simple. However, I would NOT
use the standard name lookup mechanism.
Most classes in builtins won't let you monkeypatch them
anyway, so I'm not sure it's worth the
On Wed, Sep 14, 2016 at 9:35 AM, Greg Ewing wrote:
> Chris Angelico wrote:
>
>> It's a little bit magical, in that it looks up the original class
>> using globals();
>
>
> The way you've written it, monkeypatch() will only work
> if you call it from the module it's defined in.
Yes. You could twea
Chris Angelico wrote:
It's a little bit magical, in that it looks up the original class
using globals();
The way you've written it, monkeypatch() will only work
if you call it from the module it's defined in.
--
Greg
___
Python-ideas mailing list
Py
Continuing the definition for a class feels to me like a strong
anti-pattern for Python. If you absolutely must do this, I guess the
presented decorator is available. It should be discouraged though, not be
part of new syntax.
I believe that if you find yourself doing this you should detect a bad
Pim Schellart wrote:
This PEP proposes the introduction of new syntax to create a community standard,
readable way to continue a definition for classes which are already defined.
-1. Monkeyatching is something that should be disccouraged
rather than encouraged, since it makes code very hard to
On Sep 12, 2016, at 03:12 PM, Senthil Kumaran wrote:
>I see PEP as the design document and docs as user-friendly documentation. It
>helps to keep both of them up to date and in sync. If an "Accepted" PEP is
>not updated, then folks landing on it will feel misguided or confused if the
>read the d
Hi all,
On Tue, 13 Sep 2016 at 18:30 Chris Angelico wrote:
> Did you know that you can actually abuse decorators to do this with
> existing syntax? Check out this collection of evil uses of decorators:
>
> https://github.com/Rosuav/Decorators/blob/master/evil.py
>
There's also this post from G
This general API discussion is veering off-topic for the subject line. If
people would like to continue to discuss it then please start a new thread
(if you feel it impacts your view of a null-coalescing operator then please
discuss in the new thread and come back to this one).
On Tue, 13 Sep 2016
On 2016-09-13 16:27, Rob Cliffe wrote:
On 13/09/2016 12:37, Nick Coghlan wrote:
On 13 September 2016 at 21:15, Rob Cliffe wrote:
On 13/09/2016 04:43, Guido van Rossum wrote:
Yeah, that's exactly my point. PEP 463 gives you a shorter way to
catch an exception, so it gives you less motivation
On Wed, Sep 14, 2016 at 2:22 AM, nate lust wrote:
> I have written a functional reference implementation for the proposed
> continue class syntax which can be found at
> https://raw.githubusercontent.com/natelust/continueClassCpythonPatch/master/continueClass.patch
> .
AIUI, the central core to t
Hello developers,
I have written a functional reference implementation for the proposed
continue class syntax which can be found at
https://raw.githubusercontent.com/natelust/continueClassCpythonPatch/master/continueClass.patch
.
This is a mercurial patch file created against python 3.5. An example
On 09/13/2016 09:29 AM, Chris Angelico wrote:
On Wed, Sep 14, 2016 at 2:16 AM, Pim Schellart wrote:
A well-written PEP that looked very interesting.
https://github.com/Rosuav/Decorators/blob/master/evil.py
@monkeypatch
class A:
x = 5
def foo(self):
pass
def bar(self
On 13 September 2016 at 17:29, Chris Angelico wrote:
> On Wed, Sep 14, 2016 at 2:16 AM, Pim Schellart
> wrote:
>> Semantics
>> =
>>
>> The following two snippets are semantically identical::
>>
>> continue class A:
>> x = 5
>> def foo(self):
>> pass
>> def ba
On Wed, Sep 14, 2016 at 2:16 AM, Pim Schellart
wrote:
> Semantics
> =
>
> The following two snippets are semantically identical::
>
> continue class A:
> x = 5
> def foo(self):
> pass
> def bar(self):
> pass
>
> def foo(self):
> pass
> def
On Wed, Sep 14, 2016 at 1:27 AM, Rob Cliffe wrote:
> And sorry to repeat myself, but we seemed to be having a *general*
> discussion about null-coalescing operators, which moved on to PEP 463, then
> suddenly Guido is talking about APIs. A lot of the time when I'm coding,
> I'm not writing an API
Dear Python Developers,
we have a potential idea for enhancing Python.
Below you will find what the PEP might look like.
A reference implementation has been written and will be posted in a follow up
message.
We are look forward to hearing your feedback and ideas.
Kind regards,
Pim Schellart & N
On 13/09/2016 12:37, Nick Coghlan wrote:
On 13 September 2016 at 21:15, Rob Cliffe wrote:
On 13/09/2016 04:43, Guido van Rossum wrote:
Yeah, that's exactly my point. PEP 463 gives you a shorter way to
catch an exception, so it gives you less motivation to find a way to
write your code (or de
On Wed, Sep 14, 2016 at 12:14 AM, Random832 wrote:
> On Tue, Sep 13, 2016, at 07:37, Nick Coghlan wrote:
>> P.S. There are also some use cases where Look-Before-You-Leap is
>> inherently subject to race conditions,
>
> Which use cases *aren't*?
Ones in which no external force can affect things. F
On Tue, Sep 13, 2016, at 08:44, Michel Desmoulin wrote:
> You won't see very complex usages, mostly things like:
>
> val = foo[-1] except IndexError: "bar"
> doh = val.attr.other except AttributeError: "default"
It occurs to me that if lambda were more lightweight [whether it's the
syntax or the
On Tue, Sep 13, 2016, at 07:37, Nick Coghlan wrote:
> P.S. There are also some use cases where Look-Before-You-Leap is
> inherently subject to race conditions,
Which use cases *aren't*?
> and for those, exceptions are the only reliable signaling mechanism.
It's entirely possible to design a non
I doubt very much it will be used for very complexe cases. Just like
comprehensions or ternary expressions, they are a good fit for some
specific use cases, and people will quickly catch on which one.
You rarely see nested comprehensions or ternary expressions while it's
possible to do so, because
On 13 September 2016 at 21:15, Rob Cliffe wrote:
> On 13/09/2016 04:43, Guido van Rossum wrote:
>> Yeah, that's exactly my point. PEP 463 gives you a shorter way to
>> catch an exception, so it gives you less motivation to find a way to
>> write your code (or define your API) that doesn't involve
On 13 September 2016 at 17:34, Damien George wrote:
> Suggestions for setting the opt level were:
>
> 1) sys.set_default_optimize(level), with the existing
> sys.flags.optimize attribute as the accessor.
>
> 2) sys.opt_level, being a read/write attribute
>
> 3) sys._setflag(name, value) as impleme
On 13/09/2016 04:43, Guido van Rossum wrote:
On Mon, Sep 12, 2016 at 5:45 PM, Rob Cliffe wrote:
On 12/09/2016 16:37, Guido van Rossum wrote:
For the record, I still really don't like PEP 463. We should strive to
catch fewer exceptions, not make it easier to catch them.
Can you please clarify
On 13 September 2016 at 07:13, Paul Moore wrote:
> If I understand the proposal, f is actually intended to be equivalent to:
>
> def f(spam):
> spam_val = spam()
> if spam_val is None:
> return None
> eggs_val = spam_val.eggs()
> if eggs_val is None:
Thanks all for the input on this topic. Let me summarise what was said.
There was discussion that the ability to change the "optimize" value
is not enough and there should be more fine grained control over other
flags/settings. Perhaps that is true, but at least for our case in
MicroPython there
Hi Petr,
> The API you proposed here comes is similar to something I see a lot in
> MicroPython libraries: functions/methods that combine a getter and setter.
> For example, to set the value on a pin, you do:
> pin.value(1)
> and to read, you do:
> result = pin.value()
>
> If an API like
27 matches
Mail list logo
