Mailman 3 March 2008 - Python-Dev

Proposal: from __future__ import unicode_string_literals
by Lennart Regebro 25 Mar '08

25 Mar '08

Eric Smith wrote: > It's not implementable because the work has to occur in ast.c (see > Py_UnicodeFlag). It can't occur later, because you need to skip the > encoding being done in parsestr(). But the __future__ import can only > be interpreted after the AST is built, at which time the encoding has > already been applied. There are some radical things you could do to > work around this, but it would be a gigantic change. Oh, <swear words>! > Pretty much. And even if it were possible, I don't see the point in > doing it. The point is this: http://regebro.wordpress.com/2008/03/22/why-python-26-and-30-compatibility-… Basically, the 2to3 strategy on large codebases supported by a wide set of developers isn't likely to be maintanable, and without a gradual path forward, 3.0 isn't likely to be adopted in some parts of the Python community. Worst case this splits the efforts of the community into two groups, which would be damaging to Python as a whole. Howver: If 2.6 doesn't support this it's not the end of the world. Because if it turn out to be necessary, a 2.7 that does could always be released. I don't know about other large codebases like Twisted, but the Zope/Plone world isn't likely to even try moving to 3.0 any time soon after it's final release, so since it's complicated you can probably wait with this support until it turns out to be needed. M.-A. Lemburg wrote: > Could we point them to a special byte-code compiler such as Andrew > Dalke's python4ply: ??? I'm not sure what this means... :) -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64

10 29

Re: [Python-Dev] [Python-checkins] r61709 - python/trunk/Doc/library/functions.rst python/trunk/Doc/library/future_builtins.rst python/trunk/Doc/library/python.rst
by Jim Jewett 25 Mar '08

25 Mar '08

What is the precise specification of the builtin "print" function. Does it call "str", or does it just behave as if the builtin str had been called? In 2.5, the print statement ignores any overrides of the str builtin, but I'm not sure whether a _function_ should -- and I do think it should be specified. -jJ On 3/21/08, georg.brandl <python-checkins(a)python.org> wrote: > New Revision: 61709 ============================================================================== > +++ python/trunk/Doc/library/functions.rst Fri Mar 21 20:37:57 2008 > @@ -817,6 +817,33 @@ ... > +.. function:: print([object, ...][, sep=' '][, end='\n'][, file=sys.stdout]) ... > + All non-keyword arguments are converted to strings like :func:`str` does

2 1

Proposal: from __future__ import unicode_string_literals
by Jim Jewett 24 Mar '08

24 Mar '08

> Maybe it's not apparent to people that hasn't > developed in that kind of environment, and > I'm sorry I'm not able to make this clearer. I think I understand the issue. Some contributors will be running under 2.6, others will be running under 3.0. Either the code forks, or one of them is working with (and developing patches against) the result of a compilation step, instead of against the original source code. For example, if I'm using the (real source) py2.6 code, and I create a patch that works for me, it is ready for testing and submission. If I'm using the (generated) py3 code, then I first have to get a copy of the (source) 2.6, figure out how I *would* have written it there, then keep tweaking it so that the generator eventually puts out ... what I had originally written by hand. My (working in 3.0) task would be easier if there is also a 3to2 (so that I can treat my own code as the source), but then entire files will do flip-flops on a regular basis (depening on which version was generated), unless 2to3 and 3to2 somehow create a perfect round-trip. And that compile step -- it can be automated, but I suspect most python projects don't yet have a good place to put the hooks, simply because they haven't needed to in the past. The end result is that the barrier to contributions becomes much higher for people working in at least one of the versions. -jJ

3 2

windows standard [was: PEP 365 (Adding the pkg_resources module)]
by Jim Jewett 24 Mar '08

24 Mar '08

Terry Reedy > The standard (and to me, preferable) way of dealing > with such things is to have an 'installation manager' > that can reinstall as well as delete and that has a > check box for various things to delete. This is what > Python needs. Paul Moore: > I'd dispute strongly that this is a "standard". > It may be preferable, but I'm not sure where you > see evidence of it being a standard. When I install a large program (such as developer tools, or python itself) on Windows, I expect a choice of "default" or "custom". When I choose custom, I expect a list of components, which can be chosen, not chosen, or mixed (meaning that it has subcomponents, only some of which are chosen). The whole thing only shows up once in Add/Remove programs. If I select it, I do get options to Change or Repair. These let me change my mind on which subcomponents are installed. If I install python and then separately install Zope, it may or may not make sense for Zope to be listed separately as a "program" to Add or Remove. It does not make sense (to me anyhow) have several individual packages within Zope each listed independently at the Windows level. (Though, to be fair, many (non-python) applications *do* make more than one entry.) -jJ

3 2

PEP 3127 (Integer Literal Support and Syntax): %o and %b
by Eric Smith 24 Mar '08

24 Mar '08

I've been double checking the PEP 3127 implementation in py3k and the backport I did to 2.6. The PEP says this about the % operator: "The string (and unicode in 2.6) % operator will have 'b' format specifier added for binary, and the alternate syntax of the 'o' option will need to be updated to add '0o' in front, instead of '0'." The %b operator was not added to 3.0, so I'll look into doing that in both 2.6 and 3.0 (which I opened as issue 2416). What should be done for '%#o' formatting in 2.6? The above sentence from the PEP implies it should be modified to add '0o' instead of '0', even in 2.6. But that seems like a bad idea to me. Maybe it should stay as-is, but add a -3 warning? Unfortunately, there'd be no way to change your code to get rid of the warning, short of switching to str.format() or adding a __future__ import (shudder). In 3.0, '%#o' already adds the leading '0o'.

2 2

Making sys.py3k_warning writable
by Steven Bethard 23 Mar '08

23 Mar '08

Right now, test_py3kwarn only runs if the test suite is run using the -3 command line flag to Python. So for most regrtest runs (e.g. the buildbots) this test will never be run. It would be nice to be able to turn the flag on from Python (e.g. within test_py3kwarn). Is that possible? Here's what I tried and it didn't seem to work:: $ python_d.exe Python 2.6a1+ (trunk:61715M, Mar 21 2008, 14:33:00) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys; sys.py3k_warning = True; callable(int) True And here's what happens when you specify -3 at the command line: $ python_d.exe -3 Python 2.6a1+ (trunk:61715M, Mar 21 2008, 14:33:00) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> callable(int) __main__:1: DeprecationWarning: callable() not supported in 3.x. Use hasattr(o, '__call__'). True Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy

4 11

Fixing code that produces -3 warnings in the Python 2.6 stdlib
by Steven Bethard 23 Mar '08

23 Mar '08

On Sun, Mar 23, 2008 at 3:02 PM, "Martin v. Löwis" wrote: [talking about running the buildbots using the -3 flag to issue Py3K warnings] > Yes. I don't think it should be turned on regularly in the tests until > they regularly are quiet under -3. So the plan is to silence all Py3K warnings in the Python 2.6 stdlib? I'd like to see this happen, but I vaguely remembered some people being against this idea, so I'd like to make sure. For what it's worth, I started an issue for this earlier: http://bugs.python.org/issue2402 Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy

2 1

State of N-dimensional array interface
by Mike Sullivan 23 Mar '08

23 Mar '08

What is the current state of the N-D Array Interface proposal (http://numpy.scipy.org/array_interface.shtml). Some work was done on this in an earlier Summer of Code, but it seems to never have been included. Does anybody know what state that work is in and what prevented it's inclusion? (I am interested in completing this as a Summer of Code project. I posted about this on the SOC list, and received a suggestion to try asking python-dev.) -- Mike Sullivan

2 1

Re: [Python-Dev] [Python-checkins] r61796 - in python/trunk: Doc/library/random.rst Lib/random.py Lib/test/test_random.py Misc/NEWS
by Nick Coghlan 23 Mar '08

23 Mar '08

> +## -------------------- triangular -------------------- > + > + def triangular(self, low, high, mode): > + """Triangular distribution. > + > + Continuous distribution bounded by given lower and upper limits, > + and having a given mode value in-between. > + > + http://en.wikipedia.org/wiki/Triangular_distribution > + > + """ > + u = self.random() > + c = (mode - low) / (high - low) > + if u > c: > + u = 1 - u > + c = 1 - c > + low, high = high, low > + return low + (high - low) * (u * c) ** 0.5 > + Would it be worth having default values on the parameters for this? def triangular(self, low=0, high=1, mode=None): u = self.random() if mode is None: c = 0.5 else: c = (mode - low) / (high - low) if u > c: u = 1 - u c = 1 - c low, high = high, low return low + (high - low) * (u * c) ** 0.5 At the very least, supporting mode=None would be convenient when you want a symmetric triangular distribution - having to calculate the median, pass it in as the mode, then have the function reverse that to get 0.5 seems a little wasteful. Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org

1 0

Distutils patches review request
by Tarek Ziadé 23 Mar '08

23 Mar '08

Hi, I would like to make request for a review of three patches: #2385: fixes a run_setup bug, and adds a test_core module, that can be used later to improve core.py coverage (http://bugs.python.org/issue2385) #2461: adds a test_util.py to distutils, to cover util.py. It does not cover byte_compile yet, but others are covered. (http://bugs.python.org/issue2461) #1858 (http://bugs.python.org/issue1858): - makes .pypirc support multiple servers (see http://wiki.python.org/moin/EnhancedPyPI) - superseeds #1741 (see http://bugs.python.org/issue1741) - superseeds #2166 ( see http://bugs.python.org/issue2166) - adds unit tests for upload and register (test_upload, test_register) Best regards Tarek -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/

1 0