Mailman 3 March 2010 - Python-Dev

argparse.py is licensed under the Apache License
by Amaury Forgeot d'Arc March 24, 2010

March 24, 2010

Hello, I noticed that the newly added argparse module has an unusual licence header, included below. This is the only file in the Python tree that contains an explicit reference to the Apache License, and this leads me to some questions: - Is the Apache license compatible with the Python license? Will this cause problem for some organizations that redistribute Python, possibly with proprietary software? Are there additional constraints? - Does this addition require a paragraph in the python documentation? http://docs.python.org/license.html#licenses-and-acknowledgements-for-incor… - The Apache License states that:: You must cause any modified files to carry prominent notices stating that You changed the files but r78749 already modified the file (to remove a py3k warning) didn't we break the License? - Did the contributor sign a Contributor agreement? In this case, shouldn't the code be marked as "Licensed to PSF under a Contributor Agreement", as mentioned in the contribution form? http://www.python.org/psf/contrib/contrib-form And then, could this Apache License be removed? The first lines of Lib/argparse.py are: # Copyright 2006-2009 Steven J. Bethard <steven.bethard(a)gmail.com>. # # Licensed under the Apache License, Version 2.0 (the "License"); you may not # use this file except in compliance with the License. You may obtain a copy # of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, WITHOUT # WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the # License for the specific language governing permissions and limitations # under the License. -- Amaury Forgeot d'Arc

4 4

At least one package management tool for 2.7
by anatoly techtonik March 24, 2010

March 24, 2010

I wonder if there are many people here who don't use some kind of "easy_install" package for package management in their Python / virtualenv installations? I propose to include at least one such package that is capable to auto-update itself in Python 2.7 C:\~env\Python27>python.exe -m easy_install C:\~env\Python27\python.exe: No module named easy_install C:\~env\Python27>python.exe -m pip C:\~env\Python27\python.exe: No module named pip It bugs me when I have to troubleshoot things on yet another machine that doesn't have some kind of `setuptools` installed. Or when I have to test some bug in my package on different Python version with a clean install and need some dependencies. -- anatoly t.

8 13

Joel Spolsky on Mercurial
by Terry Reedy March 24, 2010

March 24, 2010

In what might be his last Joel on Software post (for awhile, at least) http://www.joelonsoftware.com/items/2010/03/17.html Summary: Early 2009: Joel disses DVCSes. His programmers switch from subversion to hg. Joel grumbles. His programmers develop an hg-related product. Joel takes a better look. Joel sees the light: Subversion controls versions, hg controls changes; this make merging much easier. Joel flips (his opinion): Switch now! Joel write hg tutorial: http://hginit.com/ It starts with "Subversion Re-education" for existing version-oriented system users and continue with "Ground up Mercurial" where new vcs users can start. It has several simple examples. Having gotten that far, I think this might be worth referencing in new dev docs. Terry Jan Reedy

7 7

Attribute lookup ambiguity
by Pascal Chambon March 23, 2010

March 23, 2010

Hello I've already crossed a bunch of articles detailing python's attribute lookup semantic (__dict__, descriptors, order of base class traversing...), but I have never seen, so far, an explanation of WHICH method did waht, exactly. I assumed that getattr(a, b) was the same as a.__getattribute__(b), and that this __getattribute__ method (or the hidden routine replacing it when we don't override it in our class) was in charge of doing the whole job of traversing the object tree, checking descriptors, binding methods, calling __getattr__ on failure etc. However, the test case below shows that __getattribute__ does NOT call __getattr__ on failure. So it seems it's an upper levl machinery, in getattr(), which is in chrge of that last action. Is that on purpose ? Considering that __getattribute__ (at lest, object.__getattribute__) does 90% of the hard job, why are these 10% left ? Can we find somewhere the details of "who must do what" when customizing attribute access ? Shouldn't we inform people about the fact that __getattribute__ isn't sufficient in itself to lookup an attribute ? Thanks for the attention, regards, Pascal ======= INPUT ======= class A(object): def __getattribute__(self, name): print "A getattribute", name return object.__getattribute__(self, name) def __getattr__(self, name): print "A getattr", name return "hello A" class B(A): def __getattribute__(self, name): print "B getattribute", name return A.__getattribute__(self, name) def __getattr__(self, name): print "B getattr", name return "hello B" print A().obj print "---" print B().obj print "---" print getattr(B(), "obj") print "-----" print object.__getattribute__(B(), "obj") # DOES NOT CALL __getattr__() !!! =========== OUTPUT =========== A getattribute obj A getattr obj hello A --- B getattribute obj A getattribute obj B getattr obj hello B --- B getattribute obj A getattribute obj B getattr obj hello B ----- Traceback (most recent call last): File "C:\Users\Pakal\Desktop\test_object_model.py", line 34, in <module> print object.__getattribute__(B(), "obj") # DOES NOT CALL __getattr__() !!!??? AttributeError: 'B' object has no attribute 'obj'

4 9

Re: [Python-Dev] __pycache__ creation
by Henning von Bargen March 23, 2010

March 23, 2010

Antoine Pitrou wrote: > > or if a user installs by dragging into > > site-packages instead of using an installer? > > Well... do people actually do this? Why not? And it is also common to just set the PYTHONPATH environment variable instead of using setup.py install or copy the files to the lib/site-packages directory. I prefer it that way because it gives a clean separation between standard library files and application specific files. For example, if I want to use another Python version, I can just delete the python26 directory because I know it doesn't contain any application-specific code, just the standard library files. Considering the complexity, the risks and the benefit of the whole __pycache__ thingie, I'm -1... Henning

1 0

Decimal <-> float comparisons in py3k.
by Mark Dickinson March 23, 2010

March 23, 2010

Hello all, Currently in Python 2.x, Decimal-to-float comparisons behave as follows: >>> Decimal(1) < float(4) False >>> Decimal(4) < float(1) False That is, any Decimal sorts before any float (though this is arbitrary: it's possible that on some implementations any float sorts before any Decimal). This causes (a) confusion, and (b) bugs, especially when floats and Decimals are accidentally combined in a program. There probably aren't too many legitimate reasons for deliberately mixing floats and Decimals in the same calculation, so preventing accidents is the main concern here. In Python 3.x, however, such comparisons raise a TypeError ("unorderable types: Decimal() < float()"). http://bugs.python.org/issue2531 ('float compared to decimal is silently incorrect') was opened for this a while ago. I'm planning to commit a change to trunk that changes the behaviour so that the comparison result is based on the respective values of the arguments (so the results above would be True and False respectively). Question for python-dev people (and the point of this email): should this change be forward ported to py3k? On the one hand there's something to be said for maintaining a clean separation between the float and Decimal types, allowing only explicit conversions from one to the other; mixed-type arithmetic between floats and Decimals was very deliberately not permitted in the original PEP, and that's unlikely to change in a hurry. On the other hand, there's value in keeping 2.x and 3.x aligned where possible for the sake of 2-to-3 porters, and the new behaviour may even be useful. Even with the TypeError above, there are still some py3k surprises arising from the ability to compare ints and Decimals, and ints and floats, but not floats and Decimals. A quick tour of some of these surprises, in trunk: >>> from decimal import Decimal >>> Decimal(1) < 2 < float(3) < Decimal(1) # < is non-transitive True >>> Decimal(1) == 1 == float(1) # so is equality True >>> Decimal(1) == float(1) False >>> d1, i1, f1 = Decimal(1), float(1), 1 >>> set([d1, i1, f1]) == set([f1, i1, d1]) # sets with the same elements are different False >>> sorted([d1, i1, f1]) == sorted([f1, i1, d1]) False and in py3k: >>> from decimal import Decimal >>> Decimal(1) < 2 < float(3) < Decimal(1) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unorderable types: float() < Decimal() >>> Decimal(1) == 1 == float(1) True >>> Decimal(1) == float(1) False >>> d1, i1, f1 = Decimal(1), float(1), 1 >>> set([d1, i1, f1]) == set([f1, i1, d1]) False >>> sorted([Decimal(1), 2, float(3)]) [Decimal('1'), 2, 3.0] >>> sorted([2, Decimal(1), float(3)]) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: unorderable types: float() < Decimal() >>> sorted([float(3), 2, Decimal(1)]) [Decimal('1'), 2, 3.0] By the way, even with the patch there are still problems with other numeric types: comparisons or set operations involving both Fraction and Decimal instances are going to cause similar difficulties to those above. In practice I think this is much less of an issue than the float/Decimal problem, since the chance of accidentally combining Fraction and Decimal types in a calculation seems significantly smaller than the chance of accidentally combining float and Decimal types. -- Mark

17 91

__file__ and bytecode-only
by Jim Jewett March 22, 2010

March 22, 2010

I understand the need to ship without source -- but why does that require supporting .pyc (or .pyo) -only? Couldn't vendors just replace the real .py files with empty files? Then no one would need the extra stat call, and no one would be bitten by orphaned .pyc files after a rename. [Yes, zips could still allow unmatched names; yes, it would be helpful if a tool were available to sync the last-modification time; yes a deprecation release should still be needed.] -jJ

13 30

[RELEASED] Python 3.1.2
by Benjamin Peterson March 21, 2010

March 21, 2010

On behalf of the Python development team, I'm joyful to announce the second bugfix release of the Python 3.1 series, Python 3.1.2. This bug fix release fixes numerous issues found in 3.1.1, and is considered a production release. The Python 3.1 version series focuses on the stabilization and optimization of the features and changes that Python 3.0 introduced. For example, the new I/O system has been rewritten in C for speed. File system APIs that use unicode strings now handle paths with undecodable bytes in them. Other features include an ordered dictionary implementation, a condensed syntax for nested with statements, and support for ttk Tile in Tkinter. For a more extensive list of changes in 3.1, see http://doc.python.org/3.1/whatsnew/3.1.html or Misc/NEWS in the Python distribution. To download Python 3.1.2 visit: http://www.python.org/download/releases/3.1.2/ A list of changes in 3.1.2 can be found here: http://svn.python.org/projects/python/tags/r312/Misc/NEWS The 3.1 documentation can be found at: http://docs.python.org/3.1 Bugs can always be reported to: http://bugs.python.org Enjoy! -- Benjamin Peterson Release Manager benjamin at python.org (on behalf of the entire python-dev team and 3.1.2's contributors)

2 1

Silencing DeprecationWarning by default in Python 2.7 is silencing division warnings
by Brett Cannon March 20, 2010

March 20, 2010

I see two possible fixes for this. One is to not silence DeprecationWarning if Py_DivisionWarningFlag is set to >= 1. The other is to introduce a new subclass of DeprecationWarning called IntegerDivisionWarning and have that added to the warnings filter so that if it is triggered it is handled separately from what DeprecationWarning triggers. The former means that you might get more than you bargained for in terms of warnings as you are suddenly switching on all DeprecationWarnings on top of division warnings. The latter means that you now have to explicit care about IntegerDivisionWarning on top of DeprecationWarning (to minimize this I could have IntegerDivisionWarning added to the warnings filter only in the case of when Py_DivisionWarningFlag is set instead of blindly adding it). Thoughts? -Brett

3 3

Tracker opened/closed issue list: missing?
by Terry Reedy March 20, 2010

March 20, 2010

I did not receive the usual Friday tracker post on issues opened and closed during the past week. Did anyone else? I am reading via gmane. Terry Jan Reedy

4 3