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?
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: disti
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
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-upda
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
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
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 do
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 qu
> 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 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,
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 o
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 mechani
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 no
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
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 wo
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
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
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 d
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 setup
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
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
_
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 qu
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
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-D
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
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
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 bec
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
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 refere
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 :-/ )
Us
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 c
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 pi
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 rat
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
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
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
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 i
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 chang
[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
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 ch
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 us
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 old
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 t
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
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
___
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://bertrandme
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
ba
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 colu
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 < in
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
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-
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, fl
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
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,
> 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 h
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 o
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 (
> 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-d
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
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,
>> cont
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 refle
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,
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
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.
_
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 tha
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 lis
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 on
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://
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?
>>
>
>
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 sh
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,
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 l
75 matches
Mail list logo
