Mailman 3 January 2007 - Python-Dev

Re: [Python-Dev] The bytes type
by glyph＠divmod.com Jan. 17, 2007

Jan. 17, 2007

On 06:49 pm, python(a)rcn.com wrote: >I think we should draw a line in the sand and resolve not to garbage-up Py2.6. >The whole Py3.0 project is about eliminating cruft and being free of the >bonds of backwards compatibility. Adding non-essential cruft to Py2.6 >goes against that philosophy. Emotionally charged like "cruft" and "garbage" are obscuring the issue. Let's replace them with equivalents charged in the opposite direction: "I think we should draw a line in the sand and … [View More]

7 10

Re: [Python-Dev] Proposed 3.0 compatiblity module
by Phillip J. Eby Jan. 17, 2007

Jan. 17, 2007

At 03:47 PM 1/16/2007 -0800, Guido van Rossum wrote: >Oh, as long as we're talking adding features to 2.6 I'm fine. I >thought you were proposing changes to the plans for 3.0, as in your >proposal" regarding the dict view API. Nah, that was a side tangent, combined with a partial lack of understanding of how the view thing was supposed to work. Having to wrap 'em with list() calls is annoying but doable. I was just throwing out an idea I didn't realize had already been shot down.

1 0

Proposed 3.0 compatiblity module
by Raymond Hettinger Jan. 17, 2007

Jan. 17, 2007

ISTM, we can decide to limit 3.0's impact to a single compatibility module, essentially as an alternate set of builtins. import __new_builtins__ for name in 'bytes dict coerce'.split(): # list any new features you want to support setattr(__builtins__, name, getattr(__new_builtins__, name)) The bytes type would just be the new type. The dict would have keys=iterkeys, no has_key, etc. The coerce function would work but have a DeprecationWarning or somesuch. If you want future … [View More]

4 6

Re: [Python-Dev] Proposed 3.0 compatiblity module
by Phillip J. Eby Jan. 17, 2007

Jan. 17, 2007

At 03:18 PM 1/16/2007 -0800, Guido van Rossum wrote: >On 1/16/07, Phillip J. Eby <pje(a)telecommunity.com> wrote: > > The idea here being that, once 2.6 is widely-enough deployed that it can be > > assumed as a base for one's users, you can simply run the translator once, > > do any cleanup, and then have 3.0-clean code that also still runs for your > > installed base. > > > > That way, there's no chasm to leap; just a code cleanup. > >I … [View More]

2 1

Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater
by "Martin v. Löwis" Jan. 17, 2007

Jan. 17, 2007

glyph(a)divmod.com schrieb: > Also, the exact strategy I suggested could be implemented in various > ways that might be efficient. Here are a few ways it might be made more > efficient than the straw many of one extra dict lookup per call to > keys() et. al.: I'm not saying that an efficient implementation is impossible, but I still don't see it. The ones you suggest don't work that well: > * Don't make it a dictionary key; make it an attribute of the module at > the C … [View More]

3 3

Re: [Python-Dev] The bytes type
by Phillip J. Eby Jan. 17, 2007

Jan. 17, 2007

At 09:50 AM 1/16/2007 -0800, Guido van Rossum wrote: >Actually it's very easy to write code using keys(), items() and >values() that works as well in 2.2 as it works in 3.0: never use the >iter* variants, and don't sweat the performance costs of creating a >list so much. If you can't afford to create a list, iterate over the >dict itself, which will give you the keys in both versions. Actually, the main reason I use items() or keys() is because I want to mutate the dictionary, … [View More]

1 0

Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater
by glyph＠divmod.com Jan. 16, 2007

Jan. 16, 2007

On 07:42 pm, thomas(a)python.org wrote: >On 1/10/07, Raymond Hettinger <raymond.hettinger(a)verizon.net> wrote: >> >><"Anthony Baxter"> >> > Comments? What else should get warnings? >> >>It is my strong preference that we not go down this path. >>Instead, the 2.6 vs 3.0 difference analysis should go in an >>external lint utility. >Having Python 2.6 optionally warn for >3.0-compatibility is a lot easier for the average developer … [View More]

22 34

Re: [Python-Dev] [Python-3000] Warning for 2.6 and greater
by glyph＠divmod.com Jan. 16, 2007

Jan. 16, 2007

On 08:19 am, martin(a)v.loewis.de wrote: >Georg Brandl schrieb: >>> If Python 3.0 was simply a release which removed deprecated features, >>> there would clearly be no issue. I would update my code in advance of >>> the 3.0 release to not use any of those features being removed, and >>> I'm all set. But that's not what I'm hearing. Python 3 is both adding >>> new ways to do things, and removing the older way, in the same >>> version, with … [View More]

3 3

buglet in long("123\0", 10)
by Guido van Rossum Jan. 15, 2007

Jan. 15, 2007

What's wrong with this session? :-) Python 2.6a0 (trunk:53416, Jan 13 2007, 15:24:17) [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> int('123\0') Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: null byte in argument for int() >>> int('123\0', 10) Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: … [View More]

5 5

Rewrite of import in Python source (sans docs) is complete
by Brett Cannon Jan. 15, 2007

Jan. 15, 2007

Finally, after a few months worth of work, I have finally gotten far enough in my import rewrite that I am willing to stick my neck out and say it is semantically complete! You can find it in the sandbox under import_in_py. So, details of this implementation. I implemented PEP 302 importers/loaders for built-in, frozen, extension, .py, and .pyc files along with rewriting the steps __import__ goes through to do an import. I also developed an API for .py/.pyc file handling so that there is a … [View More]generic filesystem importer/loader and a separate handler for .py/.pyc files. This should allow for (relatively) easy selective overriding of just how .py/.pyc files are stored (e.g., introducing a database backend) or how variants on .py/.pyc files are handled (e.g., Quixote's .ptl format). This code has extensive tests and so I am fairly confident that it does what is expected of an import rewrite. There are actually more lines in the test file than the implementation. There is also a mock implementation used for testing. Was interesting doing this in such a test-driven, XP style of only coding what I needed. I have run this code through the entire regression test suite and that is where you find out subtle differences between this implementation and the built-in import (you can see for yourself with the regrtest.sh shell script). First test_pkg will fail because currently the new import adds a __loader__ attribute on all modules (that might change for security reasons) and test_pkg is an old, stdout comparing test. Second, test_runpy fails because I have not implemented get_code on the filesystem loader which is required by runpy. Both are shallow issues that can be dealt with. Third, and the hardest difference to deal with, is that you will get some warnings that print out that you normally don't see. This is because warnings.warn and its stack_level argument don't have the effect people are used to when importing a deprecated module. Before you could set stack_level to 2 and it would look like it came from the import statement. But now, with import written in Python and thus on the call stack compared to being in C and thus not showing up, two levels back is still in the import code. I really don't know how this should be dealt with short of saying that the rule of thumb with 2 stack levels back for a warning does not work when done at the import level. It is not blazing fast at the moment. Some things, like the built-in and frozen importers/loaders could be rewritten in C without huge issue. I am also sure I have made some stupid design decisions at various points in the code. But there is benchmarking code in the sandbox called importbench and it showed up a 10x speed slowdown on a Linux box I was using in mid to late December when doing a fresh import of certain types (I don't remember exactly which kind off the top of my head). Because of this current slowness I don't know if people want to rush into trying to make this the default import implementation quite yet or if this is not too big of a thing since the common case of pulling out of sys.modules is not that much slower. I know I am currently not planning on devoting the time to bootstrap it in as I have my security work to finish first along with other Python stuff that seems more pressing to me. And since (I think) I don't need to bootstrap it in order to finish my security work I can't justify spending work time on it. But I can rearrange priorities if people really want to pursue this (especially if I can get some help with it). As with the module's name, it is currently named 'importer', but that is bad since it conflicts with the idea of importers from PEP 302. I was thinking importlib, but I wanted to wait and see what other people thought. Don't know if you guys are okay with me checking this in without having it vetted by the community first like we prefer all new modules to do. I have not done the LaTeX docs yet. I think that is all of the details that I can think of. I am still working towards implementing the security needed so that an application that embeds Python can execute arbitrary code securely. Giving a talk at PyCon on the topic for anyone interested. Special thanks needs to go to Paul Moore who I talked to through most of the design of the code. Nick Coghlan also provided some handy feedback. And Neal Norwitz for bugging about wanting something like this done. Plus thanks to everyone who has shown support. -Brett [View Less]

2 2