There are some very serious problems with threads today. Events are
often proposed as a solution to these problems, but they have their own
issues. A detailed analysis of the two options and some solutions
(most of which are used in my proposal) can be found in Why Events Are
A Bad Idea [0].
On 26-jun-2005, at 11:34, Adam Olsen wrote:
To resolve these problems I propose adding lightweight cooperative
threads to Python. They can be built around a Frame object,
suspending
and resuming like generators do.
That much is quite easy. Avoiding the C stack is a bit harder.
Also look at greenlets, they are in the py lib http://codespeak.net/py
Regards,
Florian Schulze
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On 6/26/05, Ronald Oussoren [EMAIL PROTECTED] wrote:
Have a look at stackless python. http://www.stackless.com/
On 6/26/05, Florian Schulze [EMAIL PROTECTED] wrote:
Also look at greenlets, they are in the py lib http://codespeak.net/py
While internally Stackless and Greenlets may (or may not)
At 05:04 AM 6/26/2005 -0600, Adam Olsen wrote:
On 6/26/05, Ronald Oussoren [EMAIL PROTECTED] wrote:
Have a look at stackless python. http://www.stackless.com/
On 6/26/05, Florian Schulze [EMAIL PROTECTED] wrote:
Also look at greenlets, they are in the py lib http://codespeak.net/py
While
Hi,
while bugs and patches are sometimes tricky to close, RFE can be very easy
to decide whether to implement in the first place. So what about working a
bit on this front? Here are several RFE reviewed, perhaps some can be
closed (should is always from submitter's point of view):
1193128:
At 06:57 PM 6/26/2005 +0200, Reinhold Birkenfeld wrote:
1226256:
The path module by Jason Orendorff should be in the standard library.
http://www.jorendorff.com/articles/python/path/
Review: the module is great and seems to have a large user base. On c.l.py
there are frequent praises about it.
I
On 6/26/05, Adam Olsen [EMAIL PROTECTED] wrote:
...
To resolve these problems I propose adding lightweight cooperative
threads to Python.
Speaking of lightweight cooperative threads - has anyone recently
tried to build Python with the pth option? It doesn't quite work out
of the box. How much
Phillip J. Eby wrote:
At 06:57 PM 6/26/2005 +0200, Reinhold Birkenfeld wrote:
1226256:
The path module by Jason Orendorff should be in the standard library.
http://www.jorendorff.com/articles/python/path/
Review: the module is great and seems to have a large user base. On c.l.py
there are
On Sun, 26 Jun 2005, Phillip J. Eby wrote:
* drop getcwd(); it makes no sense on a path instance
Personally I use path.getcwd() as a class method all the time. It
makes as much sense as fromkeys() does on a dict instance, which is
technically possible but non-sensical.
And, assuming these
Phillip It has many ways to do the same thing, and many of its property
Phillip and method names are confusing because they either do the same
Phillip thing as a standard function, but have a different name (like
Phillip the 'parent' property that is os.path.dirname in disguise),
On 24-jun-2005, at 21:46, [EMAIL PROTECTED] wrote:
Update of /cvsroot/python/python/dist/src/Tools/bgen/bgen
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv18095/Tools/
bgen/bgen
Modified Files:
bgenGenerator.py bgenObjectDefinition.py bgenType.py
bgenVariable.py
Phillip J. Eby wrote:
[...]
I'm also not keen on the fact that it makes certain things
properties whose value can change over time; i.e. ctime/mtime/atime
and
size really shouldn't be properties, but rather methods.
I think ctime, mtime and atime should be (or return)
datetime.datetime
[EMAIL PROTECTED]
Update of /cvsroot/python/python/dist/src/Lib
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4891/Lib
Modified Files:
Cookie.py
Log Message:
bug [ 1108948 ] Cookie.py produces invalid code
Index: Cookie.py
[Reinhold Birkenfeld]
One more issue is open: the one of naming. As path is already the
name of a module, what would the new object be called to avoid
confusion? pathobj? objpath? Path?
[Michael Hoffman]
I would argue for Path.
Granted path is actually os.path, but I don't think it's wise
At 09:00 PM 6/26/2005 +0200, Reinhold Birkenfeld wrote:
One more issue is open: the one of naming. As path is already the name of
a module, what would the new object be called to avoid confusion? pathobj?
objpath? Path?
I was thinking os.Path, myself.
At 08:19 PM 6/26/2005 +0100, Michael Hoffman wrote:
On Sun, 26 Jun 2005, Phillip J. Eby wrote:
* drop getcwd(); it makes no sense on a path instance
Personally I use path.getcwd() as a class method all the time. It
makes as much sense as fromkeys() does on a dict instance, which is
technically
At 02:31 PM 6/26/2005 -0500, Skip Montanaro wrote:
Phillip It has many ways to do the same thing, and many of its property
Phillip and method names are confusing because they either do the same
Phillip thing as a standard function, but have a different name (like
Phillip the
At 12:22 AM 6/27/2005 +0200, Dörwald Walter wrote:
Phillip J. Eby wrote:
[...]
I'm also not keen on the fact that it makes certain things
properties whose value can change over time; i.e. ctime/mtime/atime
and
size really shouldn't be properties, but rather methods.
I think ctime, mtime and atime
At 12:08 PM 6/27/2005 +1200, Tony Meyer wrote:
[Reinhold Birkenfeld]
One more issue is open: the one of naming. As path is already the
name of a module, what would the new object be called to avoid
confusion? pathobj? objpath? Path?
[Michael Hoffman]
I would argue for Path.
Granted path
[Reinhold Birkenfeld]
One more issue is open: the one of naming. As path is already
the name of a module, what would the new object be called to
avoid confusion? pathobj? objpath? Path?
[Michael Hoffman]
I would argue for Path.
[Tony Meyer
Granted path is actually os.path, but I don't
Walter I think ctime, mtime and atime should be (or return)
Walter datetime.datetime objects instead of integer timestamps.
+1
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Phillip ... but have a different name (like the 'parent' property that
Phillip is os.path.dirname in disguise) ...
Phillip ... (like the 'listdir()' method that returns full paths rather
Phillip than just filenames).
Skip To the extent that the path module tries to provide a
On Jun 26, 2005, at 8:54 PM, Phillip J. Eby wrote:
At 12:22 AM 6/27/2005 +0200, Dörwald Walter wrote:
Phillip J. Eby wrote:
[...]
I'm also not keen on the fact that it makes certain things
properties whose value can change over time; i.e. ctime/mtime/atime
and
size really shouldn't be
At 08:29 PM 6/26/2005 -0500, Skip Montanaro wrote:
Phillip ... but have a different name (like the 'parent' property that
Phillip is os.path.dirname in disguise) ...
Phillip ... (like the 'listdir()' method that returns full paths rather
Phillip than just filenames).
At 09:26 PM 6/26/2005 -0400, Bob Ippolito wrote:
On Jun 26, 2005, at 8:54 PM, Phillip J. Eby wrote:
At 12:22 AM 6/27/2005 +0200, Dörwald Walter wrote:
Phillip J. Eby wrote:
I'm also not keen on the fact that it makes certain things
properties whose value can change over time; i.e.
1193128:
str.translate(None, delchars) should be allowed and only delete
delchars
from the string.
I had agreed to this one and it's on my todo list to implement.
1214675:
warnings should get a removefilter() method. An alternative would be
to
fully document the filters attribute to allow
Tim Peters wrote:
[EMAIL PROTECTED]
Update of /cvsroot/python/python/dist/src/Lib
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4891/Lib
Modified Files:
Cookie.py
Log Message:
bug [ 1108948 ] Cookie.py produces invalid code
[...]
I assume this accounts for the current
28 matches
Mail list logo
