Re: [Python-ideas] get() method for list and tuples

On 02/28/2017 06:02 PM, Michel Desmoulin wrote: Le 01/03/2017 à 02:23, Ethan Furman a écrit : On 02/28/2017 05:18 PM, Michel Desmoulin wrote: I love this proposal but Guido rejected it. Fighting for it right now would probably be detrimental to the current proposed feature which could potenti

Re: [Python-ideas] a bad feature in Python syntax

OK, I'm impressed! I've written about and taught Python for almost 20 years. I never realized `in` was a chained comparison. I'm pretty sure I've never seen it used that way "in the wild." I also never tried using `is` in a chained way until just now. That said, there are at least three things

[Python-ideas] add a always turn on "assert"

"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:

Re: [Python-ideas] a bad feature in Python syntax

On Wed, Mar 1, 2017 at 1:56 PM, 语言破碎处 wrote: > I'm bited once: > >>> '' in {} == False > False > >>> ('' in {}) == False > True > > # '' in {} == False ==>> ('' in {}) and ({} == False) ==>> False! > > I think only compare operations should be chained. I do feel your pain, but

Re: [Python-ideas] add variable "__this_func__" inside all functions' locals

> On Feb 28, 2017, at 8:14 PM, 语言破碎处 wrote: > > We need not care other functions, just the "current" one. > Other functions are definitely out of our control. > My last example distinguish 3 cases: > self.f()# object/overloaded version > __class__.f(self) # decorated ve

[Python-ideas] a bad feature in Python syntax

I'm bited once: >>> '' in {} == False False >>> ('' in {}) == False True # '' in {} == False ==>> ('' in {}) and ({} == False) ==>> False! I think only compare operations should be chained. ___ Python-ideas mailing list Python-ide

Re: [Python-ideas] __repr__: to support pprint

It has not to break current code: def repr(obj, allowed_tuple = False): r = type(obj).__repr__() if allowed_tuple: return r if isinstance(r, tuple): r = make_str(type(obj), r) return r At 2017-03-01 09:58:35, "Matthias welp" wr

Re: [Python-ideas] unify usage of mutable and immutable objects

> 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

Re: [Python-ideas] add variable "__this_func__" inside all functions' locals

We need not care other functions, just the "current" one. Other functions are definitely out of our control. My last example distinguish 3 cases: self.f()# object/overloaded version __class__.f(self) # decorated version __this_func__(self) # prime version A

Re: [Python-ideas] get() method for list and tuples

On Wed, Mar 01, 2017 at 02:26:18AM +0100, Michel Desmoulin wrote: > The fact the API is not exactly the same doesn't prevent duck typing. > Duck typing is precesily about incomplete but good enough similar API. Indeed. But the relationship goes this way: # Duck-typing done the right way.

Re: [Python-ideas] get() method for list and tuples

On Wed, Mar 1, 2017 at 1:02 PM, Michel Desmoulin wrote: > Le 01/03/2017 à 02:23, Ethan Furman a écrit : >> On 02/28/2017 05:18 PM, Michel Desmoulin wrote: >> >>> I love this proposal but Guido rejected it. Fighting for it right now >>> would probably be detrimental to the current proposed feature

Re: [Python-ideas] __repr__: to support pprint

On Wed, Mar 1, 2017 at 12:58 PM, Matthias welp wrote: > You are free to experiment with overriding/extending __repr__ for your > internal usage, but please note that it might break external libraries > depending on obj.__repr__ or repr(obj), and print() might break when > using built-in types as c

Re: [Python-ideas] get() method for list and tuples

Le 01/03/2017 à 02:23, Ethan Furman a écrit : > On 02/28/2017 05:18 PM, Michel Desmoulin wrote: > >> I love this proposal but Guido rejected it. Fighting for it right now >> would probably be detrimental to the current proposed feature which >> could potentially be more easily accepted. > > PEP

Re: [Python-ideas] __repr__: to support pprint

Hi, On 1 March 2017 at 02:18, qhlonline wrote: > Yes, We are both python users with languages OTHER then English, It is a > headache when looking at the print output of dicts with other language > encoding. They are just byte array. I am using python2.7 Please note that unless this is still a

Re: [Python-ideas] get() method for list and tuples

> > I am aware of that. I'm just saying you don't have to use try...except, > you can use slicing instead. Obviously you have to adapt the code since > you are getting a list not a single item: > > # may fail, if alist is empty > if alist[0] == "spam": ... > > # cannot fail > if alist[0:1] ==

Re: [Python-ideas] suggestion about the sort() function of the list instance

On Tue, Feb 28, 2017 at 09:30:37PM -0300, Soni L. wrote: > Stateful functions? What? -- Steve ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofcon

Re: [Python-ideas] __repr__: to support pprint

Yes, We are both python users with languages OTHER then English, It is a headache when looking at the print output of dicts with other language encoding. They are just byte array. I am using python2.7 Regards! At 2017-03-01 06:59:52, "语言破碎处" wrote: Hi, everyone! Oftenly, __repr__ return

Re: [Python-ideas] suggestion about the sort() function of the list instance

My code example is not proper, Yes, may be this is better: list.sort().revers(). Other languages do this differently. JavaScript may return the sorted, while C++ STL returns nothing. I think that it maybe more important to let user have good knowledge about this function then to have fluent

Re: [Python-ideas] unify usage of mutable and immutable objects

On Tue, Feb 28, 2017 at 1:49 PM, Terry Reedy wrote: > On 2/28/2017 1:48 PM, David Mertz wrote: > >> In [30]: class FrozenSet(frozenset): >> ...: def pop(self): >> ...: item = next(iter(self)) >> ...: return item, self-{item} >> >> In [31]: a = F

Re: [Python-ideas] add variable "__this_func__" inside all functions' locals

Hi, On 1 March 2017 at 01:12, 语言破碎处 wrote: > > How a function refer itself? > def f(): > f() # fine... really??? I understand your question as the following: "Should functions be allowed to point to themselves/the as of construction time unbound variable in the function body, as they

Re: [Python-ideas] get() method for list and tuples

Le 01/03/2017 à 01:02, Steven D'Aprano a écrit : > On Tue, Feb 28, 2017 at 07:10:15PM +0100, Sven R. Kunze wrote: > >> 1. advantage: it looks like dict access -> allows duck typing (oh how >> often I'd missed that) > > Dicts and lists don't duck-type because they are very different things. >

Re: [Python-ideas] get() method for list and tuples

On 02/28/2017 05:18 PM, Michel Desmoulin wrote: I love this proposal but Guido rejected it. Fighting for it right now would probably be detrimental to the current proposed feature which could potentially be more easily accepted. PEP 463 has a better chance of being accepted than this one does,

Re: [Python-ideas] get() method for list and tuples

I love this proposal but Guido rejected it. Fighting for it right now would probably be detrimental to the current proposed feature which could potentially be more easily accepted. At least let's make it a separate thread. I would love to restart the debate about this one. This is one of my most w

Re: [Python-ideas] get() method for list and tuples

On 28/02/2017 11:54, Michel Desmoulin wrote: dict.get() is a very useful method, but for lists and tuples, we need to rely on try/except instead. Can we get list.get and tuple.get as well? If PEP 463 "Exception-catching expressions" were accepted and implemented, we wouldn't need any of them:

Re: [Python-ideas] __repr__: to support pprint

On Wed, Mar 01, 2017 at 06:59:52AM +0800, 语言破碎处 wrote: > solution: > allow __repr__ to return > str > OR tuple: (args, kws) > > Better, isn't it? No. -- Steve ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailma

Re: [Python-ideas] Expose a child factory using MappingProxyType in builtins

I would be very happy to see a frozendict in collections :) Just for curiosity ; apart caching, is there any optimization that can be done on a frozendict implementation (over dict) ? I wonder if frozendict would be implemented as dict without modification methods, or as a particular object that

Re: [Python-ideas] add __contains__ into the "type" object

On 2/28/2017 6:35 PM, Jelle Zijlstra wrote: 2017-02-28 15:12 GMT-08:00 Steven D'Aprano : On Wed, Mar 01, 2017 at 07:02:23AM +0800, 语言破碎处 wrote: where we use types? almost: isinstance(obj, T); # issubclass(S, T); Note that TYPE is SET; What does that mean? I don't underst

Re: [Python-ideas] suggestion about the sort() function of the list instance

On 28/02/17 09:13 PM, Steven D'Aprano wrote: On Mon, Feb 27, 2017 at 11:07:33AM +0800, qhlonline wrote: Hi, all I have a suggestion that, the sort() member method of the list instance, should return the 'self' as the result of list.sort() call. Having list.sort() and list.rever

Re: [Python-ideas] suggestion about the sort() function of the list instance

On Mon, Feb 27, 2017 at 11:07:33AM +0800, qhlonline wrote: > Hi, all > I have a suggestion that, the sort() member method of the list > instance, should return the 'self' as the result of list.sort() > call. Having list.sort() and list.reverse() return self is a perfectly good desi

[Python-ideas] add variable "__this_func__" inside all functions' locals

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: r

Re: [Python-ideas] add __contains__ into the "type" object

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 ob

Re: [Python-ideas] get() method for list and tuples

On Tue, Feb 28, 2017 at 07:10:15PM +0100, Sven R. Kunze wrote: > 1. advantage: it looks like dict access -> allows duck typing (oh how > often I'd missed that) Dicts and lists don't duck-type because they are very different things. We know what ["item"]*10 does. What would {"key": "value"}*10 d

Re: [Python-ideas] get() method for list and tuples

On Tue, Feb 28, 2017 at 04:16:28PM +0100, Michel Desmoulin wrote: > > > Le 28/02/2017 à 15:45, Steven D'Aprano a écrit : > > On Tue, Feb 28, 2017 at 12:54:26PM +0100, Michel Desmoulin wrote: > >> dict.get() is a very useful method, but for lists and tuples, we need to > >> rely on try/except inst

Re: [Python-ideas] unify usage of mutable and immutable objects

> A hypothetical frozenset.pop() is also necessarily O(N). It needs to copy > N-1 elements into the new (smaller) frozenset object. So this isn't an > argument. Pop tuple/frozenset(standard one) gain no benefit. # O(n) It is a different story for balanced tree. # O(log n) > Sounds like `coll

Re: [Python-ideas] add __contains__ into the "type" object

2017-02-28 15:12 GMT-08:00 Steven D'Aprano : > On Wed, Mar 01, 2017 at 07:02:23AM +0800, 语言破碎处 wrote: >> >> where we use types? >> almost: >> isinstance(obj, T); >> # issubclass(S, T); >> >> Note that TYPE is SET; > > What does that mean? I don't understand. > > >> if we add

[Python-ideas] lazy use for optional import

I have seen some interest into lazy functionality implementation. I wondered if it can be linked with optional import. PEP 8 authoritatively states: Imports are always put at the top of the file, just after any module comments and docstrings, and before

Re: [Python-ideas] add __contains__ into the "type" object

On Wed, Mar 01, 2017 at 07:02:23AM +0800, 语言破碎处 wrote: > > where we use types? > almost: > isinstance(obj, T); > # issubclass(S, T); > > Note that TYPE is SET; What does that mean? I don't understand. > if we add __contains__ and __le__ into "type", > then things be

Re: [Python-ideas] unify usage of mutable and immutable objects

On Tue, Feb 28, 2017 at 2:57 PM, 语言破碎处 wrote: > 1) coverting to set or list is O(n) in time > A hypothetical frozenset.pop() is also necessarily O(N). It needs to copy N-1 elements into the new (smaller) frozenset object. So this isn't an argument. > 2) if I have to keep the old copy, >

[Python-ideas] add __contains__ into the "type" object

where we use types? almost: isinstance(obj, T); # issubclass(S, T); Note that TYPE is SET; if we add __contains__ and __le__ into "type", then things become: obj in T; # S <= T; # if only not misleading to a total ordering example: def __getitems_

[Python-ideas] __repr__: to support pprint

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 div

Re: [Python-ideas] unify usage of mutable and immutable objects

> To me, 'pop' implies mutation. Tuples do not have a pop method, and it > is not obvious to me that either tuples or frozensets should. What are > the > use cases that are not better served by converting to list or set? > -- > Terry Jan Reedy 1) coverting to set or list is O(n) in time 2) if I

Re: [Python-ideas] Positional-only parameters

> I just noticed a module on PyPI to implement this behaviour on Python > functions: > https://pypi.python.org/pypi/positional This library seem to do the opposite of what you ask and force kwarg only. In [11]: @positional.positional(1) ...: def foo(a=1,b=2): ...: print(a,b) .

Re: [Python-ideas] Expose a child factory using MappingProxyType in builtins

2017-02-28 13:17 GMT+01:00 Michel Desmoulin : > 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

Re: [Python-ideas] Positional-only parameters

On 28.02.2017 22:17, Victor Stinner wrote: > Hi, > > For technical reasons, many functions of the Python standard libraries > implemented in C have positional-only parameters. Keyword argument handling is comparatively slow and rarely needed for non-optional positional parameters of built-ins. Y

Re: [Python-ideas] Positional-only parameters

https://www.python.org/dev/peps/pep-0457/ https://mail.python.org/pipermail/python-dev/2014-January/131865.html -- ~Ethan~ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http

Re: [Python-ideas] Positional-only parameters

I think that was started as pep 457: https://www.python.org/dev/peps/pep-0457/ (Syntax For Positional-Only Parameters) Still informal. +1, it's likely possible to backport it to previous version using a decorator and faking __signature__. -- M On Tue, Feb 28, 2017 at 2:03 PM, Yury Selivanov

Re: [Python-ideas] Positional-only parameters

On 28 Feb 2017, at 22:17, Victor Stinner wrote: I just noticed a module on PyPI to implement this behaviour on Python functions: https://pypi.python.org/pypi/positional Tangential to the main topic, but this module doesn’t enforce positional-only arguments. It allows you enforce keyword-

Re: [Python-ideas] Positional-only parameters

I'm +0.5 to add positional-only parameters. Pros: * A lot of people don't know what '/' currently means in functions signatures rendered by `help` and docs. Because it's not a real syntax, it's really hard to find what it means. * Some APIs do look better with positional-only parameters, espec

Re: [Python-ideas] unify usage of mutable and immutable objects

On 2/28/2017 1:48 PM, David Mertz wrote: So it sounds like what you want is this: In [30]: class FrozenSet(frozenset): ...: def pop(self): ...: item = next(iter(self)) ...: return item, self-{item} ...: In [31]: a = FrozenSet({1,2,3,4,

[Python-ideas] Optional argument to fnmatch functions treat * and ** differently

Hello, I would like fnmatch.fnmatch to have a mode where: ** matches any files and zero or more directories and subdirectories (i.e. the current behaviour of *) * matches in one path level/only to the next path separator This is essentially achievable in glob.glob from versio

[Python-ideas] Positional-only parameters

Hi, For technical reasons, many functions of the Python standard libraries implemented in C have positional-only parameters. Example: --- $ ./python Python 3.7.0a0 (default, Feb 25 2017, 04:30:32) >>> help(str.replace) replace(self, old, new, count=-1, /) # <== notice "/" at the end ...

Re: [Python-ideas] get() method for list and tuples

I wouldn't see myself using it for an arbitrary value in the middle of the list, but perhaps for the 0th or -1st (first/last) element of a list that might be empty. Maybe also second-to-first/last if I'm initializing some comparison between sequential items? Some of the examples don't work with ne

Re: [Python-ideas] Expose a child factory using MappingProxyType in builtins

I've implemented `frozendict` a few times for various projects and never knew about MappingProxyType. I always used `collections.abc.Mapping` ... On Tue, Feb 28, 2017 at 9:12 AM, David Mertz wrote: > The difference in hits might be because MappingProxyType has a funny name > and is in a hidden

Re: [Python-ideas] Another use case for the 'lazy' (aka 'delayed') keyword

On 2017-02-28 12:04, Michel Desmoulin wrote: The debate on the 'lazy' keyword seems to have settled, but I don't know if somebody is trying to write a PEP about it. Anyway, I was doing something like this the other day: conf.get('setting_name', load_from_db('setting_name')) And then realized I

Re: [Python-ideas] get() method for list and tuples

On Tue, Feb 28, 2017 at 10:10 AM, Sven R. Kunze wrote: > Yes, and easily written as above. What significant advantage would it > have to spell the above as: > > x = alist.get(pos, default_val) > > It's a couple characters shorter in the proposed version. I guess I'll > concede that needing

Re: [Python-ideas] unify usage of mutable and immutable objects

So it sounds like what you want is this: In [30]: class FrozenSet(frozenset): ...: def pop(self): ...: item = next(iter(self)) ...: return item, self-{item} ...: In [31]: a = FrozenSet({1,2,3,4,5}) In [32]: a.pop() Out[32]: (1, frozenset({2, 3, 4, 5})) I thi

Re: [Python-ideas] get() method for list and tuples

On 28.02.2017 18:18, David Mertz wrote: Yes, and easily written as above. What significant advantage would it have to spell the above as: x = alist.get(pos, default_val) It's a couple characters shorter in the proposed version. I guess I'll concede that needing the odd indexing at the

Re: [Python-ideas] unify usage of mutable and immutable objects

> but what is frozen_tree_set() here, frozen_tree_set is my set class. > frozensets don't have pop or 'ipop' "frozen" means we don't modify the object, but we can use it as prototype to create new object. e.g. in Haskell: val {attr = 1} or in Python: namedtuple._replace frozensets can have

Re: [Python-ideas] unify usage of mutable and immutable objects

> That is simply misspelled for your intent. Take a look at the following function in Haskell (GHC) Data.Set minView :: Set a -> Maybe (a, Set a) We always want the new set after a immutable set pop(). "e = a.pop()" is fine for mutable set, but not for immutable case. we need "e, a =

Re: [Python-ideas] math.nextafter

On Fri, Feb 24, 2017 at 6:43 PM, Nathaniel Smith wrote: > On Feb 24, 2017 5:29 PM, "David Mertz" wrote: > > Marc-André slightly misspelled the recent-ish addition of math.isclose(), > but I agree that it is absolutely where a "nextafter" belongs. > > > My 2c: I disagree -- numerical tolerance b

Re: [Python-ideas] Another use case for the 'lazy' (aka 'delayed') keyword

On Tue, Feb 28, 2017 at 9:30 AM, M.-A. Lemburg wrote: > Here's an example similar to OCaml's lazy evaluation, which > uses a simple lazy proxy object. > ### OCaml like lazy evaluation > class Lazy: > def __init__(self, code, frame): > self.code = code > self.globals = frame.f_

Re: [Python-ideas] Another use case for the 'lazy' (aka 'delayed') keyword

On 28.02.2017 17:54, M.-A. Lemburg wrote: > On 28.02.2017 17:35, David Mertz wrote: >> Clearly there is SOME semantics that is consistent and coherent since many >> languages have either a lazy or eager declaration syntax, with different >> defaults between languages but both being built in. There

Re: [Python-ideas] unify usage of mutable and immutable objects

On Tue, Feb 28, 2017 at 5:59 AM, 语言破碎处 wrote: > bad example: > a = set() > a.add(1)# return None; "a" changed > e = a.pop(); > That is simply misspelled for your intent. a = set() a |= {1} e = a.pop() -- Keeping medicines from the bloodstreams of the sick; food from th

Re: [Python-ideas] get() method for list and tuples

On Tue, Feb 28, 2017 at 7:16 AM, Michel Desmoulin wrote: > Le 28/02/2017 à 15:45, Steven D'Aprano a écrit : > > No you don't. You can use slicing. > > alist = [1, 2, 3] > > print(alist[99:100]) # get the item at position 99 > > No this gives you a list of one item or an empty list. > > dict.get(

Re: [Python-ideas] Expose a child factory using MappingProxyType in builtins

The difference in hits might be because MappingProxyType has a funny name and is in a hidden-ish location. I.e. not necessarily because it *would be* less used or useful if it were more exposed. In either case, the name that makes sense to me would be `frozendict`. That could very well live in `c

Re: [Python-ideas] Another use case for the 'lazy' (aka 'delayed') keyword

On Tue, Feb 28, 2017 at 8:54 AM, M.-A. Lemburg wrote: > On 28.02.2017 17:35, David Mertz wrote: > > Clearly there is SOME semantics that is consistent and coherent since > many > > languages have either a lazy or eager declaration syntax, with different > > defaults between languages but both bei

Re: [Python-ideas] Another use case for the 'lazy' (aka 'delayed') keyword

On 28.02.2017 17:35, David Mertz wrote: > Clearly there is SOME semantics that is consistent and coherent since many > languages have either a lazy or eager declaration syntax, with different > defaults between languages but both being built in. There are a lot of > ways that Python isn't Haskell,

Re: [Python-ideas] Another use case for the 'lazy' (aka 'delayed') keyword

Clearly there is SOME semantics that is consistent and coherent since many languages have either a lazy or eager declaration syntax, with different defaults between languages but both being built in. There are a lot of ways that Python isn't Haskell, obviously. But both Scheme and OCaml are eager

Re: [Python-ideas] Another use case for the 'lazy' (aka 'delayed') keyword

On 28.02.2017 15:46, Michel Desmoulin wrote: > lazy is not only practical, but it's also beautiful. It reads well. It > solves a problem we all have on a regular basis. The only practical use case I ever ran into for lazy evaluation are lazy imports, simply because imports cause a lot of startup o

Re: [Python-ideas] Another use case for the 'lazy' (aka 'delayed') keyword

I like null coalesce too. :) I know that BDFL has said no to ? Before, but was that for the if-then shorthand only? Perhaps submit a new thread to this list so people can discuss/find? -Joseph > On Feb 28, 2017, at 10:21 AM, Mark E. Haase wrote: > > This could be solved with a null-coalesci

Re: [Python-ideas] Another use case for the 'lazy' (aka 'delayed') keyword

If you'd like help with the PEP, I'd be happy to assist (subject to time, as always the problem). I think this idea got pretty good support in the discussion (of course, I'm biased because it's one of the few proposed here that I actually really like). Few core developers really chimed in on the

Re: [Python-ideas] Another use case for the 'lazy' (aka 'delayed') keyword

There are plenty of PEP-505 threads in the archives, plus the PEP itself. I was only pointing out that the use case in thread might also be solved with an existing proposal*, so I won't derail this thread any further. *There are actually several proposals for short-circuit evaluation, including PE

Re: [Python-ideas] Expose a child factory using MappingProxyType in builtins

Searching MappingProxyType on GitHub gives over 10,000 results. I think it probably makes sense to make mappingproxy more "visible", maybe move it to collections module? (where OrderedDict lives) I am not sure if it makes sense to move it to builtins. (for comparison frozenset gives around 1000,00

Re: [Python-ideas] Another use case for the 'lazy' (aka 'delayed') keyword

Only if "None" is not a proper value from .get(). And this doest solve the problems with more general callbacks that are not trying to get a value (cf Django lazy_gettext). Besides, "??" does not exist yet for Python, so let's counter the argument for lazy with the potential benefits of something

Re: [Python-ideas] Expose a child factory using MappingProxyType in builtins

+1 I think this makes a lot of sense. What would you name the built in? -Joseph > On Feb 28, 2017, at 7:17 AM, Michel Desmoulin > wrote: > > We have the immutable frozenset for sets and and tuples for lists. > > But we also have something to manipulate dict as immutable datastructures: > >>

Re: [Python-ideas] Another use case for the 'lazy' (aka 'delayed') keyword

This could be solved with a null-coalescing operator, e.g. PEP-505. >>> val = conf.get('setting_name') ?? load_from_db('setting_name') The right side isn't evaluated unless the left side is None. It's similar to this: >>> val = conf.get('setting_name') or load_from_db('setting_name') Exce

Re: [Python-ideas] Another use case for the 'lazy' (aka 'delayed') keyword

Good luck Le 28/02/2017 à 16:08, Joseph Hackman a écrit : > Yes I do think this is precisely where a lazy or delayed feature would work > well. I'm working on writing up a complete PEP now, and have made some > progress on the things left unsolved in the other thread. I will post again > when t

Re: [Python-ideas] unify usage of mutable and immutable objects

I'm sorry for the confusion, but what is frozen_tree_set() here, and what is ipop? frozensets don't have pop or 'ipop', so my apologies that I'm a bit lost here. -Ryan Birmingham On 28 February 2017 at 08:59, 语言破碎处 wrote: > > Hi! > I write a '<'-based immutable set class. > But it is qu

Re: [Python-ideas] get() method for list and tuples

Le 28/02/2017 à 15:45, Steven D'Aprano a écrit : > On Tue, Feb 28, 2017 at 12:54:26PM +0100, Michel Desmoulin wrote: >> dict.get() is a very useful method, but for lists and tuples, we need to >> rely on try/except instead. > > No you don't. You can use slicing. > > alist = [1, 2, 3] > print(al

Re: [Python-ideas] Another use case for the 'lazy' (aka 'delayed') keyword

Yes I do think this is precisely where a lazy or delayed feature would work well. I'm working on writing up a complete PEP now, and have made some progress on the things left unsolved in the other thread. I will post again when the PEP is closer to complete. Fundamentally, anything can be done

[Python-ideas] unify usage of mutable and immutable objects

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

Re: [Python-ideas] get() method for list and tuples

On Tue, Feb 28, 2017 at 12:54:26PM +0100, Michel Desmoulin wrote: > dict.get() is a very useful method, but for lists and tuples, we need to > rely on try/except instead. No you don't. You can use slicing. alist = [1, 2, 3] print(alist[99:100]) # get the item at position 99 In my experience, di

Re: [Python-ideas] Another use case for the 'lazy' (aka 'delayed') keyword

Le 28/02/2017 à 13:47, Markus Meskanen a écrit : > You don't need list comprehension, you can use a for loop. > > You don't need upacking you can use indexing. > > And you don't need lazy, it's just convenient. > > > With this sole argument you can add almost anything to the langua

Re: [Python-ideas] Another use case for the 'lazy' (aka 'delayed') keyword

> > You don't need list comprehension, you can use a for loop. > > You don't need upacking you can use indexing. > > And you don't need lazy, it's just convenient. > With this sole argument you can add almost anything to the language as long as it has at least one use case where it's better than e

Re: [Python-ideas] Another use case for the 'lazy' (aka 'delayed') keyword

Le 28/02/2017 à 13:27, Markus Meskanen a écrit : > Well you could just use a dict subclass here with get() that takes > callable... > As I said to Angelico: Yes but this assumes: - I have access to the code instantiating conf; - all code using conf are using load_from_db as a default value;

Re: [Python-ideas] Another use case for the 'lazy' (aka 'delayed') keyword

Well you could just use a dict subclass here with get() that takes callable... On Feb 28, 2017 14:25, "Michel Desmoulin" wrote: > > > Le 28/02/2017 à 13:19, Chris Angelico a écrit : > > On Tue, Feb 28, 2017 at 11:04 PM, Michel Desmoulin > > wrote: > >> Instead, I think it's a good example of we

Re: [Python-ideas] Another use case for the 'lazy' (aka 'delayed') keyword

Le 28/02/2017 à 13:19, Chris Angelico a écrit : > On Tue, Feb 28, 2017 at 11:04 PM, Michel Desmoulin > wrote: >> Instead, I think it's a good example of were 'lazy' could help. You >> can't get simpler than: >> >> conf.get('setting_name', lazy load_from_db('setting_name')) >> > > Alternatively,

Re: [Python-ideas] Another use case for the 'lazy' (aka 'delayed') keyword

On Tue, Feb 28, 2017 at 11:04 PM, Michel Desmoulin wrote: > Instead, I think it's a good example of were 'lazy' could help. You > can't get simpler than: > > conf.get('setting_name', lazy load_from_db('setting_name')) > Alternatively, you could define 'conf' as a subclass of dict with a __missing

[Python-ideas] Expose a child factory using MappingProxyType in builtins

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 "", line 1, i

[Python-ideas] Another use case for the 'lazy' (aka 'delayed') keyword

The debate on the 'lazy' keyword seems to have settled, but I don't know if somebody is trying to write a PEP about it. Anyway, I was doing something like this the other day: conf.get('setting_name', load_from_db('setting_name')) And then realized I could save a query not doing the load_from_db(

[Python-ideas] get() method for list and tuples

dict.get() is a very useful method, but for lists and tuples, we need to rely on try/except instead. Can we get list.get and tuple.get as well? Also, for list, a list.setdefault like the dict.setdefault would be logical. ___ Python-ideas mailing list Py