Giovanni Bajo wrote:
It was discussed before, and the agreement was to use VS 2003 for another
cycle
(i.e. 2.5). But the fact that VS 2003 is no longer available for download is
an
important fact, and we might want to rediscuss the issue.
it's still available in the .net sdk packages (see
Walter Dörwald wrote:
Martin v. Löwis wrote:
It does need a configure test, though.
Unfortunately I have no idea how this whole configure business works!
I got bored. I posted a comment to the bug, which will direct you to
http://scottdial.com/python-dev/curses-resizeterm.diff
--
Scott
Giovanni Bajo wrote:
It was discussed before, and the agreement was to use VS 2003 for another
cycle
(i.e. 2.5). But the fact that VS 2003 is no longer available for download is
an
important fact, and we might want to rediscuss the issue.
I don't recall the discussion vividly, but I think
Fredrik Lundh wrote:
It was discussed before, and the agreement was to use VS 2003 for another
cycle
(i.e. 2.5). But the fact that VS 2003 is no longer available for download is
an
important fact, and we might want to rediscuss the issue.
it's still available in the .net sdk packages
Scott Dial wrote:
I don't recall the discussion vividly, but I think the reasoning was
something like because it still works. Maybe I remember wrong, but
this is not a compelling argument en lieu of it being hard to get a hold
of the toolkit. If there is some kind of legwork involved with
Georg Brandl wrote:
In abstract.c, there are many error messages like
type_error(object does not support item assignment);
It helps debugging if the object's type was prepended.
Should I go through the code and try to enhance them
where possible?
So that's definite perhaps?
Anyway,
Kristján V. Jónsson wrote:
The standard install path in chinese distributions can be with a
non-ANSI path, and installing an embedded python application there will
break it.
I very much doubt this. On a Chinese system, the Program Files folder
likely has a non-*ASCII* name, but it will have a
Neil Hodgson wrote:
It should be unusual for a Chinese installation to use an install
path that can not be represented in MBCS. Try encoding the install
directory into MBCS before adding it to sys.path.
Indeed. Unfortunately, people apparently install an English version
(because they can
Scott Dial sagte:
Walter Dörwald wrote:
Martin v. Löwis wrote:
It does need a configure test, though.
Unfortunately I have no idea how this whole configure business works!
I got bored. I posted a comment to the bug, which will direct you to
Neal Norwitz wrote:
On 6/16/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Fredrik Lundh wrote:
what's the beta 1 status ? fixing this should be trivial, but I
don't have any
cycles to spare today.
Good question. PEP 356 says beta 1 was planned two days
ago...
Hi Phillip,
On Fri, Jun 16, 2006 at 10:01:05PM -0400, Phillip J. Eby wrote:
One thing I'm curious about, if there are any PyPy folks listening: will
tricks like this drive PyPy or Psyco insane? :)
Yes, both :-)
The reason is that the details of the stack behavior of END_FINALLY are
messy in
Walter Dörwald wrote:
I'm not sure if is_term_resized() can return ERR or not.
Oh whoops, you are of course correct. I have corrected the diff accordingly.
--
Scott Dial
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
Python-Dev mailing list
I remember you voicing this point at the Texas sprint. I can't say I agree.
The behaviour of certain function (like signal and fopen) is undefined for
certain arguments. Undefined is undefined, exiting the program with an
admonition is one of the possible outcomes (as is formatting your hard
Kristján V. Jónsson wrote:
I remember you voicing this point at the Texas sprint. I can't say I
agree. The behaviour of certain function (like signal and fopen) is
undefined for certain arguments. Undefined is undefined, exiting the
program with an admonition is one of the possible outcomes
Martin v. Löwis wrote:
For fopen(3), you are right. For signal(3), VS2005 is in clear
violation with ISO C
I'm nobody but I don't find your argument compelling. I suggest you go
read: http://msdn2.microsoft.com/en-us/library/ksazx244.aspx
In short, you can tell the CRT to do whatever you like
Scott Dial wrote:
For fopen(3), you are right. For signal(3), VS2005 is in clear
violation with ISO C
I'm nobody but I don't find your argument compelling. I suggest you go
read: http://msdn2.microsoft.com/en-us/library/ksazx244.aspx
In short, you can tell the CRT to do whatever you like
One reason for not switching to VC 8, which hasn't yet been explicitly
mentioned here, is that MinGW does not yet easily support linking to the
msvcr80 runtime library. Some C extension modules, for instance those in
SciPy, are primarily developed under Linux with GCC and hence are most
easily
On 17-jun-2006, at 6:44, Nick Coghlan wrote:
Bob Ippolito wrote:
There's a similar issue in that if sys.prefix contains a colon,
Python
is also busted:
http://python.org/sf/1507224
Of course, that's not a Windows issue, but it is everywhere else. The
offending code in that case is
At 01:18 PM 6/17/2006 +0200, Armin Rigo wrote:
Psyco cheats here and emulates a behavior where there is
always exactly one object instead (which can be a tuple), so if a
END_FINALLY sees values not put there in the official way it will just
crash. PyPy works similarily but always expect three
Hello,
2006/6/16, Josiah Carlson [EMAIL PROTECTED]:
I'm not a mathematician, and I don't really work with arrays of any
dimensionality, so the need for 0-D subscripting via arr[] while being
cute, isn't compelling to my uses for Python.
Thanks for appreciating its cuteness...
Now, I
Noam Raphael wrote:
I meant the extra code for writing a special class to handle scalars,
if I decide that the x[()] syntax is too ugly or too hard to type,
so I write a special class which will allow the syntax x.value.
What I cannot understand is why you use a zero-dimensional array to
Op za, 17-06-2006 te 10:25 +0200, schreef Martin v. Löwis:
Another reason is that I consider VS 2005 buggy, I hope that some
of the breakage that Microsoft has done to the C library is reverted
in a future release. VS2005 managed to break compatibility with
C89 and C99 in a way that made
Jan Claeys wrote:
Op za, 17-06-2006 te 10:25 +0200, schreef Martin v. Löwis:
Another reason is that I consider VS 2005 buggy, I hope that some
of the breakage that Microsoft has done to the C library is reverted
in a future release. VS2005 managed to break compatibility with
C89 and C99 in a
2006/6/17, Martin v. Löwis [EMAIL PROTECTED]:
Noam Raphael wrote:
I meant the extra code for writing a special class to handle scalars,
if I decide that the x[()] syntax is too ugly or too hard to type,
so I write a special class which will allow the syntax x.value.
What I cannot
Hi, sorry for my repeated posts. I just wanted to say that I improved
my patch a little bit, so it does exactly the same thing, but with
smaller code: you can see for yourself at
http://python.pastebin.com/715221 - it changed exactly 10 lines of
code, and adds additional 8 lines, all of them
Martin v. Löwis wrote:
Noam Raphael wrote:
I meant the extra code for writing a special class to handle scalars,
if I decide that the x[()] syntax is too ugly or too hard to type,
so I write a special class which will allow the syntax x.value.
What I cannot understand is why you use a
On Sun, Jun 18, 2006, Noam Raphael wrote:
Hi, sorry for my repeated posts. I just wanted to say that I improved
my patch a little bit, so it does exactly the same thing, but with
smaller code: you can see for yourself at
http://python.pastebin.com/715221 - it changed exactly 10 lines of
On Saturday 17 June 2006 07:06, M.-A. Lemburg wrote:
Fredrik Lundh wrote:
M.-A. Lemburg wrote:
Since replace() only works on string objects, it appears
as if a temporary string object would have to be created.
However, this would involve an unnecessary allocation
and copy process... it
28 matches
Mail list logo
