> > Can you please clarify where/when I should call PyEval_InitThreads()? Is
> > this in the main python thread before any pthread callbacks are generated?
> > If so, should this be done only once?
> Do it in your module init. That function is safe to be called multiple ti
> On 28 Oct 2020, at 15:22, Paul Grinberg wrote:
>
>
>>
>> Try calling PyEval_InitThreads() to force the python threading to be all
>> setup.
>
> Can you please clarify where/when I should call PyEval_InitThreads()? Is this
> in the main python thr
> Try calling PyEval_InitThreads() to force the python threading to be all
> setup.
Can you please clarify where/when I should call PyEval_InitThreads()? Is this
in the main python thread before any pthread callbacks are generated? If so,
should this be done only once?
--
> On 28 Oct 2020, at 13:25, Paul Grinberg wrote:
>
>>> I am running into unpredictable behavior with my Python extension module
>>> that wraps around a C++ library that starts a new pthread and, after doing
>>> some work, generates callbacks b
> > I am running into unpredictable behavior with my Python extension module
> > that wraps around a C++ library that starts a new pthread and, after doing
> > some work, generates callbacks back into the caller. I've greatly
> > simplified this to a simplistic exa
/stackoverflow.com/questions/64559322/python-extension-module-with-callbacks-into-python
>
> I am running into unpredictable behavior with my Python extension module that
> wraps around a C++ library that starts a new pthread and, after doing some
> work, generates callbacks back into the c
As full disclosure, I posted this question on StackOverflow as well, but it
looks like questions with [Python] [Extension-Module] tags are not frequently
answered. The link to my question there is
https://stackoverflow.com/questions/64559322/python-extension-module-with-callbacks-into-python
I
Am Montag, 30. September 2019 11:46:43 UTC+2 schrieb Barry Scott:
> > On 29 Sep 2019, at 21:41, Eko palypse wrote:
> >
> > Am Sonntag, 29. September 2019 19:18:32 UTC+2 schrieb Barry Scott:
> >>> On 29 Sep 2019, at 14:14, Eko palypse wrote:
> >>>
>
> On 29 Sep 2019, at 21:41, Eko palypse wrote:
>
> Am Sonntag, 29. September 2019 19:18:32 UTC+2 schrieb Barry Scott:
>>> On 29 Sep 2019, at 14:14, Eko palypse wrote:
>>>
>>> Unfortunately, I can't make all callbacks synchronous or asynchronous
>
Am Sonntag, 29. September 2019 19:18:32 UTC+2 schrieb Barry Scott:
> > On 29 Sep 2019, at 14:14, Eko palypse wrote:
> >
> > Unfortunately, I can't make all callbacks synchronous or asynchronous
> > because this has negative effects on the application in one way or
> On 29 Sep 2019, at 14:14, Eko palypse wrote:
>
> Unfortunately, I can't make all callbacks synchronous or asynchronous because
> this has negative effects on the application in one way or another.
Surely you can make all callbacks async?
You do not have to have th
Am Sonntag, 29. September 2019 01:02:48 UTC+2 schrieb Paul Rubin:
> Eko palypse writes:
> > Two dicts, one for sync and the other for async registrations?
>
> Why not make all the callbacks asynchronous? Clients that don't want to
> handle a callback immediately can kee
s
as the keys and lists of methods being the values.
Notification sent, triggers the list of method to be called. Nothing fancy.
Now, where it gets trickier is that the client should be able to register
synchronous and asynchronous callbacks because some of the actions can't be
done in a s
> function()
>
> then the tkinter callbacks don't work anymore; can anybody make sense of
> this? thanks if you can help
>
> peace
> stm
>
> ps: here's the code...
When you invoke your script on the command line you'll get detailed
information about the er
hello pythonistas
the script below plays tictactoe; everything works; but if i replace the block
at the bottom
if True:
with this instead
def function():
function()
then the tkinter callbacks don't work anymore; can anybody make sense of this?
thanks if you can help
peace
st
ply, its based on the result of _one_ task.
>
> What I need I are continuations, much like the .NET TPL.
>
> def task_a():
> return "a"
>
> def task_b():
> return "b"
>
> def task_c():
> return "c"
>
> So I submit
;
def task_b():
return "b"
def task_c():
return "c"
So I submit task_a, if it completes successfully, task_b runs on its result.
If task_b completes successfully, task_c runs on its result. They "look"
like callbacks, but they are continuations.
Task_b
On Thu, Feb 18, 2016 at 12:06 PM, Joseph L. Casale
wrote:
> On Thur, Feb 17, 2016 at 9:24 AM, Ian Kelly wrote:
>>> What is the pattern for chaining execution of tasks with ThreadPoolExecutor?
>>> Callbacks is not an adequate facility as each task I have will generate new
On Thur, Feb 17, 2016 at 9:24 AM, Ian Kelly wrote:
>> What is the pattern for chaining execution of tasks with ThreadPoolExecutor?
>> Callbacks is not an adequate facility as each task I have will generate new
>> output.
>
> Can you specify in more detail what your use c
On Tue, Feb 16, 2016 at 2:48 PM, Joseph L. Casale
wrote:
> What is the pattern for chaining execution of tasks with ThreadPoolExecutor?
> Callbacks is not an adequate facility as each task I have will generate new
> output.
Can you specify in more detail what your use case is?
If
What is the pattern for chaining execution of tasks with ThreadPoolExecutor?
Callbacks is not an adequate facility as each task I have will generate new
output.
Thanks,
jlc
--
https://mail.python.org/mailman/listinfo/python-list
> ProcessPoolExecutor is built on the multiprocessing module, so I
> expect you should be able to use multiprocessing.Queue or
> multiprocessing.Pipe in place of threading.Queue.
Hi Ian,
Yeah I am using a Manager.Queue as the method polling the queue
is itself in a process.
I just wondered if the
On Wed, Mar 11, 2015 at 1:32 PM, Joseph L. Casale
wrote:
> I have a ProcessPoolExecutor for which I am attaching multiple callbacks.
> As this must be process based and not thread based, I don't have the
> luxury communication between threads. Without a queue, does something
>
I have a ProcessPoolExecutor for which I am attaching multiple callbacks.
As this must be process based and not thread based, I don't have the
luxury communication between threads. Without a queue, does something
inherent exist in concurrent futures that allows me to accumulate some
data fro
2) If more than one callback can be registered, is there an ordering to them?
3) Can a callback be registered more than once?
4) When and how are callbacks deregistered?
5) Who is responsible for maintaining a strong reference to the callback?
As far as I know, there isn't a standard method to in
> > > Yes, that looks like it would work.
>> >
>> >
>> > Cool!
>>
>> Sometimes I wonder whether anybody reads my posts. I suggested a solution
>> involving WeakMethod four days ago that additionally extends the concept to
>> non-method ca
ody reads my posts. I suggested a solution
> involving WeakMethod four days ago that additionally extends the concept to
> non-method callbacks (requiring a small amount of extra effort from the
> client in those cases, but I think that is unavoidable. There is no way that
> the fra
On Feb 26, 2015, at 7:04 PM, Fabio Zadrozny wrote:
>
> On Wed, Feb 25, 2015 at 9:46 AM, Cem Karan wrote:
>
> On Feb 24, 2015, at 8:23 AM, Fabio Zadrozny wrote:
>
> > Hi Cem,
> >
> > I didn't read the whole long thread, but I thought I'd point you to what
> > I'm using in PyVmMonitor (http:
On Feb 26, 2015, at 3:00 PM, Ethan Furman wrote:
> On 02/26/2015 11:54 AM, Ian Kelly wrote:
>
>> Sometimes I wonder whether anybody reads my posts.
>
> It's entirely possible the OP wasn't ready to understand your solution four
> days ago, but two days later the OP was.
Thank you Ethan, that
On Wed, Feb 25, 2015 at 9:46 AM, Cem Karan wrote:
>
> On Feb 24, 2015, at 8:23 AM, Fabio Zadrozny wrote:
>
> > Hi Cem,
> >
> > I didn't read the whole long thread, but I thought I'd point you to what
> I'm using in PyVmMonitor (http://www.pyvmmonitor.com/) -- which may
> already cover your use-c
On 02/26/2015 11:54 AM, Ian Kelly wrote:
> Sometimes I wonder whether anybody reads my posts.
It's entirely possible the OP wasn't ready to understand your solution four
days ago, but two days later the OP was.
--
~Ethan~
signature.asc
Description: OpenPGP digital signature
--
https://mail.
ef.html#weakref.WeakMethod)
solve
> >> this problem?
> >
> > Yes, that looks like it would work.
>
>
> Cool!
Sometimes I wonder whether anybody reads my posts. I suggested a solution
involving WeakMethod four days ago that additionally extends the concept to
non-method callback
On Feb 26, 2015, at 12:36 AM, Gregory Ewing wrote:
> Cem Karan wrote:
>> I think I see what you're talking about now. Does WeakMethod
>> (https://docs.python.org/3/library/weakref.html#weakref.WeakMethod) solve
>> this problem?
>
> Yes, that looks like it would work.
Cool!
Thanks,
Cem Kar
Cem Karan wrote:
I think I see what you're talking about now. Does WeakMethod
(https://docs.python.org/3/library/weakref.html#weakref.WeakMethod) solve
this problem?
Yes, that looks like it would work.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
On Feb 24, 2015, at 4:19 PM, Gregory Ewing wrote:
> random...@fastmail.us wrote:
>> On Tue, Feb 24, 2015, at 00:20, Gregory Ewing wrote:
>>> This is why I suggested registering a listener object
>>> plus a method name instead of a callback. It avoids that
>>> reference cycle, because there is no
On Feb 24, 2015, at 8:23 AM, Fabio Zadrozny wrote:
> Hi Cem,
>
> I didn't read the whole long thread, but I thought I'd point you to what I'm
> using in PyVmMonitor (http://www.pyvmmonitor.com/) -- which may already cover
> your use-case.
>
> Take a look at the callback.py at
> https://gith
random...@fastmail.us wrote:
On Tue, Feb 24, 2015, at 00:20, Gregory Ewing wrote:
This is why I suggested registering a listener object
plus a method name instead of a callback. It avoids that
reference cycle, because there is no long-lived callback
object keeping a reference to the listener.
;>> the owned object, but the owned object has no reference to its owner. With
>>> callbacks, you get cycles, where the owned owns the owner.
>>
>> This is why I suggested registering a listener object
>> plus a method name instead of a callback. It avoids that
&
I can make it as
obvious as possible in my code that before you perform any cleanup, you also
need to unregister from the library. That is my main goal in developing
pythonic/obvious methods of registering callbacks.
Thanks,
Cem Karan
--
https://mail.python.org/mailman/listinfo/python-list
Cem Karan wrote:
I tend to structure my code as a tree or DAG of objects. The owner refers to
the owned object, but the owned object has no reference to its owner. With
callbacks, you get cycles, where the owned owns the owner.
This is why I suggested registering a listener object
plus a
Cem Karan wrote:
>
> On Feb 21, 2015, at 12:27 PM, Steven D'Aprano
> wrote:
>> The simplest possible identity-based scheme would be something like this:
>>
>>
>> # don't hate me for using a global variable
>> CALLBACKS = []
>>
"Cem Karan" wrote in message
news:a3c11a70-5846-4915-bb26-b23793b65...@gmail.com...
>
>
> Good questions! That was why I was asking about 'gotchas' with WeakSets
> originally. Honestly, the only way to know for sure would be to write two
> APIs for doing similar things, and then see how peop
ple, several people have been strongly against using a WeakSet to
>> hold callbacks because they expect a library to hold onto callbacks.
>> If I chose not to do that, and used a WeakSet, then even if I
>> documented it, it would still end up surprising people (and from the
>>
ethodType):
owner = weakref.WeakMethod(callback)
else:
owner = callback
self._callbacks.setdefault(owner, []).append(callback)
def do_callbacks(self, message):
for callbacks in self._callbacks.values():
for callback in callbacks:
callback(message)
--
https://mail.python.org/mailman/listinfo/python-list
On Mon, Feb 23, 2015 at 9:29 AM, Laura Creighton wrote:
> But that is not so surprising. How many people use WeakSets for
> _anything_? I've never used them, aside from 'ooh! cool shiny
> new language feature! Let's kick it around the park!' That people
> aren't familiar with WeakSets doesn't
In a message of Sun, 22 Feb 2015 17:09:01 -0500, Cem Karan writes:
>Documentation is a given; it MUST be there. That said, documenting
>something, but still making it surprising, is a bad idea. For
>example, several people have been strongly against using a WeakSet to
>hold callb
idea. For example, several people
have been strongly against using a WeakSet to hold callbacks because they
expect a library to hold onto callbacks. If I chose not to do that, and used a
WeakSet, then even if I documented it, it would still end up surprising people
(and from the sound of it,
Cem Karan :
> My goal is to make things as pythonic (whatever that means in this
> case) and obvious as possible. Ideally, a novice can more or less
> guess what will happen with my API without really having to read the
> documentation on it.
If you try to shield your user from the complexities o
east shouldn't) try to prevent those kinds of
> bugs from manifesting -- they'll just get
> bitten somewhere else by the same bug.
I agree with you, but until a relatively new programmer has gotten used to what
callbacks are and what they imply, I want to make things easy. For exa
On 02/22/2015 05:13 AM, Cem Karan wrote:
> Output:
> From Evil Zombie: Surprise!
> From Your Significant Other: Surprise!
>
> In this case, the user made an error (just as Marko said in his earlier
> message),
> and forgot about the callback he registered with the library. The callback
> isn't
On Feb 22, 2015, at 5:15 AM, Gregory Ewing wrote:
> Frank Millman wrote:
>> "In order to inform users that certain bits of state have changed, I require
>> them to register a callback with my code."
>> This sounds to me like a pub/sub scenario. When a 'listener' object comes
>> into existence
>> The problem then, of course, is in the logic and not in the callbacks.
>>
>> This was PRECISELY the situation I was thinking about. My hope was to
>> make the callback mechanism slightly less surprising by allowing the
>> user to track them, releasing them whe
; the user to track them, releasing them when they aren't needed
>> without having to figure out where the callbacks were registered.
>> However, it appears I'm making things more surprising rather than
>> less.
>
> You may be able to accomplish your goal by usin
#x27;s the thing: GC relieves your from dynamic memory management. You
are still on your own when it comes to other resources.
> We're not trying to scare beginners, we're a group of moderately
> experienced coders discussing "best practice" (or at least "reasonabl
On Mon, Feb 23, 2015 at 12:45 AM, Steven D'Aprano
wrote:
>> No no no. It's the other way around. _Something_ has to be doing those
>> callbacks, and it's that _something_ that should be keeping them
>> alive. The fact that it's a registered callback should
> Helping it along means your program doesn't waste memory. Why such a
>> blanket statement?
>
> Because worrying Python programmers with evil spirits (reference loops)
> leads to awkward coding practices and takes away one of the main
> advantages of Python as a high-level
ce to the object knows the
> object is not supposed to be used anymore.
The other way round: the zombie object knows to ignore callbacks sent
its way. It's not the responsibility of the sender to mind the
receiver's internal state.
I nowadays tend to implement states as inner class
re about it, you don't need to know when it's been closed, the only
>>> event on it is "hit Close to destroy the window"), and most usage
>>> would have other complications, but it's not uncommon for me to build
>>> a GUI program that leaves everyth
Chris Angelico wrote:
> On Sun, Feb 22, 2015 at 9:32 PM, Steven D'Aprano
> wrote:
>> Why? Do you expect that the Python garbage collector special cases
>> callbacks to keep them alive even when there are no references to them?
>> How would it distinguish a call
On Feb 22, 2015, at 7:12 AM, Marko Rauhamaa wrote:
> Cem Karan :
>
>> On Feb 21, 2015, at 11:03 AM, Marko Rauhamaa wrote:
>>> I use callbacks all the time but haven't had any problems with strong
>>> references.
>>>
>>> I am careful to mo
f state have changed, I
>>>> require them to register a callback with my code. The problem is that
>>>> when I store these callbacks, it naturally creates a strong reference to
>>>> the objects, which means that if they are deleted without unregistering
&
st surprise for you.
>>>> Interesting. Is this a general pattern in python? That is, callbacks
>>>> are owned by what they are registered with?
>>>>
>>>> In the end, I want to make a library that offers as few surprises to the
>>>>
having to figure out where the callbacks were registered.
>However, it appears I'm making things more surprising rather than
>less.
You may be able to accomplish your goal by using a Queue with a
producer/consumer model.
see:
http://stackoverflow.com/questions/9968592/turn-functions
Cem Karan :
> On Feb 21, 2015, at 12:08 PM, Marko Rauhamaa wrote:
>> Maybe the logic of the receiving object isn't prepared for the callback
>> anymore after an intervening event.
>>
>> The problem then, of course, is in the logic and not in the callbacks.
>
&
only
>> event on it is "hit Close to destroy the window"), and most usage
>> would have other complications, but it's not uncommon for me to build
>> a GUI program that leaves everything owned by the GUI engine.
>> Everything is done through callbacks. Destr
t; Maybe the logic of the receiving object isn't prepared for the callback
> anymore after an intervening event.
>
> The problem then, of course, is in the logic and not in the callbacks.
This was PRECISELY the situation I was thinking about. My hope was to make the
callback mechan
Cem Karan :
> On Feb 21, 2015, at 11:03 AM, Marko Rauhamaa wrote:
>> I use callbacks all the time but haven't had any problems with strong
>> references.
>>
>> I am careful to move my objects to a zombie state after they're done so
>> they can ab
problem is that
>>> when I store these callbacks, it naturally creates a strong reference
>>> to the objects, which means that if they are deleted without
>>> unregistering themselves first, my code will keep the callbacks
>>> alive. Since this could lead to real
the only
> event on it is "hit Close to destroy the window"), and most usage
> would have other complications, but it's not uncommon for me to build
> a GUI program that leaves everything owned by the GUI engine.
> Everything is done through callbacks. Destroy a windo
somebody, I got confused with the indent level wrote:
>> They force the use of the much slower cycle-detecting GC, rather than
>> the quick and efficient CPython refcounter.
Somebody has misunderstood something here. When it comes to efficient
garbage collectors, refcounting is a turtle. The CP
On Sun, Feb 22, 2015 at 9:32 PM, Steven D'Aprano
wrote:
> Why? Do you expect that the Python garbage collector special cases callbacks
> to keep them alive even when there are no references to them? How would it
> distinguish a callback from some other function?
No no no. It&#
>> bucket_of_stuff.append(some_function(a, b, c))
>> bucket_of_stuff.append(make_web_server())
>> bucket_of_stuff.append(socket(23, on_accept=client_connected))
>
> Sure, and whether it's a name or a list-element reference doesn't
> matter: it seems wrong to
On Sun, Feb 22, 2015 at 8:14 PM, Marko Rauhamaa wrote:
>> Helping it along means your program doesn't waste memory. Why such a
>> blanket statement?
>
> Because worrying Python programmers with evil spirits (reference loops)
> leads to awkward coding practices and takes away one of the main
> adva
Frank Millman wrote:
"In order to inform users that certain bits of state have changed, I require
them to register a callback with my code."
This sounds to me like a pub/sub scenario. When a 'listener' object comes
into existence it is passed a reference to a 'controller' object that holds
st
Chris Angelico :
> On Sun, Feb 22, 2015 at 7:34 PM, Marko Rauhamaa wrote:
>> Refloops are not to be worried about, let alone removed.
>
> Why?
Because the whole point of GC-languages is that you should stop worrying
about memory. Trying to mastermind and micromanage GC in the application
is, par
On Sun, Feb 22, 2015 at 7:34 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> Or (a very common case for me) a callback saying "remote end is gone"
>> (eg on a socket) might wipe out the callbacks, thus removing their
>> refloops.
>
> Refloops are not to b
Chris Angelico :
> Or (a very common case for me) a callback saying "remote end is gone"
> (eg on a socket) might wipe out the callbacks, thus removing their
> refloops.
Refloops are not to be worried about, let alone removed.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
or, and its job is to break a reference cycle.
For instance, you might have a close() method that clears out a bunch
of references, which will then allow everything to get cleaned up
promptly. Or (a very common case for me) a callback saying "remote end
is gone" (eg on a socket) mig
Steven D'Aprano :
> Marko Rauhamaa wrote:
>> Grant Edwards :
>>> the polite thing to do is to delete references to it when you're done
>>> with it.
>>
>> I disagree with that recommendation. You should do the natural thing and
>> not care who holds references to who.
>
> I don't understand this.
f state have changed, I
>>>> require them to register a callback with my code. The problem is that
>>>> when I store these callbacks, it naturally creates a strong reference to
>>>> the objects, which means that if they are deleted without unregistering
&
"Steven D'Aprano" wrote in message
news:54e8af1b$0$12976$c3e8da3$54964...@news.astraweb.com...
> Frank Millman wrote:
>
>> I tried something similar a while ago, and I did find a gotcha.
>>
>> The problem lies in this phrase - "if they are no longer alive, they are
>> automatically removed from
make_web_server())
> bucket_of_stuff.append(socket(23, on_accept=client_connected))
Sure, and whether it's a name or a list-element reference doesn't
matter: it seems wrong to have to stash a thing in a bucket in order
to keep its callbacks alive. I expect the callbacks _themselves_
Chris Angelico wrote:
> On Sun, Feb 22, 2015 at 1:04 PM, Steven D'Aprano
> wrote:
>> Marko Rauhamaa wrote:
>>
>>> Grant Edwards :
>>>
the polite thing to do is to delete references to it when you're done
with it.
>>>
>>> I disagree with that recommendation. You should do the natural thi
On Sun, Feb 22, 2015 at 1:04 PM, Steven D'Aprano
wrote:
> Marko Rauhamaa wrote:
>
>> Grant Edwards :
>>
>>> the polite thing to do is to delete references to it when you're done
>>> with it.
>>
>> I disagree with that recommendation. You should do the natural thing and
>> not care who holds refere
Marko Rauhamaa wrote:
> Grant Edwards :
>
>> the polite thing to do is to delete references to it when you're done
>> with it.
>
> I disagree with that recommendation. You should do the natural thing and
> not care who holds references to who.
I don't understand this. What is "the natural thing
Grant Edwards :
> the polite thing to do is to delete references to it when you're done
> with it.
I disagree with that recommendation. You should do the natural thing and
not care who holds references to who.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
y code. The problem is that when I store
>>> these callbacks, it naturally creates a strong reference to the objects,
>>> which means that if they are deleted without unregistering themselves
>>> first, my code will keep the callbacks alive. Since this could lead to
Cem Karan wrote:
>
> On Feb 21, 2015, at 8:15 AM, Chris Angelico wrote:
>
>> On Sun, Feb 22, 2015 at 12:13 AM, Cem Karan wrote:
>>> OK, so it would violate the principle of least surprise for you.
>>> Interesting. Is this a general pattern in python? Th
ck
anymore after an intervening event.
The problem then, of course, is in the logic and not in the callbacks.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Frank Millman wrote:
> I tried something similar a while ago, and I did find a gotcha.
>
> The problem lies in this phrase - "if they are no longer alive, they are
> automatically removed from the WeakSet, preventing me from accidentally
> calling them when they are dead."
>
> I found that the r
Chris Angelico :
> On Sat, Feb 21, 2015 at 1:44 PM, Cem Karan wrote:
>> In order to inform users that certain bits of state have changed, I
>> require them to register a callback with my code. The problem is that
>> when I store these callbacks, it naturally creates a stron
e other complications, but it's not uncommon for me to build
a GUI program that leaves everything owned by the GUI engine.
Everything is done through callbacks. Destroy a window, clean up its
callbacks. The main window will have an "on-deletion" callback that
terminates the progra
On Feb 21, 2015, at 9:36 AM, Chris Angelico wrote:
> On Sun, Feb 22, 2015 at 1:07 AM, Cem Karan wrote:
>> I agree about closures; its the only way they could work. When I was
>> originally thinking about the library, I was trying to include all types of
>> callbacks, i
On Sun, Feb 22, 2015 at 1:07 AM, Cem Karan wrote:
> I agree about closures; its the only way they could work. When I was
> originally thinking about the library, I was trying to include all types of
> callbacks, including closures and callable objects. The callable objects ma
you, I expect it to be called; I expect, in fact, that
> that *will* keep my object alive.
For that matter, if the callback is a method, you need to hang onto
it, because method wrappers are generated on demand, so the method
would be removed from the valid callbacks instantly.
Weak referenc
On Feb 21, 2015, at 8:37 AM, Mark Lawrence wrote:
> On 21/02/2015 05:41, Frank Millman wrote:
>>
>> "Cem Karan" wrote in message
>> news:33677ae8-b2fa-49f9-9304-c8d937842...@gmail.com...
>>> Hi all, I'm working on a project that will involve the
On Feb 21, 2015, at 8:15 AM, Chris Angelico wrote:
> On Sun, Feb 22, 2015 at 12:13 AM, Cem Karan wrote:
>> OK, so it would violate the principle of least surprise for you.
>> Interesting. Is this a general pattern in python? That is, callbacks are
>> owned by what the
On 21/02/2015 05:41, Frank Millman wrote:
"Cem Karan" wrote in message
news:33677ae8-b2fa-49f9-9304-c8d937842...@gmail.com...
Hi all, I'm working on a project that will involve the use of callbacks,
and I want to bounce an idea I had off of everyone to make sure I'm not
d
On Feb 21, 2015, at 12:41 AM, Frank Millman wrote:
>
> "Cem Karan" wrote in message
> news:33677ae8-b2fa-49f9-9304-c8d937842...@gmail.com...
>> Hi all, I'm working on a project that will involve the use of callbacks,
>> and I want to bounce an idea I had
On Sun, Feb 22, 2015 at 12:13 AM, Cem Karan wrote:
> OK, so it would violate the principle of least surprise for you.
> Interesting. Is this a general pattern in python? That is, callbacks are
> owned by what they are registered with?
>
> In the end, I want to make a library
1 - 100 of 206 matches
Mail list logo
