[Python-Dev] argparse.py is licensed under the Apache License
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-incorporated-software - 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.beth...@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 ___ 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] Mixing float and Decimal -- thread reboot
On Wed, Mar 24, 2010 at 5:36 AM, Stephen J. Turnbull step...@xemacs.org wrote:
Steven D'Aprano writes:
As usual though, NANs are unintuitive:
d = {float('nan'): 1}
d[float('nan')] = 2
d
{nan: 1, nan: 2}
I suspect that's a feature, not a bug.
Right: distinct nans (i.e., those with different id()) are treated as
distinct set elements or dict keys.
I don't see how it can be so. Aren't all of those entries garbage?
To compute a histogram of results for computations on a series of
cases would you not have to test each result for NaN-hood, then hash
on a proxy such as the string Nan?
So what alternative behaviour would you suggest, and how would you implement it?
I agree that many aspects of the current treatment of nans aren't
ideal, but I as far as I can see that's unavoidable. For sane
containment testing, Python's == operator needs to give an equivalence
relation. Meanwhile IEEE 754 requires that nans compare unequal to
themselves, breaking reflexivity. So there have to be some
compromises somewhere.
The current compromise at least has the virtue that it doesn't require
special-casing nans anywhere in the general containment-testing and
hashing machinery.
One alternative would be to prohibit putting nans into sets and dicts
by making them unhashable; I'm not sure what that would gain, though.
And there would still be some unintuitive behaviour for containment
testing of nans in lists.
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] At least one package management tool for 2.7
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\Python27python.exe -m easy_install C:\~env\Python27\python.exe: No module named easy_install C:\~env\Python27python.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. ___ 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] At least one package management tool for 2.7
On Wed, Mar 24, 2010 at 10:59 AM, anatoly techtonik techto...@gmail.com wrote: 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\Python27python.exe -m easy_install C:\~env\Python27\python.exe: No module named easy_install C:\~env\Python27python.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. We are working on distutils2 right now to improve the situation, and Ian has proposed to work on the possible inclusion of virtualenv in the stldib as well. I'll talk for distutils2 : The plan is to provide a distutils2 standalone version that can be installed from 2.4 to 3.x, and that will provide a basic installer/uninstaller via -m. Distutils2 is planned to be reintegrated in the stdlib in Python 3.3, and my goal is to release it when Python 2.7 final is released. The open question is: do we want to include a full installer that takes care of installing / removing dependencies as well ? I think not. Pip already provides this feature on the top of distutils (and distutils2 later I guess) and is not hard to install on the top of Python. But the auto-update story seems interesting, can you expand on this ? Tarek -- Tarek Ziadé | http://ziade.org ___ 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] Joel Spolsky on Mercurial
On Fri, Mar 19, 2010 at 11:00 AM, Dirkjan Ochtman dirk...@ochtman.nl wrote: Having gotten that far, I think this might be worth referencing in new dev docs. Will do. I finally read hginit yesterday, after having seen people rave about it on twitter for a few weeks, and it's a very friendly introduction. I more like hands-on approach that does use real world workflow instead of academic examples. For example, tutorial like Ondrej Certik made for SymPy patches using Mercurial queues. http://docs.sympy.org/sympy-patches-tutorial.html It goes straight from the problem in SymPy development you'd like to resolve for yourself and then shows how Mercurial helps with it. If you have more time to dig - you may read a book or Joel series. -- anatoly t. ___ 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] Mixing float and Decimal -- thread reboot
On Wed, 24 Mar 2010 08:51:36 pm Mark Dickinson wrote:
On Wed, Mar 24, 2010 at 5:36 AM, Stephen J. Turnbull
step...@xemacs.org wrote:
Steven D'Aprano writes:
As usual though, NANs are unintuitive:
d = {float('nan'): 1}
d[float('nan')] = 2
d
{nan: 1, nan: 2}
I suspect that's a feature, not a bug.
Right: distinct nans (i.e., those with different id()) are treated
as distinct set elements or dict keys.
I don't see how it can be so. Aren't all of those entries garbage?
To compute a histogram of results for computations on a series of
cases would you not have to test each result for NaN-hood, then
hash on a proxy such as the string Nan?
Not necessarily -- you could merely ignore any key which is a NaN, or
you could pass each key through this first:
def intern_nan(x, nan=float('nan')):
if math.isnan(x): return nan
return x
thus ensuring that all NaN keys were the same NaN.
So what alternative behaviour would you suggest, and how would you
implement it?
[...]
One alternative would be to prohibit putting nans into sets and dicts
by making them unhashable; I'm not sure what that would gain,
though. And there would still be some unintuitive behaviour for
containment testing of nans in lists.
I think that would be worse than the current situation. That would mean
that dict[some_float] would *nearly always* succeed, but occasionally
would fail. I can't see that being a good thing.
--
Steven D'Aprano
___
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] Mixing float and Decimal -- thread reboot
Mark Dickinson writes: On Wed, Mar 24, 2010 at 5:36 AM, Stephen J. Turnbull step...@xemacs.org wrote: Steven D'Aprano writes: I suspect that's a feature, not a bug. Right: distinct nans (i.e., those with different id()) are treated as distinct set elements or dict keys. I don't see how it can be so. Aren't all of those entries garbage? To compute a histogram of results for computations on a series of cases would you not have to test each result for NaN-hood, then hash on a proxy such as the string Nan? So what alternative behaviour would you suggest, and how would you implement it? I don't have an alternative behavior to suggest. I'm not suggesting that it's a bug, I'm suggesting that it's a wart: useless, ugly, and in some presumably rare/buggy cases, it could lead to nasty behavior. The example I have in mind is computing a histogram of function values for a very large sample of inputs. (This is a pathological example, of course: things where NaNs are representable generally won't be used directly as keys in a dictionary used to represent a histogram. Rather, they would be mapped to a representative value as the key.) If there are a lot of NaN's, the dictionary could get unexpectedly large. That's not Python's fault, of course: Meanwhile IEEE 754 requires that nans compare unequal to themselves, breaking reflexivity. So there have to be some compromises somewhere. Indeed. IEEE 754 compatibility *is* a feature. One alternative would be to prohibit putting nans into sets and dicts by making them unhashable; I'm not sure what that would gain, though. I would find that more intuitive. While NaNs aren't mutable, they're similar to mutable values in that their value is not deterministic in a certain sense. OTOH, since the only example I can think of where I would personally want to check whether a NaN is in a container is pathological, my intuition is hardly reliable. ___ 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] At least one package management tool for 2.7
Sure. Package management tool should have an ability to update itself when required regardless of Python release. For example:: python.exe -m easy_install setuptools This should be: python -m easy_install -U setuptools P.S. Wave effect. =) -- anatoly t. ___ 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] At least one package management tool for 2.7
On Wed, Mar 24, 2010 at 12:20 PM, anatoly techtonik techto...@gmail.com wrote: On Wed, Mar 24, 2010 at 12:26 PM, Tarek Ziadé ziade.ta...@gmail.com wrote: Distutils2 is planned to be reintegrated in the stdlib in Python 3.3, and my goal is to release it when Python 2.7 final is released. Does that means after Python 2.7, because I meant it to be before or at least with? The goal is to provide a first version by the time 2.7 is out. The open question is: do we want to include a full installer that takes care of installing / removing dependencies as well ? If there is a risk to get nothing at all in 2.7 distribution, because it just won't be ready/accepted by that time, then I it is certainly optional. Understand that the distutils2 project is happening outside the stdlib at this time, so you will have to install it on the top of Python in any case. Last, its release cycle will be shorter until it gets back in the stdlib, that will make it easy to add features. But the auto-update story seems interesting, can you expand on this ? Sure. Package management tool should have an ability to update itself when required regardless of Python release. For example:: python.exe -m easy_install setuptools This will get you new version of `setuptools` and `easy_install` module from it automagically. You do not need to install new version of `setuptools` manually or copy files from SVN if you want to see fixes before next Python release. The stuff you would likely need to do with distutils bugs, which I personally find awkward. Package management is orthogonal to Python releases, and it is more oriented at Python users who don't like to wait or follow PEPs. That's why package management tool such as 'easy_install' has shorter development cycle, and it should faster react to user feedback. What can be one of the reasons that no package management tool is included with Python. In various README you may often see requires setuptools 0.6c9 or similar. I can't see why package management tool can not detect this dependency and propose to update itself. If it is impossible to ship the whole package management system then at least Python distribution may carry small bootstrap script for it. When user tries to execute package management tools, it warns him that these are not installed and gives a hint where to get them:: python -m easy_install bla-bla-bla Error: easy_install module is not shipped with this Python release. Please execute the following command to install the latest version. python -m easy_bootstrap Interesting, can you start a new thread on distutils-SIG for this part, so we can discuss it there ? Regards Tarek -- Tarek Ziadé | http://ziade.org ___ 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] Mixing float and Decimal -- thread reboot
Steven D'Aprano wrote:
On Wed, 24 Mar 2010 08:51:36 pm Mark Dickinson wrote:
I don't see how it can be so. Aren't all of those entries garbage?
To compute a histogram of results for computations on a series of
cases would you not have to test each result for NaN-hood, then
hash on a proxy such as the string Nan?
Not necessarily -- you could merely ignore any key which is a NaN, or
you could pass each key through this first:
def intern_nan(x, nan=float('nan')):
if math.isnan(x): return nan
return x
thus ensuring that all NaN keys were the same NaN.
Interning NaN certainly seems like it should be sufficient to eliminate
the set/dict membership weirdness.
That is, make it so that the first two lines of the following return
True, while the latter two lines continue to return False:
float(nan) is float(nan)
False
dec(nan) is dec(nan)
False
float(nan) == float(nan)
False
dec(nan) == dec(nan)
False
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] Mixing float and Decimal -- thread reboot
Raymond Hettinger wrote: The decimal module is already drowning in complexity, so it would be best to keep it simple: one boolean flag that if set would warn about any implicit decimal/float interaction. Agreed - those that want exceptions instead can use the usual warnings module mechanisms to trigger them. 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] [Distutils] At least one package management tool for 2.7
On Wed, Mar 24, 2010 at 6:26 AM, Tarek Ziadé ziade.ta...@gmail.com wrote: The open question is: do we want to include a full installer that takes care of installing / removing dependencies as well ? I think not. Pip already provides this feature on the top of distutils (and distutils2 later I guess) and is not hard to install on the top of Python. Is pip able to determine and install dependencies recursively, like easy_install does? Or is it up to the requested package to it specify its dependencies (and its dependencies dependencies) in a pip requirements file that is distributed separately? Darren ___ 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] [Distutils] At least one package management tool for 2.7
On Wed, Mar 24, 2010 at 12:50 PM, Darren Dale dsdal...@gmail.com wrote: On Wed, Mar 24, 2010 at 6:26 AM, Tarek Ziadé ziade.ta...@gmail.com wrote: The open question is: do we want to include a full installer that takes care of installing / removing dependencies as well ? I think not. Pip already provides this feature on the top of distutils (and distutils2 later I guess) and is not hard to install on the top of Python. Is pip able to determine and install dependencies recursively, like easy_install does? Or is it up to the requested package to it specify its dependencies (and its dependencies dependencies) in a pip requirements file that is distributed separately? Pip uses the same standard: the install_requires option in setuptools, that is put in a requires.txt file when the egg-info is computed. Notice that we have defined this field in the new version of the metadata (PEP 345) for future interoperability. Let's remove python-dev for packaging talks in the next answers Regards Tarek Darren -- Tarek Ziadé | http://ziade.org ___ 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] At least one package management tool for 2.7
anatoly techtonik wrote: If it is impossible to ship the whole package management system then at least Python distribution may carry small bootstrap script for it. When user tries to execute package management tools, it warns him that these are not installed and gives a hint where to get them:: python -m easy_install bla-bla-bla Error: easy_install module is not shipped with this Python release. Please execute the following command to install the latest version. python -m easy_bootstrap Note that this idea has come up before and is *much* more likely to get traction than including a full package management system. The nature of package management is such that tying an installation system to the release cycle of the core interpreter is unlikely to end well. A bootstrapping tool that only knows how to download a single specific package would be much easier to keep stable. Even such a scaled back idea is still far from a certainty to be accepted though, given the number of people who vehemently object to duplicating any significant part of the functionality of the system package management tools (i.e. RPM, apt et al). At this point, the packaging story is in the hands of distutils-sig and they're pressing forward with several initiatives that will permit the construction of more robust and reliable Python-specific package management systems (such as supporting listing and uninstallation of installed packages). 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] __pycache__ creation
Barry Warsaw wrote: On Mar 22, 2010, at 12:38 PM, Guido van Rossum wrote: Huh? Last time I looked weren't we going to make __pycache__ the default (and eventually only) behavior? We definitely agreed it would be the default in Python 3.2. My recollection is that we agreed it would be the only on-demand way of writing pyc files, but that Python would read a lone .pyc file where the source would be if the source is missing, and that py_compile/compileall would support optional creation of those lone .pyc files. Yep, that's my recollection as well. I don't recall seeing an update to state that clearly in the PEP go by on the checkins list though :) 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] Mixing float and Decimal -- thread reboot
On Wed, 24 Mar 2010 10:47:26 pm Nick Coghlan wrote:
Steven D'Aprano wrote:
On Wed, 24 Mar 2010 08:51:36 pm Mark Dickinson wrote:
I don't see how it can be so. Aren't all of those entries
garbage? To compute a histogram of results for computations on a
series of cases would you not have to test each result for
NaN-hood, then hash on a proxy such as the string Nan?
Not necessarily -- you could merely ignore any key which is a NaN,
or you could pass each key through this first:
def intern_nan(x, nan=float('nan')):
if math.isnan(x): return nan
return x
thus ensuring that all NaN keys were the same NaN.
Interning NaN certainly seems like it should be sufficient to
eliminate the set/dict membership weirdness.
I didn't mean to suggest that Python should do that automatically! I
meant that the developer could easily intern NaNs if needed.
I wouldn't want Python to automatically intern NaNs, the reason being
that this would throw away information (at least potentially, depending
on the C library). According to the relevant IEEE standard, NaNs should
(may?) carry a payload. For example, Apple's SANE math library back in
the 1980s exposed this payload: NaNs created from different failures
would have a consistent payload, allowing the programmer to tell how
the NaN appeared in the calculation.
E.g. INF-INF would give you a payload of 123 (or whatever it was), while
log(-1) would give you a payload of 456. (I've made up the numbers,
it's been far too many years for me to remember what they were.)
The point is, whether Python currently exposes these payloads or not, we
shouldn't prohibit it. If programmers want to explicitly fold all NaNs
into one, it is easy to do so themselves.
--
Steven D'Aprano
___
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] __pycache__ creation
Ron Adam wrote: I think I misunderstood this at first. It looks like, while developing a python 3.2+ program, if you don't create an empty __pycache__ directory, everything will still work, you just won't get the .pyc files. That can be a good thing during development because you also will not have any problems with old .pyc files hanging around if you move or rename files. The behaviour you described (not creating __pycache__ automatically) was just a suggestion in this thread. The behaviour in the actual PEP (and what will be implemented for 3.2+) is to create __pycache__ if it is missing. 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] __pycache__ creation
On Mar 23, 2010, at 08:42 PM, Ron Adam wrote: It looks like, while developing a python 3.2+ program, if you don't create an empty __pycache__ directory, everything will still work, you just won't get the .pyc files. That can be a good thing during development because you also will not have any problems with old .pyc files hanging around if you move or rename files. Not quite. In PEP-3147-land, you do not need to create the empty __pycache__ directory, Python will create it for you on-demand. If you subsequently move the .py source file, the __pycache__/...pyc file will be ignored. So this is actually better than today because you can't accidentally load stale pyc files -- if they live inside __pycache__. For backward compatibility we'll still support loading lone pyc files in the source file directory (i.e. outside of __pycache__). -Barry signature.asc Description: PGP signature ___ 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 3147, __pycache__ directories and umask
Russell E. Owen wrote: This in turn implies that we may have to give up some support for dragging python modules into site-packages, e.g. not generate .pyc files for such modules. At least if we go that route it will mostly affect power users, who can presumably cope. And when someone drags a Python module into the per-user site-packages instead? [1] Yes, a shared Python needs to be managed carefully. Systems with a shared Python should also generally have a vaguely competent sysadmin running them. An unshared Python and associated packages under PEP 3147 should work just as well as they do under the existing pyc scheme (only without the source directory clutter). Cheers, Nick. [1] http://www.python.org/dev/peps/pep-0370/ -- 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] At least one package management tool for 2.7
On Wed, Mar 24, 2010 at 7:23 AM, anatoly techtonik techto...@gmail.com wrote:
Sure. Package management tool should have an ability to update itself when
required regardless of Python release. For example::
python.exe -m easy_install setuptools
This should be:
python -m easy_install -U setuptools
JFTR
More precisely, what I use for CI is
{{{
#!sh
$ easy_install -U setuptools==dev
}}}
but the `python -m` part should work as well ;o)
PS: e.g. that allows to check out code from SVN in order to use
setuptools 0.7.x `test_runner` switch like this
{{{
python -W ignore::DeprecationWarning setup.py test -r ciutils:junitrunner
}}}
;o)
--
Regards,
Olemis.
Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/
Featured article:
TracRpc: API v2: Test cases for XML-RPC ... PASS -
http://bitbucket.org/osimons/trac-rpc-mq/changeset/228ef43726b0/
___
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] [Distutils] At least one package management tool for 2.7
On Wed, Mar 24, 2010 at 7:50 AM, Darren Dale dsdal...@gmail.com wrote: On Wed, Mar 24, 2010 at 6:26 AM, Tarek Ziadé ziade.ta...@gmail.com wrote: The open question is: do we want to include a full installer that takes care of installing / removing dependencies as well ? I think not. Pip already provides this feature on the top of distutils (and distutils2 later I guess) and is not hard to install on the top of Python. Is pip able to determine and install dependencies recursively, like easy_install does? Or is it up to the requested package to it specify its dependencies (and its dependencies dependencies) in a pip requirements file that is distributed separately? My experience is that only `install_requires` is needed (unless you want to create app bundles AFAICR) , but in practice I've noticed that *some* easy_installable packages are not pip-able (though I had no time to figure out why :-/ ) -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: On adding Hessian (RPC) support for Trac - http://feedproxy.google.com/~r/simelo-en/~3/Vit6dRudChU/on-adding-hessian-rpc-support-for-trac.html ___ 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] __pycache__ creation
Barry Warsaw wrote: On Mar 24, 2010, at 10:04 PM, Nick Coghlan wrote: Yep, that's my recollection as well. I don't recall seeing an update to state that clearly in the PEP go by on the checkins list though :) Check again wink. Ah yes, the recollection of seeing such a message is now quite fresh in my mind :) 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] At least one package management tool for 2.7
anatoly techtonik techtonik at gmail.com writes: 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\Python27python.exe -m easy_install C:\~env\Python27\python.exe: No module named easy_install C:\~env\Python27python.exe -m pip C:\~env\Python27\python.exe: No module named pip It will not happen in 2.7, which is almost in beta phase. Based on previous discussions, it will most likely not happen in 3.2 either. The consensus is that setuptools, which both pip and easy_install depend on, should not be included into the core. However, Tarek's work on distutils2 (a mostly forward-compatible replacement for distutils) will include features such as dependencies, and make it much easier to create and perhaps bundle a pip-like utility. So perhaps in 3.3 you have a chance ;) 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] __pycache__ creation
On Mar 24, 2010, at 11:06 PM, Nick Coghlan wrote: Ah yes, the recollection of seeing such a message is now quite fresh in my mind :) Just don't tell Guido I borrowed his time machine keys! -Barry signature.asc Description: PGP signature ___ 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] __pycache__ creation
Barry Warsaw writes: On Mar 24, 2010, at 11:06 PM, Nick Coghlan wrote: Ah yes, the recollection of seeing such a message is now quite fresh in my mind :) Just don't tell Guido I borrowed his time machine keys! Wouldn't that be preferable to revealing you've learned to hotwire it? ___ 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] argparse.py is licensed under the Apache License
On Wed, Mar 24, 2010 at 1:42 AM, Amaury Forgeot d'Arc amaur...@gmail.com wrote: 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: Sorry, I forgot to remove this when moving argparse to the stdlib. There's probably one test\test_argparse too. - 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? Yes, I have signed a contributor agreement. I was thinking of just removing the license entirely, but if it's better to replace it with Licensed to PSF under a Contributor Agreement, that's fine too. Let me know, and I'll take care of this today. Thanks for catching this! Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus ___ 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] Mixing float and Decimal -- thread reboot
On Wed, Mar 24, 2010 at 11:47 AM, Nick Coghlan Interning NaN certainly seems like it should be sufficient to eliminate the set/dict membership weirdness. That is, make it so that the first two lines of the following return True, while the latter two lines continue to return False: float(nan) is float(nan) False dec(nan) is dec(nan) False float(nan) == float(nan) False dec(nan) == dec(nan) False Yes; that could be done. Though as Steven points out, not all NaNs are equivalent (possibility of different payloads and different signs), so float nans with different underlying bit patterns, and Decimal nans with different string representations, would ideally be interned separately. For floats it might be possible to get away with pretending that there's only one nan. For decimal, I don't think that's true, since the payload and sign are part of the standard, and are very visible (e.g. in the repr of the nan). The obvious way to do this nan interning for floats would be to put the interning code into PyFloat_FromDouble. I'm not sure whether this would be worth the cost in terms of added code (and possibly reduced performance, since the nan check would be done every time a float was returned), but I'd be willing to review a patch. 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] __pycache__ creation
Nick Coghlan wrote: Ron Adam wrote: I think I misunderstood this at first. It looks like, while developing a python 3.2+ program, if you don't create an empty __pycache__ directory, everything will still work, you just won't get the .pyc files. That can be a good thing during development because you also will not have any problems with old .pyc files hanging around if you move or rename files. The behaviour you described (not creating __pycache__ automatically) was just a suggestion in this thread. The behaviour in the actual PEP (and what will be implemented for 3.2+) is to create __pycache__ if it is missing. Cheers, Nick. OK :-) h... unless there is a __pycache__ *file* located there first. ;-) Not that I can think of any good reason to do that at this moment. Ron ___ 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] GSoC 2010 is on -- projects?
On Fri, Mar 19, 2010 at 2:45 AM, Terry Reedy tjre...@udel.edu wrote: On 3/19/2010 2:23 AM, Laurent Gautier wrote: On 3/19/10 3:36 AM, C. Titus Brown wrote: Hi all, once again, the PSF has been accepted as a mentoring foundation for the Google Summer of Code! This year, we're going to emphasize python 3 porting, so please think of projects you'd like to see tackled. Hi, Does this mean that any other python project could potentially see itself ported to Python 3 in the course of this SoC ? The theme should include both general porting tools and specific projects, especially infrastructure projects like numeric, which are blocking the porting of other projects. It would be nice if those doing specific projects contributed their experience/knowledge to a central pool. If so, can any project owner submit a request for help, Any project owner is *always* free to ask for help (on python-list, but now here in this thread). Those who can also mentor might be more likely to get it. If I were a student, I would consider serious interest from a project owner (and a promise to distribute a port, when ready), a prerequisite. or is there going to be a list of projects that would nice to port, or will a voting system of some sort be put in place ? Like most contributors, students choose projects, within the limits of what they can get mentors for, that scratch their itches. They may or may not otherwise be swayed by requests and opinions. My views. Terry Jan Reedy Would anyone be interested in mentoring further lib3to2 work? I'm planning on applying again as a student. --Joe Amenta ___ 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] Mixing float and Decimal -- thread reboot
On Mar 24, 2010, at 9:22 AM, Mark Dickinson wrote: The obvious way to do this nan interning for floats would be to put the interning code into PyFloat_FromDouble. I'm not sure whether this would be worth the cost in terms of added code (and possibly reduced performance, since the nan check would be done every time a float was returned), but I'd be willing to review a patch. -1 Propagating support for NaNs has already consumed an enormous amount of your time. The code for the math module doubled in complexity as a result of adding Nan/Inf support. At each stage, some new weirdness emerges (such as complex(Nan, Nan), etc). And each change introduces the risk of new bugs in code that had been stable for a long time. IIRC, the original purpose of a NaN was to serve as a placeholder value in a long series of floating point ops so that the programmer would not have to introduce edge case tests at each stage of a calculation. Yet, I look at the code for the decimal module and the C code for the math module and see that the opposite result occurred, the code is littered with is_special(x) tests and handlers. In terms of practicality, NaNs work great as a way to mark missing values and to propagate through subsequent calculations. IMO, their least useful feature is the property of being not equal to themselves -- that causes more problems than it solves because it impairs a programmer's ability to reason about their programs. Raymond ___ 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] [Distutils] At least one package management tool for 2.7
On Wed, Mar 24, 2010 at 1:19 PM, Ian Bicking i...@colorstudy.com wrote: On Wed, Mar 24, 2010 at 7:27 AM, Olemis Lang ole...@gmail.com wrote: My experience is that only `install_requires` is needed (unless you want to create app bundles AFAICR) , but in practice I've noticed that *some* easy_installable packages are not pip-able (though I had no time to figure out why :-/ ) Usually this is because Setuptools is poking at objects to do its work, while pip tries to work mostly with subprocesses. Though to complicate things a bit, pip makes sure the Setuptools monkeypatches to distutils are applied, so that it's always as though the setup.py says from setuptools import setup. easy_install *also* does this. But then easy_install starts calling methods and whatnot, while pip just does: setup.py install --single-version-externally-managed --no-deps --record some_tmp_file The --no-deps keeps Setuptools from resolving dependencies Seeking clarification: how can pip recursively install dependencies *and* keep Setuptools from resolving dependencies? Darren ___ 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] Mixing float and Decimal -- thread reboot
On Wed, Mar 24, 2010 at 1:39 PM, Raymond Hettinger raymond.hettin...@gmail.com wrote: .. IMO, their least useful feature is the property of being not equal to themselves -- that causes more problems than it solves because it impairs a programmer's ability to reason about their programs. I agree. An often cited rationale for IEEE 754 behavior is that it eliminates branching in some high performance numerical algorithms. While this is likely to be true, I have never seen it benefiting real life applications, certainly not those written in Python. I wonder why Python did not follow Java model where Float NaN objects unlike raw float NaNs compare equal to themselves.One reason may be that Python does not have raw floats, but if someone needs IEEE 754 NaNs, one can use numpy scalars or add arithmetics to ctypes numerical types. Mark, I wonder if you could describe an algorithm off the top of your head that relies on NaN == NaN being false. ___ 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] [Distutils] At least one package management tool for 2.7
On Wed, Mar 24, 2010 at 12:53 PM, Darren Dale dsdal...@gmail.com wrote: On Wed, Mar 24, 2010 at 1:19 PM, Ian Bicking i...@colorstudy.com wrote: On Wed, Mar 24, 2010 at 7:27 AM, Olemis Lang ole...@gmail.com wrote: My experience is that only `install_requires` is needed (unless you want to create app bundles AFAICR) , but in practice I've noticed that *some* easy_installable packages are not pip-able (though I had no time to figure out why :-/ ) Usually this is because Setuptools is poking at objects to do its work, while pip tries to work mostly with subprocesses. Though to complicate things a bit, pip makes sure the Setuptools monkeypatches to distutils are applied, so that it's always as though the setup.py says from setuptools import setup. easy_install *also* does this. But then easy_install starts calling methods and whatnot, while pip just does: setup.py install --single-version-externally-managed --no-deps --record some_tmp_file The --no-deps keeps Setuptools from resolving dependencies Seeking clarification: how can pip recursively install dependencies *and* keep Setuptools from resolving dependencies? Using the --no-deps option to setup.py ___ 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] Mixing float and Decimal -- thread reboot
On Wed, Mar 24, 2010 at 11:26 AM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: I wonder why Python did not follow Java model where Float NaN objects unlike raw float NaNs compare equal to themselves. One reason may be that Python does not have raw floats, but if someone needs IEEE 754 NaNs, one can use numpy scalars or add arithmetics to ctypes numerical types. Probably because we were blindly following the IEEE standard without understanding it in every detail. -- --Guido van Rossum (python.org/~guido) ___ 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] Mixing float and Decimal -- thread reboot
On Wed, Mar 24, 2010 at 6:26 PM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: Mark, I wonder if you could describe an algorithm off the top of your head that relies on NaN == NaN being false. No, I certainly couldn't! And I often wonder if the original IEEE 754 committee, given 20/20 foresight, would have made the same decisions regarding comparisons of nans. It's certainly not one of my favourite features of IEEE 754. (Though sqrt(-0.) - -0. ranks lower for me. Grr.) A bogus application that I've often seen mentioned is that it allows checking whether a float 'x' is a nan by doing `x == x'; but the proper way to do this is to have an 'isnan' function or method, so this isn't particularly convincing. Slightly more convincing is history: this is the way that nan comparisons behave in other languages (Fortran, C) used for numerics. If Python were to do something different then a naively translated algorithm from another language would fail. It's the behaviour that numerically-aware people expect, and I'd expect to get complaints from those people if it changed. 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] Mixing float and Decimal -- thread reboot
On Wed, Mar 24, 2010 at 2:36 PM, Guido van Rossum gu...@python.org wrote: .. Probably because we were blindly following the IEEE standard without understanding it in every detail. Are you talking about accidental support for NaNs in older versions of Python or about recent efforts to support them properly in math and decimal modules? I feel you are too harsh on the developers that worked in this area. I dare to suggest that the current situation is not due to lack of understanding of the standard, but due to pragmatic decisions made in early development and desire for backward compatibility in the recent versions. Is this an area where design changes are feasible? IIRC, NaN support was never officially in the language, but it may have changed with the decimal module. ___ 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] Mixing float and Decimal -- thread reboot
On Wed, Mar 24, 2010 at 2:50 PM, Mark Dickinson dicki...@gmail.com wrote: .. If Python were to do something different then a naively translated algorithm from another language would fail. It's the behaviour that numerically-aware people expect, and I'd expect to get complaints from those people if it changed. Numerically-aware people are likely to be aware of the differences in languages that they use. I think in this day and age you are more likely to hear from confused Java programmers than from Fortran or even C folks. ___ 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] Why is nan != nan?
[Changing the subject line, since we're way off the original topic] On Wed, Mar 24, 2010 at 7:04 PM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: On Wed, Mar 24, 2010 at 2:50 PM, Mark Dickinson dicki...@gmail.com wrote: .. If Python were to do something different then a naively translated algorithm from another language would fail. It's the behaviour that numerically-aware people expect, and I'd expect to get complaints from those people if it changed. Numerically-aware people are likely to be aware of the differences in languages that they use. Sure. But I'd still expect them to complain. :) Here's an interesting recent blog post on this subject, from the creator of Eiffel: http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civilization/ 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] Mixing float and Decimal -- thread reboot
On Thu, 25 Mar 2010 03:22:29 am Mark Dickinson wrote: The obvious way to do this nan interning for floats would be to put the interning code into PyFloat_FromDouble. I'm not sure whether this would be worth the cost in terms of added code (and possibly reduced performance, since the nan check would be done every time a float was returned), but I'd be willing to review a patch. I hope that it's obvious from my previous post that I do NOT want such interning done, but since I put the idea in people's heads, I wish to reiterate that I'm against the idea: -1 on interning NaNs. For the rare application where it might be useful, it is easy to do in the application code. -- Steven D'Aprano ___ 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] Mixing float and Decimal -- thread reboot
Nick Coghlan ncogh...@gmail.com wrote: Raymond Hettinger wrote: The decimal module is already drowning in complexity, so it would be best to keep it simple: one boolean flag that if set would warn about any implicit decimal/float interaction. Agreed - those that want exceptions instead can use the usual warnings module mechanisms to trigger them. I'm not sure about the warnings module. If lower complexity is a goal, I would prefer Facundo's original proposal of just adding a single new signal. Users who just want to know if a NonIntegerConversion has occurred can check the flags, users who want an exception set the trap. With the warnings module, users have to know (and deal with) two exception handling/suppressing mechanisms. Stefan Krah ___ 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] Mixing float and Decimal -- thread reboot
On Wed, Mar 24, 2010 at 11:55 AM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: On Wed, Mar 24, 2010 at 2:36 PM, Guido van Rossum gu...@python.org wrote: .. Probably because we were blindly following the IEEE standard without understanding it in every detail. Are you talking about accidental support for NaNs in older versions of Python or about recent efforts to support them properly in math and decimal modules? My recollection include recent efforts, such as the math.isnan() function. I don't recall ever hearing an argument for the peculiar behavior of NaN in comparisons beyond this is what the IEEE standard prescribes. I feel you are too harsh on the developers that worked in this area. Maybe. I didn't mean to put down individuals complicit in the decision -- in fact I would say that I am to blame myself for not probing deeper. I dare to suggest that the current situation is not due to lack of understanding of the standard, but due to pragmatic decisions made in early development and desire for backward compatibility in the recent versions. I think that originally NaN (and Inf) behavior was so platform-dependent that it really wouldn't have mattered if we had changed it. Is this an area where design changes are feasible? IIRC, NaN support was never officially in the language, but it may have changed with the decimal module. It has been at least since 2.6 introduced math.isnan(), and ISTR there was a proposal to add a separate module to deal with NaN and Inf properly in a pure-python library module. -- --Guido van Rossum (python.org/~guido) ___ 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] Mixing float and Decimal -- thread reboot
On Wed, Mar 24, 2010 at 2:50 PM, Mark Dickinson dicki...@gmail.com wrote: On Wed, Mar 24, 2010 at 6:26 PM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: Mark, I wonder if you could describe an algorithm off the top of your head that relies on NaN == NaN being false. No, I certainly couldn't! And I often wonder if the original IEEE 754 committee, given 20/20 foresight, would have made the same decisions regarding comparisons of nans. It's certainly not one of my favourite features of IEEE 754. I tried to google the rationale for the IEEE 754 decision, but came up with nothing. Here are a few representative results: So without fear let me not stop at the arguments that “the committee must have voted on this point and they obviously knew what they were doing” and “it is the standard and implemented on zillions of machines, you cannot change it now”. - Reflexivity, and other pillars of civilization by Bertrand Meyer http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civilization/ I suppose this simplifies numerical computations in some way, but I couldn't find an explicitly stated reason, not even in the Lecture Notes on the Status of IEEE 754 by Kahan which discusses other design decisions in detail. - What is the rationale for all comparisons returning false for IEEE754 NaN values? http://stackoverflow.com/questions/1565164/what-is-the-rationale-for-all-comparisons-returning-false-for-ieee754-nan-values ___ 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] GSoC 2010 is on -- projects?
I'm sure we can find you a mentor. On Wed, Mar 24, 2010 at 1:16 PM, Joe Amenta ament...@msu.edu wrote: On Fri, Mar 19, 2010 at 2:45 AM, Terry Reedy tjre...@udel.edu wrote: On 3/19/2010 2:23 AM, Laurent Gautier wrote: On 3/19/10 3:36 AM, C. Titus Brown wrote: Hi all, once again, the PSF has been accepted as a mentoring foundation for the Google Summer of Code! This year, we're going to emphasize python 3 porting, so please think of projects you'd like to see tackled. Hi, Does this mean that any other python project could potentially see itself ported to Python 3 in the course of this SoC ? The theme should include both general porting tools and specific projects, especially infrastructure projects like numeric, which are blocking the porting of other projects. It would be nice if those doing specific projects contributed their experience/knowledge to a central pool. If so, can any project owner submit a request for help, Any project owner is *always* free to ask for help (on python-list, but now here in this thread). Those who can also mentor might be more likely to get it. If I were a student, I would consider serious interest from a project owner (and a promise to distribute a port, when ready), a prerequisite. or is there going to be a list of projects that would nice to port, or will a voting system of some sort be put in place ? Like most contributors, students choose projects, within the limits of what they can get mentors for, that scratch their itches. They may or may not otherwise be swayed by requests and opinions. My views. Terry Jan Reedy Would anyone be interested in mentoring further lib3to2 work? I'm planning on applying again as a student. --Joe Amenta ___ 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/arcriley%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] Mixing float and Decimal -- thread reboot
FWIW, my viewpoint on this is softening over time and I no longer feel a need to push for a new context flag. It is probably simplest for users if implicit coercions didn't come with control knobs. We already have Fraction+float--float occurring without any exceptions or warnings, and nothing bad has happened as a result. Also, I'm reminded of Tim Peter's admonition to resist extending the decimal spec. I used to worry that any decimal/float interactions were most likely errors and shouldn't pass silently. Now, I've just stopped worrying and I feel better already ;-) Adding a FAQ entry is simpler than building-out Context object circuitry and documenting it in an understandable way. Raymond On Mar 24, 2010, at 12:36 PM, Stefan Krah wrote: Nick Coghlan ncogh...@gmail.com wrote: Raymond Hettinger wrote: The decimal module is already drowning in complexity, so it would be best to keep it simple: one boolean flag that if set would warn about any implicit decimal/float interaction. Agreed - those that want exceptions instead can use the usual warnings module mechanisms to trigger them. I'm not sure about the warnings module. If lower complexity is a goal, I would prefer Facundo's original proposal of just adding a single new signal. Users who just want to know if a NonIntegerConversion has occurred can check the flags, users who want an exception set the trap. With the warnings module, users have to know (and deal with) two exception handling/suppressing mechanisms. Stefan Krah ___ 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 3147, __pycache__ directories and umask
Isaac Morland wrote: the benefit to me and to Greg and to others writing .py code is that our directories will contain *.py and __pycache__, rather than *.py and *.pyc. So it will be much easier to see what is actually there. Yes. When using MacOSX I do most of my work using the Finder's column view. With two windows open one above the other, there's room for about a dozen files to be seen at once. There's no way to filter the view or sort by anything other than name, so with the current .pyc scheme, half of that valuable screen space is wasted. -- Greg ___ 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] Mixing float and Decimal -- thread reboot
Slight change of topic. I've been implementing the extra comparisons required for the Decimal type and found an anomaly while testing. Currently in py3k, order comparisons (but not ==, !=) between a complex number and another complex, float or int raise TypeError: z = complex(0, 0) z int() Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: complex() int() z float() Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: complex() float() z complex() Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: complex() complex() But Fraction is the odd man out: a comparison between a Fraction and a complex raises a TypeError for complex numbers with nonzero imaginary component, but returns a boolean value if the complex number has zero imaginary component: z Fraction() False complex(0, 1) Fraction() Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: complex() Fraction() I'm tempted to call this Fraction behaviour a bug, but maybe it arises from the numeric integration themes of PEP 3141. Any ideas? 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] Mixing float and Decimal -- thread reboot
W00t! On Wed, Mar 24, 2010 at 1:56 PM, Raymond Hettinger raymond.hettin...@gmail.com wrote: FWIW, my viewpoint on this is softening over time and I no longer feel a need to push for a new context flag. It is probably simplest for users if implicit coercions didn't come with control knobs. We already have Fraction+float--float occurring without any exceptions or warnings, and nothing bad has happened as a result. Also, I'm reminded of Tim Peter's admonition to resist extending the decimal spec. I used to worry that any decimal/float interactions were most likely errors and shouldn't pass silently. Now, I've just stopped worrying and I feel better already ;-) Adding a FAQ entry is simpler than building-out Context object circuitry and documenting it in an understandable way. Raymond On Mar 24, 2010, at 12:36 PM, Stefan Krah wrote: Nick Coghlan ncogh...@gmail.com wrote: Raymond Hettinger wrote: The decimal module is already drowning in complexity, so it would be best to keep it simple: one boolean flag that if set would warn about any implicit decimal/float interaction. Agreed - those that want exceptions instead can use the usual warnings module mechanisms to trigger them. I'm not sure about the warnings module. If lower complexity is a goal, I would prefer Facundo's original proposal of just adding a single new signal. Users who just want to know if a NonIntegerConversion has occurred can check the flags, users who want an exception set the trap. With the warnings module, users have to know (and deal with) two exception handling/suppressing mechanisms. Stefan Krah ___ 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/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ 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] Mixing float and Decimal -- thread reboot
On Wed, Mar 24, 2010 at 8:56 PM, Raymond Hettinger raymond.hettin...@gmail.com wrote: FWIW, my viewpoint on this is softening over time and I no longer feel a need to push for a new context flag. It is probably simplest for users if implicit coercions didn't come with control knobs. We already have Fraction+float--float occurring without any exceptions or warnings, and nothing bad has happened as a result. I agree with this; I'd be happy to avoid the control knobs. 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] Mixing float and Decimal -- thread reboot
On Mar 24, 2010, at 2:09 PM, Mark Dickinson wrote: Slight change of topic. I've been implementing the extra comparisons required for the Decimal type and found an anomaly while testing. Currently in py3k, order comparisons (but not ==, !=) between a complex number and another complex, float or int raise TypeError: z = complex(0, 0) z int() Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: complex() int() z float() Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: complex() float() z complex() Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: complex() complex() But Fraction is the odd man out: a comparison between a Fraction and a complex raises a TypeError for complex numbers with nonzero imaginary component, but returns a boolean value if the complex number has zero imaginary component: z Fraction() False complex(0, 1) Fraction() Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: complex() Fraction() I'm tempted to call this Fraction behaviour a bug, but maybe it arises from the numeric integration themes of PEP 3141. Any ideas? Conceptually, it's a bug. The numeric tower treats non-complex numbers as special cases of complex where the imaginary component is zero (that's why the non-complex types all support real/imag), and since complex numbers are not allowed to compare to themselves, they shouldn't compare to anything else either. To confirm, we should ask Jeffrey Y to opine. Raymond ___ 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] Why is nan != nan?
On Wed, Mar 24, 2010 at 3:26 PM, Mark Dickinson dicki...@gmail.com wrote:
..
Here's an interesting recent blog post on this subject, from the
creator of Eiffel:
http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civilization/
It appears that Meyer's view has evolved over the years:
In this context it doesn't particularly shock me that operations on
NaN should cause invariant violations. After all, isn't NaN supposed
to mean not a number? If it's not a number, it doesn't have to
satisfy the properties of numbers.
NaN and floating point exceptions by Roger Browne quoting an ISE
Eiffel mailing list post by Bertrand Meyer
http://teameiffel.blogspot.com/2006/04/nan-and-floating-point-exceptions.html
Compare this with the conclusion he reached in Pillars:
It is rather dangerous indeed to depart from the fundamental laws of
mathematics.
To bring the discussion back on topic for python-dev, I would argue
that reflexivity should hold for hashable values. Having it otherwise
would lead to unsurmountable problems when storing such values in sets
or using them as keys in dictionaries. If x == x is False stays for x
= float('nan'), I would argue that hash(float('nan')) should raise
NotImplemented or ValueError.
___
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] argparse.py is licensed under the Apache License
Yes, I have signed a contributor agreement. I was thinking of just removing the license entirely, but if it's better to replace it with Licensed to PSF under a Contributor Agreement, that's fine too. Let me know, and I'll take care of this today. Technically, your *contribution* should have included that line, whereas the code that we (i.e. the PSF) immediately relicense won't. IIUC, and IANAL, the line indicates that you do intend your contribution to be covered by your agreement (just so you couldn't claim we stole it from your laptop, and you didn't really mean to contribute it). Of course, committing it to subversion is an even stronger indication that you wanted to contribute it :-) The PSF then immediately exercises its right to relicense the code, currently under the PSF license. 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] Why is nan != nan?
On Mar 24, 2010, at 2:31 PM, Alexander Belopolsky wrote:
In this context it doesn't particularly shock me that operations on
NaN should cause invariant violations. After all, isn't NaN supposed
to mean not a number? If it's not a number, it doesn't have to
satisfy the properties of numbers.
This sound like a good, universal reply to bug reports about
various containers/tools not working with NaNs :-)
Bug report: Container X or Function Y doesn't behave well when I
give it a NaN as an input.
Closed -- Won't fix: It does not shock me that a NaN violates that
tool or container's invariants.
To bring the discussion back on topic for python-dev, I would argue
that reflexivity should hold for hashable values. Having it otherwise
would lead to unsurmountable problems when storing such values in sets
or using them as keys in dictionaries. If x == x is False stays for x
= float('nan'), I would argue that hash(float('nan')) should raise
NotImplemented or ValueError.
Hashability isn't the only place where you have a problem.
Even unordered collections are affected:
class ListBasedSet(collections.Set):
''' Alternate set implementation favoring space over speed
and not requiring the set elements to be hashable. '''
def __init__(self, iterable):
self.elements = lst = []
for value in iterable:
if value not in lst:
lst.append(value)
def __iter__(self):
return iter(self.elements)
def __contains__(self, value):
return any(value == elem for elem in self.elements)
def __len__(self):
return len(self.elements)
n = float('Nan')
s = ListBasedSet([n])
n in s # unexpected result
False
len(s)# expected result
1
len(s s) # unexpected result
0
If we want to be able to reason about our programs,
then we need to rely on equality relations being
reflexsive, symmetric, and transitive. Otherwise,
containers and functions can't even make minimal
guarantees about what they do.
Anything else smells of a Douglas Hofstadter style
or Betrand Russell style logic bomb:
* this sentence is a lie
* this object isn't equal to itself
* this is a set containing sets that are not members of themselves
The property of NaN objects not being equal to themselves
is more harmful than helpful. We should probably draw the
line at well-defined numeric contexts such as the decimal module
and stop trying to propagate NaN awareness throughout the
entire object model.
Raymond
___
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] Mixing float and Decimal -- thread reboot
On Wed, Mar 24, 2010 at 2:29 PM, Raymond Hettinger raymond.hettin...@gmail.com wrote: On Mar 24, 2010, at 2:09 PM, Mark Dickinson wrote: Slight change of topic. I've been implementing the extra comparisons required for the Decimal type and found an anomaly while testing. Currently in py3k, order comparisons (but not ==, !=) between a complex number and another complex, float or int raise TypeError: z = complex(0, 0) z int() Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: complex() int() z float() Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: complex() float() z complex() Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: complex() complex() But Fraction is the odd man out: a comparison between a Fraction and a complex raises a TypeError for complex numbers with nonzero imaginary component, but returns a boolean value if the complex number has zero imaginary component: z Fraction() False complex(0, 1) Fraction() Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: complex() Fraction() I'm tempted to call this Fraction behaviour a bug, but maybe it arises from the numeric integration themes of PEP 3141. Any ideas? Conceptually, it's a bug. The numeric tower treats non-complex numbers as special cases of complex where the imaginary component is zero (that's why the non-complex types all support real/imag), and since complex numbers are not allowed to compare to themselves, they shouldn't compare to anything else either. That's how I read the PEP too. PEP 3141 doesn't define any ordering operations on Complex, they only show up on Real. To confirm, we should ask Jeffrey Y to opine. CC'ed him. After all looks like it was he who added it to Fraction. :-) -- --Guido van Rossum (python.org/~guido) ___ 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] Why is nan != nan?
Even unordered collections are affected: s/unordered/unhashed, equality-based/ Raymond ___ 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] Why is nan != nan?
On Wed, Mar 24, 2010 at 6:21 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
..
If we want to be able to reason about our programs,
then we need to rely on equality relations being
reflexsive, symmetric, and transitive. Otherwise,
containers and functions can't even make minimal
guarantees about what they do.
+1
.. We should probably draw the
line at well-defined numeric contexts such as the decimal module
and stop trying to propagate NaN awareness throughout the
entire object model.
I am not sure what this means in practical terms. Should
float('nan') == float('nan') return True or should float('nan') raise
an exception to begin with? I would prefer the former.
___
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] Why is nan != nan?
On Wed, Mar 24, 2010 at 10:30 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Wed, Mar 24, 2010 at 6:21 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
..
If we want to be able to reason about our programs,
then we need to rely on equality relations being
reflexsive, symmetric, and transitive. Otherwise,
containers and functions can't even make minimal
guarantees about what they do.
+1
.. We should probably draw the
line at well-defined numeric contexts such as the decimal module
and stop trying to propagate NaN awareness throughout the
entire object model.
I am not sure what this means in practical terms. Should
float('nan') == float('nan') return True or should float('nan') raise
an exception to begin with? I would prefer the former.
Neither is necessary, because Python doesn't actually use == as the
equivalence relation for containment testing: the actual equivalence
relation is: x equivalent to y iff id(x) == id(y) or x == y. This
restores the missing reflexivity (besides being a useful
optimization).
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] Why is nan != nan?
On Wed, Mar 24, 2010 at 6:31 PM, Mark Dickinson dicki...@gmail.com wrote:
..
Neither is necessary, because Python doesn't actually use == as the
equivalence relation for containment testing: the actual equivalence
relation is: x equivalent to y iff id(x) == id(y) or x == y. This
restores the missing reflexivity (besides being a useful
optimization).
No, it does not:
float('nan') in [float('nan')]
False
It would if NaNs were always interned, but they are not.
___
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] Why is nan != nan?
Not to mention the following aberrations:
{x for x in [float('nan')] * 10}
{nan}
{float(x) for x in ['nan'] * 10}
{nan, nan, nan, nan, nan, nan, nan, nan, nan, nan}
{float('nan')} | {float('nan')}
{nan, nan}
{float('nan')} {float('nan')}
set()
On Wed, Mar 24, 2010 at 6:36 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Wed, Mar 24, 2010 at 6:31 PM, Mark Dickinson dicki...@gmail.com wrote:
..
Neither is necessary, because Python doesn't actually use == as the
equivalence relation for containment testing: the actual equivalence
relation is: x equivalent to y iff id(x) == id(y) or x == y. This
restores the missing reflexivity (besides being a useful
optimization).
No, it does not:
float('nan') in [float('nan')]
False
It would if NaNs were always interned, but they are not.
___
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] Why is nan != nan?
On Wed, Mar 24, 2010 at 10:36 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Wed, Mar 24, 2010 at 6:31 PM, Mark Dickinson dicki...@gmail.com wrote:
..
Neither is necessary, because Python doesn't actually use == as the
equivalence relation for containment testing: the actual equivalence
relation is: x equivalent to y iff id(x) == id(y) or x == y. This
restores the missing reflexivity (besides being a useful
optimization).
No, it does not:
float('nan') in [float('nan')]
False
Sure, but just think of it as having two different nans there. (You
could imagine thinking of the id of the nan as part of the payload.)
There's no ideal solution here; IMO, the compromise that currently
exists is an acceptable one.
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] Why is nan != nan?
On Wed, Mar 24, 2010 at 6:47 PM, Mark Dickinson dicki...@gmail.com wrote: .. There's no ideal solution here; IMO, the compromise that currently exists is an acceptable one. I don't see a compromise. So far I failed to find a use case that benefits from NaN violating reflexivity. ___ 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] Why is nan != nan?
On Wed, Mar 24, 2010 at 10:52 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Wed, Mar 24, 2010 at 6:47 PM, Mark Dickinson dicki...@gmail.com wrote:
..
There's no ideal solution here; IMO, the compromise that currently
exists is an acceptable one.
I don't see a compromise. So far I failed to find a use case that
benefits from NaN violating reflexivity.
So if I understand correctly, you propose that float('nan') ==
float('nan') return True. Would you also suggest extending this
behaviour to Decimal nans?
___
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] Why is nan != nan?
On Wed, Mar 24, 2010 at 7:02 PM, Mark Dickinson dicki...@gmail.com wrote:
..
So if I understand correctly, you propose that float('nan') ==
float('nan') return True. Would you also suggest extending this
behaviour to Decimal nans?
yes
___
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] Why is nan != nan?
On Wed, Mar 24, 2010 at 11:11 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Wed, Mar 24, 2010 at 7:02 PM, Mark Dickinson dicki...@gmail.com wrote:
..
So if I understand correctly, you propose that float('nan') ==
float('nan') return True. Would you also suggest extending this
behaviour to Decimal nans?
yes
Okay. So now it seems to me that there are many decisions to make:
should any Decimal nan compare equal to any other? What if the two
nans have different payloads or signs? How about comparing a
signaling nan with either an arbitrary quiet nan, or with the exact
quiet nan that corresponds to the signaling nan? How do decimal nans
compare with float nans? Should Decimal.compare(Decimal('nan'),
Decimal('nan')) return 0 rather than nan? If not, how do you justify
the difference between == and compare? If so, how do you justify the
deviation from the standard on which the decimal modulo is based?
In answering all these questions, you effectively end up developing
your own standard, and hoping that all the answers you chose are
sensible, consistent, and useful.
Alternatively, we could do what we're currently doing: make use of
*existing* standards to answer these questions, and rely on the
expertise of the many who've thought about this in depth.
You say that you don't see any compromise: I say that there's value
in adhering to (de facto and de jure) standards, and I see a
compromise between standards adherence and Python pragmatics.
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] Mixing float and Decimal -- thread reboot
Raymond Hettinger wrote: Conceptually, it's a bug. The numeric tower treats non-complex numbers as special cases of complex where the imaginary component is zero (that's why the non-complex types all support real/imag), and since complex numbers are not allowed to compare to themselves, they shouldn't compare to anything else either. There's a contradiction in there somewhere. If you believe that a non-complex is equivalent to a complex with zero imaginary part, then you *should* be able to compare two complexes provided that their imaginary parts are both zero. (I don't think that should be the case, BTW -- complex numbers live on a two-dimensional plane, and from a geometrical point of view there's no reason to single out the x-axis and give it special treatment.) -- Greg ___ 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] Mixing float and Decimal -- thread reboot
On Wed, Mar 24, 2010 at 2:09 PM, Mark Dickinson dicki...@gmail.com wrote: Slight change of topic. I've been implementing the extra comparisons required for the Decimal type and found an anomaly while testing. Currently in py3k, order comparisons (but not ==, !=) between a complex number and another complex, float or int raise TypeError: z = complex(0, 0) z int() Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: complex() int() z float() Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: complex() float() z complex() Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: complex() complex() But Fraction is the odd man out: a comparison between a Fraction and a complex raises a TypeError for complex numbers with nonzero imaginary component, but returns a boolean value if the complex number has zero imaginary component: z Fraction() False complex(0, 1) Fraction() Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: complex() Fraction() I'm tempted to call this Fraction behaviour a bug, but maybe it arises from the numeric integration themes of PEP 3141. Any ideas? I'd call it a bug. ___ 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
