Benjamin Peterson schrieb:
svnmerge is written in Python, so wouldn't it be possible to add
support for maintaining such renaming to that tool ?
svnmerge.py is mostly a wrapper over svn merge, and svn merge can't
handle it, so I don't think is easily possible.
I don't think that an administr
On Mon, May 19, 2008 at 12:26 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On Mon, May 19, 2008 at 5:08 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>> On 2008-05-18 22:24, Brett Cannon wrote:
>>>
>>> On Sun, May 18, 2008 at 6:14 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
M.-A. Lemburg
Benjamin Peterson wrote:
On Mon, May 19, 2008 at 6:00 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
On Mon, May 19, 2008 at 5:46 PM, Graham Horler <[EMAIL PROTECTED]> wrote:
Hi all,
I created a patch on 2007-08-15:
http://bugs.python.org/issue1775025
I wonder, will it just stay in patches
Bill Janssen wrote:
On Mon, May 19, 2008 at 5:15 PM, Bill Janssen <[EMAIL PROTECTED]> wrote:
If you can run a pure Python module
that does not depend on any C extension, then that platform has the
support needed to run Python.
This is certainly a point of view. One that many end-users wouldn't
> On Mon, May 19, 2008 at 5:15 PM, Bill Janssen <[EMAIL PROTECTED]> wrote:
> >> If you can run a pure Python module
> >> that does not depend on any C extension, then that platform has the
> >> support needed to run Python.
> >
> > This is certainly a point of view. One that many end-users wouldn'
On Mon, May 19, 2008 at 5:15 PM, Bill Janssen <[EMAIL PROTECTED]> wrote:
>> If you can run a pure Python module
>> that does not depend on any C extension, then that platform has the
>> support needed to run Python.
>
> This is certainly a point of view. One that many end-users wouldn't
> understa
> If you can run a pure Python module
> that does not depend on any C extension, then that platform has the
> support needed to run Python.
This is certainly a point of view. One that many end-users wouldn't
understand :-).
Bill
___
Python-Dev mailing
On Sun, 18 May 2008 22:59:05 +, Dan Lenski wrote:
> So here's what I don't understand. Why doesn't the "t#" argument
> specifier support read-write buffers as well as read-only buffers?
> Aren't read-write buffers a *superset* of read-only buffers?? Is there
> something I'm doing wrong or a
On Mon, May 19, 2008 at 6:00 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> On Mon, May 19, 2008 at 5:46 PM, Graham Horler <[EMAIL PROTECTED]> wrote:
>> Hi all,
>>
>> I created a patch on 2007-08-15:
>> http://bugs.python.org/issue1775025
>>
>> I wonder, will it just stay in patches unnoticed
On Mon, May 19, 2008 at 5:46 PM, Graham Horler <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I created a patch on 2007-08-15:
> http://bugs.python.org/issue1775025
>
> I wonder, will it just stay in patches unnoticed until it has its very
> own associated bug report to keep it company?
At the moment,
On Mon, May 19, 2008 at 3:46 PM, Graham Horler <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I created a patch on 2007-08-15:
> http://bugs.python.org/issue1775025
>
> I wonder, will it just stay in patches unnoticed until it has its very
> own associated bug report to keep it company?
Being a patch d
On Mon, May 19, 2008 at 3:26 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> On Mon, May 19, 2008 at 7:08 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>> On 2008-05-18 22:24, Brett Cannon wrote:
>>>
>>> On Sun, May 18, 2008 at 6:14 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
M.-A. Lemb
Hi all,
I created a patch on 2007-08-15:
http://bugs.python.org/issue1775025
I wonder, will it just stay in patches unnoticed until it has its very
own associated bug report to keep it company?
Thanks,
Graham
___
Python-Dev mailing list
Python-Dev@py
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Trent Nelson wrote:
| I downloaded the source that includes AES encryption, for no reason
| other than it was first on the list. I'm now wondering if we should
| only be importing the 'NC' source that doesn't contain any
| encryption? Jesus, does py
On Mon, May 19, 2008 at 7:08 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2008-05-18 22:24, Brett Cannon wrote:
>>
>> On Sun, May 18, 2008 at 6:14 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>>>
>>> M.-A. Lemburg wrote:
Perhaps I have a misunderstanding of the reasoning behind
d
On Mon, May 19, 2008 at 08:50:39PM +0200, Thomas Heller wrote:
> Myself I would rather spend my energy to make ctypes more portable, within my
> skills and the platforms I have access to.
Someone could run Solaris x86 inside a hosted virtual machine and make
it available to the Python developers.
Yannick Gingras schrieb:
"Alexandre Vassalotti" <[EMAIL PROTECTED]> writes:
So now I am not sure what OP is proposing. Do you want to replace 21
with EISDIR in the above?
Yes, that's what I had in mind.
Then, check out EnvironmentError_str in Objects/exceptions.c. You
should be able impor
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> Have you considered whether this works on all platforms? (E.g.
> Windows, or embedded non-Unix-based.)
Yes but I guess I didn't comment it properly. The line
printed_errno = errno_str ? errno_str : self->myerrno;
ensures that we gracefully fal
On 2008-05-19 21:26, Brett Cannon wrote:
It is possible to make pickle aware of the module renames, but
that doesn't solve problems with other forms of serialization
or use of the .__module__ attribute in general.
Why can't we just provide a "from __future__ import renamed_modules"
which then pr
On Mon, May 19, 2008 at 2:03 AM, Ulrich Berning
<[EMAIL PROTECTED]> wrote:
> Gregory P. Smith wrote:
>
>> On Fri, May 16, 2008 at 1:32 AM, Ulrich Berning
>> <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> As long as the ctypes extension doesn't build on major Un*x platforms
>>> (AIX,
>>> HP-UX), I don't like
On Mon, May 19, 2008 at 5:08 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2008-05-18 22:24, Brett Cannon wrote:
>>
>> On Sun, May 18, 2008 at 6:14 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>>>
>>> M.-A. Lemburg wrote:
Perhaps I have a misunderstanding of the reasoning behind
d
On Mon, May 19, 2008 at 9:22 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Mon, May 19, 2008 at 8:39 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>>> Nick writes:
M.-A. Lemburg wrote:
> I don't think that an administrative problem such as forward-
> porting patches to
Bill Janssen schrieb:
>> Hmm, perhaps the ctypes documentation could use a more prominent warning
>> that it may not be available on some Unix platforms (HP-UX, AIX, IRIX),
>> and that it may require the use of GCC rather than the vendor compiler
>> on others (Solaris).
>>
>> At the moment, I s
On Sun, May 21, 2006 at 17:38:49 CEST, Guido van Rossum wrote
> ...
> Also, it would be a parsing conflict for the new conditional
> expressions (x if T else y).
> ...
That's all I needed to know.
Sorry, everyone, I'll try not to waste your time in the future.
___
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
A.M. Kuchling wrote:
| Python development doesn't seem to have any volunteers who use AIX or
| HP-UX and can fix bugs on these platforms. Searching bugs.python.org,
| I find about 20 open AIX issues, 4 or 5 HP-UX issues, 6 IRIX bugs, and
| about 15 S
> Hmm, perhaps the ctypes documentation could use a more prominent warning
> that it may not be available on some Unix platforms (HP-UX, AIX, IRIX),
> and that it may require the use of GCC rather than the vendor compiler
> on others (Solaris).
>
> At the moment, I suspect some projects may be
On Mon, May 19, 2008 at 8:39 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>> Nick writes:
>>>
>>> M.-A. Lemburg wrote:
>>> > I don't think that an administrative problem such as forward-
>>> > porting patches to 3.x warrants breakage in the 2.x branch.
>>> >
>>> > After all, the renaming was ap
On Mon, May 19, 2008 at 2:08 PM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Why can't we just provide a "from __future__ import renamed_modules"
> which then provides all the new name to old name mappings in
> some form (e.g. module proxies or whatever) and leave the
> existing modules in 2.x untou
Nick writes:
M.-A. Lemburg wrote:
> I don't think that an administrative problem such as forward-
> porting patches to 3.x warrants breakage in the 2.x branch.
>
> After all, the renaming was approached for Python 3.0 and not
> 2.6 *because* it introduces major breakage.
>
> AFAIR, the discussion
On Sat, May 17, 2008 at 5:42 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> I know Guido has opposed adding Py3k warnings to oct and hex for
> "practical reasons," but I would like to make the case again.
>
> future_buitlins oct and hex will give you the correct Py3k behavior,
> but 2to3 can't
On Mon, May 19, 2008 at 5:33 AM, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
...
import this
> The Zen of Python, by Tim Peters
> ...
> There should be one-- and preferably only one --obvious way to do it.
>
> There should be ONE OBVIOUS way to do it, not "only one way".
The "only one way"
Ryan Hitchman wrote:
This would make the syntax closer to that of generators, which have
'for variable in iterable if condition',
Incorporating the filter condition into the list comprehension syntax
(and later into generator expressions) is necessary because they need to
be written as a sin
Nick writes:
> M.-A. Lemburg wrote:
> > I don't think that an administrative problem such as forward-
> > porting patches to 3.x warrants breakage in the 2.x branch.
> >
> > After all, the renaming was approached for Python 3.0 and not
> > 2.6 *because* it introduces major breakage.
> >
> > AFAIR,
"Alexandre Vassalotti" <[EMAIL PROTECTED]> writes:
>>> So now I am not sure what OP is proposing. Do you want to replace 21
>>> with EISDIR in the above?
>>
>> Yes, that's what I had in mind.
>>
>
> Then, check out EnvironmentError_str in Objects/exceptions.c. You
> should be able import the errn
"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
| M.-A. Lemburg wrote:
| > I don't think that an administrative problem such as forward-
| > porting patches to 3.x warrants breakage in the 2.x branch.
| >
| > After all, the renaming was approached for Python 3.0 and not
On Mon, 19 May 2008 08:42:29 pm Lennart Regebro wrote:
> How was it again? "One and only one way"? :-)
Certainly not. What on earth gave you the idea that that ridiculous
statement is a Python philosophy? I know some Perl developers like to
contrast the supposed flexibility of Perl ("more than
M.-A. Lemburg wrote:
I don't think that an administrative problem such as forward-
porting patches to 3.x warrants breakage in the 2.x branch.
After all, the renaming was approached for Python 3.0 and not
2.6 *because* it introduces major breakage.
AFAIR, the discussion on the stdlib-sig also d
On 2008-05-18 22:24, Brett Cannon wrote:
On Sun, May 18, 2008 at 6:14 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
M.-A. Lemburg wrote:
Perhaps I have a misunderstanding of the reasoning behind
doing the renaming in the 2.x branch, but it appears that
the only reason is to get used to the new na
On Mon, May 19, 2008 at 5:55 AM, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Ryan Hitchman" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> | I'd like to propose an addition to the for statement's syntax:
> |
> | for {variable} in {iterable} if {condition}:
> |{block}
> |
> | wh
Ulrich Berning wrote:
I'm trying to use the vendor specific compilers whenever possible,
because using gcc puts in additional dependencies (libgcc), I want to
avoid, and even if I could live with these dependencies, it's not easy
to get/build the 'right' gcc version, if your software also depen
Gregory P. Smith wrote:
On Fri, May 16, 2008 at 1:32 AM, Ulrich Berning
<[EMAIL PROTECTED]> wrote:
As long as the ctypes extension doesn't build on major Un*x platforms (AIX,
HP-UX), I don't like to see ctypes dependend modules included into the
stdlib. Please keep the stdlib as portable as
Nick Coghlan wrote:
Ulrich Berning wrote:
More and more people tend to say "Runs on Un*x" when they really mean
"Tested on Linux". Un*x is not Linux.
Hmm, perhaps that would be why there are Solaris, FreeBSD and Tru64
machines amongst the main Python buildbots, to go along with the
assort
42 matches
Mail list logo
