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
On Wed, Mar 24, 2010 at 5:36 AM, Stephen J. Turnbull step...@xemacs.org wrote:
Steven D'Aprano writes:
As usual though, NANs are unintuitive:
d = {float('nan'): 1}
d[float('nan')] = 2
d
{nan: 1, nan: 2}
I suspect that's a feature, not a bug.
Right: distinct nans
I wonder if there are many people here who don't use some kind of
easy_install package for package management in their Python /
virtualenv installations? I propose to include at least one such
package that is capable to auto-update itself in Python 2.7
C:\~env\Python27python.exe -m easy_install
On Wed, Mar 24, 2010 at 10:59 AM, anatoly techtonik techto...@gmail.com wrote:
I wonder if there are many people here who don't use some kind of
easy_install package for package management in their Python /
virtualenv installations? I propose to include at least one such
package that is
On Fri, Mar 19, 2010 at 11:00 AM, Dirkjan Ochtman dirk...@ochtman.nl wrote:
Having gotten that far, I think this might be worth referencing in new dev
docs.
Will do. I finally read hginit yesterday, after having seen people
rave about it on twitter for a few weeks, and it's a very friendly
On Wed, 24 Mar 2010 08:51:36 pm Mark Dickinson wrote:
On Wed, Mar 24, 2010 at 5:36 AM, Stephen J. Turnbull
step...@xemacs.org wrote:
Steven D'Aprano writes:
As usual though, NANs are unintuitive:
d = {float('nan'): 1}
d[float('nan')] = 2
d
{nan: 1, nan: 2}
Mark Dickinson writes:
On Wed, Mar 24, 2010 at 5:36 AM, Stephen J. Turnbull step...@xemacs.org
wrote:
Steven D'Aprano writes:
I suspect that's a feature, not a bug.
Right: distinct nans (i.e., those with different id()) are treated as
distinct set elements or dict keys.
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.
On Wed, Mar 24, 2010 at 12:20 PM, anatoly techtonik techto...@gmail.com wrote:
On Wed, Mar 24, 2010 at 12:26 PM, Tarek Ziadé ziade.ta...@gmail.com wrote:
Distutils2 is planned to be reintegrated in the stdlib in Python 3.3,
and my goal is to release it when Python 2.7 final is released.
Does
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
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
On Wed, Mar 24, 2010 at 6:26 AM, Tarek Ziadé ziade.ta...@gmail.com wrote:
The open question is: do we want to include a full installer that
takes care of installing / removing dependencies as well ?
I think not. Pip already provides this feature on the top of distutils
(and distutils2 later I
On Wed, Mar 24, 2010 at 12:50 PM, Darren Dale dsdal...@gmail.com wrote:
On Wed, Mar 24, 2010 at 6:26 AM, Tarek Ziadé ziade.ta...@gmail.com wrote:
The open question is: do we want to include a full installer that
takes care of installing / removing dependencies as well ?
I think not. Pip
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
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
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
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
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
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
On Wed, Mar 24, 2010 at 7:23 AM, anatoly techtonik techto...@gmail.com wrote:
Sure. Package management tool should have an ability to update itself when
required regardless of Python release. For example::
python.exe -m easy_install setuptools
This should be:
python -m easy_install -U
On Wed, Mar 24, 2010 at 7:50 AM, Darren Dale dsdal...@gmail.com wrote:
On Wed, Mar 24, 2010 at 6:26 AM, Tarek Ziadé ziade.ta...@gmail.com wrote:
The open question is: do we want to include a full installer that
takes care of installing / removing dependencies as well ?
I think not. Pip
Barry Warsaw wrote:
On Mar 24, 2010, at 10:04 PM, Nick Coghlan wrote:
Yep, that's my recollection as well. I don't recall seeing an update to
state that clearly in the PEP go by on the checkins list though :)
Check again wink.
Ah yes, the recollection of seeing such a message is now quite
anatoly techtonik techtonik at gmail.com writes:
I wonder if there are many people here who don't use some kind of
easy_install package for package management in their Python /
virtualenv installations? I propose to include at least one such
package that is capable to auto-update itself in
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
___
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?
On Wed, Mar 24, 2010 at 1:42 AM, Amaury Forgeot d'Arc
amaur...@gmail.com wrote:
I noticed that the newly added argparse module has an unusual
licence header, included below. This is the only file in the Python tree
that contains an explicit reference to the Apache License,
and this leads me to
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:
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
On Fri, Mar 19, 2010 at 2:45 AM, Terry Reedy tjre...@udel.edu wrote:
On 3/19/2010 2:23 AM, Laurent Gautier wrote:
On 3/19/10 3:36 AM, C. Titus Brown wrote:
Hi all,
once again, the PSF has been accepted as a mentoring foundation for
the Google
Summer of Code! This year, we're going to
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
On Wed, Mar 24, 2010 at 1:19 PM, Ian Bicking i...@colorstudy.com wrote:
On Wed, Mar 24, 2010 at 7:27 AM, Olemis Lang ole...@gmail.com wrote:
My experience is that only `install_requires` is needed (unless you
want to create app bundles AFAICR) , but in practice I've noticed that
*some*
On Wed, Mar 24, 2010 at 1:39 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
..
IMO, their least useful feature is the property of being not equal
to themselves -- that causes more problems than it solves
because it impairs a programmer's ability to reason about
their programs.
I
On Wed, Mar 24, 2010 at 12:53 PM, Darren Dale dsdal...@gmail.com wrote:
On Wed, Mar 24, 2010 at 1:19 PM, Ian Bicking i...@colorstudy.com wrote:
On Wed, Mar 24, 2010 at 7:27 AM, Olemis Lang ole...@gmail.com wrote:
My experience is that only `install_requires` is needed (unless you
want to
On Wed, Mar 24, 2010 at 11:26 AM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
I wonder why Python did not follow Java model where Float NaN objects
unlike raw float NaNs compare equal to themselves. One reason may
be that Python does not have raw floats, but if someone needs
On Wed, Mar 24, 2010 at 6:26 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
Mark, I wonder if you could describe an algorithm off the top of your
head that relies on NaN == NaN being false.
No, I certainly couldn't! And I often wonder if the original IEEE 754
committee, given
On Wed, Mar 24, 2010 at 2:36 PM, Guido van Rossum gu...@python.org wrote:
..
Probably because we were blindly following the IEEE standard without
understanding it in every detail.
Are you talking about accidental support for NaNs in older versions
of Python or about recent efforts to support
On Wed, Mar 24, 2010 at 2:50 PM, Mark Dickinson dicki...@gmail.com wrote:
..
If Python were to do something different then a naively translated
algorithm from another language would fail. It's the behaviour that
numerically-aware people expect, and I'd expect to get complaints from
those
[Changing the subject line, since we're way off the original topic]
On Wed, Mar 24, 2010 at 7:04 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Wed, Mar 24, 2010 at 2:50 PM, Mark Dickinson dicki...@gmail.com wrote:
..
If Python were to do something different then a naively
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
Nick Coghlan ncogh...@gmail.com wrote:
Raymond Hettinger wrote:
The decimal module is already drowning in complexity,
so it would be best to keep it simple: one boolean flag
that if set would warn about any implicit decimal/float
interaction.
Agreed - those that want exceptions
On Wed, Mar 24, 2010 at 11:55 AM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Wed, Mar 24, 2010 at 2:36 PM, Guido van Rossum gu...@python.org wrote:
..
Probably because we were blindly following the IEEE standard without
understanding it in every detail.
Are you talking
On Wed, Mar 24, 2010 at 2:50 PM, Mark Dickinson dicki...@gmail.com wrote:
On Wed, Mar 24, 2010 at 6:26 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
Mark, I wonder if you could describe an algorithm off the top of your
head that relies on NaN == NaN being false.
No, I
I'm sure we can find you a mentor.
On Wed, Mar 24, 2010 at 1:16 PM, Joe Amenta ament...@msu.edu wrote:
On Fri, Mar 19, 2010 at 2:45 AM, Terry Reedy tjre...@udel.edu wrote:
On 3/19/2010 2:23 AM, Laurent Gautier wrote:
On 3/19/10 3:36 AM, C. Titus Brown wrote:
Hi all,
once again, the PSF
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
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
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()
W00t!
On Wed, Mar 24, 2010 at 1:56 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
FWIW, my viewpoint on this is softening over time
and I no longer feel a need to push for a new context flag.
It is probably simplest for users if implicit coercions didn't come
with control knobs.
On Wed, Mar 24, 2010 at 8:56 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
FWIW, my viewpoint on this is softening over time
and I no longer feel a need to push for a new context flag.
It is probably simplest for users if implicit coercions didn't come
with control knobs. We
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
On Wed, Mar 24, 2010 at 3:26 PM, Mark Dickinson dicki...@gmail.com wrote:
..
Here's an interesting recent blog post on this subject, from the
creator of Eiffel:
http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civilization/
It appears that Meyer's view has evolved over the
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
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
On Wed, Mar 24, 2010 at 2:29 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
On Mar 24, 2010, at 2:09 PM, Mark Dickinson wrote:
Slight change of topic. I've been implementing the extra comparisons
required for the Decimal type and found an anomaly while testing.
Currently in py3k,
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:
On Wed, Mar 24, 2010 at 6:21 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
..
If we want to be able to reason about our programs,
then we need to rely on equality relations being
reflexsive, symmetric, and transitive. Otherwise,
containers and functions can't even make minimal
On Wed, Mar 24, 2010 at 10:30 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Wed, Mar 24, 2010 at 6:21 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
..
If we want to be able to reason about our programs,
then we need to rely on equality relations being
On Wed, Mar 24, 2010 at 6:31 PM, Mark Dickinson dicki...@gmail.com wrote:
..
Neither is necessary, because Python doesn't actually use == as the
equivalence relation for containment testing: the actual equivalence
relation is: x equivalent to y iff id(x) == id(y) or x == y. This
restores
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
On Wed, Mar 24, 2010 at 10:36 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Wed, Mar 24, 2010 at 6:31 PM, Mark Dickinson dicki...@gmail.com wrote:
..
Neither is necessary, because Python doesn't actually use == as the
equivalence relation for containment testing: the
On Wed, Mar 24, 2010 at 6:47 PM, Mark Dickinson dicki...@gmail.com wrote:
..
There's no ideal solution here; IMO, the compromise that currently
exists is an acceptable one.
I don't see a compromise. So far I failed to find a use case that
benefits from NaN violating reflexivity.
On Wed, Mar 24, 2010 at 10:52 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Wed, Mar 24, 2010 at 6:47 PM, Mark Dickinson dicki...@gmail.com wrote:
..
There's no ideal solution here; IMO, the compromise that currently
exists is an acceptable one.
I don't see a compromise.
On Wed, Mar 24, 2010 at 7:02 PM, Mark Dickinson dicki...@gmail.com wrote:
..
So if I understand correctly, you propose that float('nan') ==
float('nan') return True. Would you also suggest extending this
behaviour to Decimal nans?
yes
___
On Wed, Mar 24, 2010 at 11:11 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Wed, Mar 24, 2010 at 7:02 PM, Mark Dickinson dicki...@gmail.com wrote:
..
So if I understand correctly, you propose that float('nan') ==
float('nan') return True. Would you also suggest extending
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
On Wed, Mar 24, 2010 at 2:09 PM, Mark Dickinson dicki...@gmail.com wrote:
Slight change of topic. I've been implementing the extra comparisons
required for the Decimal type and found an anomaly while testing.
Currently in py3k, order comparisons (but not ==, !=) between a
complex number and
65 matches
Mail list logo
