gmane.comp.python.devel

Re: What if we didn't have repr?

Greg Ewing — 2013-05-21T23:14:35

-1. The purposes of repr() and pprint() are quite different.

Please let's not make any sweeping changes about str() and
repr(). They're generally okay as they are, IMO.

Re: Is thread-safe smtpd desired/possible?

R. David Murray — 2013-05-21T17:43:32

Currently I am effectively the maintainer of that module, though other
people are helping out.


I don't think issue 11959 represents a categorical rejection of
improvements here; however, I suspect that tulip has an impact on this.

Regardless of that, any changes need to be discussed in a wider context
than just the smtpd module, no matter where changes are actually made.

--David

Is thread-safe smtpd desired/possible?

Sorin Stelian — 2013-05-21T16:50:23

Hi,

I am posting this here since I could find no active maintainer of the smtpd module.

In my work as a test engineer for Axis (www.axis.com) I encountered the need of having thread-safe SMTP servers. I know the use case of several SMTP servers running in concurrent threads might seem odd, but it can actually be quite useful for testing purposes.

I have implemented (for my own use) a possible solution which basically means that every SMTP channel has its own socket map, instead of using asyncore's global socket map. It would not involve any change in asyncore.

Looking at the disucssion from http://bugs.python.org/issue11959 it seems to me that such a solution would not be accepted. Do you think that modifying asyncore is more feasible? If not, is this something that might be looked at?

I can provide code if needed, but I would first like to know your thoughts about this.

Best regards,
Sorin

Re: PEP 409 and the stdlib

Ethan Furman — 2013-05-21T16:03:13

I had forgotten about that, Nick, thanks.

So the moral of the story for our library code and replacing exceptions is we should either do

     raise ... from OldException

or

     raise ... from None

depending on the importance of the originating exception.

And, of course, we only make these changes when we're already modifying the module for some other reason.

--
~Ethan~

Re: PEP 442 delegate

Guido van Rossum — 2013-05-21T16:42:20

No objections. Benjamin, don't accept it until we've had a chance to
talk this over in person. I think we'll see a lot of each other
starting next week... :-)

On Tue, May 21, 2013 at 9:00 AM, Benjamin Peterson <benjamin< at >python.org> wrote:

Re: PEP 442 delegate

Benjamin Peterson — 2013-05-21T16:00:28

2013/5/21 Antoine Pitrou <solipsis< at >pitrou.net>:

I think he's a scoundrel.



--
Regards,
Benjamin

PEP 442 delegate

Antoine Pitrou — 2013-05-21T15:57:39

Hello,

I would like to nominate Benjamin as BDFL-Delegate for PEP 442.
Please tell me if you would like to object :)

Regards

Antoine.

Re: PEP 409 and the stdlib

R. David Murray — 2013-05-21T15:55:43

[...]
 

Doubtless you are correct.  Now that you mention it I do remember being
confused, even as an experienced programmer, by the chained exceptions
when I first started dealing with them, but at this point I suppose it
has become second nature :).

I agree with the subsequent discussion that this error is a good case
for 'from None', given that any such conversion should make sure all
essential information is contained in the new error message.  And I agree
with Nick that there are probably many more places where 'raise from'
will help clarify things when we *don't* want 'from None'.

--David

Re: PEP 409 and the stdlib

Nick Coghlan — 2013-05-21T13:46:31

Hrvoje, can we drop this subthread please. The topic was addressed way
back when PEP 3134 was written, and there is already dedicated syntax
to distinguish incidental exceptions in error handlers ("raise new")
from deliberate replacement of an exception with a new one ("raise new
from original")

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan< at >gmail.com   |   Brisbane, Australia

Re: What if we didn't have repr?

Guido van Rossum — 2013-05-21T13:36:54

Actually changing __str__ or __repr__ is out of the question, best we can
do is discourage makingbthem different. But adding a protocol for pprint
(with extra parameters to convey options) is a fair idea. I note that Nick
sggested to use single-dispatch generic functions for this though. Both
have pros and cons. Post design ideas to python-ideas please, not here!

--Guido

On Tuesday, May 21, 2013, Łukasz Langa wrote:

Re: PEP 409 and the stdlib

Hrvoje Niksic — 2013-05-21T13:23:44

In my example code the "raise" keyword appears lexically inside the 
"except" clause.  The compiler would automatically emit a different 
raise opcode in that case.

NB in your example the "raise" is just as intentional, but invoked from 
a different function, which causes the above criterion to result in a 
false negative.  Even in so, the behavior would be no worse than now, 
you'd just get the old message.

Hrvoje

_______________________________________________
Python-Dev mailing list
Python-Dev< at >python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org

Re: What if we didn't have repr?

Łukasz Langa — 2013-05-21T13:16:40



What if we did the opposite?

1. Make __str__() a protocol for arbitrary string conversion.
2. Move the current __repr__() contracts, both firm and informal to a new, extensible version of pprint.

There has been some discussion led by Raymond in 2010 about a general `pprint rewrite`__ and I'm willing to pick up the idea with a PEP for inclusion in 3.4.



__ http://bugs.python.org/issue7434

Re: PEP 409 and the stdlib

Serhiy Storchaka — 2013-05-21T12:57:02

21.05.13 13:05, Hrvoje Niksic написав(ла):

In both cases the BusinessError exception raised explicitly. How do you 
distinguish one case from another?


_______________________________________________
Python-Dev mailing list
Python-Dev< at >python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org

Re: PEP 409 and the stdlib

Nick Coghlan — 2013-05-21T11:23:01

This ship sailed long ago (it was covered by the original exception
chaining spec in PEP 3134). If you want to deliberately replace an
exception while retaining the full traceback, you use "raise X from
Y", and the intro text will change to something like "This exception
was the direct cause of the following exception:"

This thread is about the case where you want to use "raise X from
None" to suppress the display of the original exception completely,
which is a new capability in Python 3.3. So whenever we consider
changing the standard library, we should also look at the explicit
chaining option, particularly when the original exception may have
happened inside a user provided callback (including method calls)

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan< at >gmail.com   |   Brisbane, Australia

Re: PEP 409 and the stdlib

Hrvoje Niksic — 2013-05-21T10:05:37

Yes, in that case the exception will appear unintentional and you get 
the old message — it's on a best-effort basis.

Hrvoje

_______________________________________________
Python-Dev mailing list
Python-Dev< at >python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org

Re: PEP 409 and the stdlib

Serhiy Storchaka — 2013-05-21T09:56:14

21.05.13 12:28, Hrvoje Niksic написав(ла):

try:
     x = d['key']
except KeyError:
     x = fallback('key')

def fallback(key):
     if key not in a:
         raise BusinessError(...)
     return 1 / a[key] # possible TypeError, ZeroDivisionError, etc


_______________________________________________
Python-Dev mailing list
Python-Dev< at >python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org

Re: PEP 435 - ref impl disc 2

Glenn Linderman — 2013-05-21T09:16:23

Oh, it was an hg misunderstanding (hg newbie here)... I wasn't getting 
the latest code.  Things are working much better now.

I notice, however, with my latest code at 
https://v_python< at >bitbucket.org/v_python/ref435a that demo1, which has an 
explicit duplicate name, and no __new__  or __init__ code, has a .value 
which is actually a IntET (as shown by the last print of the repr of the 
value).  However, demo2, which attempts to "marry" the classes and avoid 
the duplicate name specifications, has a .value which is an "unnamed" 
IntET, whereas one would expect it to be named.

Noticing the changes you made, I think it is a result of line 177 in 
ref435.py where you actually instantiate a 2nd copy of IntET—using the 
same parameters, but a separate instantiation from the 
"married-with-Enum" copy—to use as the value.  I guess there is no way 
to "extract" the IntET from the "married-with-Enum" copy, to use as the 
value?  So then, this is good, but not quite good enough: the 2nd copy 
of the IntET should have the same name as the "married-with-Enum" copy.

Now in demo4.py I figured out how I could fix that, since the second 
copy is (currently) made before the __init__ call for the 
"married-with-Enum" copy, and stored in an accessible place.

On the other hand, it is a bit of a surprise to have to do that, and it 
would also be a bit of a surprise for classes that have class state that 
affects the instantiation of instances... That might just mean that some 
classes can't be mixed with Enum, but I suppose known restrictions 
and/or side effects should be documented.

As an example of this, I tried to resurrect your AutoNumber from your 
message of 6 May 2013 19:29 -0700 in the "PEP 435: initial values must 
be specified? Yes" thread, but couldn't, apparently due to changes in 
the implementation of ref435, but after fixing those problems, I still 
got an error where it demanded a parameter to new, even though one 
shouldn't be needed in that case.

Re: PEP 409 and the stdlib

Hrvoje Niksic — 2013-05-21T09:28:33

By the use of the "raise" keyword.  Given the code:

try:
     x = d['key']
except KeyError:
     raise BusinessError(...)

...the explicit raising is a giveaway that the new exception was quite 
intentional.

Hrvoje

Re: PEP 409 and the stdlib

Serhiy Storchaka — 2013-05-21T08:36:29

21.05.13 10:17, Hrvoje Niksic написав(ла):

How do you distinguish intentional and unintentional exceptions?


_______________________________________________
Python-Dev mailing list
Python-Dev< at >python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org

Re: PEP 409 and the stdlib

Hrvoje Niksic — 2013-05-21T07:17:29

The word "occurred" misleads one to think that, during handling of the 
real exception, an unrelated and unintended exception occurred.  This is 
not the case when the "raise" keyword is used.  In that case, the 
exception was intentionally *converted* from one type to another.  For 
the "raise" case a wording like the following might work better:

     The above exception was converted to the following exception:
     ...

That makes it clear that the conversion was explicit and (hopefully) 
intentional, and that the latter exception supersedes the former.

Hrvoje

Re: PEP 435 - ref impl disc 2

Glenn Linderman — 2013-05-21T06:44:50

Gladly. And we now have several more days to have forgotten what we were 
doing/talking about...


Maybe.

I upgraded my ref435.py from yours at 
https://bitbucket.org/stoneleaf/ref435 (and your test file there 
references enum.py which is not there).

My demo1.py still doesn't work.  The first 4 lines are fine, but not the 
last two.  I still cannot do a lookup (via __call__ syntax) by either 
int or IntET value.

You have my old misnamed NEI class in your test file now, and the tests 
you use with it work... but you don't have a lookup test.  My demo1 
does, and that fails.

After instrumenting Enum.__new__ it seems that the member.value is still 
the constructor parameters...

Maybe I picked up the wrong version of your code?

Oh and demo1.py has leftover __new__ and __init__ definitions for NIE, 
modeled after your earlier suggestions. Leaving them in causes 
everything to be named 'temp'. Taking them out makes things not work 
differently.