Re: [Python-Dev] PEP for allowing 'raise NewException from None'
Benjamin Peterson wrote: 2012/1/26 Ethan Furman et...@stoneleaf.us: PEP: XXX Congratulations, you are now PEP 409. Thanks, Benjamin! So, how do I make changes to it? ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for allowing 'raise NewException from None'
For those not on the nosy list, here's the latest post to http://bugs.python.org/issue6210: --- It looks like agreement is forming around the raise ... from None method. It has been mentioned more than once that having the context saved on the exception would be a Good Thing, and for further debugging (or logging or what-have-you) I must agree. The patch attached now sets __cause__ to True, leaving __context__ unclobbered. The exception printing routine checks to see if __cause__ is True, and if so simply skips the display of either cause or __context__, but __context__ can still be queried by later code. One concern raised was that since it is possible to write (even before this patch) raise KeyError from NameError outside of a try block that some would get into the habit of writing raise KeyError from None as a way of preemptively suppressing implicit context chaining; I am happy to report that this is not an issue, since when that exception is caught and a new exception raised, it is the new exception that controls the display. In other words: try: ... raise ValueError from None ... except: ... raise NameError ... Traceback (most recent call last): File stdin, line 2, in module ValueError During handling of the above exception, another exception occurred: Traceback (most recent call last): File stdin, line 4, in module NameError ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for allowing 'raise NewException from None'
Am 29.01.2012 08:42, schrieb Ethan Furman: Benjamin Peterson wrote: 2012/1/26 Ethan Furman et...@stoneleaf.us: PEP: XXX Congratulations, you are now PEP 409. Thanks, Benjamin! So, how do I make changes to it? Please send PEP updates to the PEP editors at p...@python.org. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] A new dictionary implementation
Hi, Now that issue 13703 has been largely settled, I want to propose my new dictionary implementation again. It is a little more polished than before. https://bitbucket.org/markshannon/hotpy_new_dict Object-oriented benchmarks use considerably less memory and are sometimes faster (by a small amount). (I've only benchmarked on my old 32bit machine) E.g 2to3 No speed change -28% memory GCbench +10% speed -47% memory Other benchmarks show little or no change in behaviour, mainly minor memory savings. If an application is OO and uses lots of memory the new dict will save a lot of memory and maybe boost performance. Other applications will be largely unaffected. It passes all the tests. (I had to change a couple that relied on dict repr() ordering) Cheers, Mark. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new dictionary implementation
Hi, On Sun, 29 Jan 2012 10:31:48 + Mark Shannon m...@hotpy.org wrote: Now that issue 13703 has been largely settled, I want to propose my new dictionary implementation again. It is a little more polished than before. https://bitbucket.org/markshannon/hotpy_new_dict I briefly took a look at your code yesterday and it looked generally reasonable to me. It would be nice to open an issue on http://bugs.python.org so that we can review it there (just fill the repository field and use the create patch button). Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new dictionary implementation
2012/1/29 Mark Shannon m...@hotpy.org: Hi, Now that issue 13703 has been largely settled, I want to propose my new dictionary implementation again. It is a little more polished than before. If you're serious about changing the dictionary implementation, I think you should write a PEP. It should explain the new dicts advantages (and disadvantages?) and give comprehensive benchmark numbers. Something along the lines of http://www.python.org/dev/peps/pep-3128/ I should think. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new dictionary implementation
On Sun, 29 Jan 2012 09:56:11 -0500 Benjamin Peterson benja...@python.org wrote: 2012/1/29 Mark Shannon m...@hotpy.org: Hi, Now that issue 13703 has been largely settled, I want to propose my new dictionary implementation again. It is a little more polished than before. If you're serious about changing the dictionary implementation, I think you should write a PEP. It should explain the new dicts advantages (and disadvantages?) and give comprehensive benchmark numbers. Something along the lines of http://www.python.org/dev/peps/pep-3128/ I should think. New dictionary implementation is a misnomer here. Mark's patch merely allows to share the keys array between several dictionaries. The lookup algorithm remains exactly the same as far as I've read. It's actually much less invasive than e.g. Martin's AVL trees-for-hash-collisions proposal. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new dictionary implementation
2012/1/29 Antoine Pitrou solip...@pitrou.net: On Sun, 29 Jan 2012 09:56:11 -0500 Benjamin Peterson benja...@python.org wrote: 2012/1/29 Mark Shannon m...@hotpy.org: Hi, Now that issue 13703 has been largely settled, I want to propose my new dictionary implementation again. It is a little more polished than before. If you're serious about changing the dictionary implementation, I think you should write a PEP. It should explain the new dicts advantages (and disadvantages?) and give comprehensive benchmark numbers. Something along the lines of http://www.python.org/dev/peps/pep-3128/ I should think. New dictionary implementation is a misnomer here. Mark's patch merely allows to share the keys array between several dictionaries. The lookup algorithm remains exactly the same as far as I've read. It's actually much less invasive than e.g. Martin's AVL trees-for-hash-collisions proposal. Ah, okay. So, the subject makes sound scarier than it is. :) -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new dictionary implementation
Antoine Pitrou wrote: Hi, On Sun, 29 Jan 2012 10:31:48 + Mark Shannon m...@hotpy.org wrote: Now that issue 13703 has been largely settled, I want to propose my new dictionary implementation again. It is a little more polished than before. https://bitbucket.org/markshannon/hotpy_new_dict I briefly took a look at your code yesterday and it looked generally reasonable to me. It would be nice to open an issue on http://bugs.python.org so that we can review it there (just fill the repository field and use the create patch button). Done: http://bugs.python.org/issue13903 Cheers, Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] #include Python.h
I have a newbie question about CPython. Looking at the C code I noted that for example in tupleobject.c there is only one include #include Python.h Python.h actually includes everything as far as I can I see so: - it's very hard with a not-enough smart editor to find out where the not-locally defined symbols are actually defined (well sure that is not a problem for most of the people) - if all the files include python.h, doesn't it generate very big object files? Or is it not a problem since they are stripped out after? Thanks, Andrea ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new dictionary implementation
Antoine Pitrou wrote: On Sun, 29 Jan 2012 09:56:11 -0500 Benjamin Peterson benja...@python.org wrote: 2012/1/29 Mark Shannon m...@hotpy.org: Hi, Now that issue 13703 has been largely settled, I want to propose my new dictionary implementation again. It is a little more polished than before. If you're serious about changing the dictionary implementation, I think you should write a PEP. It should explain the new dicts advantages (and disadvantages?) and give comprehensive benchmark numbers. Something along the lines of http://www.python.org/dev/peps/pep-3128/ I should think. New dictionary implementation is a misnomer here. Mark's patch merely allows to share the keys array between several dictionaries. The lookup algorithm remains exactly the same as far as I've read. It's actually much less invasive than e.g. Martin's AVL trees-for-hash-collisions proposal. Antoine is right. It is a reorganisation of the dict, plus a couple of changes to typeobject.c and object.c to ensure that instance dictionaries do indeed share keys arrays. The lookup algorithm remains the same (it works well). Cheers, Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] #include Python.h
Hello. We are sorry but we cannot help you. This mailing list is to work on developing Python (adding new features to Python itself and fixing bugs); if you're having problems learning, understanding or using Python, please find another forum. Probably python-list/comp.lang.python mailing list/news group is the best place; there are Python developers who participate in it; you may get a faster, and probably more complete, answer there. See http://www.python.org/community/ for other lists/news groups/fora. Thank you for understanding. On Sun, Jan 29, 2012 at 03:34:38PM +, Andrea Crotti wrote: I have a newbie question about CPython. Looking at the C code I noted that for example in tupleobject.c there is only one include #include Python.h Python.h actually includes everything as far as I can I see so: - it's very hard with a not-enough smart editor to find out where the not-locally defined symbols are actually defined (well sure that is not a problem for most of the people) - if all the files include python.h, doesn't it generate very big object files? Or is it not a problem since they are stripped out after? Thanks, Andrea Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] #include Python.h
On 01/29/2012 05:22 PM, Oleg Broytman wrote: Hello. We are sorry but we cannot help you. This mailing list is to work on developing Python (adding new features to Python itself and fixing bugs); if you're having problems learning, understanding or using Python, please find another forum. Probably python-list/comp.lang.python mailing list/news group is the best place; there are Python developers who participate in it; you may get a faster, and probably more complete, answer there. See http://www.python.org/community/ for other lists/news groups/fora. Thank you for understanding. I wrote here because I thought it was the best place, but I understand this point of view, I can ask on python or python-core for example.. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] #include Python.h
On Sun, Jan 29, 2012 at 05:59:51PM +, Andrea Crotti wrote: On 01/29/2012 05:22 PM, Oleg Broytman wrote: Hello. We are sorry but we cannot help you. This mailing list is to work on developing Python (adding new features to Python itself and fixing bugs); if you're having problems learning, understanding or using Python, please find another forum. Probably python-list/comp.lang.python mailing list/news group is the best place; there are Python developers who participate in it; you may get a faster, and probably more complete, answer there. See http://www.python.org/community/ for other lists/news groups/fora. Thank you for understanding. I wrote here because I thought it was the best place, but I understand this point of view, I can ask on python or python-core for example.. python-dev isn't that inappropriate, IMO, but probably the best place to go with this discussion is python-ideas. Could you repost over there? cheers, --titus -- C. Titus Brown, c...@msu.edu ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] #include Python.h
On 29 January 2012 18:10, C. Titus Brown c...@msu.edu wrote: python-dev isn't that inappropriate, IMO, but probably the best place to go with this discussion is python-ideas. Could you repost over there? I agree that python-dev isn't particularly appropriate, python-list is probably your best bet. The python-ideas isn't really appropriate, as this isn't a proposal for a change to Python, but rather a question about how the Python C code is structured. That's always a grey area, and I can see why the OP thought python-dev might be a reasonable place. Having said all that: Python.h actually includes everything as far as I can I see so: - it's very hard with a not-enough smart editor to find out where the not-locally defined symbols are actually defined (well sure that is not a problem for most of the people) Well, that's more of a question of what tools you use to edit/read Python code. I guess you could view it as a trade-off between ease of writing the core code and extensions (avoiding micromanagement of headers, and being able to document #include Python.h as the canonical way to get access to the Python API from C) versus tracking down macro definitions and symbol declarations (and that's really only for information, as the API is documented in the manuals anyway). I don't use an editor that can automatically find the definitions, but grep and the manuals does me fine. - if all the files include python.h, doesn't it generate very big object files? Or is it not a problem since they are stripped out after? That's more of a C/linker question, but generally .h files only contain declarations and macros, and nothing that generates code. So there is no impact on object code size if you include multiple .h files, or too many, or whatever. So no, it doesn't generate big object files. Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] #include Python.h
On 01/29/2012 06:34 PM, Paul Moore wrote: On 29 January 2012 18:10, C. Titus Brownc...@msu.edu wrote: python-dev isn't that inappropriate, IMO, but probably the best place to go with this discussion is python-ideas. Could you repost over there? I agree that python-dev isn't particularly appropriate, python-list is probably your best bet. The python-ideas isn't really appropriate, as this isn't a proposal for a change to Python, but rather a question about how the Python C code is structured. That's always a grey area, and I can see why the OP thought python-dev might be a reasonable place. Ok well for this I won't repost it anywhere else, I have already all the answers I wanted and it was not so important.. Having said all that: Python.h actually includes everything as far as I can I see so: - it's very hard with a not-enough smart editor to find out where the not-locally defined symbols are actually defined (well sure that is not a problem for most of the people) Well, that's more of a question of what tools you use to edit/read Python code. I guess you could view it as a trade-off between ease of writing the core code and extensions (avoiding micromanagement of headers, and being able to document #include Python.h as the canonical way to get access to the Python API from C) versus tracking down macro definitions and symbol declarations (and that's really only for information, as the API is documented in the manuals anyway). I don't use an editor that can automatically find the definitions, but grep and the manuals does me fine. Yes sure it makes sense, probably it's even better than including only simple files, since all the contributions to Python.h can be moved around and refactored without breaking all the code.. And for editor I use Emacs, which can actually do any kind of magic on the symbols, I just didn't set it up for the python source code.. Thanks, Andrea ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] #include Python.h
On Sun, Jan 29, 2012 at 17:34, Andrea Crotti andrea.crott...@gmail.com wrote: I have a newbie question about CPython. Looking at the C code I noted that for example in tupleobject.c there is only one include #include Python.h Python.h actually includes everything as far as I can I see so: - it's very hard with a not-enough smart editor to find out where the not-locally defined symbols are actually defined (well sure that is not a problem for most of the people) Hi Andrea, Not sure what you mean by not-enough smart editor. Dismissing IDEs for the moment (which by your classifications are probably smart enough), Python's source code (including headers included in Python.h) is readily navigable with Emacs or Vim using ctags, which is very easy to set up. Declarations are then easily found. Even if you forgo such features of the editor, grepping (or source specific greppers like ack or pss) also works fine most of the time. - if all the files include python.h, doesn't it generate very big object files? Or is it not a problem since they are stripped out after? Header files usually don't affect object file size. Unless something very fishy is going on (and this is not the case for headers included from Python.h, AFAIK) headers only contain declarations which don't affect code size. They may affect compilation time, but that's not a bit problem for Python's code base which is very fast to compile. Eli ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [issue13703] Hash collision security issue
On Fri, Jan 27, 2012 at 11:39 AM, mar...@v.loewis.de wrote: In fact, none of the strategies fixes all issues with hash collisions; even the hash-randomization solutions only deal with string keys, and don't consider collisions on non-string keys. The hash-randomization approach also works fine on immutable container objects containing bytes and string keys such as tuples and UserString that merely expose a combination of the hashes of all of their contained elements. -gps ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] plugging the hash attack
On Fri, Jan 27, 2012 at 6:33 PM, Benjamin Peterson benja...@python.org wrote: 2012/1/27 Steven D'Aprano st...@pearwood.info: Benjamin Peterson wrote: Hello everyone, In effort to get a fix out before Perl 6 goes mainstream, Barry and I have decided to pronounce on what we want for our stable releases. What we have decided is that 1. Simple hash randomization is the way to go. We think this has the best chance of actually fixing the problem while being fairly straightforward such that we're comfortable putting it in a stable release. 2. It will be off by default in stable releases and enabled by an envar at runtime. This will prevent code breakage from dictionary order changing as well as people depending on the hash stability. Do you have the expectation that it will become on by default in some future release? Yes, 3.3. The solution in 3.3 could even be one of the more sophisticated proposals we have today. Yay! Thanks for the decision Release Managers! -gps ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 408 -- Standard library __preview__ package
On Fri, Jan 27, 2012 at 9:26 AM, Alex alex.gay...@gmail.com wrote: Eli Bendersky eliben at gmail.com writes: Hello, Following an earlier discussion on python-ideas [1], we would like to propose the following PEP for review. Discussion is welcome. The PEP can also be viewed in HTML form at http://www.python.org/dev/peps/pep-0408/ [1] http://mail.python.org/pipermail/python-ideas/2012-January/013246.html I'm -1 on this, for a pretty simple reason. Something goes into __preview__, instead of it's final destination directly because it needs feedback/possibly changes. However, given the release cycle of the stdlib (~18 months), any feedback it gets can't be seen by actual users until it's too late. Essentially you can only get one round of stdlib. I think a significantly healthier process (in terms of maximizing feedback and getting something into it's best shape) is to let a project evolve naturally on PyPi and in the ecosystem, give feedback to it from an inclusion perspective, and then include it when it becomes ready on it's own merits. The counter argument to this is that putting it in the stdlib gets you signficantly more eyeballs (and hopefully more feedback, therefore), my only response to this is: if it doesn't get eyeballs on PyPi I don't think there's a great enough need to justify it in the stdlib. -1 from me as well. How is the __preview__ namespace any different than the PendingDeprecationWarning that nobody ever uses? Nobody is likely to write significant code depending on anything in __preview__ thus the amount of feedback received would be low. A better way to get additional feedback would be to promote libraries that we are considering including by way of direct links to them on pypi from the relevant areas of the Python documentation (including the Module Reference / Index pages?) for that release and let the feedback on them roll in via that route. An example of this working: ipaddr is ready to go in. It got the eyeballs and API modifications while still a pypi library as a result of the discussion around the time it was originally suggested as being added. I or any other committers have simply not added it yet. -gps ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new dictionary implementation
On 01/29/2012 11:31 AM, Mark Shannon wrote: It passes all the tests. (I had to change a couple that relied on dict repr() ordering) Hi Mark, I've cloned the repo, build it the I've tried with ./python -m test. I got some errors: First in general: 340 tests OK. 2 tests failed: test_dis test_gdb 4 tests altered the execution environment: test_multiprocessing test_packaging test_site test_strlit 18 tests skipped: test_curses test_devpoll test_kqueue test_lzma test_msilib test_ossaudiodev test_smtpnet test_socketserver test_startfile test_timeout test_tk test_ttk_guionly test_urllib2net test_urllibnet test_winreg test_winsound test_xmlrpc_net test_zipfile64 1 skip unexpected on linux: test_lzma [1348560 refs] then test_dis: == CPython 3.3.0a0 (default:f15cf35c9922, Jan 29 2012, 18:12:19) [GCC 4.6.2] == Linux-3.1.0-1-amd64-x86_64-with-debian-wheezy-sid little-endian == /home/ci/prog/cpython/hotpy_new_dict/build/test_python_14470 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0) [1/1] test_dis test_big_linenos (test.test_dis.DisTests) ... ok test_boundaries (test.test_dis.DisTests) ... ok test_bug_1333982 (test.test_dis.DisTests) ... ok test_bug_708901 (test.test_dis.DisTests) ... ok test_dis (test.test_dis.DisTests) ... ok test_dis_none (test.test_dis.DisTests) ... ok test_dis_object (test.test_dis.DisTests) ... ok test_dis_traceback (test.test_dis.DisTests) ... ok test_disassemble_bytes (test.test_dis.DisTests) ... ok test_disassemble_method (test.test_dis.DisTests) ... ok test_disassemble_method_bytes (test.test_dis.DisTests) ... ok test_disassemble_str (test.test_dis.DisTests) ... ok test_opmap (test.test_dis.DisTests) ... ok test_opname (test.test_dis.DisTests) ... ok test_code_info (test.test_dis.CodeInfoTests) ... FAIL test_code_info_object (test.test_dis.CodeInfoTests) ... ok test_pretty_flags_no_flags (test.test_dis.CodeInfoTests) ... ok test_show_code (test.test_dis.CodeInfoTests) ... FAIL == FAIL: test_code_info (test.test_dis.CodeInfoTests) -- Traceback (most recent call last): File /home/ci/prog/cpython/hotpy_new_dict/Lib/test/test_dis.py, line 439, in test_code_info self.assertRegex(dis.code_info(x), expected) AssertionError: Regex didn't match: 'Name: f\nFilename: (.*)\nArgument count:1\nKw-only arguments: 0\nNumber of locals: 1\nStack size:8\nFlags: OPTIMIZED, NEWLOCALS, NESTED\nConstants:\n 0: None\nNames:\n 0: print\nVariable names:\n 0: c\nFree variables:\n 0: e\n 1: d\n 2: f\n 3: y\n 4: x\n 5: z' not found in 'Name: f\nFilename: /home/ci/prog/cpython/hotpy_new_dict/Lib/test/test_dis.py\nArgument count:1\nKw-only arguments: 0\nNumber of locals: 1\nStack size:8\nFlags: OPTIMIZED, NEWLOCALS, NESTED\nConstants:\n 0: None\nNames:\n 0: print\nVariable names:\n 0: c\nFree variables:\n 0: y\n 1: e\n 2: d\n 3: f\n 4: x\n 5: z' == FAIL: test_show_code (test.test_dis.CodeInfoTests) -- Traceback (most recent call last): File /home/ci/prog/cpython/hotpy_new_dict/Lib/test/test_dis.py, line 446, in test_show_code self.assertRegex(output.getvalue(), expected+\n) AssertionError: Regex didn't match: 'Name: f\nFilename: (.*)\nArgument count:1\nKw-only arguments: 0\nNumber of locals: 1\nStack size:8\nFlags: OPTIMIZED, NEWLOCALS, NESTED\nConstants:\n 0: None\nNames:\n 0: print\nVariable names:\n 0: c\nFree variables:\n 0: e\n 1: d\n 2: f\n 3: y\n 4: x\n 5: z\n' not found in 'Name: f\nFilename: /home/ci/prog/cpython/hotpy_new_dict/Lib/test/test_dis.py\nArgument count:1\nKw-only arguments: 0\nNumber of locals: 1\nStack size:8\nFlags: OPTIMIZED, NEWLOCALS, NESTED\nConstants:\n 0: None\nNames:\n 0: print\nVariable names:\n 0: c\nFree variables:\n 0: y\n 1: e\n 2: d\n 3: f\n 4: x\n 5: z\n' -- Ran 18 tests in 0.070s FAILED (failures=2) test test_dis failed 1 test failed: test_dis [111919 refs] * For test gdb: Lots of output . Ran 42 tests in 11.361s FAILED (failures=28) test test_gdb failed 1 test failed: test_gdb [109989 refs] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe:
Re: [Python-Dev] PEP 408 -- Standard library __preview__ package
On 29 January 2012 21:39, Gregory P. Smith g...@krypto.org wrote: An example of this working: ipaddr is ready to go in. It got the eyeballs and API modifications while still a pypi library as a result of the discussion around the time it was originally suggested as being added. I or any other committers have simply not added it yet. Interesting. I recall the API debates and uncertainty, but I don't recall having seen anything to indicate that it all got resolved and we're essentially ready to go. If I were looking for an IP address library, I wouldn't know where to go, and I certainly wouldn't know that there was an option that would become part of the stdlib. Not sure that counts as the approach working... (although I concede that my lack of a *real* need for an IP address library may be a contributing factor to my lack of knowledge...) Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new dictionary implementation
Now that issue 13703 has been largely settled, I want to propose my new dictionary implementation again. It is a little more polished than before. Please clarify the status of that code: are you actually proposing 6a21f3b35e20 for inclusion into Python as-is? If so, please post it as a patch to the tracker, as it will need to be reviewed (possibly with requests for further changes). If not, it would be good if you could give a list of things that need to be done before you consider submission to Python. Also, please submit a contrib form if you haven't done so. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new dictionary implementation
francis wrote: On 01/29/2012 11:31 AM, Mark Shannon wrote: It passes all the tests. (I had to change a couple that relied on dict repr() ordering) Hi Mark, I've cloned the repo, build it the I've tried with ./python -m test. I got some errors: First in general: 340 tests OK. 2 tests failed: test_dis test_gdb [snip] then test_dis: [snip] == FAIL: test_code_info (test.test_dis.CodeInfoTests) -- [snip] == FAIL: test_show_code (test.test_dis.CodeInfoTests) -- [snip] These are known failures, the tests are at fault as they rely on dict ordering. However, they should be commented out. Probably crept back in again when I pulled the latest version of cpython -- I'll fix them now. [snip] * For test gdb: Lots of output . Ran 42 tests in 11.361s FAILED (failures=28) test test_gdb failed 1 test failed: test_gdb [109989 refs] I still have gdb 6.somthing, would you mail me the full output please, so I can see what the problem is. Cheers, Mark. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 408 -- Standard library __preview__ package
On Jan 28, 2012, at 07:29 PM, Guido van Rossum wrote: Finally, if you really want to put warnings in whenever an experimental module is being used, make it a silent warning, like SilentDeprecationWarning. That allows people to request more strict warnings without unduly alarming the users of an app. I'll just note too that we have examples of stable APIs in modules being used successfully in the field for years, and still having long hand-wringing debates about whether the API choices are right or not. coughemail/cough Nothing beats people beating on it heavily for years in production code to shake things out. I often think a generic answer to did I get the API right could be no, but it's okay :) -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new dictionary implementation
Martin v. Löwis wrote: Now that issue 13703 has been largely settled, I want to propose my new dictionary implementation again. It is a little more polished than before. Please clarify the status of that code: are you actually proposing 6a21f3b35e20 for inclusion into Python as-is? If so, please post it as a patch to the tracker, as it will need to be reviewed (possibly with requests for further changes). I thought it already was a patch. What do I need to do to make it a patch? If not, it would be good if you could give a list of things that need to be done before you consider submission to Python. A few tests that rely on dict ordering should probably be fixed first. I'll submit bug reports for those. Also, please submit a contrib form if you haven't done so. Where do I find it? Cheers, Mark. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switching to Visual Studio 2010
I... I think I might have already done this, inadvertently. I needed an x64 VS2010 debug build of Subversion/APR*/Python a few weeks ago -- forgetting the fact that we're still on VS2008. There is a lot of duplication of work going on here: at least four people have done the same. The more people duplicate the work, the more urgent it apparently becomes that the trunk switches officially. * Three new buildbot scripts: - build-amd64-vs10.bat - clean-amd64-vs10.bat - external-amd64-vs10.bat When we switch, these should actually replace the current ones, rather than being additions. So, I guess my question is, is that work useful? Perhaps not, given that several other copies of that to draw from may exist. OTOH, I haven't heard anybody reporting these specific changes. In any case, it's now in Brian's hand. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new dictionary implementation
Please clarify the status of that code: are you actually proposing 6a21f3b35e20 for inclusion into Python as-is? If so, please post it as a patch to the tracker, as it will need to be reviewed (possibly with requests for further changes). I thought it already was a patch. What do I need to do to make it a patch? I missed your announcement of issue13903; all is fine here. Where do I find it? http://www.python.org/psf/contrib/contrib-form-python/ Thanks, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new dictionary implementation
Matt Joiner wrote: Mark, Good luck with getting this in, I'm also hopeful about coroutines, maybe after pushing your dict optimization your coroutine implementation will get more consideration. Shush, don't say the C word or you'll put people off ;) I'm actually not that fussed about the coroutine implementation. With yield from generators have all the power of asymmetric coroutines. I think my coroutine implementation is a neater way to do things, but it is not worth the fuss. Anyway, I'm working on my next crazy experiment :) Cheers, Mark. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new dictionary implementation
Mark Shannon wrote: Antoine Pitrou wrote: On Sun, 29 Jan 2012 09:56:11 -0500 Benjamin Peterson benja...@python.org wrote: 2012/1/29 Mark Shannon m...@hotpy.org: Hi, Now that issue 13703 has been largely settled, I want to propose my new dictionary implementation again. It is a little more polished than before. If you're serious about changing the dictionary implementation, I think you should write a PEP. It should explain the new dicts advantages (and disadvantages?) and give comprehensive benchmark numbers. Something along the lines of http://www.python.org/dev/peps/pep-3128/ I should think. New dictionary implementation is a misnomer here. Mark's patch merely allows to share the keys array between several dictionaries. The lookup algorithm remains exactly the same as far as I've read. It's actually much less invasive than e.g. Martin's AVL trees-for-hash-collisions proposal. Antoine is right. It is a reorganisation of the dict, plus a couple of changes to typeobject.c and object.c to ensure that instance dictionaries do indeed share keys arrays. I don't quite follow how that could work. If I have this: class C: pass a = C() b = C() a.spam = 1 b.ham = 2 how can a.__dict__ and b.__dict__ share key arrays? I've tried reading the source, but I'm afraid I don't understand it well enough to make sense of it. -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 408 -- Standard library __preview__ package
On Mon, Jan 30, 2012 at 8:44 AM, Barry Warsaw ba...@python.org wrote: Nothing beats people beating on it heavily for years in production code to shake things out. I often think a generic answer to did I get the API right could be no, but it's okay :) Heh, my answer to complaints about the urrlib (etc) APIs being horrendous in the modern web era is to point out that they were put together in an age where web mostly meant unauthenticated HTTP GET requests. They're hard to use for modern authentication protocols because they *predate* widespread use of such things... Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] threading.Semaphore()'s counter can become negative for non-ints
import threading s = threading.Semaphore(0.5) But why would you want to pass a float? It seems like API abuse to me. If something should be changed, Semaphore(arg) should raise a TypeError if arg is not an integer. Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 408 -- Standard library __preview__ package
I think an advocacy of 3rd party modules would start with modules such as ipaddr, requests, regex. Linking directly to them from the python core documentation, while requesting they hold a successful moratorium in order to be included in a later standard module release. On Jan 30, 2012 10:47 AM, Nick Coghlan ncogh...@gmail.com wrote: On Mon, Jan 30, 2012 at 8:44 AM, Barry Warsaw ba...@python.org wrote: Nothing beats people beating on it heavily for years in production code to shake things out. I often think a generic answer to did I get the API right could be no, but it's okay :) Heh, my answer to complaints about the urrlib (etc) APIs being horrendous in the modern web era is to point out that they were put together in an age where web mostly meant unauthenticated HTTP GET requests. They're hard to use for modern authentication protocols because they *predate* widespread use of such things... Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A new dictionary implementation
I still have gdb 6.somthing, would you mail me the full output please, so I can see what the problem is. It's done, let me know if you need more output. Cheers, francis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] threading.Semaphore()'s counter can become negative for non-ints
On Sat, Jan 28, 2012 at 3:07 PM, Benjamin Peterson benja...@python.org wrote: But why would you want to pass a float? It seems like API abuse to me. Agreed. Anything else seems meaningless. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for allowing 'raise NewException from None'
Latest addition for PEP 409 has been sent. Text follows: Language Details Currently, __context__ and __cause__ start out as None, and then get set as exceptions occur. To support 'from None', __context__ will stay as it is, but __cause__ will start out as False, and will change to None when the 'raise ... from None' method is used. If __cause__ is False the __context__ (if any) will be printed. If __cause__ is None the __context__ will not be printed. if __cause__ is anything else, __cause__ will be printed. This has the benefit of leaving the __context__ intact for future logging, querying, etc., while suppressing its display if it is not caught. raise ... from ... is not disallowed outside a try block, but this behavior is not guaranteed to remain. -- Should that last disclaimer be there? Should it be changed? ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for allowing 'raise NewException from None'
On Mon, Jan 30, 2012 at 2:51 PM, Ethan Furman et...@stoneleaf.us wrote: raise ... from ... is not disallowed outside a try block, but this behavior is not guaranteed to remain. -- Should that last disclaimer be there? Should it be changed? I'd leave it out - the original PEP didn't disallow it, enforcing it would be annoying, and it's easy enough to pick up if you happen to happen to care (it will mean __cause__ is set along with __context == None). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
