Terry Reedy wrote:
> Alternate proposal: give the NameError class a .name instance method
> that extracts the name from the message. This should not increase the
> time to create an instance. You would then write 'err.name()' instead
> of 'err.name'. For 3.6
>
> def name(self):
> msg = self
On 30.06.2017 00:57, Jan Kaliszewski wrote:
Please, note that it can be upturned: maybe they are not so common as
they could be because of all that burden with importing from separate
module -- after all we are saying about somewhat very simple operation,
so using lists and `+` just wins because
On Tue, Jul 04, 2017 at 11:37:51PM -0400, Terry Reedy wrote:
> I personally been on the side of wanting richer exceptions.
Could you explain what you would use them for? Ken has give two
use-cases which I personally consider are relatively niche, and perhaps
even counter-productive:
- translat
Hi all,
I want to point out that if it's not common to dispatch on values of
exceptions it might be **because** it is hard to do or to know wether
an exception will be structured or not. If Exceptions were by default
more structured, if CPython would provide a default
"StructuredException", or we
On Wed, Jul 05, 2017 at 03:29:35PM +0200, Matthias Bussonnier wrote:
> Hi all,
>
> I want to point out that if it's not common to dispatch on values of
> exceptions it might be **because** it is hard to do or to know wether
> an exception will be structured or not.
It "might be" for a lot of reas
Hi,
On Wed, 5 Jul 2017 at 16:41 Steven D'Aprano wrote:
> and more. Third parties *are* providing rich exception APIs where it
> makes sense to do so, using the interface encouraged by PEP 352 (named
> attributes), without needing a default "StructuredException" in the
> core language.
>
Your ar
I agree with Ken for the need to make rich exceptions easy to write, but
I do not know enough to say if changing BaseException to support this is
a good idea; I made my own error reporting library to do this: For
example, to define a new exception type with a `name` attribute:
raise Log.error("na
On Wed, Jul 05, 2017 at 04:12:29PM +, Ed Kellett wrote:
> Hi,
>
> On Wed, 5 Jul 2017 at 16:41 Steven D'Aprano wrote:
>
> > and more. Third parties *are* providing rich exception APIs where it
> > makes sense to do so, using the interface encouraged by PEP 352 (named
> > attributes), without
On 2017-07-05 04:36, Steven D'Aprano wrote:
On Tue, Jul 04, 2017 at 11:37:51PM -0400, Terry Reedy wrote:
I personally been on the side of wanting richer exceptions.
Could you explain what you would use them for? Ken has give two
use-cases which I personally consider are relatively niche, and
On Sun, Jun 25, 2017 at 6:20 PM, Mikhail V wrote:
> And it reminded me times starting with Python and wondering
> why I can't simply write something like:
>
> def move(x,y):
> x = x + 10
> y = y + 20
> move(x,y)
>
> Instead of this:
>
> def move(x,y):
> x1 = x + 10
> y1 = y + 20
On Mon, Jun 19, 2017 at 8:04 PM, Nick Coghlan wrote:
> As context for anyone not familiar with the time module precedent that
> Guido mentioned, we have a C level `PyStructSequence` that provides
> some of the most essential namedtuple features, but not all of them:
> https://github.com/python/cp
On Wed, Jul 5, 2017 at 11:34 AM, Chris Barker wrote:
> On Sun, Jun 25, 2017 at 6:20 PM, Mikhail V wrote:
>>
>> And it reminded me times starting with Python and wondering
>> why I can't simply write something like:
>>
>> def move(x,y):
>> x = x + 10
>> y = y + 20
>> move(x,y)
>>
>> Inste
On Sun, Jul 2, 2017 at 2:16 PM, Steven D'Aprano wrote:
> On Sat, Jun 24, 2017 at 10:42:19PM +0300, Koos Zevenhoven wrote:
>
> [...]
> > Clearly, there needs to be some sort of distinction between runtime
> > classes/types and static types, because static types can be more precise
> > than Python'
>
> Would there be any benefit in making a C implementation available from
> Python?
>
> -CHB
>
Yes, at startup time point of view.
Current Python namedtuple implementation uses `eval`.
It means we can't cache bytecode in pyc files.
For example, importing functools is not so fast and
its because
On Thu, Jul 6, 2017 at 10:46 AM, Jeff Walker wrote:
> I am one of those that also find you to be too negative. I find your
> critiques to
> be useful. You often raise issues that had not occurred to me. But then you
> go further an make pronouncements which I think go too far. For example:
>
>> t
On Thu, Jul 06, 2017 at 03:32:21AM +1000, Steven D'Aprano wrote:
> On Wed, Jul 05, 2017 at 04:12:29PM +, Ed Kellett wrote:
> > Hi,
> >
> > On Wed, 5 Jul 2017 at 16:41 Steven D'Aprano wrote:
> >
> > > and more. Third parties *are* providing rich exception APIs where it
> > > makes sense to do
I am one of those that also find you to be too negative. I find your critiques
to
be useful. You often raise issues that had not occurred to me. But then you
go further an make pronouncements which I think go too far. For example:
> the idea doesn't actually solve the problem it is intended to
o
Stephen,
These statements do not ring true to me. I have been following the
conversation
closely and I have not seen support for any of them. Perhaps I missed it.
Could you please expand on these statements:
> the idea doesn't actually solve the problem it is intended to
Specifically Ken st
18 matches
Mail list logo
