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
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
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
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
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
"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
"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 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,
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
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"
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
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 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
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
> 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
-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
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.
___
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 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
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 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 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
"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
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
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.
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
-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
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
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
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 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 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 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
> 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 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
> 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'
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
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
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 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
42 matches
Mail list logo
