On 2007-03-15 07:45, Martin v. Löwis wrote:
> 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
[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 *
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 c
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
"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
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
pat
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
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
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" f
> :) 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
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
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, this
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 scr
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 a
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 implementa
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
"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 fi
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.
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 '
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 origi
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 dis
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.
> ^^^
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
> fi
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 reasonabl
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 Philli
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,
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
beh
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
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 alte
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
> >
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
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).
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 li
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 lo
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 lik
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 e
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 t
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 val
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?
> >
>
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?)
_
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
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 r
42 matches
Mail list logo
