If for ... else was spelt more intelligibly, e.g. for ... nobreak, there
would be no temptation to use anything like `elif'. `nobreakif' wouldn't
be a keyword.
Rob Cliffe
On 30/11/2021 06:24, Chris Angelico wrote:
for ns in namespaces:
if name in ns:
print("Found!")
brea
for ns in namespaces:
if name in ns:
print("Found!")
break
elif name.isupper():
print("All-caps name that wasn't found")
This actually doesn't work. I have been programming in Python for well
over a decade, and never before been in a situation where this would
be useful.
A
Note: Previous comments have been made on this, this is my reply to another
response of this question.
I would have it so, the "admin" of the program would be able to change if
devices are allowed on that network, and would also be able to remove and
make certain devices always receive a password t
On Mon, Mar 22, 2021 at 6:03 AM Quentin Bock wrote:
>
> I had a recent thought about someone's wifi/network connection and password.
> Could it be possible to create a program that will randomize a new password
> every 24 hours (letters and numbers) and when the prog
I had a recent thought about someone's wifi/network connection and password.
Could it be possible to create a program that will randomize a new password
every 24 hours (letters and numbers) and when the program is opened (or
notification would be sent) you can see the new password to log int
On 10/31/2018 11:08 AM, Rob Gaddi wrote:
> The decision is also almost certainly not worth the amount of
> thought you're giving it.
When learning something new, hopefully all aspects are given a lot of
thought. After learning how all the pieces fit together then most
decisions
On 08.02.2016 23:13, Marko Rauhamaa wrote:
As I stated in an earlier post, a normal subroutine may turn out to be
blocking. To make it well-behaved under asyncio, you then dutifully tag
the subroutine with "async" and adorn the blocking statement with
"await". Consequently, you put "await" in fro
As I stated in an earlier post, a normal subroutine may turn out to be
blocking. To make it well-behaved under asyncio, you then dutifully tag
the subroutine with "async" and adorn the blocking statement with
"await". Consequently, you put "await" in front of all calls to the
subroutine and cascad
Hi all, I apologize for taking so long to reply, but neither my work schedule
nor the weather have been kind in the past week. That said, I've been thinking
long and hard about what everyone has said, and have decided that it would be
useful to write a wrap-up email that attempts to encapsulate
On Mon, Mar 2, 2015 at 4:04 AM, Cem Karan wrote:
> On Feb 26, 2015, at 2:54 PM, Ian Kelly wrote:
>> On Feb 26, 2015 4:00 AM, "Cem Karan" wrote:
>> >
>> >
>> > On Feb 26, 2015, at 12:36 AM, Gregory Ewing
>> > wrote:
>> >
>> > > Cem Karan wrote:
>> > >> I think I see what you're talking about no
On Feb 26, 2015, at 2:54 PM, Ian Kelly wrote:
> On Feb 26, 2015 4:00 AM, "Cem Karan" wrote:
> >
> >
> > 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/librar
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
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.pyvmmonito
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.
On Feb 26, 2015 4:00 AM, "Cem Karan" wrote:
>
>
> 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?
> >
> >
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
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.
I'm combining two messages into one,
On Feb 24, 2015, at 12:29 AM, random...@fastmail.us wrote:
> On Tue, Feb 24, 2015, at 00:20, Gregory Ewing wrote:
>> 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 ob
On Feb 23, 2015, at 7:29 AM, "Frank Millman" wrote:
>
> "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 t
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 meth
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 = []
>>
>> def register(func):
>>if func not in 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
On Feb 22, 2015, at 5:29 PM, Laura Creighton wrote:
> 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 bee
method, and I'd prefer not to make that
assumption.
Also, I just noticed that Python 3.4 adds a weakref.WeakMethod class
that solves the problem for the bound method case. That still leaves
the closure and lambda cases, but here's a thought: add an optional
argument to the callback regis
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 callbacks because the
On Feb 22, 2015, at 4:34 PM, Marko Rauhamaa wrote:
> 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
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
On Feb 22, 2015, at 4:02 PM, Ethan Furman wrote:
> 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
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
On Feb 22, 2015, at 7:46 AM, Marko Rauhamaa wrote:
> 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 an
On Feb 22, 2015, at 7:52 AM, Laura Creighton wrote:
> In a message of Sun, 22 Feb 2015 07:16:14 -0500, Cem Karan writes:
>
>> 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, rel
Steven D'Aprano :
> I don't know about Java's Hotspot, but I do know that CPython's ref counting
> garbage collector has at least one advantage over the GC used by Jython and
> IronPython: unlike them, open files are closed as soon as they are no
> longer in use.
You can't depend on that kind of
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 itself *be* a
>> reference (and not a wea
for educational purposes, we should try to code in the
simplest and most elegant way with no thought given to annoying practical
matters. At least at first. But when writing programs for actual use, we
should write for the implication we have, not the one we wish we had.
>> They force the use of
Cem Karan :
> You were saying that you move your objects into a zombie state. I
> assumed that you meant you marked them in some manner (e.g., setting
> 'is_zombie' to True),
Yes, but even better:
self.set_state(ZOMBIE)
> so that anything that has a strong reference to the object knows th
On Feb 22, 2015, at 7:24 AM, Chris Angelico wrote:
> On Sun, Feb 22, 2015 at 11:07 PM, Cem Karan wrote:
>>> Correct. The GUI engine ultimately owns everything. Of course, this is
>>> a very simple case (imagine a little notification popup; you don't
>>> care about it, you don't need to know whe
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 callback from some other function?
>
>
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 move my objects to a zombie state after they're done so
>
On Feb 21, 2015, at 3:57 PM, Grant Edwards wrote:
> On 2015-02-21, Cem Karan wrote:
>>
>> On Feb 21, 2015, at 12:42 AM, Chris Angelico wrote:
>>
>>> 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
On Feb 21, 2015, at 12:27 PM, Steven D'Aprano
wrote:
> 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 g
In a message of Sun, 22 Feb 2015 07:16:14 -0500, Cem Karan writes:
>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 when they aren't needed
>without having to figure out
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.
>
> This was PRECISELY the situation I
On Sun, Feb 22, 2015 at 11:07 PM, Cem Karan wrote:
>> Correct. The GUI engine ultimately owns everything. Of course, this is
>> a very simple case (imagine a little notification popup; you don't
>> care about it, you don't need to know when it's been closed, the only
>> event on it is "hit Close t
On Feb 21, 2015, at 12:08 PM, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> Other than that, I cannot see how calling a function which has *not*
>> yet been garbage collected can fail, just because the only reference
>> still existing is a weak reference.
>
> Maybe the logic of the receiving
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 absorb any potential loose callbacks that are linger
On Feb 21, 2015, at 11:03 AM, Marko Rauhamaa wrote:
> 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 th
On Feb 21, 2015, at 10:55 AM, Chris Angelico wrote:
> On Sun, Feb 22, 2015 at 2:45 AM, Cem Karan wrote:
>> OK, so if I'm reading your code correctly, you're breaking the cycle in your
>> object graph by making the GUI the owner of the callback, correct? No other
>> chunk of code has a refere
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's the other way aroun
Chris Angelico wrote:
> On Sun, Feb 22, 2015 at 3:38 PM, Steven D'Aprano
> wrote:
>> But you are using it. You might not be using it by name, but you are
>> using it via the callback function. What did you expect, that Python
>> should read your mind and somehow intuit that you still care about t
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 be worried about, let alone removed.
Why?
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
On Sun, Feb 22, 2015 at 6:52 PM, Marko Rauhamaa wrote:
> What I mean, though, is that you shouldn't think you need to create
> object destructors where you routinely set all members to None.
Sure, not *routinely*. It'd be a special case where it's not
specifically a destructor, and its job is to
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.
On Sat, Feb 21, 2015 at 1:57 PM, Grant Edwards wrote:
> On 2015-02-21, Cem Karan wrote:
>>
>> On Feb 21, 2015, at 12:42 AM, Chris Angelico wrote:
>>
>>> 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
only reference still
> existing is a weak reference.
>
You are right. I tried to reproduce the problem and I can't.
Before describing what I think was happening, I want to clarify something.
Most of this thread uses the word 'callback' in the sense of an
'asynchronous'
On Sun, Feb 22, 2015 at 3:38 PM, Steven D'Aprano
wrote:
> But you are using it. You might not be using it by name, but you are using
> it via the callback function. What did you expect, that Python should read
> your mind and somehow intuit that you still care about this socket
> listener, but not
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
On 2015-02-21, Cem Karan wrote:
>
> On Feb 21, 2015, at 12:42 AM, Chris Angelico wrote:
>
>> 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
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? That is, callbacks
>>> are owned by what
Steven D'Aprano :
> Other than that, I cannot see how calling a function which has *not*
> yet been garbage collected can fail, just because the only reference
> still existing is a weak reference.
Maybe the logic of the receiving object isn't prepared for the callback
anymore after an intervenin
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 strong reference
>> to the
On Sun, Feb 22, 2015 at 2:45 AM, Cem Karan wrote:
> OK, so if I'm reading your code correctly, you're breaking the cycle in your
> object graph by making the GUI the owner of the callback, correct? No other
> chunk of code has a reference to the callback, correct?
Correct. The GUI engine ultim
> def make_callback(i):
>def inner():
>print("Callback! %d"%i)
>register_callback(inner)
>return inner
>
> make_callback(5)
> remove_me = make_callback(6)
> make_callback(7)
> unregister_callback(remove_me)
> do_callbacks()
Yeah, that's pretty
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 may
> pass themselv
On Fri, Feb 20, 2015 at 9:42 PM, Chris Angelico wrote:
> No, it's not. I would advise using strong references - if the callback
> is a closure, for instance, you need to hang onto it, because there
> are unlikely to be any other references to it. If I register a
> callback with you, I expect it to
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 use of callbacks,
>>> and I want to bounce an id
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 they are registered with?
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
developing a bad idea.
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 off of everyone to make sure I'm not
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 that offers as fe
On Feb 21, 2015, at 12:42 AM, Chris Angelico wrote:
> 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 naturall
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 strong reference to the objects,
> which means
"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
> developing a bad idea. Note that this is for python 3.4 co
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 developing a
bad idea. Note that this is for python 3.4 code; I don't need to worry about
any version of python earlier than that.
In order to inform
ess, the following surprised me. A program creates a
>> dictionary with a known set of keys. I would have thought that multiple
>> runs of the program would return the keys in the same sequence. As you
>> can see, the results appear to be totally random.
>>
>> Just ou
reates a dictionary
>> with a known set of keys. I would have thought that multiple runs of the
>> program would return the keys in the same sequence. As you can see, the
>> results appear to be totally random.
>>
>> Just out of interest, I would appreciate an explanati
set of keys. I would have thought that multiple runs of the
program would return the keys in the same sequence. As you can see, the
results appear to be totally random.
Just out of interest, I would appreciate an explanation.
Mainly, it's just something you utterly cannot depend on, so it'
On Mon, Mar 18, 2013 at 6:26 PM, Frank Millman wrote:
> Hi all
>
> I know that you cannot rely on the order of keys in a dictionary, and I am
> not attempting to do so.
>
> Nevertheless, the following surprised me. A program creates a dictionary
> with a known set of keys.
Hi all
I know that you cannot rely on the order of keys in a dictionary, and I
am not attempting to do so.
Nevertheless, the following surprised me. A program creates a dictionary
with a known set of keys. I would have thought that multiple runs of the
program would return the keys in the
On Sunday, January 13, 2013 8:16:29 PM UTC-8, Steven D'Aprano wrote:
> A programmer had a problem, and thought Now he has "I know, I'll solve
> two it with threads!" problems.
Very nice! :^)
This problem isn't exclusive to Python, however. Other multi-threaded
a
On 15/01/13 16:48, Antoine Pitrou wrote:
Steven D'Aprano pearwood.info> writes:
A programmer had a problem, and thought Now he has "I know, I'll solve
two it with threads!" problems.
Host: Last week the Royal Festival Hall saw the first performance of a new
logfil
On Wed, Jan 16, 2013 at 3:48 AM, Antoine Pitrou wrote:
> D'Aprano: No, no. Look. This thread business -- it doesn't really matter.
> The threads aren't important. A few friends call me Two Threads and that's
> all there is to it. I wish you'd ask me about the logfile. Everybody talks
> about the t
On 15/01/2013 16:48, Antoine Pitrou wrote:
> Steven D'Aprano pearwood.info> writes:
>>
>> A programmer had a problem, and thought Now he has "I know, I'll solve
>> two it with threads!" problems.
>
>
> Host: Last week the Royal Festival Hal
Steven D'Aprano pearwood.info> writes:
>
> A programmer had a problem, and thought Now he has "I know, I'll solve
> two it with threads!" problems.
Host: Last week the Royal Festival Hall saw the first performance of a new
logfile by one of the world's le
On 01/14/2013 09:18 AM, Chris Angelico wrote:
> On Tue, Jan 15, 2013 at 1:15 AM, Tim Chase
> wrote:
>> A newbie programmer had a problem and thought
>>
>>
>>
>> "I'll solve it by posting on
>>
>>
>>
>> python-list@python.org
On 01/14/2013 11:09 AM, John Gordon wrote:
> In Michael Torrie
> writes:
>
>> On 01/13/2013 09:16 PM, Steven D'Aprano wrote:
>>> A programmer had a problem, and thought Now he has "I know, I'll solve
>>> two it with threads!" problems.
&g
1 - 100 of 187 matches
Mail list logo
