[issue3959] Add Google's ipaddr.py to the stdlib
Gregory P. Smith g...@krypto.org added the comment:
Consider applications that need to validate addresses (or networks,
but not both) supplied as user input:
address = ipaddr.IP(input)
if isinstance(address, ipaddr.IPv4):
if address.prefixlen != 32:
raise TypeError(Expecting IP address, not network)
elif isinstance(address, ipaddr.IPv6):
if address.prefixlen != 128:
raise TypeError(Expecting IP address, not network)
Support for this can be added (its too late for Python 3.1). User
input validation is a good use case. For now I suggest the simpler
code:
if '/' in input:
raise TypeError(Expecting IP address)
address = ipaddr.IP(input)
Or for a more pedantic test prior to calling ipaddr.IP.
if re.match('^[0-9a-fA-F:.]+$', input):
raise TypeError(Invalid characters in IP address)
Please file a feature request on bugs.python.org for this one if you
haven't already. We could add optional parameter(s) to ipaddr.IP to
enable only accepting host addresses or network addresses in the
future.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3959
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
Martin v. Löwis mar...@v.loewis.de added the comment: I'd like to see the issues fixed upstream, and the library removed from Python until it is satisfactory to the developers who will actually use it. To my knowledge, every developer (outside of Google) who has commented on the issue has indicated a preference for a different API. That's not true - I'm outside of Google, and have not indicated such a preference. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6173] Minor typo in socket.py
Changes by Pablo Torres Navarrete tn.pa...@gmail.com: -- versions: +Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6173 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
Clay McClure c...@daemons.net added the comment: On Tue, Jun 2, 2009 at 2:18 AM, Martin v. Löwis rep...@bugs.python.org wrote: I'd like to see the issues fixed upstream, and the library removed from Python until it is satisfactory to the developers who will actually use it. To my knowledge, every developer (outside of Google) who has commented on the issue has indicated a preference for a different API. That's not true - I'm outside of Google, and have not indicated such a preference. You've indicated no preference either way, and have said: I personally have no plans for using this library, or any other IP address library I should think you would seek the opinion of those developers who actually do have plans to use an IP address library. As far as I can tell, every developer in that category, outside of Google, that has commented on this issue here or in python-dev has advocated a different API. Clay -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
pmoody pyt...@hda3.com added the comment: I should think you would seek the opinion of those developers who actually do have plans to use an IP address library. That's what this has been doing for the last 8 1/2 months. As far as I can tell, every developer in that category, outside of Google, that has commented on this issue here or in python-dev has advocated a different API. Is there some sort of conspiracy theory-ish reason that a google software engineer might be somehow unfairly influenced? Cheers, /peter -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6170] Mac 'make frameworkinstall' error: [...]/Python.framework/Versions/3.1/bin/2to3: Too many levels of symbolic links
Ned Deily n...@acm.org added the comment: The URL you provide for the log doesn't seem to be accessible externally so it is difficult to guess exactly what was being done. However, there were changes between 3.1b2 and 3.1rc1 to the top-level Makefile (Makefile.pre.in) and to the Mac/Makefile.in affecting framework builds and installs. -- nosy: +nad, ronaldoussoren ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6170 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6172] 'make framework...' fails on Mac ([...]/bin/pythonw3.1: No such file or directory)
Ned Deily n...@acm.org added the comment: See also Issue6170. -- nosy: +nad, ronaldoussoren ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6172 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6173] Minor typo in socket.py
Mark Dickinson dicki...@gmail.com added the comment: Thanks! Fixed in r73138, r71739, r71740, r71741. -- nosy: +marketdickinson resolution: - fixed stage: - committed/rejected status: open - closed type: - behavior versions: +Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6173 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6173] Minor typo in socket.py
Mark Dickinson dicki...@gmail.com added the comment: Sorry. Those revision numbers should be: r73138, r73139, r73140, r73141. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6173 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6175] inet_aton documentation kind of lies
New submission from Daniel Svensson dsvens...@gmail.com: The documentation for inet_aton specifically says that it's used to Convert an IPv4 address from dotted-quad string format. This however is not really true, it does accept dotted-quad, but not dotted-quad alone, but also these forms from inet(3) man page: a.b.c.d Each of the four numeric parts specifies a byte of the address; the bytes are assigned in left-to-right order to produce the binary address. a.b.c Parts a and b specify the first two bytes of the binary address. Part c is interpreted as a 16-bit value that defines the rightmost two bytes of the binary address. This notation is suitable for specifying (outmoded) Class B network addresses. a.b Part a specifies the first byte of the binary address. Part b is interpreted as a 24-bit value that defines the rightmost three bytes of the binary address. This notation is suitable for specifying (outmoded) Class C network addresses. a The value a is interpreted as a 32-bit value that is stored directly into the binary address without any byte rearrangement. Sure, it references the man-page, but if anything it should say among the formats it supports, dotted-quad is *one* of them. http://docs.python.org/library/socket.html#socket.inet_aton -- assignee: georg.brandl components: Documentation messages: 88725 nosy: dsvensson, georg.brandl severity: normal status: open title: inet_aton documentation kind of lies versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6175 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6170] Mac 'make frameworkinstall' error: [...]/Python.framework/Versions/3.1/bin/2to3: Too many levels of symbolic links
Tarek Ziadé ziade.ta...@gmail.com added the comment: Sorry I can't reproduce it, can you tell me how you run configure precisely ? eg the whole set of commands after a fresh checkout -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6170 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6172] 'make framework...' fails on Mac ([...]/bin/pythonw3.1: No such file or directory)
Ronald Oussoren ronaldousso...@mac.com added the comment: I cannot reproduce this with the py3k branch, I'm currently building r31rc1 to check if I can reproduce the issue with that. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6172 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6170] Mac 'make frameworkinstall' error: [...]/Python.framework/Versions/3.1/bin/2to3: Too many levels of symbolic links
Ronald Oussoren ronaldousso...@mac.com added the comment: I also cannot reproduce this, using both the py3k branch and the r31rc1 tag. My build procedure: * cd r31rc1 * mkdir build * cd build * ../configure --enable-framework --enable-universalsdk * make * make install DESTDIR=$PWD/image The resulting framework in the $DESTDIR seems to be complete, and I don't get errors while building it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6170 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6170] Mac 'make frameworkinstall' error: [...]/Python.framework/Versions/3.1/bin/2to3: Too many levels of symbolic links
Ronald Oussoren ronaldousso...@mac.com added the comment: Now I'm really confused, I tried to install a second time and this time I do get an error. Time to start hunting down an issue... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6170 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6170] Mac 'make frameworkinstall' error: [...]/Python.framework/Versions/3.1/bin/2to3: Too many levels of symbolic links
Tarek Ziadé ziade.ta...@gmail.com added the comment: Ronald, did you try Sridar precise sequence after Pyhon was built ? make frameworkinstallframework DESTDIR=image make frameworkinstallapps DESTDIR=image make frameworkinstall frameworkinstallextras DESTDIR=image -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6170 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6172] 'make framework...' fails on Mac ([...]/bin/pythonw3.1: No such file or directory)
Ronald Oussoren ronaldousso...@mac.com added the comment: The build was quicker than expected. I also cannot reproduce using r31rc1. Or rather, I can reproduce this using make frameworkinstallframework, but not using make install. The latter is the correct way to install the framework, the former is an internal makefile target that is used during installation but should not be used on its own. Closing this as won't fix. -- resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6172 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6170] Mac 'make frameworkinstall' error: [...]/Python.framework/Versions/3.1/bin/2to3: Too many levels of symbolic links
Ronald Oussoren ronaldousso...@mac.com added the comment: Manually running make frameworkinstallframework (and the other ones) is not supported, those are internal makefile targets that are are used to implement make install. make framworkinstall is supported as an alias for make install because the former was the only way to install a framework for a long time. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6170 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6153] email parsing - Rare Failure
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: This is a duplicate of issue170. -- nosy: +amaury.forgeotdarc resolution: - duplicate status: open - closed superseder: - email parser incorrectly breaks headers with a CRLF at 8192 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6153 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4829] confusing error for file(foo, w++)
Ulrich Eckhardt eckha...@satorlaser.com added the comment:
Good catch, it just took me a while to actually figure out myself where
the bug is. Try the following instead:
import io
io.FileIO('foo.text', 'w++')
This will yield ValueError: Must have exactly one of read/write/append
mode with 2.6 on win32. I haven't tested on the latest 2.x or 3.x
branches, but looking at the 2.7 branch, I see the faulty code is still
there.
BTW:
Using io.open('foo.text', 'w++') yields ValueError: invalid mode:
'w++', I would have expected the same error as for io.FileIO() above.
Using open('foo.text', 'w++') works.
Using open('foo.text', 'ww++') yields IOError: [Errno 22] invalid mode
('ww++') or filename: 'foo.text').
In other words, Python 2.6 is behaving a bit inconsistent here. The
patch only fixes one of those issues, the others and the necessary unit
tests remain.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4829
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6176] Reference to a wrong version of flock's documentation
New submission from Pascal Chambon chambon.pas...@gmail.com: It seems that the flock wrapped by the fcntl module is the one descriebd in flock(2), not flock(3) (just in case this might confuse people...) Quote : fcntl.flock(fd, op) Perform the lock operation op on file descriptor fd (file objects providing a fileno() method are accepted as well). See the Unix manual flock(3) for details. (On some systems, this function is emulated using fcntl.) Regards, Pascal -- assignee: georg.brandl components: Documentation messages: 88735 nosy: georg.brandl, pakal severity: normal status: open title: Reference to a wrong version of flock's documentation versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6176 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6170] Mac 'make frameworkinstall' error: [...]/Python.framework/Versions/3.1/bin/2to3: Too many levels of symbolic links
Ronald Oussoren ronaldousso...@mac.com added the comment: I found the issue. In r72899 antoine.pitrou checked in a change that adds these two lines to the bininstall target in Makefile.pre.in: -rm -f $(DESTDIR)$(LIBPC)/python3.pc (cd $(DESTDIR)$(LIBPC); $(LN) -s python-$(VERSION).pc python3.pc) This exposes a bug in the configure script, which causes target 'bininstall' to run before 'libainstall' when your doing a framework install. The latter target is the one that creates python- $(VERSION).pc, which is why we get build failures. What I don't understand is why I've been able to install frameworks all along and didn't notice this before. I'm working on a patch, and will check that in after I've full tested it. The important bit of the patch is this change to configure.in: - FRAMEWORKALTINSTALLFIRST=frameworkinstallstructure bininstall maninstall + FRAMEWORKALTINSTALLFIRST=frameworkinstallstructure -- components: +Macintosh -2to3 (2.x to 3.0 conversion tool), Distutils ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6170 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6170] Mac 'make frameworkinstall' error: [...]/Python.framework/Versions/3.1/bin/2to3: Too many levels of symbolic links
Ronald Oussoren ronaldousso...@mac.com added the comment: This should be fixed in r73142, please test. -- resolution: - fixed status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6170 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6136] Make logging configuration files easier to use
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: Re. point (a): The configuration logic assumes that if you put things in the configuration file, you want them included - that means instantiating handlers, which will generally open their output files (uness the delay parameter is set) and sockets. If you use append semantics for files and configure levels as you want them, the files are opened but not written to (and closed when the handlers are closed or the application exits). This is not a bug, as it was designed to work like this. Re. point (b): Agreed that the presence of the sections may not seem necessary as you could achieve the same with loggers=, handlers= etc. The sections were originally placed there as a place to hang other settings which could apply across loggers, handlers etc. - which never materialised. In any case, it's not a big problem and not worth breaking backward compatibility for. The qualname is not always the same as the value in the section header - see the documentation for an example of this, search for compiler.parser. The values in e.g. the section header and the handlers= section are just names to allow the configuration to cross-refer different parts of the configuration - so you could use h1, h2 etc. as handler names. Re. point (c): there are alternative ways of configuring logging; for one example, see http://www.red-dove.com/python_config.html and look at logconfig.cfg and logconfig.py in the linked tarball/zip. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5230] pydoc reports misleading failure if target module raises an ImportError
Lucas Prado Melo lukepada...@gmail.com added the comment: Take a look at the output: $ python pydoc.py test.pydoc_badimport2 problem in test.pydoc_badimport2 - type 'exceptions.ImportError': No module named i_dont_exist.neither_do_i This is different from what you expected. How do we change this output? (I was talking about this issue in the last message) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5230 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5230] pydoc reports misleading failure if target module raises an ImportError
R. David Murray rdmur...@bitdance.com added the comment:
I'm sorry, I mistyped. That is the error message I was expecting (it's
derived from the one 'import' gives in that case). If the test were
like this:
elif exc is ImportError and str(value).endswith(path.split('.')[-1]):
then I think the tests would pass (but I haven't checked yet).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5230
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6117] Fix O(n**2) performance problem in socket._fileobject
Kristján Valur Jónsson krist...@ccpgames.com added the comment: Checked into trunk as r73145 -- assignee: - georg.brandl components: +Documentation nosy: +georg.brandl resolution: - accepted ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6117 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6117] Fix O(n**2) performance problem in socket._fileobject
Changes by Kristján Valur Jónsson krist...@ccpgames.com: -- stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6117 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
Clay McClure c...@daemons.net added the comment: On Tue, Jun 2, 2009 at 2:52 AM, pmoody rep...@bugs.python.org wrote: As far as I can tell, every developer in that category, outside of Google, that has commented on this issue here or in python-dev has advocated a different API. Is there some sort of conspiracy theory-ish reason that a google software engineer might be somehow unfairly influenced? From reading your comments and the code, it is clear that concepts that aren't relevant at Google have been neglected. For that reason, developers at Google who are already familiar with ipaddr might consider its API quite natural because of their institutionalized thinking. But since this library is now intended for general purpose use outside Google, I should think it is important to consult developers outside Google who have been exposed to a broader range of IP addressing issues. I don't believe that good enough for Google ought to be our acid test. The fact that developers outside Google seem to prefer a different API is not new -- comments in this issue dating back several months reflect that fact. What I don't see is a comment that explains why their concerns were not considered. Clay -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6142] Distutils doesn't remove .pyc files
James purplei...@gmail.com added the comment: Currently, I have (had) a make file with a clean target that would remove these files. Would you recommend keeping this file and it's associated functionality, or is the idea to be able to integrate this into distutils and be able to do away with makefiles for python projects? I'm aware that I can subclass Command and make my own target... I've done this, but it seems to me it's better suited upstream. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6142 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1943] improved allocation of PyUnicode objects
Marc-Andre Lemburg m...@egenix.com added the comment: Jim Jewett wrote: Jim Jewett jimjjew...@users.sourceforge.net added the comment: There were a number of patches to support sharing of data between unicode objects. (By Larry Hastings?) They were rejected because (a) they were complicated, and (b) it was possible to provoke pathological memory retention. Right, but the patches were targeting the main Unicode type implementation. It would certainly be possible to implement these features on a Unicode sub-type. Note that the Unicode type implementation on which the Python type is based did in fact use references to other objects in order to implement sharing. This part was removed from the base type due to the issues with unwillingly keeping alive large reference objects. However, the implementation can be used as basis for writing a Unicode sub-type which does implement data sharing. If you're looking for application space where such data sharing types are useful, have a look at parsing engines or routines that split larger chunks of data in multiple smaller pieces. Shared memory is another use case where such types would enable sharing of Unicode data between processes... but I'm repeating myself. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1943] improved allocation of PyUnicode objects
Marc-Andre Lemburg m...@egenix.com added the comment: Antoine Pitrou wrote: Antoine Pitrou pit...@free.fr added the comment: There were a number of patches to support sharing of data between unicode objects. (By Larry Hastings?) They were rejected because (a) they were complicated, and (b) it was possible to provoke pathological memory retention. Yes, it's the lazy strings patches by Larry Hastings (it was for str, not unicode, though). Issues are #1590352 and #1569040 (and perhaps others). In any case, as I said, it is easy to switch back to the old representation, so I don't think it is an argument to block this patch. That's not the case. The patch breaks C API + binary compatibility for an essential Python type - that's not something you can easily undo. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1943] improved allocation of PyUnicode objects
Antoine Pitrou pit...@free.fr added the comment: The patch breaks C API + binary compatibility for an essential Python type - that's not something you can easily undo. I don't see how it breaks C API compatibility. No officially documented function has changed, and the accessor macros still work. Am I missing something? As for binary compatibility, yes, it does break it, which isn't an exceptional situation in the development process. We have changed other essential types too -- for example, recently, the PyLong object got 30-bit digits on some systems. Why you think it is hard to undo, I don't understand. As for the future ABI PEP, which has not yet been accepted, it does not mention PyUnicodeObject as part of the structures which are guaranteed to remain binary-compatible : http://www.python.org/dev/peps/pep-0384/#structures -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1943] improved allocation of PyUnicode objects
Changes by Eric Smith e...@trueblade.com: -- nosy: +eric.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6177] unittest.main testRunner default argument changed from None
New submission from Michael Foord mich...@voidspace.org.uk: In Python 2.6 the testRunner keyword argument to unittest.main (TestProgram) changed from None to TextTestRunner. This breaks test suites (like the setuptools tests) which pass in None when not wanting to override the default. This is easy to fix without breaking anything (but hard to test). I will be fixing this and backporting to 2.6-maint unless there are objections. -- assignee: michael.foord components: Library (Lib) keywords: easy messages: 88747 nosy: michael.foord severity: normal status: open title: unittest.main testRunner default argument changed from None type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6177 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6177] unittest.main testRunner default argument changed from None
Changes by Tarek Ziadé ziade.ta...@gmail.com: -- nosy: +tarek ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6177 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6178] Core error in Py_EvalFrameEx 2.6.2
New submission from Tim Savannah tsava...@arinc.com: I'm getting many segmentation faults (about 1 per half hour) from within the core of python 2.6.2 on 64-bit machines. (examples from dmesg: pythonLaunch.py[13307]: segfault at 0058 rip 2b845cfb3550 rsp 41809930 error 4 pythonLaunch.py[27589]: segfault at 0058 rip 2b4112287906 rsp 42dab930 error 4 pythonLaunch.py[14436]: segfault at 0058 rip 2ae0a4f68550 rsp 42cd9930 error 4 pythonLaunch.py[10374]: segfault at 0058 rip 2af43f966906 rsp 4214b930 error 4 pythonLaunch.py[17656]: segfault at 0058 rip 2aed0cfe8906 rsp 417f0930 error 4 ) pythonLaunch.py is a symbolic link to python 2.6.2 binary. From disassembling the python binary, I've found the corrosponding line in source to be ceval.c:2717 if (tstate-frame-f_exc_type != NULL) tstate-frame is null, and an access on f_exc_type causes a segfault (trying to access memory 0x58, see above segfaults). I can't find any clear code path that could cause tstate-frame to go null, any suggestions? This is preventing us from moving from python 2.4 32-bit to python 2.6 64-bit. -- components: Interpreter Core messages: 88748 nosy: tsavannah severity: normal status: open title: Core error in Py_EvalFrameEx 2.6.2 type: crash versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6178 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6178] Core error in Py_EvalFrameEx 2.6.2
Antoine Pitrou pit...@free.fr added the comment: Have you compiled Python yourself? Are you using any third-party C extensions? -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6178 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6178] Core error in Py_EvalFrameEx 2.6.2
Tim Savannah tsava...@arinc.com added the comment: Yes I compiled python myself, using ./configure --prefix=/usr/local/python2.6/ --with-pth --enable-shared It is a 64-bit compile. I've done this with both standard config and a config that I modded which produces optimizations options as -ggdb3 -O0. Both contain the segfault error. We are including some external site packages, but there is no consistent site package import or usage that causes the segfault, it just seems that heavy stress with many threads going off has a race chance to cause it. I can send any additional info that can help debug this issue -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6178 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1943] improved allocation of PyUnicode objects
Marc-Andre Lemburg m...@egenix.com added the comment: Antoine Pitrou wrote: Antoine Pitrou pit...@free.fr added the comment: The patch breaks C API + binary compatibility for an essential Python type - that's not something you can easily undo. I don't see how it breaks C API compatibility. No officially documented function has changed, and the accessor macros still work. Am I missing something? Yes: The layout and object type of the PyUnicodeObject object. You cannot simply recompile your code and have it working. Instead, you have to provide different sub-typing implementations depending on whether PyUnicodeObject is a PyVarObject or PyObject, since these are inherently different in their structure. Please note that all type objects documented in the header files not explicitly declared for private use only, are in fact public APIs. You need access to those type objects in order to be able to subclass them. As for binary compatibility, yes, it does break it, which isn't an exceptional situation in the development process. We have changed other essential types too -- for example, recently, the PyLong object got 30-bit digits on some systems. Why you think it is hard to undo, I don't understand. That's a different kind of change. Even though it's very hard to sub-type longs due to their PyVarObject nature and the fact that longs even dig into the PyObject_VAR_HEAD, you can still recompile your code and it will continue to work. The change was to a typedef - the name of the typedef itself has not changed. This is similar to compiling Python as UCS2 or UCS4 version - Py_UNICODE will stay the same typedef, but on a UCS2 system it maps to 16 bits, whereas on a UCS4 system it is set to 32 bits. Note that the Unicode implementation takes great care not to hide this binary incompatibility - by remapping all APIs to include the UCS2/UCS4 hint in the exported name. As an side: The long implementation does not. As for the future ABI PEP, which has not yet been accepted, it does not mention PyUnicodeObject as part of the structures which are guaranteed to remain binary-compatible : http://www.python.org/dev/peps/pep-0384/#structures That's fine, but please note that the ABI PEP only addresses applications that wish to benefit from the binary compatibility across Python versions. It has no implications on applications that don't want to use the ABI or cannot, since they are too low-level, such as extensions wishing to sub-class built-in types. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
Gregory P. Smith g...@krypto.org added the comment: This issue is closed. Please take discussion up on a mailing list. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3959] Add Google's ipaddr.py to the stdlib
Changes by Alexander Belopolsky belopol...@users.sourceforge.net: -- nosy: +belopolsky ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1943] improved allocation of PyUnicode objects
Antoine Pitrou pit...@free.fr added the comment: You cannot simply recompile your code and have it working. Who is you? People doing mundane things with PyUnicodeObjects certainly can, assuming they use the macros for any member access. Please note that all type objects documented in the header files not explicitly declared for private use only, are in fact public APIs. If the datatype layout is not publicly documented in the API reference, it certainly seems to be a non-public part of the API. That's why we have macros for member access, instead of letting people access members directly. The fact that my patch doesn't touch any part of the C sources except for the unicode implementation itself seems to support this view as well: people have been using the macros because they understand the actual layout shouldn't be relied upon. You need access to those type objects in order to be able to subclass them. As is needed for every other core object whose layout is nevertheless changed now and then... I think it should be expected that any code relying on low-level implementation specifics can break now and then. Changing low-level implementation specifics is often a prerequisite for improving things and it would be foolish to make a promise that we guarantee 100% compatibility at that level. (we could of course strengthen the rules for unicode if it was demonstrated that there are several popular instances of subclassing unicode in a C extension. However, I haven't seen any such examples) Note that the Unicode implementation takes great care not to hide this binary incompatibility - by remapping all APIs to include the UCS2/UCS4 hint in the exported name. That's because there are UCS2 and UCS4 builds *of the same interpreter version*, and people are not necessarily aware of there being a difference. Such variability is not what we are talking about here. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6178] Core error in Py_EvalFrameEx 2.6.2
Antoine Pitrou pit...@free.fr added the comment: If the third-party packages include some C extensions, have they been recompiled with the new Python build? Also, does the segfault disappear if you disable optimizations? Have you tried with another compiler version? (I'm asking all this because to my knowledge it's the first time such random crashes happen in the Python core with 2.6, which was released quite a while ago) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6178 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6156] Error compiling valid regex
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti versions: +Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6156 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6178] Core error in Py_EvalFrameEx 2.6.2
Tim Savannah tsava...@arinc.com added the comment: All site-packages were compiled against python 2.6.1, and python was upgraded later to 2.6.2 (but upon running a make install with python 2.6.2, it seemed to recompile site-packages on a byte-code level). And no, there is still segfaults without optimizations, I've tried at -O2 -O and -O0 ( -O0 being no optimization). Judging by the invalid read always being on 0x58, and the line of assembly accessing 0x58 offset from a register, tstate-frame must be being initilized to NULL (or always being corrupted to point to other NULL data) The compiler used is gcc version 4.1.2 20071124 (Red Hat 4.1.2-42) The setup we are using is 8-core xeon 64-bit servers. (We have about 14 of these, Centos based systems, all are experiencing the segfaults). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6178 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6126] Python 3 pdb: shows internal code, breakpoints don't work
Eric Promislow er...@activestate.com added the comment: Similar problem with 3.1rc1: C:\...c:\Python31rc1\python.exe -m pdb hello01.py --Return-- c:\python31rc1\lib\encodings\cp437.py(19)encode()-b'Hello' - return codecs.charmap_encode(input,self.errors,encoding_map)[0] (Pdb) b 2 *** Blank or comment (Pdb) b hello01.py:2 Breakpoint 1 at c:\...\hello01.py:2 (Pdb) b Num Type Disp Enb Where 1 breakpoint keep yes at c:\...\hello01.py:2 (Pdb) c Hello here bye The program finished and will be restarted --Return-- c:\python31rc1\lib\encodings\cp437.py(19)encode()-b'Hello' - return codecs.charmap_encode(input,self.errors,encoding_map)[0] (Pdb) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6126 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6177] unittest.main testRunner default argument changed from None
Michael Foord mich...@voidspace.org.uk added the comment: Patch attached. -- keywords: +patch Added file: http://bugs.python.org/file14155/fix_unittest_main.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6177 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1244929] hide tests from TestProgram
Michael Foord mich...@voidspace.org.uk added the comment: A module can now define load_tests (used by loadTestsFromModule) and exclude certain classes itself. -- resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1244929 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6177] unittest.main testRunner default argument changed from None
Barry A. Warsaw ba...@python.org added the comment: Feel free to apply this to 2.6. -- nosy: +barry resolution: - accepted ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6177 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6177] unittest.main testRunner default argument changed from None
Michael Foord mich...@voidspace.org.uk added the comment: Committed to trunk in revision 73151 and revision 73152. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6177 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1207] Load tests from path (patch included)
Michael Foord mich...@voidspace.org.uk added the comment: Similar functionality is now in TestLoader.discover. -- resolution: - rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1207 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2919] Merge profile/cProfile in 3.0
Changes by Jean Brouwers mrje...@gmail.com: Removed file: http://bugs.python.org/file14131/profile_module.tgz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2919 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2919] Merge profile/cProfile in 3.0
Jean Brouwers mrje...@gmail.com added the comment: Fixed a couple of typos in the README and _profile_hires.c files of the attached profile_module2.tgz tar ball. -- Added file: http://bugs.python.org/file14156/profile_module2.tgz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2919 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6136] Make logging configuration files easier to use
Geoffrey Bache gjb1...@users.sourceforge.net added the comment: a) What is the point of opening files that will never be written to and sockets that will never be used? A large application might have a great many loggers for debugging which are off by default, and this means you have to either put up with lots of empty files being created all the time, or tell everyone that they need to change the configuration in two places each time they enable or disable a logger. Logging config files need to be easy to tweak, even for people who aren't coders: it should be quick and obvious how to enable or disable a logger. b) I don't see why making those sections optional would break backward compatibility. It would be easy to just silently ignore them if they were present (or call today's code that uses them). I'm aware that qualname isn't always the same as the section name. My point is that it should not be *compulsory*, not that it shouldn't exist. It has an obvious default value so it's wrong to fail with a python stack if it isn't present. c) I know there are other packages out there. I've been using log4py for years, which is now abandoned. But Python now has an official way to do logging and I think it should be more user-friendly for simple usage than it is. I can write my own config file format without too much difficulty but it seems a shame if everyone ends up doing this. (The one you linked to seemed to have wider ambitions than logging and its format seemed even more unwieldy. Curly braces in Python?!) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6178] Core error in Py_EvalFrameEx 2.6.2
Changes by Marshall Roach mro...@arinc.com: -- nosy: +mroach ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6178 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6179] Documentation of for statement in Reference says that range() returns a list
New submission from Mitchell Model m...@acm.org: The documentation of the for statement in Section 7 of the Python 3 Reference states range(3) returns the list [0, 1, 2]. Since range() no longer returns a list, shouldn't this statement be made more precise? (since this is the reference it should be technically accurate) -- assignee: georg.brandl components: Documentation messages: 88764 nosy: MLModel, georg.brandl severity: normal status: open title: Documentation of for statement in Reference says that range() returns a list versions: Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6179 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
Changes by Brett Cannon br...@python.org: -- stage: - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6154 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6180] Tkinter.Entry: fix for xview and some doc clarifications
New submission from Guilherme Polo ggp...@gmail.com: The xview method in Tkinter.Entry doesn't indicate that index may be None, which is used to query the Entry xview. I also considered that the docstrings in the selection_range and selection_present methods needed some clarifications, so the attached patch also fixes this. -- components: Tkinter files: Entry_fixes.diff keywords: patch messages: 88765 nosy: gpolo severity: normal status: open title: Tkinter.Entry: fix for xview and some doc clarifications versions: Python 2.7, Python 3.1 Added file: http://bugs.python.org/file14157/Entry_fixes.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6180 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6181] Tkinter.Listbox several minor issues
New submission from Guilherme Polo ggp...@gmail.com: Hi there, I've found several minor issues in Tkinter.Listbox which are all fixed by the attached patch. I'm considering the bbox method should be clear in relation to the amount of accepted arguments, which is always one. So I dropped the *args usage there. The curselection method has a reminder about applying getints on it, I have done it now. I think it is fine to finally fix it, since we have some tests for it now (at least in the tk_and_idle_maintenance branch). The remaining changes in the patch are all about fixing docstring of several methods in Listbox. -- components: Tkinter files: Listbox_fixes.diff keywords: patch messages: 88766 nosy: gpolo severity: normal status: open title: Tkinter.Listbox several minor issues versions: Python 2.7, Python 3.1 Added file: http://bugs.python.org/file14158/Listbox_fixes.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6181 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1943] improved allocation of PyUnicode objects
Marc-Andre Lemburg m...@egenix.com added the comment: Here's an example implementation of a Unicode sub-type that allows referencing other Unicode objects: http://downloads.egenix.com/python/unicoderef-0.0.1.tar.gz As you can see, it's pretty straight-forward to write and I want to keep it that way. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1943] improved allocation of PyUnicode objects
Marc-Andre Lemburg m...@egenix.com added the comment: Antoine Pitrou wrote: Antoine Pitrou pit...@free.fr added the comment: You cannot simply recompile your code and have it working. Who is you? People doing mundane things with PyUnicodeObjects certainly can, assuming they use the macros for any member access. As soon as they want to do C-level sub-typing, a change from PyObject to PyVarObject will break their code in non-trivial ways. Please note that all type objects documented in the header files not explicitly declared for private use only, are in fact public APIs. If the datatype layout is not publicly documented in the API reference, it certainly seems to be a non-public part of the API. That's why we have macros for member access, instead of letting people access members directly. Header files *are* the API reference. There are many instances where they include things that are only meant to be used internally by the interpreter, but these are carefully documented in the header files. You need access to those type objects in order to be able to subclass them. As is needed for every other core object whose layout is nevertheless changed now and then... I think it should be expected that any code relying on low-level implementation specifics can break now and then. Changing low-level implementation specifics is often a prerequisite for improving things and it would be foolish to make a promise that we guarantee 100% compatibility at that level. It would be foolish to break such compatibility for the sake of some really minor performance win. Python's main focus is flexibility, not speed. Your proposed change makes it a lot harder to tap into the available flexibility, since sub-typing of PyVarObjects is non-trivial. (we could of course strengthen the rules for unicode if it was demonstrated that there are several popular instances of subclassing unicode in a C extension. However, I haven't seen any such examples) Well, since you don't appear to count the many attempts to get slicing-by-reference into the base type as proof that such ideas do have use-cases, I've posted an example implementation which provides such a sub-type. It's easy to extend to all the use cases I've mentioned so far. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
Benjamin Peterson benja...@python.org added the comment: Here's another patch. -- Added file: http://bugs.python.org/file14159/locale_fix.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6154 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4806] Function calls taking a generator as star argument can mask TypeErrors in the generator
Kenneth Arnold kenneth.arn...@gmail.com added the comment: I can confirm that (a) this exact behavior is happening and (b) it quite confused me (most of the time it works!). What would be a good TypeError? I'd vote for generators to be explicitly supported even if it required a special case. Thanks! -- nosy: +kcarnold ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4806 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
Evan Behar beh...@gmail.com added the comment:
I think I've found the problem.
In configure:
13830 if test ${ac_cv_lib_intl_textdomain+set} = set; then
13831 echo $ECHO_N (cached) $ECHO_C 6
13832 else
13833 ac_check_lib_save_LIBS=$LIBS
13834 LIBS=-lintl $LIBS
but then
13883 rm -f core conftest.err conftest.$ac_objext
conftest_ipa8_conftest.oo \
13884 conftest$ac_exeext conftest.$ac_ext
13885 LIBS=$ac_check_lib_save_LIBS
ac_check_lib_save_LIBS is assigned before -lintl is added to LIBS, and
then LIBS is unconditionally re-assigned to ac_check_lib_save_LIBS a
little bit further down, which then doesn't have -lintl in it.
I've included a patch that changes this to be:
...
13880 ac_cv_lib_intl_textdomain=no
13881 LIBS=$ac_check_lib_save_LIBS
13882 fi
13883
13884 rm -f core conftest.err conftest.$ac_objext
conftest_ipa8_conftest.oo \
13885 conftest$ac_exeext conftest.$ac_ext
13886 fi
So that LIBS is only restored to the saved state if the check fails.
I'm not sure if mucking with the configure file directly is a great
idea, but this was the simplest thing I could think of that would work.
--
nosy: +ebehar
Added file: http://bugs.python.org/file14160/configure_lintl.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6154
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6136] Make logging configuration files easier to use
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: a) Loggers don't have a one-to-one correspondence to files that are opened, so I don't quite understand your point. Perhaps you are conflating loggers with handlers. The common way of using logging is to have a small number of file-based handlers and perhaps a socket handler and console handler, working with a potentially much larger number of loggers. b) If you want to propose a patch (incl. tests and docs) which maintains backward compatibility, I'll certainly look at it. the qualname *is* compulsory as it determines exactly which logger is instantiated. So I don't understand your statement. c) Having used log4py (which I'm not familiar with), it may be that you have to consider that Python's logging package might do some things differently. You are of course free to use your own configuration format - it's one of those areas where personal taste is more of a factor. I don't know of any alternative formats which have a lot of traction for configuring logging specifically, though the programmatic API for configuring logging is pretty simple and almost any other configuration approach could be made to fit. It's funny to hear you comment on the inappropriateness of curly braces in Python, how do you manage without dict literals? ;-) It's probably best not to continue this discussion on the issue tracker - it's not the best place as it's not its intended purpose, and also the audience here will be much smaller than, say, comp.lang.python. Before rolling your own config format, I would suggest posting on c.l.py with your difficulties with logging configuration and see how others have coped with those or similar problems. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6136 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
Evan Behar beh...@gmail.com added the comment: I applied Benjamin's new patch to the original files, but I receive the same error, and the LIBS in the Makefile still only has -ldl and not -lintl. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6154 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1943] improved allocation of PyUnicode objects
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: Mark, I'm inclined to agree that this would be a destabilizing change. Guido, do you care to pronounce on whether it is okay to change the struct? -- assignee: - gvanrossum nosy: +gvanrossum, rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1943] improved allocation of PyUnicode objects
Guido van Rossum gu...@python.org added the comment: If this is not yet in 3.1, it's clearly too late to add it (now that RC1 was already released). If was in already (hard to tell from the long bug), I think it should be kept in (removing it would destabilize more than keeping it). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1943] improved allocation of PyUnicode objects
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: It's not in 3.1. It is a proposal for 3.2 that changes the struct from what it is in 3.0 and 3.o. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1943] improved allocation of PyUnicode objects
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: Correction: It is a proposal for 3.2 that changes the struct used in 3.0 and 3.1. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1943] improved allocation of PyUnicode objects
Changes by Raymond Hettinger rhettin...@users.sourceforge.net: -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6178] Core error in Py_EvalFrameEx 2.6.2
Antoine Pitrou pit...@free.fr added the comment: And no, there is still segfaults without optimizations, I've tried at -O2 -O and -O0 ( -O0 being no optimization). Then you can try rebuilding Python after ./configure --with-pydebug. It will add some runtime checks, perhaps it will find the cause of the problem. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6178 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1943] improved allocation of PyUnicode objects
Guido van Rossum gu...@python.org added the comment: That's unfortunate; it would clearly have been easier to change this in 3.1. That said, I'm not sure anyone *should* be subclassing PyUnicode. Maybe Marc-Andre can explain why he is doing this (or point to the message in this thread where he explained this before)? If it's a viable use case, it should be possible to have some symbol or a few symbols whose presence can be tested in the preprocessor by code that needs to subclass; we should design the patch with that in mind and Marc-Andre could help testing it. All this is assuming the speed-up is important enough to bother. Has anyone run a comparison benchmark using the Unladen Swallow benchmarks? I trust those much more than micro-benchmarks (including, I assume, stringbench.py). I do expect that reducing the number of allocations for short-to-medium-size strings from 2 to 1 would be a significant speed-up, but I can't guess how much. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
Changes by Benjamin Peterson benja...@python.org: Added file: http://bugs.python.org/file14161/locale_fix2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6154 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
Brett Cannon br...@python.org added the comment: @Evan -- You need to edit configure.in and use autoconf to regenerate configure. @Benjamin -- your second patch leads to an infinite recursion or something with 'y\n' being printed out constantly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6154 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
Benjamin Peterson benja...@python.org added the comment: What about the third? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6154 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
Brett Cannon br...@python.org added the comment: I meant locale_fix2.patch causes the infinite output. Regardless, I now have my own patch that solves the problem. I simply make sure that if the check for intl passes it also added -lintl to $LIBS. You will need to run autoconf/autoheader yourself as when I ran it svn diff complained about different line endings on configure. -- Added file: http://bugs.python.org/file14162/add_lintl.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6154 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
Benjamin Peterson benja...@python.org added the comment: Does that fix framework builds, too? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6154 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6170] Mac 'make frameworkinstall' error: [...]/Python.framework/Versions/3.1/bin/2to3: Too many levels of symbolic links
Ned Deily n...@acm.org added the comment: That seems to work. However, while testing that, I found another, minor problem in that same area. In Makefile.pre.in bininstall target just before the lines you cite, there is also this added in r71935: -rm -f $(DESTDIR)$(BINDIR)/python3-config (cd $(DESTDIR)$(BINDIR); $(LN) -s python$(VERSION)-config python3- config) Prior to that, though, the Mac Makefile target install_versionedtools is mucking in the same area: if [ ! -h $(DESTDIR)$(prefix)/bin/python3-config ]; then \ mv $(DESTDIR)$(prefix)/bin/python3-config $(DESTDIR)$(prefix)/bin/python$(VERSION)-config ;\ ln -sf python$(VERSION)-config $(DESTDIR)$(prefix)/bin/python3- config ; \ fi and, in fact, the mv fails with an error because (1) the python3-config hasn't been created yet and (2) the test is incorrect: ! -h is also true if the file doesn't exist. With the code in bininstall, I think these lines can be safely removed from install_versionedtools. -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6170 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6182] Remove ipaddr library from py3k before 3.1rc2
New submission from Gregory P. Smith g...@krypto.org: Do not use this bug for discussion of the topic. Use the python-dev mailing list. This bug is here to track its removal (or not) of the ipaddr library pending the outcome of the mailing list discussion. Resolving this is a release blocker either way. According to http://www.python.org/dev/peps/pep-0375/ 3.1rc2 goes out on June 13, 2009. -- assignee: gregory.p.smith messages: 88785 nosy: gregory.p.smith priority: release blocker severity: normal status: open title: Remove ipaddr library from py3k before 3.1rc2 versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6182 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6183] test_time fails on VC6
New submission from Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp:
test_time fails on VC6 with following message.
==
FAIL: test_strptime (__main__.TimeTestCase)
--
Traceback (most recent call last):
File test_time.py, line 246, in module
test_main()
File test_time.py, line 243, in test_main
support.run_unittest(TimeTestCase, TestLocale)
File e:\python-dev\py3k\lib\test\support.py, line 879, in run_unittest
_run_suite(suite)
File e:\python-dev\py3k\lib\test\support.py, line 854, in _run_suite
result = runner.run(suite)
File e:\python-dev\py3k\lib\unittest.py, line 1490, in run
result.printErrors()
File e:\python-dev\py3k\lib\unittest.py, line 1451, in printErrors
self.printErrorList('FAIL', self.failures)
File e:\python-dev\py3k\lib\unittest.py, line 1458, in printErrorList
self.stream.writeln(%s % err)
File e:\python-dev\py3k\lib\unittest.py, line 1367, in writeln
self.write(arg)
UnicodeEncodeError: 'cp932' codec can't encode character '\x93' in
position 453:
illegal multibyte sequence
Here is quotation from
http://msdn.microsoft.com/en-us/library/fe06s4ak%28VS.71%29.aspx
Note Before this version of Visual C++, the documentation described
the format parameter of wcsftime as having the datatype const wchar_t
*, but the actual implementation of the format datatype was const
char *. In this version, the implementation of the format datatype
has been updated to reflect the previous and current documentation,
that is: const wchar_t *.
Can I apply attached patch? Thank you.
--
components: Extension Modules
files: patch_for_under_71.patch
keywords: patch
messages: 88786
nosy: ocean-city
severity: normal
status: open
title: test_time fails on VC6
versions: Python 3.1
Added file: http://bugs.python.org/file14163/patch_for_under_71.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6183
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6184] py3k build gets spurious errors from libinstall target compile of lib2to3 files
New submission from Ned Deily n...@acm.org: [...] Compiling /tmp/image/Library/Frameworks/Python.framework/Versions/3.1/lib/python3. 1/lib2to3/tests/__init__.py ... Listing /tmp/image/Library/Frameworks/Python.framework/Versions/3.1/lib/python3. 1/lib2to3/tests/data ... Compiling /tmp/image/Library/Frameworks/Python.framework/Versions/3.1/lib/python3. 1/lib2to3/tests/data/crlf.py ... *** File /Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/lib2to3 /tests/data/crlf.py, line 1 print hi ^ SyntaxError: invalid syntax Compiling /tmp/image/Library/Frameworks/Python.framework/Versions/3.1/lib/python3. 1/lib2to3/tests/data/different_encoding.py ... *** File /Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/lib2to3 /tests/data/different_encoding.py, line 3 print(u'ßàáâãäåæçèéêëìíîïðñòóôõöøùúûüýþÿÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖØÙÚÛÜÝÞ') ^ SyntaxError: invalid syntax Listing /tmp/image/Library/Frameworks/Python.framework/Versions/3.1/lib/python3. 1/lib2to3/tests/data/fixers ... [...] Seen during build on OSX 10.5: ./configure --enable-framework --enable- universalsdk=/Developer/SDKs/MacOSX10.4u.sdk make make install DESTDIR=/tmp/image -- components: 2to3 (2.x to 3.0 conversion tool), Build messages: 88787 nosy: nad severity: normal status: open title: py3k build gets spurious errors from libinstall target compile of lib2to3 files type: compile error versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6184 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6184] py3k build gets spurious errors from libinstall target compile of lib2to3 files
Benjamin Peterson benja...@python.org added the comment: Thanks! Fixed in r73160. -- nosy: +benjamin.peterson resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6184 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6179] Documentation of for statement in Reference says that range() returns a list
Benjamin Peterson benja...@python.org added the comment: Fixed in r73161. -- nosy: +benjamin.peterson resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6179 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6154] Python 3.1 rc1 will not build on OS X 10.5.7
Evan Behar beh...@gmail.com added the comment: It works fine for my framework build on 10.4.11 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6154 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6184] py3k build gets spurious errors from libinstall target compile of lib2to3 files
Ned Deily n...@acm.org added the comment: r73160 does make the spurious errors go away - along with the compiles of all the other modules! Suggest removing the spurious !'s: 926c926 -x 'bad_coding|badsyntax|site- packages|py2_test_grammar|crlf|different_encoding|' \ --- -x 'bad_coding|badsyntax|site- packages|py2_test_grammar|crlf|different_encoding' \ 931c931 -x 'bad_coding|badsyntax|site- packages|py2_test_grammar|crlf|different_encoding|' \ --- -x 'bad_coding|badsyntax|site- packages|py2_test_grammar|crlf|different_encoding' \ -- status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6184 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6184] py3k build gets spurious errors from libinstall target compile of lib2to3 files
Ned Deily n...@acm.org added the comment: er, spurious |'s -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6184 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6183] test_time fails on VC6
Martin v. Löwis mar...@v.loewis.de added the comment: Can I apply attached patch? Thank you. Looks fine to me, go ahead. -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6183 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6183] test_time fails on VC6
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp added the comment: Thanks, committed in r73162. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6183 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6185] 2to3 misses buffer slicing
Joe Amenta ament...@msu.edu added the comment: Patch that will fix the problem (and make the test pass) -- Added file: http://bugs.python.org/file14165/bufferfix.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6185 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
