Mailman 3 April 2017 - Python-ideas

Re: [Python-ideas] Augmented assignment syntax for objects.
by Tin Tvrtković April 25, 2017

April 25, 2017

You might want to check out attrs (http://attrs.readthedocs.io/en/stable/). It can generate the __init__ for you, and much much more. Date: Tue, 25 Apr 2017 14:33:49 +0200 > From: George Fischhof <george(a)fischhof.hu> > To: Paul Moore <p.f.moore(a)gmail.com> > Cc: Python-Ideas <python-ideas(a)python.org>, "Steven D'Aprano" > <steve(a)pearwood.info> > Subject: Re: [Python-ideas] Augmented assignment syntax for objects. > Message-ID: > < > CAFwcP0gjg1BXeQ2pmv637bXG6+vcXiVu1QNEkdetuHjmoT_yCw(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 2017. ?pr. 25. de. 10:04 ezt ?rta ("Paul Moore" <p.f.moore(a)gmail.com>): > > On 25 April 2017 at 03:53, Steven D'Aprano <steve(a)pearwood.info> wrote: > > On Tue, Apr 25, 2017 at 02:08:05AM +0100, Erik wrote: > > > >> I often find myself writing __init__ methods of the form: > >> > >> def __init__(self, foo, bar, baz, spam, ham): > >> self.foo = foo > >> self.bar = bar > >> self.baz = baz > >> self.spam = spam > >> self.ham = ham > >> > >> This seems a little wordy and uses a lot of vertical space on the > >> screen. > > > > It does, and while both are annoying, in the grand scheme of things > > they're a very minor annoyance. After all, this is typically only an > > issue once per class, and not even every class, and vertical space is > > quite cheap. In general, the barrier for accepting new syntax is quite > > high, and "minor annoyance" generally doesn't reach it. > > I suspect that with a suitably creative use of inspect.signature() you > could write a decorator for this: > > @auto_attrs > def __init__(self, a, b, c): > # Remaining init code, called with self.a, self.b and self.c set > > I don't have time to experiment right now, but will try to find time > later. If nothing else, such a decorator would be a good prototype for > the proposed functionality, and may well be sufficient for the likely > use cases without needing a syntax change. > > Paul > >

1 0

Re: [Python-ideas] Callable Enum values
by Ethan Furman April 21, 2017

April 21, 2017

[redirecting back to the list] On 04/19/2017 11:15 PM, Stephan Hoyer wrote: > Ethan and Steven, > > Thanks for your feedback on this one. I agree that it probably doesn't make sense for the standard library. > > I'm still not really happy with any of the standard approaches for choosing a function based on an enum value -- they > all seem pretty verbose/ugly -- but clearly I'm bothered by this more than most, and the standard library is not a good > place for novel solutions. I'm curious, what did you find ugly with: class TestEnum(CallableEnum): @enum def hello(text): "a pleasant greeting" print('hello,', text) @enum def goodbye(text): print('goodbye,', text) -- ~Ethan~

3 4

Thread-safe generators
by Serhiy Storchaka April 17, 2017

April 17, 2017

When use a generator from different threads you can get a ValueError "generator already executing". Getting this exception with the single thread is a programming error, it in case of different threads it could be possible to wait until other thread finish executing the generator. The generator can be made thread-safe after wrapping it in a class that acquire a lock before calling the generator's __next__ method (for example see [1]). But this is not very efficient of course. I wondering if it is worth to add support of thread-safe generators in the stdlib. Either by providing standard decorator (written in C for efficiency), or adding threading support just in the generator object. The latter may need increasing the size of the generator object for a lock and thread identifier (but may be GIL is enough), but should not affect performance since locking is used only when you faced with a generator running in other thread. This topic already was raised on Python-Dev [2] but didn't moved too much. There are a number of StackOverflow questions about threads and generators. We have already encountered this issue in the stdlib. Once in regrtest with the -j option ([3], [4]), other time after reimplementing tempfile._RandomNameSequence as a generator [5]. [1] http://anandology.com/blog/using-iterators-and-generators/ [2] https://mail.python.org/pipermail/python-dev/2004-February/042390.html [3] https://bugs.python.org/issue7996 [4] https://bugs.python.org/issue15320 [5] https://bugs.python.org/issue30030

8 12

Callable Enum values
by Stephan Hoyer April 16, 2017

April 16, 2017

Enums are great. They allow you cleanly define a set of statically defined options. One way that I've found myself using enums recently is for dispatching (as keys in a dictionary) between different interchangeable functions or classes. My code looks something like this: from enum import Enum def foo(...): ... def bar(...): ... class Implementation(Enum): FOO = 1 BAR = 2 _IMPLEMENTATIONS = { Implementation.FOO: foo, Implementation.BAR: bar, } def call_implementation(implementation, *args, **kwargs): return _IMPLEMENTATIONS[implementation](*args, **kwargs) The first part of this blog post does a nice job of summarizing the general use case: http://lukasz.langa.pl/8/single-dispatch-generic-functions/ Obviously, enums are better than strings, because they're static declared and already grouped together. But it would be nice if we could do one better, by eliminating the dictionary, moving the dictionary values to the enum and making the enum instances. You might try this by writing a small subclass of Enum: class CallableEnum(Enum): def __call__(self, *args, **kwargs): return self.value(*args, **kwargs) class Implementation(CallableEnum): FOO = foo BAR = bar def call_implementation(implementation, *args, **kwargs): return implementation(*args, **kwargs) This looks great, with the Enum serving essentially as a typed namespace for a group of related functions, but unfortunately it this doesn't work. The problem is that when you assign a function to an Enum, it treats it as a method instead of an enum value: http://stackoverflow.com/questions/40338652/how-to-define-enum-values-that-… Instead, you need to wrap function values in a callable class, e.g., from functools import partial class Implementation(CallableEnum): FOO = partial(foo) BAR = partial(bar) This is OK, but definitely uglier and more error prone than necessary. It's easy to forget to add a partial, which results in an accidental method declaration. It would be nice to have a CallableEnum class that works like Enum, but adds the __call_ method and doesn't allow defining any new methods: all functions assigned in the class body become Enum instances instead of methods. I would write this myself and throw it up on pypi, but there doesn't seem to be any way to do this short of delving into the guts of enum.EnumMeta <https://github.com/python/cpython/blob/0dc5c3169dcd4853612d11ed8c92b12fa210…>. Given that I think that others will also find this pattern useful, rather than forking the enum module I would like to add this into the standard library instead. Note: this proposal would also allow defining enum values using "def" inside the Enum body. But I think this is actually pretty clean, aside from general enum confusion over the fact that Implementation.FOO is Enum instance, not the method. class Implementation(CallableEnum): def FOO(...): ... def BAR(...): ...

3 2

"import me" to display some summary of the current python installation
by Kamal Mustafa April 12, 2017

April 12, 2017

On the same theme with "import this" and "import antigravity", "import me" I think can be both some fun way to introduce Python and also offer a helpful functionality when troubleshooting python installation with someone new to the language. Currently, we have to use some myriad approach like "show me the output of `which python`" to know the basic info of the python installation someone having trouble or asking question.

7 11

Proposal: making __str__ count in time's class
by Francesco Franchina April 9, 2017

April 9, 2017

Hello everyone, I'm shortly writing to you about a reflection I lately made upon the current functioning of __str__ for the time's class. Before expressing my thought and proposal, I want to make sure we all agree on a simple and clear fact: the __str__ magic method is used to give a literal and human-readable representation to the object (unlike __repr__). Generally this is true across the python panorama. It's not true for the time class, for example. *>>> import time>>> a = time.localtime()>>> a.__str__()'time.struct_time(tm_year=2017, tm_mon=3, tm_mday=8, tm_hour=16, tm_min=6, tm_sec=16, tm_wday=2, tm_yday=67, tm_isdst=0)'* Well, don't get me wrong: the main aim of the __str__ method has been accomplished but, imho, not in the most pythonic way. I just wanted to ask you: what do you think about re-writing the __str__ of the time class so it would return something like ISO 8601 [https://en.wikipedia.org/wiki/ISO_8601] format? Wouldn't it be more meaningful? Especially in the JS-everywhere-era it could be more more productive. *TL;DR* __str__ for dates should return a human-readable date format (eg: https://en.wikipedia.org/wiki/ISO_8601) I'm waiting for your opinions. Thank you for your time and ideas! Francesco Franchina

4 3

Re: [Python-ideas] Make `import a.b.c as m` is equivalent to `m = sys.modules['a.b.c']`
by Victor Varvariuc April 9, 2017

April 9, 2017

The issue: http://bugs.python.org/issue30024 <http://bugs.python.org/issue30024> > On 9 Apr 2017, at 10:05, Nick Coghlan <ncoghlan(a)gmail.com> wrote: > > On 9 April 2017 at 16:13, Victor Varvariuc <victor.varvariuc(a)gmail.com> wrote: >> I think there are can be several ways to achieve the result. >> >> The question is if what I've presented is a valid concern. I think this would make the language more consistent and help reducing number of errors related to import without breaking old code. >> >> May I create an issue in the bug tracker? > > Aye, go ahead - I would previously have advised against it, but given > at least one relatively low impact path to resolution, it's worth > filing it as an enhancement request. > > Cheers, > Nick. > > -- > Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

1 0

Re: [Python-ideas] Make `import a.b.c as m` is equivalent to `m = sys.modules['a.b.c']`
by Victor Varvariuc April 9, 2017

April 9, 2017

Thanks for the reply. CC'ing the mailing list. > On 9 Apr 2017, at 10:05, Nick Coghlan <ncoghlan(a)gmail.com> wrote: > > On 9 April 2017 at 16:13, Victor Varvariuc <victor.varvariuc(a)gmail.com> wrote: >> I think there are can be several ways to achieve the result. >> >> The question is if what I've presented is a valid concern. I think this would make the language more consistent and help reducing number of errors related to import without breaking old code. >> >> May I create an issue in the bug tracker? > > Aye, go ahead - I would previously have advised against it, but given > at least one relatively low impact path to resolution, it's worth > filing it as an enhancement request. > > Cheers, > Nick. > > -- > Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia > Begin forwarded message: > > From: Nick Coghlan <ncoghlan(a)gmail.com> > Subject: Re: [Python-ideas] Make `import a.b.c as m` is equivalent to `m = sys.modules['a.b.c']` > Date: 9 April 2017 at 08:33:43 GMT+3 > To: Victor Varvariuc <victor.varvariuc(a)gmail.com> > > On 8 April 2017 at 22:57, Victor Varvariuc <victor.varvariuc(a)gmail.com> wrote: >> Thanks, Nick, for the thorough explanation. >> >> changing those semantics isn't as >> simple as just having the compiler reinterpret "import x.y.z as m" as >> "from x.y import z as m" >> >> >> I don't think this is a solution. >> >> The solution, IMO, is to treat `import x.y.z as m` as `m = >> __import__('x.y.z')` (or similar, IIRC). > > That's not quite how the `__import__` hook works: when the fromlist is > empty, it returns the *base* module, not the most resolved one. > >>>> __import__("unittest.mock") > <module 'unittest' from '/usr/lib64/python3.5/unittest/__init__.py'> > > However, the idea does indicate a potential resolution, which would be > to add a new IMPORT_ATTR opcode with roughly the following semantics: > > try: > _op_result = getattr(obj, ATTR) > except AttributeError: > _package_name = obj.__package__ > if not _package_name: > raise > _op_result = sys.modules[_package_name + "." + ATTR] > > And then have the import statement unconditionally emit IMPORT_ATTR > instead of LOAD_ATTR for the "import x.* as y" case. > > Cheers, > Nick. > > -- > Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

1 0

Make `import a.b.c as m` is equivalent to `m = sys.modules['a.b.c']`
by Victor Varvariuc April 8, 2017

April 8, 2017

Hi there. I asked a question <http://stackoverflow.com/questions/41845671/import-as-in-python-3> on Stackoverflow: (Pdb) import brain.utils.mail (Pdb) import brain.utils.mail as mail_utils *** AttributeError: module 'brain.utils' has no attribute 'mail' I always thought that import a.b.c as m is roughly equivalent to m = sys.modules['a.b.c']. Why AttributeError? Python 3.6 I was pointed out <http://stackoverflow.com/a/24968941/248296> that this is a somewhat weird behavior of Python: The statement is not quite true, as evidenced by the corner case you met, namely if the required modules already exist in sys.modules but are yet uninitialized. The import ... as requires that the module foo.bar is injected in foo namespace as the attribute bar, in addition to being in sys.modules, whereas the from ... import ... as looks for foo.bar in sys.modules. Why would `import a.b.c` work when `a.b.c` is not yet fully imported, but `import a.b.c as my_c` would not? I though it would be vice versa. Using `import a.b.c as my_c` allows avoiding a number of circular import issues. Right now I have to use `from a.b import c as my_c` as a workaround, but this doesn't look right. Does this make sense? Is there an issue in the Python bug tracker for this? Can/should I create one? Victor

2 1

Relative import of self or parent package?
by C Anthony Risinger April 8, 2017

April 8, 2017

I occasionally want to do something like this: import .. as parent or: import . as self The pattern is a little less useful for namespace packages (which I've been trying to use almost exclusively, along with relative imports) than it is for __init__.py based packages, but there is still some utility. Is there a reason one can't import dots directly and bind them to a name? I did not find any text around this and the closest I've come up with is: from .. import __name__ as parent_module_name parent = __import__(parent_module_name) Could we support relative imports without `from` so long as there is an `as`? Thanks, -- C Anthony

2 1