[ python-Bugs-1653736 ] Problems in datetime.c and typeobject.c.

2007-02-18 Thread SourceForge.net
Bugs item #1653736, was opened at 2007-02-07 02:15
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653736&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: ked-tao (ked-tao)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problems in datetime.c and typeobject.c.

Initial Comment:
This is related to [python-Bugs-1648268], but I think these problems might be 
important enough to consider fixing prior to any patch being produced for that 
item.

Modules/datetimemodule.c:time_isoformat() is declared in time_methods[] as 
METH_KEYWORDS. However, I believe it is better declared as METH_NOARGS (calling 
it with args and kwargs doesn't raise any exception, but it doesn't accept 
them).

Objects/typeobject.c:4428 - slot_nb_inplace_power is declared with the SLOT1() 
macro. I'm not sure I entirely grok what's going on here (not enough to supply 
a python-level failure case), but it seems to me that it should be declared 
with the SLOT2() macro (it's a ternary op). FWIW, I changed it from:

SLOT1(slot_nb_inplace_power, "__ipow__", PyObject *, "O")

to:

SLOT2(slot_nb_inplace_power, "__ipow__", PyObject *, PyObject *, "OO")

... and that ran the failing tests OK.

Hopefully someone familiar with this code can determine if this is correct or 
not.

Thanks, Kev.




--

>Comment By: Martin v. Löwis (loewis)
Date: 2007-02-18 09:51

Message:
Logged In: YES 
user_id=21627
Originator: NO

I had to revert r53672. New fix is r53816.

--

Comment By: Martin v. Löwis (loewis)
Date: 2007-02-09 13:20

Message:
Logged In: YES 
user_id=21627
Originator: NO

The second bug should now be fixed in r53689 and r53690.

--

Comment By: Martin v. Löwis (loewis)
Date: 2007-02-08 10:18

Message:
Logged In: YES 
user_id=21627
Originator: NO

Thanks for the report. I have fixed the first bug, in r53671 and r53672.

As for the second bug: I think your suggested change is wrong. __ipow__ is
supposed to take only two arguments. I'm unsure why nb_inplace_power is
defined with three arguments; the third argument is set to Py_None in all
places I could find. So it is, at a minimum,
ok if slot_nb_inplace_power discards its third argument; I wonder whether
the API should be changed to drop this argument entirely. This is for
python-dev to discuss.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1653736&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1486663 ] Over-zealous keyword-arguments check for built-in set class

2007-02-18 Thread SourceForge.net
Bugs item #1486663, was opened at 2006-05-11 11:17
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
>Group: Python 2.5
>Status: Open
Resolution: Fixed
>Priority: 8
Private: No
Submitted By: dib (dib_at_work)
Assigned to: Georg Brandl (gbrandl)
Summary: Over-zealous keyword-arguments check for built-in set class

Initial Comment:
The fix for bug #1119418 (xrange() builtin accepts
keyword arg silently) included in Python 2.4.2c1+
breaks code that passes keyword argument(s) into
classes derived from the built-in set class, even if
those derived classes explictly accept those keyword
arguments and avoid passing them down to the built-in
base class.

Simplified version of code in attached
BuiltinSetKeywordArgumentsCheckBroken.py fails at (G)
due to bug #1119418 if version < 2.4.2c1; if version >=
2.4.2c1 (G) passes thanks to that bug fix, but instead
(H) incorrectly-in-my-view fails.

[Presume similar cases would fail for xrange and the
other classes mentioned in #1119418.]

  -- David Bruce

(Tested on 2.4, 2.4.2, 2.5a2 on linux2, win32.)

--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-02-18 21:38

Message:
Logged In: YES 
user_id=80475
Originator: NO

There are more of these that need to be fixed:

bufferobject.c:236: if (!_PyArg_NoKeywords("buffer()", kw))
classobject.c:2261: if (!_PyArg_NoKeywords("instancemethod", kw))
exceptions.c:57:if (!_PyArg_NoKeywords(self->ob_type->tp_name, kwds))
funcobject.c:653:   if (!_PyArg_NoKeywords("classmethod", kwds))
funcobject.c:810:   if (!_PyArg_NoKeywords("staticmethod", kwds))
rangeobject.c:48:   if (!_PyArg_NoKeywords("xrange()", kw))
sliceobject.c:197:  if (!_PyArg_NoKeywords("slice()", kw))
typeobject.c:5773:  if (!_PyArg_NoKeywords("super", kwds))



--

Comment By: Georg Brandl (gbrandl)
Date: 2007-01-21 05:29

Message:
Logged In: YES 
user_id=849994
Originator: NO

Committed as rev. 53509, 53510 (2.5).

--

Comment By: Georg Brandl (gbrandl)
Date: 2007-01-17 04:13

Message:
Logged In: YES 
user_id=849994
Originator: NO

I'll create the testcases and commit the patch (as well as NEWS entries :)
when I find the time.

--

Comment By: Neal Norwitz (nnorwitz)
Date: 2007-01-17 02:22

Message:
Logged In: YES 
user_id=33168
Originator: NO

Were these changes applied by Raymond?  I don't think there were NEWS
entries though.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-11 15:43

Message:
Logged In: YES 
user_id=80475
Originator: NO

That looks about right.  Please add test cases that fail without the patch
and succeed with the patch.  Also, put a comment in Misc/NEWS.  If the
whole test suite passes, go ahead and check-in to Py2.5.1 and the head.  

Thanks, 

Raymond

--

Comment By: Georg Brandl (gbrandl)
Date: 2007-01-11 14:56

Message:
Logged In: YES 
user_id=849994
Originator: NO

Attaching patch.
File Added: nokeywordchecks.diff

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-11 13:30

Message:
Logged In: YES 
user_id=80475
Originator: NO

I fixed setobject.c in revisions 53380 and 53381.

Please apply similar fixes to all the other places being bitten my the
pervasive NoKeywords tests.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-10 19:49

Message:
Logged In: YES 
user_id=80475
Originator: NO

My proposed solution:

- if(!PyArg_NoKeywords("set()", kwds)
+ if(type == &PySet_Type && !PyArg_NoKeywords("set()", kwds)

--

Comment By: Georg Brandl (gbrandl)
Date: 2007-01-10 16:30

Message:
Logged In: YES 
user_id=849994
Originator: NO

I'll do that, only in set_init, you have 
if (!PyArg_UnpackTuple(args, self->ob_type->tp_name, 0, 1, &iterable))

Changing this to use PyArg_ParseTupleAndKeywords would require a format
string of
"|O:" + self->ob_type->tp_name

Is it worth constructing that string each time set_init() is called or
should it just be "|O:set" for
sets and frozensets?

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-05 21:26

Message:
Logged In: YES 
user_id=80475
O