Mailman 3 September 2018 - Python-ideas

Fwd: Add Unicode-aware str.reverse() function?
by Stephan Houben 08 Sep '18

08 Sep '18

Op za 8 sep. 2018 13:33 schreef Paddy3118 <paddy3118(a)gmail.com>: > > I would like to propose that Python add a Unicode-aware *str.reverse *method. > The problem is, I'm a Brit, who only speaks English and only very rarely > dips into Unicode.* I don't know how useful this would be!* > To be honest, quite apart from the Unicode issue, I never had a need to reverse a string in real code. .ytilibigel edepmi ot sdnet yllareneg tI Stephan > Cheers, Paddy. > > > > _______________________________________________ > Python-ideas mailing list > Python-ideas(a)python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >

6 10

Re: [Python-ideas] Keyword only argument on function call
by David Mertz 08 Sep '18

08 Sep '18

> > I disagree. Those are examples of people being used to *positional > arguments* and this expecting that order to carry over. I don’t think > that’s a good argument because it presupposes that a habit of positional > arguments is good. > If 99% of existing code uses: pd.read_csv(fname, parse_dates=True, day_first=True) In preference to: pd.read_csv(fname, day_first=True, parse_dates=True) It seems pretty absurd to say that readability isn't harmed by someone choosing the "non-standard" order. Of course it still works the same for the library; but it's not the same for humans reading the code. There is one thing: my proposal wouldn’t result in a NameError at the > eval() call. You tried it out in a console but didn’t think about the > scoping properly. For your suggestion to work you have to copy paste that > helper function into the code at all scopes you want to use it. > This is just wrong. Assuming there is no 'd' available in the current scope, what could this POSSIBLY do other than raise a NameError: function(a=77, *, b, d) My little utility function decided to convert the NameError into a None value for the missing variable; but I mentioned that I'm not sure whether that's more useful behavior, and I'm not much attached to one or the other. function(a=77, **use('b d')) To make that helper function work you need to grab the stack frame and > extract the variables from there. You could absolutely do that though. > That’s pretty evil though. > Nope, there's absolutely no need to poke into the stack frame. It's just a regular closure over any variables that might exist in surrounding scopes. *Exactly* the same thing that your proposal would have to do. It makes absolutely no difference how deeply or shallowly nested the call to `use()` might be... A name like `d` simply is or is not available. Since the utility function doesn't have its own locals or formal parameters, nothing is changed by being one level deeper.[*] [*] Actually, that's not true. My implementation potentially steps on the three names `names`, `name` and `kws`. Perhaps those should be called `__names`, `__name`, and `__kws` to avoid that issue. If so, that's an easy change. -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.

1 0

Fwd: Add Unicode-aware str.reverse() function?
by Jonathan Fine 08 Sep '18

08 Sep '18

Paddy wrote > I would like to propose that Python add a Unicode-aware str.reverse method. > The problem is, I'm a Brit, who only speaks English and only very rarely > dips into Unicode. I don't know how useful this would be! Excellent post and piece of work. Well done! Here's someone who might know not only how useful, but also the wrinkles in doing it correctly: <quote> https://www.telecom-bretagne.eu/studies/msc/professors/haralambous/ Yannis Haralambous received his Ph.D. in Pure Mathematics from the Université de Sciences et Techniques de Lille-Flandre-Artois, Lille, France in 1990. He is currently working as a full-time Professor at Institut Mines-Telecom/Telecom Bretagne, Brest, in the Computer Science Department. His research areas include digital typography and representation of text, electronic documents, internationalization of documents, character encodings and the preservation of the cultural heritage of the book in the digital era. He is the author of Fonts & Encodings, to be published by O'Reilly in 2007 (French version : Fontes & codages, O'Reilly France, 2003). </quote> I know Yannis, so could approach him on behalf of this list. -- Jonathan

2 1

Re: [Python-ideas] Syntactic sugar to declare partial functions
by Michel Desmoulin 08 Sep '18

08 Sep '18

I'd rather have functools.partial() to be added as a new method on function objects. > > fromfunctools importpartial > > > def add(x:int,y:int)->int: > returnx +y > > > add_2 = partial(add,2) > Would become: add_2 = add.partial(2) Nothing to change on the parser, no obscure syntax for future readers, and we can get the opportunity of rewriting partial() in C as right now it is amazingly way, way slower than a lambda.

30 142

Re: [Python-ideas] Python-ideas Digest, Vol 142, Issue 22
by James Lu 07 Sep '18

07 Sep '18

What if * and ** forwarded all unnamed arguments to a function? Example: import traceback def print_http_response(request, color=True): ... def print_invalid_api_response(error, *, show_traceback=False, **): print_http_response(*, **) if show_traceback: traceback.print_last() else: print(error) This would essentially allow * and ** to be used to call a function without having to give a name: *args or **kwargs. However in this scenario, the client function is more likely to be “inheriting from” the behavior of the inner function, in a way where all or most of the arguments of the inner function are valid on the client function. Example: requests.get creates a Request object and immediately sends the response while blocking for it. > On Sep 6, 2018, at 3:27 PM, python-ideas-request(a)python.org wrote: > > Send Python-ideas mailing list submissions to > python-ideas(a)python.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.python.org/mailman/listinfo/python-ideas > or, via email, send a message with subject or body 'help' to > python-ideas-request(a)python.org > > You can reach the person managing the list at > python-ideas-owner(a)python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Python-ideas digest..." > > > Today's Topics: > > 1. Re: On evaluating features [was: Unpacking iterables for > augmented assignment] (Franklin? Lee) > 2. Re: On evaluating features [was: Unpacking iterables for > augmented assignment] (Chris Angelico) > 3. Re: Keyword only argument on function call (Jonathan Fine) > 4. Re: On evaluating features [was: Unpacking iterables for > augmented assignment] (Franklin? Lee) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 6 Sep 2018 14:38:26 -0400 > From: "Franklin? Lee" <leewangzhong+python(a)gmail.com> > To: Chris Angelico <rosuav(a)gmail.com> > Cc: Python-Ideas <python-ideas(a)python.org> > Subject: Re: [Python-ideas] On evaluating features [was: Unpacking > iterables for augmented assignment] > Message-ID: > <CAB_e7iyjcFLCCmnbviUDKZY6mXdv0Hs7-_4kUQEpZe8mVTzvbg(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > >> On Thu, Sep 6, 2018 at 2:23 PM Chris Angelico <rosuav(a)gmail.com> wrote: >> >> On Fri, Sep 7, 2018 at 4:11 AM, Franklin? Lee >> <leewangzhong+python(a)gmail.com> wrote: >>>> On Tue, Aug 28, 2018 at 6:37 PM Greg Ewing <greg.ewing(a)canterbury.ac.nz> wrote: >>>> >>>> Guido van Rossum wrote: >>>>> we might propose (as the OP did) that this: >>>>> >>>>> a, b, c += x, y, z >>>>> >>>>> could be made equivalent to this: >>>>> >>>>> a += x >>>>> b += y >>>>> c += z >>>> >>>> But not without violating the principle that >>>> >>>> lhs += rhs >>>> >>>> is equivalent to >>>> >>>> lhs = lhs.__iadd__(lhs) >>> >>> (Corrected: lhs = lhs.__iadd__(rhs)) >>> >>> Since lhs here is neither a list nor a tuple, how is it violated? Or >>> rather, how is it any more of a special case than in this syntax: >>> >>> # Neither name-binding or setitem/setattr. >>> [a,b,c] = items >>> >>> If lhs is a Numpy array, then: >>> a_b_c += x, y, z >>> is equivalent to: >>> a_b_c = a_b_c.__iadd__((x,y,z)) >>> >>> We can translate the original example: >>> a, b, c += x, y, z >>> to: >>> a, b, c = target_list(a,b,c).__iadd__((x,y,z)) >>> where `target_list` is a virtual (not as in "virtual function") type >>> for target list constructs. >> >> What is the virtual type here, and what does its __iadd__ method do? I >> don't understand you here. Can you go into detail? Suppose I'm the >> author of the class that all six of these objects are instances of; >> can I customize the effect of __iadd__ here in some way, and if so, >> how? > > I shouldn't have used jargon I had to look up myself. > > The following are equivalent and compile down to the same code: > a, b, c = lst > [a, b, c] = lst > > The left hand side is not an actual list (even though it looks like > one). The brackets are optional. The docs call the left hand side a > target list: https://docs.python.org/3/reference/simple_stmts.html#assignment-statements > > "Target list" is not a real type. You can't construct such an object, > or hold one in memory. You can't make a class that emulates it > (without interpreter-specific hacks), because it is a collection of > its names, not a collection of values. > > target_list.__iadd__ also does not exist, because target_list does not > exist. However, target_list can be thought of as a virtual type, a > type that the compiler compiles away. We can then consider > target_list.__iadd__ as a virtual operator, which the compiler will > understand but hide from the runtime. > > I was making the point that, because the __iadd__ in the example does > not refer to list.__iadd__, but rather a virtual target_list.__iadd__, > there is not yet a violation of the rule. > > > ------------------------------ > > Message: 2 > Date: Fri, 7 Sep 2018 04:46:36 +1000 > From: Chris Angelico <rosuav(a)gmail.com> > To: Python-Ideas <python-ideas(a)python.org> > Subject: Re: [Python-ideas] On evaluating features [was: Unpacking > iterables for augmented assignment] > Message-ID: > <CAPTjJmrauU+GD+Utcm=zUGFqWX5QXOhWLg5PL94s5OH_O8jLrQ(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > On Fri, Sep 7, 2018 at 4:38 AM, Franklin? Lee > <leewangzhong+python(a)gmail.com> wrote: >> The following are equivalent and compile down to the same code: >> a, b, c = lst >> [a, b, c] = lst >> >> The left hand side is not an actual list (even though it looks like >> one). The brackets are optional. The docs call the left hand side a >> target list: https://docs.python.org/3/reference/simple_stmts.html#assignment-statements >> >> "Target list" is not a real type. You can't construct such an object, >> or hold one in memory. You can't make a class that emulates it >> (without interpreter-specific hacks), because it is a collection of >> its names, not a collection of values. > > A target list is a syntactic element, like a name, or an operator, or > a "yield" statement. You can't construct one, because it isn't an > object type. It's not a "virtual type". It's a completely different > sort of thing. > >> target_list.__iadd__ also does not exist, because target_list does not >> exist. However, target_list can be thought of as a virtual type, a >> type that the compiler compiles away. We can then consider >> target_list.__iadd__ as a virtual operator, which the compiler will >> understand but hide from the runtime. >> >> I was making the point that, because the __iadd__ in the example does >> not refer to list.__iadd__, but rather a virtual target_list.__iadd__, >> there is not yet a violation of the rule. > > What you're suggesting is on par with trying to say that: > > for += 5 > > should be implemented as: > > current_loop.__iadd__(5) > > where "current_loop" doesn't really exist, but it's a virtual type > that represents a 'for' loop. That doesn't make sense, because there > is no object in Python to represent the loop. There is no class/type > that represents all loops, on which a method like this could be added. > The word 'for' is part of the grammar, not the object model. And > "target list" is the same. There's no way to attach an __iadd__ method > to something that doesn't exist. > > So for your proposal to work, you would need to break that rule, and > give a *different* meaning to this. > > ChrisA > > > ------------------------------ > > Message: 3 > Date: Thu, 6 Sep 2018 20:10:49 +0100 > From: Jonathan Fine <jfine2358(a)gmail.com> > To: Anders Hovm?ller <boxed(a)killingar.net> > Cc: python-ideas <python-ideas(a)python.org> > Subject: Re: [Python-ideas] Keyword only argument on function call > Message-ID: > <CALD=Yf8Ddn4MQnbLw+ouoac7YQedc_EsK8o5PyKuwetMuNMAbg(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Summary: I addressed the DEFINING problem. My mistake. Some rough > ideas for the CALLING problem. > > Anders has kindly pointed out to me, off-list, that I solved the wrong > problem. His problem is CALLING the function fn, not DEFINING fn. > Thank you very much for this, Anders. > > For calling, we can use https://docs.python.org/3/library/functions.html#locals > >>>> lcls = locals() > >>>> a = 'apple' >>>> b = 'banana' >>>> c = 'cherry' > >>>> dict((k, lcls[k]) for k in ('a', 'b', 'c')) > {'b': 'banana', 'c': 'cherry', 'a': 'apple'} > > So in his example > > foo(a=a, b=b, c=c, d=3, e=e) > > one could instead write > > foo(d=3, **helper(locals(), ('a', 'b', 'c', 'e'))) > > or perhaps better > > helper(locals(), 'a', 'b', 'c', 'e')(foo, d=3) > > where the helper() picks out items from the locals(). And in the > second form, does the right thing with them. > > Finally, one might be able to use > >>>> def fn(*, a, b, c, d, e): f, g, h = 3, 4, 5 >>>> fn.__code__.co_kwonlyargcount > 5 >>>> fn.__code__.co_varnames > ('a', 'b', 'c', 'd', 'e', 'f', 'g', 'h') >>>> fn.__code__.co_argcount > 0 > > to identify the names of all keyword arguments of the function foo(), > and they provide the values in locals() as the defaults. Of course, > this is somewhat magical, and requires strict conformance to > conventions. So might not be a good idea. > > The syntax could then be > > localmagic(foo, locals())(d=3) > > which, for magicians, might be easier. But rightly in my opinion, > Python is reluctant to use magic. > > On the other hand, for a strictly controlled Domain Specific Language, > it might, just might, be useful. And this list is for "speculative > language ideas" (see > https://mail.python.org/mailman/listinfo/python-ideas). > > -- > Jonathan > > > ------------------------------ > > Message: 4 > Date: Thu, 6 Sep 2018 15:26:47 -0400 > From: "Franklin? Lee" <leewangzhong+python(a)gmail.com> > To: Chris Angelico <rosuav(a)gmail.com> > Cc: Python-Ideas <python-ideas(a)python.org> > Subject: Re: [Python-ideas] On evaluating features [was: Unpacking > iterables for augmented assignment] > Message-ID: > <CAB_e7iyiM2ByZKxToNumtVRMTZr0S0K8-zyBykUbKYvv7AeQKQ(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > n Thu, Sep 6, 2018 at 2:47 PM Chris Angelico <rosuav(a)gmail.com> wrote: >> >> On Fri, Sep 7, 2018 at 4:38 AM, Franklin? Lee >> <leewangzhong+python(a)gmail.com> wrote: >>> The following are equivalent and compile down to the same code: >>> a, b, c = lst >>> [a, b, c] = lst >>> >>> The left hand side is not an actual list (even though it looks like >>> one). The brackets are optional. The docs call the left hand side a >>> target list: https://docs.python.org/3/reference/simple_stmts.html#assignment-statements >>> >>> "Target list" is not a real type. You can't construct such an object, >>> or hold one in memory. You can't make a class that emulates it >>> (without interpreter-specific hacks), because it is a collection of >>> its names, not a collection of values. >> >> A target list is a syntactic element, like a name, or an operator, or >> a "yield" statement. You can't construct one, because it isn't an >> object type. It's not a "virtual type". It's a completely different >> sort of thing. > > I didn't think I gave the impression that I was complaining about not > being able to construct it. I gave an explanation for how it isn't a > real type, because you asked how you could modify the behavior, and > because I wanted to give an explanation for more than just you. > > There are constructs that correspond to types (such as slices and > functions). There are those that don't. We call `3:2` (in the right > context) a slice, even though it's technically a construct which is > compiled down to a `slice` object. I see no problem there. > > I called it a "virtual type" and explained why I called it that. You > reject the use of that term, but you don't even acknowledge that I > gave reasons for it. > >>> target_list.__iadd__ also does not exist, because target_list does not >>> exist. However, target_list can be thought of as a virtual type, a >>> type that the compiler compiles away. We can then consider >>> target_list.__iadd__ as a virtual operator, which the compiler will >>> understand but hide from the runtime. >>> >>> I was making the point that, because the __iadd__ in the example does >>> not refer to list.__iadd__, but rather a virtual target_list.__iadd__, >>> there is not yet a violation of the rule. >> >> What you're suggesting is on par with trying to say that: >> >> for += 5 >> >> should be implemented as: >> >> current_loop.__iadd__(5) >> >> where "current_loop" doesn't really exist, but it's a virtual type >> that represents a 'for' loop. > > I explained how target_list could be thought of as a special imaginary > type which only exists in the compiler's "mind", and then extended > that to an imaginary method on that type. Of course your example shows > absurdity: you didn't try to say how a for-loop is like an object in > the first place. > >> That doesn't make sense, because there >> is no object in Python to represent the loop. There is no class/type >> that represents all loops, on which a method like this could be added. >> The word 'for' is part of the grammar, not the object model. And >> "target list" is the same. There's no way to attach an __iadd__ method >> to something that doesn't exist. > > But I'm not using the word `for`. I am using constructs like `[a,b,c]` > (where it is not a list). At least use `(for x in y: z) += 5` as your > example. You're effectively accusing me of trying to make `[` (a > single token, not a full construct) an object. > > Your argument here is that there is no Python object to represent a > loop, but that really means there's no _runtime_ object to represent a > loop. I already said that target lists don't exist in memory (i.e. > runtime). > > "Target list" does exist, just not as a runtime type. It exists as an > abstraction not available to the runtime, and we can extend that > abstraction in ways not available to the runtime. That means that you > can't attach it during the runtime. It does not mean you can't reason > with it during compile-time. > >> So for your proposal to work, you would need to break that rule, and >> give a *different* meaning to this. > > It is not my proposal. I was questioning how there was a rule > violation about x+=y translating to `x = x.__iadd__(y)`. You're > talking about a different, made-up rule about how syntactical > constructs can't correspond to compile-time imaginary objects or > runtime objects. But there are syntactical constructs that DO > correspond to runtime types (slice, list, class), there are those > which don't but can (let's not get into that), there are those which > can stay compile-time (f-strings, target lists), and there are those > which probably can't be thought of as types at all (import). > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Python-ideas mailing list > Python-ideas(a)python.org > https://mail.python.org/mailman/listinfo/python-ideas > > > ------------------------------ > > End of Python-ideas Digest, Vol 142, Issue 22 > *********************************************

2 1

Re: [Python-ideas] Positional-only parameters
by Yury Selivanov 06 Sep '18

06 Sep '18

On Fri, Sep 7, 2018 at 12:31 AM Anders Hovmöller <boxed(a)killingar.net> wrote: > > Yury, > > I’m sorry if that came off badly, I was not attempting to be snarky. Text is hard and I know I’m not good in emails but rereading the text below I honestly can’t see why my honest attempt at describing my experience can be considered snarky. > > I haven’t sought out to discuss positional only parameters, this is something that has just come up in conversation from time to time over the last few years and this has been the response. > > If you would explain how you interpreted my mail in this way I would of course be thankful but I also don’t want to take more of your time. Sure. (If you choose to reply to this email please do that off-list.) IMHO your email lacks substance, uses rather strong words like "disgust" and "disbelief", and ends with "I don't think that's a good look for Python :P" phrase that doesn't help you to make any point. You re-surfaced a pretty old email thread where a number of core developers explained their position and listed quite a few arguments for having positional-only arguments. You, on the other hand, didn't add a lot to the discussion except your own opinion with no serious arguments to support it. Please don't feel discouraged from posting to python-ideas though, just try to keep a higher signal-to-noise ratio. ;) Yury

1 0

Re: [Python-ideas] Python-ideas Digest, Vol 141, Issue 145
by James Lu 06 Sep '18

06 Sep '18

> As Matthew points out, you could use numpy.array. Or code your own > class, by providing __add__ and __iadd__ methods. > > >>> import numpy > >>> a = numpy.array([1, 2]) > >>> b = numpy.array([3, 4]) > >>> a + b > array([4, 6]) > >>> a += b > >>> a > array([4, 6]) I could, but I don't think that justifies not having this functionality in python standard. From the language experience perspective, numpy is often a pain to install on most systems. If I'm designing card games and I just want to run a quick monte carlo simulation, the experience should be as smooth as possible. This is something I think most students will expect while learning python, especially if they're implementing algorithms. On Mon, Aug 27, 2018 at 4:24 AM <python-ideas-request(a)python.org> wrote: > Send Python-ideas mailing list submissions to > python-ideas(a)python.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.python.org/mailman/listinfo/python-ideas > or, via email, send a message with subject or body 'help' to > python-ideas-request(a)python.org > > You can reach the person managing the list at > python-ideas-owner(a)python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Python-ideas digest..." > > > Today's Topics: > > 1. Re: Unpacking iterables for augmented assignment (Matthew Einhorn) > 2. Re: Unpacking iterables for augmented assignment (Jonathan Fine) > 3. Re: Pre-conditions and post-conditions (Jacco van Dorp) > 4. Re: Pre-conditions and post-conditions (Ivan Levkivskyi) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 27 Aug 2018 01:29:14 -0400 > From: Matthew Einhorn <moiein2000(a)gmail.com> > To: python-ideas(a)python.org > Subject: Re: [Python-ideas] Unpacking iterables for augmented > assignment > Message-ID: > <CALCauYeAjPWek5L=BU-= > yMM-FNYw3Bza2hJqsGmdgtrvBUa7XA(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Sun, Aug 26, 2018, 9:24 PM James Lu <jamtlu(a)gmail.com> wrote: > > > Hi Johnathan > > > > I echo your points. Indeed, the PEP referenced to refers to a "tuple > > expression" in the grammatical and not the programmatic sense. > > > > Finally, here's something that surprised me a little bit > > > > >>> x = [1, 2]; id(x) > > 140161160364616 > > >>> x += [3, 4]; id(x) > > 140161160364616 > > > > >>> x = (1, 2); id(x) > > 140161159928520 > > >>> x += (3, 4); id(x) > > 140161225906440 > > > > Notice that '+=' creates uses the same object when the object is > > a > > list, but creates a new object. This raises the question: Why and > > how > > does Python behave in this way? > > > > It's because lists are mutable are tuples are immutable. > > There's a dunder iadd method and a dunder add method. > > iadd magic methods, operating on the left hand side, return None and > > modify the object in-place. add magic methods return the result and > > don't modify the object it's called on. > > iadd is mutable add, whereas add is "return a copy with the result > > added" > > > > >>> tuple.__iadd__ > > Traceback (most recent call last): > > File "<stdin>", line 1, in <module> > > AttributeError: type object 'tuple' has no attribute '__iadd__' > > type object 'tuple' has no attribute '__iadd__' > > >>> tuple.__add__ > > <slot wrapper '__add__' of 'tuple' objects> > > >>> list.__iadd__ > > <slot wrapper '__iadd__' of 'list' objects> > > >>> list.__add__ > > <slot wrapper '__add__' of 'list' objects> > > > > > > tuple1 = tuple1.__add__(tuple2) > > > > list1.__iadd__(list2) > > > > > Does it IN PRACTICE bring sufficient benefits to users? > > > > I found myself needing this when I was writing a monte-carlo > > simulation in python that required incrementing a tallying counter > > from a subroutine. > > > > > Wouldn't a numpy array be very suited for this kind of task? > > > >

15 23

Executable space protection: NX bit,
by Wes Turner 04 Sep '18

04 Sep '18

Rationale ========= - Separation of executable code and non-executable data is a good thing. - Additional security in Python is a good idea. - Python should support things like the NX bit to separate code and non-executable data. Discussion ========== How could Python implement support for the NX bit? (And/or additional modern security measures; as appropriate). What sort of an API would C extensions need? Would this be easier in PyPy or in CPython? - https://en.wikipedia.org/wiki/NX_bit - https://en.wikipedia.org/wiki/Executable_space_protection Here's one way to identify whether an executable supports NX: https://github.com/longld/peda/blob/e0eb0af4bcf3ee/peda.py#L2543

8 13

Re: [Python-ideas] Add recordlcass to collections module
by Wes Turner 04 Sep '18

04 Sep '18

On Sunday, September 2, 2018, Zaur Shibzukhov <szport(a)gmail.com> wrote: > > > --- > *Zaur Shibzukhov* > > > 2018-09-02 22:11 GMT+03:00 Wes Turner <wes.turner(a)gmail.com>: > >> Does the value of __hash__ change when attributes of a recordclass change? >> > > Currently recordclass's __hash__ didn't implemented. > https://docs.python.org/3/glossary.html#term-hashable https://docs.python.org/3/reference/datamodel.html#object.__hash__ http://www.attrs.org/en/stable/hashing.html > >> On Sunday, September 2, 2018, Zaur Shibzukhov <szport(a)gmail.com> wrote: >> >>> As the author of `recordclass` I would like to shed some light... >>> >>> Recorclass originated as a response to the [question]( >>> https://stackoverflow.com/questions/29290359/exis >>> tence-of-mutable-named-tuple-in-python/29419745#29419745) on >>> stackoverflow. >>> >>> `Recordclass` was conceived and implemented as a type that, by api, >>> memory and speed, would be completely identical to` namedtuple`, except >>> that it would support an assignment in which any element could be replaced >>> without creating a new instance, as in ` namedtuple`. Those. would be >>> almost identical to `namedtuple` and support the assignment (` __setitem__` >>> / `setslice__`). >>> >>> The effectiveness of namedtuple is based on the effectiveness of the >>> `tuple` type in python. In order to achieve the same efficiency it was >>> necessary to create a type `memoryslots`. Its structure >>> (`PyMemorySlotsObject`) is identical to the structure of` tuple` >>> (`PyTupleObject`) and therefore takes up the same amount of memory as` >>> tuple`. >>> >>> `Recordclass` is defined on top of` memoryslots` just like `namedtuple` >>> above` tuple`. Attributes are accessed via a descriptor (`itemgetset`), >>> which supports both` __get__` and `__set__` by the element index. >>> >>> The class generated by `recordclass` is: >>> >>> `` ` >>> from recordclass import memoryslots, itemgetset >>> >>> class C (memoryslots): >>> __slots__ = () >>> >>> _fields = ('attr_1', ..., 'attr_m') >>> >>> attr_1 = itemgetset (0) >>> ... >>> attr_m = itemgetset (m-1) >>> >>> def __new __ (cls, attr_1, ..., attr_m): >>> 'Create new instance of {typename} ({arg_list})' >>> return memoryslots .__ new __ (cls, attr_1, ..., attr_m) >>> `` ` >>> etc. following the `namedtuple` definition scheme. >>> >>> As a result, `recordclass` takes up as much memory as` namedtuple`, it >>> supports quick access by `__getitem__` /` __setitem__` and by attribute >>> name via the protocol of the descriptors. >>> >>> Regards, >>> >>> Zaur >>> >>> суббота, 1 сентября 2018 г., 10:48:07 UTC+3 пользователь Martin Bammer >>> написал: >>>> >>>> Hi, >>>> >>>> what about adding recordclass >>>> (https://bitbucket.org/intellimath/recordclass) to the collections >>>> module >>>> >>>> It is like namedtuple, but elements are writable and it is written in C >>>> and thus much faster. >>>> >>>> And for convenience it could be named as namedlist. >>>> >>>> Regards, >>>> >>>> Martin >>>> >>>> >>>> _______________________________________________ >>>> Python-ideas mailing list >>>> Python...(a)python.org >>>> https://mail.python.org/mailman/listinfo/python-ideas >>>> Code of Conduct: http://python.org/psf/codeofconduct/ >>>> >>> >

4 3

Re: [Python-ideas] Pre-conditions and post-conditions
by Hugh Fisher 03 Sep '18

03 Sep '18

> Date: Thu, 30 Aug 2018 00:07:04 +0200 > From: Marko Ristin-Kaufmann <marko.ristin(a)gmail.com> ... > I think we got entangled in a discussion about whether design-by-contract > is useful or not. IMO, the personal experience ("I never used/needed this > feature") is quite an inappropriate rule whether something needs to be > introduced into the language or not. > > There seems to be evidence that design-by-contract is useful. Let me cite > Bertrand Meyer from his article "Why not program right?" that I already > mentioned before: I don't think that being useful by itself should be enough. I think new features should also be "Pythonic" and I don't see design by contract notation as a good fit. For example, C has the useful & operator which lets you pass &foo as a pointer/array argument despite foo being a scalar, so assignment to bar[0] in the called function actually sets the value of foo. It might be possible to create some kind of aliasing operator for Python so that two or more variables were bound to the same location, but would we want it? No, because Python is not intended for that style of programming. For another example, GPU shading languages have the special keywords uniform and varying for distinguishing definitions that won't change across parallel invocations and definitions that will. Demonstrably very useful in computer games and supercomputer number crunching, so why doesn't Python have those keywords? Because it's not designed to be used for such. For design by contract, as others have noted Python assert statements work fine for simple preconditions and postconditions. I don't see any significant difference in readability between existing def foo(x, y): assert(x > 0) # Do stuff assert(x == y) and new style def foo(x, y): require: x > 0 # Do stuff ensure: x == y Yes there's more to design by contract than simple assertions, but it's not just adding syntax. Meyer often uses the special "old" construct in his post condition examples, a trivial example being ensure count = old.count + 1 How do we do that in Python? And another part of design by contract (at least according to Meyer) is that it's not enough to just raise an exception, but there must be a guarantee that it is handled and the post conditions and/or invariants restored. So there's more syntax for "rescue" and "retry" If you want to do simple pre and post conditions, Python already has assert. If you want to go full design by contract, there's no law saying that Python is the only programming language allowed. Instead of trying to graft new and IMHO alien concepts onto Python, what's wrong with Eiffel? -- cheers, Hugh Fisher

9 12