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
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
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 <
python-ideas@python.org> wrote:
>
>
> On 06/08/2020 21:24, raymond.hettin...@gmail.com wrote:
> >> Have
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
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 21:24, raymond.hettin...@gmail.com 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
`... 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
>
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
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
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
> 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
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
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
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
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 -- python-ideas@python.org
To unsubscribe
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}')
```
_
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
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
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 01:00 Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> 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
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 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
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
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 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”)
> `
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
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
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
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 = fo
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 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
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
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):
...
```
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
On 06.08.20 04:58, Guido van Rossum wrote:
On Wed, Aug 5, 2020 at 6:42 PM Steven D'Aprano mailto:st...@pearwood.info>> 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:st...@pearwood.info>> 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
37 matches
Mail list logo
