Re: [Python-Dev] Adding a conditional expression in Py3.0

2005-09-27 Thread Gustavo J. A. M. Carneiro 
On Sun, 2005-09-25 at 19:11 +0200, Reinhold Birkenfeld wrote:
> Sokolov Yura wrote:
> > Sorry for looking in every hole.
> > Just a  suggestion.
> > 
> > A= condition and first or second
> > problem is in case when first in (None,0,[],"").
> > May be invent new operator 'take'.
> > take - returns right operator when left evals to True and stops 
> > computing condidtional expression.
> > Then we could write:
> > 
> > A = condition take first or second.
> > A = x==y take w or s
> > A = z is not None and q!=12 take [] or allowable(z,q) take [(z,q)] or 
> > "Impossible"
> > 
> > Ok, it might looks ugly. But may be not.
> 
> One of the advantages of (if x then y else z) is that it doesn't require
> the introduction of a new keyword (I think the "then" could be special-
> cased like "as" in the import statement).

  This wouldn't look so bad either:
(if x: y else: z)

  More realistic example:

def greet(person=None):
print "Hello %s" % (if person is None: "World" else: person)

  Not as compact as C's ?:, but more readable and intuitive.  It's just
like an if-else construct, but on a single line and () around to make it
look like an expression instead of a statement.

> 
> Reinhold
> 
-- 
Gustavo J. A. M. Carneiro
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
The universe is always one step beyond logic.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Adding a conditional expression in Py3.0

2005-09-27 Thread Sokolov Yura 
New keyword is so expensive?
And why special case for 'then' is better than special case for 'take'?

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 350: Codetags

2005-09-27 Thread Guido van Rossum 
On 9/26/05, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
> Micah Elliott <[EMAIL PROTECTED]> wrote:
> > ``FIXME (XXX, DEBUG, BROKEN, REFACTOR, REFACT, RFCTR, OOPS, SMELL, 
> > NEEDSWORK, INSPECT)``
> >*Fix me*: Areas of problematic or ugly code needing refactoring or
> >cleanup.
>
> I think the standard should not have codetags that are synonyms.
> This is Python and there should be only one way to do it.  One
> problem with synonyms is that they makes it harder to search using
> tools like grep.

It has always been my choice to *only* use XXX. I hope there aren't
any developers contributing to the Python core who use any others? I
honestly don't see much of a point for distinguishing different types;
these are for humans to read and review, and different tags just makes
it harder to grep.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 350: Codetags

2005-09-27 Thread Fredrik Lundh 
Guido van Rossum wrote:

> It has always been my choice to *only* use XXX. I hope there aren't
> any developers contributing to the Python core who use any others?

[Python-2.4.1]$ grep FIXME */*.c */*.py | wc -l
 12
[Python-2.4.1]$ grep TODO */*.c */*.py | wc -l
 17
[Python-2.4.1]$ grep XXX */*.c */*.py | wc -l
525

> I honestly don't see much of a point for distinguishing different types;
> these are for humans to read and review, and different tags just makes
> it harder to grep.

I tend to use FIXME for smelly code, and a collection of TODO:s at the top
of the file for things that someone should work on some day...  (which explains
some, but not all, of the non-XXX:es above...)

 



___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Fixing pty.spawn()

2005-09-27 Thread Gustavo Barbieri 
Hello,

I've come to a problem with pty.spawn() as it states on its source code:

# Bugs: No signal handling.  Doesn't set slave termios and window size.

As I need this feature working, I want to fix this bug. Does someone
have any idea on how to fix it?

(My problem: I want to launch ncurses software from my python
software, then come back, choose another program and launch it, ...)

--
Gustavo Sverzut Barbieri
---
Computer Engineer 2001 - UNICAMP
GPSL - Grupo Pro Software Livre
Cell..: +55 (19) 9165 8010
Jabber: [EMAIL PROTECTED]
  ICQ#: 17249123
   MSN: [EMAIL PROTECTED]
 Skype: gsbarbieri
   GPG: 0xB640E1A2 @ wwwkeys.pgp.net
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Active Objects in Python

2005-09-27 Thread Bruce Eckel 
According to this list's welcome message, I should introduce myself.
I'm Bruce Eckel, I write, consult and give seminars about computer
programming, I use Python whenever I can get away with it, and I've
spoken at Pycon a number of times. There are further URLs in my
signature at the bottom.

I'm joining this list because I was having a conversation with Guido
about concurrency support in Python (in particular, using an
actor/active-object approach) and he suggested I bring it over
here. Here are the highlights of my most recent reply to him (Guido's
remarks are marked by the '>' signs):

> Agreed. IMO the pthreads-style solution doesn't work well no matter
> *what* the programming model.

Exactly. I think the problem may be that low-level threads people are
one step behind (much like embedded systems programmers, which is
where I began). They may be just now catching up to objects, but as
far as concurrency goes their brains still think in terms of threads,
so it seems natural to apply thread concepts to objects.

But from an OO standpoint, pthread-style thinking is two steps
backwards. You effectively throw open the innards of the object that
you just spent time decoupling from the rest of your system, and the
coupling is now unpredictable. It's the worst of all possible worlds.

> I worked on Mobile Agents at CNRI from 1995 till 2000, but they were
> very heavy-weight. Yet, I think that any solution that moves objects
> between CPUs on a regular basis is going to suffer the same problem
> that process switching in general gets you -- the move is so expensive
> that it's hard to decide when it's justified.

The examples I've seen haven't relied on mobility, so that's a
question: how important is mobility really to an agent system? And
could it be done in a trivial fashion in Python, by sending source
code. And if it was really necessary sometimes, could it be something
where the cost of mobility only occurred when moving an object?

It's possible that either an argument can be made against mobility
and/or some kind of trivial mobility system could be developed that
would work when necessary. Possibly a Linda-like put-take system with
pickles (off the top of my head).

I don't know that much about mobility, but it does seem like mobile
agents could be a powerful solution to the problem solved by
enterprise messaging systems.

> I believe you pointed me to Active Objects before, right? (Years ago,
> maybe when you visited us at Zope.)

I may have mentioned them in the past.

> If multiple active objects can co-exist in the same *process*, but
> nevertheless the language implementation prevents them from sharing
> data except via channels, and in addition allows dynamic reallocation
> of active objects across multiple CPUs, they just might be the ticket.
> But it would require a complete implementation to prove it.

Yes, defining an class as "active" would:
1) Install a worker thread and concurrent queue in each object of that
class.
2) Automatically turn method calls into tasks and enqueue them
3) Prevent any other interaction other than enqueued messages

At that point, the only time the GIL might be needed is to lock the
queue at the point of putting ant taking objects. But there has been
work done on lock-free data structures, which has been incorporated
into Java 5 libraries, so it might even be possible to use a lock-free
queue to do this and thus eliminate the need for the GIL at all.

Since the enqueuing process serializes all requests to active objects,
and since each message-task runs to completion before the next one
starts, the problem of threads interfering with each other is
eliminated. Also, the enqueuing process will always happen, so even if
the queue blocks it will be for a very short, deterministic time. So
the theory is that Active Object systems cannot deadlock (although I
believe they can livelock).

So yes, the best way for this to work might be some kind of enforced
implementation -- but forcing you to do something is not particularly
Pythonic, so I would think that it would be possible to build an
active object framework along with some checking tools to warn you if
you are breaking the rules. But what's not clear is whether this would
require knowledge of the innards of the Python interpreter (which I
don't have) or if it could be built using libraries.

BTW: I think that Hoare's Communicating Sequential Processes (CSP)
basically describes the idea of active objects but without objects.
That is, I think active objects is CSP applied to OO.

Bruce Eckelhttp://www.BruceEckel.com
Contains electronic books: "Thinking in Java 3e" & "Thinking in C++ 2e"
Web log: http://www.artima.com/weblogs/index.jsp?blogger=beckel



___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Active Objects in Python

2005-09-27 Thread Phillip J. Eby 
At 11:18 AM 9/27/2005 -0600, Bruce Eckel wrote:
>Yes, defining an class as "active" would:
>1) Install a worker thread and concurrent queue in each object of that
>class.
>2) Automatically turn method calls into tasks and enqueue them
>3) Prevent any other interaction other than enqueued messages

#3 is the sticky bit.  Enforcing such restrictions in Python is 
*hard*.  Each active object would have to have its own sys.modules, for 
example, because modules and classes in Python are mutable and use 
dictionaries, and modifying them from two thread simultaneously would be fatal.

For built-in types it's not so bad, so they could be shared...  except for 
the fact that they have reference counts, which need lock protection as 
well to avoid fouling up GC.  So really, this idea doesn't really help with 
GIL removal at all.

What it *does* help with, is effective use of multiprocessor machines on 
platforms where fork() is available, if the API works across processes as 
well as threads.


>So yes, the best way for this to work might be some kind of enforced
>implementation -- but forcing you to do something is not particularly
>Pythonic,

But keeping the interpreter from dumping core due to program bugs *is* 
Pythonic, which is why the GIL would need to stay.  :)


>so I would think that it would be possible to build an
>active object framework along with some checking tools to warn you if
>you are breaking the rules.

Well, you could pickle and unpickle the objects you send from one function 
to another, and for cross-process communication, you'll need to do 
something like that anyway, or else use that shared-memory objects 
thing.  PySHM?  I don't remember its name, but it's an extension that lets 
you store Python objects in shared memory and use them from multiple 
processes, modulo certain strict limitations.


>  But what's not clear is whether this would
>require knowledge of the innards of the Python interpreter (which I
>don't have) or if it could be built using libraries.

If you're not trying to get rid of the GIL or truly "enforce" things, you 
can do everything you need for CSP in plain old Python.  peak.events has a 
generator-based microthread facility that's CSP-ish, for example, although 
it doesn't have decorators for async methods.  They're not hard to write, 
though; Chandler has some for methods that get called across thread 
barriers now.  That is, methods that get called from Chandler's UI thread 
but are run in the Twisted reactor thread.  I've occasionally also thought 
about implementing async C#'s "chord" features in Python for peak.events, 
but I haven't actually had a use case that needed that much generality yet.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Active Objects in Python

2005-09-27 Thread Benji York 
Phillip J. Eby wrote:
> Well, you could pickle and unpickle the objects you send from one function 
> to another, and for cross-process communication, you'll need to do 
> something like that anyway, or else use that shared-memory objects 
> thing.  PySHM?  I don't remember its name, but it's an extension that lets 
> you store Python objects in shared memory and use them from multiple 
> processes, modulo certain strict limitations.

"POSH": http://poshmodule.sourceforge.net/posh/html/
--
Benji York


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 350: Codetags

2005-09-27 Thread Josiah Carlson 

"Phillip J. Eby" <[EMAIL PROTECTED]> wrote:
> At 03:35 PM 9/26/2005 -0700, Micah Elliott wrote:
> >Please read/comment/vote.  This circulated as a pre-PEP proposal
> >submitted to c.l.py on August 10, but has changed quite a bit since
> >then.  I'm reposting this since it is now "Open (under consideration)"
> >at .
> 
> This seems a little weird to me.  On the one hand, seems like a cool idea 
> if you aren't using Eclipse or another IDE that tracks this stuff, but 
> still need some kind of tracking system.  But, if that is the case, the 
> notation seems a little bit overkill, especially with respect to tracking 
> who's responsible - i.e., just you.

There are various Python editors which have had support for a similar
style of tags for quite a while.  Some allow #: ,
others allow #  : , even others allow
more or less.  Some even count exclamation points as an indicator of
severity.

Personally, though I use tags in some of the code I write, and though
the editor I use (and wrote) supports tags, I'm of the opinion that an
unofficial spec is sufficient.  See koders.com and search for 'fixme' to
see some common variants.

 - Josiah

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fixing pty.spawn()

2005-09-27 Thread Gustavo Barbieri 
The attached patch calls ioctl() to set master_fd win size.

I use fcntl and struct modules, I have hardcoded values from termios
since this module is deleted.

Is it ok?

--
Gustavo Sverzut Barbieri
---
Computer Engineer 2001 - UNICAMP
GPSL - Grupo Pro Software Livre
Cell..: +55 (19) 9165 8010
Jabber: [EMAIL PROTECTED]
  ICQ#: 17249123
   MSN: [EMAIL PROTECTED]
 Skype: gsbarbieri
   GPG: 0xB640E1A2 @ wwwkeys.pgp.net


pty_spawn_set_winsize.patch
Description: Binary data
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 350: Codetags

2005-09-27 Thread Micah Elliott 
Please read/comment/vote.  This circulated as a pre-PEP proposal
submitted to c.l.py on August 10, but has changed quite a bit since
then.  I'm reposting this since it is now "Open (under consideration)"
at .

Thanks!

-- 
Micah Elliott 


PEP: 350
Title: Codetags
Version: $Revision: 1.2 $
Last-Modified: $Date: 2005/09/26 19:56:53 $
Author: Micah Elliott 
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 27-Jun-2005
Post-History: 10-Aug-2005, 26-Sep-2005


Abstract


This informational PEP aims to provide guidelines for consistent use
of *codetags*, which would enable the construction of standard
utilities to take advantage of the codetag information, as well as
making Python code more uniform across projects.  Codetags also
represent a very lightweight programming micro-paradigm and become
useful for project management, documentation, change tracking, and
project health monitoring.  This is submitted as a PEP because its
ideas are thought to be Pythonic, although the concepts are not unique
to Python programming.  Herein are the definition of codetags, the
philosophy behind them, a motivation for standardized conventions,
some examples, a specification, a toolset description, and possible
objections to the Codetag project/paradigm.

This PEP is also living as a wiki_ for people to add comments.


What Are Codetags?
==

Programmers widely use ad-hoc code comment markup conventions to serve
as reminders of sections of code that need closer inspection or
review.  Examples of markup include ``FIXME``, ``TODO``, ``XXX``,
``BUG``, but there many more in wide use in existing software.  Such
markup will henceforth be referred to as *codetags*.  These codetags
may show up in application code, unit tests, scripts, general
documentation, or wherever suitable.

Codetags have been under discussion and in use (hundreds of codetags
in the Python 2.4 sources) in many places (e.g., c2_) for many years.
See References_ for further historic and current information.


Philosophy
==

If you subscribe to most of these values, then codetags will likely be
useful for you.

1. As much information as possible should be contained **inside the
   source code** (application code or unit tests).  This along with
   use of codetags impedes duplication.  Most documentation can be
   generated from that source code; e.g., by using help2man, man2html,
   docutils, epydoc/pydoc, ctdoc, etc.

2. Information should be almost **never duplicated** -- it should be
   recorded in a single original format and all other locations should
   be automatically generated from the original, or simply be
   referenced.  This is famously known as the Single Point Of
   Truth (SPOT) or Don't Repeat Yourself (DRY) rule.

3. Documentation that gets into customers' hands should be
   **auto-generated** from single sources into all other output
   formats.  People want documentation in many forms.  It is thus
   important to have a documentation system that can generate all of
   these.

4. The **developers are the documentation team**.  They write the code
   and should know the code the best.  There should not be a
   dedicated, disjoint documentation team for any non-huge project.

5. **Plain text** (with non-invasive markup) is the best format for
   writing anything.  All other formats are to be generated from the
   plain text.

Codetag design was influenced by the following goals:

A. Comments should be short whenever possible.

B. Codetag fields should be optional and of minimal length.  Default
   values and custom fields can be set by individual code shops.

C. Codetags should be minimalistic.  The quicker it is to jot
   something down, the more likely it is to get jotted.

D. The most common use of codetags will only have zero to two fields
   specified, and these should be the easiest to type and read.


Motivation
==

* **Various productivity tools can be built around codetags.**

  See Tools_.

* **Encourages consistency.**

  Historically, a subset of these codetags has been used informally in
  the majority of source code in existence, whether in Python or in
  other languages.  Tags have been used in an inconsistent manner with
  different spellings, semantics, format, and placement.  For example,
  some programmers might include datestamps and/or user identifiers,
  limit to a single line or not, spell the codetag differently than
  others, etc.

* **Encourages adherence to SPOT/DRY principle.**

  E.g., generating a roadmap dynamically from codetags instead of
  keeping TODOs in sync with separate roadmap document.

* **Easy to remember.**

  All codetags must be concise, intuitive, and semantically
  non-overlapping with others.  The format must also be simple.

* **Use not required/imposed.**

  If you don't use codetags already, there's no obligation to start,
  and no risk of affecting code (but see Objections_).  A small subset
  can be

Re: [Python-Dev] PEP 350: Codetags

2005-09-27 Thread Phillip J. Eby 
At 03:35 PM 9/26/2005 -0700, Micah Elliott wrote:
>Please read/comment/vote.  This circulated as a pre-PEP proposal
>submitted to c.l.py on August 10, but has changed quite a bit since
>then.  I'm reposting this since it is now "Open (under consideration)"
>at .

This seems a little weird to me.  On the one hand, seems like a cool idea 
if you aren't using Eclipse or another IDE that tracks this stuff, but 
still need some kind of tracking system.  But, if that is the case, the 
notation seems a little bit overkill, especially with respect to tracking 
who's responsible - i.e., just you.

If you have a team that can agree to use the tools, I suppose it might be 
useful, but then I wonder, why not use something like Trac?

Finally, I think there should be something besides just a comment to 
distinguish these things; like starting with a symbol (e.g. # !FIXME), so 
that that documentation extraction tools can distinguish code tags from 
other documentation that just happens to start with a CAPITALIZED word.

Overall, I'm kind of -0.5.  It seems like a spec in search of an 
application.  The Motivation is sorely lacking - it reads like, "hey, it's 
optional and you can do stuff", where the stuff you can do is deferred to a 
later section, and is mostly stuff that could easily be done in other 
ways.  For example, FIT-style acceptance test documents, or Python doctest 
files go a long way towards documenting stories in association with tests, 
and they don't require you to cram things into comments.  (And because 
they're executable tests, they get kept up-to-date.)  Tracking bugfixes 
with code history is handled nicely by tools like Trac.  There are lots of 
Python documentation tools already.  And so on.  Really, it reads to me 
like you came up with the features to sell the format, instead of designing 
the format to implement specific features.

My suggestion: implement some tools, use them for a while, and come back 
with more focused use cases to show why only this format can work, and why 
the Python core developers should therefore use it.  I'm not saying that 
you can't have an informational PEP unless it should be used in the stdlib, 
mind you.  Just pointing out that if you can't convince the core developers 
it's useful, I'm thinking you'll have a hard time convincing the community 
at large to actually use it.  You need to actually have a better mousetrap 
to present before you ask people to move their cheese.  :)

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding a conditional expression in Py3.0

2005-09-27 Thread Nick Coghlan 
Gustavo J. A. M. Carneiro wrote:
>   More realistic example:
> 
> def greet(person=None):
>   print "Hello %s" % (if person is None: "World" else: person)
> 
>   Not as compact as C's ?:, but more readable and intuitive.  It's just
> like an if-else construct, but on a single line and () around to make it
> look like an expression instead of a statement.

It looks even more like an expression without any embedded colons ;)

   def greet(person=None):
   # Infix conditional
   print "Hello %s" % ("World" if person is None else person)

   def greet(person=None):
   # Negated infix conditional so that 'normal' value is first
   print "Hello %s" % (person if person is not None else "World")

   def greet(person=None):
   # Prefix conditional
   print "Hello %s" % (if person is None then "World" else person)

Anyway, Guido's already given some indication that the PEP 308 infix and 
prefix conditional operators without colons (above) are the main options he is 
considering choosing from.

Regards,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://boredomandlaziness.blogspot.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Active Objects in Python

2005-09-27 Thread Nick Coghlan 
Bruce Eckel wrote:
> Since the enqueuing process serializes all requests to active objects,
> and since each message-task runs to completion before the next one
> starts, the problem of threads interfering with each other is
> eliminated. Also, the enqueuing process will always happen, so even if
> the queue blocks it will be for a very short, deterministic time. So
> the theory is that Active Object systems cannot deadlock (although I
> believe they can livelock).

I've done this at work (in C++, not Python), and it works very well. I had my 
doubts when my boss first put the architecture for it in place, but a couple 
of years of working with this architecture (and that boss!) persuaded me 
otherwise.

Livelock is a definite issue, particular if you design the individual active 
objects as finite state machines - it is fairly easy to get into a situation 
where Object A is waiting for a particular message from Object B, while Object 
B is waiting for a particular message from Object A. This chain is generally 
indirect, which makes it hard to spot. It is, however, still easier to figure 
this out than it is to figure out normal threading bugs, because you can find 
it just by analysing a sequence diagram showing message exchange and state 
transitions, rather than caring about the actual underlying code. Threading 
bugs, on the other hand, can turn up any time you access a shared data 
structure.

> BTW: I think that Hoare's Communicating Sequential Processes (CSP)
> basically describes the idea of active objects but without objects.
> That is, I think active objects is CSP applied to OO.

Or to put it another way, applying OO to CSP is a matter of hiding the 
addressing and sending of messages behind method calls. It becomes almost like 
doing in-process remote procedure calls.

I think there's a definite synergy with PEP 342 here as well - one of the 
problems with handling Active Objects is how to allow other messages to be 
processed while making a blocking call, without losing your current state. One 
way is to hold any state that persists between messages in the object itself, 
but that's a seriously unnatural style of programming (it can be done, it's 
just a pain).

PEP 342's yield expressions can probably be used to help address that problem, 
though:

   class SomeAO(ActiveObject):
 def processSomeMessage(self):
   msg = yield
   # Do something with the message
   next_msg = yield makeSomeBlockingCall(self)
   # Do something with the next message

Regards,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://boredomandlaziness.blogspot.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Active Objects in Python

2005-09-27 Thread Greg Ewing 
Nick Coghlan wrote:

> PEP 342's yield expressions can probably be used to help address that 
> problem, 
> though:
> 
>class SomeAO(ActiveObject):
>  def processSomeMessage(self):
>msg = yield
># Do something with the message
>next_msg = yield makeSomeBlockingCall(self)
># Do something with the next message

I don't see how that helps, since makeSomeBlockingCall()
is evaluated (and therefore blocks) *before* the yield
happens.

-- 
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | A citizen of NewZealandCorp, a   |
Christchurch, New Zealand  | wholly-owned subsidiary of USA Inc.  |
[EMAIL PROTECTED]  +--+
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Active Objects in Python

2005-09-27 Thread Christopher Armstrong 
On 9/28/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Nick Coghlan wrote:
>
> > PEP 342's yield expressions can probably be used to help address that 
> > problem,
> > though:
> >
> >class SomeAO(ActiveObject):
> >  def processSomeMessage(self):
> >msg = yield
> ># Do something with the message
> >next_msg = yield makeSomeBlockingCall(self)
> ># Do something with the next message
>
> I don't see how that helps, since makeSomeBlockingCall()
> is evaluated (and therefore blocks) *before* the yield
> happens.

Sounds like makeSomeBlockingCall is just misnamed (probably depending
who you ask).

I wrote a small library recently that wraps Twisted's Deferreds and
asynchronous Failure objects such that you can do stuff like

try:
 x = yield remoteObject.getSomething()
except Foo:
 print "Oh no!"

This is just a 2.5-ification of defgen, which is at
twisted.internet.defer.{deferredGenerator,waitForDeferred}. So anyway,
if your actor messages always return Deferreds, then this works quite
nicely.


--
  Twisted   |  Christopher Armstrong: International Man of Twistery
   Radix|-- http://radix.twistedmatrix.com
|  Release Manager, Twisted Project
  \\\V///   |-- http://twistedmatrix.com
   |o O||
wvw-+
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Active Objects in Python

2005-09-27 Thread Bruce Eckel 
Oops. I forgot to add that to the list. Yes, in the working example
of Active Objects that I've written in Java J2SE5, when you send a
message to an active object, you get back a Future, which
I suspect would be the same as your Deferred.

Tuesday, September 27, 2005, 7:41:27 PM, Christopher Armstrong wrote:

> On 9/28/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> Nick Coghlan wrote:
>>
>> > PEP 342's yield expressions can probably be used to help address that 
>> > problem,
>> > though:
>> >
>> >class SomeAO(ActiveObject):
>> >  def processSomeMessage(self):
>> >msg = yield
>> ># Do something with the message
>> >next_msg = yield makeSomeBlockingCall(self)
>> ># Do something with the next message
>>
>> I don't see how that helps, since makeSomeBlockingCall()
>> is evaluated (and therefore blocks) *before* the yield
>> happens.

> Sounds like makeSomeBlockingCall is just misnamed (probably depending
> who you ask).

> I wrote a small library recently that wraps Twisted's Deferreds and
> asynchronous Failure objects such that you can do stuff like

> try:
>  x = yield remoteObject.getSomething()
> except Foo:
>  print "Oh no!"

> This is just a 2.5-ification of defgen, which is at
> twisted.internet.defer.{deferredGenerator,waitForDeferred}. So anyway,
> if your actor messages always return Deferreds, then this works quite
> nicely.


> --
>   Twisted   |  Christopher Armstrong: International Man of Twistery
>Radix|-- http://radix.twistedmatrix.com
> |  Release Manager, Twisted Project
>   \\\V///   |-- http://twistedmatrix.com
>|o O||
> wvw-+
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/bruceeckel-python3234%40mailblocks.com


Bruce Eckelhttp://www.BruceEckel.com   mailto:[EMAIL PROTECTED]
Contains electronic books: "Thinking in Java 3e" & "Thinking in C++ 2e"
Web log: http://www.artima.com/weblogs/index.jsp?blogger=beckel
Subscribe to my newsletter:
http://www.mindview.net/Newsletter
My schedule can be found at:
http://www.mindview.net/Calendar



___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Python 2.4.2 documentation online

2005-09-27 Thread Fred L. Drake, Jr. 
The Python 2.4.2 documentation is now online in the main documentation area 
(as opposed to just the /dev/ area) for both www.python.org and 
docs.python.org.  The 2.4 and 2.4.1 documentation areas have been updated to 
link to the 2.4.2 documentation as the preferred documentation for all 2.4.x 
releases.


  -Fred

-- 
Fred L. Drake, Jr.   
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com