Travis E. Oliphant wrote:
> Internally PyNumber_AsSize_t makes a call to PyNumber_Index, and
> PyNumber_Index also calls the PyIndex_Check as well . So, basically we
> end up calling PyIndex_Check(obj) 2 times when only one check should be
> necessary.
>
> This code could be re-written to move
On 8/12/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Alexander Belopolsky schrieb:
> > Would a patch adding "readinto" to StringIO be acceptable?
>
> You mean, whether it would be accepted? Depends on the patch.
Here is the patch:
https://sourceforge.net/tracker/index.php?func=detail&aid=153
It ought to be called @instancemethod for a better analogy.
PS Nick how's the book coming along? :-)
--Guido
On 8/11/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> It's sometimes useful to be able to use an existing callable as a method of a
> new class. If the callable is a real function, this i
On 8/12/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> I can only guess why it may go away; my guess it will go away when
> the buffer interface is removed from Python (then it becomes
> unimplementable).
In Py3k, the I/O APIs will be redesigned, especially the binary ones.
My current idea is
Tim Peters wrote:
> [Travis E. Oliphant]
>> Right now throughout the Python code it is assumed that
>> sizeof(Py_ssize_t) <= sizeof(long).
>
> If you find any code like that, it's a bug. Win64 is a platform where
> it's false.
Sorry for my confusion. I meant to say that it is assumed that
size
[Travis E. Oliphant]
> Right now throughout the Python code it is assumed that
> sizeof(Py_ssize_t) <= sizeof(long).
If you find any code like that, it's a bug. Win64 is a platform where
it's false.
___
Python-Dev mailing list
Python-Dev@python.org
http
Alexander Belopolsky schrieb:
> I know that it is a subject of an annual discussion, but since I could
> not find any mention of it in the last year, let me ask this question
> again: why is file.readinto "Undocumented"? It is quite useful,
> particularly with numpy.
>
> Would a patch adding "read
Neal Norwitz wrote:
> I checked in this fix for the __index__ clipping issue that's been
> discussed. This patch is an improvement, but still needs some work.
> Please pull out any parts you have an issue with and suggest a patch
> to address your concern.
>
For me the only remaining concern is
Neal Norwitz wrote:
> I checked in this fix for the __index__ clipping issue that's been
> discussed. This patch is an improvement, but still needs some work.
>
> +/* Return a Python Int or Long from the object item
> + Raise TypeError if the result is not an int-or-long
> + or if the object
tomer filiba wrote:
> [Aahz]
>> -1
>>
>> This is seriously no different from an attempt to do
>>
>> >>> a = {}
>> >>> a[ [] ] = 1
>
> how so? i'm not trying to modify/store anything in a dict.
> i'm only testing if a certain object is contained in the dict.
> that's totally different.
> imagine th
I checked in this fix for the __index__ clipping issue that's been
discussed. This patch is an improvement, but still needs some work.
Please pull out any parts you have an issue with and suggest a patch
to address your concern.
n
-- Forwarded message --
From: neal.norwitz <[EMAI
On Sat, 12 Aug 2006 18:57:02 +0200, tomer filiba <[EMAIL PROTECTED]> wrote:
>
>the logic is simple: every `x` is either contained in `y` or not.
>if `x` *cannot* be contained in `y`, then the answer is a "strong no",
>but that's still a "no".
>
def blacklisted(o):
try:
# Is the object
[Aahz]
> -1
>
> This is seriously no different from an attempt to do
>
> >>> a = {}
> >>> a[ [] ] = 1
how so? i'm not trying to modify/store anything in a dict.
i'm only testing if a certain object is contained in the dict.
that's totally different.
imagine this:
>>> x = 6
>>> x < 2
am i trying to
tomer filiba wrote:
a={1:2, 3:4}
[] in a
>
> Traceback (most recent call last):
> File "", line 1, in ?
> TypeError: list objects are unhashable
>
> imo, the expression should just evaluate to False instead of raising an
> exception. it's a question of semantics -- i asked whether the
On Sat, Aug 12, 2006, tomer filiba wrote:
>
> >>>a={1:2, 3:4}
> >>>[] in a
> Traceback (most recent call last):
> File "", line 1, in ?
> TypeError: list objects are unhashable
> >>>
>
> imo, the expression should just evaluate to False instead of raising an
> exception.
-1
This is seriously no
[added python-dev to make sure everyone sees this]
On Sat, Aug 12, 2006, Josiah Carlson wrote:
>
> All other feature additions are too late in the Beta cycle (Beta 3 is
> next week)
For some reason, this is the second time I've seen this claim. Beta 3
was released August 3 and next week is rc1.
>>> a={1:2, 3:4}>>> [] in aTraceback (most recent call last): File "", line 1, in ?TypeError: list objects are unhashable>>>imo, the _expression_ should just evaluate to False instead of raising an exception.
it's a question of semantics -- i asked whether the object (a list, in this case)is cont
Tim Peters wrote:
> We're getting an awful lot of these turds at the ends of test runs now:
>
> Error in atexit._run_exitfuncs:
> Not sure what caused it, but suspect this:
>
> """
> Author: georg.brandl
> Date: Fri Aug 11 09:26:10 2006
> New Revision: 51206
>
> Modified:
> python/trunk/Lib/
We're getting an awful lot of these turds at the ends of test runs now:
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
File "C:\Code\bb_slave\trunk.peters-windows\build\lib\atexit.py",
line 24, in _run_exitfuncs
func(*targs, **kargs)
File "C:\Code\bb_slave\trunk.peters-
19 matches
Mail list logo
