[EMAIL PROTECTED] schrieb:
> The real issue I have here is one of process. Why is it that PJE (or
> any python user who wishes their code to keep working against new
> versions of Python) must frequent python-dev and convince you (or
> whatever Python developer might be committing a patch) of e
I recommend not setting these variables at all, or to use wrapper
scripts that set them instead. But there's probably some reason why
you can't do that...
On 3/8/07, Anthony Baxter <[EMAIL PROTECTED]> wrote:
> What do people think about the idea of a version-specific PYTHONPATH
> environment varia
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
My understanding of the current backwards-compatibility policy for
Python, the one that Twisted has been trying to emulate strictly, is
that, for each potentially incompatible change, there will be:
* at least
What do people think about the idea of a version-specific PYTHONPATH
environment variable? Something like PYTHON25PATH or the like.
Reason I ask is that on our production systems, we have a couple of
versions of Python being used by different systems. Yes, yes, in a
perfect world they'd be all
At 2:16 PM -0500 3/8/07, Phillip J. Eby wrote:
>At 11:53 AM 3/8/2007 +0100, Martin v. Löwis wrote:
>>That assumes there is a need for the old functionality. I really don't
>>see it (pje claimed he needed it once, but I remain unconvinced, not
>>having seen an actual fragment where the old behavior
[EMAIL PROTECTED] wrote:
>
> In the past I've begged off of actually writing PEPs because I don't
> have the time, but if there is interest in codifying this I think I
> don't have the time *not* to write it. I'd prefer to document the
> pending/deprecate/remove policy first, but I can write u
On 3/8/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Buildbot has a "build this branch" feature which could be used to settle
> these discussions more rapidly, except for the fact that the community
> builders are currently in pretty sad shape:
>
> http://www.python.org/dev/buildbot/commu
I'm a long-term lurker and Python coder, and although I've never really
contributed much to the list, I do make a point to keep up on it so I'm
prepared at least when changes come through. This thread's gone on forever,
so I thought I'd offer my opinion :) Mwha.
Ahem.
First of all, I think the c
On 8 Mar, 06:02 pm, [EMAIL PROTECTED] wrote:
On Thu, Mar 08, 2007 at 06:54:30PM +0100, "Martin v. L?wis" wrote:
back_name = splitext(name[0]) + '.bak'
back_name = splitext(name)[0] + '.bak'
This is really totally secondary to the point I actually care about, but
seeing this antipatter
[EMAIL PROTECTED] wrote:
That assumes there is a need for the old functionality. I really don't
see it (pje claimed he needed it once, but I remain unconvinced, not
having seen an actual fragment where the old behavior is helpful).
This passage is symptomatic of the thing that really bothers me
Collin Winter schrieb:
> Was any course of action ever decided on for this issue, or was the
> consensus that it would break too much code? If the latter, what about
> making the change for Python 3000?
Neither, nor. If a grand renaming is not feasible, I'd atleast do
something about object.h for
I studied Skip patch, and I think he is in good direction: add a
NetworkConnection object to socket.py, and then use it from the other
modules.
This NetworkConnection basically does what all the other modules do
once and again, so no mistery about it (basically calls getaddrinfo
over the receive
On 1/3/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On 1/3/07, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> >
> >
> > On 1/3/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > On 1/3/07, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> > > > On Wednesday 03 January 2007 11:06, Martin v. Löwis wro
On 3/8/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 3/8/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> > Now that unittest has a test suite, it would seem to make sense that
> > it should be fairly high up in the testing order, since most of the
> > regression suite depends on it. I'd like to h
At 11:53 AM 3/8/2007 +0100, Martin v. Löwis wrote:
>That assumes there is a need for the old functionality. I really don't
>see it (pje claimed he needed it once, but I remain unconvinced, not
>having seen an actual fragment where the old behavior is helpful).
The code in question was a type assoc
On 3/8/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> Now that unittest has a test suite, it would seem to make sense that
> it should be fairly high up in the testing order, since most of the
> regression suite depends on it. I'd like to have it included with
> test_grammar, test_opcodes, test_ope
Now that unittest has a test suite, it would seem to make sense that
it should be fairly high up in the testing order, since most of the
regression suite depends on it. I'd like to have it included with
test_grammar, test_opcodes, test_operations, etc, so that if a bug in
unittest is causing other
Alexey Borzenkov schrieb:
> I don't understand only one thing, why do people need new functions?
> You can anticipate the change today, and write functions that do
> exactly what you need no matter which way (current or proposed) python
> implements:
Indeed, that's also true. When people actually
On 3/8/07, Alexey Borzenkov <[EMAIL PROTECTED]> wrote:
> On 3/7/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > > Now it's becoming difficult: several people in favor, some opposed...
> > What about changing the semantics of splitext and creating a
On Thu, Mar 08, 2007 at 06:54:30PM +0100, "Martin v. L?wis" wrote:
> back_name = splitext(name[0]) + '.bak'
back_name = splitext(name)[0] + '.bak'
Oleg.
--
Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
Programmers don't die, they just GOSUB without
Scott David Daniels schrieb:
> c) Given a filename, make an appropriately named associated file.
> pyo_name = os.path.splitext(name)[0] + '.pyo'
> This argues for os.path.splitext('.pythonrc') == ('.pythonrc','')
Indeed, somebody found that people apparently do
back_name = spl
On 3/7/07, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Now it's becoming difficult: several people in favor, some opposed...
> What about changing the semantics of splitext and creating a new
> function (available on all platforms) that does what the
Martin v. Löwis wrote:
> Phillip J. Eby schrieb:
>> I consider it correct, or at the least, don't think it should be
>> changed, as it would make the behavior more difficult to reason about
>> and introduce yet another thing to worry about when writing
>> cross-version code.
>
> Now it's becomi
BJörn Lindqvist schrieb:
> (This might be a silly question..)
>
> In the dev stdlib reference there are lots of pages in which all text
> is in italics. Such as all chapters after chapter 18.
Certainly not. In today's copy (8.3.07, 13:30 GMT), this starts
between 18.17 and 18.17.1. However, look
(This might be a silly question..)
In the dev stdlib reference there are lots of pages in which all text
is in italics. Such as all chapters after chapter 18. Is it supposed
to be that way? It looks quite ugly.
--
mvh Björn
___
Python-Dev mailing list
Martin v. Löwis wrote:
>> - How can I know if a patch is still open?
>
> Easy: if it's marked as Open.
>
>> - I found a problem, and know how to fix it, but what else need to do?
>
> Go to www.python.org, then "CORE DEVELOPMENT", then "Patch submission".
>
>> - Found a problem in the docs, for thi
On 08/03/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Titus Brown schrieb:
> > and it's not at all clear to outsiders like me how new
> > features, old patches, and old bugs are dealt with.
>
> The simple answer is "when we have time". There really is not
> more to it. Some patches get high
Josiah Carlson schrieb:
> Because we should refuse the temptation to guess, what about:
>
> Rename the posix splitext to X (for some X), and offer a function with
> identical functionality to the posix variant under win32, also available
> as X for that platform.
>
> Rename the (current) win32 sp
Giovanni Bajo schrieb:
I can't see that the barrier at contributing is high.
>>>
>>> I think this says it all. It now appears obvious to me that people
>>> inside the "mafia" don't even realize there is one. Thus, it looks
>>> like we are all wasting time in this thread, since they think th
Andrew Bennetts schrieb:
> Glyph's proposing that rather than risk breaking existing code (and in the
> worst
> possible way: silently, giving wrong answers rather than exceptions), we
> examine
> what benefits changing splitext would bring, and see if there's a way to get
> those benefits withou
Josiah Carlson writes:
> > And the best way to encourage someone to maintain a package is...
> > accepting their patches.
>
> And that's what I think is bull. Whether or not we want or need
> maintainers for module or package X is independant of the fact that user
> Y has submitted a patc
31 matches
Mail list logo
