On Sun, Dec 15, 2013 at 7:52 AM, Victor Stinner
wrote:
>
> Oh, I like this proposition! The following pattern is very common in Python:
>
> "... %.400s ...", Py_TYPE(self)->tp_name
>
Okay, I have created ticket (and preliminary patch) for this
enhancement: http://bugs.python.org/issue19984
Vajra
We all strive to be python programmers, and some of the responses are that
it might not be around in the future.
Now we all probably speak conversational in other langs, but I'm thinking
of keeping around a great prototyping language.
So the topic becomes how too integrate it with the not just t
Susskinds...Me too, but the refinement of the error messages is the point.
We should be looking at the full assessment of the error, which the
prototyping of python should present.
I've seen others reply that python wouldn't be around, or that theree are
other forms I've seen before that will take
On Sun, Dec 15, 2013 at 11:25:10AM +1000, Nick Coghlan wrote:
> Oh, yes, a %T shortcut for "length limited type name of the supplied
> object" would be brilliant. We need this frequently for C level error
> messages, and I almost always have to look at an existing example to
> remember the exact i
Hi.
On 15.12.2013. 0:19, Antoine Pitrou wrote:
It would be nice if you could get an actual C traceback
> and open an issue on the bug tracker.
Done. C traceback and related information collected and attached to a
new Python issue report available at:
http://bugs.python.org/issue19983
On 15 December 2013 09:52, Victor Stinner wrote:
> 2013/12/15 Antoine Pitrou :
>> Shouldn't we have a special "%T" shortcut instead of trying to
>> harmonize all the occurrences of `"%.400s", Py_TYPE(self)->tp_name` ?
>
> Oh, I like this proposition! The following pattern is very common in Python:
2013/12/15 Antoine Pitrou :
> Shouldn't we have a special "%T" shortcut instead of trying to
> harmonize all the occurrences of `"%.400s", Py_TYPE(self)->tp_name` ?
Oh, I like this proposition! The following pattern is very common in Python:
"... %.400s ...", Py_TYPE(self)->tp_name
Victor
__
On Sat, 14 Dec 2013 15:14:10 +0100
Jurko Gospodnetić wrote:
>
>I believe the current Python default SIGINT handling by raising an
> asynchronous KeyboardInterrupt exception is dangerous, and can directly
> cause Python interpreter crashes even if no user code is involved, or
> any sort of
On Sun, 15 Dec 2013 09:10:08 +1000
Nick Coghlan wrote:
>
> The question should probably be addressed directly in PEP 7, and I'd
> be inclined to just bless the "%.400s" variant for future code.
Shouldn't we have a special "%T" shortcut instead of trying to
harmonize all the occurrences of `"%.40
On 14 December 2013 14:56, Vajrasky Kok wrote:
> Greetings,
>
> When fixing/adding error message for wrong type of argument in C code,
> I am always confused, how long the wrong type is the ideal?
>
> The type of error message that I am talking about:
>
> "Blabla() argument 1 must be integer not w
Hi.
On 14.12.2013. 17:14, R. David Murray wrote:
On Sat, 14 Dec 2013 15:14:10 +0100, "Jurko Gospodneti"
wrote:
My scripts replace the default SIGINT/SIGBREAK signal handlers as
soon as possible, and everything works great after that, but things get
ugly if Ctrl-C is pressed before the s
David Hutto wrote:
Being that python is, to me, a prototyping language, then every possible
outcome should be presented to the end user.
So we should produce a quantum superposition of
error messages? :-)
(Sorry, I've been watching Susskind's lectures on
QM and I've got quantum on the brain at
Your subject should probably have mentioned Windows. SIGINT handling
on UNIX is well-behaved. Yes, you can interrupt a finally clause, but
this by itself doesn't threaten the integrity of the interpreter and
the standard data types.
On Windows, "signal" handling is some feeble emulation done by th
On Sat, 14 Dec 2013 15:14:10 +0100, "Jurko Gospodneti"
wrote:
>My scripts replace the default SIGINT/SIGBREAK signal handlers as
> soon as possible, and everything works great after that, but things get
> ugly if Ctrl-C is pressed before the script gets a chance to do this. I
> could even
Hi all.
Is there any way to disable the default asynchronous exception
raising SIGINT signal handling? Or a plan to add support for this? My
searches on the net found several bug reports and discussions regarding
this, but nothing seems final... :-(
I believe the current Python default
15 matches
Mail list logo
