[ python-Feature Requests-1156499 ] __getattr__ and __setattr__ methods for modules
Feature Requests item #1156499, was opened at 2005-03-04 09:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1156499&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Reinhold Birkenfeld (birkenfeld) Assigned to: Nobody/Anonymous (nobody) Summary: __getattr__ and __setattr__ methods for modules Initial Comment: Wouldn't it be a good addition if modules supported __getattr__ and __setattr__? In this way, one could easily write modules that dispatch calls to different objects and/or modules, such as a "global" module. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1156499&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1156259 ] [2.4 regression] seeking in codecs.reader broken
Bugs item #1156259, was opened at 2005-03-03 23:29
Message generated for change (Comment added) made by lemburg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156259&group_id=5470
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Matthias Klose (doko)
Assigned to: Martin v. Löwis (loewis)
Summary: [2.4 regression] seeking in codecs.reader broken
Initial Comment:
[forwarded from
https://bugzilla.ubuntu.com/show_bug.cgi?id=6972 ]
This is a regression; the following script (call as
"scriptname some_textfile")
fails.
It is obvious that the file starts with a number of
random bytes from the
previous run.
Uncommenting the two #XXX lines makes the bug go away.
So does running it with
Python 2.3.5
import sys
import codecs
from random import random
data = codecs.getreader("utf-8")(open(sys.argv[1]))
df = data.read()
for t in range(30):
#XXX data.seek(0,1)
#XXX data.read()
data.seek(0,0)
dn=""
for l in data:
dn += l
if random() < 0.1: break
if not df.startswith(dn):
print "OUCH",t
print "BAD:", dn[0:100]
print "GOOD:", df[0:100]
sys.exit(1)
print "OK",len(df)
sys.exit(0)
--
>Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-04 10:56
Message:
Logged In: YES
user_id=38388
This is obviously related to the buffer logic that Walter added
to support .readline().
In order to fix the problem, a .seek() method must be
implemented
that resets the buffers whenever called (before asking the
stream
to seek to the specified stream position).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156259&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1124637 ] test_subprocess is far too slow
Bugs item #1124637, was opened at 2005-02-17 11:10 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_id=5470 Category: Python Library Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Michael Hudson (mwh) Assigned to: Peter Åstrand (astrand) Summary: test_subprocess is far too slow Initial Comment: test_subprocess takes multiple minutes. I'm pretty sure it's "test_no_leaking". It should either be sped up or only tested when some -u argument is passed to regrtest. -- >Comment By: Michael Hudson (mwh) Date: 2005-03-04 10:17 Message: Logged In: YES user_id=6656 Thank you! -- Comment By: Peter Åstrand (astrand) Date: 2005-03-03 20:58 Message: Logged In: YES user_id=344921 Forgot to close. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-03-03 20:54 Message: Logged In: YES user_id=1188172 Shouldn't it be closed then? -- Comment By: Peter Åstrand (astrand) Date: 2005-03-03 20:53 Message: Logged In: YES user_id=344921 Fixed in HEAD revisions: regrtest.py: 1.166 1.19 Fixed in 2.4 revisions: regrtest.py: 1.165.2.1 test_subprocess.py: 1.15.2.2 -- Comment By: Peter Åstrand (astrand) Date: 2005-02-17 15:17 Message: Logged In: YES user_id=344921 tim_one: test_subprocess only creates 65 processes on Windows, compared to 1026 for UNIX. -- Comment By: Tim Peters (tim_one) Date: 2005-02-17 15:13 Message: Logged In: YES user_id=31435 Peculiar -- test_subprocess takes about 8 seconds on my WinXP box release build, about 10 seconds debug build, and Windows is notorious for slow process creation. That's a zippy 3.4 GHz P4, but clock rate alone can't account for such a large speed difference. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2005-02-17 13:16 Message: Logged In: YES user_id=29957 I'm with mwh. This test should be enabled with an option - I'd noticed that test_subprocess took a long time, but hadn't bothered to track it down. Before releases (and at other times) I always try to make sure that I run 'make testall', but for day-to-day use, this is too slow. -- Comment By: Michael Hudson (mwh) Date: 2005-02-17 12:09 Message: Logged In: YES user_id=6656 Bog standard linux pc -- p3 933, 384 megs of ram. "$ time ./python ../Lib/test/regrtest.py test_subprocess" reports 2 minutes 7. This is a debug build, a release build might be quicker. A run of the entire test suite takes a hair over nine minutes, so 20-odd % of the time seems to be test_subprocess. It also takes ages on my old-ish ibook (600 Mhz G3, also 384 megs of ram), but that's at home and I can't time it. -- Comment By: Peter Åstrand (astrand) Date: 2005-02-17 11:50 Message: Logged In: YES user_id=344921 Tell me a bit about your type of OS and hardware. On my machine (P4 2.66 GHz with Linux), the test takes 28 seconds. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124637&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1156441 ] Solaris and Python/pykota
Bugs item #1156441, was opened at 2005-03-04 04:44 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156441&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Kelly Ormsby (ormsbyka) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris and Python/pykota Initial Comment: I have a Solaris 9 system that I have installed Python 2.4 on with the following modules: egenix-mx-base 2.0.6 jaxml3.0.1 python-snmp 3.4.3 psyco 1.4 reportlab 1.20 and postgresql 3.6.1 net-snmp 5.2.1 which are all required by pykota (a print quota management system) I am having the issue that when pykota is plugged in to my cups system, and I try to print, the print job is put on hold and printing to that printer is stopped. I tried running the pykota software from the command line to see what is causing the problem and from what I (and Jerome Alet from librelogiciel.com) can work out it is a problem with the solaris build of python. I have used gcc 3.3 and binutils 2.14 to build python. The following is what happens when I try running from the command line: #python /usr/local/pykota/pykota/pdlanalyzer.py --debug ~kelly/align.ps /home/staff/kelly/align.ps is a PostScript file Bus error (core dumped) # pkpgcounter --debug ~kelly/align.ps /home/staff/kelly/align.ps is a PostScript file Bus error (core dumped) I have attached the pdlanalyzer.py file for you to look at. Please let me know what I should do. -- >Comment By: Michael Hudson (mwh) Date: 2005-03-04 10:34 Message: Logged In: YES user_id=6656 Well, that's kind of a large module for us to pick at... Does it only crash on certain postscript files? Can you run it under a debugger/analyze a core file to see where it's crashing? Does it only crash with 2.4.0 -- can you try 2.3/release24-maint from CVS/CVS HEAD? It doesn't crash for me with any of the ps files I happen to have lying around with release24-maint head (what will soon be 2.4.1) on linux. I don't have a version 2.4.0 lying around though. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156441&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1156259 ] [2.4 regression] seeking in codecs.reader broken
Bugs item #1156259, was opened at 2005-03-03 23:29
Message generated for change (Comment added) made by doerwalter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156259&group_id=5470
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 7
Submitted By: Matthias Klose (doko)
Assigned to: Martin v. Löwis (loewis)
Summary: [2.4 regression] seeking in codecs.reader broken
Initial Comment:
[forwarded from
https://bugzilla.ubuntu.com/show_bug.cgi?id=6972 ]
This is a regression; the following script (call as
"scriptname some_textfile")
fails.
It is obvious that the file starts with a number of
random bytes from the
previous run.
Uncommenting the two #XXX lines makes the bug go away.
So does running it with
Python 2.3.5
import sys
import codecs
from random import random
data = codecs.getreader("utf-8")(open(sys.argv[1]))
df = data.read()
for t in range(30):
#XXX data.seek(0,1)
#XXX data.read()
data.seek(0,0)
dn=""
for l in data:
dn += l
if random() < 0.1: break
if not df.startswith(dn):
print "OUCH",t
print "BAD:", dn[0:100]
print "GOOD:", df[0:100]
sys.exit(1)
print "OK",len(df)
sys.exit(0)
--
>Comment By: Walter Dörwald (doerwalter)
Date: 2005-03-04 12:44
Message:
Logged In: YES
user_id=89016
How about the following patch? Unfortunately this breaks the
codec in more obscure cases. Calling seek(0, 1) should have
now effect, but with this patch it does. Maybe calling
seek() should be prohibited? Calling a seek(1, 1) in a
UTF-16 stream completely messes up the decoded text.
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-04 10:56
Message:
Logged In: YES
user_id=38388
This is obviously related to the buffer logic that Walter added
to support .readline().
In order to fix the problem, a .seek() method must be
implemented
that resets the buffers whenever called (before asking the
stream
to seek to the specified stream position).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156259&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-925152 ] buffer problem in pyexpat.c(xmlparse_GetInputContext)
Bugs item #925152, was opened at 2004-03-29 08:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925152&group_id=5470 Category: XML Group: None >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: Tobias Sargeant (tobiasjs) Assigned to: Martin v. Löwis (loewis) Summary: buffer problem in pyexpat.c(xmlparse_GetInputContext) Initial Comment: xmlparse_GetInputContext doesn't adjust the bounds of the substring it returns, leading to the python string result hanging off one or more ends of the buffer & associated nastiness. 2 line fix attached. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-03-04 15:41 Message: Logged In: YES user_id=21627 Thanks for the patch. This was just resubmitted as #1118602, which I have applied. Your patch also checks whether offset is negative; I believe this cannot happen. Committed as pyexpat.c 2.90 and 2.89.2.1 NEWS 1.1264 and 1.1193.2.31 Sorry this took so long; it would have caught my attention earlier if it was in the patches tracker, not the bugs tracker. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925152&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1156412 ] add documentation for __new__
Bugs item #1156412, was opened at 2005-03-04 13:00 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470 Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: add documentation for __new__ Initial Comment: 3.3.1 Basic customization does not document __new__. Proposed addition: __new__(cls[, ...]) Called to create a new instance of the class. __new__ is a staticmethod (special-cased so you need not declare it as such) that takes the class to be created as the first argument. The remaining arguments are those passed to the class constructor expression. The return value of __new__ should be the new object instance. Typical usage is to create a new instance of the class by invoking the superclass's __new__ method using "super(BaseClass, cls).__new__([...])" with appropriate arguments, modifying the returned instance if necessary, and then returning it. If the returned value is an instance of "cls" (the first argument to __new__), its __init__ will be invoked. Note that you need not return an instance of "cls", but if you don't, the new instance's __init__ method will not be invoked. The __new__ staticmethod is intended mainly to allow modification of immutable types like int, long, float, str and tuple. -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-03-05 01:53 Message: Logged In: YES user_id=1038590 Looks reasonable to me - but does CPython actually currently follow those rules regarding when __init__ is and isn't invoked? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1156412 ] add documentation for __new__
Bugs item #1156412, was opened at 2005-03-03 20:00 Message generated for change (Comment added) made by bediviere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470 Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: add documentation for __new__ Initial Comment: 3.3.1 Basic customization does not document __new__. Proposed addition: __new__(cls[, ...]) Called to create a new instance of the class. __new__ is a staticmethod (special-cased so you need not declare it as such) that takes the class to be created as the first argument. The remaining arguments are those passed to the class constructor expression. The return value of __new__ should be the new object instance. Typical usage is to create a new instance of the class by invoking the superclass's __new__ method using "super(BaseClass, cls).__new__([...])" with appropriate arguments, modifying the returned instance if necessary, and then returning it. If the returned value is an instance of "cls" (the first argument to __new__), its __init__ will be invoked. Note that you need not return an instance of "cls", but if you don't, the new instance's __init__ method will not be invoked. The __new__ staticmethod is intended mainly to allow modification of immutable types like int, long, float, str and tuple. -- >Comment By: Steven Bethard (bediviere) Date: 2005-03-04 09:11 Message: Logged In: YES user_id=945502 Yup, type_call in typeobject.c special-cases this behavior. See also http://sourceforge.net/tracker/?func=detail&aid=1123716&group_id=5470&atid=105470 -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-03-04 08:53 Message: Logged In: YES user_id=1038590 Looks reasonable to me - but does CPython actually currently follow those rules regarding when __init__ is and isn't invoked? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1156412 ] add documentation for __new__
Bugs item #1156412, was opened at 2005-03-04 03:00 Message generated for change (Comment added) made by orenti You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470 Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: add documentation for __new__ Initial Comment: 3.3.1 Basic customization does not document __new__. Proposed addition: __new__(cls[, ...]) Called to create a new instance of the class. __new__ is a staticmethod (special-cased so you need not declare it as such) that takes the class to be created as the first argument. The remaining arguments are those passed to the class constructor expression. The return value of __new__ should be the new object instance. Typical usage is to create a new instance of the class by invoking the superclass's __new__ method using "super(BaseClass, cls).__new__([...])" with appropriate arguments, modifying the returned instance if necessary, and then returning it. If the returned value is an instance of "cls" (the first argument to __new__), its __init__ will be invoked. Note that you need not return an instance of "cls", but if you don't, the new instance's __init__ method will not be invoked. The __new__ staticmethod is intended mainly to allow modification of immutable types like int, long, float, str and tuple. -- Comment By: Oren Tirosh (orenti) Date: 2005-03-04 18:05 Message: Logged In: YES user_id=562624 "The __new__ staticmethod is intended mainly to allow modification of immutable types like int, long, float, str and tuple." You might like to rephrase that. It gives the impression that __new__ somehow makes it possible to modify the value of an immutable object. In fact, it only allows customized creation of new instances. -- Comment By: Steven Bethard (bediviere) Date: 2005-03-04 16:11 Message: Logged In: YES user_id=945502 Yup, type_call in typeobject.c special-cases this behavior. See also http://sourceforge.net/tracker/?func=detail&aid=1123716&group_id=5470&atid=105470 -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-03-04 15:53 Message: Logged In: YES user_id=1038590 Looks reasonable to me - but does CPython actually currently follow those rules regarding when __init__ is and isn't invoked? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1105699 ] Warnings in Python.h with gcc 4.0.0
Bugs item #1105699, was opened at 2005-01-20 01:52 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105699&group_id=5470 Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: Warnings in Python.h with gcc 4.0.0 Initial Comment: (this happens for every file that includes Python.h) In file included from ../Include/Python.h:55, from ../Objects/intobject.c:4: ../Include/pyport.h:396: warning: 'struct winsize' declared inside parameter list ../Include/pyport.h:397: warning: 'struct winsize' declared inside parameter list The source lines look like this: extern int openpty(int *, int *, char *, struct termios *, struct winsize *); extern int forkpty(int *, char *, struct termios *, struct winsize *); -- >Comment By: Martin v. Löwis (loewis) Date: 2005-03-04 21:15 Message: Logged In: YES user_id=21627 What operating system is this on? struct winsize should have been included through . Then, the mentioning of it in the propotypes is not a declaration, just a reference. So if you get this warning, it probably indicates a problem with your system headers. -- Comment By: Richard Kettlewell (rjk1002) Date: 2005-01-31 16:43 Message: Logged In: YES user_id=217390 C does guarantee that all struct pointers share the same *representation* (section 6.2.5 of C99). That's not what the compiler is complaining about here. Rather, a struct declared inside a parameter list is restricted in scope to that parameter list, and so is not the same structure as one declared outside it, even if the tag is the same. The solution is to forward-declare the struct (as an incomplete type, i.e. just "struct winsize;") before any of the declarations that use it. Then the struct tag will mean the same thing in every scope. -- Comment By: Tim Peters (tim_one) Date: 2005-01-21 00:13 Message: Logged In: YES user_id=31435 The warning almost certainly means that there's no declaration of struct winsize in scope when these externs are declared. That's bad, because C doesn't guarantee that all pointers are the same size (although they are on all Python platforms I'm aware of). Some quality time with Google suggested that other projects wormed around this by #include'ing instead of , because the former but not the latter #include's where the winsize struct was defined. Beats me -- ain't a Windows problem . -- Comment By: Bob Ippolito (etrepum) Date: 2005-01-20 23:49 Message: Logged In: YES user_id=139309 Beats me, it's probably just "bad style". It's a problem because it shows up a lot in the output, so we should at least figure out how to disable this warning so that it doesn't become annoying. -- Comment By: Michael Hudson (mwh) Date: 2005-01-20 16:18 Message: Logged In: YES user_id=6656 Why is this a problem? Is it not valid C or something? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105699&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1156412 ] add documentation for __new__
Bugs item #1156412, was opened at 2005-03-03 20:00 Message generated for change (Comment added) made by bediviere You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470 Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: add documentation for __new__ Initial Comment: 3.3.1 Basic customization does not document __new__. Proposed addition: __new__(cls[, ...]) Called to create a new instance of the class. __new__ is a staticmethod (special-cased so you need not declare it as such) that takes the class to be created as the first argument. The remaining arguments are those passed to the class constructor expression. The return value of __new__ should be the new object instance. Typical usage is to create a new instance of the class by invoking the superclass's __new__ method using "super(BaseClass, cls).__new__([...])" with appropriate arguments, modifying the returned instance if necessary, and then returning it. If the returned value is an instance of "cls" (the first argument to __new__), its __init__ will be invoked. Note that you need not return an instance of "cls", but if you don't, the new instance's __init__ method will not be invoked. The __new__ staticmethod is intended mainly to allow modification of immutable types like int, long, float, str and tuple. -- >Comment By: Steven Bethard (bediviere) Date: 2005-03-04 13:19 Message: Logged In: YES user_id=945502 Good point. How about: "The __new__ staticmethod is intended mainly to allow you, in a subclass of an immutable type (like int, long, float, complex, str, unicode, or tuple), to customize instance creation." -- Comment By: Oren Tirosh (orenti) Date: 2005-03-04 11:05 Message: Logged In: YES user_id=562624 "The __new__ staticmethod is intended mainly to allow modification of immutable types like int, long, float, str and tuple." You might like to rephrase that. It gives the impression that __new__ somehow makes it possible to modify the value of an immutable object. In fact, it only allows customized creation of new instances. -- Comment By: Steven Bethard (bediviere) Date: 2005-03-04 09:11 Message: Logged In: YES user_id=945502 Yup, type_call in typeobject.c special-cases this behavior. See also http://sourceforge.net/tracker/?func=detail&aid=1123716&group_id=5470&atid=105470 -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-03-04 08:53 Message: Logged In: YES user_id=1038590 Looks reasonable to me - but does CPython actually currently follow those rules regarding when __init__ is and isn't invoked? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1156412 ] add documentation for __new__
Bugs item #1156412, was opened at 2005-03-04 13:00 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470 Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Steven Bethard (bediviere) Assigned to: Nobody/Anonymous (nobody) Summary: add documentation for __new__ Initial Comment: 3.3.1 Basic customization does not document __new__. Proposed addition: __new__(cls[, ...]) Called to create a new instance of the class. __new__ is a staticmethod (special-cased so you need not declare it as such) that takes the class to be created as the first argument. The remaining arguments are those passed to the class constructor expression. The return value of __new__ should be the new object instance. Typical usage is to create a new instance of the class by invoking the superclass's __new__ method using "super(BaseClass, cls).__new__([...])" with appropriate arguments, modifying the returned instance if necessary, and then returning it. If the returned value is an instance of "cls" (the first argument to __new__), its __init__ will be invoked. Note that you need not return an instance of "cls", but if you don't, the new instance's __init__ method will not be invoked. The __new__ staticmethod is intended mainly to allow modification of immutable types like int, long, float, str and tuple. -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-03-05 14:02 Message: Logged In: YES user_id=1038590 Close, but the phrasing's a bit awkward. Getting rid of the commas seems to fix that: "The __new__ staticmethod is intended mainly to allow you to customize instance creation in a subclass of an immutable type (like int, long, float, complex, str, unicode, or tuple)." -- Comment By: Steven Bethard (bediviere) Date: 2005-03-05 06:19 Message: Logged In: YES user_id=945502 Good point. How about: "The __new__ staticmethod is intended mainly to allow you, in a subclass of an immutable type (like int, long, float, complex, str, unicode, or tuple), to customize instance creation." -- Comment By: Oren Tirosh (orenti) Date: 2005-03-05 04:05 Message: Logged In: YES user_id=562624 "The __new__ staticmethod is intended mainly to allow modification of immutable types like int, long, float, str and tuple." You might like to rephrase that. It gives the impression that __new__ somehow makes it possible to modify the value of an immutable object. In fact, it only allows customized creation of new instances. -- Comment By: Steven Bethard (bediviere) Date: 2005-03-05 02:11 Message: Logged In: YES user_id=945502 Yup, type_call in typeobject.c special-cases this behavior. See also http://sourceforge.net/tracker/?func=detail&aid=1123716&group_id=5470&atid=105470 -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-03-05 01:53 Message: Logged In: YES user_id=1038590 Looks reasonable to me - but does CPython actually currently follow those rules regarding when __init__ is and isn't invoked? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1156412&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
