On 06.08.20 04:58, Guido van Rossum wrote:
On Wed, Aug 5, 2020 at 6:42 PM Steven D'Aprano mailto:[email protected]>> wrote:
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
mailto:[email protected]>> wrote:
>
Mathew Elman writes:
> Being able to break multiple loops and having "labelled" breaks
> would be achievable using `except`, i.e. adding `except` to the
> loop statements before `else` like this:
This would certainly be consistent with the existing use of the except
keyword, unlike the proposa
JSON serialization used in many different libraries without the ability for
configuration (Example
https://github.com/aio-libs/aioredis/blob/8a207609b7f8a33e74c7c8130d97186e78cc0052/aioredis/commands/pubsub.py#L18).
Propose to add something like the context in the decimal module, wIch will
cont
I think a property decorator can be useful, because you consider the simplest
case with:
```python
class MyClass:
@my_property
name = arg
```
but consider it can generate the following code:
```python
class MyClass:
def name(self):
...
def see_name(self):
...
```
Thank you both for the feedback.
Some pros and cons that occur to me (I may be biased, YMMV):
> Pros:
> (1) It can cleanly separate the handling of break-type exceptions and
> other exceptions, if needed.
> (2) It actually clarifies what the dreaded "else" means!
> (3) it allows you to
On Thu, Aug 6, 2020 at 6:16 PM wrote:
>
> I think a property decorator can be useful, because you consider the simplest
> case with:
> ```python
> class MyClass:
> @my_property
> name = arg
> ```
> but consider it can generate the following code:
> ```python
> class MyClass:
> def nam
On Thu, Aug 6, 2020 at 3:40 AM Christopher Barker
wrote:
> I'm all for clear and helpful error messages, but this feels a tad too
> verbose (and even a bit patronizing) to me. But the highlighting of
> character look-alikes is very helpful.
>
> Perhaps something like:
>
> """
> SyntaxError: inval
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 = fo
On Thu, Aug 06, 2020 at 08:11:50AM -, [email protected] 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, 6 Aug 2020 at 00:14, Guido van Rossum wrote:
> On Wed, Aug 5, 2020 at 7:06 PM Steven D'Aprano
> wrote:
>
>> *blinks*
>>
>> When did this happen?
>>
>> I'm on Python-Ideas, Python-Dev, and I get announcements of new issues
>> on the bug tracker, and I don't recall ever seeing this feature
Hey all,
Instead of writing this:
```
try:
return my_dict[“a”][“b”][“c”][“d”]
except:
return “some default”
```
Or this
```
return my_dict.get(“a”, {}).get(“b”, {}),get(“c”, {}).get(“d”, “some
default”)
```
I propose we allow for an inline exception handler, like `eor`:
```
return my_di
Hi Todd
You wrote:
I guess the thing I don't understand is why you favor that API. Could you
> please explain what you think are the advantages of your approach, ideally
> with some examples where you think your approach is clearer?
>
I've created a github issue for this, which I'll answer her
On Thu, Aug 6, 2020 at 10:56 PM Jonathan Grant
wrote:
>
> Hey all,
>
> Instead of writing this:
>
> ```
> try:
> return my_dict[“a”][“b”][“c”][“d”]
> except:
> return “some default”
> ```
>
> Or this
> ```
> return my_dict.get(“a”, {}).get(“b”, {}),get(“c”, {}).get(“d”, “some default”)
> `
I was following you right up till this bit:
>
> By the way, as previously noted
> d[1, 2]
> d[(1, 2)]
> are at present equivalent. However, in the new syntax
> d[1, 2, a=3]
> d[(1, 2), a=3]
> are not equivalent. (The first has three arguments, the second two, the
> first of which i
On 2020-08-06 14:16, Stestagg wrote:
I was following you right up till this bit:
By the way, as previously noted
d[1, 2]
d[(1, 2)]
are at present equivalent. However, in the new syntax
d[1, 2, a=3]
d[(1, 2), a=3]
are not equivalent. (The first has
On 06/08/2020 08:57, Stephen J. Turnbull wrote:
Mathew Elman writes:
> Being able to break multiple loops and having "labelled" breaks
> would be achievable using `except`, i.e. adding `except` to the
> loop statements before `else` like this:
This would certainly be consistent with the e
Yes fair point.
That seems more correct
On Thu, Aug 6, 2020 at 2:49 PM MRAB wrote:
> On 2020-08-06 14:16, Stestagg wrote:
> > I was following you right up till this bit:
> >
> >
> > By the way, as previously noted
> > d[1, 2]
> > d[(1, 2)]
> > are at present equivalent
On Thu, Aug 6, 2020 at 01:00 Stephen J. Turnbull <
[email protected]> wrote:
> However, we would probably not want to burden all loops with the
> exception-handling machinery, so the compiler would have to do some
> hacky backtracking (I doubt that the arbitrary lookahead needed
Maybe I’m lacking context, but I don’t understand the proposal. Can you
explain the semantics and syntax you have in mind in more detail? How do
you get from the first example (@my_property etc.) to the second (def name,
def set_name)?
—Guido
On Thu, Aug 6, 2020 at 01:13 wrote:
> I think a prop
On Thu, Aug 6, 2020 at 2:52 AM Greg Ewing
wrote:
> On 6/08/20 6:42 am, David Mertz wrote:
> @unit("meter") a = 3 # a = unit("meter")("a", 3)
> @unit("foot") b = 4 # b = unit("foot")("b", 4)
>
> This still doesn't explain why the decorator syntax would be
> significantly better than j
Actually in example:
```python
class MyClass:
@my_property
name = arg
class MyClass:
def name(self):
...
def see_name(self):
...
```
I have done mistake ... of course it will not be like this ...
What I wanted to show that @my_property could add more complex behav
Also instead of making all class as dataclass, it would be possible to make
only some properties as instance properties:
```python
class Client:
bank = Bank()
@instance
name = Name()
print(f'Client.bank is {Client.bank}')
client = Client()
print(f'client.name is {client.name}')
```
_
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)
```
___
Python-ideas mailing list -- [email protected]
To unsubscribe
On 06/08/2020 12:39, Jonathan Grant wrote:
Hey all,
Instead of writing this:
```
try:
return my_dict[“a”][“b”][“c”][“d”]
except:
return “some default”
Please, say "except KeyError:" (or whatever). A bare "except" is
dangerous, as it will catch *all* exceptions, including totally
un
As this is a third party package, you, of course, can do what you want :-),
But I would likew to see more communicative error messages in standard
Python as well, and I think your package could be a great prototype --
thanks!
On Thu, Aug 6, 2020 at 2:57 AM André Roberge
wrote:
3. It allows one to
Based on experience with the decimal module, I think this would open a can of
worms. To match what decimal does, we would need a Context() object with
methods for dump, dumps, load, loads. There would need to be a thread-local or
contextvar instance accessed by getcontext and setcontext, and p
> Have a look at PEP 463, which looks into this in some detail.
I wish this PEP had gained more traction. Sooner or later, everyone wants an
expression form of a try/except.
When it comes to expressing "in the event of this exception, I want this
default", exception expressions read much more
On Fri, Aug 7, 2020 at 6:28 AM wrote:
>
> > Have a look at PEP 463, which looks into this in some detail.
>
> I wish this PEP had gained more traction. Sooner or later, everyone wants an
> expression form of a try/except.
>
> When it comes to expressing "in the event of this exception, I want th
I agree with Raymond. The "implicit context" pattern is really only
desirable in a small subset of situations, and I don't think
configuring JSON serialization is one of those.
(it may even be an active nuisance, because some libraries may be using
JSON as an implementation detail and a "JSON c
I have wanted this sort of syntax before but assumed it wasn't feasible and
never considered how I'd want it to look. One possibility that wasn't
mentioned in Chris's earlier PEP is this:
`value = func() except Exception with default`
Though you'd almost certainly want to use a more specific exce
`... except ... with ...` more closely mirrors the inline if-else syntax,
which I think is the idea, and it doesn't use a colon.
On Thu, Aug 6, 2020, 6:29 PM Rob Cliffe wrote:
>
>
> On 06/08/2020 23:14, Steele Farnsworth wrote:
> > I have wanted this sort of syntax before but assumed it wasn't
>
On 06/08/2020 21:24, [email protected] wrote:
Have a look at PEP 463, which looks into this in some detail.
I wish this PEP had gained more traction. Sooner or later, everyone wants an
expression form of a try/except.
When it comes to expressing "in the event of this exception, I
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?"
I've only really been thinking about attributes, but I suppose
it might be
On 06/08/2020 23:36, Steele Farnsworth wrote:
`... except ... with ...` more closely mirrors the inline if-else
syntax, which I think is the idea, and it doesn't use a colon.
Sorry, I don't understand. Presuambly you're referring to
x = expr1 if cond else expr2
I don't see how adding 'wit
How can we start to revive this PEP? And I completely agree, making the
syntax `... except ... with ...` is much better than `eor`.
On Thu, Aug 6, 2020 at 7:05 PM Rob Cliffe via Python-ideas <
[email protected]> wrote:
>
>
> On 06/08/2020 21:24, [email protected] wrote:
> >> Have
On 06/08/2020 23:14, Steele Farnsworth wrote:
I have wanted this sort of syntax before but assumed it wasn't
feasible and never considered how I'd want it to look. One possibility
that wasn't mentioned in Chris's earlier PEP is this:
`value = func() except Exception with default`
Er, how is
On Fri, Aug 7, 2020 at 11:01 AM Jonathan Grant
wrote:
>
> How can we start to revive this PEP? And I completely agree, making the
> syntax `... except ... with ...` is much better than `eor`.
>
Have a read of the PEP's rejection notice at the top. To revive the
PEP, the objections to it need to
37 matches
Mail list logo
