Thanks Simon.
Thanks for the extensive info; however it needs some hours (if not days :P)
to be digested.
On Tue, Dec 25, 2012 at 9:24 PM, Simon McVittie <
simon.mcvit...@collabora.co.uk> wrote:
> On 24/12/12 08:26, Ajay Garg wrote:
> > For a recap of the brief history, I have a parent process,
Also, I think I am now starting to get a hang of things; however, one
doubt solved raises another doubt :D
The reason I began looking out for the two-threads-approach, is because
when trying to use the GUI (Gtk) application as a dbus-service, I was
getting the error "This connection was not provi
On Dec 24, 2012 11:44 PM, "Brian Curtin" wrote:
>
> On Mon, Dec 24, 2012 at 7:42 AM, anatoly techtonik
wrote:
> > What should I do in case Eric lost interest after his GSoC project for
PSF
> > appeared as useless for python-dev community? Should I rewrite the
proposal
> > from scratch?
>
> Before
Currently we have exception tree of classes inherited from OSError
When we use C API we can call PyErr_SetFromErrno and
PyErr_SetFromErrnoWithFilename[Object] functions.
This ones raise concrete exception class (FileNotFoundError for
example) looking on implicit errno value.
I cannot see the way to
2012/12/25 Andrew Svetlov :
> Currently we have exception tree of classes inherited from OSError
> When we use C API we can call PyErr_SetFromErrno and
> PyErr_SetFromErrnoWithFilename[Object] functions.
> This ones raise concrete exception class (FileNotFoundError for
> example) looking on implici
static method is better than new builtin function, agree.
On Wed, Dec 26, 2012 at 12:03 AM, Benjamin Peterson wrote:
> 2012/12/25 Andrew Svetlov :
>> Currently we have exception tree of classes inherited from OSError
>> When we use C API we can call PyErr_SetFromErrno and
>> PyErr_SetFromErrnoWit
