[ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds
Bugs item #1683368, was opened at 2007-03-19 03:32
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&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: None
Priority: 5
Private: No
Submitted By: Blake Ross (blakeross)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: object.__init__ shouldn't allow args/kwds
Initial Comment:
object.__init__ currently allows any amount of args and keywords even though
they're ignored. This is inconsistent with other built-ins, like list, that are
stricter about what they'll accept. It's also inconsistent with object.__new__,
which does throw if any are provided (if the default __init__ is to be used).
To reproduce:
object.__init__(object(), foo, bar=3)
This is a slight irritation when using cooperative super calling. I'd like each
class' __init__ to cherry-pick keyword params it accepts and pass the remaining
ones up the chain, but right now I can't rely on object.__init__ to throw if
there are remaining keywords by that point.
--
>Comment By: Georg Brandl (gbrandl)
Date: 2007-03-19 08:56
Message:
Logged In: YES
user_id=849994
Originator: NO
I don't really understand either why object_new() checks the arguments,
not object_init():
"""
static int
object_init(PyObject *self, PyObject *args, PyObject *kwds)
{
return 0;
}
/* If we don't have a tp_new for a new-style class, new will use this
one.
Therefore this should take no arguments/keywords. However, this new
may
also be inherited by objects that define a tp_init but no tp_new.
These
objects WILL pass argumets to tp_new, because it gets the same args as
tp_init. So only allow arguments if we aren't using the default init,
in
which case we expect init to handle argument parsing. */
static PyObject *
object_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
{
if (type->tp_init == object_init && (PyTuple_GET_SIZE(args) ||
(kwds && PyDict_Check(kwds) && PyDict_Size(kwds {
PyErr_SetString(PyExc_TypeError,
"default __new__ takes no parameters");
return NULL;
}
return type->tp_alloc(type, 0);
}
"""
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1683316 ] select.select() injecting spurious text in stdout
Bugs item #1683316, was opened at 2007-03-19 00:34 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683316&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 Library Group: Python 2.4 >Status: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: Peter Williams (peter_ono) Assigned to: Nobody/Anonymous (nobody) Summary: select.select() injecting spurious text in stdout Initial Comment: I'm using a function (see attachment) similar to that described on Page 386 (Section 9.12) of the Python Cookbook (Second Edition) to capture the stdout and stderr streams of programs run with popen2.Popen3. This involves using select.select() to detect the availability of data on the two streams. Sometimes, what looks like a debugging message: "EXCEPTION IN SAFE SELECT 9\n" gets injected into the stdout stream. As far as I can tell this has only started occuring after updating to version 2.4.4. No exception occurs and the string just silently appears in stdout. Apart from the bogus text in stdout everything seems to be working correctly and I'm able to work around the problem by looking for the string and removing whenever it occurs. It looks to me like a debugging message that somebody forgot to remove. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-19 09:12 Message: Logged In: YES user_id=849994 Originator: NO I can find no occurrence of the message or parts of it in the current 2.5 or 2.6 branches. Please make sure that it is Python that emits that message. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683316&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1683288 ] xreload.py won't update class docstrings
Bugs item #1683288, was opened at 2007-03-18 22:48
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683288&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 Library
Group: Python 3000
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jim Jewett (jimjjewett)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: xreload.py won't update class docstrings
Initial Comment:
"""
def _update_class(oldclass, newclass):
...
for name in oldnames & newnames - {"__dict__", "__doc__"}:
setattr(oldclass, name, _update(olddict[name], newdict[name]))
return oldclass
"""
I assume __doc__ is skipped because a string can't be updated in place. But
since oldclass is returned, __doc__ should still be replaced with the updated
documentation.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683288&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1378305 ] Import value 1e400 from pyc fails
Bugs item #1378305, was opened at 2005-12-11 21:09 Message generated for change (Comment added) made by sean_gillespie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378305&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: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Guenter Jantzen (gjantzen) Assigned to: Nobody/Anonymous (nobody) Summary: Import value 1e400 from pyc fails Initial Comment: --- #file: bug.py #sys.version_info (2, 4, 2, 'final', 0) #Platform is Windows XP import sys, bug infinity = 1e400 if __name__ == "__main__": import bug print "Infinity is", bug.infinity -- This code behaves correct using bug.py - when bug.pyc is not up to date / not exists: Infinity is 1.#INF and behaves wrong using bug.pyc - when bug.pyc is up to date: Infinity is 1.0 -- Comment By: Sean Gillespie (sean_gillespie) Date: 2007-03-19 13:24 Message: Logged In: YES user_id=1744567 Originator: NO This does indeed seem to be fixed in Python2.5. I was able to reproduce this with Python2.4 with similar results (Windows XP again). However, in Python2.5, the results are as expected. Python24: > python.exe bug.pyc Infinity is 1.0 Python25: > python.exe bug.pyc Infinity is 1.#INF -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-14 06:10 Message: Logged In: YES user_id=341410 This is a known bug with Python and floating point infinity literals. You can use: infinity = 1e155 * 1e155 I believe this is fixed in the latest Python 2.5 SVN. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378305&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1378305 ] Import value 1e400 from pyc fails
Bugs item #1378305, was opened at 2005-12-11 21:09 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378305&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: Parser/Compiler Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Guenter Jantzen (gjantzen) Assigned to: Nobody/Anonymous (nobody) Summary: Import value 1e400 from pyc fails Initial Comment: --- #file: bug.py #sys.version_info (2, 4, 2, 'final', 0) #Platform is Windows XP import sys, bug infinity = 1e400 if __name__ == "__main__": import bug print "Infinity is", bug.infinity -- This code behaves correct using bug.py - when bug.pyc is not up to date / not exists: Infinity is 1.#INF and behaves wrong using bug.pyc - when bug.pyc is up to date: Infinity is 1.0 -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-19 16:30 Message: Logged In: YES user_id=849994 Originator: NO Fixed, then. -- Comment By: Sean Gillespie (sean_gillespie) Date: 2007-03-19 13:24 Message: Logged In: YES user_id=1744567 Originator: NO This does indeed seem to be fixed in Python2.5. I was able to reproduce this with Python2.4 with similar results (Windows XP again). However, in Python2.5, the results are as expected. Python24: > python.exe bug.pyc Infinity is 1.0 Python25: > python.exe bug.pyc Infinity is 1.#INF -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-12-14 06:10 Message: Logged In: YES user_id=341410 This is a known bug with Python and floating point infinity literals. You can use: infinity = 1e155 * 1e155 I believe this is fixed in the latest Python 2.5 SVN. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378305&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1681984 ] unittest documentation is incomplete
Bugs item #1681984, was opened at 2007-03-16 06:17 Message generated for change (Settings changed) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681984&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: Documentation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: STINNER Victor (haypo) >Assigned to: Collin Winter (collinwinter) Summary: unittest documentation is incomplete Initial Comment: When I tried to write a test suite using many test cases, I read the documentation (docs.python.org) but it does work because I was unable to run my test suite. Using Google I realised that documentation is incomplete! In Python binding of gstreamer, I found a "TextTestRunner"! So, would it be possible to update the doc? -- Comment By: STINNER Victor (haypo) Date: 2007-03-18 22:00 Message: Logged In: YES user_id=365388 Originator: YES "Could you please state what exactly is missing from the documentation, in your opinion?" Well, when I ready Python documentation I expect to have the full list of "builtin" modules, functions and classes. But if you check unittest module, documentation only list TestCase, TestSuite, TestResult and TestLoader. Whereas dir(unittest) gives TestCase, TestLoader, *TestProgram*, TestResult, TestSuite, *TextTestRunner*. So information about TestProgram and TextTestRunner is missing. I also expect a small example showing how to use a test runner and a test suite. I'm using: -- 8< --- from unittest import TestSuite, TestLoader, TextTestRunner from sys import exit def loadTests(loader): """Generator listing all test cases""" ... def main(): loader = TestLoader() suite = TestSuite() for test in loadTests(loader.loadTestsFromTestCase): suite.addTests(test) runner = TextTestRunner(descriptions=2, verbosity=2) result = runner.run(suite) if result.failures or result.errors: exit(1) -- 8< --- -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-16 09:02 Message: Logged In: YES user_id=849994 Originator: NO Could you please state what exactly is missing from the documentation, in your opinion? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1681984&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1675967 ] Python2.5 can't read a (complex) pickle build by python2.4
Bugs item #1675967, was opened at 2007-03-07 13:16
Message generated for change (Settings changed) made by collinwinter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675967&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 Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Michael Vogt (mvo)
>Assigned to: Žiga Seilnacht (zseil)
Summary: Python2.5 can't read a (complex) pickle build by python2.4
Initial Comment:
Part of gnome-app-install in ubuntu is a pickle data structure cache. If I
create this pickle with python 2.4 and read it later with 2.5. I get the
following error:
$ python2.5 -c 'import pickle;
pickle.load(open("/var/cache/app-install/menu.p"))'
/usr/lib/python2.5/pickle.py:1124: DeprecationWarning: The sre module is
deprecated, please import re.
__import__(module)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/pickle.py", line 1370, in load
return Unpickler(file).load()
File "/usr/lib/python2.5/pickle.py", line 858, in load
dispatch[key](self)
File "/usr/lib/python2.5/pickle.py", line 1090, in load_global
klass = self.find_class(module, name)
File "/usr/lib/python2.5/pickle.py", line 1126, in find_class
klass = getattr(mod, name)
AttributeError: 'module' object has no attribute '_compile'
With:
$ python2.4 -c 'import pickle;
pickle.load(open("/var/cache/app-install/menu.p"))'
[EMAIL PROTECTED] ~ $
It loads just fine.
The test pickle can be found here:
http://people.ubuntu.com/~mvo/gnome-app-install/menu.p.gz
Cheers,
Michael
--
Comment By: Žiga Seilnacht (zseil)
Date: 2007-03-11 11:40
Message:
Logged In: YES
user_id=1326842
Originator: NO
Attaching the patch with a test here. Unpickling
old patterns with this patch works, but it still
issues a DeprecationWarning. The test itself is
a bit obscure, but the other option is to add
a binary file to the test suite.
File Added: sre_pickle_compatibility.diff
--
Comment By: Žiga Seilnacht (zseil)
Date: 2007-03-07 14:43
Message:
Logged In: YES
user_id=1326842
Originator: NO
This happens because of SRE_Pattern objects in jour pickle.
The sre module was renamed to re in Python 2.5, but the
old pickles still expect the _compile function in sre module.
I posted the patch here:
http://freeweb.siol.net/chollus/
Could you try if it fixes the problem for you and in that
case, attach it to this report?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1675967&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1673403 ] date-datetime comparison doesn't work
Bugs item #1673403, was opened at 2007-03-04 06:51 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673403&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 Library Group: Python 2.5 >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Jon Ribbens (jribbens) Assigned to: Tim Peters (tim_one) Summary: date-datetime comparison doesn't work Initial Comment: Summary: bug #1028306 was not a bug, but the fix for it introduced one Comparing a date to a datetime currently throws an exception. This makes no sense. In what way is: datetime(2006, 1, 1, 0, 0, 0) < date(2007, 1, 1) not a perfectly reasonable and well-defined comparison? Throwing an exception here violates the "Principle of Least Surprise" to a considerable degree. Obviously some slight ambiguity arises if the date and the datetime differ only in the time part. There are two sensible responses in this situation that I can see: Treat dates as if they have a time-part of midnight. This is my preferred solution, and it is already what the datetime module does, for example, when subtracting two dates. Treat dates as if they refer to the entire day, i.e. if the date and datetime differ only in the time part then they are equal. This is consistent but becomes confusing in other situations such as when subtracting dates. -- >Comment By: Collin Winter (collinwinter) Date: 2007-03-19 13:22 Message: Logged In: YES user_id=1344176 Originator: NO Quoting from http://mail.python.org/pipermail/python-ideas/2007-March/000331.html: """refusing to compare dates and datetimes is the right thing to do""". Closing. -- Comment By: Raymond Hettinger (rhettinger) Date: 2007-03-08 16:09 Message: Logged In: YES user_id=80475 Originator: NO Tim, any thoughts? -- Comment By: Collin Winter (collinwinter) Date: 2007-03-08 15:55 Message: Logged In: YES user_id=1344176 Originator: NO I think this warrants discussion on python-dev (http://mail.python.org/mailman/listinfo/python-dev) as to which of the two date interpretations to pick. Please post a description of the problem there and ask for suggestions. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1673403&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-415692 ] smarter temporary file object
Feature Requests item #415692, was opened at 2001-04-12 11:37 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=415692&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 Library Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: smarter temporary file object Initial Comment: Jim Fulton suggested the following: I wonder if it would be a good idea to have a new kind of temporary file that stored data in memory unless: - The data exceeds some size, or - Somebody asks for a fileno. Then the cgi module (and other apps) could use this thing in a uniform way. -- >Comment By: Collin Winter (collinwinter) Date: 2007-03-19 14:53 Message: Logged In: YES user_id=1344176 Originator: NO Patch #1630118 checked in as r54439. -- Comment By: Dustin J. Mitchell (djmitche) Date: 2007-01-07 15:36 Message: Logged In: YES user_id=7446 Originator: NO Patch is at http://python.org/sf/1630118 -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-01-02 23:52 Message: Logged In: YES user_id=6380 Originator: YES I've reopened the issue for you. Do try to interest some other core developer in reviewing your code, or it will take a long time... Thanks for remembering! -- Comment By: Dustin J. Mitchell (djmitche) Date: 2007-01-02 23:30 Message: Logged In: YES user_id=7446 Originator: NO I have a potential implementation for this, intended to be included in Lib/tempfile.py. Because the issue is closed, I can't attach it. Let's see if posting to the issue will open that option up. Dustin -- Comment By: Guido van Rossum (gvanrossum) Date: 2001-08-09 12:51 Message: Logged In: YES user_id=6380 Thank you. I've moved this feature request to PEP 42, "Feature Requests". -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=415692&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1683872 ] module-ctypes should show platform availability
Bugs item #1683872, was opened at 2007-03-19 11:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683872&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: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Noah Spurrier (noah) Assigned to: Nobody/Anonymous (nobody) Summary: module-ctypes should show platform availability Initial Comment: It is not clear that ctypes is only for Microsoft Windows. Many other module documentation pages have a line similar to this: Availability: Unix. This was even more confusing because ctypes is listed under "Generic Operating System Services". http://docs.python.org/lib/module-ctypes.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683872&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1673203 ] add identity function
Feature Requests item #1673203, was opened at 2007-03-03 19:21 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&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: Open Resolution: None Priority: 5 Private: No Submitted By: paul rubin (phr) Assigned to: Raymond Hettinger (rhettinger) Summary: add identity function Initial Comment: Requested and assigned to Raymond at his suggestion: http://groups.google.com/group/comp.lang.python/msg/603870361743c85c There should be an identify function identity(x)=x. I suggest it also take and ignore an optional second arg: identity(x1,x2)=x1. The second arg can be useful in some generator expressions: foo = (x for x in bar if condition(x) and identity(True, memoize(x)) That allows calling memoize (or some other function) on the selected elements in the genexp, and disposing of the returned value. It's sort of like the const function (K combinator) to go along with the identity function's I combinator. OK, the above is not really in the functional spirit, but it's been useful. There could conceivably be also an actual const function const(k)=partial(identity,k) but I can't remember needing that in Python code. The two-arg identity function (uncurried version of const) is probably enough. -- >Comment By: Collin Winter (collinwinter) Date: 2007-03-19 15:05 Message: Logged In: YES user_id=1344176 Originator: NO I can see adding the 1-argument form to operator or functools (as it's useful in functional programming), but the 2-argument form you've suggested is right out. If you really feel the need to torture a "for" loop into a genexp/listcomp like that, foo = (x for x in bar if condition(x) and [memoize(x)]) does the same thing using today's capabilities. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-12 16:06 Message: Logged In: YES user_id=341410 Originator: NO Not all x line functions should be built into Python. Further, Python's standard syntax offers an infix operator that does the same thing (though in slightly different order as described below, you can reorder with minimal effort). identity(X, Y) -> (Y and False) or X Also, the only use-case that you are provided and that I can imagine, are examples like you provide where one is changing state within a statement (if, elif, while, etc.) or expression (generator, list comprehension, conditional, etc.). -- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 09:21 Message: Logged In: YES user_id=835142 Originator: NO 1. If this proposal is accepted, it will make sense to deprecate the use of None as an identity function in map: >>> map(None, range(10)) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] 2. Some other languages have an dyadic identity function that returns the *second* argument. For example, K has : primitive: identity:(:) identity[1;2] 2 The rationale in K is that it is useful in an ammed function that replaces entries of an an array with a result of a dyadic function applied to the old and the supplied value and it is natural to have old value first: @[1 2 3;1;-;20] 1 -18 3 @[1 2 3;1;:;20] 1 20 3 This rationale does not apply to Python, but in the absence of other reasons to choose the order of arguments, Python may as well follow the precedent. Does anyone know a less exotic language that has a dyadic identity? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1506122 ] Add "compose" function to the functools
Feature Requests item #1506122, was opened at 2006-06-14 11:12 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506122&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 Library >Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gregory Petrosyan (gregory_p) Assigned to: Nobody/Anonymous (nobody) Summary: Add "compose" function to the functools Initial Comment: I think it would be very usefull to have something similar to Haskell's "dot" operator in Python, IMO it should be something like this (untested): def compose(f, g): return lambda *args, **kws: f(g(*args, **kws)) but C-coded. So, _functools can be a good place for it. -- Regards, Gregory. -- >Comment By: Collin Winter (collinwinter) Date: 2007-03-19 15:07 Message: Logged In: YES user_id=1344176 Originator: NO If there's interest in this, I already have an implementation in my functional package (http://cheeseshop.python.org/pypi/functional). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1506122&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1683872 ] module-ctypes should show platform availability
Bugs item #1683872, was opened at 2007-03-19 18:54 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683872&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: Documentation Group: Python 2.5 >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Noah Spurrier (noah) Assigned to: Nobody/Anonymous (nobody) Summary: module-ctypes should show platform availability Initial Comment: It is not clear that ctypes is only for Microsoft Windows. Many other module documentation pages have a line similar to this: Availability: Unix. This was even more confusing because ctypes is listed under "Generic Operating System Services". http://docs.python.org/lib/module-ctypes.html -- >Comment By: Georg Brandl (gbrandl) Date: 2007-03-19 19:11 Message: Logged In: YES user_id=849994 Originator: NO Why do you think ctypes is for Windows only? The first tutorial page already covers Windows and Linux. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683872&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1673203 ] add identity function
Feature Requests item #1673203, was opened at 2007-03-03 19:21 Message generated for change (Comment added) made by belopolsky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&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: Open Resolution: None Priority: 5 Private: No Submitted By: paul rubin (phr) Assigned to: Raymond Hettinger (rhettinger) Summary: add identity function Initial Comment: Requested and assigned to Raymond at his suggestion: http://groups.google.com/group/comp.lang.python/msg/603870361743c85c There should be an identify function identity(x)=x. I suggest it also take and ignore an optional second arg: identity(x1,x2)=x1. The second arg can be useful in some generator expressions: foo = (x for x in bar if condition(x) and identity(True, memoize(x)) That allows calling memoize (or some other function) on the selected elements in the genexp, and disposing of the returned value. It's sort of like the const function (K combinator) to go along with the identity function's I combinator. OK, the above is not really in the functional spirit, but it's been useful. There could conceivably be also an actual const function const(k)=partial(identity,k) but I can't remember needing that in Python code. The two-arg identity function (uncurried version of const) is probably enough. -- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-19 15:57 Message: Logged In: YES user_id=835142 Originator: NO I have just realized that the requested functionality is known in C as the comma operator. I often find myself writing "return Py_INCREF(o),o;" in my C code, but I cannot really defend that idiom against "Py_INCREF(o); return o;" alternative. My personal reason is entirely C-specific, if followed an if(), the first form does not require curly braces. In any case, comma operator can be emulated in python as exp1,expr2,expr3 -> (exp1,expr2,expr3)[-1] Since multi-argument "identity" is likely to be rejected, my proposal to alter the order of arguments is moot. My other suggestion that with identity, map(None, ..) should be deprecated in favor of map(identity, ..) is probably an arument against the identity proposal now. -- Comment By: Collin Winter (collinwinter) Date: 2007-03-19 15:05 Message: Logged In: YES user_id=1344176 Originator: NO I can see adding the 1-argument form to operator or functools (as it's useful in functional programming), but the 2-argument form you've suggested is right out. If you really feel the need to torture a "for" loop into a genexp/listcomp like that, foo = (x for x in bar if condition(x) and [memoize(x)]) does the same thing using today's capabilities. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-03-12 16:06 Message: Logged In: YES user_id=341410 Originator: NO Not all x line functions should be built into Python. Further, Python's standard syntax offers an infix operator that does the same thing (though in slightly different order as described below, you can reorder with minimal effort). identity(X, Y) -> (Y and False) or X Also, the only use-case that you are provided and that I can imagine, are examples like you provide where one is changing state within a statement (if, elif, while, etc.) or expression (generator, list comprehension, conditional, etc.). -- Comment By: Alexander Belopolsky (belopolsky) Date: 2007-03-05 09:21 Message: Logged In: YES user_id=835142 Originator: NO 1. If this proposal is accepted, it will make sense to deprecate the use of None as an identity function in map: >>> map(None, range(10)) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] 2. Some other languages have an dyadic identity function that returns the *second* argument. For example, K has : primitive: identity:(:) identity[1;2] 2 The rationale in K is that it is useful in an ammed function that replaces entries of an an array with a result of a dyadic function applied to the old and the supplied value and it is natural to have old value first: @[1 2 3;1;-;20] 1 -18 3 @[1 2 3;1;:;20] 1 20 3 This rationale does not apply to Python, but in the absence of other reasons to choose the order of arguments, Python may as well follow the precedent. Does anyone know a less exotic language that has a dyadic identity? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1673203&group_id=5470 ___ Python-bugs
[ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds
Bugs item #1683368, was opened at 2007-03-18 23:32
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&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: None
Priority: 5
Private: No
Submitted By: Blake Ross (blakeross)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: object.__init__ shouldn't allow args/kwds
Initial Comment:
object.__init__ currently allows any amount of args and keywords even though
they're ignored. This is inconsistent with other built-ins, like list, that are
stricter about what they'll accept. It's also inconsistent with object.__new__,
which does throw if any are provided (if the default __init__ is to be used).
To reproduce:
object.__init__(object(), foo, bar=3)
This is a slight irritation when using cooperative super calling. I'd like each
class' __init__ to cherry-pick keyword params it accepts and pass the remaining
ones up the chain, but right now I can't rely on object.__init__ to throw if
there are remaining keywords by that point.
--
>Comment By: Guido van Rossum (gvanrossum)
Date: 2007-03-19 16:01
Message:
Logged In: YES
user_id=6380
Originator: NO
I'll try to explain why I did it this way. I was considering the single
inheritance case implementing an Immutable object, which overrides __new__
but has no need to override __init__ (since it's too late to do anything in
__init__ for an Immutable object). Since the __init__ still gets called it
would be annoying to have to override it just to make the error go away if
there was a check in __init__. The other case is overriding __init__
without overriding __new__, which is the most common way of doing Mutable
objects; here you wouldn't want __new__ to complain about extra args. So
the only time when you'd want complaints is if both __new__ and __init__
are the defaults, in which case it doesn't really matter whether you
implement this in __init__ or in __new__, so I arbitrarily chose __new__.
I wasn't thinking of your use case at the time though (cooperative super
calls to __init__, which still isn't something I engage in on a day-to-day
basis). I wonder if the right thing to do wouldn't be to implement the
same check both in __init__ and in __new__.
Am I makign sense?
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-03-19 04:56
Message:
Logged In: YES
user_id=849994
Originator: NO
I don't really understand either why object_new() checks the arguments,
not object_init():
"""
static int
object_init(PyObject *self, PyObject *args, PyObject *kwds)
{
return 0;
}
/* If we don't have a tp_new for a new-style class, new will use this
one.
Therefore this should take no arguments/keywords. However, this new
may
also be inherited by objects that define a tp_init but no tp_new.
These
objects WILL pass argumets to tp_new, because it gets the same args as
tp_init. So only allow arguments if we aren't using the default init,
in
which case we expect init to handle argument parsing. */
static PyObject *
object_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
{
if (type->tp_init == object_init && (PyTuple_GET_SIZE(args) ||
(kwds && PyDict_Check(kwds) && PyDict_Size(kwds {
PyErr_SetString(PyExc_TypeError,
"default __new__ takes no parameters");
return NULL;
}
return type->tp_alloc(type, 0);
}
"""
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds
Bugs item #1683368, was opened at 2007-03-18 20:32
Message generated for change (Comment added) made by blakeross
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&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: None
Priority: 5
Private: No
Submitted By: Blake Ross (blakeross)
Assigned to: Guido van Rossum (gvanrossum)
Summary: object.__init__ shouldn't allow args/kwds
Initial Comment:
object.__init__ currently allows any amount of args and keywords even though
they're ignored. This is inconsistent with other built-ins, like list, that are
stricter about what they'll accept. It's also inconsistent with object.__new__,
which does throw if any are provided (if the default __init__ is to be used).
To reproduce:
object.__init__(object(), foo, bar=3)
This is a slight irritation when using cooperative super calling. I'd like each
class' __init__ to cherry-pick keyword params it accepts and pass the remaining
ones up the chain, but right now I can't rely on object.__init__ to throw if
there are remaining keywords by that point.
--
>Comment By: Blake Ross (blakeross)
Date: 2007-03-19 15:45
Message:
Logged In: YES
user_id=1747060
Originator: YES
Makes sense. I don't think we can ever be completely correct here since
we're inferring intent from the presence of __init__/__new__ that's liable
to be wrong in some cases, but it's likely correct often enough that it's
worth doing.
If I understand correctly, we want to be more forgiving iff one of the two
methods is used, so it seems like we should be complaining if both are used
*or* if neither is used. After all, I could add a __new__ to my coop use
case and I'd still want object to complain. If that's the case, both
object_new and object_init should be complaining if ((tp->tp_new ==
object_new && tp->tp_init == object_init) || (tp->tp_new != object_new &&
tp->tp_init != object_init)).
Of course, for the paranoid, there's always the risk that __new__ will
modify these class functions and change the outcome :) For instance, if a
class had a __new__ and no __init__ and its __new__ changed __new__ back to
object.__new__, object_init on that run would be fooled into thinking it's
using the defaults for both and would complain. I think this could only be
fixed in type_call, which is rather ugly...but then, this *is* a special
case of the "call __init__ after __new__" behavior, and we're trying to
solve it within the methods themselves. Perhaps this last point is academic
enough to be ignored...I don't know why anyone would do this, although the
language makes it possible.
--
Comment By: Guido van Rossum (gvanrossum)
Date: 2007-03-19 13:01
Message:
Logged In: YES
user_id=6380
Originator: NO
I'll try to explain why I did it this way. I was considering the single
inheritance case implementing an Immutable object, which overrides __new__
but has no need to override __init__ (since it's too late to do anything in
__init__ for an Immutable object). Since the __init__ still gets called it
would be annoying to have to override it just to make the error go away if
there was a check in __init__. The other case is overriding __init__
without overriding __new__, which is the most common way of doing Mutable
objects; here you wouldn't want __new__ to complain about extra args. So
the only time when you'd want complaints is if both __new__ and __init__
are the defaults, in which case it doesn't really matter whether you
implement this in __init__ or in __new__, so I arbitrarily chose __new__.
I wasn't thinking of your use case at the time though (cooperative super
calls to __init__, which still isn't something I engage in on a day-to-day
basis). I wonder if the right thing to do wouldn't be to implement the
same check both in __init__ and in __new__.
Am I makign sense?
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-03-19 01:56
Message:
Logged In: YES
user_id=849994
Originator: NO
I don't really understand either why object_new() checks the arguments,
not object_init():
"""
static int
object_init(PyObject *self, PyObject *args, PyObject *kwds)
{
return 0;
}
/* If we don't have a tp_new for a new-style class, new will use this
one.
Therefore this should take no arguments/keywords. However, this new
may
also be inherited by objects that define a tp_init but no tp_new.
These
objects WILL pass argumets to tp_new, because it gets the same args as
tp_init. So only allow arguments if we aren't using the default init,
in
which case we expect init to handle argument parsing. */
stati
[ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds
Bugs item #1683368, was opened at 2007-03-18 23:32 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&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: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Guido van Rossum (gvanrossum) Summary: object.__init__ shouldn't allow args/kwds Initial Comment: object.__init__ currently allows any amount of args and keywords even though they're ignored. This is inconsistent with other built-ins, like list, that are stricter about what they'll accept. It's also inconsistent with object.__new__, which does throw if any are provided (if the default __init__ is to be used). To reproduce: object.__init__(object(), foo, bar=3) This is a slight irritation when using cooperative super calling. I'd like each class' __init__ to cherry-pick keyword params it accepts and pass the remaining ones up the chain, but right now I can't rely on object.__init__ to throw if there are remaining keywords by that point. -- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 19:31 Message: Logged In: YES user_id=6380 Originator: NO Attached is a patch that implements this proposal, adding copious commentary. It doesn't seem to break anything in the test suite. I wonder if we should even make the check more rigid: check the argument list if either the current method *is* overridden or the other one *is not* overridden. This would make super calls check the arguments even if the other method is overridden. What do you think? File Added: new_init.patch -- Comment By: Blake Ross (blakeross) Date: 2007-03-19 18:45 Message: Logged In: YES user_id=1747060 Originator: YES Makes sense. I don't think we can ever be completely correct here since we're inferring intent from the presence of __init__/__new__ that's liable to be wrong in some cases, but it's likely correct often enough that it's worth doing. If I understand correctly, we want to be more forgiving iff one of the two methods is used, so it seems like we should be complaining if both are used *or* if neither is used. After all, I could add a __new__ to my coop use case and I'd still want object to complain. If that's the case, both object_new and object_init should be complaining if ((tp->tp_new == object_new && tp->tp_init == object_init) || (tp->tp_new != object_new && tp->tp_init != object_init)). Of course, for the paranoid, there's always the risk that __new__ will modify these class functions and change the outcome :) For instance, if a class had a __new__ and no __init__ and its __new__ changed __new__ back to object.__new__, object_init on that run would be fooled into thinking it's using the defaults for both and would complain. I think this could only be fixed in type_call, which is rather ugly...but then, this *is* a special case of the "call __init__ after __new__" behavior, and we're trying to solve it within the methods themselves. Perhaps this last point is academic enough to be ignored...I don't know why anyone would do this, although the language makes it possible. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 16:01 Message: Logged In: YES user_id=6380 Originator: NO I'll try to explain why I did it this way. I was considering the single inheritance case implementing an Immutable object, which overrides __new__ but has no need to override __init__ (since it's too late to do anything in __init__ for an Immutable object). Since the __init__ still gets called it would be annoying to have to override it just to make the error go away if there was a check in __init__. The other case is overriding __init__ without overriding __new__, which is the most common way of doing Mutable objects; here you wouldn't want __new__ to complain about extra args. So the only time when you'd want complaints is if both __new__ and __init__ are the defaults, in which case it doesn't really matter whether you implement this in __init__ or in __new__, so I arbitrarily chose __new__. I wasn't thinking of your use case at the time though (cooperative super calls to __init__, which still isn't something I engage in on a day-to-day basis). I wonder if the right thing to do wouldn't be to implement the same check both in __init__ and in __new__. Am I makign sense? -- Comment By: Georg Brandl (gbrandl) Date: 2007-03-19 04:56 Message: Logged In: YES user_id=849994 Originator: NO I don't r
[ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds
Bugs item #1683368, was opened at 2007-03-18 23:32 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Guido van Rossum (gvanrossum) Summary: object.__init__ shouldn't allow args/kwds Initial Comment: object.__init__ currently allows any amount of args and keywords even though they're ignored. This is inconsistent with other built-ins, like list, that are stricter about what they'll accept. It's also inconsistent with object.__new__, which does throw if any are provided (if the default __init__ is to be used). To reproduce: object.__init__(object(), foo, bar=3) This is a slight irritation when using cooperative super calling. I'd like each class' __init__ to cherry-pick keyword params it accepts and pass the remaining ones up the chain, but right now I can't rely on object.__init__ to throw if there are remaining keywords by that point. -- >Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 19:35 Message: Logged In: YES user_id=6380 Originator: NO This smells enough like a new feature that it couldn't go into 2.5. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 19:31 Message: Logged In: YES user_id=6380 Originator: NO Attached is a patch that implements this proposal, adding copious commentary. It doesn't seem to break anything in the test suite. I wonder if we should even make the check more rigid: check the argument list if either the current method *is* overridden or the other one *is not* overridden. This would make super calls check the arguments even if the other method is overridden. What do you think? File Added: new_init.patch -- Comment By: Blake Ross (blakeross) Date: 2007-03-19 18:45 Message: Logged In: YES user_id=1747060 Originator: YES Makes sense. I don't think we can ever be completely correct here since we're inferring intent from the presence of __init__/__new__ that's liable to be wrong in some cases, but it's likely correct often enough that it's worth doing. If I understand correctly, we want to be more forgiving iff one of the two methods is used, so it seems like we should be complaining if both are used *or* if neither is used. After all, I could add a __new__ to my coop use case and I'd still want object to complain. If that's the case, both object_new and object_init should be complaining if ((tp->tp_new == object_new && tp->tp_init == object_init) || (tp->tp_new != object_new && tp->tp_init != object_init)). Of course, for the paranoid, there's always the risk that __new__ will modify these class functions and change the outcome :) For instance, if a class had a __new__ and no __init__ and its __new__ changed __new__ back to object.__new__, object_init on that run would be fooled into thinking it's using the defaults for both and would complain. I think this could only be fixed in type_call, which is rather ugly...but then, this *is* a special case of the "call __init__ after __new__" behavior, and we're trying to solve it within the methods themselves. Perhaps this last point is academic enough to be ignored...I don't know why anyone would do this, although the language makes it possible. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 16:01 Message: Logged In: YES user_id=6380 Originator: NO I'll try to explain why I did it this way. I was considering the single inheritance case implementing an Immutable object, which overrides __new__ but has no need to override __init__ (since it's too late to do anything in __init__ for an Immutable object). Since the __init__ still gets called it would be annoying to have to override it just to make the error go away if there was a check in __init__. The other case is overriding __init__ without overriding __new__, which is the most common way of doing Mutable objects; here you wouldn't want __new__ to complain about extra args. So the only time when you'd want complaints is if both __new__ and __init__ are the defaults, in which case it doesn't really matter whether you implement this in __init__ or in __new__, so I arbitrarily chose __new__. I wasn't thinking of your use case at the time though (cooperative super calls to __init__, which still isn't something I engage in on a day-to-day basis). I wonder if the right thing to do wouldn't be to implement the
[ python-Bugs-1683368 ] object.__init__ shouldn't allow args/kwds
Bugs item #1683368, was opened at 2007-03-18 20:32 Message generated for change (Comment added) made by blakeross You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1683368&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Blake Ross (blakeross) Assigned to: Guido van Rossum (gvanrossum) Summary: object.__init__ shouldn't allow args/kwds Initial Comment: object.__init__ currently allows any amount of args and keywords even though they're ignored. This is inconsistent with other built-ins, like list, that are stricter about what they'll accept. It's also inconsistent with object.__new__, which does throw if any are provided (if the default __init__ is to be used). To reproduce: object.__init__(object(), foo, bar=3) This is a slight irritation when using cooperative super calling. I'd like each class' __init__ to cherry-pick keyword params it accepts and pass the remaining ones up the chain, but right now I can't rely on object.__init__ to throw if there are remaining keywords by that point. -- >Comment By: Blake Ross (blakeross) Date: 2007-03-19 18:27 Message: Logged In: YES user_id=1747060 Originator: YES I think making the check more rigid is a good idea, since this should throw: class a(object): def __init__(self, foo): super(a, self).__init__(foo) def __new__(cls, foo): return object.__new__(cls) a(1) (minor typo in the patch: "solution it" -> "solution is") -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 16:35 Message: Logged In: YES user_id=6380 Originator: NO This smells enough like a new feature that it couldn't go into 2.5. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 16:31 Message: Logged In: YES user_id=6380 Originator: NO Attached is a patch that implements this proposal, adding copious commentary. It doesn't seem to break anything in the test suite. I wonder if we should even make the check more rigid: check the argument list if either the current method *is* overridden or the other one *is not* overridden. This would make super calls check the arguments even if the other method is overridden. What do you think? File Added: new_init.patch -- Comment By: Blake Ross (blakeross) Date: 2007-03-19 15:45 Message: Logged In: YES user_id=1747060 Originator: YES Makes sense. I don't think we can ever be completely correct here since we're inferring intent from the presence of __init__/__new__ that's liable to be wrong in some cases, but it's likely correct often enough that it's worth doing. If I understand correctly, we want to be more forgiving iff one of the two methods is used, so it seems like we should be complaining if both are used *or* if neither is used. After all, I could add a __new__ to my coop use case and I'd still want object to complain. If that's the case, both object_new and object_init should be complaining if ((tp->tp_new == object_new && tp->tp_init == object_init) || (tp->tp_new != object_new && tp->tp_init != object_init)). Of course, for the paranoid, there's always the risk that __new__ will modify these class functions and change the outcome :) For instance, if a class had a __new__ and no __init__ and its __new__ changed __new__ back to object.__new__, object_init on that run would be fooled into thinking it's using the defaults for both and would complain. I think this could only be fixed in type_call, which is rather ugly...but then, this *is* a special case of the "call __init__ after __new__" behavior, and we're trying to solve it within the methods themselves. Perhaps this last point is academic enough to be ignored...I don't know why anyone would do this, although the language makes it possible. -- Comment By: Guido van Rossum (gvanrossum) Date: 2007-03-19 13:01 Message: Logged In: YES user_id=6380 Originator: NO I'll try to explain why I did it this way. I was considering the single inheritance case implementing an Immutable object, which overrides __new__ but has no need to override __init__ (since it's too late to do anything in __init__ for an Immutable object). Since the __init__ still gets called it would be annoying to have to override it just to make the error go away if there was a check in __init__. The other case is overriding __init__ without overriding __new__, which is the most common way of doing Mutable objects; here you wouldn't want __new__
[ python-Bugs-1682241 ] Problems with urllib2 read()
Bugs item #1682241, was opened at 2007-03-16 12:00 Message generated for change (Comment added) made by maenpaa You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682241&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 Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Lucas Malor (lucas_malor) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with urllib2 read() Initial Comment: urllib2 objects opened with urlopen() does not have the method seek() as file objects. So reading only some bytes from opened urls is pratically forbidden. An example: I tried to open an url and check if it's a gzip file. If IOError is raised I read the file (to do this I applied the #1675951 patch: https://sourceforge.net/tracker/index.php?func=detail&aid=1675951&group_id=5470&atid=305470 ) But after I tried to open the file as gzip, if it's not a gzip file the current position in the urllib object is on the second byte. So read() returns the data from the 3rd to the last byte. You can't check the header of the file before storing it on hd. Well, so what is urlopen() for? If I must store the file by url on hd and reload it, I can use urlretrieve() ... -- Comment By: Zacherates (maenpaa) Date: 2007-03-19 22:43 Message: Logged In: YES user_id=1421845 Originator: NO I'd contend that this is not a bug: * If you need to seek, you can wrap the file-like object in a StringIO (which is what urllib would have to do internally, thus incurring the StringIO overhead for all clients, even those that don't need the functionality). * You can check the type of the response content before you try to uncompress it via the Content-Encoding header of the response. The meta-data is there for a reason. Check http://www.diveintopython.org/http_web_services/gzip_compression.html for a rather complete treatment of your use-case. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1682241&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-967161 ] pty.spawn() enhancements
Feature Requests item #967161, was opened at 2004-06-06 00:29 Message generated for change (Comment added) made by jhenstridge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=967161&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 Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: pty.spawn() enhancements Initial Comment: (Originally suggested by James Henstridge in bug #897935) There are also a few changes that would be nice to see in pty.spawn: 1) get the exit status of the child. Could be fixed by adding the following to the end of the function: pid, status = os.waitpid(pid, 0) return status 2) set master_fd to non-blocking mode, so that the output is printed to the screen at the speed it is produced by the child. -- Comment By: James Henstridge (jhenstridge) Date: 2007-03-20 15:32 Message: Logged In: YES user_id=146903 Originator: NO #2 was an old misunderstanding by me about file.read() vs. os.read() w.r.t pipes, so is not needed. As for returning the status code vs the pid, it looks like spawn() is designed to return only when it can't read/write to the subprocess. You could return the pid at this point, but the process has most likely finished running at this point so the only thing you'd be likely to do is call waitpid() on it (and it is necessary to call waitpid() for the child process to be cleaned up properly). That's why I suggested that pty.spawn() get the child status itself. -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-03-16 15:08 Message: Logged In: YES user_id=33168 Originator: NO Wouldn't it be better to just return the pid. The caller can get the status if they want or do anything else with the pid. I'm guessing #2 is no longer requested? -- Comment By: James Henstridge (jhenstridge) Date: 2004-06-09 22:16 Message: Logged In: YES user_id=146903 Since filing the original bug report, I got reports that simply setting the fds to non-blocking caused problems under Solaris. Some details are available in this bug report: http://bugzilla.gnome.org/show_bug.cgi?id=139168 The _copy() function never raised an IOError or OSError, so it never exited. I'd imagine that EOF could be detected by getting back then empty string when reading from the fd when select() says it is ready for reading, but I haven't checked whether this works. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=967161&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
