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

On 28 February 2017 at 23:19, Victor Stinner wrote: > 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: > > ... Sorry, I don't understand your pr

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

On 1 March 2017 at 01:31, qhlonline wrote: > My code example is not proper, Yes, may be this is better: > list.sort().revers( We can already do this - reversed(sorted(lst)) This is a long-established design decision in Python. It would need a *very* compelling use case to even think about chan

[Python-ideas] for/except/else

I know what the regulars among you will be thinking (time machine, high bar for language syntax changes, etc.) so let me start by assuring you that I'm well aware of all of this, that I did research the topic before posting and that this is not the same as a previous suggestion using almost the

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

It's even in the Programming FAQ: "In general in Python (and in all cases in the standard library) a method that mutates an object will return None to help avoid getting the two types of operations confused. So if you mistakenly write y.sort() thinking it will give you a sorted copy of y, you’ll i

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

Cf. https://martinfowler.com/bliki/CommandQuerySeparation.html But: >>> l = [1,2,3] >>> l.pop() 3 >>> l [1, 2] => Not so true. S. On Wed, Mar 1, 2017 at 11:10 AM, Stephan Houben wrote: > It's even in the Programming FAQ: > > "In general in Python (and in all cases in the standard library)

Re: [Python-ideas] lazy use for optional import

On Wed, Mar 1, 2017 at 2:31 AM, Nicolas Cellier wrote: > For example: > >> lazy import pylab as pl # do nothing for now >> >> # do stuff >> >> def plot(*args): >> pl.figure() # Will raise an ImportError at this point >> pl.plot(...) This can already be achieved without introducing a new

Re: [Python-ideas] for/except/else

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 all

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

On 01/03/17 02:56, 语言破碎处 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 think comparing against False (or True) is bad id

Re: [Python-ideas] for/except/else

Much snippage; apologies, Wolfgang! On 01/03/17 09:37, 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. [snip] - in some situations for/except/else would make

Re: [Python-ideas] for/except/else

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 unders

Re: [Python-ideas] for/except/else

On 01.03.2017 12:56, Steven D'Aprano wrote: - 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. one way to implement this with unconditional GOTOs would be (in pseudoc

Re: [Python-ideas] for/except/else

> On 2017 Mar 1 , at 4:37 a, Wolfgang Maier > wrote: > > I know what the regulars among you will be thinking (time machine, high bar > for language syntax changes, etc.) so let me start by assuring you that I'm > well aware of all of this, that I did research the topic before posting and > t

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

On Wed, Mar 01, 2017 at 10:44:22AM +0800, 语言破碎处 wrote: > "assert" is good, but it is used as a guard frequently. Using assert as a guard is an abuse of assert. We should not encourage it. assert has many uses already, but runtime guards is not one of them: http://import-that.dreamwidth.org/676.h

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

On Wed, Mar 01, 2017 at 01:04:00PM +1100, Chris Angelico wrote: > 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_

[Python-ideas] PEP 8 coding style included in grammar ?

I was wondering why the PEP coding style ( https://www.python.org/dev/peps/pep-0008/) is not natively included in python grammar ? For instance, both, *function definition* and *class definition*, are using the same “NAME” token. ((see, https://docs.python.org/3/reference/grammar.html). classdef:

Re: [Python-ideas] PEP 8 coding style included in grammar ?

Long story short, it's because there can be good reasons to ignore PEP8 naming conventions. Linting tools can be taught to skip over an intentional PEP8 violation. A grammar rule can't Alex On 2017-03-01 09:04 AM, Mathieu BEAL wrote: > > I was wondering why the PEP coding style > (https://www.p

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

On 1 March 2017 at 13:50, Steven D'Aprano wrote: > It is possible that we could come up with a pretty-printing protocol, > but that wouldn't be a trivial job. I'd be inclined to do this via simplegeneric. Let pprint do what it currently does, but allow users to register implementations for specif

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

> On Mar 1, 2017, at 9:35 AM, Paul Moore wrote: > >> On 1 March 2017 at 13:50, Steven D'Aprano wrote: >> It is possible that we could come up with a pretty-printing protocol, >> but that wouldn't be a trivial job. > > I'd be inclined to do this via simplegeneric. Let pprint do what it > current

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

On 1 March 2017 at 14:48, Eric V. Smith wrote: > > If you mean functools.singledispatch, then I agree. It's even mentioned as a > motivating case in PEP 443. Sorry - that was a thinko on my part - yes, functools.singledispatch. Paul ___ Python-ideas m

Re: [Python-ideas] for/except/else

On 03/01/2017 01:37 AM, 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. I find the proposal interesting. More importantly, the proposal is well written an

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

> On 1 Mar 2017, at 10:26, Stéfane Fermigier wrote: > > Cf. https://martinfowler.com/bliki/CommandQuerySeparation.html > > > But: > > >>> l = [1,2,3] > >>> l.pop() > 3 > >>> l > [1, 2] > > => Not so true. > > S. This is natural

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

Definitively not, just like M. Fowler: "Meyer likes to use command-query separation absolutely, but there are exceptions. Popping a stack is a good example of a query that modifies state. Meyer correctly says that you can avoid having this method, but it is a useful idiom. So I prefer to follow thi

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

>From my experience teaching Python to non-programmers, it's a huge hurdle/nightmare to teach functions/methods that modify objects in-place vs. return a value that must be reassigned. Behold Pandas's DataFrame's sort method, which has an optional `in_place` argument that defaults to *False*, which

Re: [Python-ideas] PEP 8 coding style included in grammar ?

Of course, in Python 8 this naming convention will indeed be enforced. https://mail.python.org/pipermail/python-dev/2016-March/143603.html Op 1 mrt. 2017 15:16 schreef "Alexandre Brault" : > Long story short, it's because there can be good reasons to ignore PEP8 > naming conventions. Linting to

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

> On 1 Mar 2017, at 01:26, Michel Desmoulin wrote: > > - you can iterate on both Maybe, bit do you want the keys, values or (key, value) items? Keys being the deafult. > - you can index both Maybe as you cannot in the general case know the index. Need keys(). > - you can size both Yes I think

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

Barry, you're taking the metaphor too far. Duct typing is about presenting a certain interface. If your function takes an object that has a get(key, default) method, the rest doesn't matter. That's the only way in which the object needs to resemble a duck in your function. I'd like to +1 this prop

Re: [Python-ideas] Positional-only parameters

On 28.02.17 23:17, Victor Stinner wrote: My question is: would it make sense to implement this feature in Python directly? If yes, what should be the syntax? Use "/" marker? Use the @positional() decorator? I'm strongly +1 for supporting positional-only parameters. The main benefit to me is th

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

On 01.03.17 11:31, Paul Moore wrote: On 1 March 2017 at 01:31, qhlonline wrote: My code example is not proper, Yes, may be this is better: list.sort().revers( We can already do this - reversed(sorted(lst)) Or just sorted(lst, reverse=True). __

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

On 01.03.17 16:35, Paul Moore wrote: On 1 March 2017 at 13:50, Steven D'Aprano wrote: It is possible that we could come up with a pretty-printing protocol, but that wouldn't be a trivial job. I'd be inclined to do this via simplegeneric. Let pprint do what it currently does, but allow users t

Re: [Python-ideas] Positional-only parameters

On Wed, Mar 1, 2017 at 11:25 AM, Serhiy Storchaka wrote: > On 28.02.17 23:17, Victor Stinner wrote: > >> My question is: would it make sense to implement this feature in >> Python directly? If yes, what should be the syntax? Use "/" marker? >> Use the @positional() decorator? >> > > I'm strongly

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

Stéfane Fermigier wrote: Cf. https://martinfowler.com/bliki/CommandQuerySeparation.html Python's convention is less extreme than this, since it only applies to methods that, under the conventions of some other languages, would return self to facilitate chaining. There's no rule against a mutati

Re: [Python-ideas] Positional-only parameters

On 3/1/2017 2:53 PM, Guido van Rossum wrote: On Wed, Mar 1, 2017 at 11:25 AM, Serhiy Storchaka mailto:storch...@gmail.com>> wrote: On 28.02.17 23:17, Victor Stinner wrote: My question is: would it make sense to implement this feature in Python directly? If yes, what should b

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

On Wed, Mar 1, 2017 at 11:13 AM, Abe Dillon wrote: > I'd like to +1 this proposal. It should be trivial to implement. It won't > break backward compatibility. It's intuitive. I can think of several places > I would use it. I can't think of a good reason not to include it. > I've yet to see in th

Re: [Python-ideas] Positional-only parameters

On 03/01/2017 11:53 AM, Guido van Rossum wrote: FWIW in typeshed we've started using double leading underscore as a convention for positional-only parameters, e.g. here: https://github.com/python/typeshed/blob/master/stdlib/3/builtins.pyi#L936 I would much rather have a single '/' to denote

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

On 3/1/2017 12:26 PM, Stéfane Fermigier wrote: What I wanted to point out is that the paragraph quoted by Stephan ("In general in Python (and in all cases in the standard library) a method that mutates an object will return None to help avoid getting the two types of operations confused. So if y

Re: [Python-ideas] Positional-only parameters

On 2017-03-01 21:32, Ethan Furman wrote: On 03/01/2017 11:53 AM, Guido van Rossum wrote: FWIW in typeshed we've started using double leading underscore as a convention for positional-only parameters, e.g. here: https://github.com/python/typeshed/blob/master/stdlib/3/builtins.pyi#L936 I woul

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

> On 1 Mar 2017, at 19:13, Abe Dillon wrote: > > Barry, you're taking the metaphor too far. Duct typing is about presenting a > certain interface. If your function takes an object that has a get(key, > default) method, the rest doesn't matter. That's the only way in which the > object needs t

Re: [Python-ideas] Positional-only parameters

On Wed, Mar 1, 2017 at 9:26 PM Serhiy Storchaka wrote: > On 28.02.17 23:17, Victor Stinner wrote: > > My question is: would it make sense to implement this feature in > > Python directly? If yes, what should be the syntax? Use "/" marker? > > Use the @positional() decorator? > > > The problem

Re: [Python-ideas] PEP 8 coding style included in grammar ?

On Mar 01, 2017, at 03:04 PM, Mathieu BEAL wrote: >I was wondering why the PEP coding style ( >https://www.python.org/dev/peps/pep-0008/) is not natively included in python >grammar ? Well, the simple answer is that the grammar predates PEP 8 (or any PEP) by many years. Cheers, -Barry pgpGjysE

Re: [Python-ideas] PEP 8 coding style included in grammar ?

On Thu, Mar 2, 2017 at 11:04 AM, Barry Warsaw wrote: > On Mar 01, 2017, at 03:04 PM, Mathieu BEAL wrote: > >>I was wondering why the PEP coding style ( >>https://www.python.org/dev/peps/pep-0008/) is not natively included in python >>grammar ? > > Well, the simple answer is that the grammar predat

Re: [Python-ideas] lazy use for optional import

Going through machinations to satisfy PEP 8 makes no sense -- it's s style *guide* -- that's it. -CHB On Tue, Feb 28, 2017 at 3:31 PM, Nicolas Cellier < cont...@nicolas-cellier.net> wrote: > I have seen some interest into lazy functionality implementation. > > I wondered if it can be linked wit

Re: [Python-ideas] Positional-only parameters

On Wed, Mar 1, 2017 at 2:16 PM, אלעזר wrote: > I like the idea, but I wanted to note that since it has no meaning from > the point of view of the defined function, it can be done with a magic > decorator, so new syntax is not required: > > @positional_only[:4] > def replace(self, old, new, count=

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

On Tue, Feb 28, 2017 at 5:26 PM, Michel Desmoulin wrote: > Duck typing is precesily about incomplete but good enough similar API. > yes, though ideally one API is a subset of the other -- if they have the same method, it should mean the same thing: > For the dict and list: > > - you can itera

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

On Tue, Feb 28, 2017 at 5:56 PM, Michel Desmoulin wrote: > Me, I have to deal SOAP government systems, mongodb based API built by > teenagers, geographer data set exports and FTP + CSV in marina systems > (which I happen to work on right now). > > 3rd party CSV, XML and JSON processing are just

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

On Tue, Feb 28, 2017 at 03:35:31PM -0800, 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 t

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

On 3/1/17, Steven D'Aprano wrote: > 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. Maybe she/he wants to say tha

Re: [Python-ideas] for/except/else

On 1 March 2017 at 19:37, Wolfgang Maier < wolfgang.ma...@biologie.uni-freiburg.de> wrote: > I know what the regulars among you will be thinking (time machine, high > bar for language syntax changes, etc.) so let me start by assuring you that > I'm well aware of all of this, that I did research th

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

On 2 March 2017 at 07:03, David Mertz wrote: > On Wed, Mar 1, 2017 at 11:13 AM, Abe Dillon wrote: > >> I'd like to +1 this proposal. It should be trivial to implement. It won't >> break backward compatibility. It's intuitive. I can think of several places >> I would use it. I can't think of a go

Re: [Python-ideas] Positional-only parameters

Hi all, I have a slight variant of the decorator proposal. Rather than specify a count, let the decorator implement the typeshed dunder convention: @positional_only def replace(self, __old, __new, count=-1): (I imagine this decorator would also treat "self" as position_only, so no need for _

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

A crucial difference between a set and a type is that you cannot explicitly iterate over the elements of a type, so while we could implement x in int to do something useful, we cannot make for x in int: print(x) Because if we could, we could implement Russell's paradox in Python: R = set(x