Mailman 3 March 2017 - Python-ideas

__repr__: to support pprint
by 语言破碎处 March 1, 2017

March 1, 2017

Hi, everyone! Oftenly, __repr__ return "{type}({args}, {kws})" problem: 1) to call .format() myself is tedious I have seen someone do it wrong: "T(1,)"! I write a helper function myself, but to import such tiny function everywhere isnot good. 2) pprint cannot dive into string that from repr() To use pprint, I sometimes have to recursively turn objects into builtin containers: (type_name, args...) solution: allow __repr__ to return str OR tuple: (args, kws) Better, isn't it?

8 10

add a always turn on "assert"
by 语言破碎处 March 1, 2017

March 1, 2017

"assert" is good, but it is used as a guard frequently. We can make such usage legal by adding a new syntax: assert bool_expr, ExceptionType, True suggest reasons: 1) even "__debug__" turn off, assert is working assertion as guard. 2) to avoid boilerplate code I write code like this: if pred(....) or pred(....): raise ValueError('pred(....) or pred(....)') Simplifed: assert pred(...), ValueError, True # the above line will be printed when error. # I need not to copy the condition! 3) future: "assert bool_expr, ET, False" To aid static tool, like Proof System. Better document. For complicate algorithm, I actually add a invariant outline comment above every statement.

2 1

Re: [Python-ideas] for/except/else
by Wolfgang Maier March 1, 2017

March 1, 2017

On 01.03.2017 12:56, Steven D'Aprano wrote: > On Wed, Mar 01, 2017 at 10:37:17AM +0100, Wolfgang Maier wrote: > >> Now here's the proposal: allow an except (or except break) clause to >> follow for/while loops that will be executed if the loop was terminated >> by a break statement. > > Let me see if I understand the proposal in full. You would allow: > > > for i in (1, 2, 3): > print(i) > if i == 2: > break > except break: # or just except > assert i == 2 > print("a break was executed") > else: > print("never reached") # this is never reached > print("for loop is done") > > > as an alternative to something like: > > > broke_out = False > for i in (1, 2, 3): > print(i) > if i == 2: > broke_out = True > break > else: > print("never reached") # this is never reached > if broke_out: > assert i == 2 > print("a break was executed") > print("for loop is done") > > correct. > I must admit the suggestion seems a little bit neater than having to > manage a flag myself, but on the other hand I can't remember the last > time I've needed to manage a flag like that. > > And on the gripping hand, this is even simpler than both alternatives: > > for i in (1, 2, 3): > print(i) > if i == 2: > assert i == 2 > print("a break was executed") > break > else: > print("never reached") # this is never reached > print("for loop is done") > Right, that's how you'd likely implement the behavior today, but see my argument about the two alternative code branches not ending up together at the same level of indentation. > > > There are some significant unanswered questions: > > - Does it matter which order the for...except...else are in? > Obviously the for block must come first, but apart from that? > Just like in try/except/else, the order would be for (or while)/except/else with the difference that both except and else would be optional. > - How is this implemented? Currently "break" is a simple > unconditional GOTO which jumps past the for block. This will > need to change to something significantly more complex. > Yeah, I know that's why I listed this under cons. > - There are other ways to exit a for-loop than just break. Which > of them, if any, will also run the except block? > None of them (though, honestly, I cannot think of anything but exceptions here; what do you have in mind?) > >

1 0

a bad feature in Python syntax
by 语言破碎处 March 1, 2017

March 1, 2017

I'm bited once: >>> '' in {} == False False >>> ('' in {}) == False True # '' in {} == False ==>> ('' in {}) and ({} == False) ==>> False! I think only compare operations should be chained.

4 3

Expose a child factory using MappingProxyType in builtins
by Michel Desmoulin March 1, 2017

March 1, 2017

We have the immutable frozenset for sets and and tuples for lists. But we also have something to manipulate dict as immutable datastructures: >>> from types import MappingProxyType as idict >>> d = idict({'a':1, 'b':2, 'c':3}) >>> d['a'] = 4 Traceback (most recent call last): File "<ipython-input-3-c6f93d6278af>", line 1, in <module> d['a'] = 4 TypeError: 'mappingproxy' object does not support item assignment We could expose this as a built type to allow the last of the most important data structure in Python to be easily immutable.

7 7

add variable "__this_func__" inside all functions' locals
by 语言破碎处 March 1, 2017

March 1, 2017

How a function refer itself? def f(): f() # fine... really??? consider these situations: 1) decorator @xxx def f():... # how can I access the wrapped version? 2) replace by other def f(): f() # call second!! a = T(f) # to call first def f():... 3) refactor: rename function # first version def f():f() ------------------- # second version, wrap it def f(): log(); try: # to avoid indent _f_impl() except... def _f_impl(): _f_impl() # hadnot we rename it! solution: # add __this_func__ class C: @xxxx def f(self): self.f() __class__.f(self) __this_func__(self)

3 3

Re: [Python-ideas] unify usage of mutable and immutable objects
by 语言破碎处 March 1, 2017

March 1, 2017

> We are not going to change the implementation of sets so fundamentally, > mostly because having O(1) behaviors is so nice (add, remove, membership > check, etc). What I want are such interfaces (no matter with standard set): class IDynSet: # "Dyn" means it have methods like ipop_both def ipop_both(self): if hasattr(self, 'pop_mutable'): elem = self.pop_mutable() elif hasattr(self, 'ipop_immutable'): elem, self = self.ipop_immutable() else: raise return elem, self class IMutableDynSet(IDynSet): def pop_mutable(self): return self.pop() class IImutableDynSet(IDynSet): def ipop_immutable(self): elem, new = self.ipop() # ipop not pop return elem, new

1 0

unify usage of mutable and immutable objects
by 语言破碎处 March 1, 2017

March 1, 2017

Hi! I write a '<'-based immutable set class. But it is quit different from the standard set class. I wish collections.abc.Set be more friendly to immutable tree sets or Python add new syntax to unify such difference. good example: a = [] a += a # "a" is the original list a = () a += a # "a" is a new tuple bad example: a = set() a.add(1) # return None; "a" changed e = a.pop(); a = frozen_tree_set() a = a.add(1) # return another set; e, a = a.ipop() # return two objects instead of one! solution I used: a <<= 1 # <==> a = a.add(1) but "a.ipop()" .... my current solution is to write a wrapper class to turn immutable set into mutable set, but it is so noisy to box and unbox. solution that I wish: a :=.add(1) # "=." mimic "+="; return the result object e ~ a :=.pop() d[key] :=.add(1) # in dict if only python add following features: 1) modify the original object 1-0) 1) define: def .method(self):... # "." means "intend to modify self" # return any thing # to avoid immutable method # which was intended to return new object # leave self unchanged 2) invoke: r = a..method(); 1-1) ignore result # no matter what returned, discard it a.-.method(); # <==> [a..method(), None][-1] 1-2) return self # no matter what returned, return self a.>.method().>.method();# <==> [a..method(), a..method(), a][-1] 2) create new object 2-0) 1) define # intend to return (result, new object) def ^method():... 2)invoke: r, a' = a.^method(); 2-1) return other, discard result a.-^method().-^method();# <==> a.^method()[1].^method()[1]; 2-2) assign other to original variable a=^method(); # <==> a = a.^method()[1]; 3) unify both: a :=.method(); # if defined ".method" then "a..method();" # elif defined "^method" then "a = a.^method()[1];" # elif defined "method" then "a.method();" # else error r ~ a :=.method(); # if defined ".method" then "r = a..method();" # elif defined "^method" then "r, a = a.^method();" # elif defined "method" then "r = a.method();" # else error

4 7

Re: [Python-ideas] add __contains__ into the "type" object
by 语言破碎处 March 1, 2017

March 1, 2017

TYPE is not a collection! But conceptually it is a SET, set of all its possible instances. quot: "Types and Programming Languages (2002)(Benjamin C. Pierce)" [page 92] Chapter 8 Typed Arithmetic Expressions "a term t has type T" (or "t belongs to T," or "t is an element of T") An object obj has a type T or obj is a type T <==> obj belongs to T So, "obj in T" is fine. e.g. "1 in int" means 1 is in the whole number set. > > Note that TYPE is SET; > What does that mean? I don't understand. > > obj in T; > But obj is **not** in T, since T is a type, not a container. > "is-a" tests are not the same as "in" tests. They are completely > unrelated comparisons.

1 0