comp.lang.python - 26 new messages in 13 topics - digest

comp.lang.python
http://groups.google.com/group/comp.lang.python?hl=en

comp.lang.python@googlegroups.com

Today's topics:

* Chanelling Guido - dict subclasses - 7 messages, 7 authors
http://groups.google.com/group/comp.lang.python/t/bc0cb52e5b848e8e?hl=en
* dictionary with tuples - 1 messages, 1 author
http://groups.google.com/group/comp.lang.python/t/e621c5b76468f362?hl=en
* Python 3.x adoption - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.python/t/3d5defc6634ef3b4?hl=en
* extracting string.Template substitution placeholders - 1 messages, 1 author
http://groups.google.com/group/comp.lang.python/t/e98ada5213c4b344?hl=en
* python-list@python.org - 1 messages, 1 author
http://groups.google.com/group/comp.lang.python/t/dbc472f3db4baab9?hl=en
* Fwd: What's correct Python syntax? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.python/t/02a96ec3e80cc46a?hl=en
* Trying to wrap my head around futures and coroutines - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.python/t/9d51a767380b9642?hl=en
* Learning python networking - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.python/t/3af0846b15a26766?hl=en
* 'Straße' ('Strasse') and Python 2 - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.python/t/93ddbbff468ab95d?hl=en
* proposal: bring nonlocal to py2.x - 1 messages, 1 author
http://groups.google.com/group/comp.lang.python/t/643e84b50e561338?hl=en
* Python 3 __bytes__ method - 1 messages, 1 author
http://groups.google.com/group/comp.lang.python/t/03c277858d35f158?hl=en
* Question about object lifetime and access - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.python/t/127e2f43e2934562?hl=en
* ANN: Python Meeting Düsseldorf - 21.01.2014 - 1 messages, 1 author
http://groups.google.com/group/comp.lang.python/t/ce3d5c7c3eaef5e3?hl=en

==============================================================================
TOPIC: Chanelling Guido - dict subclasses
http://groups.google.com/group/comp.lang.python/t/bc0cb52e5b848e8e?hl=en
==============================================================================

== 1 of 7 ==
Date: Tues, Jan 14 2014 5:27 pm
From: Steven D'Aprano


Over on the Python-Dev mailing list, there is an ENORMOUS multi-thread
discussion involving at least two PEPs, about bytes/str compatibility.
But I don't want to talk about that. (Oh gods, I *really* don't want to
talk about that...)

In the midst of that discussion, Guido van Rossum made a comment about
subclassing dicts:

[quote]
From: Guido van Rossum <guido@python.org>
Date: Tue, 14 Jan 2014 12:06:32 -0800
Subject: Re: [Python-Dev] PEP 460 reboot

Personally I wouldn't add any words suggesting or referring
to the option of creation another class for this purpose. You
wouldn't recommend subclassing dict for constraining the
types of keys or values, would you?
[end quote]

https://mail.python.org/pipermail/python-dev/2014-January/131537.html

This surprises me, and rather than bother Python-Dev (where it will
likely be lost in the noise, and certain will be off-topic), I'm hoping
there may be someone here who is willing to attempt to channel GvR. I
would have thought that subclassing dict for the purpose of constraining
the type of keys or values would be precisely an excellent use of
subclassing.


class TextOnlyDict(dict):
def __setitem__(self, key, value):
if not isinstance(key, str):
raise TypeError
super().__setitem__(key, value)
# need to override more methods too


But reading Guido, I think he's saying that wouldn't be a good idea. I
don't get it -- it's not a violation of the Liskov Substitution
Principle, because it's more restrictive, not less. What am I missing?


--
Steven




== 2 of 7 ==
Date: Tues, Jan 14 2014 6:04 pm
From: Ned Batchelder


On 1/14/14 8:27 PM, Steven D'Aprano wrote:
> Over on the Python-Dev mailing list, there is an ENORMOUS multi-thread
> discussion involving at least two PEPs, about bytes/str compatibility.
> But I don't want to talk about that. (Oh gods, I *really* don't want to
> talk about that...)
>
> In the midst of that discussion, Guido van Rossum made a comment about
> subclassing dicts:
>
> [quote]
> From: Guido van Rossum <guido@python.org>
> Date: Tue, 14 Jan 2014 12:06:32 -0800
> Subject: Re: [Python-Dev] PEP 460 reboot
>
> Personally I wouldn't add any words suggesting or referring
> to the option of creation another class for this purpose. You
> wouldn't recommend subclassing dict for constraining the
> types of keys or values, would you?
> [end quote]
>
> https://mail.python.org/pipermail/python-dev/2014-January/131537.html
>
> This surprises me, and rather than bother Python-Dev (where it will
> likely be lost in the noise, and certain will be off-topic), I'm hoping
> there may be someone here who is willing to attempt to channel GvR. I
> would have thought that subclassing dict for the purpose of constraining
> the type of keys or values would be precisely an excellent use of
> subclassing.
>
>
> class TextOnlyDict(dict):
> def __setitem__(self, key, value):
> if not isinstance(key, str):
> raise TypeError
> super().__setitem__(key, value)
> # need to override more methods too
>
>
> But reading Guido, I think he's saying that wouldn't be a good idea. I
> don't get it -- it's not a violation of the Liskov Substitution
> Principle, because it's more restrictive, not less. What am I missing?
>
>

One problem with it is that there are lots of ways of setting values in
the dict, and they don't use your __setitem__:

>>> tod = TextOnlyDict()
>>> tod.update({1: "haha"})
>>>

This is what you're getting at with your "need to override more methods
too", but it turns out to be a pain to override enough methods.

I don't know if that is what Guido was getting at, I suspect he was
talking at a more refined "principles of object design" level rather
than "dicts don't happen to work that way" level.

Also, I've never done it, but I understand that deriving from
collections.MutableMapping avoids this problem.

--
Ned Batchelder, http://nedbatchelder.com





== 3 of 7 ==
Date: Tues, Jan 14 2014 7:48 pm
From: Terry Reedy


On 1/14/2014 8:27 PM, Steven D'Aprano wrote:

> In the midst of that discussion, Guido van Rossum made a comment about
> subclassing dicts:
>
> [quote]
> From: Guido van Rossum <guido@python.org>
> Date: Tue, 14 Jan 2014 12:06:32 -0800
> Subject: Re: [Python-Dev] PEP 460 reboot
>
> Personally I wouldn't add any words suggesting or referring
> to the option of creation another class for this purpose. You
> wouldn't recommend subclassing dict for constraining the
> types of keys or values, would you?
> [end quote]
>
> https://mail.python.org/pipermail/python-dev/2014-January/131537.html
>
> This surprises me,

I was slightly surprised too. I understand not wanting to add a subclass
to stdlib, but I believe this was about adding words to the doc. Perhaps
he did not want to over-emphasize one particular possible subclass by
putting the words in the doc.

--
Terry Jan Reedy





== 4 of 7 ==
Date: Tues, Jan 14 2014 11:00 pm
From: F


I can't speak for Guido but I think it is messy and unnatural and will lead to user frustration.
As a user, I would expect a dict to take any hashable as key and any object as value when using one. I would probably just provide a __getitem__ method in a normal class in your case.

This said I have overriden dict before, but my child class only added to dict, I didn't change it's underlying behaviour so you can use my class(es) as a vanilla dict everywhere, which enforcing types would have destroyed.



On 01:27 15/01 , Steven D'Aprano wrote:
>Over on the Python-Dev mailing list, there is an ENORMOUS multi-thread
>discussion involving at least two PEPs, about bytes/str compatibility.
>But I don't want to talk about that. (Oh gods, I *really* don't want to
>talk about that...)
>
>In the midst of that discussion, Guido van Rossum made a comment about
>subclassing dicts:
>
> [quote]
> From: Guido van Rossum <guido@python.org>
> Date: Tue, 14 Jan 2014 12:06:32 -0800
> Subject: Re: [Python-Dev] PEP 460 reboot
>
> Personally I wouldn't add any words suggesting or referring
> to the option of creation another class for this purpose. You
> wouldn't recommend subclassing dict for constraining the
> types of keys or values, would you?
> [end quote]
>
>https://mail.python.org/pipermail/python-dev/2014-January/131537.html
>
>This surprises me, and rather than bother Python-Dev (where it will
>likely be lost in the noise, and certain will be off-topic), I'm hoping
>there may be someone here who is willing to attempt to channel GvR. I
>would have thought that subclassing dict for the purpose of constraining
>the type of keys or values would be precisely an excellent use of
>subclassing.
>
>
>class TextOnlyDict(dict):
> def __setitem__(self, key, value):
> if not isinstance(key, str):
> raise TypeError
> super().__setitem__(key, value)
> # need to override more methods too
>
>
>But reading Guido, I think he's saying that wouldn't be a good idea. I
>don't get it -- it's not a violation of the Liskov Substitution
>Principle, because it's more restrictive, not less. What am I missing?
>
>
>--
>Steven
>

--
yrNews Usenet Reader for iOS
http://appstore.com/yrNewsUsenetReader





== 5 of 7 ==
Date: Wed, Jan 15 2014 12:40 am
From: Peter Otten <__peter__@web.de>


Steven D'Aprano wrote:

> In the midst of that discussion, Guido van Rossum made a comment about
> subclassing dicts:
>
> [quote]

> Personally I wouldn't add any words suggesting or referring
> to the option of creation another class for this purpose. You
> wouldn't recommend subclassing dict for constraining the
> types of keys or values, would you?
> [end quote]

> This surprises me, and rather than bother Python-Dev (where it will
> likely be lost in the noise, and certain will be off-topic), I'm hoping
> there may be someone here who is willing to attempt to channel GvR. I
> would have thought that subclassing dict for the purpose of constraining
> the type of keys or values would be precisely an excellent use of
> subclassing.
>
>
> class TextOnlyDict(dict):
> def __setitem__(self, key, value):
> if not isinstance(key, str):
> raise TypeError

Personally I feel dirty whenever I write Python code that defeats duck-
typing -- so I would not /recommend/ any isinstance() check.
I realize that this is not an argument...

PS: I tried to read GvR's remark in context, but failed. It's about time to
to revolt and temporarily install the FLUFL as our leader, long enough to
revoke Guido's top-posting license, but not long enough to reintroduce the
<> operator...





== 6 of 7 ==
Date: Wed, Jan 15 2014 1:10 am
From: Mark Lawrence



On 15/01/2014 01:27, Steven D'Aprano wrote:
> Over on the Python-Dev mailing list, there is an ENORMOUS multi-thread
> discussion involving at least two PEPs, about bytes/str compatibility.
> But I don't want to talk about that. (Oh gods, I *really* don't want to
> talk about that...)

+ trillions

>
> In the midst of that discussion, Guido van Rossum made a comment about
> subclassing dicts:
>
> [quote]
> From: Guido van Rossum <guido@python.org>
> Date: Tue, 14 Jan 2014 12:06:32 -0800
> Subject: Re: [Python-Dev] PEP 460 reboot
>
> Personally I wouldn't add any words suggesting or referring
> to the option of creation another class for this purpose. You
> wouldn't recommend subclassing dict for constraining the
> types of keys or values, would you?
> [end quote]
>
> https://mail.python.org/pipermail/python-dev/2014-January/131537.html
>
> This surprises me, and rather than bother Python-Dev (where it will
> likely be lost in the noise, and certain will be off-topic), I'm hoping
> there may be someone here who is willing to attempt to channel GvR. I
> would have thought that subclassing dict for the purpose of constraining
> the type of keys or values would be precisely an excellent use of
> subclassing.

Exactly what I was thinking.

>
>
> class TextOnlyDict(dict):
> def __setitem__(self, key, value):
> if not isinstance(key, str):
> raise TypeError
> super().__setitem__(key, value)
> # need to override more methods too
>
>
> But reading Guido, I think he's saying that wouldn't be a good idea. I
> don't get it -- it's not a violation of the Liskov Substitution
> Principle, because it's more restrictive, not less. What am I missing?
>
>

Couple of replies I noted from Ned Batchelder and Terry Reedy. Smacked
bottom for Peter Otten, how dare he? :)

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence





== 7 of 7 ==
Date: Wed, Jan 15 2014 3:03 am
From: Tim Chase


On 2014-01-15 01:27, Steven D'Aprano wrote:
> class TextOnlyDict(dict):
> def __setitem__(self, key, value):
> if not isinstance(key, str):
> raise TypeError
> super().__setitem__(key, value)
> # need to override more methods too
>
>
> But reading Guido, I think he's saying that wouldn't be a good
> idea. I don't get it -- it's not a violation of the Liskov
> Substitution Principle, because it's more restrictive, not less.
> What am I missing?

Just as an observation, this seems almost exactly what anydbm does,
behaving like a dict (whether it inherits from dict, or just
duck-types like a dict), but with the limitation that keys/values need
to be strings.

-tkc







==============================================================================
TOPIC: dictionary with tuples
http://groups.google.com/group/comp.lang.python/t/e621c5b76468f362?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 14 2014 6:24 pm
From: YBM


Le 14/01/2014 23:00, Tobiah a �crit :
> On 01/14/2014 01:21 PM, YBM wrote:
>> Le 14/01/2014 22:10, Igor Korot a �crit :
>>> Hi, ALL,
>>> C:\Documents and Settings\Igor.FORDANWORK\Desktop\winpdb>python
>>> Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit
>>> (Intel)] on win32
>>> Type "help", "copyright", "credits" or "license" for more information.
>>>>>> dict = {}
>>>>>> dict[(1,2)] = ('a','b')
>>>>>> dict[(3,4)] = ('c','d')
>>>>>> for (key1,key2),(value1,value2) in dict:
>>> ... print key1, " ", key2
>>> ... print value1, " ", value2
>>> ...
>>> Traceback (most recent call last):
>>> File "<stdin>", line 1, in <module>
>>> TypeError: 'int' object is not iterable
>>>>>>
>>>
>>> What am I doing wrong?
>>
>> for ... in dict:
>>
>> is a way to iterate through dictionnary items,
>>
>> what you want to do can be done so:
>>
>> for (key1,key2),(value1,value2) in dict.items():
>>
>>
>>
>
> But it's (key1, value1), (key2, value2)

No. Try it.

key1 key2 are the members of every tuple key.
value1, value2 are the members of every tuple value.

>>> d={ (1,2):('a','b'), (3,4):('c','d') }
>>> for (key1,key2),(value1,value2) in d.items():
... print key1,key2,value1,value2
...
1 2 a b
3 4 c d








==============================================================================
TOPIC: Python 3.x adoption
http://groups.google.com/group/comp.lang.python/t/3d5defc6634ef3b4?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Jan 14 2014 6:55 pm
From: Steven D'Aprano


On Tue, 14 Jan 2014 20:33:50 +0100, Staszek wrote:

> Hi
>
> What's the problem with Python 3.x?

Nothing.

> It was first released in 2008,

That was only five years ago.

I know that to young kids today who change their iPhone every six months,
five years sounds like a lot, but in the world of mature software, five
years is a blink of the eye. People still use Fortran code that is 30
years old. I know of at least one person supporting a Python 1.5 system,
which is about 15 years old. RedHat is still providing commercial support
for Python 2.3, and their Python 2.7 commercial support won't end until
2023 or 2024.


> but web hosting companies still seem to offer Python 2.x rather.
>
> For example, Google App Engine only offers Python 2.7.
>
> What's wrong?...

Hosting companies are conservative. Just look at how many still offer old
versions of PHP. These guys offer PHP 5.2 to 5.5:

http://www.a2hosting.com/php-hosting

WordPress will run on PHP 4.1!

So it is no surprise that Python hosting companies still mostly provide
2.7.



--
Steven




== 2 of 2 ==
Date: Tues, Jan 14 2014 7:30 pm
From: MRAB


On 2014-01-15 02:55, Steven D'Aprano wrote:
> On Tue, 14 Jan 2014 20:33:50 +0100, Staszek wrote:
>
>> Hi
>>
>> What's the problem with Python 3.x?
>
> Nothing.
>
>> It was first released in 2008,
>
> That was only five years ago.
>
> I know that to young kids today who change their iPhone every six months,
> five years sounds like a lot, but in the world of mature software, five
> years is a blink of the eye. People still use Fortran code that is 30
> years old. I know of at least one person supporting a Python 1.5 system,
> which is about 15 years old. RedHat is still providing commercial support
> for Python 2.3, and their Python 2.7 commercial support won't end until
> 2023 or 2024.
>
>
>> but web hosting companies still seem to offer Python 2.x rather.
>>
>> For example, Google App Engine only offers Python 2.7.
>>
>> What's wrong?...
>
> Hosting companies are conservative. Just look at how many still offer old
> versions of PHP. These guys offer PHP 5.2 to 5.5:
>
> http://www.a2hosting.com/php-hosting
>
> WordPress will run on PHP 4.1!
>
> So it is no surprise that Python hosting companies still mostly provide
> 2.7.
>
Not to mention Windows XP, which is only now being dropped by Microsoft.






==============================================================================
TOPIC: extracting string.Template substitution placeholders
http://groups.google.com/group/comp.lang.python/t/e98ada5213c4b344?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 14 2014 7:07 pm
From: "Eric S. Johansson"



On 1/13/2014 2:24 AM, Steven D'Aprano wrote:
> On Sun, 12 Jan 2014 10:08:31 -0500, Eric S. Johansson wrote:
>
>
> Now just walk the template for $ signs. Watch out for $$ which escapes
> the dollar sign. Here's a baby parser:
found a different way

import string
cmplxstr="""a simple $string a longer $string a $last line"""
nst=string.Template(cmplxstr)

identifiers = {}

while True:
try:
result = nst.substitute(identifiers)
except KeyError, error:
print error
identifiers[error[0]] = "x"
else:
break
print "loop done"

------
at the end I only care about the keys in identifier which I fill in
after user interaction.






==============================================================================
TOPIC: python-list@python.org
http://groups.google.com/group/comp.lang.python/t/dbc472f3db4baab9?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 14 2014 7:49 pm
From: MRAB


On 2014-01-15 01:25, Florian Lindner wrote:
> Am Dienstag, 14. Januar 2014, 17:00:48 schrieb MRAB:
>> On 2014-01-14 16:37, Florian Lindner wrote:
>> > Hello!
>> >
>> > I'm using python 3.2.3 on debian wheezy. My script is called from my mail delivery agent (MDA) maildrop (like procmail) through it's xfilter directive.
>> >
>> > Script works fine when used interactively, e.g. ./script.py < testmail but when called from maildrop it's producing an infamous UnicodeDecodeError:
>> >
>> > File "/home/flindner/flofify.py", line 171, in main
>> > mail = sys.stdin.read()
>> > File "/usr/lib/python3.2/encodings/ascii.py", line 26, in decode
>> > return codecs.ascii_decode(input, self.errors)[0]
>> >
>> > Exception for example is always like
>> >
>> > UnicodeDecodeError: 'ascii' codec can't decode byte 0x82 in position 869: ordinal not in range(128)
>> > UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 1176: ordinal not in range(128)
>> > UnicodeDecodeError: 'ascii' codec can't decode byte 0x8c in position 846: ordinal not in range(128)
>> >
>> > I read mail from stdin "mail = sys.stdin.read()"
>> >
>> > Environment when called is:
>> >
>> > locale.getpreferredencoding(): ANSI_X3.4-1968
>> > environ["LANG"]: C
>> >
>> > System environment when using shell is:
>> >
>> > ~ % echo $LANG
>> > en_US.UTF-8
>> >
>> > As far as I know when reading from stdin I don't need an decode(...) call, since stdin has a decoding. I also tried some decoding/encoding stuff but changed nothing.
>> >
>> > Any ideas to help me?
>> >
>> When run from maildrop it thinks that the encoding of stdin is ASCII.
>
> Well, true. But what encoding does maildrop actually gives me? It obviously does not inherit LANG or is called from the MTA that way. I also tried:
>
locale.getpreferredencoding() said "ANSI_X3.4-1968", which is ASCII
(ask Wikipedia if you want to know why it's called that!).

> inData = codecs.getreader('utf-8')(sys.stdin)
> mail = inData.read()
>
> Failed also. But I'm not exactly an encoding expert.
>
Try:

sys.stdin = codecs.getreader('utf-8')(sys.stdin.detach())






==============================================================================
TOPIC: Fwd: What's correct Python syntax?
http://groups.google.com/group/comp.lang.python/t/02a96ec3e80cc46a?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 14 2014 10:00 pm
From: Larry Hudson


On 01/14/2014 02:03 AM, Igor Korot wrote:
[snip]

> C:\Documents and Settings\Igor.FORDANWORK\Desktop\winpdb>python
> Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit
> (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
>>>> test = "I,like,my,chocolate"
>>>> print test.split(',')[2,3]
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> TypeError: list indices must be integers, not tuple
>

Try again... but use a colon not a comma, [2:3]

Two additional comments:
(1) test.split(',')[2:3] will give you ["my"] only. The slicing syntax starts with the first
index and goes up to but NOT INCLUDING the second. In this case it is the same as the single
index, [2]. You want either [2:4] or [2:], or even [2:500]. Any value >= the length of the
list (or whatever sequence) is acceptable as the ending index in a slice. It's probably not a
good idea to use a value like this, but it does work. And obviously, don't try to read with an
out-of-bounds index, but it does work as the _ending_ index in a slice.

(2) A comma-separated list of data items IS a tuple, even without the usual enclosing
parenthesis. That is your error here -- [2,3] is the same as [(2,3)], which is a tuple.

-=- Larry -=-






==============================================================================
TOPIC: Trying to wrap my head around futures and coroutines
http://groups.google.com/group/comp.lang.python/t/9d51a767380b9642?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Jan 15 2014 2:18 am
From: Phil Connell


On Mon, Jan 06, 2014 at 06:56:00PM -0600, Skip Montanaro wrote:
> So, I'm looking for a little guidance. It seems to me that futures,
> coroutines, and/or the new Tulip/asyncio package might be my salvation, but
> I'm having a bit of trouble seeing exactly how that would work. Let me
> outline a simple hypothetical calculation. I'm looking for ways in which
> these new facilities might improve the structure of my code.

This instinct is exactly right -- the point of coroutines and tulip futures is
to liberate you from having to daisy chain callbacks together.


>
> Let's say I have a dead simple GUI with two buttons labeled, "Do A" and "Do
> B". Each corresponds to executing a particular activity, A or B, which take
> some non-zero amount of time to complete (as perceived by the user) or
> cancel (as perceived by the state of the running system - not safe to run A
> until B is complete/canceled, and vice versa). The user, being the fickle
> sort that he is, might change his mind while A is running, and decide to
> execute B instead. (The roles can also be reversed.) If s/he wants to run
> task A, task B must be canceled or allowed to complete before A can be
> started. Logically, the code looks something like (I fear Gmail is going to
> destroy my indentation):
>
> def do_A():
> when B is complete, _do_A()
> cancel_B()
>
> def do_B():
> when A is complete, _do_B()
> cancel_A()
>
> def _do_A():
> do the real A work here, we are guaranteed B is no longer running
>
> def _do_B():
> do the real B work here, we are guaranteed A is no longer running
>
> cancel_A and cancel_B might be no-ops, in which case they need to start up
> the other calculation immediately, if one is pending.

It strikes me that what you have two linear sequences of 'things to do':
- 'Tasks', started in reaction to some event.
- Cancellations, if a particular task happens to be running.

So, a reasonable design is to have two long-running coroutines, one that
executes your 'tasks' sequentially, and another that executes cancellations.
These are both fed 'things to do' via a couple of queues populated in event
callbacks.

Something like (apologies for typos/non-working code):


cancel_queue = asyncio.Queue()
run_queue = asyncio.Queue()

running_task = None
running_task_name = ""

def do_A():
cancel_queue.put_nowait("B")
run_queue.put_nowait(("A", _do_A()))

def do_B():
cancel_queue.put_nowait("A")
run_queue.put_nowait(("B", _do_B()))

def do_C():
run_queue.put_nowait(("C", _do_C()))

@asyncio.coroutine
def canceller():
while True:
name = yield from cancel_queue.get()
if running_task_name == name:
running_task.cancel()

@asyncio.coroutine
def runner():
while True:
name, coro = yield from run_queue.get()
running_task_name = name
running_task = asyncio.async(coro)
yield from running_task

def main():
...
cancel_task = asyncio.Task(canceller())
run_task = asyncio.Task(runner())
...



Cheers,
Phil





== 2 of 2 ==
Date: Wed, Jan 15 2014 4:58 am
From: Oscar Benjamin


On Mon, Jan 06, 2014 at 09:15:56PM -0600, Skip Montanaro wrote:
> From the couple responses I've seen, I must have not made myself
> clear. Let's skip specific hypothetical tasks. Using coroutines,
> futures, or other programming paradigms that have been introduced in
> recent versions of Python 3.x, can traditionally event-driven code be
> written in a more linear manner so that the overall algorithms
> implemented in the code are easier to follow? My code is not
> multi-threaded, so using threads and locking is not really part of the
> picture. In fact, I'm thinking about this now precisely because the
> first sentence of the asyncio documentation mentions single-threaded
> concurrent code: "This module provides infrastructure for writing
> single-threaded concurrent code using coroutines, multiplexing I/O
> access over sockets and other resources, running network clients and
> servers, and other related primitives."
>
> I'm trying to understand if it's possible to use coroutines or objects
> like asyncio.Future to write more readable code, that today would be
> implemented using callbacks, GTK signals, etc.

Hi Skip,

I don't yet understand how asyncio works in complete examples (I'm not sure
that many people do yet) but I have a loose idea of it so take the following
with a pinch of salt and expect someone else to correct me later. :)

With asyncio the idea is that you can run IO operations concurrently in the
a single thread. Execution can switch between different tasks while each task
can be written as a linear-looking generator function without the need for
callbacks and locks. Execution switching is based on which task has avilable
IO data. So the core switcher keeps track of a list of objects (open files,
sockets etc.) and executes the task when something is available.

>From the perspective of the task generator code what happens is that you yield
to allow other code to execute while you wait for some IO e.g.:

@asyncio.coroutine
def task_A():
a1 = yield from futureA1()
a2 = yield from coroutineA2(a1) # Indirectly yields from futures
a3 = yield from futureA3(a2)
return a3

At each yield statement you are specifying some operation that takes time.
During that time other coroutine code is allowed to execute in this thread.

If task_B has a reference to the future that task_A is waiting on then it can
be cancelled with the Future.cancel() method. I think that you can also cancel
with a reference to the task. So I think you can do something like

@asyncio.coroutine
def task_A():
# Cancel the other task and wait
if ref_taskB is not None:
ref_taskB.cancel()
asyncio.wait([ref_taskB])
try:
# Linear looking code with no callbacks
a1 = yield from futureA1()
a2 = yield from coroutineA2(a1) # Indirectly yields from futures
a3 = yield from futureA3(a2)
except CancelledError:
stop_A()
raise # Or return something...
return a3

Then task_B() would have the reciprocal structure. The general form with more
than just A or B would be to have a reference to the current task then you
could factor out the cancellation code with context managers, decorators or
something else.


Oscar





==============================================================================
TOPIC: Learning python networking
http://groups.google.com/group/comp.lang.python/t/3af0846b15a26766?hl=en
==============================================================================

== 1 of 3 ==
Date: Wed, Jan 15 2014 2:37 am
From: Paul Pittlerson


I'm sorry if this is a bit late of a response, but here goes.

Big thanks to Chris Angelico for his comprehensive reply, and yes, I do have some questions!


> On Thursday, January 9, 2014 1:29:03 AM UTC+2, Chris Angelico wrote:
> Those sorts of frameworks would be helpful if you need to scale to
> infinity, but threads work fine when it's small.
That's what I thought, but I was just asking if it would be like trivially easy to set up this stuff in some of those frameworks. I'm sticking to threads for now because the learning curve of twisted seems too steep to be worth it at the moment.

> Absolutely! The thing to look at is MUDs and chat servers. Ultimately,
> a multiplayer game is really just a chat room with a really fancy
> front end.
If you know of any open source projects or just instructional code of this nature in general I'll be interested to take a look. For example, you mentioned you had some similar projects of your own..?


> The server shouldn't require interaction at all. It should accept any
> number of clients (rather than getting the exact number that you
> enter), and drop them off the list when they're not there. That's a
> bit of extra effort but it's hugely beneficial.
I get what you are saying, but I should mention that I'm just making a 2 player strategy game at this point, which makes sense of the limited number of connections.

> One extremely critical point about your protocol. TCP is a stream -
> you don't have message boundaries. You can't depend on one send()
> becoming one recv() at the other end. It might happen to work when you
> do one thing at a time on localhost, but it won't be reliable on the
> internet or when there's more traffic. So you'll need to delimit
> messages; I recommend you use one of two classic ways: either prefix
> it with a length (so you know how many more bytes to receive), or
> terminate it with a newline (which depends on there not being a
> newline in the text).
I don't understand. Can you show some examples of how to do this?

> Another rather important point, in two halves. You're writing this for
> Python 2, and you're writing with no Unicode handling. I strongly
> recommend that you switch to Python 3 and support full Unicode.
Good point, however the framework I'm using for graphics does not currently support python3. I could make the server scripts be in python3, but I don't think the potential confusion is worth it until the whole thing can be in the same version.


> Note, by the way, that it's helpful to distinguish "data" and "text",
> even in pseudo-code. It's impossible to send text across a socket -
> you have to send bytes of data. If you keep this distinction clearly
> in your head, you'll have no problem knowing when to encode and when
> to decode. For what you're doing here, for instance, I would packetize
> the bytes and then decode into text, and on sending, I'd encode text
> (UTF-8 would be hands-down best here) and then packetize. There are
> other options but that's how I'd do it.
I'm not sure what you are talking about here. Would you care to elaborate on this please (it interests and confuses) ?


I'm posting this on google groups, so I hope the formatting turns out ok :P thanks.




== 2 of 3 ==
Date: Wed, Jan 15 2014 3:11 am
From: Denis McMahon


On Wed, 15 Jan 2014 02:37:05 -0800, Paul Pittlerson wrote:

>> One extremely critical point about your protocol. TCP is a stream - you
>> don't have message boundaries. You can't depend on one send() becoming
>> one recv() at the other end. It might happen to work when you do one
>> thing at a time on localhost, but it won't be reliable on the internet
>> or when there's more traffic. So you'll need to delimit messages; I
>> recommend you use one of two classic ways: either prefix it with a
>> length (so you know how many more bytes to receive), or terminate it
>> with a newline (which depends on there not being a newline in the
>> text).

> I don't understand. Can you show some examples of how to do this?

How much do you understand about tcp/ip networking? because when trying
to build something on top of tcp/ip, it's a good idea to understand the
basics of tcp/ip first.

A tcp/ip connection is just a pipe that you pour data (octets, more or
less analagous to bytes or characters) into at one end, and it comes out
at the other end.

For your stream of octets (bytes / characters) to have any meaning to a
higher level program, then the applications using the pipe at both ends
have to understand that a message has some structure.

The message structure might be to send an n character message length
count (where in a simple protocol n would have to be a fixed number)
followed by the specified number of characters.

Assuming your maximum message length is 9999 characters:

You could send the characters 9999 followed by 9999 characters of message
content.

The receiving end would receive 4 characters, convert them to the number
9999, and assume the next 9999 characters will be the message. Then it
expects another 4 character number.

You could send json encoded strings, in which case each message might
start with the "{" character and end with the "}" character, but you
would have to allow for the fact that "}" can also occur within a json
encoded string.

You might decide that each message is simply going to end with a specific
character or character sequence.

Whatever you choose, you need some way for the receiving application to
distinguish between individual messages in the stream of octets / bytes /
characters that is coming out of the pipe.

--
Denis McMahon, denismfmcmahon@gmail.com




== 3 of 3 ==
Date: Wed, Jan 15 2014 4:52 am
From: Chris Angelico


On Wed, Jan 15, 2014 at 9:37 PM, Paul Pittlerson <menkomigen6@gmail.com> wrote:
> I'm sorry if this is a bit late of a response, but here goes.
>
> Big thanks to Chris Angelico for his comprehensive reply, and yes, I do have some questions!

Best way to learn! And the thread's not even a week old, this isn't
late. Sometimes there've been responses posted to something from
2002... now THAT is thread necromancy!!

>> On Thursday, January 9, 2014 1:29:03 AM UTC+2, Chris Angelico wrote:
>> Those sorts of frameworks would be helpful if you need to scale to
>> infinity, but threads work fine when it's small.
> That's what I thought, but I was just asking if it would be like trivially easy to set up this stuff in some of those frameworks. I'm sticking to threads for now because the learning curve of twisted seems too steep to be worth it at the moment.

I really don't know, never used the frameworks. But threads are fairly
easy to get your head around. Let's stick with them.

>> Absolutely! The thing to look at is MUDs and chat servers. Ultimately,
>> a multiplayer game is really just a chat room with a really fancy
>> front end.
> If you know of any open source projects or just instructional code of this nature in general I'll be interested to take a look. For example, you mentioned you had some similar projects of your own..?
>

Here's something that I did up as a MUD-writing tutorial for Pike:

http://rosuav.com/piketut.zip

I may need to port that tutorial to Python at some point. In any case,
it walks you through the basics. (Up to section 4, everything's the
same, just different syntax for the different languages. Section 5 is
Pike-specific.)

>> The server shouldn't require interaction at all. It should accept any
>> number of clients (rather than getting the exact number that you
>> enter), and drop them off the list when they're not there. That's a
>> bit of extra effort but it's hugely beneficial.
> I get what you are saying, but I should mention that I'm just making a 2 player strategy game at this point, which makes sense of the limited number of connections.

One of the fundamentals of the internet is that connections *will*
break. A friend of mine introduced me to Magic: The Gathering via a
program that couldn't handle drop-outs, and it got extremely
frustrating - we couldn't get a game going. Build your server such
that your clients can disconnect and reconnect, and you protect
yourself against half the problem; allow them to connect and kick the
other connection off, and you solve the other half. (Sometimes, the
server won't know that the client has gone, so it helps to be able to
kick like that.) It might not be an issue when you're playing around
with localhost, and you could even get away with it on a LAN, but on
the internet, it's so much more friendly to your users to let them
connect multiple times like that.

>> One extremely critical point about your protocol. TCP is a stream -
>> you don't have message boundaries. You can't depend on one send()
>> becoming one recv() at the other end. It might happen to work when you
>> do one thing at a time on localhost, but it won't be reliable on the
>> internet or when there's more traffic. So you'll need to delimit
>> messages; I recommend you use one of two classic ways: either prefix
>> it with a length (so you know how many more bytes to receive), or
>> terminate it with a newline (which depends on there not being a
>> newline in the text).
> I don't understand. Can you show some examples of how to do this?

Denis gave a decent explanation of the problem, with a few
suggestions. One of the easiest to work with (and trust me, you will
LOVE the ease of debugging this kind of system) is the line-based
connection. You just run a loop like this:

buffer = b''

def gets():
while '\n' not in buffer:
data = sock.recv(1024)
if not data:
# Client is disconnected, handle it gracefully
return None # or some other sentinel
line, buffer = buffer.split(b'\n',1)
return line.decode().replace('\r', '')

You could put this into a class definition that wraps up all the
details. The key here is that you read as much as you can, buffering
it, and as soon as you have a newline, you return that. This works
beautifully with the basic TELNET client, so it's easy to see what's
going on. Its only requirement is that there be no newlines *inside*
commands. The classic MUD structure guarantees that (if you want a
paragraph of text, you have some marker that says "end of paragraph" -
commonly a dot on a line of its own, which is borrowed from SMTP), and
if you use json.dumps() then it'll use two characters "\\" and "n" to
represent a newline, so that's safe too.

The next easiest structure to work with is length-preceded, which
Denis explained. Again, you read until you have a full packet, but
instead of "while '\n' not in buffer", it would be "while
len(buffer)<packetlen". Whichever way you mark packets, you have to be
prepared for both problems: incomplete packets, and packets merged.
And both at once, too - one recv() call might return the tail of one
and the beginning of another.

Note that I've written the above example with the intent that it'll
work on either Python 2 or Python 3 (though it's not actually tested
on either). The more code you can do that way, the easier it'll be...
see next point.

>> Another rather important point, in two halves. You're writing this for
>> Python 2, and you're writing with no Unicode handling. I strongly
>> recommend that you switch to Python 3 and support full Unicode.
> Good point, however the framework I'm using for graphics does not currently support python3. I could make the server scripts be in python3, but I don't think the potential confusion is worth it until the whole thing can be in the same version.
>

Hmm. Maybe, but on the flip side, it might be better to first learn
how to do things in Py3, and then work on making your code able to run
in Py2. That way, you force yourself to get everything right for Py3,
and then there's no big porting job to move. Apart from the fact that
you have to learn two variants of the language, there's nothing
stopping the server being Py3 while the client's in Py2.

>> Note, by the way, that it's helpful to distinguish "data" and "text",
>> even in pseudo-code. It's impossible to send text across a socket -
>> you have to send bytes of data. If you keep this distinction clearly
>> in your head, you'll have no problem knowing when to encode and when
>> to decode. For what you're doing here, for instance, I would packetize
>> the bytes and then decode into text, and on sending, I'd encode text
>> (UTF-8 would be hands-down best here) and then packetize. There are
>> other options but that's how I'd do it.
> I'm not sure what you are talking about here. Would you care to elaborate on this please (it interests and confuses) ?

Fundamentally, network protocols work with bytes. (Actually, they're
often called 'octets' - and a good number of protocols work with
*bits*, of which an octet is simply a group of eight.) They don't work
with characters. But humans want to send text. I'll use these posts as
an example.

1) Human types text into mail client, newsreader, or web browser.
2) Client wraps that text up somehow and sends it to a server.
3) Server sends it along to other servers.
4) Server sends stuff to another client.
5) Client unwraps the text and shows it to a human.

For there to be viable communication, the text typed in step 1 has to
be the same as the text shown in step 5. So we need to have some kind
of system that says "This character that I see on my screen is
represented by this byte or sequence of bytes". That's called an
encoding. It's simply a mapping of characters to byte sequences.
(There are other complexities, too, but I'll handwave those for the
moment. For now, let's pretend that one character that you see on the
screen - more properly termed a glyph - is represented by one stream
of bytes.) The best way to handle this is Unicode, because it's fairly
safe to assume that most people can handle it. So you design your
protocol to use Unicode characters and UTF-8 encoding. That means
that:

* The character 'A' (LATIN CAPITAL LETTER A) is represented by code
point U+0041 and byte sequence 0x41
* The character '©' (COPYRIGHT SIGN) is code point U+00A9 or 0xC2 0xA9
* '☺' (WHITE SMILING FACE) is U+263A or 0xE2 0x98 0xBA
* '𒍅' (CUNEIFORM SIGN URU TIMES KI) is U+12345 or 0xF0 0x92 0x8D 0x85

(Tip: http://www.fileformat.info/ is a great place to play around with
these sorts of things.)

An agreement like this means that one human can type a white smiling
face, his client will interpret it as U+263A, the email and news posts
will contain E2 98 BA, and the human at the other end will see a white
smiling face. There's more to it than that, at least with these posts,
because not everyone uses UTF-8 (so the encoding has to be declared),
but if you're creating a brand new protocol, you can simply mandate
it. I strongly recommend UTF-8, by the way; it's compact for text
that's mostly Latin characters, it's well known, and it covers the
entire Unicode range (unlike, say, CP-1252 as used on Windows, or the
ISO-8859-? series).

Since you're working with JSON, you could choose to work with ASCII,
as JSON has its own notation for incorporating non-ASCII characters in
an ASCII stream. But I think it's probably better to use UTF-8.

One of the huge advantages of Python 3 over Python 2 is that it forces
you to think about this up-front. There is a stark divide between
bytes and text. In Python 2, you can sorta pretend that ASCII text and
bytes are the same thing, which often leads to programs that work
perfectly until they get to a "weird character". Fact is, there are no
weird characters. :) I recommend this talk by Ned Batchelder:

http://nedbatchelder.com/text/unipain.html

Watch it, comprehend it, and code with his Facts of Life and Pro Tips
in mind, and you'll have no pain.

> I'm posting this on google groups, so I hope the formatting turns out ok :P thanks.

Your lines are coming out extremely long, but the biggest annoyance of
GG (double-spaced replies) isn't happening. Thank you.

ChrisA





==============================================================================
TOPIC: 'Straße' ('Strasse') and Python 2
http://groups.google.com/group/comp.lang.python/t/93ddbbff468ab95d?hl=en
==============================================================================

== 1 of 3 ==
Date: Wed, Jan 15 2014 4:00 am
From: Robin Becker


On 12/01/2014 07:50, wxjmfauth@gmail.com wrote:
>>>> sys.version
> 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)]
>>>> s = 'Straße'
>>>> assert len(s) == 6
>>>> assert s[5] == 'e'
>>>>
>
> jmf
>

On my utf8 based system


> robin@everest ~:
> $ cat ooo.py
> if __name__=='__main__':
> import sys
> s='A̅B'
> print('version_info=%s\nlen(%s)=%d' % (sys.version_info,s,len(s)))
> robin@everest ~:
> $ python ooo.py
> version_info=sys.version_info(major=3, minor=3, micro=3, releaselevel='final', serial=0)
> len(A̅B)=3
> robin@everest ~:
> $


so two 'characters' are 3 (or 2 or more) codepoints. If I want to isolate so
called graphemes I need an algorithm even for python's unicode ie when it really
matters, python3 str is just another encoding.
--
Robin Becker





== 2 of 3 ==
Date: Wed, Jan 15 2014 4:13 am
From: Ned Batchelder


On 1/15/14 7:00 AM, Robin Becker wrote:
> On 12/01/2014 07:50, wxjmfauth@gmail.com wrote:
>>>>> sys.version
>> 2.7.6 (default, Nov 10 2013, 19:24:18) [MSC v.1500 32 bit (Intel)]
>>>>> s = 'Straße'
>>>>> assert len(s) == 6
>>>>> assert s[5] == 'e'
>>>>>
>>
>> jmf
>>
>
> On my utf8 based system
>
>
>> robin@everest ~:
>> $ cat ooo.py
>> if __name__=='__main__':
>> import sys
>> s='A̅B'
>> print('version_info=%s\nlen(%s)=%d' % (sys.version_info,s,len(s)))
>> robin@everest ~:
>> $ python ooo.py
>> version_info=sys.version_info(major=3, minor=3, micro=3,
>> releaselevel='final', serial=0)
>> len(A̅B)=3
>> robin@everest ~:
>> $
>
>
> so two 'characters' are 3 (or 2 or more) codepoints. If I want to
> isolate so called graphemes I need an algorithm even for python's
> unicode ie when it really matters, python3 str is just another encoding.

You are right that more than one codepoint makes up a grapheme, and that
you'll need code to deal with the correspondence between them. But let's
not muddy these already confusing waters by referring to that mapping as
an encoding.

In Unicode terms, an encoding is a mapping between codepoints and bytes.
Python 3's str is a sequence of codepoints.

--
Ned Batchelder, http://nedbatchelder.com





== 3 of 3 ==
Date: Wed, Jan 15 2014 4:50 am
From: Robin Becker


On 15/01/2014 12:13, Ned Batchelder wrote:
........
>> On my utf8 based system
>>
>>
>>> robin@everest ~:
>>> $ cat ooo.py
>>> if __name__=='__main__':
>>> import sys
>>> s='A̅B'
>>> print('version_info=%s\nlen(%s)=%d' % (sys.version_info,s,len(s)))
>>> robin@everest ~:
>>> $ python ooo.py
>>> version_info=sys.version_info(major=3, minor=3, micro=3,
>>> releaselevel='final', serial=0)
>>> len(A̅B)=3
>>> robin@everest ~:
>>> $
>>
>>
........
> You are right that more than one codepoint makes up a grapheme, and that you'll
> need code to deal with the correspondence between them. But let's not muddy
> these already confusing waters by referring to that mapping as an encoding.
>
> In Unicode terms, an encoding is a mapping between codepoints and bytes. Python
> 3's str is a sequence of codepoints.
>
Semantics is everything. For me graphemes are the endpoint (or should be); to
get a proper rendering of a sequence of graphemes I can use either a sequence of
bytes or a sequence of codepoints. They are both encodings of the graphemes;
what unicode says is an encoding doesn't define what encodings are ie mappings
from some source alphabet to a target alphabet.
--
Robin Becker






==============================================================================
TOPIC: proposal: bring nonlocal to py2.x
http://groups.google.com/group/comp.lang.python/t/643e84b50e561338?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Jan 15 2014 4:07 am
From: Robin Becker


On 13/01/2014 15:28, Chris Angelico wrote:
..........
>
> It's even worse than that, because adding 'nonlocal' is not a bugfix.
> So to be committed to the repo, it has to be approved for either 2.7
> branch (which is in bugfix-only maintenance mode) or 2.8 branch (which
> does not exist). Good luck. :)
.......
fixing badly named variables is not a bug fix either, but that has happened in
python 2.7. A micro change release changed

compiler.consts.SC_GLOBAL_EXPLICT

to

compiler.consts.SC_GLOBAL_EXPLICIT

this is a change of api for the consts module (if you regard exported variables
as part of its api), but that didn't count for the developers.
--
Robin Becker






==============================================================================
TOPIC: Python 3 __bytes__ method
http://groups.google.com/group/comp.lang.python/t/03c277858d35f158?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Jan 15 2014 4:07 am
From: Thomas Rachel


Am 12.01.2014 01:24 schrieb Ethan Furman:

> I must admit I'm not entirely clear how this should be used. Is anyone
> using this now? If so, how?

I am not, as I currently am using Py2, but if I would, I would do it e.
g. for serialization of objects in order to send them over the line or
to save them into a file. IOW, the same purpose as we havd on __str__ in
Py2.


Thomas






==============================================================================
TOPIC: Question about object lifetime and access
http://groups.google.com/group/comp.lang.python/t/127e2f43e2934562?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Jan 15 2014 4:13 am
From: Asaf Las


Hi community

i am beginner in Python and have possibly silly questions i could not figure out answers for.

Below is the test application working with uwsgi to test json-rpc.
------------------------------------------------------------------------
from multiprocessing import Process
from werkzeug.wrappers import Request, Response
from werkzeug.serving import run_simple

from jsonrpc import JSONRPCResponseManager, dispatcher

p = "module is loaded" <------ (3)
print(p)
print(id(p))

@Request.application
def application(request):
print("server started")

print(id(p))

# Dispatcher is dictionary {<method_name>: callable}
dispatcher["echo"] = lambda s: s <---- (1)
dispatcher["add"] = lambda a, b: a + b <---- (2)

print("request data ==> ", request.data)
response = JSONRPCResponseManager.handle(request.data, dispatcher)
return Response(response.json, mimetype='application/json')
------------------------------------------------------------------------

As program will grow new rpc method dispatchers will be added so there is idea to reduce initialization code at steps 1 and 2 by making them global objects created at module loading, like string p at step 3.

Multithreading will be enabled in uwsgi and 'p' will be used for read only.

Questions are:
- what is the lifetime for global object (p in this example).
- will the p always have value it got during module loading
- if new thread will be created will p be accessible to it
- if p is accessible to new thread will new thread initialize p value again?
- is it guaranteed to have valid p content (set to "module is loaded") whenever application() function is called.
- under what condition p is cleaned by gc.

The rationale behind these question is to avoid object creation within application() whose content is same and do not change between requests calling application() function and thus to reduce script response time.

Thanks in advance!








== 2 of 2 ==
Date: Wed, Jan 15 2014 4:55 am
From: Ned Batchelder


On 1/15/14 7:13 AM, Asaf Las wrote:
> Hi community
>
> i am beginner in Python and have possibly silly questions i could not figure out answers for.
>
> Below is the test application working with uwsgi to test json-rpc.
> ------------------------------------------------------------------------
> from multiprocessing import Process
> from werkzeug.wrappers import Request, Response
> from werkzeug.serving import run_simple
>
> from jsonrpc import JSONRPCResponseManager, dispatcher
>
> p = "module is loaded" <------ (3)
> print(p)
> print(id(p))
>
> @Request.application
> def application(request):
> print("server started")
>
> print(id(p))
>
> # Dispatcher is dictionary {<method_name>: callable}
> dispatcher["echo"] = lambda s: s <---- (1)
> dispatcher["add"] = lambda a, b: a + b <---- (2)
>
> print("request data ==> ", request.data)
> response = JSONRPCResponseManager.handle(request.data, dispatcher)
> return Response(response.json, mimetype='application/json')
> ------------------------------------------------------------------------
>
> As program will grow new rpc method dispatchers will be added so there is idea to reduce initialization code at steps 1 and 2 by making them global objects created at module loading, like string p at step 3.
>
> Multithreading will be enabled in uwsgi and 'p' will be used for read only.

The important concepts to understand are names and values. All values in
Python work the same way: they live until no name refers to them. Also,
any name can be assigned to (rebound) after it has been defined.

This covers the details in more depth:
http://nedbatchelder.com/text/names.html

>
> Questions are:
> - what is the lifetime for global object (p in this example).

The name p is visible in this module for as long as the program is
running. The object you've assigned to p can be shorter-lived if p is
reassigned.

> - will the p always have value it got during module loading

Depends if you reassign it.

> - if new thread will be created will p be accessible to it

If the thread is running code defined in this module, yes, that code
will be able to access p in that thread.

> - if p is accessible to new thread will new thread initialize p value again?

No, the module is only imported once, so the statements at the top level
of the module are only executed once.

> - is it guaranteed to have valid p content (set to "module is loaded") whenever application() function is called.

Yes, unless you reassign p.

> - under what condition p is cleaned by gc.

Names are not reclaimed by the garbage collector, values are. The value
assigned to p can be reclaimed if you reassign the name p, and nothing
else is referring to the value.

>
> The rationale behind these question is to avoid object creation within application() whose content is same and do not change between requests calling application() function and thus to reduce script response time.
>
> Thanks in advance!

Welcome.


--
Ned Batchelder, http://nedbatchelder.com






==============================================================================
TOPIC: ANN: Python Meeting Düsseldorf - 21.01.2014
http://groups.google.com/group/comp.lang.python/t/ce3d5c7c3eaef5e3?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Jan 15 2014 4:39 am
From: "eGenix Team: M.-A. Lemburg"


[This announcement is in German since it targets a local user group
meeting in Düsseldorf, Germany]

________________________________________________________________________
ANKÜNDIGUNG

Python Meeting Düsseldorf

http://pyddf.de/

Ein Treffen von Python Enthusiasten und Interessierten
in ungezwungener Atmosphäre.

Dienstag, 21.01.2014, 18:00 Uhr
Raum 1, 2.OG im Bürgerhaus Stadtteilzentrum Bilk
Düsseldorfer Arcaden, Bachstr. 145, 40217 Düsseldorf

Diese Nachricht ist auch online verfügbar:
http://www.egenix.com/company/news/Python-Meeting-Duesseldorf-2014-01-21

________________________________________________________________________
NEUIGKEITEN

* Bereits angemeldete Vorträge:

Charlie Clark
"Properties & Descriptors"

Marc-Andre Lemburg
"Webseiten Screenshots mit Python automatisieren"

Charlie Clark
"Einfache Test-Automatisierung mit tox"

* Neue Videos

Wir haben in den letzten Wochen eine ganze Reihe neuer Videos
produziert und auf unseren YouTube-Kanal hochgeladen:

PyDDF YouTube-Kanal: http://www.youtube.com/pyddf/

* Neuer Veranstaltungsraum:

Wir treffen uns im Bürgerhaus in den Düsseldorfer Arcaden.
Da beim letzten Mal einige Teilnehmer Schwierigkeiten hatten,
den Raum zu finden, hier eine kurze Beschreibung:

Das Bürgerhaus teilt sich den Eingang mit dem Schwimmbad
und befindet sich an der Seite der Tiefgarageneinfahrt der
Düsseldorfer Arcaden.

Über dem Eingang steht ein großes "Schwimm''in Bilk"
Logo. Hinter der Tür direkt links zu den zwei Aufzügen,
dann in den 2. Stock hochfahren. Der Eingang zum Raum 1
liegt direkt links, wenn man aus dem Aufzug kommt.

Google Street View: http://bit.ly/11sCfiw

________________________________________________________________________
EINLEITUNG

Das Python Meeting Düsseldorf ist eine regelmäßige Veranstaltung in
Düsseldorf, die sich an Python Begeisterte aus der Region wendet:

* http://pyddf.de/

Einen guten Überblick über die Vorträge bietet unser YouTube-Kanal,
auf dem wir die Vorträge nach den Meetings veröffentlichen:

* http://www.youtube.com/pyddf/

Veranstaltet wird das Meeting von der eGenix.com GmbH, Langenfeld,
in Zusammenarbeit mit Clark Consulting & Research, Düsseldorf:

* http://www.egenix.com/
* http://www.clark-consulting.eu/

________________________________________________________________________
PROGRAMM

Das Python Meeting Düsseldorf nutzt eine Mischung aus Open Space
und Lightning Talks, wobei die Gewitter bei uns auch schon mal
20 Minuten dauern können ;-).

Lightning Talks können vorher angemeldet werden, oder auch
spontan während des Treffens eingebracht werden. Ein Beamer mit
XGA Auflösung steht zur Verfügung. Folien bitte als PDF auf USB
Stick mitbringen.

Lightning Talk Anmeldung bitte formlos per EMail an info@pyddf.de

________________________________________________________________________
KOSTENBETEILIGUNG

Das Python Meeting Düsseldorf wird von Python Nutzern für Python
Nutzer veranstaltet. Um die Kosten zumindest teilweise zu
refinanzieren, bitten wir die Teilnehmer um einen Beitrag
in Höhe von EUR 10,00 inkl. 19% Mwst, Schüler und Studenten
zahlen EUR 5,00 inkl. 19% Mwst.

Wir möchten alle Teilnehmer bitten, den Betrag in bar mitzubringen.

________________________________________________________________________
ANMELDUNG

Da wir nur für ca. 20 Personen Sitzplätze haben, möchten wir
bitten, sich per EMail anzumelden. Damit wird keine Verpflichtung
eingegangen. Es erleichtert uns allerdings die Planung.

Meeting Anmeldung bitte formlos per EMail an info@pyddf.de

________________________________________________________________________
WEITERE INFORMATIONEN

Weitere Informationen finden Sie auf der Webseite des Meetings:

http://pyddf.de/

Mit freundlichen Grüßen,
--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source (#1, Jan 15 2014)
>>> Python Projects, Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________

::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::

eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/




==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.python"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.python?hl=en

To unsubscribe from this group, send email to comp.lang.python+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.python/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en