Re: [Python-Dev] Python-3 transition in Arch Linux
On Fri, Nov 5, 2010 at 01:43, Stephen J. Turnbull wrote: > Thomas Wouters writes: > > > To clarify (but I dont speak for the rest of #python, just myself), I > think > > the move was premature, but I don't use Arch and I don't know what > typical > > Arch users expect. > > All of the Arch users I know expect Arch to occasionally do radical > things because they're the right things to do in the long run. But > every avant garde distribution picks up its share of wannabes who > don't understand how the process works. > > > The reason I think it's premature is that 'python2' just doesn't > > work everywhere, and I would have gone for a transitionary period > > where '/usr/bin/python' is something that screams loudly that it > > shouldn't be used before it executes 'python2'. > > This is unrealistic. It would seriously annoy Arch's intended > audience. (Eg, recently I've become a lot more favorable to using > Word instead of OOo because Word doesn't pop up a useless warning > every time I save a .doc file.) Practically speaking, it would have > to be off by default, like Python pending deprecation warnings. > Wait, what? Warning about impending brokenness is *more annoying* than just plain breaking? How on earth would the warning be "useless"? Keep in mind that the warning would only show up *if stuff would otherwise not work*. Anyway, I bet that anybody capable of upgrading their *Arch* packages > and complaining to *#python* about resulting breakage would be capable > of complaining to #python about the weird warning about python2. And > you can't have a NO /USR/BIN/PYTHON topic, can you? > Any change is disruptive. My comment wasn't about the crowd of people visiting #python and complaining, it was about the decision to change /usr/bin/python, and how it was done. However, a warning with a clear description -- for example, a link to a webpage explaining the situation -- would most assuredly have prevented many people from coming to #python in desperation. They might still have *complained*, in #python or elsewhere, but it would have been a lot clearer. > > > As for #python, well, we got this storm of people utterly confused > > about how their stuff doesn't work anymore, and putting the blame > > in the wrong place. > > How so? Ultimately, Guido is responsible for this. Sure, the immediate symptom was caused by Arch's action, but Python 3 *is* > rather incompatible with Python 2. You're going to get a storm every > time a distro changes, and in a year or two, it's no longer going to > be something you can dispose of by setting a hotkey to "Google for > 'BOGUS Linux python'" -- it's going to be stuff that requires a real > understanding of how Python 3 differs from Python 2, and often will be > pretty subtle. > > I don't think a distribution should ever cause that (even though > > many do in lesser ways) > > Sure, and Guido should have exercised the Time Machine a little harder > so that Python 3 never needed to happen. IOW, this is the price of > success and wide distribution. > No, that's not my point at all. The problem isn't that Python 3 is incompatible with Python 2. The problem is that stuff broke without (apparently) fair warning. This isn't a Python thing, this is a distribution thing: for users of a distribution, having a clear, usable migration path for incompatible changes is *important*. For users, not packagers, this means you have to slap them in the face with upcoming incompatible changes, or they won't notice. It may not be important for Arch, or for the users Arch expects to have, but it sure as hell is important to me and every sysadmin I know :) -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-3 transition in Arch Linux
On 05/11/10 18:47, Thomas Wouters wrote: No, that's not my point at all. The problem isn't that Python 3 is incompatible with Python 2. The problem is that stuff broke without (apparently) fair warning. Just to clarify (and going way off topic for this list...), this was discussed on the Arch Linux mailing lists around six months in advance, then again about two months beforehand when the rebuild started. Then it sat in our testing repository for a month where issues were discussed on our mailing lists and forums. Also a news post was made on our website front page before moving it into our main repos. With a rolling release distro we do not have the luxury of making release notes every major release so we make it abundantly clear to our users that we expect them to at least always read the front page news before updating. There are even wrapper scripts for our package manager that print the news headlines before updating. So there was warning. As always, it was just ignored by a portion of our users. Allan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Help with warnings not being raised
On Fri, Nov 5, 2010 at 11:12 AM, Jesus Cea wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 05/11/10 01:36, Benjamin Peterson wrote: >>> I don't know why. >> >> Are you passing -3 -Wall? > > I am passing "-3 -Werror", to induce the error control I have committed. Under -We, PyErr_Warn raises an exception rather than printing to stdout. That exception is clobbered by the immediately following call to PyErr_Clear. Since you *only* hit that branch under -We in the first place, a second call to PyErr_WriteUnraisable should get the error to actually print out. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pickle alternative in stdlib (Was: On breaking modules into packages)
On Fri, Nov 5, 2010 at 10:56 AM, Steven D'Aprano wrote: > Nick Coghlan wrote: > >> As a tool for communicating between different instances of the *same* >> version of Python though, pickle is fine. > > I'm using pickle to pass a list and dict of floats and strings from Python > 2.6 to 3.1. I've never had any problems with it. Am I living in a state of > sin or is that okay? Builtins are generally fine, and we do try reasonably hard to keep the pickle formats properly compatible across versions. It's corner cases (like pickling unittest objects) that may sometimes break, since pickle implicitly depends on things that *should* be disregarded as implementation details. Specifically, without explicit directions to do otherwise, pickle encodes objects based on what they *are*, which may include implementation details, such as optional acceleration modules, platform specific variants of classes returned by a factory function, etc. Technically such things are bugs in an object's pickling support, but they're *really* non-obvious (and genuinely harmless in most cases). As I see it, there are at least 3 levels of pickling support: 1. Complete, version independent (implementation details are weeded out from the pickle, or deliberately kept the same across versions to preserve pickle compatibility) 2. Partial, potentially version dependent (pickles may be infected with implementation details that affect cross-version compatibility if they happen to change) 3. None (can't even pickle it in the first place) Builtins are in category 1, but there are plenty of things in the standard library (like unittest classes) that rely on default pickling behaviour and hence fit into category 2 (we just very, very rarely move anything around, so such classes may as well be in category 1 most of the time). Notably, this mostly causes problems when reading pickles generated with a *new* version of Python in an *old* version. When going the other way, we can adjust the unpickling process to cope with any discrepancies (for the "relying on implementation details case", usually by the simple expedient of keeping both sets of names around). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-3 transition in Arch Linux
On Thu, Nov 4, 2010 at 11:59 PM, Benjamin Peterson wrote: > 2010/11/4 Nick Coghlan : >> Tools also had a few discrepancies: >> scripts/2to3.py: /usr/bin/env python (necessary, I think - I believe >> 2to3 is a 2.x only program) > > No, I believe distutils is supposed to patch that up, though. Yeah, I did a more thorough grep and the ready-to-install version of 2to3.py has a correctly updated shebang line. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-3 transition in Arch Linux
Thomas Wouters writes: > > This is unrealistic. It would seriously annoy Arch's intended > > audience. (Eg, recently I've become a lot more favorable to using > > Word instead of OOo because Word doesn't pop up a useless warning > > every time I save a .doc file.) Practically speaking, it would have > > to be off by default, like Python pending deprecation warnings. > > Wait, what? Warning about impending brokenness is *more annoying* than just > plain breaking? How on earth would the warning be "useless"? > Keep in mind that the warning would only show up *if stuff would otherwise > not work*. As I understood it, what you proposed was that in a *Python 2-based* distribution thinking about switching to Python 3 as the default /usr/bin/python, they should first substitute a bitch'n'run-python2 script for the python (Python 2) binary, and after that works the bugs out, switch to Python 3. In that scenario, the bitching is useful *exactly* once: the first time anybody reports the bug to someone who can do something about it. But for some time, *every time* you run your app, it bitches uselessly: it would work fine if you just install Python 2 as /usr/bin/python, without bitching. That's not very graceful. And "some time" will often stretch into weeks or months for any given user, since few distros will bless a new package with zero testing. > No, that's not my point at all. The problem isn't that Python 3 is > incompatible with Python 2. The problem is that stuff broke without > (apparently) fair warning. Warning was given; they weren't listening. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-3 transition in Arch Linux
On Fri, Nov 5, 2010 at 17:09, Stephen J. Turnbull wrote: > Thomas Wouters writes: > > > > This is unrealistic. It would seriously annoy Arch's intended > > > audience. (Eg, recently I've become a lot more favorable to using > > > Word instead of OOo because Word doesn't pop up a useless warning > > > every time I save a .doc file.) Practically speaking, it would have > > > to be off by default, like Python pending deprecation warnings. > > > > Wait, what? Warning about impending brokenness is *more annoying* than > just > > plain breaking? How on earth would the warning be "useless"? > > Keep in mind that the warning would only show up *if stuff would > otherwise > > not work*. > > As I understood it, what you proposed was that in a *Python 2-based* > distribution thinking about switching to Python 3 as the default > /usr/bin/python, they should first substitute a bitch'n'run-python2 > script for the python (Python 2) binary, and after that works the bugs > out, switch to Python 3. > > In that scenario, the bitching is useful *exactly* once: the first > time anybody reports the bug to someone who can do something about it. > But for some time, *every time* you run your app, it bitches > uselessly: it would work fine if you just install Python 2 as > /usr/bin/python, without bitching. That's not very graceful. And > "some time" will often stretch into weeks or months for any given > user, since few distros will bless a new package with zero testing. > No, what I suggested was that *instead of changing /usr/bin/python to Python 3*, it would produce a warning. So, as before, change everything you know about to python2. Keep everything that is python3 using python3. Change /usr/bin/python, which *should* now be unused, to something that complains. Since all the distribution-installed packages were changed, the only warnings will come from invocations that would otherwise have spectacularly and possibly quite confusingly blown up. As I said, the warning can provide clear instructions on updating the software. Heck, the /usr/bin/python wrapper could be made to be quiet for a day at a time by having the user press a button. > > No, that's not my point at all. The problem isn't that Python 3 is > > incompatible with Python 2. The problem is that stuff broke without > > (apparently) fair warning. > > Warning was given; they weren't listening. > Yes, that's what users do. They don't look at the websites or read the mailinglists, they just care that their stuff keeps working and they don't want to pay the maintenance cost :) I'm not saying Arch should have done this, but most Linux distributions do *not* have attentive users. This is not news. I would rather we stay with an explicit 'python3' for another decade (as, after all, Perl did with perl5 as well) than that more people are confronted with the switch to python3 by having their own code break. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2010-10-29 - 2010-11-05)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open2514 (+17)
closed 19597 (+78)
total 22111 (+95)
Open issues with patches: 1044
Issues opened (56)
==
#5251: contextlib.nested inconsistent with, well, nested with stateme
http://bugs.python.org/issue5251 reopened by ncoghlan
#10236: Sporadic failures of test_ssl
http://bugs.python.org/issue10236 opened by ixokai
#10237: failure in Barrier tests
http://bugs.python.org/issue10237 opened by pitrou
#10238: ctypes not building under OS X 10.6 with LLVM/Clang 2.8
http://bugs.python.org/issue10238 opened by brett.cannon
#10239: multiprocessing signal defect
http://bugs.python.org/issue10239 opened by Neal.Becker
#10240: dict.update.__doc__ is misleading
http://bugs.python.org/issue10240 opened by ivank
#10241: gc fixes for module m_copy attribute
http://bugs.python.org/issue10241 opened by nascheme
#10242: unittest's assertItemsEqual() method makes too many assumption
http://bugs.python.org/issue10242 opened by rhettinger
#10245: Fix resource warnings in test_telnetlib
http://bugs.python.org/issue10245 opened by bbrazil
#10248: Fix resource warnings in test_xmlrpclib
http://bugs.python.org/issue10248 opened by bbrazil
#10252: Fix resource warnings in distutils
http://bugs.python.org/issue10252 opened by bbrazil
#10254: unicodedata.normalize('NFC', s) regression
http://bugs.python.org/issue10254 opened by valhallasw
#10255: refleak in initstdio
http://bugs.python.org/issue10255 opened by nascheme
#10259: Entry text not set if all of 'Font', 'Foreground' and 'Justify
http://bugs.python.org/issue10259 opened by iarspider
#10260: Add a threading.Condition.wait_for() method
http://bugs.python.org/issue10260 opened by krisvale
#10261: tarfile iterator without members caching
http://bugs.python.org/issue10261 opened by karstenw
#10262: Add --disable-abi-flags option to `configure`
http://bugs.python.org/issue10262 opened by Arfrever
#10267: test_ttk_guionly leaks many references
http://bugs.python.org/issue10267 opened by pitrou
#10270: Fix resource warnings in test_threading
http://bugs.python.org/issue10270 opened by bbrazil
#10271: warnings.showwarning should allow any callable object
http://bugs.python.org/issue10271 opened by lekma
#10272: SSL handshake timeouts not caught by transient_internet
http://bugs.python.org/issue10272 opened by pitrou
#10273: Clean-up Unittest API
http://bugs.python.org/issue10273 opened by rhettinger
#10274: imaplib should provide a means to validate a remote server ssl
http://bugs.python.org/issue10274 opened by db
#10276: zlib crc32/adler32 buffer length truncation (64-bit)
http://bugs.python.org/issue10276 opened by nvawda
#10278: add time.wallclock() method
http://bugs.python.org/issue10278 opened by krisvale
#10282: IMPLEMENTATION token differently delt with in NNTP capability
http://bugs.python.org/issue10282 opened by jelie
#10284: NNTP should accept bytestrings for username and password
http://bugs.python.org/issue10284 opened by jelie
#10287: NNTP authentication should check capabilities
http://bugs.python.org/issue10287 opened by jelie
#10288: Remove deprecated C "character" handling macros ISUPPER() etc
http://bugs.python.org/issue10288 opened by dmalcolm
#10289: Document magic methods called by built-in functions
http://bugs.python.org/issue10289 opened by eric.araujo
#10291: Clean-up turtledemo in-package documentation
http://bugs.python.org/issue10291 opened by belopolsky
#10292: tarinfo should use relative symlinks
http://bugs.python.org/issue10292 opened by magcius
#10296: ctypes catches BreakPoint error on windows 32
http://bugs.python.org/issue10296 opened by krisvale
#10297: decimal module documentation is misguiding
http://bugs.python.org/issue10297 opened by hafiza.jameel
#10298: zipfile: incorrect comment size will prevent extracting
http://bugs.python.org/issue10298 opened by rep
#10299: Add index with links section for built-in functions
http://bugs.python.org/issue10299 opened by nestor
#10302: Add class-functions to hash many small objects with hashlib
http://bugs.python.org/issue10302 opened by ebfe
#10303: small inconsistency in tutorial
http://bugs.python.org/issue10303 opened by maltehelmert
#10304: error in tutorial triple-string example
http://bugs.python.org/issue10304 opened by maltehelmert
#10305: Cleanup up ResourceWarnings in multiprocessing
http://bugs.python.org/issue10305 opened by brian.curtin
#10308: Modules/getpath.c bugs
http://bugs.python.org/issue10308 opened by hfuru
#10309: dlmalloc.c needs _GNU_SOURCE for mremap()
http://bugs.python.org/issue10309 opened by hfuru
#10310: signed:1 bitfields rarely make sense
http://bugs.python.org/issue10310 opened by hfuru
#10311: Signal handlers must preserve errno
http
Re: [Python-Dev] Python-3 transition in Arch Linux
On Thu, Nov 4, 2010 at 3:40 PM, Laurens Van Houtven wrote: > On Thu, Nov 4, 2010 at 5:44 AM, Allan McRae wrote: > What is true is that there's a new and temporary "NO ARCH" rule in the > topic It's your channel and you can do with it what you want, but seriously- does this strike you as the best response to a widespread problem? You're basically telling people to get lost, and in all caps no less. Geremy Condra ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-3 transition in Arch Linux
On 05/11/2010 17:10, geremy condra wrote: On Thu, Nov 4, 2010 at 3:40 PM, Laurens Van Houtven wrote: On Thu, Nov 4, 2010 at 5:44 AM, Allan McRae wrote: What is true is that there's a new and temporary "NO ARCH" rule in the topic It's your channel and you can do with it what you want, Actually it's a PSF run channel. but seriously- does this strike you as the best response to a widespread problem? You're basically telling people to get lost, and in all caps no less. They're saying that the channel isn't the correct place to get support on that particular issue. All the best, Michael Geremy Condra ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] *** glibc detected *** gdb: malloc(): smallbin double linked list
Hi, I've compiled Python 2.7 (r27:82500, Nov 2 2010, 09:00:37) [GCC 4.4.3] on linux2 with the following configure options ./configure --prefix=/home/john/local/python-dbg --with-pydebug I've installed numpy and some other packages but when I try to run my extension code under gdb I get the errors below. Does anyone have any ideas of how to track down what's happening here? I imagine I've misconfigured something somewhere. Is valgrind the answer? Thanks, John. *** glibc detected *** gdb: malloc(): smallbin double linked list corrupted: 0x04de7ad0 *** === Backtrace: = /lib/libc.so.6(+0x775b6)[0x7f0a252215b6] /lib/libc.so.6(+0x7b8e9)[0x7f0a252258e9] /lib/libc.so.6(__libc_malloc+0x6e)[0x7f0a2522658e] gdb(xmalloc+0x18)[0x45bc38] gdb[0x476df1] gdb[0x474c9b] gdb[0x474ee8] gdb(execute_command+0x2dd)[0x458d1d] gdb(catch_exception+0x50)[0x535510] gdb[0x4b5191] gdb(interp_exec+0x17)[0x535637] gdb(mi_cmd_interpreter_exec+0x6c)[0x4b9adc] gdb[0x4ba71a] gdb(catch_exception+0x50)[0x535510] gdb(mi_execute_command+0x97)[0x4ba137] gdb[0x53a0f8] gdb(gdb_do_one_event+0x29a)[0x53b38a] gdb(catch_errors+0x5b)[0x53531b] gdb(start_event_loop+0x1e)[0x53a90e] gdb[0x44f619] gdb(catch_errors+0x5b)[0x53531b] gdb[0x450166] gdb(catch_errors+0x5b)[0x53531b] gdb(gdb_main+0x24)[0x44f554] gdb(main+0x2e)[0x44f51e] /lib/libc.so.6(__libc_start_main+0xfd)[0x7f0a251c8c4d] gdb[0x44f429] === Memory map: 0040-00818000 r-xp 08:05 4832730 /usr/bin/gdb 00a17000-00a18000 r--p 00417000 08:05 4832730 /usr/bin/gdb 00a18000-00a25000 rw-p 00418000 08:05 4832730 /usr/bin/gdb 00a25000-00a43000 rw-p 00:00 0 0287f000-0b92 rw-p 00:00 0 [heap] 7f0a1c00-7f0a1c021000 rw-p 00:00 0 7f0a1c021000-7f0a2000 ---p 00:00 0 7f0a20fc-7f0a20fd6000 r-xp 08:05 3498245 /lib/libgcc_s.so.1 7f0a20fd6000-7f0a211d5000 ---p 00016000 08:05 3498245 /lib/libgcc_s.so.1 7f0a211d5000-7f0a211d6000 r--p 00015000 08:05 3498245 /lib/libgcc_s.so.1 7f0a211d6000-7f0a211d7000 rw-p 00016000 08:05 3498245 /lib/libgcc_s.so.1 7f0a211fd000-7f0a21211000 r--p 000dc000 08:05 4825848 /usr/lib/libstdc++.so.6.0.13 7f0a21211000-7f0a21218000 r--p 00018000 08:05 4841756 /usr/lib/debug/lib/librt-2.11.1.so 7f0a21218000-7f0a21226000 r--p 1000 08:05 4841756 /usr/lib/debug/lib/librt-2.11.1.so 7f0a21226000-7f0a2123e000 r--p 000bc000 08:05 4653290 /home/john/Dev/MyProjects/Bio/MotifSearch/python/stempy/_debug/libboost_python.so.1.44.0 7f0a2123e000-7f0a21287000 r--p 003dd000 08:05 4653290 /home/john/Dev/MyProjects/Bio/MotifSearch/python/stempy/_debug/libboost_python.so.1.44.0 7f0a21287000-7f0a21299000 r--p 00425000 08:05 4653290 /home/john/Dev/MyProjects/Bio/MotifSearch/python/stempy/_debug/libboost_python.so.1.44.0 7f0a21299000-7f0a213e7000 r--p 0018c000 08:05 4653290 /home/john/Dev/MyProjects/Bio/MotifSearch/python/stempy/_debug/libboost_python.so.1.44.0 7f0a213e7000-7f0a2152f000 r--p 0207c000 08:05 4653324 /home/john/Dev/MyProjects/Bio/MotifSearch/python/stempy/_debug/_stempy.so 7f0a2152f000-7f0a22027000 r--p 01585000 08:05 4653324 /home/john/Dev/MyProjects/Bio/MotifSearch/python/stempy/_debug/_stempy.so 7f0a22027000-7f0a2240 rw-p 00:00 0 7f0a22408000-7f0a224d1000 r--p 00315000 08:05 4653290 /home/john/Dev/MyProjects/Bio/MotifSearch/python/stempy/_debug/libboost_python.so.1.44.0 7f0a224d1000-7f0a224ff000 r--p 002e8000 08:05 4653290 /home/john/Dev/MyProjects/Bio/MotifSearch/python/stempy/_debug/libboost_python.so.1.44.0 7f0a224ff000-7f0a22526000 r--p 00038000 08:05 4653310 /home/john/Dev/MyProjects/Bio/MotifSearch/python/stempy/_debug/myrrh_pylib-d 7f0a22526000-7f0a2259c000 r--p 0151 08:05 4653324 /home/john/Dev/MyProjects/Bio/MotifSearch/python/stempy/_debug/_stempy.so 7f0a2259c000-7f0a2280c000 r--p 012a 08:05 4653324 /home/john/Dev/MyProjects/Bio/MotifSearch/python/stempy/_debug/_stempy.so 7f0a2280c000-7f0a2343f000 rw-p 00:00 0 7f0a23443000-7f0a2344c000 r--p 0001a000 08:05 6169643 /home/john/local/python-dbg/lib/python2.7/lib-dynload/datetime.so 7f0a2344c000-7f0a2345c000 r--p 002d9000 08:05 4653290 /home/john/Dev/MyProjects/Bio/MotifSearch/python/stempy/_debug/libboost_python.so.1.44.0 7f0a2345c000-7f0a23461000 r--p 0005e000 08:05 4653310 /home/john/Dev/MyProjects/Bio/MotifSearch/python/stempy/_debug/myrrh_pylib-d 7f0a23461000-7f0a23477000 r--p 0001f000 08:05 4653310 /home/john/Dev/MyProjects/Bio/MotifSearch/python/stempy/_debug/myrrh_pylib-d 7f0a23477000-7f0a2347d000 r--p 4000 08:05 4653095 /home/john/Dev/MyProjects/Bio/MotifSearch/python/stempy/_debug/libboost_system.so.1.44.0 7f0a2347d000-7f0a2350c000 r--p 00757000 08:05 4653324 /home/john/Dev/MyProjects/Bio/MotifSearch/python/stempy/_debug/_stempy.so 7f0a2350c000-7f0a23555000 r--p 021c3000 08:05 4653324 /home/john/Dev/MyProjects/Bio/MotifSearch/python/stempy/_debug/_stempy.so 7f0a23555000-7f0a2355b000 r--p 00048000 08:05 6169627 /home
Re: [Python-Dev] Python-3 transition in Arch Linux
On Fri, Nov 5, 2010 at 6:10 PM, geremy condra wrote: > On Thu, Nov 4, 2010 at 3:40 PM, Laurens Van Houtven wrote: >> On Thu, Nov 4, 2010 at 5:44 AM, Allan McRae wrote: > > > >> What is true is that there's a new and temporary "NO ARCH" rule in the >> topic > > It's your channel and you can do with it what you want, but seriously- > does this strike you as the best response to a widespread problem? > You're basically telling people to get lost, and in all caps no less. > > Geremy Condra It is not by any means "my channel" -- I apologize if I gave anyone the impression that I alone decided that was going up, because that's not true. Unfortunately Freenode does not give us the ability to be more verbose in IRC topics. In fact, to put that up, we had to remove something less important. As a result, NO ARCH is roughly the best we can do. (Similarly NO LOL is really NO CHATSPEAK, but topics are length limited.) cheers lvh ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-3 transition in Arch Linux
Whoops, pressed send too soon. This should've followed my previous email: Unscientifically judging by the rate of people who used to have vague problems that turned out to be Arch-related, I don't really think anyone feels they're being told to "get lost". People ask a question about it, which is great: answering that issue in the detail it deserves (as you've mentioned), which is something we can't do in the /topic but *can* do in the channel itself, takes a lot less time for everyone and leads to the correct answer (such as "tell the package maintainer") faster. As soon as this dies down and it stops being an issue, we're obviously taking it down. cheers lvh ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] *** glibc detected *** gdb: malloc(): smallbin double linked list
> Hi, > > I've compiled > Python 2.7 (r27:82500, Nov 2 2010, 09:00:37) > [GCC 4.4.3] on linux2 > > with the following configure options > ./configure --prefix=/home/john/local/python-dbg --with-pydebug > > I've installed numpy and some other packages but when I try to run my > extension code under gdb I get the errors below. Does anyone have any > ideas of how to track down what's happening here? I imagine I've > misconfigured something somewhere. Is valgrind the answer? > > Thanks, > John. Hi John, the right place for asking such questions is the python mailing list [email protected], please see http://mail.python.org/mailman/listinfo/python-list This python-dev list is for the development *of* python and not development *with* python. For the latter python-list is the appropriate forum. Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r86170 - in python/branches/py3k: Doc/library/stdtypes.rst Lib/test/test_unicode.py Misc/NEWS Objects/stringlib/string_format.h Objects/unicodeobject.c
> Author: eric.smith > Date: Thu Nov 4 18:06:58 2010 > New Revision: 86170 > > Log: > Issue #6081: Add str.format_map. str.format_map(mapping) is similar to > str.format(**mapping), except mapping does not get converted to a dict. > Modified: python/branches/py3k/Doc/library/stdtypes.rst > == > --- python/branches/py3k/Doc/library/stdtypes.rst (original) > +++ python/branches/py3k/Doc/library/stdtypes.rst Thu Nov 4 18:06:58 2010 > @@ -1038,6 +1038,14 @@ > that can be specified in format strings. > > > +.. method:: str.format_map(mapping) > + > + Similar to ``str.forrmat(**mapping)``, except that ``mapping`` is Yarrr me hearrties, it be forrrmat! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-3 transition in Arch Linux
On Fri, Nov 5, 2010 at 10:14 AM, Michael Foord wrote: > On 05/11/2010 17:10, geremy condra wrote: >> >> On Thu, Nov 4, 2010 at 3:40 PM, Laurens Van Houtven >> wrote: >>> >>> On Thu, Nov 4, 2010 at 5:44 AM, Allan McRae wrote: >> >> >> >>> What is true is that there's a new and temporary "NO ARCH" rule in the >>> topic >> >> It's your channel and you can do with it what you want, > > Actually it's a PSF run channel. > >> but seriously- >> does this strike you as the best response to a widespread problem? >> You're basically telling people to get lost, and in all caps no less. >> > They're saying that the channel isn't the correct place to get support on > that particular issue. In the same way that telling someone to RTFM n00b is the same thing as telling them to kindly refer to the documents produced by man, yes. As you said during the "python 2 or 3" discussion some months back "given the topic is far more nuanced than an IRC topic can express maybe that just isn't the right place for it". Geremy Condra ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of Python tracker Issues
Hi, On 05/11/2010 19.08, Python tracker wrote: ACTIVITY SUMMARY (2010-10-29 - 2010-11-05) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open2514 (+17) closed 19597 (+78) total 22111 (+95) as suggested in recent mails[0][1] I changed these values to represent the deltas with the previous week. Now let's try to keep the "open" delta negative ;) Best Regards, Ezio Melotti [0]: http://mail.python.org/pipermail/python-dev/2010-October/104840.html [1]: http://mail.python.org/pipermail/python-dev/2010-September/104054.html ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r86170 - in python/branches/py3k: Doc/library/stdtypes.rst Lib/test/test_unicode.py Misc/NEWS Objects/stringlib/string_format.h Objects/unicodeobject.c
According to #python-dev, there’s no need to go through python-checkins/-dev for typos, so I fixed this one in r86247. Piratical regards ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
