Re: [Python-ideas] A better (simpler) approach to PEP 505

On Mon, Jul 23, 2018 at 11:26 AM Paul Moore wrote: > * Library solution works with all versions of Python > * The need for unbox is a little ugly, but arguably less so than ?. > (conceded that's a subjective view) > * Mixing ?. and . is terser than unboxing and reboxing - but are there > any

Re: [Python-ideas] PEP 505: None-aware operators

I personally do almost only classical programming, and I am somewhat opposed to OOP in general. So here my somewhat outlandish view, (and I am biased becase I will probably never need this feature). First thoughts after reading the PEP: what is so super-special and fundamental about None value?

Re: [Python-ideas] A better (simpler) approach to PEP 505

On Mon, Jul 23, 2018 at 12:47 PM Antoine Pitrou wrote: > > favorite = cfg?.user?.profile?.food ?? "Spam" > > favorite = NoneAware(cfg, "Spam").user.profile.food.unbox() > > You could use .__call__() instead of .unbox(). Also you can make > unboxing unnecessary in most cases by having your

Re: [Python-ideas] A better (simpler) approach to PEP 505

On Mon, Jul 23, 2018 at 1:28 PM Steven D'Aprano wrote: > There's the first bug right there. foo.bar.blim ought to raise > AttributeError, since there is no blim attribute defined on foo.bar. > Note my observation that this is deliberately different semantics. I want to solve the underlying

Re: [Python-ideas] Python docs page: In what ways is None special

I think your description of the uses of None is really great. There's definitely no reason it cannot be a blog post immediately, but perhaps at some later point included in The Python Tutorial. On Mon, Jul 23, 2018 at 8:39 AM Jonathan Fine wrote: > Hi Steve > > You wrote > > > I think your

Re: [Python-ideas] A better (simpler) approach to PEP 505

On Mon, Jul 23, 2018 at 2:12 PM Rhodri James wrote: > > How are you supposed to do method calling, the equivalent of > "foo?.bar()" ? "NoneAware(foo).bar.unbox()()" looks downright weird. > Is there more magic in NoneAware to cover this case? (Not that I think > we should be encouraging people

Re: [Python-ideas] Add function readbyte to asyncio.StreamReader

Well, even if it is worth, i.e. your use case is not rare enough, I would suggest at least making it private, readexactly can call this specialised function if nbytes==1: def _readbyte(self): def readexactly(self, num): if num == 1: return self._readbyte() ... the rest stays

Re: [Python-ideas] A better (simpler) approach to PEP 505

Le 23/07/2018 à 17:12, David Mertz a écrit : > The need addressed by PEP 505 is real; it's also MUCH more niche and > uncommon than something that would merit new syntax. Moreover, the > actual legitimate purpose served by the PEP 505 syntax is easily served > by existing Python simply by

Re: [Python-ideas] PEP 505: None-aware operators

On Mon, Jul 23, 2018 at 6:53 PM Steven D'Aprano wrote: > > On Mon, Jul 23, 2018 at 02:04:17PM +0200, Giampaolo Rodola' wrote: > > "a?.b" does two and that's a fundamental difference (explicitness). > > How is "two things" less explicit than "one thing"? > Comments like the above is why I think

Re: [Python-ideas] PEP 505: None-aware operators

On Tue, Jul 24, 2018 at 8:22 AM, Thomas Jollans wrote: > On 18/07/18 19:43, Steve Dower wrote: >> When a ``None``-aware operator is present, the left-to-right evaluation >> may be >> short-circuited. For example, ``await a?.b(c).d?[e]`` is evaluated:: >> >> _v = a >> if _v is not None: >>

Re: [Python-ideas] slice[] to get more complex slices

Stephan Hoyer schrieb am 23.07.2018 um 18:01: > On Mon, Jul 23, 2018 at 4:24 AM Paul Moore wrote: > >> I thought the reason the proposal got nowhere was because it's pretty >> simple to define it yourself: >> >> >>> class SliceHelper: >> ... def __getitem__(self, slice): >> ... return

Re: [Python-ideas] PEP 505: None-aware operators

On Tue, Jul 24, 2018 at 8:05 AM, Giampaolo Rodola' wrote: > The argument about this is that '?.' short-circuits execution > *silently*. Instead of AttributeError you get None. You may chain ?. > in order to lazily traverse a long tree, inadvertently assign None to > a variable, continue code

Re: [Python-ideas] PEP 505: None-aware operators

On 18/07/18 19:43, Steve Dower wrote: > When a ``None``-aware operator is present, the left-to-right evaluation > may be > short-circuited. For example, ``await a?.b(c).d?[e]`` is evaluated:: > >     _v = a >     if _v is not None: >     _v = _v.b >     _v = _v(c) >     _v = _v.d >    

Re: [Python-ideas] A better (simpler) approach to PEP 505

I agree a class can provide a very good alternative to PEP505.  I built one a while ago, and still use it https://github.com/klahnakoski/mo-dots for most my data transformation code. The library only boxes dicts and lists, which removes the need for .unbox() in many of my use cases. My point is,

Re: [Python-ideas] slice[] to get more complex slices

I find pandas.IndexSlice makes a lot of operations easier to spell. As simple as it is, it's a valuable capability. Rather than every library—or a number of them anyway—creating the same 4 lines of code with a different name, it would be much nicer to have it as a class __getitem__ method, e.g.

Re: [Python-ideas] A better (simpler) approach to PEP 505

Short circuit is indeed the main difference. Makes me re-think about the None trigger subclasses of invalid operations exceptions. Like None.a trigger a NoneAttributeError(AttributeError), and so on... I think it solves many issues without much problems nor syntax changes, but probably I miss

Re: [Python-ideas] slice[] to get more complex slices

May I propose `slice.L` as in "slice literal": ``` class slice: ... class L: """Slice literal. slice.L[1:2:3, 1] -> (slice(1, 2, 3), slice(1)) """ @classmethod def __class_getitem__(cls, item): return item ``` On Mon, Jul 23, 2018 at 12:02 PM Joseph Jevnik

Re: [Python-ideas] PEP 505: None-aware operators

On 24/07/18 00:39, Chris Angelico wrote: > On Tue, Jul 24, 2018 at 8:22 AM, Thomas Jollans wrote: >> On 18/07/18 19:43, Steve Dower wrote: >>> When a ``None``-aware operator is present, the left-to-right evaluation >>> may be >>> short-circuited. For example, ``await a?.b(c).d?[e]`` is

Re: [Python-ideas] PEP 505: None-aware operators

On Mon, Jul 23, 2018 at 11:52 AM Steve Dower wrote: > I'm borderline on ?[] right now. Honestly, I think it works best if it > also silently handles LookupError (e.g. for traversing a loaded JSON > dict), but then it's inconsistent with ?. which I think works best if it > handles None but allows

Re: [Python-ideas] A better (simpler) approach to PEP 505

On 23 July 2018 at 16:12, David Mertz wrote: > The need addressed by PEP 505 is real; it's also MUCH more niche and > uncommon than something that would merit new syntax. Moreover, the actual > legitimate purpose served by the PEP 505 syntax is easily served by existing > Python simply by using

Re: [Python-ideas] slice[] to get more complex slices

On Mon, Jul 23, 2018 at 4:24 AM Paul Moore wrote: > I thought the reason the proposal got nowhere was because it's pretty > simple to define it yourself: > > >>> class SliceHelper: > ... def __getitem__(self, slice): > ... return slice > ... > >>> SH = SliceHelper() > >>> SH[1::3] >

Re: [Python-ideas] A better (simpler) approach to PEP 505

On 23/07/18 16:12, David Mertz wrote: Here is a way of solving the "deep attribute access to messy data" problem Before we go too far, and /pace/ Steve's work, how real is this problem? I get that there is a use in accessing JSON trees, but this feels awfully like a rather specific issue

[Python-ideas] A better (simpler) approach to PEP 505

The need addressed by PEP 505 is real; it's also MUCH more niche and uncommon than something that would merit new syntax. Moreover, the actual legitimate purpose served by the PEP 505 syntax is easily served by existing Python simply by using a wrapper class. Here is a way of solving the "deep

Re: [Python-ideas] A better (simpler) approach to PEP 505

The default could be at the end with an argument to unboxing : favorite = NoneAware(cfg).user.profile.food.unbox("Spam") Le lun. 23 juil. 2018 à 17:26, Paul Moore a écrit : > On 23 July 2018 at 16:12, David Mertz wrote: > > The need addressed by PEP 505 is real; it's also MUCH more niche and

Re: [Python-ideas] A better (simpler) approach to PEP 505

The proto here swallow and short circuit on attribute error. Changing to do it on Noneness is easy, and you can choose between the two behavior: it's a strength compared to the operator approach. It's working in current python, another strength. I think short-circuit behavior is similar: once

Re: [Python-ideas] PEP 505: None-aware operators

On Mon, Jul 23, 2018 at 12:09:00PM +0100, Steve Dower wrote: > On 23Jul2018 1145, Antoine Pitrou wrote: > > > >Le 23/07/2018 à 12:38, Steve Dower a écrit : > >> > >>General comment to everyone (not just Antoine): these arguments have > >>zero value to me. Feel free to keep making them, but I am

Re: [Python-ideas] PEP 505: None-aware operators

On Mon, Jul 23, 2018 at 7:46 AM, Grégory Lielens wrote: > Paul Moore wrote: >> >> This is my impression, as well. It seems like something that's helpful >> in dealing with unstructured object hierarchies with lots of optional >> attributes - which is where JSON tends to be used. >> >> But given

Re: [Python-ideas] A better (simpler) approach to PEP 505

Your wrapper class can also, I think: Swallow exceptions, especially AttributeError Specify the sentinel, if it is not None Work for getitem Mixing is indeed more difficult, and there is probably performance impact. Still, it's general and does not need to touch the implementation of the

Re: [Python-ideas] slice[] to get more complex slices

On Mon, Jul 23, 2018 at 3:24 AM, Jeroen Demeyer wrote: > On 2018-07-23 11:58, Grégory Lielens wrote: > >> Not sure slice[1::3] can be done >> > > It can be done. Since "slice" is a class, it would require a metaclass > though. > Since PEP 560 it won't need a metaclass -- it can be implemented

Re: [Python-ideas] PEP 505: None-aware operators

On 2018-07-23 13:04, Giampaolo Rodola' wrote: On Mon, Jul 23, 2018 at 3:12 AM Steven D'Aprano wrote: > ? has no spaces, it's literally "variable names interrupted by > question marks" and evaluation can stop at any time while scanning the > line from left to right. Just like ordinary

Re: [Python-ideas] slice[] to get more complex slices

23.07.18 18:16, Guido van Rossum пише: On Mon, Jul 23, 2018 at 3:24 AM, Jeroen Demeyer > wrote: On 2018-07-23 11:58, Grégory Lielens wrote: Not sure slice[1::3] can be done It can be done. Since "slice" is a class, it would require a metaclass

Re: [Python-ideas] A better (simpler) approach to PEP 505

On 23/07/18 19:21, David Mertz wrote: On Mon, Jul 23, 2018 at 2:12 PM Rhodri James wrote: How are you supposed to do method calling, the equivalent of "foo?.bar()" ? "NoneAware(foo).bar.unbox()()" looks downright weird. Is there more magic in NoneAware to cover this case? (Not that I think

Re: [Python-ideas] A better (simpler) approach to PEP 505

On Mon, 23 Jul 2018 11:12:45 -0400 David Mertz wrote: > > The particular names I use are nothing special, and better ones might be > found. I just called the class NoneAware and the "escape" method > `.unbox()` because that seemed intuitive at first brush. > > I don't disagree that needing to

Re: [Python-ideas] A better (simpler) approach to PEP 505

On Mon, Jul 23, 2018 at 2:12 PM Rhodri James wrote: > How are you supposed to do method calling, the equivalent of > "foo?.bar()" ? "NoneAware(foo).bar.unbox()()" looks downright weird. > Is there more magic in NoneAware to cover this case? (Not that I think > we should be encouraging people

Re: [Python-ideas] slice[] to get more complex slices

I still think that 'operator.subscript' would be valuable to me for all of the same reasons discussed in the previous threads and issues. I don't understand why it was reverted without any serious discussion given that it was already accepted and many people find this useful. On Mon, Jul 23, 2018

Re: [Python-ideas] PEP 505: None-aware operators

On Mon, Jul 23, 2018 at 02:04:17PM +0200, Giampaolo Rodola' wrote: [I wrote this] > > This is the point I was making earlier: you accept existing punctuation > > doing these things: > > > > try: > > obj.spam.egsg.tomato.cheese # oops a typo > > except AttributeError: > >

Re: [Python-ideas] PEP 505: None-aware operators

On Sun, Jul 22, 2018 at 11:54:19AM +1000, Steven D'Aprano wrote: > In my opinion, writing > > expression if expression is None else default > > is the *opposite* of Pythonic, it is verbose and the DRY violation is > inelegant (as well as inefficient). I'd much rather use: > >

Re: [Python-ideas] A better (simpler) approach to PEP 505

On Mon, Jul 23, 2018 at 11:34 AM Robert Vanden Eynde wrote: > The default could be at the end with an argument to unboxing : > > favorite = NoneAware(cfg).user.profile.food.unbox("Spam") > That's what PyMaybe does: https://pymaybe.readthedocs.io/en/latest/readme.html#examples-use-cases

Re: [Python-ideas] A better (simpler) approach to PEP 505

Btw. I *do* realize that the semantics of my suggested NoneAware class is different from the coalescing syntax. I just look at whether attribute access succeeds or fails in that code, not whether the starting value is specifically None (nor any particular sentinel). I believe that that behavior

Re: [Python-ideas] Python docs page: In what ways is None special

On Mon, Jul 23, 2018 at 10:03:10 +0100, Jonathan Fine wrote: > I thought, a page on how None is special would be nice. > I've not found such a page on the web. We do have > === > https://docs.python.org/3/library/constants.html Hi, there's also

Re: [Python-ideas] slice[] to get more complex slices

Humour warning. Serhiy wrote: > Do you bless using __class_getitem__ for something other than typing? As in https://perldoc.perl.org/functions/bless.html, perhaps? -- Jonathan ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] PEP 505: None-aware operators

On 23Jul2018 1530, David Mertz wrote: Of course I don't mean that if implemented the semantics would be ambiguous... rather, the proper "swallowing" of different kinds of exceptions is not intuitively obvious, not even to you, Steve.  And if some decision was reached and documented, it would

Re: [Python-ideas] A better (simpler) approach to PEP 505

On Mon, Jul 23, 2018 at 11:12:45AM -0400, David Mertz wrote: > Here is a way of solving the "deep attribute access to messy data" problem > that is: > > (1) Much more explicit > (2) Requires no change in syntax > (3) Will not be a bug magnet That's one opinion. > (4) Inasmuch as there are

Re: [Python-ideas] A better (simpler) approach to PEP 505

Hi David and Paul Thank you both for your contributions, and for starting a new thread. David, you wrote > The need addressed by PEP 505 is real; I completely agree. My view is that with PEP 505 as it it, the problem is better than the solution. But all the same, something can be done to

Re: [Python-ideas] A better (simpler) approach to PEP 505

Le 23/07/2018 à 18:00, David Mertz a écrit : On Mon, Jul 23, 2018 at 11:26 AM Paul Moore > wrote: * Library solution works with all versions of Python * The need for unbox is a little ugly, but arguably less so than ?. (conceded that's a subjective view)

Re: [Python-ideas] slice[] to get more complex slices

On Mon, Jul 23, 2018 at 4:19 PM Stefan Behnel wrote: > Stephan Hoyer schrieb am 23.07.2018 um 18:01: > > I think a SliceHelper class like this is a reasonable solution, but there > > would be a lot of value having it a standard place somewhere in the > > standard library (e.g.,

Re: [Python-ideas] Python docs page: In what ways is None special

On Jul 23, 2018 8:43 PM, "Chris Barker - NOAA Federal via Python-ideas" < python-ideas@python.org> wrote: > Procedures return None > == a = [3,1,2] b = a.sort() a, b > ([1, 2, 3], None) This is less about None than about the convention that mutating methods return

Re: [Python-ideas] A better (simpler) approach to PEP 505

On Mon, Jul 23, 2018 at 01:55:48PM -0400, David Mertz wrote: > On Mon, Jul 23, 2018 at 1:28 PM Steven D'Aprano wrote: > > > There's the first bug right there. foo.bar.blim ought to raise > > AttributeError, since there is no blim attribute defined on foo.bar. > > > > Note my observation that

Re: [Python-ideas] PEP 505: None-aware operators

On 2018-07-23 23:05, Giampaolo Rodola' wrote: On Mon, Jul 23, 2018 at 6:53 PM Steven D'Aprano wrote: On Mon, Jul 23, 2018 at 02:04:17PM +0200, Giampaolo Rodola' wrote: > "a?.b" does two and that's a fundamental difference (explicitness). How is "two things" less explicit than "one thing"?

[Python-ideas] A better PEP 505 (test package: coalescing)

I proposed a very toy example of a coalescing class that would solve the problem solved by brand new syntax in PEP 505. In my 5 minute version, there were several faults or limitations. For one, the class I wrote was misnamed, since it wasn't really about None-coalescing, but rather about

Re: [Python-ideas] A better (simpler) approach to PEP 505

David Mertz schrieb am 23.07.2018 um 16:12: > The need addressed by PEP 505 is real; it's also MUCH more niche and > uncommon than something that would merit new syntax. Moreover, the actual > legitimate purpose served by the PEP 505 syntax is easily served by > existing Python simply by using a

Re: [Python-ideas] Python docs page: In what ways is None special

>lot. Actually, the ?. and ?[ > operators seem like they'd be much more useful if I did more JSON > processing - This has been mentioned a lot in this discussion— Maybe what we need is a smarter JSON processing package, rather than new operators. Granted, these operators would help the authors

Re: [Python-ideas] Python docs page: In what ways is None special

I agree that some more docs on the specialness of None (and, to a lessor extent, True and False). A few comments: > None is a keyword > == None = 0 > SyntaxError: can't assign to keyword One of the implications of this is that “None” will always be the Singleton None object —

Re: [Python-ideas] A better (simpler) approach to PEP 505

On Mon, Jul 23, 2018 at 10:53:11AM -0700, Grégory Lielens wrote: > The proto here swallow and short circuit on attribute error. Changing > to do it on Noneness is easy, and you can choose between the two > behavior: it's a strength compared to the operator approach. Being able to choose

Re: [Python-ideas] PEP 505: None-aware operators

On Mon, Jul 23, 2018 at 2:38 AM Steven D'Aprano wrote: > > On Mon, Jul 23, 2018 at 12:59:20AM +0200, Giampaolo Rodola' wrote: > > > You're back at "since we have X that justifies the addition of Y" [1] > > and AFAICT that's the only argument you have provided so far in a 100+ > > messages

Re: [Python-ideas] PEP 505: None-aware operators

On Monday, July 23, 2018 at 8:24:45 AM UTC+2, Nicholas Cole wrote: And that leads to a simple question: how many times does this actually > occur in real-world by python code? -- i.e. how many times do I want > to check the value of an existing label, and, finding it is None (and > None

Re: [Python-ideas] slice[] to get more complex slices

+1 on this. Seems easy a limited in scope, and it reduce the need to remember the details of slice constructor, just reuse the same syntax for getitem slices. Seems that the initial proposal was skipped just for timing reasons, and have a large support among numpy users. More mixed outside

Re: [Python-ideas] slice[] to get more complex slices

Hi Grégory You wrote: > Seems that the initial proposal was skipped just for timing reasons The discussion is in https://bugs.python.org/issue24379. It was first skipped for that reason. Second time around our Then and now Former BDFL wrote === https://bugs.python.org/msg280721 Actually I'm with

Re: [Python-ideas] PEP 505: None-aware operators

Responding to a few more ideas that have come up here. Again, apologies for not directing them to the original authors, but I want to focus on the ideas that are leading towards a more informed decision, and not getting distracted by providing customised examples for people or getting into

Re: [Python-ideas] slice[] to get more complex slices

Hi Grégory You wrote: > Oh yes , I see. Seems like almost everybody think using the [...] syntax to > define reusable slices is a good idea, > Not sure slice[1::3] can be done, but this has my preference too: it's the > most direct exposure I can think of... The slice class already has all the

Re: [Python-ideas] slice[] to get more complex slices

On 2018-07-23 12:24, Jeroen Demeyer wrote: Another solution that nobody has mentioned (as far as I know) is to add additional syntax to the language for that. For example, one could say that (1:3) could be used to construct slice(1, 3) directly. The parentheses are required to avoid confusion

Re: [Python-ideas] Python docs page: In what ways is None special

On 23Jul2018 1003, Jonathan Fine wrote: This arises out of PEP 505 - None-aware operators. I thought, a page on how None is special would be nice. I've not found such a page on the web. We do have === https://docs.python.org/3/library/constants.html None The sole value of the type NoneType.

Re: [Python-ideas] PEP 505: None-aware operators

Le 23/07/2018 à 12:38, Steve Dower a écrit : > > General comment to everyone (not just Antoine): these arguments have > zero value to me. Feel free to keep making them, but I am uninterested. So you're uninterested in learning from past mistakes? You sound like a child who thinks their

Re: [Python-ideas] PEP 505: None-aware operators

On 23Jul2018 0151, Steven D'Aprano wrote: What if there was a language supported, non-hackish way to officially delay evaluation of expressions until explicitly requested? The current spelling for this is "lambda: delayed-expression" and the way to request the value is "()". :) (I'm not

Re: [Python-ideas] PEP 505: None-aware operators

On 23Jul2018 , Antoine Pitrou wrote: On Mon, 23 Jul 2018 10:51:31 +0100 Steve Dower wrote: Which is the most important operator? - Personally, I think '?.' is the most valuable. For me, it's the most contentious. The fact that a single '?' added to

Re: [Python-ideas] PEP 505: None-aware operators

On 23Jul2018 1129, Antoine Pitrou wrote: Le 23/07/2018 à 12:25, Steve Dower a écrit : On 23Jul2018 , Antoine Pitrou wrote: On Mon, 23 Jul 2018 10:51:31 +0100 Steve Dower wrote: Which is the most important operator? - Personally, I think '?.' is the

[Python-ideas] Python docs page: In what ways is None special

This arises out of PEP 505 - None-aware operators. I thought, a page on how None is special would be nice. I've not found such a page on the web. We do have === https://docs.python.org/3/library/constants.html None The sole value of the type NoneType. None is frequently used to represent the

Re: [Python-ideas] slice[] to get more complex slices

Oh yes , I see. Seems like almost everybody think using the [...] syntax to define reusable slices is a good idea, the discussion is where this could be implemented, knowing that numpy.s_ already exists. Discussion is not easy to follow, with the patch almost accepted then delayed then

Re: [Python-ideas] PEP 505: None-aware operators

On Mon, 23 Jul 2018 10:51:31 +0100 Steve Dower wrote: > > Which is the most important operator? > - > > Personally, I think '?.' is the most valuable. For me, it's the most contentious. The fact that a single '?' added to a regular line of Python code can

Re: [Python-ideas] slice[] to get more complex slices

On 2018-07-23 11:58, Grégory Lielens wrote: Not sure slice[1::3] can be done It can be done. Since "slice" is a class, it would require a metaclass though. Another solution that nobody has mentioned (as far as I know) is to add additional syntax to the language for that. For example, one

Re: [Python-ideas] PEP 505: None-aware operators

Le 23/07/2018 à 12:25, Steve Dower a écrit : > On 23Jul2018 , Antoine Pitrou wrote: >> On Mon, 23 Jul 2018 10:51:31 +0100 >> Steve Dower wrote: >>> >>> Which is the most important operator? >>> - >>> >>> Personally, I think '?.' is the most valuable. >> >>

Re: [Python-ideas] PEP 505: None-aware operators

On Mon, Jul 23, 2018 at 2:37 PM Mark E. Haase wrote: >> What does a scan through the existing core library say? > > > Please read the PEP before you shoot it down. It answers this _exact_ > question. My apologies. I'd missed the line where it says the examples were taken from the core

Re: [Python-ideas] PEP 505: None-aware operators

On Mon, Jul 23, 2018 at 6:52 AM Steve Dower wrote: > Responding to a few more ideas that have come up here. > ​Thank you for the clarifications.​ ​I'm trying to wrap my head around the various facets of None aware operators proposal after reading the whole discussion - as well as having read

Re: [Python-ideas] PEP 505: None-aware operators

On Mon, Jul 23, 2018 at 10:48:23AM +0100, Steve Dower wrote: > On 23Jul2018 0151, Steven D'Aprano wrote: > >What if there was a language > >supported, non-hackish way to officially delay evaluation of > >expressions until explicitly requested? > > The current spelling for this is "lambda:

Re: [Python-ideas] PEP 505: None-aware operators

On Mon, Jul 23, 2018 at 5:52 AM Steve Dower wrote: > The PEP author is unsure about how it works > --- > I wish this statement had come with some context, because the only thing > I'm unsure about is what I'm supposed to be unsure about. > In general—as I

Re: [Python-ideas] PEP 505: None-aware operators

On 23Jul2018 1145, Antoine Pitrou wrote: Le 23/07/2018 à 12:38, Steve Dower a écrit : General comment to everyone (not just Antoine): these arguments have zero value to me. Feel free to keep making them, but I am uninterested. So you're uninterested in learning from past mistakes? You

Re: [Python-ideas] PEP 505: None-aware operators

On Mon, Jul 23, 2018 at 8:08 AM Grégory Lielens wrote: > > > > On Monday, July 23, 2018 at 8:24:45 AM UTC+2, Nicholas Cole wrote: > >> And that leads to a simple question: how many times does this actually >> occur in real-world by python code? -- i.e. how many times do I want >> to check the

Re: [Python-ideas] slice[] to get more complex slices

On Mon, Jul 23, 2018 at 6:24 AM, Jeroen Demeyer wrote: > On 2018-07-23 11:58, Grégory Lielens wrote: > >> Not sure slice[1::3] can be done >> > > It can be done. Since "slice" is a class, it would require a metaclass > though. > > Another solution that nobody has mentioned (as far as I know) is

Re: [Python-ideas] slice[] to get more complex slices

On Mon, Jul 23, 2018 at 6:28 AM, Jonathan Fine wrote: > Hi Grégory > > You wrote: > > Oh yes , I see. Seems like almost everybody think using the [...] syntax > to > > define reusable slices is a good idea, > > > Not sure slice[1::3] can be done, but this has my preference too: it's > the > >

[Python-ideas] Idea: msgfmt.py and pygettext..py should be -m executable modules

Currently, the documentation (as well as plenty of other places on the Internet, such as Stack Overflow answers) mentions msgfmt.py and pygettext.py. See https://docs.python.org/3/library/gettext.html > (Python also includes pure-Python versions of these programs, called > pygettext.py and

Re: [Python-ideas] Python docs page: In what ways is None special

On 23 July 2018 at 10:16, Steve Dower wrote: > On 23Jul2018 1003, Jonathan Fine wrote: >> >> This arises out of PEP 505 - None-aware operators. >> >> I thought, a page on how None is special would be nice. >> I've not found such a page on the web. We do have >> === >>

Re: [Python-ideas] slice[] to get more complex slices

On 23 July 2018 at 11:31, Jeroen Demeyer wrote: > On 2018-07-23 12:24, Jeroen Demeyer wrote: >> >> Another solution that nobody has mentioned (as far as I know) is to add >> additional syntax to the language for that. For example, one could say >> that (1:3) could be used to construct slice(1, 3)

Re: [Python-ideas] Python docs page: In what ways is None special

Hi Paul Thank you for your contribution > The examples are interesting, agreed. One thing they highlight to me > is that most uses of None are effectively convention. The only two > behaviours that are unique to None and implemented in the interpreter > are: > > 1. Functions that don't return an

Re: [Python-ideas] slice[] to get more complex slices

That would be even more directbut it require syntax support, usefull mainly for people doing multdim complex slicing (i.e numpy users). I may be wrong, but I do not see it gain much support outside numpy... slice[] is probably much more easy to swallow for standard python users, and

Re: [Python-ideas] PEP 505: None-aware operators

Le 23/07/2018 à 13:09, Steve Dower a écrit : > On 23Jul2018 1145, Antoine Pitrou wrote: >> >> Le 23/07/2018 à 12:38, Steve Dower a écrit : >>> >>> General comment to everyone (not just Antoine): these arguments have >>> zero value to me. Feel free to keep making them, but I am uninterested. >> >>

Re: [Python-ideas] PEP 505: None-aware operators

Maybe it would help if you mention in which context you will benefit the most? If the python sub-community related to this context agree "?? and friends" is a good idea, then it will add weight to the proposal. Else, probably better to forget it. It seems related to JSON, but as I have never

Re: [Python-ideas] PEP 505: None-aware operators

On 23 July 2018 at 12:39, Grégory Lielens wrote: > Maybe it would help if you mention in which context you will benefit the > most? If the python sub-community related to this context agree "?? and > friends" is a good idea, then it will add weight to the proposal. Else, > probably better to

Re: [Python-ideas] PEP 505: None-aware operators

On Mon, Jul 23, 2018 at 3:12 AM Steven D'Aprano wrote: > > ? has no spaces, it's literally "variable names interrupted by > > question marks" and evaluation can stop at any time while scanning the > > line from left to right. > > Just like ordinary attribute access. > > This is the point I was

Re: [Python-ideas] slice[] to get more complex slices

On 23 July 2018 at 13:19, Todd wrote: > On Mon, Jul 23, 2018 at 7:24 AM, Paul Moore wrote: >> >> On 23 July 2018 at 11:31, Jeroen Demeyer wrote: >> > On 2018-07-23 12:24, Jeroen Demeyer wrote: >> >> >> >> Another solution that nobody has mentioned (as far as I know) is to add >> >> additional

Re: [Python-ideas] slice[] to get more complex slices

On Mon, Jul 23, 2018 at 7:24 AM, Paul Moore wrote: > On 23 July 2018 at 11:31, Jeroen Demeyer wrote: > > On 2018-07-23 12:24, Jeroen Demeyer wrote: > >> > >> Another solution that nobody has mentioned (as far as I know) is to add > >> additional syntax to the language for that. For example, one

Re: [Python-ideas] Python docs page: In what ways is None special

On Mon, Jul 23, 2018 at 10:03:10AM +0100, Jonathan Fine wrote: > I thought, a page on how None is special would be nice. I think your document would be a great blog post. I don't think it is very helpful as part of the standard documention, as it is more a collection of arbitrary facts about

Re: [Python-ideas] Python docs page: In what ways is None special

Hi Steve In this thread you wrote, replying to Paul Moore's comments on PEP 505 > None is already a special value. It is so special, it is one of only > three built-in values given keyword status. All the other built-ins, > including such things that are used implicitly by the interpreter (such

Re: [Python-ideas] Python docs page: In what ways is None special

Hi Steve You wrote > I think your document would be a great blog post. I don't think it is > very helpful as part of the standard documention, as it is more a > collection of arbitrary facts about None than a coherent "big picture" > document. Thank you. That's nice. However, I think there is,

Re: [Python-ideas] PEP 505: None-aware operators

Paul Moore wrote: > > This is my impression, as well. It seems like something that's helpful > in dealing with unstructured object hierarchies with lots of optional > attributes - which is where JSON tends to be used. > > But given that, I'm really much more interested in seeing the new >

Re: [Python-ideas] PEP 505: None-aware operators

On Mon, Jul 23, 2018 at 2:23 AM Nicholas Cole wrote: > One issue for me is that the trivial case is already a one-liner: > > if a is None: a = 10 > Yes, if you have no indentation and a 1-character name, then it fits on a single line. If you have a longer expression and/or side effects, then