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
> 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 t
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.
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).
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 r
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 provi
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
Unsubscri
[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.pa
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
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, mti
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>
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
>tech
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.
[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
[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
> =
[EMAIL PROTECTED]
>> 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 scantools.py
>> Log Message:
>>
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.datet
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 sca
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 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 fi
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
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 m
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 i
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:
str.
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
[me]
> > (c) The right place to do the overflow checks is in the API wrappers,
> > not in the integer types.
[Keith Dart]
> That would be the "traditional" method.
>
> I was trying to keep it an object-oriented API. What should "know" the
> overflow condition is the type object itself. It raises
On 23-jun-2005, at 21:05, Robert W. Johnstone wrote:
> Hello,
>
> I'm trying to develop an extension module in C, but am having some
> difficulties. I thought about posting to the general python mailling
> list, but since it has to do with the C API I figured this was the
> correct
> location.
Hello,
I'm trying to develop an extension module in C, but am having some
difficulties. I thought about posting to the general python mailling
list, but since it has to do with the C API I figured this was the correct
location.
My difficulty lies with subclassing a class provided by another exte
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
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:
http://mail.python.org/mailman/options/pyt
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.
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]. I'm
32 matches
Mail list logo
