Talin wrote:
> The motivation, as I understand it, is one of mathematical consistency.
Noam told me in private email that this is *not* the motivation.
Instead, he wants mutable values. This, in turn, he wants so he
can catch modifications.
Regards,
Martin
___
Python 2.5 ships with uuid.py and now I want to ask you
about its backward compatibility.
uuid.py says in its docstring:
This module works with Python 2.3 or higher.
And my question is:
Do we plan to make it 2.3 compatible in future releases?
If so, uuid needs to be listed in PEP 291.
Other
On Friday 16 June 2006 23:13, 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 appears as if the
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
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
>
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
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 really
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
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
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
On Sat, Jun 17, 2006 at 03:27:36PM +0200, "Martin v. L?wis" wrote:
> 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/e
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
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 a
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 thre
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 tha
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
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 y
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 lik
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 outcom
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
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
Python-Dev@pytho
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 i
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...
>>
>> h
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
> http://scottdial.com/python-dev/cur
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
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
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"?
An
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 w
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 p
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 th
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
--
Scot
31 matches
Mail list logo
