Hi Skip,
On 2007-03-12 03:01, [EMAIL PROTECTED] wrote:
I decided it would be worthwhile to have a csv module written in Python (no
C underpinnings) for a number of reasons:
* It will probably be easier to add Unicode support to a Python version
* More people will be able to
On Tue, Mar 13, 2007 at 04:55:07PM -0700, Guido van Rossum wrote:
What does that buy us?
subprocess offers better error-trapping, I think, and additional
features such as closing all file descriptors after forking. At work,
I found this fixed a number of bugs in our daemons code because if you
Guido van Rossum wrote:
What about reimplementing commands.* using subprocess? Or providing a
commands.*-compatible interface in the subprocess module?
What does that buy us?
multi-platform support? (commands is Unixoid only, right?)
/F
___
Alright already! It wasn't a thetorical question, and I'm convinced! :-)
On 3/14/07, Fredrik Lundh [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
What about reimplementing commands.* using subprocess? Or providing a
commands.*-compatible interface in the subprocess module?
What does
A couple of weeks ago, I posted a message titled thread safe SMTP
module on python-list. It's oddly split in the archive:
http://mail.python.org/pipermail/python-list/2007-March/429067.html
http://mail.python.org/pipermail/python-list/2007-March/429172.html
A while ago, I wrote an address
In addition to being made in the face of controversy and opposition, this
change is an alteration to *documented and tested* behavior and thus cannot
reasonably be considered a mere bug fix.
In addition to the prior behavior being explicitly documented in the
function docstrings, r54204 shows
Phillip J. Eby schrieb:
This backwards-incompatible change is therefore contrary to policy and
should be reverted, pending a proper transition plan for the change
(such as introduction of an alternative API and deprecation of the
existing one.)
I'm clearly opposed to this proposal, or else
Gordon Messmer [EMAIL PROTECTED] wrote:
After some discussion, Aahz suggested that I discuss the problem here,
on python-dev. He seemed to think that the problem I saw may have been
an indication of a bug in python. Could anyone take a look at that
thread and say whether it looks like a
On Wed, Mar 14, 2007, Jon Ribbens wrote:
Gordon Messmer [EMAIL PROTECTED] wrote:
After some discussion, Aahz suggested that I discuss the problem here,
on python-dev. He seemed to think that the problem I saw may have been
an indication of a bug in python. Could anyone take a look at that
Gordon Messmer [EMAIL PROTECTED] wrote:
After some discussion, Aahz suggested that I discuss the problem here,
on python-dev. He seemed to think that the problem I saw may have been
an indication of a bug in python. Could anyone take a look at that
thread and say whether it looks like a
Aahz [EMAIL PROTECTED] wrote:
One small wrinkle (and the reason I suggested bringing this to
python-dev): I suspect that the problem is not a bug, but simply the
occasional failure of sockets. When that happens in a threaded app
without timeouts, eventually threads die (block forever). But
Aahz wrote:
One small wrinkle (and the reason I suggested bringing this to
python-dev): I suspect that the problem is not a bug, but simply the
occasional failure of sockets. When that happens in a threaded app
without timeouts, eventually threads die (block forever).
IIRC, my whole
At 06:47 PM 3/14/2007 +0100, Martin v. Löwis wrote:
Phillip J. Eby schrieb:
This backwards-incompatible change is therefore contrary to policy and
should be reverted, pending a proper transition plan for the change
(such as introduction of an alternative API and deprecation of the
existing
Phillip J. Eby wrote:
At 06:47 PM 3/14/2007 +0100, Martin v. Löwis wrote:
Phillip J. Eby schrieb:
This backwards-incompatible change is therefore contrary to policy and
should be reverted, pending a proper transition plan for the change
(such as introduction of an alternative API
On 3/14/07, Michael Foord [EMAIL PROTECTED] wrote:
Phillip J. Eby wrote:
At 06:47 PM 3/14/2007 +0100, Martin v. Löwis wrote:
Phillip J. Eby schrieb:
This backwards-incompatible change is therefore contrary to policy and
should be reverted, pending a proper transition plan for the change
Phillip J. Eby wrote:
In addition to being made in the face of controversy and opposition,
this
change is an alteration to *documented and tested* behavior and thus
cannot reasonably be considered a mere bug fix.
FWIW, I support Phillip on this. There can be no question that the old
At 08:30 AM 3/15/2007 +1100, Delaney, Timothy (Tim) wrote:
Phillip J. Eby wrote:
In addition to being made in the face of controversy and opposition,
this
change is an alteration to *documented and tested* behavior and thus
cannot reasonably be considered a mere bug fix.
FWIW, I support
Delaney, Timothy (Tim) wrote:
Phillip J. Eby wrote:
In addition to being made in the face of controversy and opposition,
this
change is an alteration to *documented and tested* behavior and thus
cannot reasonably be considered a mere bug fix.
FWIW, I support Phillip on this.
Phillip J. Eby wrote:
At 08:30 AM 3/15/2007 +1100, Delaney, Timothy (Tim) wrote:
Phillip J. Eby wrote:
In addition to being made in the face of controversy and opposition,
this
change is an alteration to *documented and tested* behavior and thus
cannot reasonably be considered a
Michael Foord wrote:
There was code posted that used the (almost entirely sane) pattern :
new_filename = os.path.splitext(old_filename)[1] + '.bak'
That was broken but is now fixed. It follows the entirely natural
assumption that filename without an extension would not have the
filename
Delaney, Timothy (Tim) wrote:
[snip..]
Even the docstring only states that either part may be empty, hardly
documenting what is clearly a misfeature.
splitext(p)
Split the extension from a pathname.
Extension is everything from the last dot to the end.
Phillip J. Eby schrieb:
That much is obvious. But I haven't seen any explanation as to why
explicitly-documented and explicitly-tested behavior should be treated
as a bug in policy terms, just because people don't like the documented
and tested behavior.
It's not just that people disliked
On 3/14/07, Phillip J. Eby [EMAIL PROTECTED] wrote:
This backwards-incompatible change is therefore contrary to policy and
should be reverted, pending a proper transition plan for the change (such
as introduction of an alternative API and deprecation of the existing one.)
I think the original
Thomas Wouters schrieb:
However, changing documented, tested behaviour without warning gives
Python an even worse name. I agree with PJE that the change is the wrong
thing to do, simply because it sets (yet another) precedent. If
providing an alternate API with clearer semantics is too
Delaney, Timothy (Tim) schrieb:
A change to the documented behaviour should require a __future__
import for at least one version. That's even assuming that the change
is desireable (I don't believe so). We have multiple anecdotes of
actual, existing code that *will* break with this change. So
Martin v. Löwis wrote:
It's not just that people disliked the behavior. The majority of
those
that commented agreed that the current behavior is incorrect. Some
also
observed that the online documentation was underspecified, and indeed
allowed for that change. So this is a bug fix, even
At 10:54 PM 3/14/2007 +0100, Martin v. Löwis wrote:
Phillip J. Eby schrieb:
That much is obvious. But I haven't seen any explanation as to why
explicitly-documented and explicitly-tested behavior should be treated
as a bug in policy terms, just because people don't like the documented
and
Hi Martin,
On Wed, Mar 14, 2007 at 10:54:41PM +0100, Martin v. L?wis wrote:
So this is a bug fix, even though the old test
case explicitly tested for the presence of the bug
FWIW, when developing PyPy we found quite a number of tests in CPython
that were checking not just obscure
On 3/14/07, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 06:47 PM 3/14/2007 +0100, Martin v. Löwis wrote:
Phillip J. Eby schrieb:
This backwards-incompatible change is therefore contrary to policy and
should be reverted, pending a proper transition plan for the change
(such as
Gordon Messmer [EMAIL PROTECTED] wrote:
Tonight I should have time to pull an old copy of the code out of CVS
and recreate the test script that I used. Once I have, it should be a
matter of feeding a big list of email addresses to the script and
waiting a couple of minutes for the script
On 14 Mar, 05:08 pm, [EMAIL PROTECTED] wrote:
In addition to the prior behavior being explicitly documented in the
function docstrings, r54204 shows that it was also *tested* as behaving
that way by test_macpath, test_ntpath, and test_posixpath. When
combined
with the explicit docstrings,
On Thursday 15 March 2007 08:54, Martin v. Löwis wrote:
The bug fix may also break existing applications. Hence it cannot
go into 2.5.1 but has to wait for 2.6.
Steering clear of the rest of the discussion, I'd just like to give
a hearty +1 for this not going into 2.5.x in any way shape or
:) is that, when I go to the downloads page for Python 2.3, in
addition to downloading Python, I could download all the
compatible libraries which were included in later versions as a
single installable file. When 2.6 comes out, this extras
package would be upgraded to include any new
Anthony On Thursday 15 March 2007 08:54, Martin v. Löwis wrote:
The bug fix may also break existing applications. Hence it cannot go
into 2.5.1 but has to wait for 2.6.
Anthony Steering clear of the rest of the discussion, I'd just like to
Anthony give a hearty +1 for this
On 3/14/07, Anthony Baxter [EMAIL PROTECTED] wrote:
Steering clear of the rest of the discussion, I'd just like to give
a hearty +1 for this not going into 2.5.x in any way shape or
form.
Agreed. I'd further vote for keeping this change out until 3.x because
it is a behavior change in a corner
Hello Python-dev!
we have a document on PyPy's interpreter and translation
features that might be of interest to you - we target
it at language implementors in general: Includes
a discussion on our .NET and also the emerging Java
backends, as well as our RPython - Javascript webapp
generating
Michael Urman wrote:
Who would rather see os.path.dropext(path)?
I'd like to see such a function, and also
maybe replaceext(path, new_ext). I often
end up coding things like these myself,
since indexing the result of splitext all
the time is rather ugly.
To round off the set, I suggest
holger krekel [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
| We'd be very happy about feedback and opinions/questions
| (preferably until Monday, 19th March)
|
|
http://codespeak.net/pypy/extradoc/eu-report/D12.1_H-L-Backends_and_Feature_Prototypes-interim-2007-03-12.pdf
As of
Good, we have gotten around to discussing a little annoyance I've
noticed. I think this should behave similar to the way a Unix admin who
is familiar with basename(1) would behave:
$ basename -s .py
/tmp/foo.py
Phillip J. Eby schrieb:
And yet, that incorrect behavior was clearly intended by the author(s)
of the code, test, and docstrings.
As it happens, Guido wrote that code (16 years ago) and the docstring (9
years ago), in the case of the posixpath module at least.
I don't find it that clear
[EMAIL PROTECTED] schrieb:
This backwards-incompatible change is therefore contrary to policy and
should be reverted, pending a proper transition plan for the change (such
as introduction of an alternative API and deprecation of the existing
one.)
I hope that this is true, but *is* this
41 matches
Mail list logo
