On 3/15/07, Terry Reedy [EMAIL PROTECTED] wrote:
As to the usefulness of current behavior, the only supposed use-case code
posted, that I have noticed, was that it made it easy to turn '.emacs' into
'1.emacs', but then MK said the app does not really do that.
I said the name .emacs was used
Josiah Carlson wrote:
Greg Ewing [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Can you suggest any use-cases for thread termination which will *not*
result in a completely broken and unpredictable heap after the thread
has died?
Suppose you have a GUI and you want to launch a
On 16/03/2007 1.06, Greg Ewing wrote:
Can you suggest any use-cases for thread termination which will *not*
result in a completely broken and unpredictable heap after the thread
has died?
Suppose you have a GUI and you want to launch a
long-running computation without blocking the
user
On 16/03/07, Phillip J. Eby [EMAIL PROTECTED] wrote:
What's *actually* under dispute here is whether it's acceptable to classify
this perfectly useful-as-is behavior, that was documented and tested in
released versions of Python for several years (with patches to change its
behavior explicitly
On 3/14/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
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
On Thu, Mar 15, 2007 at 10:31:06PM +0100, Martin v. L?wis wrote:
I would do that, except that Andrew explicitly reserved the right to
change whatsnew.tex. I believe he does go over Misc/NEWS in doing so.
It's actually OK to add things to whatsnew.tex, subject to the warning that:
1) I will
Phillip J. Eby schrieb:
Some other options:
1. Deprecate splitext() and remove it in 3.0
How would that help the problem? Isn't it useful to have a function
that strips off the extension?
2. Add an optional flag argument to enable the new behavior
How would that help backwards
Thomas Wouters schrieb:
Hah, everyone agree? They weren't agreeing when you changed it, either
:) But no, we don't add a warning *and* change the API. We add a warning
*about* changing the API. 2.6 sees no semantic change, just a warning
when os.path.splitext is used on a dotfile with no
Patrick Maupin schrieb:
The worst part is, if they are relying on that specific behavior and have
to rely on the new specific behavior, and want to support old and new
versions of Python, they are potentially left with some very unattractive
options -- check the Python version to figure out
A.M. Kuchling schrieb:
Where should I add a note about this: a comment at the top of
whatsnew.tex, maybe?
That would be good.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Martin v. Löwis wrote:
Phillip J. Eby schrieb:
Some other options:
1. Deprecate splitext() and remove it in 3.0
How would that help the problem? Isn't it useful to have a function
that strips off the extension?
2. Add an optional flag argument to enable the new behavior
How would
Martin v. Löwis wrote:
Patrick Maupin schrieb:
The worst part is, if they are relying on that specific behavior and have
to rely on the new specific behavior, and want to support old and new
versions of Python, they are potentially left with some very unattractive
options -- check the Python
At 01:31 PM 3/16/2007 +0100, Martin v. Löwis wrote:
Phillip J. Eby schrieb:
Some other options:
1. Deprecate splitext() and remove it in 3.0
How would that help the problem? Isn't it useful to have a function
that strips off the extension?
Not if there's no consensus as to what extension
At 01:47 AM 3/16/2007 -0400, Terry Reedy wrote:
I think it is a ludicrous comparison, not even in the same ballpark, that
tends to discredit the valid points you have made.
Of course it's not in the same ballpark. The point was to show how
ludicrous the *logic* is, by applying it to something
Phillip J. Eby wrote:
At 01:31 PM 3/16/2007 +0100, Martin v. Löwis wrote:
Phillip J. Eby schrieb:
2. Add an optional flag argument to enable the new behavior
How would that help backwards compatibility?
All existing calls to splitext() would work the same way they've done
for several
On 3/16/07, Titus Brown [EMAIL PROTECTED] wrote:
- What about reimplementing commands.* using subprocess? Or providing a
- commands.*-compatible interface in the subprocess module?
OK, so as I understand it, the next step would be for me to provide a
patch implementing this, right? Or is
On 3/16/07, Titus Brown [EMAIL PROTECTED] wrote:
- Yes. Another intermediate step might be to rewrite the commands module
- to call the new APIs in the subprocess module.
My preference would be to push people towards subprocess, and the more
capable complex API there, by deprecating commands
Steve Holden schrieb:
Somebody has pointed out that it is fairly easy to write a wrapper
around splitext that explicitly produces the old behavior on all
versions, or the new behavior on all versions, depending on what
precisely is desired. Users that have coded for a specific behavior
will
On 3/16/07, Nick Coghlan [EMAIL PROTECTED] wrote:
splitext(name, ignore_leading_dot=False, all_ext=False)
+1. ISTM this is a reasonable way to go in the face of our existing
backward compatibility issue and the differing definitions of
extensions across OS's.
Mike
On 3/16/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
If they pass the flag to the function, the code will stop running on
2.5 and earlier. This is worse than having code that works on all
versions. This is also whz I wondered how the flag helps backwards
compatibility: when people add the
Paul Moore writes:
On 16/03/07, Phillip J. Eby [EMAIL PROTECTED] wrote:
What's *actually* under dispute here is whether it's acceptable to classify
this perfectly useful-as-is behavior, that was documented and tested in
released versions of Python for several years (with patches to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 16, 2007, at 3:30 PM, Mike Krell wrote:
On 3/16/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
If they pass the flag to the function, the code will stop running on
2.5 and earlier. This is worse than having code that works on all
versions.
Mike Krell schrieb:
On 3/16/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
If they pass the flag to the function, the code will stop running on
2.5 and earlier. This is worse than having code that works on all
versions. This is also whz I wondered how the flag helps backwards
compatibility:
Nick Coghlan [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
That may actually be a genuinely useful approach:
splitext(name, ignore_leading_dot=False, all_ext=False)
Split the extension from a pathname. Returns (root, ext).
By default, the extension is all characters from the
On 03/16/2007 05:43 PM, Nick Coghlan wrote:
--
Sjoerd Mullender
Phillip J. Eby wrote:
At 01:31 PM 3/16/2007 +0100, Martin v. Löwis wrote:
Phillip J. Eby schrieb:
2. Add an optional flag argument to enable the new behavior
How would that help backwards compatibility?
All existing calls to
On 3/16/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
Assuming the current behavior is a bug (which I still believe to be
the case), in order to actually make use of the bug fix, you have to
pass the parameter. This will make your code break on old versions.
But, that's a GOOD thing. If you
Patrick Maupin schrieb:
On 3/16/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
Assuming the current behavior is a bug (which I still believe to be
the case), in order to actually make use of the bug fix, you have to
pass the parameter. This will make your code break on old versions.
But,
On 15 Mar, 11:34 pm, [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] schrieb:
However, the decision was a bad one regardless of the existing policy,
and sets a bad precedent while we are discussing this policy. I could
be wrong, but I think it would be reasonable to assume that if Martin
On 12:06 am, [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Can you suggest any use-cases for thread termination which will *not*
result in a completely broken and unpredictable heap after the thread
has died?
Suppose you have a GUI and you want to launch a
long-running computation
That may actually be a genuinely useful approach:
splitext(name, ignore_leading_dot=False, all_ext=False)
... that's perfect. I updated my patch to do it that way! :)
--S
___
Python-Dev mailing list
Python-Dev@python.org
Mike Krell wrote:
I said the name .emacs was used as an example. For that matter, the
name a.txt was also used as an example. The use cases are real.
So does your application create any file names
that have a single dot at the beginning?
--
Greg
On 3/16/07, Greg Ewing [EMAIL PROTECTED] wrote:
Mike Krell wrote:
I said the name .emacs was used as an example. For that matter, the
name a.txt was also used as an example. The use cases are real.
So does your application create any file names
that have a single dot at the beginning?
Hi all,
Forgive me for the off-topic post.
I'm looking for a topic for a masters thesis in the field of
(programming) language theory in Computer Science - in the timeframe
of 2-4 years.
To combine this with my love of Python, can anyone here suggest a
topic that would directly benefit Python
On Tue, Mar 13, 2007 at 02:16:21PM -0700, Guido van Rossum wrote:
- On 3/13/07, Georg Brandl [EMAIL PROTECTED] wrote:
- I'd like to deprecate commands.getstatus() in 2.6.
-
- Reason: there is getoutput() and getstatusoutput(). In the latter, status
- means the exit code. getstatus(), however,
On Tue, Mar 13, 2007 at 04:55:07PM -0700, Guido van Rossum wrote:
- On 3/13/07, Titus Brown [EMAIL PROTECTED] wrote:
- What about reimplementing commands.* using subprocess? Or providing a
- commands.*-compatible interface in the subprocess module?
-
- What does that buy us?
The simplicity of
Hi all,
I'm a grad student at UC Davis studying the python community and I
wanted to know if some on this list could help me out. I'm studying
the factors that affect people graduating from being mailing list
participant to developers with write access to the repository. Is it
possible to find
- What about reimplementing commands.* using subprocess? Or providing a
- commands.*-compatible interface in the subprocess module?
OK, so as I understand it, the next step would be for me to provide a
patch implementing this, right? Or is this PEP-required (please no...)?
What do people
On Fri, Mar 16, 2007 at 09:50:29AM -0700, Guido van Rossum wrote:
- What do people think of this basic interface?
-
- (status, output) = subprocess.get_status_output(cmd)
-
- output = subprocess.get_output(cmd)
-
- Here 'status' is the 'returncode' from subprocess.Popen, and
From: Facundo Batista [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
This patch was posted by koder_ua.
I think that Request must have a request type parameters, so people
can send HEAD requests easily.
But it seems to me that keeping a request history in the module is bad,
because it
Martin v. Löwis writes:
Phillip J. Eby schrieb:
Some other options:
1. Deprecate splitext() and remove it in 3.0
How would that help the problem? Isn't it useful to have a function
that strips off the extension?
No. It's useful to have a function that performs a
Mike Krell wrote:
On 3/16/07, Greg Ewing [EMAIL PROTECTED] wrote:
Mike Krell wrote:
I said the name .emacs was used as an example. For that matter, the
name a.txt was also used as an example. The use cases are real.
So does your application create any file names
that have a single dot at
On 3/16/07, Steve Holden [EMAIL PROTECTED] wrote:
Perhaps you'd like to remind me that backward compatibilty includes
the necessity to run new programs on old versions of Python, too?
Ahh, but you see, new programs are the easy part. You actually have
at least four choices of different levels
Patch / Bug Summary
___
Patches : 342 open (-38) / 3712 closed (+54) / 4054 total (+16)
Bugs: 951 open (-14) / 6588 closed (+33) / 7539 total (+19)
RFE : 257 open (-15) / 266 closed (+13) / 523 total ( -2)
New / Reopened Patches
__
43 matches
Mail list logo
