Re: [Python-Dev] List vs Tuple / Homogeneous vs Heterogeneous / Mutable vs Immutable
On Thu, Apr 24, 2014 at 1:59 PM, Łukasz Langa wrote: > On Apr 17, 2014, at 11:49 AM, Brett Cannon wrote: > >> Think of tuples like a struct in C, lists like an array. > > > I generally agree but it’s a bit more complex, for instance when you have a > homogenous sequence but want it to be hashable. I just hit that today and > felt a little bad using tuple because of that “struct” mindset :) All you need is a "frozenlist" type, parallel to "frozenset": frozenlist = tuple # Magic! some_dict[frozenlist([...])] = some_value ChrisA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ref leaks
On Wed, Apr 23, 2014, at 19:14, Ethan Furman wrote: > Command line: > >./python -m test.regrtest -v -R3:3 test_tools > > Results: > >Ran 44 tests in 7.628s > >OK (skipped=1) >. >test_tools leaked [0, 2, 2] references, sum=4 >1 test failed: >test_tools > > Any words of wisdom for tracking those leaks? Unless it's consistent, that sort of behavior usually just gets dismissed as intermittent. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] List vs Tuple / Homogeneous vs Heterogeneous / Mutable vs Immutable
On Apr 17, 2014, at 11:49 AM, Brett Cannon wrote: > Think of tuples like a struct in C, lists like an array. I generally agree but it’s a bit more complex, for instance when you have a homogenous sequence but want it to be hashable. I just hit that today and felt a little bad using tuple because of that “struct” mindset :) -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] ref leaks
Command line: ./python -m test.regrtest -v -R3:3 test_tools Results: Ran 44 tests in 7.628s OK (skipped=1) . test_tools leaked [0, 2, 2] references, sum=4 1 test failed: test_tools Any words of wisdom for tracking those leaks? -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (3.4): Prevent Sphinx error on whatsnew/changelog
On April 23, 2014 5:24:53 PM CDT, Terry Reedy wrote: >On 4/23/2014 11:05 AM, zach.ware wrote: >> http://hg.python.org/cpython/rev/75419257fec3 >> changeset: 90440:75419257fec3 >> branch: 3.4 >> parent: 90437:5d745d97b7da >> user:Zachary Ware >> date:Wed Apr 23 10:04:20 2014 -0500 >> summary: >>Prevent Sphinx error on whatsnew/changelog >> >> files: >>Misc/NEWS | 2 +- >>1 files changed, 1 insertions(+), 1 deletions(-) >> >> >> diff --git a/Misc/NEWS b/Misc/NEWS >> --- a/Misc/NEWS >> +++ b/Misc/NEWS >> @@ -44,7 +44,7 @@ >> at the same time without losing the Popen.returncode value. >> >> - Issue #21127: Path objects can now be instantiated from str >subclass >> - instances (such as numpy.str_). >> + instances (such as ``numpy.str_``). > >Could you explain this? I thought NEWS was a plain text file without >.rst markup. Doc/whatsnew/changelog.rst includes the full text of Misc/NEWS, which means Sphinx doesn't like markup issues in NEWS. -- Zach (on a phone) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Patches in need of review
On 4/23/2014 3:27 PM, Claudiu Popa wrote: * http://bugs.python.org/issue16104 `Use multiprocessing in compileall script` This patch adds a new command line argument to `compileall`, also a new argument to `compileall.compile_dir`, which controls the number of worker processes used to compile a given directory. The title of the issue is actually misleading a little, because the patch uses `concurrent.futures` instead. I think titles should give goal, not intended or expected method. I changed the title accordingly. Compileall script: add option to use multiple cores -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Patches in need of review
Hello!
This approach worked for Nikolaus and I hope that it could work for me.
I have a couple of languishing patches, waiting for a core dev
to review, reject or commit them. I consider them ready to go,
but another pair of eyes could unveil unknown problems to me.
I pinged some issues from this list on core-mentorship a month ago,
without luck though. Here they are:
* http://bugs.python.org/issue19385
`dbm.dumb should be consistent when the database is closed`
This patch adds a check for operations with closed
dbm.dumb databases. The problem is that currently this
fails with AttributeError:
>>> import dbm.dumb as d
>>> db = d.open('test.dat', 'c')
>>> db.close()
>>> db.keys()
Traceback (most recent call last):
File "", line 1, in
File "/tank/libs/cpython/Lib/dbm/dumb.py", line 212, in keys
return list(self._index.keys())
AttributeError: 'NoneType' object has no attribute 'keys'
With this patch, the error is consistent with the other
dbm flavours.
* http://bugs.python.org/issue16104
`Use multiprocessing in compileall script`
This patch adds a new command line argument to `compileall`, also
a new argument to `compileall.compile_dir`, which controls the number
of worker processes used to compile a given directory.
The title of the issue is actually misleading a little,
because the patch uses `concurrent.futures` instead.
* http://bugs.python.org/issue19714
`Add tests for importlib.machinery.WindowsRegistryFinder.`
This is Windows specific and adds tests for the finder
in the title.
* http://bugs.python.org/issue17442
`code.InteractiveInterpreter doesn't display the exception cause`
This patch adds the ability for `code.InteractiveInterpreter` instances
to display the exception cause as seen below:
- currently
>>> try:
...1 / 0
... except ZeroDivisionError as exc:
...raise IOError from exc
...
Traceback (most recent call last):
File "", line 4, in
OSError
- with the patch
>>> try:
...1 / 0
... except ZeroDivisionError as exc:
...raise IOError from exc
...
Traceback (most recent call last):
File "", line 2, in
ZeroDivisionError: division by zero
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "", line 4, in
OSError
Thank you for your time!
Claudiu
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] this is what happens if you freeze all the modules required for startup
On Fri Apr 18 2014 at 5:03:33 PM, Ezio Melotti wrote: > Hi, > > On Thu, Apr 17, 2014 at 9:09 PM, Brett Cannon wrote: > > > > > > On Thu Apr 17 2014 at 1:34:23 PM, Jurko Gospodnetić > > wrote: > >> > >>Hi. > >> > >> On 14.4.2014. 23:51, Brett Cannon wrote: > >> > Now the question is whether the maintenance cost of having to rebuild > >> > Python for a select number of stdlib modules is enough to warrant > >> > putting in the effort to make this work. > >> > >>I would really love to have better startup times in production, but I > >> would also really hate to lose the ability to hack around in stdlib > >> sources during development just to get better startup performance. > >> > >>In general, what I really like about using Python for software > >> development is the ability to open any stdlib file and easily go poking > >> around using stuff like 'import pdb;pdb.set_trace()' or simple print > >> statements. Researching mysterious behaviour is generally much much > >> MUCH! easier (read: takes less hours/days/weeks) if it ends up leading > >> into a stdlib Python module than if it takes you down into the bowels of > >> some C module (think zipimport.c *grin*). Not to mention the effect that > >> being able to quickly resolve a mystery by hacking on some Python > >> internals leaves you feeling very satisfied, while having to entrench > >> yourself in those internals for a long time just to find out you've made > >> something foolish on your end leaves you feeling exhausted at best. > > > > > > Freezing modules does not affect the ability to use gdb. And as long as > you > > set the appropriate __file__ values then tracebacks will contain even the > > file line and location. > > > > Will the tracebacks only contain the line number or the line of code too? > Yes. > > I've seen tracebacks involving importlib,_bootstrap that didn't > include the code, and I'm wondering if we will get something similar > for all the other modules you are freezing: > > Traceback (most recent call last): > File "/tmp/foo.py", line 7, in > import email > File "", line 1561, in _find_and_load > File "", line 1519, in > _find_and_load_unlocked > File "", line 1473, in _find_module > File "", line 1308, in find_module > File "", line 1284, in _get_loader > File "", line 1273, in _path_importer_cache > File "", line 1254, in _path_hooks > TypeError: 'NoneType' object is not iterable > > Best Regards, > Ezio Melotti > That's because the frozen importer doesn't define get_source(). But since we have the source in this instance the __loader__ can be updated to be SourceFileLoader so that get_source() is available: http://bugs.python.org/issue21335 . ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
