Re: [Twisted-Python] what is a non-class class?

[Glyph Lefkowitz]

On Sep 3, 2014, at 12:55 AM, Wolfgang Rohdewald  
wrote:

> Am Mittwoch, 3. September 2014, 00:29:59 schrieb Glyph:
>>> That is my problem. How do I know if the object is of a non-class class?
>> 
>> isinstance(something, (types.ClassType, type)).
> 
> but that will make it possible to attach a method even to type "int"

Yes, that's fine.  'int' has methods, there's no reason that those methods 
couldn't be serialized by jelly.  For example:

>>> (3).conjugate


The bound method object there is the sort of thing that we're talking about.

Particularly since we might be talking about a subclass of 'int' with its own 
overridden conjugate method, and the im_class attribute says which class the 
method's function actually came from.

> Python2:
> 
 isinstance(int, type)
> True
> 
> isinstance(object, type)
>> True
> isinstance(object(), type)
>> False

> Sure but the test only gets the class and it should certainly not instantiate 
> it.

Right; the point is that you get a thing, and that thing may be a class object 
_or_ it might be an instance object, and if it's an instance that's invalid.

> Meanwhile I believe it is best to simply remove the test since python itself
> will reject most:
> 
 a=int
 a.x=5
> Traceback (most recent call last):
>  File "", line 1, in 
> TypeError: can't set attributes of built-in/extension type 'int'

This is about serializing and deserializing existing methods, not assigning 
attributes to instances.

-glyph

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Return only when value/handle is available

[exarkun]

On 05:52 pm, vikas.c.ku...@oracle.com wrote:

Hi Jonas,

This is nice.
But still we are retrying it repeatedly at regular interval(10). Can't 
we get the notified asynchronously as and when handle is available.


You tell us.  What's a handle?  Where do you get it from?  Does that 
system produce an event when it is ready?


Jean-Paul

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] spawnProcess with timeout and same error handling on Unix and Windows

[exarkun]

On 05:17 pm, a...@roiban.ro wrote:

On 3 September 2014 16:49, Adi Roiban  wrote:

Hi,

If I call spawnProcess with a bad executable, on Unix the process will
exit with exit code 1 while on Windows an OSError is raised.

I am working on a multi-OS software and to make my life easier I ended
up with this hack inspired by _BackRelay

https://gist.github.com/adiroiban/bac493f00ce5e94738ce



Is there something already in Twisted doing this? Am I reinventing the 
wheel?


If not, do you think that it would help to update _BackRelay to
support timeout and cross-os error handling?


Searching the Twisted trac I found this ticket
http://twistedmatrix.com/trac/ticket/4184

Maybe we can leave spawnProcess as the low-level API and then create
another wrapper which will handle/raise the errors in an consistent
way.

For the case where command is not found, I prefer the behaviour from
Windows where an OSError is raise, rather than
looking at errReceived and trying to guess is execvpe call failed or 
not.


It is more convenient, certainly.  Unfortunately on POSIX the underlying 
API isn't synchronous - which is why the POSIX implementation doesn't 
deliver the exception synchronously.  So to be uniform we probably need 
to make the Windows behavior asynchronous.


I suggest we can improve the situation by reporting the error more in an 
easier-to-recognize way when we report it asynchronously, though.


For example, instead of forcing the application to parse stderr we could 
deliver a different exception type to processEnded.


A better solution would be to make `spawnProcess` properly asynchronous 
- have it return a `Deferred` that fires with an `IProcessTransport` and 
let that `Deferred` fire with a `Failure` if there is a problem creating 
the new process.


But that's probably more like "introduce an API to replace 
`spawnProcess`" (for which I believe there is also a ticket).


Jean-Paul

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] spawnProcess - reapProcess not retrying on failures

[exarkun]

On 05:55 pm, exar...@twistedmatrix.com wrote:


Gtk messes with signals too.  There are confusing order-of-execution 
dependencies and Gtk changes subtly from release to release, re- 
breaking things after we fix them or changing them to be broken in a 
different way.


So that's *why* it probably doesn't work with Gtk2 reactor - if not 
*how*. ;)


I think I missed the explanation of what in particular wasn't working 
with Gtk2 reactor though.


Oh right, that was where Justin's bug was.

Jean-Paul

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] spawnProcess - reapProcess not retrying on failures

[exarkun]

On 03:27 pm, a...@roiban.ro wrote:

On 3 September 2014 14:39,   wrote:


Yes.  Providing more fine-grain control over signal handlers would be 
a fine

improvement.


Do you have any suggestion for how the calls should be made?

reactor.run(installSignalHandlers=True,  installStopHandlers=False)


Perhaps.

or

reactor.installStopHandlers = False
reactor.run()


Probably not this one.  Setting attributes on random things is kind of 
sad. :)


It might be nice to try to be somewhat flexible - in case there's some 
reason to change what signals the reactor wants to handle in the future. 
Perhaps:


   reactor.run(installSignalHandlers={SIGCHLD})

An entirely different direction could be to make this bit of 
configuration into initialization for the reactor.


   from twisted.internet.epollreactor import install
   install(installSignalHandlers={SIGCHLD})

   from twisted.internet import reactor
   ...
   reactor.run()

By keeping these details away from `IReactorCore.run`, that method 
remains maximally useful.  For example, if you could set up the reactor 
this way, a normal `twistd` plugin would still be able to benefit from 
your choice, even with twistd's naive call of `reactor.run()` with no 
extra arguments.


Application code calling these `install` functions is already supported 
(it's how you select a specific reactor, after all).  Some of the 
install functions even accept arguments already.


This would actually eliminate another existing issue - 
`IReactorCore.run` is actually defined to take no arguments.  The 
implementations ignore this because someone thought it was important to 
be able to disable installation of signal handlers.


Another fine improvement would be making child processes work even if 
a

SIGCHLD handler cannot be installed (for example, by polling children
periodically, by using wait() in a sidecar process, or by using a 
better
system-specific child process monitoring API (eg kqueue's 
EVFILT_PROC)).


I see that GlibReactorBase inherits from PosixReactorBase so it should
install the SIGCHLD handler... this should not be the reason why gtk2
reactor don't work.


Gtk messes with signals too.  There are confusing order-of-execution 
dependencies and Gtk changes subtly from release to release, re-breaking 
things after we fix them or changing them to be broken in a different 
way.


So that's *why* it probably doesn't work with Gtk2 reactor - if not 
*how*. ;)


I think I missed the explanation of what in particular wasn't working 
with Gtk2 reactor though.

As a poor man's fix and Unix independent fix maybe we can call
reapAllProcess in a task.LoopingCall...
What are the reasons why SIGCHLD handler cannot be installed?


Either because you want to run the reactor in a non-main thread (where 
Python won't let you install signal handlers for the good reason that 
mixing signals and threads has crazy behavior) or because you want to 
use a different library that depends on having its own SIGCHLD handler 
and you're not interested in Twisted's process support.

I am asking since I hope it could help me understant where and how to
enable the poor man's fix... and how to fill the bug report.

kqueue's EVFILT_PROC would be great, but I guess that we still need a
general fix


Perhaps, perhaps not.  A general fix might be less code but having half 
a dozen specialized fixes, one for each reactor, would also still fix 
the problem.  The different reactor implementations are essentially the 
big piles of specialized fixes needed to do non-blocking I/O on 
different platforms.  This would just be a little more of the same.


The sidecar process is an example of a general fix, though.  The idea 
there is that Twisted itself runs a private child process (perhaps only 
when the first call to spawnProcess is made).  It talks to that process 
using a file descriptor.  That process can install a SIGCHLD handler 
(because Twisted owns it, application developers don't get to say they 
don't want one installed) or use another more invasive strategy for 
child process management.  When you want to spawn a process, the main 
process tells the sidecar to do it.  The sidecar relays traffic between 
the child and the original parent (or does something involving passing 
file descriptors across processes).


This removes the need to ever install a SIGCHLD handler in the main 
process.  It also probably enables some optimizations (reapProcesses is 
O(N!) on the number of child processes right now) that are very tricky 
or impossible otherwise.


Jean-Paul

-

For the record: Right now, to ignore SIGINT, SIGTERM, SIGBREAK handles
but keep SIGCHLD I do:

# Patch base reactor to not install SIGINT, SIGTERM and SIGBREAK 
handlers

_SignalReactorMixin._handleSignals = lambda self: None
reactor.run()


--
Adi Roiban


___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Return only when value/handle is available

[vikas kumar]

Hi Jonas,

This is nice.
But still we are retrying it repeatedly at regular interval(10). Can't 
we get the notified asynchronously as and when handle is available.


Regards
Vikas

On 9/3/2014 6:10 PM, Jonas Brunsgaard wrote:

I would fiddle around with something like this.

from twisted.internet.defer import inlineCallbacks, returnValue, Deferred
from twisted.internet import reactor


@inlineCallbacks
def foo(self, retries=10, interval=10):
while True:
try:
returnValue((yield self.get_handle()))
except SystemDelayException as e:
if retries > 0:
retries -= 1
d = Deferred()
reactor.callLater(interval, d.callback, None)
yield d
else:
raise e

On Wed, Sep 3, 2014 at 1:32 PM, vikas kumar > wrote:


Hi,

I am little new to twisted.
I've a function(get_handle) which returns a handle.

But get_handle() may throw an exception(SystemDelayException)
because of some delay in system.
My requirement is : When I get SystemDelayException re-attempt
get_handle() and return only when handle is available. How do I
use deferred/reactor in this scenario?

try:
handle = yield self.get_handle()
except SystemDelayException:
// code to re-attempt get_handle and return only when handle
is available

Regards
Vikas


___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com

http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python




___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python


___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] spawnProcess - reapProcess not retrying on failures

[Adi Roiban]

Just for reference: For the gkt2 reactor problem I found this bug
report https://twistedmatrix.com/trac/ticket/5289 ... I guess that
there is a problem with gtk2 and spawnProcess

On 3 September 2014 16:27, Adi Roiban  wrote:
> On 3 September 2014 14:39,   wrote:
>> On 01:05 pm, a...@roiban.ro wrote:
>>>
>>> On 2 September 2014 14:50,   wrote:

 On 01:38 pm, j...@editshare.com wrote:
>
>
>>> [snip]
>
>
> Without my workaround, I continue to have the problem with the
> gtk2reactor.


 Have you reported this bug?

 Jean-Paul
>>>
>>>
>>> In my initial use case, signal handlers were not installed since I
>>> wanted a custom behaviour for SIGINT, SIGTERM, SIGBREAK so that I can
>>> use my custom Unix Daemon and Windows Service adapters.
>>>
>>> I understand why reactor.run has the installSignalHandlers argument.
>>>
>>> Do you think it would make sense to have some kind of public API which
>>> would skip handlers for SIGINT, SIGTERM, SIGBREAK (as they only do
>>> reactor.stop())  but would install the SIGCHLD handler?
>>
>>
>> Yes.  Providing more fine-grain control over signal handlers would be a fine
>> improvement.
>
> Do you have any suggestion for how the calls should be made?
>
> reactor.run(installSignalHandlers=True,  installStopHandlers=False)
>
> or
>
> reactor.installStopHandlers = False
> reactor.run()
>
>
>> Another fine improvement would be making child processes work even if a
>> SIGCHLD handler cannot be installed (for example, by polling children
>> periodically, by using wait() in a sidecar process, or by using a better
>> system-specific child process monitoring API (eg kqueue's EVFILT_PROC)).
>>
>
> I see that GlibReactorBase inherits from PosixReactorBase so it should
> install the SIGCHLD handler... this should not be the reason why gtk2
> reactor don't work.
>
> As a poor man's fix and Unix independent fix maybe we can call
> reapAllProcess in a task.LoopingCall...
> What are the reasons why SIGCHLD handler cannot be installed?
>
> I am asking since I hope it could help me understant where and how to
> enable the poor man's fix... and how to fill the bug report.
>
>  kqueue's EVFILT_PROC would be great, but I guess that we still need a
> general fix
>
> -
>
> For the record: Right now, to ignore SIGINT, SIGTERM, SIGBREAK handles
> but keep SIGCHLD I do:
>
> # Patch base reactor to not install SIGINT, SIGTERM and SIGBREAK handlers
> _SignalReactorMixin._handleSignals = lambda self: None
> reactor.run()
>
>
> --
> Adi Roiban



-- 
Adi Roiban

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] spawnProcess with timeout and same error handling on Unix and Windows

[Adi Roiban]

On 3 September 2014 16:49, Adi Roiban  wrote:
> Hi,
>
> If I call spawnProcess with a bad executable, on Unix the process will
> exit with exit code 1 while on Windows an OSError is raised.
>
> I am working on a multi-OS software and to make my life easier I ended
> up with this hack inspired by _BackRelay
>
> https://gist.github.com/adiroiban/bac493f00ce5e94738ce
>
> 
>
> Is there something already in Twisted doing this? Am I reinventing the wheel?
>
> If not, do you think that it would help to update _BackRelay to
> support timeout and cross-os error handling?
>

Searching the Twisted trac I found this ticket
http://twistedmatrix.com/trac/ticket/4184

Maybe we can leave spawnProcess as the low-level API and then create
another wrapper which will handle/raise the errors in an consistent
way.

For the case where command is not found, I prefer the behaviour from
Windows where an OSError is raise, rather than
looking at errReceived and trying to guess is execvpe call failed or not.


-- 
Adi Roiban

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] spawnProcess with timeout and same error handling on Unix and Windows

[exarkun]

On 03:49 pm, a...@roiban.ro wrote:

Hi,

If I call spawnProcess with a bad executable, on Unix the process will
exit with exit code 1 while on Windows an OSError is raised.


Ideally, these two implementations of the same interface would have the 
same error behavior in this case.  In other words, this seems like a bug 
to me.


Jean-Paul

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] spawnProcess with timeout and same error handling on Unix and Windows

[Adi Roiban]

Hi,

If I call spawnProcess with a bad executable, on Unix the process will
exit with exit code 1 while on Windows an OSError is raised.

I am working on a multi-OS software and to make my life easier I ended
up with this hack inspired by _BackRelay

https://gist.github.com/adiroiban/bac493f00ce5e94738ce



Is there something already in Twisted doing this? Am I reinventing the wheel?

If not, do you think that it would help to update _BackRelay to
support timeout and cross-os error handling?


-- 
Adi Roiban

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] spawnProcess - reapProcess not retrying on failures

[Adi Roiban]

On 3 September 2014 14:39,   wrote:
> On 01:05 pm, a...@roiban.ro wrote:
>>
>> On 2 September 2014 14:50,   wrote:
>>>
>>> On 01:38 pm, j...@editshare.com wrote:


>> [snip]


 Without my workaround, I continue to have the problem with the
 gtk2reactor.
>>>
>>>
>>> Have you reported this bug?
>>>
>>> Jean-Paul
>>
>>
>> In my initial use case, signal handlers were not installed since I
>> wanted a custom behaviour for SIGINT, SIGTERM, SIGBREAK so that I can
>> use my custom Unix Daemon and Windows Service adapters.
>>
>> I understand why reactor.run has the installSignalHandlers argument.
>>
>> Do you think it would make sense to have some kind of public API which
>> would skip handlers for SIGINT, SIGTERM, SIGBREAK (as they only do
>> reactor.stop())  but would install the SIGCHLD handler?
>
>
> Yes.  Providing more fine-grain control over signal handlers would be a fine
> improvement.

Do you have any suggestion for how the calls should be made?

reactor.run(installSignalHandlers=True,  installStopHandlers=False)

or

reactor.installStopHandlers = False
reactor.run()


> Another fine improvement would be making child processes work even if a
> SIGCHLD handler cannot be installed (for example, by polling children
> periodically, by using wait() in a sidecar process, or by using a better
> system-specific child process monitoring API (eg kqueue's EVFILT_PROC)).
>

I see that GlibReactorBase inherits from PosixReactorBase so it should
install the SIGCHLD handler... this should not be the reason why gtk2
reactor don't work.

As a poor man's fix and Unix independent fix maybe we can call
reapAllProcess in a task.LoopingCall...
What are the reasons why SIGCHLD handler cannot be installed?

I am asking since I hope it could help me understant where and how to
enable the poor man's fix... and how to fill the bug report.

 kqueue's EVFILT_PROC would be great, but I guess that we still need a
general fix

-

For the record: Right now, to ignore SIGINT, SIGTERM, SIGBREAK handles
but keep SIGCHLD I do:

# Patch base reactor to not install SIGINT, SIGTERM and SIGBREAK handlers
_SignalReactorMixin._handleSignals = lambda self: None
reactor.run()


-- 
Adi Roiban

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] spawnProcess - reapProcess not retrying on failures

[exarkun]

On 01:05 pm, a...@roiban.ro wrote:

On 2 September 2014 14:50,   wrote:

On 01:38 pm, j...@editshare.com wrote:



[snip]


Without my workaround, I continue to have the problem with the
gtk2reactor.


Have you reported this bug?

Jean-Paul


In my initial use case, signal handlers were not installed since I
wanted a custom behaviour for SIGINT, SIGTERM, SIGBREAK so that I can
use my custom Unix Daemon and Windows Service adapters.

I understand why reactor.run has the installSignalHandlers argument.

Do you think it would make sense to have some kind of public API which
would skip handlers for SIGINT, SIGTERM, SIGBREAK (as they only do
reactor.stop())  but would install the SIGCHLD handler?


Yes.  Providing more fine-grain control over signal handlers would be a 
fine improvement.


Another fine improvement would be making child processes work even if a 
SIGCHLD handler cannot be installed (for example, by polling children 
periodically, by using wait() in a sidecar process, or by using a better 
system-specific child process monitoring API (eg kqueue's EVFILT_PROC)).


Jean-Paul

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] spawnProcess - reapProcess not retrying on failures

[Adi Roiban]

On 2 September 2014 14:50,   wrote:
> On 01:38 pm, j...@editshare.com wrote:
>>
[snip]
>>
>> Without my workaround, I continue to have the problem with the
>> gtk2reactor.
>
> Have you reported this bug?
>
> Jean-Paul

In my initial use case, signal handlers were not installed since I
wanted a custom behaviour for SIGINT, SIGTERM, SIGBREAK so that I can
use my custom Unix Daemon and Windows Service adapters.

I understand why reactor.run has the installSignalHandlers argument.

Do you think it would make sense to have some kind of public API which
would skip handlers for SIGINT, SIGTERM, SIGBREAK (as they only do
reactor.stop())  but would install the SIGCHLD handler?

Thanks!

-- 
Adi Roiban

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] spawnProcess - reapProcess not retrying on failures

[Justin Mazzola Paluska]

On 09/02/2014 09:50 AM, exar...@twistedmatrix.com wrote:


I dig deeper and I found out that since I was using
reactor.run(installSignalHandlers=False)  _SIGCHLDWaker was not
installed.

I have switched to using just reactor.run() and the process is now 
killed.


Without my workaround, I continue to have the problem with the 
gtk2reactor.


Have you reported this bug?


No, not yet since I don't have a 100%-reliable test case since it's 
mostly related to races between the child process, the parent process, 
and signal handling.  However, if that's not required, I'd love to get 
it in the system.

--Justin

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Return only when value/handle is available

[Adi Roiban]

One option in which we have both reactor and deferred :)

def do_low_level_stuff(deferred)
try:
deferred.callback(self.get_handle())
except SystemDelayException:
reactor.callLater(1, do_low_level_stuff, deferred)

def do_stuff():
deferred = Deferred()
do_low_level_stuff(deferred)
return deferred

Cheers

On 3 September 2014 12:32, vikas kumar  wrote:
> Hi,
>
> I am little new to twisted.
> I've a function(get_handle) which returns a handle.
>
> But get_handle() may throw an exception(SystemDelayException) because of
> some delay in system.
> My requirement is : When I get SystemDelayException re-attempt get_handle()
> and return only when handle is available. How do I use deferred/reactor in
> this scenario?
>
> try:
> handle = yield self.get_handle()
> except SystemDelayException:
> // code to re-attempt get_handle and return only when handle is
> available
>
> Regards
> Vikas
>
>
> ___
> Twisted-Python mailing list
> Twisted-Python@twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python



-- 
Adi Roiban

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] Return only when value/handle is available

[Jonas Brunsgaard]

I would fiddle around with something like this.

from twisted.internet.defer import inlineCallbacks, returnValue, Deferred
from twisted.internet import reactor


@inlineCallbacks
def foo(self, retries=10, interval=10):
while True:
try:
returnValue((yield self.get_handle()))
except SystemDelayException as e:
if retries > 0:
retries -= 1
d = Deferred()
reactor.callLater(interval, d.callback, None)
yield d
else:
raise e

On Wed, Sep 3, 2014 at 1:32 PM, vikas kumar 
wrote:

> Hi,
>
> I am little new to twisted.
> I've a function(get_handle) which returns a handle.
>
> But get_handle() may throw an exception(SystemDelayException) because of
> some delay in system.
> My requirement is : When I get SystemDelayException re-attempt
> get_handle() and return only when handle is available. How do I use
> deferred/reactor in this scenario?
>
> try:
> handle = yield self.get_handle()
> except SystemDelayException:
> // code to re-attempt get_handle and return only when handle is
> available
>
> Regards
> Vikas
>
>
> ___
> Twisted-Python mailing list
> Twisted-Python@twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>
___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

[Twisted-Python] Return only when value/handle is available

[vikas kumar]

Hi,

I am little new to twisted.
I've a function(get_handle) which returns a handle.

But get_handle() may throw an exception(SystemDelayException) because of 
some delay in system.
My requirement is : When I get SystemDelayException re-attempt 
get_handle() and return only when handle is available. How do I use 
deferred/reactor in this scenario?


try:
handle = yield self.get_handle()
except SystemDelayException:
// code to re-attempt get_handle and return only when handle is 
available


Regards
Vikas


___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] what is a non-class class?

[Wolfgang Rohdewald]

Am Mittwoch, 3. September 2014, 00:29:59 schrieb Glyph:
> > That is my problem. How do I know if the object is of a non-class class?
> 
> isinstance(something, (types.ClassType, type)).

but that will make it possible to attach a method even to type "int"

Python2:

>>> isinstance(int, type)
True

> >>> isinstance(object, type)
> True
> >>> isinstance(object(), type)
> False
> 

Sure but the test only gets the class and it should certainly not instantiate 
it.

Meanwhile I believe it is best to simply remove the test since python itself
will reject most:

>>> a=int
>>> a.x=5
Traceback (most recent call last):
  File "", line 1, in 
TypeError: can't set attributes of built-in/extension type 'int'


-- 
Wolfgang

___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python

Re: [Twisted-Python] what is a non-class class?

[Glyph]

On Sep 2, 2014, at 11:45 PM, Wolfgang Rohdewald  
wrote:

> I still do not like "non-class class" because this is a contradiction
> in itself.

How about "non-class found in class slot when deserializing method object"?

> Anyway a non-class class is a class whose objects may not get a 
> method attached. So far so good, but that was obvious.

Uh... no?  A non-class in an object which is not a class.  The error is when 
that object is provided as the class associated with a method.

> Am Dienstag, 2. September 2014, 16:29:41 schrieb Glyph Lefkowitz:
>> Except I think it might be broken in the face of new-style classes;
>> ClassType is the old-style class type, 'type' is the new one, so,
>> that should probably be fixed
> 
> That is my problem. How do I know if the object is of a non-class class?

isinstance(something, (types.ClassType, type)).

> As you say, current code does not handle new style classes.

Yes, but it could be easily modified to do so.

> I cannot check if the object is of type "type" because 
> int is also of type "type". An int certainly should not get
> a method attached. Then we could just as well remove this check.

>>> isinstance(object, type)
True
>>> isinstance(object(), type)
False

> That is why I proposed to instead exclude a list of basic types
> int, float, list, dict, set and so on.

I'm not sure I understand the proposal.  But in any case - it's not necessary.  
It's clearly possible to determine if a particular value is a type or not.

-glyph


___
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python