[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 . # # 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 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\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. ___ 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 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\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. 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 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
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 > 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
On Wed, Mar 24, 2010 at 12:26 PM, Tarek Ziadé 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 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. > 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 -- 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
> 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 wrote: > On Wed, Mar 24, 2010 at 12:26 PM, Tarek Ziadé 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é 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 wrote: > On Wed, Mar 24, 2010 at 6:26 AM, Tarek Ziadé 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 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 wrote: > On Wed, Mar 24, 2010 at 6:26 AM, Tarek Ziadé 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
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 . -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 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 . 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 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\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 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 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 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] argparse.py is licensed under the Apache License
On Wed, Mar 24, 2010 at 09:05, Steven Bethard wrote: > On Wed, Mar 24, 2010 at 1:42 AM, Amaury Forgeot d'Arc > 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. > > I say just strip it out. If you leave it the PSF board will get an email from some large corporation at some point in the future about whether you have actually signed an agreement or not. Much easier to simply remove it so people can rightfully assume it is licensed under the PSF license. ___ 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:27 AM, Olemis Lang 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 (because it does so using easy_install), and --single-version-externally-managed keeps Setuptools doing egg directories. And --record keeps track of installed files, which are later moved around to facilitate uninstall. But some distributions pay extra attention to those options, or do other tricky things in their setup.py, and as a result this causes failures. Because easy_install is just calling internal methods, it kind of sidelines those tricks (also people don't tend to give these options to easy_install, and some don't even exist, so some code paths just aren't exercised with typical easy_install usage). Oh, the other reason is the link searching mechanism is slightly different between the two installers. Not particularly intentionally, just incidentally. Also because pip doesn't install anything but source packages, some packages are installable via easy_install but not pip -- usually this is an oversight on the part of the person doing the packaging, but they just never noticed. -- Ian Bicking | http://blog.ianbicking.org | http://twitter.com/ianbicking ___ 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 wrote: > On Wed, Mar 24, 2010 at 7:27 AM, Olemis Lang 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 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 wrote: > On Wed, Mar 24, 2010 at 1:19 PM, Ian Bicking wrote: > > On Wed, Mar 24, 2010 at 7:27 AM, Olemis Lang 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 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 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 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 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 wrote: > On Wed, Mar 24, 2010 at 2:50 PM, Mark Dickinson 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 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 wrote: > On Wed, Mar 24, 2010 at 2:36 PM, Guido van Rossum 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 wrote: > On Wed, Mar 24, 2010 at 6:26 PM, Alexander Belopolsky > 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 wrote: > On Fri, Mar 19, 2010 at 2:45 AM, Terry Reedy 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
On Mar 24, 2010, at 12:51 PM, Alexander Belopolsky wrote: > > - "Reflexivity, and other pillars of civilization" by Bertrand Meyer > http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civilization/ Excellent link. Thanks for the research. 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
Thanks. Same link reported concurrently by Mark in the "Why is nan != nan?" thread. On Wed, Mar 24, 2010 at 4:26 PM, Raymond Hettinger wrote: > > On Mar 24, 2010, at 12:51 PM, Alexander Belopolsky wrote: > > - "Reflexivity, and other pillars of civilization" by Bertrand Meyer > http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civilization/ > > Excellent link. > Thanks for the research. > > 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
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 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 "", line 1, in TypeError: unorderable types: complex() < int() >>> z < float() Traceback (most recent call last): File "", line 1, in TypeError: unorderable types: complex() < float() >>> z < complex() Traceback (most recent call last): File "", line 1, in 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 "", line 1, in 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 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 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 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 "", line 1, in > TypeError: unorderable types: complex() < int() z < float() > Traceback (most recent call last): > File "", line 1, in > TypeError: unorderable types: complex() < float() z < complex() > Traceback (most recent call last): > File "", line 1, in > 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 "", line 1, in > 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 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] Mixing float and Decimal -- thread reboot
On 3/24/2010 1:56 PM, Raymond Hettinger wrote: FWIW, my viewpoint on this is softening over time and I no longer feel a need to push for a new context flag. To make Decimal useful for people that want to control its numerical quality, there must be a way to exclude accidental operations, and preferably an option for producing exceptions. Otherwise the status quo in 3.x is preferable to adding it to the numeric tree. I agree that not worrying can make you feel better, though. :) 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. You are looking at the wrong code. The point is that the code _using_ the math module and decimal module doesn't have to be littered with edge case tests; not that the implementation, which the good folks at IEEE figured would be in custom silicon that could do the edge case checking in parallel with other operations and with no net slowdown, would not have to be littered with edge cases. Glenn ___ 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 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 "", line 1, in >> TypeError: unorderable types: complex() < int() > z < float() >> Traceback (most recent call last): >> File "", line 1, in >> TypeError: unorderable types: complex() < float() > z < complex() >> Traceback (most recent call last): >> File "", line 1, in >> 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 "", line 1, in >> 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
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
wrote:
> On Wed, Mar 24, 2010 at 6:21 PM, Raymond Hettinger
> 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 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
wrote:
> On Wed, Mar 24, 2010 at 6:31 PM, Mark Dickinson 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
wrote:
> On Wed, Mar 24, 2010 at 6:31 PM, Mark Dickinson 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 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
wrote:
> On Wed, Mar 24, 2010 at 6:47 PM, Mark Dickinson 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 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] argparse.py is licensed under the Apache License
On Wed, Mar 24, 2010 at 10:08 AM, Brett Cannon wrote: > On Wed, Mar 24, 2010 at 09:05, Steven Bethard > wrote: >> On Wed, Mar 24, 2010 at 1:42 AM, Amaury Forgeot d'Arc >> 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. > > I say just strip it out. Benjamin beat me to the punch for argparse.py, but I also fixed this in test_argparse.py. 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
[Python-Dev] Issue 6081: format string using mapping rather than kwargs
Hello everyone,
I was told to bring this issue to python-dev, but I was reluctant to
do this until I was confident I can solve the problem. I have managed
to provide the patch that works, so now I can talk about how this
should be done, just as Eric told me. Here is the link to the ticket:
http://bugs.python.org/issue6081.
In the issue Raymond Hettinger proposed adding method to string, that
would allow to explicitly pass subscriptable object, from which
formatting of a string would be done. Two questions arise:
1) whether add such functionality at all?
2) how the method should be called? Should formatting options based on
*args be kept (like using {0} in formatted string) or not and how
argument should be passed. Eric suggested passing only mapping and
only adding *args, if that is found useful by users; I have though
about having both mapping and *args, which would keep it similar to
the old formatting. Another option is to have *args and one keyword
with the mapping (instead of kwargs).
I would appreciate any advice on this topic, even if this ticket would
be dismissed altogether, as I would like to learn as much as possible
on practices on developing Python.
--
Filip Gruszczyński
___
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
wrote:
> On Wed, Mar 24, 2010 at 7:02 PM, Mark Dickinson 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 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 "", line 1, in > TypeError: unorderable types: complex() < int() z < float() > Traceback (most recent call last): > File "", line 1, in > TypeError: unorderable types: complex() < float() z < complex() > Traceback (most recent call last): > File "", line 1, in > 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 "", line 1, in > 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
Re: [Python-Dev] Request for commit access
Am 23.03.2010 23:01, schrieb Antoine Pitrou: > Martin v. Löwis v.loewis.de> writes: >> >> Procedurally, I wonder where people got the notion from that you can or >> need to apply for commit access. IIUC, it used to be the case that you >> would be recommended for commit access, by some (more or less senior) >> fellow committer. That person then would work on actually getting commit >> access to the new committer - perhaps by first asking other people in >> private, to avoid any public embarrassment if access is ultimately >> denied. IMO, that committer should then also mentor the new guy, both by >> helping out in difficult cases, and by closely following commits to see >> whether (possibly unstated) conventions are being followed. >> >> I'm not really picking on Brian here specifically, I just want to point >> out that I dislike this (apparent) change in process, primarily because >> of the risk of embarrassment. > > For the record, I'm not opposing any point you are making, but all this is not > clearly written out, and I think that's why people (including me) lately have > been thinking that the candidate for commit rights had to declare himself on > this mailing-list. I don't think it is "wrong" to do it this way -- but of course the hopeful new committer needs to be prepared for a "no". I still would like every new committer to have a "mentor" from the pool of more experienced committers; however for people who are very active on IRC like Brian, there's usually one of the around to review a patch before it is committed. Georg ___ 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
