On Thu, Sep 17, 2020 at 11:09:35PM +1000, Chris Angelico wrote:
> I've frequently yearned for an sscanf-like feature in Python. Usually
> I end up longhanding it with string methods, or else reaching for a
> regex, but neither of those is quite what I want. I'd prefer scanf
> notation to format
On Fri, Sep 18, 2020 at 09:05:39AM +1000, Chris Angelico wrote:
> > f-strings are not literals. They are a form of eval().
>
> Oh, that makes 'em sound way too scary :) They're more akin to a list
> display - a syntactic structure that yields a well-defined object, and
> has expressions inside
On Fri, Sep 18, 2020 at 10:05:07AM +1000, Steven D'Aprano wrote:
> Your proposal is to have a magic dunder, spelled '__attrs__` (note the
> two additional dots) which converts a attribute access into a string:
Oops, the comment about the dots was from an earlier thought which I
deleted.
On Thu, Sep 17, 2020 at 11:47:03PM -, Joseph Perez wrote:
> Thus `f"{:a + b}" == "a + b"`.
That can already be done by just *not* using a f-string.
This looks like a case of "when the only tool you have is a hammer,
everything looks like a nail". If you don't want a string literal to be
On Thu, Sep 17, 2020 at 08:34:26PM -, Joseph Perez wrote:
> A lot of libraries use string for attribute names to do some "dynamic"
> things. A typical example are SQLAlchemy
> [validators](https://docs.sqlalchemy.org/en/13/orm/mapped_attributes.html#simple-validators):
> ```python
> from
On Thu, Sep 17, 2020 at 06:06:39PM +0200, Alexis Masson wrote:
> I do really like the idea, but assigning to a literal really makes it
> feel wrong...
f-strings are not literals. They are a form of eval().
--
Steve
___
Python-ideas mailing list --
On Mon, Sep 14, 2020 at 12:16:54PM +1000, Chris Angelico wrote:
> (How often do people even use "x is True"?)
Alas, that is a common idiom. For example:
https://stackoverflow.com/questions/50816182/pep-8-comparison-to-true-should-be-if-cond-is-true-or-if-cond
It's possibly less common than it
On Sat, Sep 12, 2020 at 05:48:30PM -0700, Paul Bryan wrote:
> I meant to ask, why is nan not comparable? Even:
>
> >>> math.nan == math.nan
> False
It is worth explaining why the IEEE-754 standards committee agreed to
make NANs unequal to everything.
"It is not possible to specify a
On Sat, Sep 12, 2020 at 08:16:36PM -0400, Cade Brown wrote:
> As per tagged nans, check for JavaScript tagged NaN optimization.
> Essentially, the tag of the NaN (i.e. the mantissa) is interpreted as a
> pointer. Obviously, this is a very advanced use case, probably not worth
> Python guaranteeing
On Sun, Sep 13, 2020 at 12:32:54AM -0400, Random832 wrote:
> This isn't what I was suggesting - I meant something like this:
>
> class instancemethod:
> def __init__(self, wrapped):
> self.wrapped = wrapped
> def __get__(self, obj, objtype):
> if obj is None: return
On Sat, Sep 12, 2020 at 07:25:30PM -0400, Eric V. Smith wrote:
> On 9/12/2020 7:13 PM, Random832 wrote:
> >On Fri, Sep 11, 2020, at 19:57, Cameron Simpson wrote:
> >>The default (an instance method) requires "self" to perform.
> >Of course, this is only the default if the method is a function
On Sat, Sep 12, 2020 at 02:09:11PM -1000, David Mertz wrote:
> On Sat, Sep 12, 2020, 2:02 PM Steven D'Aprano wrote:
>
> > In general though, Python doesn't support generating the full range of
> > NANs with payloads directly.
>
>
> I've researched this a little bit f
On Sat, Sep 12, 2020 at 05:37:23PM -0700, Christopher Barker wrote:
> On Sat, Sep 12, 2020 at 5:05 PM Steven D'Aprano wrote:
> > IEEE-754 requires that float literals overflow to infinity.
>
> sure, which means that, e.g. 1e100 * 1e300 would overflow to Inf.
>
> But that
On Sat, Sep 12, 2020 at 12:56:25PM -0700, Christopher Barker wrote:
> Is there any guarantee in Python or the C spec, or the IEEE spec that, e.g.:
>
> 1e1
>
> would create an Inf value, rather than an error of some sort?
IEEE-754 requires that float literals overflow to infinity.
I don't
On Sat, Sep 12, 2020 at 11:06:35AM -0400, Cade Brown wrote:
> If, in the future, Python used a library such as MPFR and made all floats a
> given precision (say, by giving a flag to the interpreter "python
> -prec2048"), it would never be enough to make infinity because it only has
> the
On Fri, Sep 11, 2020 at 11:19:05AM -1000, David Mertz wrote:
> On Fri, Sep 11, 2020 at 10:19 AM Guido van Rossum wrote:
>
> > While one may argue that writing `1e1000` is not an "arithmetic
> > operation", certainly it's certainly not "casting strings to floats", and
> > it's the simeplest way
On Fri, Sep 04, 2020 at 06:30:39PM -0400, Todd wrote:
> It will break an ENORMOUS amount of code. Numpy has its own top-level
> "inf" variable. So all code that uses "from numpy import *" will break.
Yeah no.
py> import builtins
py> builtins.inf = "Hello world!"
py> inf
'Hello
On Sat, Sep 05, 2020 at 04:00:40PM +0900, Stephen J. Turnbull wrote:
> Jeffrey Kintscher writes:
>
> > "from foo import *" is a really lazy programming practice
>
> However much corporate policies and educators may deprecate widely
> adopted coding practices, complaining about them will get you
On Sat, Sep 05, 2020 at 11:01:33AM +0300, Serhiy Storchaka wrote:
> 05.09.20 06:52, Christopher Barker пише:
> > I am a -0 on this, but I think it was Greg Ewing that presented a real
> > use case:
> >
> > There is no way to use literal_eval that gets you an inf (or NaN value).
>
>
On Sat, Sep 05, 2020 at 12:44:47AM -0400, Cade Brown wrote:
> First of all, you're comparing immutable value types to dynamic objects
> which are predicated and processed based on the memory address (e.g. for
> equality testing, by default). Of course they're going to have different
> semantics,
On Fri, Sep 04, 2020 at 08:52:22PM -0700, Christopher Barker wrote:
> I am a -0 on this, but I think it was Greg Ewing that presented a real use
> case:
>
> There is no way to use literal_eval that gets you an inf (or NaN value).
>
> Which is a real, though maybe not important, use case.
That's
On Fri, Sep 04, 2020 at 09:40:55PM -0400, Cade Brown wrote:
> The `eval(repr(x)) == x` is not a segment of my code; rather it is part of
> Python's description of what 'repr' should do:
>
> https://docs.python.org/3.4/library/functions.html?highlight=repr#repr
>
>
> Specifically: ` For many
On Fri, Sep 04, 2020 at 06:10:23PM -0400, Cade Brown wrote:
> I mentioned that in my post; however it doesn't satisfy the problems I have
> (mainly being that eval(repr(x))==x)
Further to my previous comment, if you *absolutely must* use eval, you
can mitigate some (but not all) security
On Fri, Sep 04, 2020 at 06:10:23PM -0400, Cade Brown wrote:
> I mentioned that in my post; however it doesn't satisfy the problems I have
> (mainly being that eval(repr(x))==x)
I'm not very sympathetic to that problem. `eval(repr(x))` is a Nice To
Have convenience for the interactive
On Wed, Sep 02, 2020 at 12:55:43PM +1200, Greg Ewing wrote:
> On 2/09/20 3:44 am, Steven D'Aprano wrote:
> >(9) Keyword-only subscripts are permitted:
> >
> > obj[spam=1, eggs=2]
> > # calls type(obj).__getitem__(spam=1, eggs=2)
> >
> > del obj[s
On Tue, Sep 01, 2020 at 09:04:31AM -0700, Christopher Barker wrote:
> The set case is non-trival (which you do discuss later), but could you
> provide an example or two here as well?
>
> I think:
>
> obj[foo, bar, spam=1, eggs=2] = a_value
> # calls type(obj).__getitem__((foo, bar),
This is slightly revised version of something I sent to Stefano two
weeks ago. I hope he is planning to use this, or something similar, in
the PEP, but for what it's worth here it is for discussion.
This is, as far as I can tell, the minimum language change needed to
support keywords in
On Sun, Aug 30, 2020 at 05:49:50PM +1200, Greg Ewing wrote:
> On 30/08/20 3:06 pm, Steven D'Aprano wrote:
> >On Thu, Aug 27, 2020 at 11:13:38PM +1200, Greg Ewing wrote:
> >
> >>a[17, 42]
> >>a[time = 17, money = 42]
> >>a[money = 42, time = 17
On Mon, Aug 31, 2020 at 04:01:06AM -, junkneno...@gmail.com wrote:
> I have a use case which relates to this request: iterating over a dict
> starting from a given key. I would like to achieve this without having
> to pay the full O(n) cost if I'm going to be iterating over only a few
>
On Sun, Aug 30, 2020 at 09:56:28PM +1200, Greg Ewing wrote:
> A thought just occurred to me. If we hadn't got rid of tuple
> unpacking in argument lists, we would have been able to write
>
> def __getitem__(self, (x, y, z), **kwds):
> ...
Indeed.
Now that Python is moving to a PEG
On Sat, Aug 29, 2020 at 07:22:52PM +0100, Paul Moore wrote:
> > Item assignment (ie __setitem__) is the one thing that a function call
> > can't do. If we want keywords in our __getitem__ and so on commands, then
> > one route for item assignment is to allow
> > >>> d[1, 2, a=3, b=4] = 5
>
On Thu, Aug 27, 2020 at 11:13:38PM +1200, Greg Ewing wrote:
> >So if you want to accept keywords, you just add keywords to your
> >existing dunder method. If you don't want them, don't add them. We don't
> >need a new dunder just for the sake of keywords.
>
> Nobody disputes that it *could* be
On Sat, Aug 29, 2020 at 04:31:53PM -0700, Guido van Rossum wrote:
> On Sat, Aug 29, 2020 at 4:08 PM Guido van Rossum wrote:
>
> > [...]
> > Finally, I am unsure how you would deal with the difference between d[1]
> > and d[1,], which must be preserved (for `__keyfn__ = True` or absent, for
> >
On Sat, Aug 29, 2020 at 12:50:15AM -0400, Ricky Teachey wrote:
> I was really trying to explain the semantics multiple times but as I look
> over my messages your criticism is correct, I was throwing out too many
> detailed examples rather than focusing on the idea.
Also there are so many
On Fri, Aug 28, 2020 at 09:34:43AM -0700, Christopher Barker wrote:
> And on the Python side, there is no standard way to represent arbitrary
> text files as Python objects.
Um, sure there is: unstructured text, which is exactly what Python does.
And contrary to Steve Barnes' comments, Python
On Thu, Aug 27, 2020 at 09:57:26AM -0400, Ricky Teachey wrote:
> Sorry, I need to stop coding in shorthand.
That might help.
What might help even more is if you spend less time showing imaginary,
and invariably buggy, examples and more time explaining in words the
intended semantics of this,
On Fri, Aug 28, 2020 at 05:30:26PM +0900, Stephen J. Turnbull wrote:
> David Mertz writes:
>
> > I support named indices. But I strongly oppose using them in list,
> > tuple, or dict themselves. So `mylist[99, default=4]` would still
> > be a syntax error (or maybe a different exception).
>
On Thu, Aug 27, 2020 at 07:10:38PM +0200, Alex Hall wrote:
> On Thu, Aug 27, 2020 at 6:32 PM Steven D'Aprano wrote:
>
> > Personally, I found your examples underwhelming because they're mostly
> > repetitions of the same pattern.
> >
>
> That's surprising to me. Wh
On Thu, Aug 27, 2020 at 03:17:24PM +0200, Alex Hall wrote:
> I'm copying my earlier post because apparently linking to it repeatedly has
> no effect and people keep on claiming that this method wouldn't be useful
> while not saying a word about the evidence I presented that it would be.
Perhaps
On Thu, Aug 27, 2020 at 11:49:22PM +0900, Stephen J. Turnbull wrote:
> Alex Hall writes:
>
> > OK, I'll try again. Do people want collections to get a standard 'default'
> > for `__getitem__`?
>
> I don't know.
I'm pretty sure that Guido said that he doesn't want the builtin dict
and list
On Thu, Aug 27, 2020 at 07:24:01AM -0400, Ricky Teachey wrote:
> It kills at least 3 birds with one stone:
>
> 1. Brings kwd arguments to item dunders (PEP 472 does this too, but a
> key/index translation dunder kills two other birds)
I would put it another way: your proposal to redesign
On Thu, Aug 27, 2020 at 08:25:45AM +0100, Stefano Borini wrote:
> I already sent a mail to D'Aprano and he said (please Steven correct
> me if I am wrong) that basically PEP-472 as is is not acceptable (and
> I agree) without modifications.
What I said was that *I* "cannot support any of the
On Thu, Aug 27, 2020 at 03:28:07AM +1200, Greg Ewing wrote:
> On 27/08/20 12:53 am, Steven D'Aprano wrote:
>
> >Presumably the below method is provided by `object`. If not, what
> >provides it?
> >
> >> def __getindex__(self, *args, **kwds):
> >&g
On Wed, Aug 26, 2020 at 12:32:56PM -0400, Ricky Teachey wrote:
> On Wed, Aug 26, 2020 at 11:19 AM Steven D'Aprano
> wrote:
>
> > On Wed, Aug 26, 2020 at 10:10:34AM -0400, Ricky Teachey wrote:
> >
> > > But I have to say that I think this latest is a fantastic
On Wed, Aug 26, 2020 at 11:03:20PM +0100, Stefano Borini wrote:
> On Wed, 26 Aug 2020 at 17:50, David Mertz wrote:
> >
> > In my mind, *anything* other than the straightforward and obvious
> > signature `__getitem__(self, index, **kws)` is a pointless
> > distraction.
>
> It isn't.
> and the
On Wed, Aug 26, 2020 at 11:06:26AM -0400, Ricky Teachey wrote:
> Well I did give a couple examples: language supported opt-in for
> pep-472-ification, and pep-472 opt-out. But Ok, more are needed.
That's one example, not a couple: the ability to choose whether to
opt-in or opt-out of keyword
On Wed, Aug 26, 2020 at 10:10:34AM -0400, Ricky Teachey wrote:
> But I have to say that I think this latest is a fantastic idea, and when
> Jonathan presented it to me it was very surprising that I had not seen it
> presented by anyone else yet. I think it solves a ton of problems,
Such as?
>
On Tue, Aug 25, 2020 at 10:51:42PM -0400, Ricky Teachey wrote:
> > The only way it could tell that would be to inspect *at runtime* the
> > `__setitem__` method. And it would have to do this on every subscript
> > call. Introspection is likely to be slow, possibly very slow. This would
> > make
On Wed, Aug 26, 2020 at 03:06:25PM +1200, Greg Ewing wrote:
> On 26/08/20 1:59 pm, Steven D'Aprano wrote:
> >Most existing uses of subscripts already don't fit that key:value
> >mapping idea, starting with lists and tuples.
>
> Not sure what you mean by that.
Lists and tu
Please don't hijack an existing PEP for an unrelated issue.
PEP 472 is an existing PEP for "Support for indexing with keyword
arguments".
https://www.python.org/dev/peps/pep-0472/
If you want to write a competing PEP, see PEP 1 for the steps you must
follow:
On Wed, Aug 26, 2020 at 11:31:25AM +1200, Greg Ewing wrote:
> I think an argument can be made that the new dunder -- let's call
> it __getindex__ for now -- shouldn't be considered part of the
> mapping protocol. It's a new thing for classes that want to use the
> indexing notation in ways that
On Mon, Aug 24, 2020 at 01:10:26PM -0400, Ricky Teachey wrote:
> SIGNATURE === SEMANTICS
> (self, a, b) === (self, key_tuple, value)
>
> In the above, a on the left side, semantically, is the key tuple, and b in
> the value on the RHS.
That's not how Python works today. Individual values
On Fri, Aug 07, 2020 at 06:31:02PM -0700, Stephan Hoyer wrote:
> To fill in my missing word: From my perspective, the *only* reasonable way
> to add keyword arguments to indexing would be in a completely backwards
> compatible way with **kwargs.
Do you have a reason for this assertion?
I see no
On Tue, Aug 25, 2020 at 09:23:18PM +0100, Stefano Borini wrote:
> There's another option (but I am not endorsing it):
>
> a[1:2, 2, j=4:7, k=3] means:
>
> a.__getitem__((slice(1, 2, None), 2, named("j", slice(4, 7, None)),
> named("k", 3)}))
This is not another option, it's just a variant on
On Tue, Aug 25, 2020 at 10:22:20AM -0700, Christopher Barker wrote:
> This one is easier than most because it's pretty much a do we or don't we
> question, with the spelling semantics, all pretty much already decided.
Is it to be added to lists, or lists and tuples? How about range
objects?
On Mon, Aug 24, 2020 at 10:58:13AM +0200, Alex Hall wrote:
> {a:b} is a dict, {(a:b)} is a set containing one slice.
What's `{a: b: c: d, x: y}`? Typo or key with a slice value?
I know that any syntax can contain typos, but we generally try to avoid
syntax which silently swallows such
On Sun, Aug 23, 2020 at 09:43:14PM -0700, Christopher Barker wrote:
> Why not allow slice syntax as an expression everywhere? Everywhere I’ve
> tried, it’s a syntax error now, but is there any technical reason that it
> couldn’t be used pretty much anywhere?
When do you use slices outside of a
I attempted to send this yesterday, but used the wrong sender email
address and it got rejected.
I think this is still relevent, just to confirm I understand the
proposal correctly.
- Forwarded message from Steven D'Aprano -
Date: Mon, 24 Aug 2020 11:46:02 +1000
From: Steven
On Sun, Aug 23, 2020 at 03:47:59PM +0100, Stefano Borini wrote:
> I am currently in the process of scouting the whole set of threads and
> rewrite PEP-472, somehow.
> but just as a 2 cents to the discussion, the initial idea was focused
> on one thing only: give names to axes.
That is one of the
On Tue, Aug 18, 2020 at 07:39:29AM +0200, Marco Sulla wrote:
> For example, many py programmers desider to make their objects a
> constant. This could be done in the example I wrote before:
>
> from mykeywords import @const
> @const a = 1
>
> The new `@const` will be added as a hook to the PEG
On Sat, Aug 22, 2020 at 10:50:28PM -, redrad...@gmail.com wrote:
> Actually, I would like to write a proposal ...
> It would be nice if someone support me with it because I will do it at first
> time ... )
Okay, the first step is to familiarise yourself with the way the PEPs
are written:
On Fri, Aug 21, 2020 at 09:35:14AM -, Gustav O wrote:
> If a file named "tkinter.py" is created and tkinter is imported and used
> within the file, the following exception is raised:
> "AttributeError: partially initialized module 'tkinter' has no attribute 'Tk'
> (most likely due to a
On Thu, Aug 20, 2020 at 02:58:28PM -0400, Todd wrote:
> If xarray supports keyword arguments, this would assign to the
> corresponding values. If it didn't, it would create a new element of the
> Dataset containing "y[a=2, b=3]". But "y" would continue working as it
> would, only with different
On Thu, Aug 20, 2020 at 10:41:42AM -0700, Christopher Barker wrote:
> Current indexing behavior is an oddball now:
>
> ( you all know this, but I think it’s helpful to lay it out)
Correct.
> The signature of __getitem__ is always:
>
> def __getitem__(self, index):
Mostly correct -- you can
Hmmm, sorry, there was an encoding issue with my previous email. Somehow
my attempted U+2091 LATIN SUBSCRIPT SMALL LETTER E got turned into the
^J control character.
--
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe
On Thu, Aug 20, 2020 at 09:03:40AM -0400, Random832 wrote:
> On Mon, Aug 17, 2020, at 14:00, Christopher Barker wrote:
> > From an implementation perspective, the [] operator is another way to
> > call __getitem__ and __setitem__. And from that perspective, why not
> > have it act like a
On Mon, Aug 17, 2020 at 04:08:54PM +0200, Stefan Behnel wrote:
> I re-opened the ticket to allow for some discussion over there in order to
> understand the implications better. But I agree that a third-party package
> on PyPI seems like a good first step, also as a backport.
Perhaps I have
On Sun, Aug 16, 2020 at 11:18:40AM -0700, Guido van Rossum wrote:
> > Just to clarify here, I assume you mean that if xarray cares about
> > order-preserving keywords, they should write their methods this way:
> >
> > def __getitem__(self, index=None, **kwargs):
> >
> > rather than mandating
On Sun, Aug 16, 2020 at 12:07:47PM -0700, Guido van Rossum wrote:
[...]
> So I probably would be okay with allowing `obj[]` syntactically, as long as
> the dict type could be made to reject it.
I don't absolutely hate the idea, but I do feel that it's semantically
rather dubious. `obj` with no
On Mon, Aug 17, 2020 at 10:46:58AM +0200, Marco Sulla wrote:
> Well, "up" it's used in forums to draw attention :)
My ex-boss used to do the same thing except he would use "ping" to get
attention.
But in his case he would quote his previous (unanswered) question, so
that we would at least know
On Mon, Aug 17, 2020 at 12:32:08AM +1200, Greg Ewing wrote:
> On 16/08/20 11:49 am, Guido van Rossum wrote:
> >SEMANTICS OF NO ARGUMENTS
> >I can see two basic ways of allowing no arguments. One is for the
> >interpreter to construct an object that is the argument passed to
> >
On Sat, Aug 15, 2020 at 08:26:10PM -0700, Guido van Rossum wrote:
> Are you saying that for xarray it is important to distinguish between
> `d[day=3, detector=4]` and `d[detector=4, day=3]`? If we just passed the
> keyword args to `__getitem__` as an extra `**kwds` argument (which
> preserves
On Sat, Aug 15, 2020 at 09:25:00PM -0700, Stephan Hoyer wrote:
> One question that comes up: should d[**kwargs] be valid syntax? d[*args]
> currently is not, but that's OK since d[tuple(args)] is identical.
If we're going to support keyword arguments, what reason would we have
for not
On Fri, Aug 14, 2020 at 08:58:36PM -0400, Ricky Teachey wrote:
> One problem is type hint creation has been extended to built-ins in python
> 3.9, so that you do not have to import Dict, List, et al anymore.
>
> Without kwd args inside [ ], you would not be able to do this:
>
> Vector =
On Fri, Aug 14, 2020 at 04:07:33PM -0700, Caleb Donovick wrote:
> My own personal use for this would be for generating anonymous protocols
> and dataclasses:
>
> class T(Protocol):
> x: int
> y: str
> # with some abuse of notation obviously these would generate unique
> typesassert T ==
On Fri, Aug 14, 2020 at 08:45:44AM -0400, Ricky Teachey wrote:
> It seems very obvious to me that kwd args only should be valid, as Greg
> Ewing said, if kwd args are added.
Absolutely. We shouldn't even need to debate this. Would we consider a
language change that forced every single function
On Fri, Aug 14, 2020 at 10:43:31AM +0200, Marco Sulla wrote:
> Many times I want a function parameter that is an iterable but not a
> string. Usually I do:
>
> try:
> var.__iter__
> except AttributeError:
> # not an iterable
> else:
> try:
> var.isascii
> except
On Thu, Aug 13, 2020 at 09:33:46PM -0700, Guido van Rossum wrote:
> That's food for thought. I have to admit that I have forgotten almost
> everything about linear algebra that I was ever taught
In Australia, at least, secondary schools don't spend a lot of time
teaching matrices for linear
On Thu, Aug 13, 2020 at 11:17:00PM +0100, Stefano Borini wrote:
> The math module has plenty of mathematical functions that are very
> interesting, but no Matrix object.
Funny you mention this, I have been working on a Matrix object for
precisely the use-case you discuss (secondary school
On Thu, Aug 13, 2020 at 12:38:38PM -0700, Christopher Barker wrote:
> On Thu, Aug 13, 2020 at 12:27 PM Ben Rudiak-Gould
> wrote:
>
> >
> > I think islice should implement __length_hint__, though. As of 3.8.5 it
> > doesn't.
> >
>
> And it could support __len__, and raise an Exception when the
On Mon, Aug 10, 2020 at 12:20:49PM +0100, haael wrote:
>
> Forgive me if this has already been discussed.
>
>
> Could we add the idea of "negative" sets to Python? That means sets that
> contain EVERYTHING EXCEPT certain elements.
Can you give an example of what you would use this for? A
On Sat, Aug 08, 2020 at 08:13:53PM -0400, David Mertz wrote:
> Yes, this is absolutely doable! I guess my argument in several posts is
> that this simple level of analysis of "possible bounds violation" is rarely
> useful (at least in a Python context[*]). Vastly more complicated formal
> proofs
On Sat, Aug 08, 2020 at 01:28:59AM -0400, David Mertz wrote:
> On Sat, Aug 8, 2020, 1:12 AM Steven D'Aprano
>
> > Static languages often check what
> > bounds they can at compile time, and optionally insert bound checking
> > runtime code for ambiguous places.
>
On Sat, Aug 08, 2020 at 10:22:20PM -, Roger Serwy wrote:
> The property decorator, with its .setter and .deleter chaining, is a
> bit cumbersome and repetitive. If we can add `.apply` as a method on
> property that calls a function that returns the fget/fset/fdel/doc
> arguments, it would
On Fri, Aug 07, 2020 at 05:44:31PM -0400, Ricky Teachey wrote:
> Would it make good semantic sense- and be useful- to specify valid
> numerical ranges using slices and type-hint syntax? My suggestion would be
> to, at minimum, provide this functionality for int and float.
We know that
On Fri, Aug 07, 2020 at 11:48:40PM -0400, David Mertz wrote:
> On Fri, Aug 7, 2020, 6:03 PM Paul Moore wrote:
>
> > > x: int[0:] # any ints greater than or equal to zero would match, others
> > would fail
> > > x: int[:101] # any ints less than 101 match
> > > x: int[0:101:2] # even less than
On Fri, Aug 07, 2020 at 12:09:28PM -0400, Ricky Teachey wrote:
> I was actually trying to help the kwd arg case here. As illustrated by the
> quote I included from Greg Ewing, there seems to be not even close to a
> consensus over what the semantic meaning of this should be:
>
> m[1, 2, a=3,
On Fri, Aug 07, 2020 at 06:40:33PM +0100, Rob Cliffe via Python-ideas wrote:
>
>
> On 07/08/2020 17:16, Serhiy Storchaka wrote:
> >The main problem to me with the exception catching expression is that
> >you need to add the exception name and several keywords, and it makes
> >real-world
On Thu, Aug 06, 2020 at 02:46:01PM +0100, MRAB wrote:
> On 2020-08-06 14:16, Stestagg wrote:
> > In the "New syntax", wouldn't these examples map to:
> >
> > d[1, 2, a=3] => d.__getitem__((1, 2), a=3)
> > and
> > d[(1, 2), a=3] => d.__getitem__((1, 2), a=3)
That is certainly what I would
On Fri, Aug 07, 2020 at 12:22:28PM +1200, Greg Ewing wrote:
> On 7/08/20 2:47 am, David Mertz wrote:
> >The only difference is that in the usual existing style, 'a' doesn't
> >know that it's called "a". You and Steven have both, basically, said
> >"Why would you possibly care about that?"
>
>
On Fri, Aug 07, 2020 at 05:54:18PM +1000, Steven D'Aprano wrote:
> This proposal doesn't say anything about reversing the decision made all
> those years ago to bundle all positional arguments in a subscript into a
> single positional parameter. What's done is done, that's
On Tue, Aug 04, 2020 at 10:58:51AM -0400, Todd wrote:
> My main issue with this is that, in my opinion, dunders are not something a
> beginner should be messing with anyway. By the time someone is experienced
> enough to start working on this, they are also experienced enough to
> understand
On Thu, Aug 06, 2020 at 04:01:47PM -, redrad...@gmail.com wrote:
> I see lots of use-cases for property decorators ...
We have had property decorators since version Python 2.2 which was 18
years ago. We know that there are many wonderful use-cases for things
like this. What you are not
On Thu, Aug 06, 2020 at 04:03:39PM -, redrad...@gmail.com wrote:
> No it is not possible to have something like this:
> ```python
> def function(cls):
> # Where is cls is Neuron class object
> pass
>
> class Neuron:
> activation = function(Neuron)
> ```
Correct. And it isn't
On Thu, Aug 06, 2020 at 08:11:50AM -, redrad...@gmail.com wrote:
> I think a property decorator can be useful, because you consider the simplest
> case with:
We already have `property`, which can be used as a decorator.
> ```python
> class MyClass:
> @my_property
> name = arg
> ```
On Thu, Aug 06, 2020 at 09:57:59AM +0200, Dominik Vilsmeier wrote:
> It seems that the OP has many such transformations and wants to use
> decorators to define a pipeline of transformations:
>
> @foo
> @bar
> @baz
> something = initial_value
>
> instead of
>
> something =
On Thu, Aug 06, 2020 at 11:22:38AM +1000, Chris Angelico wrote:
> On Thu, Aug 6, 2020 at 11:11 AM Steven D'Aprano wrote:
> > [Dominik Vilsmeier]:
> > > > That should be possible by doing `fred = my_property(42)` and defining
> > > > `__set_name__` on the `my_prop
On Wed, Aug 05, 2020 at 06:15:22PM -0700, Guido van Rossum wrote:
> On Wed, Aug 5, 2020 at 5:55 PM Steven D'Aprano wrote:
> > That require two different rules for decorators:
> >
> > @decorator over a `class name` or `def name` statement:
> >
> > - execu
On Wed, Aug 05, 2020 at 02:42:34PM -0400, David Mertz wrote:
> Here's something I think could be more useful (again, I'm +0 at best
> myself).
>
> >>> @unit("meter") a = 3 # a = unit("meter")("a", 3)
Why does the measurement "3 metres" need to know that it is bound to the
target name "a"?
On Wed, Aug 05, 2020 at 03:35:15PM +0200, Marco Sulla wrote:
[Greg Ewing]
> > > A considerable number of moons ago, I suggested that
> > >
> > > @my_property
> > > fred = 42
> > >
> > > should expand to
> > >
> > > fred = my_property("fred", 42)
> > >
> > > The point being to give
901 - 1000 of 2842 matches
Mail list logo
