* Phillip J. Eby <[EMAIL PROTECTED]> [2007-12-08 20:19:29 -0500]:
> At 07:55 PM 12/8/2007 -0500, Manuel Alejandro Cerón Estrada wrote:
> >2007/12/8, Greg Ewing <[EMAIL PROTECTED]>:
> > > I would put it the other way around -- the problem
> > > that 'yield break' is meant to solve is already solved
> "Josiah Carlson" <[EMAIL PROTECTED]> wrote:
> On Dec 5, 2007 9:19 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > The asyncore and asynchat modules are in a difficult position when it
> > comes to Python 3000. None of the core developers use it or
> > particularly care about it (AFAIK), and t
On Dec 8, 2007 6:54 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Dec 8, 2007 5:30 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > On Dec 8, 2007 5:21 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > Hm... Does this mean you're *always* creating an extra thread to handle
> > > signals?
>
On Dec 8, 2007 5:30 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On Dec 8, 2007 5:21 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Hm... Does this mean you're *always* creating an extra thread to handle
> > signals?
>
> Yup, Py_Initialize will do it.
That's unacceptable. It must be possible
Probably. Have you tried it?
On Dec 5, 2007 1:41 AM, Meerovich, Demitry <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> Hello,
>
>
>
> Does python25 supports on the "Windows 2003 Enterprise Server OS" ?
>
>
>
> Thanks
>
>
>
> Meerovich Dima,
>
> Software
>
> Intel
>
>
On Dec 8, 2007 6:30 PM, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> On 09/12/2007, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Gustavo, at some point you suggested making changes to Python so that
> > all signals are blocked in all threads except for the main thread. I
> > think I'd be more i
On 09/12/2007, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On Dec 8, 2007 3:57 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> >
> > On Dec 8, 2007 4:28 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > >
> > > On Dec 8, 2007 2:36 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > > > On Dec 8, 2007 2
On Dec 8, 2007 5:21 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On Dec 8, 2007 3:57 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> >
> > On Dec 8, 2007 4:28 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > >
> > > On Dec 8, 2007 2:36 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > > > On Dec
At 07:55 PM 12/8/2007 -0500, Manuel Alejandro Cerón Estrada wrote:
>2007/12/8, Greg Ewing <[EMAIL PROTECTED]>:
> > I would put it the other way around -- the problem
> > that 'yield break' is meant to solve is already solved
> > by 'return'. So there's no need for change.
>
>I have been re-thinking
Python 3.0 will dispense with the rarely used, but occasionally
indispensible, bsddb185 module. I extracted the source code and unit tests
from the current Python trunk, wrote a setup.py, made a couple slight mods
so it would build and pass tests under both Python 2.6 and 3.0. It's
available fro
2007/12/8, Greg Ewing <[EMAIL PROTECTED]>:
> I would put it the other way around -- the problem
> that 'yield break' is meant to solve is already solved
> by 'return'. So there's no need for change.
I have been re-thinking the problem and this is true. The only
exception would be empty generators,
On Dec 8, 2007 3:57 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
>
> On Dec 8, 2007 4:28 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >
> > On Dec 8, 2007 2:36 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > > On Dec 8, 2007 2:56 PM, <[EMAIL PROTECTED]> wrote:
> > > > On 05:20 pm, [EMAIL PROTECTED
Manuel Alejandro Cerón Estrada wrote:
> Acording to PEP 255:
>
> Note that return isn't always equivalent to raising StopIteration: the
> difference lies in how enclosing try/except constructs are treated.
All that means is that
def g():
try:
if 0:
yield
At 12:30 PM 12/9/2007 +1300, Greg Ewing wrote:
>Terry Reedy wrote:
> > I would prefer plain 'yield' to 'yield break' as a synonym for 'raise
> > StopIteration'.
>
>Don't we already have a plain yield these days meaning
>something else?
Yes. It's equivalent to 'yield None'.
_
On Dec 8, 2007 4:28 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On Dec 8, 2007 2:36 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > On Dec 8, 2007 2:56 PM, <[EMAIL PROTECTED]> wrote:
> > > On 05:20 pm, [EMAIL PROTECTED] wrote:
> > > >The best solution I can think of is to add a new API that
Manuel Alejandro Cerón Estrada wrote:
> The real problem is that
> raising StopIteration is not orthogonal.
This is a non-problem as far as I can see. In a generator,
the way to stop the iteration is simply to return. In a
non-generator iterator, you're still going to have to
raise StopIteration.
> 2007/12/8, Raymond Hettinger <[EMAIL PROTECTED]>:
>>...the proposal adds new syntax without adding functionality.
>
> That is indeed the definition of syntactic sugar [1]. Python is full
> of that, for example the import statement.
. . .
> The real problem is that
> raising StopIteration is not
Terry Reedy wrote:
> I would prefer plain 'yield' to 'yield break' as a synonym for 'raise
> StopIteration'.
Don't we already have a plain yield these days meaning
something else?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.p
Guido van Rossum wrote:
> Does Unix even promise that a signal gets delivered twice if it gets
> sent quickly twice in a row?
No, it doesn't.
However, this doesn't necessarily mean that you can just
drop them when the pipe becomes full. If more than one
type of signal is sharing a pipe, you don'
On Dec 8, 2007 2:36 PM, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On Dec 8, 2007 2:56 PM, <[EMAIL PROTECTED]> wrote:
> > On 05:20 pm, [EMAIL PROTECTED] wrote:
> > >The best solution I can think of is to add a new API that takes a
> > >signal and a file descriptor and registers a C-level handler for
On Dec 8, 2007 2:56 PM, <[EMAIL PROTECTED]> wrote:
> On 05:20 pm, [EMAIL PROTECTED] wrote:
> >The best solution I can think of is to add a new API that takes a
> >signal and a file descriptor and registers a C-level handler for that
> >signal which writes a byte to the file descriptor. You can the
Guido van Rossum wrote:
> On Dec 8, 2007 9:55 AM, Johan Dahlin <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>>> On Dec 8, 2007 2:17 AM, Johan Dahlin <[EMAIL PROTECTED]> wrote:
Guido van Rossum wrote:
> Adam, perhaps at some point (Monday?) we could get together on
> #python-de
Guido van Rossum wrote:
> On Dec 8, 2007 2:17 AM, Johan Dahlin <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>>> Adam, perhaps at some point (Monday?) we could get together on
>>> #python-dev and interact in real time on this issue. Probably even
>>> better on the phone. This offer is open
Guido,
These modules provide the server component of many existing versions of the
Zope system where they have served well (pun intended).I would be
concerned were they disappear in Python 3000.
On Dec 5, 2007 10:19 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> The asyncore and asynchat
On Dec 5, 2007 9:19 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> The asyncore and asynchat modules are in a difficult position when it
> comes to Python 3000. None of the core developers use it or
> particularly care about it (AFAIK), and the API has problems because
> it wasn't written to dea
Hello,
Does python25 supports on the "Windows 2003 Enterprise Server OS" ?
Thanks
Meerovich Dima,
Software
Intel
-
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
t
Hello,
Does python25 supports on the "Windows 2003 Enterprise Server OS" ?
Thanks
Meerovich Dima,
Software
Intel
-
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
t
> An interesting question has come up in the development of the
> SSL module.
>
> The function ssl.wrap_socket() takes a flag,
> do_handshake_on_connect, which tells it whether to do the SSL
> handshake before returning an SSLSocket object to the caller.
> If the socket being wrapped is non-b
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
2007/12/8, Raymond Hettinger <[EMAIL PROTECTED]>:
> In your example, why do you "raise StopIteration" instead just writing
> "return"?
In the example would be better to use 'return' rather than 'raise
StopIteration'. In most cases 'return' will have the same behavior
than 'raise StopIteration', b
Manuel Alejandro Cerón Estrada wrote:
> 2007/12/8, Raymond Hettinger <[EMAIL PROTECTED]>:
>> ...the proposal adds new syntax without adding functionality.
>
> That is indeed the definition of syntactic sugar [1]. Python is full
> of that, for example the import statement.
>
> 2007/12/8, Paul Sven
On 05:20 pm, [EMAIL PROTECTED] wrote:
>The best solution I can think of is to add a new API that takes a
>signal and a file descriptor and registers a C-level handler for that
>signal which writes a byte to the file descriptor. You can then create
>a pipe, connect the signal handler to the write en
On Dec 8, 2007 1:38 PM, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> On 08/12/2007, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On Dec 8, 2007 9:57 AM, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> > > Which is the best solution? I think my patch fixes two problems: 1. the
> > > need to have
In your example, why do you "raise StopIteration" instead just writing "return"?
- Original Message -
From: "Manuel Alejandro Cerón Estrada" <[EMAIL PROTECTED]>
Take a look at this example:
def lines():
for line in my_file:
if some_error():
raise StopIteration()
2007/12/8, Raymond Hettinger <[EMAIL PROTECTED]>:
>...the proposal adds new syntax without adding functionality.
That is indeed the definition of syntactic sugar [1]. Python is full
of that, for example the import statement.
2007/12/8, Paul Svensson <[EMAIL PROTECTED]>:
> What is the problem that
I would prefer plain 'yield' to 'yield break' as a synonym for 'raise
StopIteration'.
But the raise stands out better visually as an exit point.
The point about the raise not being explicitly caught is not valid since
any generator could be used in the following code
g = some_gen
try:
while
On 08/12/2007, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On Dec 8, 2007 9:57 AM, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> > On 08/12/2007, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >
> > > On Dec 8, 2007 3:58 AM, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> > > > Not only that, but
On 12/8/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On Dec 8, 2007 9:55 AM, Johan Dahlin <[EMAIL PROTECTED]> wrote:
> > Guido van Rossum wrote:
>
> > > Hm. How about making that an option? I don't think on the OLPC XO this
> > > is a valid use case (end users never have a console where they
On Dec 8, 2007 9:57 AM, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> On 08/12/2007, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> > On Dec 8, 2007 3:58 AM, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> > > Not only that, but pygtk is a generic module;
> >
> > What does "generic" mean in this con
On Dec 8, 2007 9:55 AM, Johan Dahlin <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > On Dec 8, 2007 2:17 AM, Johan Dahlin <[EMAIL PROTECTED]> wrote:
> >> Guido van Rossum wrote:
> >>> Adam, perhaps at some point (Monday?) we could get together on
> >>> #python-dev and interact in real time
> Note that 'yield break' resembles the 'break' statement used in loops,
> while 'StopIteration' doesn't. 'yield break' is more orthogonal to the
> rest of the language.
>
> I am looking forward to seeing your opinions.
-1
I do not find the meaning to be transparent and the proposal adds new synt
Hello Python developers.
This is my first post on the list. I have been using Python for a
while and I have been thinking about one feature I would like to see
integrated into the language. I thought it could be a good topic for a
PEP, so I decided to join the list and write about it.
First probl
On 08/12/2007, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On Dec 8, 2007 9:20 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > The
> > handler must be written in C in order to avoid the race condition
> > referred to by Glyph (signals arriving after the signal check in the
> > VM main loop
> """
> According to [1], all python needs to do to avoid this problem is
> block all signals in all but the main thread; then we can guarantee
> signal handlers are always called from the main thread, and pygtk
> doesn't need a timeout.
>
> [1] https://bugzilla.redhat.com/bugzilla/process_bug.cgi
On 08/12/2007, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On Dec 8, 2007 3:58 AM, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> > Not only that, but pygtk is a generic module;
>
> What does "generic" mean in this context? Surely not that it applies
> to other libraries than GTK?
Well, actual
At 11:17 AM +0100 12/8/07, Johan Dahlin wrote:
>Guido van Rossum wrote:
>> Adam, perhaps at some point (Monday?) we could get together on
>> #python-dev and interact in real time on this issue. Probably even
>> better on the phone. This offer is open to anyone who is serious about
>> getting this r
At 2:01 AM -0800 12/8/07, Guido van Rossum wrote:
...
>I'm curious -- is there anyone here who understands why [Py]GTK is
>using signals anyway? It's not like writing robust signal handling
>code in C is at all easy or obvious. If instead of a signal a file
>descriptor could be used, all problems
On Dec 8, 2007 9:20 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> The
> handler must be written in C in order to avoid the race condition
> referred to by Glyph (signals arriving after the signal check in the
> VM main loop but before the select()/poll() system call is entered
> will not be not
On Dec 8, 2007 3:58 AM, Gustavo Carneiro <[EMAIL PROTECTED]> wrote:
> Not only that, but pygtk is a generic module;
What does "generic" mean in this context? Surely not that it applies
to other libraries than GTK?
> who are we to forbid the usage
> of signals if python itself allows it? If we we
On Dec 8, 2007 2:17 AM, Johan Dahlin <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Adam, perhaps at some point (Monday?) we could get together on
> > #python-dev and interact in real time on this issue. Probably even
> > better on the phone. This offer is open to anyone who is serious ab
Guido> I think I've seen this too when running the bsddb3 unittest. I
Guido> think it's caused by a previous test ending badly and leaving
Guido> junk behind that the test suite doesn't properly remove before
Guido> starting. But I don't recall the details.
skip> Thanks, that
On 08/12/2007, Johan Dahlin <[EMAIL PROTECTED]> wrote:
>
> Guido van Rossum wrote:
> > Adam, perhaps at some point (Monday?) we could get together on
> > #python-dev and interact in real time on this issue. Probably even
> > better on the phone. This offer is open to anyone who is serious about
> >
Giampaolo Rodola' schrieb:
> O.T. - I noticed that the PEP-3 still refers to the old sourceforge
> bug tracker. Shouldn't it be rewritten?
Yes, thanks! I did a minimal change, but still someone could elaborate
it, describing current practices.
Georg
--
Thus spake the Lord: Thou shalt indent wit
Guido van Rossum wrote:
> Adam, perhaps at some point (Monday?) we could get together on
> #python-dev and interact in real time on this issue. Probably even
> better on the phone. This offer is open to anyone who is serious about
> getting this resolved. Someone please take it -- I'm offering free
Adam, perhaps at some point (Monday?) we could get together on
#python-dev and interact in real time on this issue. Probably even
better on the phone. This offer is open to anyone who is serious about
getting this resolved. Someone please take it -- I'm offering free
consulting here!
I'm curious -
Facundo Batista wrote:
> 2007/11/1, Facundo Batista <[EMAIL PROTECTED]>:
>
>>> I think the keyword and keywords interface can be improved. Do you have
>>> any plans in that direction?
>> Surely!
>>
>> But, no, I have no plans to do it, as I can not make cgi scripts in my
>> hosting, so these pa
56 matches
Mail list logo
