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,

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

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

[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

[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,

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] >

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

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

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

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')

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

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

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

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

[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

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

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

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

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

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

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 >

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

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] 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] 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

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:

[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

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,

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,

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 =

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

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.

[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 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

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

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 >

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

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

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

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

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} >> >>

[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

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

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] __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

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

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

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

> > 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]

[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

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

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

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:

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. > >

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

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!

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

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.