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.
I don't see how it can be so. Aren't all of those entries garbage?
To compute a histogram o
On 3/20/10 4:13 AM, C. Titus Brown wrote:
On Sat, Mar 20, 2010 at 12:00:48AM +0100, "Martin v. L?wis" wrote:
Whether this is worth weeks of work or not will depend on a given
student's knowledge about Python 3, and I'd suspect that the GSoC would
be an opportunity for a number of applicant to ac
Terry Reedy wrote:
On 3/22/2010 2:15 PM, Antoine Pitrou wrote:
What I am proposing is that the creation of __pycache__ /directories/
be put
outside of the core. It can be part of distutils, or of a separate
module, or
delegated to third-party tools. It could even be as simple as
"python -m
Le mardi 23 mars 2010 à 20:50 -0400, Isaac Morland a écrit :
>
> I'm sure Greg will jump in if I'm wrong about what he is saying, but 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 w
On Tue, 23 Mar 2010, Antoine Pitrou wrote:
Greg Ewing canterbury.ac.nz> writes:
The main point of the __pycache__ proposal is to solve the needs of
Ubuntu/Debian packagers. If you are developing (rather than deploying or
building packages), you shouldn't have these needs AFAICT.
Maybe it's o
On Mar 23, 2010, at 12:02 AM, Martin v. Löwis wrote:
>I think the appropriate action at this point is to record this specific
>objection in the PEP.
Done.
-Barry
signature.asc
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.or
Antoine Pitrou writes:
Steven D'Aprano writes:
> On Wed, 24 Mar 2010 12:35:43 am Ben Finney wrote:
> > > On 23.03.2010 02:28, Ben Finney wrote:
> > > > http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html
> > > >#VARCACHEAPPLICATIONCACHEDATA>
> > > >
> > > > This would suggest that Pyth
On Mar 23, 2010, at 12:49 PM, Russell E. Owen wrote:
>If .pyc files are to be shared, it seems essential to (by default)
>generate them at install time and make them read-only for unprivileged
>users.
I think in practice this is what's almost always going to happen for system
Python source, eit
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 wo
On Mar 24, 2010, at 12:35 AM, Ben Finney wrote:
>So what? There's no implication that data-which-happens-to-be-code is
>unsuitable for storage in ‘/var/cache/foo/’. Easily-regenerated Python
>byte code for caching meets the description quite well, AFAICT.
pyc files don't go there now, so why woul
On Mar 22, 2010, at 08:33 PM, Antoine Pitrou wrote:
>Well, precisely. That's why I suggest that creating the __pycache__
>directories be done *at install time* (or packaging time), and not via the
>core import machinery (that is, not at import time). That is, when you *know*
>you are the right use
Greg Ewing canterbury.ac.nz> writes:
> > The main point of the __pycache__ proposal is to solve the needs of
> > Ubuntu/Debian packagers. If you are developing (rather than deploying or
> > building packages), you shouldn't have these needs AFAICT.
>
> Maybe it's one point, but I'm not sure it's
On Mar 22, 2010, at 09:57 PM, Antoine Pitrou wrote:
>It's especially annoying, of course, if you have to ask someone else to
>remove the directories for you (or if you have to write custom code and get
>it executed by the Apache or WSGI handler...).
compileall should probably grow a --clean optio
On Mar 22, 2010, at 09:47 PM, Martin v. Löwis wrote:
>Therefore, I'm in favor of having it on by default. If certain use cases
>make it problematic (e.g. Apache creating directories which you then
>cannot delete), there should be a way to turn it *off*. Perhaps the
>existing machinery to turn of b
Pascal Chambon wrote:
All I've found is "If the class also defines __getattr__(),
the latter will not be called unless __getattribute__()
either calls it explicitly or raises an AttributeError
Hmmm. Well, it still implies that there is some mechanism
outside of __getattribute__ that will catc
>> Having been active in bug triage and patch writing/reviewing since late
>> 2009, it was suggested in the python-dev IRC channel that I request commit
>> access to the repository. I'm primarily a Windows user and have worked with
>> many of the other active contributors to diagnose issues and tes
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
wri
Russell E. Owen wrote:
If .pyc files are to be shared, it seems essential to (by default)
generate them at install time and make them read-only for unprivileged
users.
This in turn implies that we may have to give up some support for
dragging python modules into site-packages
No, I don't t
Steven D'Aprano wrote:
If the user has write permission and the __pycache__ folder is created,
but the umask is screwy and no .pyc files can be created, no .pyc file
is created and the import uses the .py file only despite the existence
of an empty __pycache__ folder.
Sounds okay to me.
--
On Wed, 24 Mar 2010 05:04:37 am Mark Dickinson wrote:
> On Tue, Mar 23, 2010 at 5:48 PM, Adam Olsen wrote:
> > a = Decimal('nan')
> > a != a
> >
> > They don't follow the behaviour required for being hashable.
>
> What's this required behaviour? The only rule I'm aware of is that
> if a == b then
Antoine Pitrou wrote:
Well, if I can create a setuid apache shell, I can probably su as root or apache
as well.
("su -c rm -r whatever")
Or are you talking about a Web-based shell?
I'm just saying that if there is any way of running code of
your choice as the apache user, you can get it to ma
Antoine Pitrou wrote:
The main point of the __pycache__ proposal is to solve the needs of
Ubuntu/Debian packagers. If you are developing (rather than deploying or
building packages), you shouldn't have these needs AFAICT.
Maybe it's one point, but I'm not sure it's the *main* one.
Personally I
Greg Ewing a écrit :
Pascal Chambon wrote:
I don't follow you there - in my mind, the default __getattribute__
could simply have wrapped all its operations inside soem kind of
"try..catch AttributeError:" mechanism, and thus been able to
fallback to __getattr__ in any way.
But then it woul
Antoine Pitrou wrote:
> > or if a user installs by dragging into
> > site-packages instead of using an installer?
>
> Well... do people actually do this?
Why not?
And it is also common to just set the PYTHONPATH environment variable
instead of using setup.py install or copy the files to the
lib/
On Tue, Mar 23, 2010 at 10:55 AM, Mark Dickinson wrote:
> On Tue, Mar 23, 2010 at 6:07 PM, Adam Olsen wrote:
>> On Tue, Mar 23, 2010 at 12:04, Mark Dickinson wrote:
>>> Note that containment tests check identity before equality, so there's
>>> no problem with putting (float) nans in sets or dict
In article <4ba80418.6030...@canterbury.ac.nz>,
Greg Ewing wrote:
> Antoine Pitrou wrote:
>
> > In light of this issue, I'm -0.5 on __pycache__ becoming the default
> > caching
> > mechanism. The directory ownership/permissions issue is too much of a mess,
> > especially for Web applications (
On Tue, Mar 23, 2010 at 6:07 PM, Adam Olsen wrote:
> On Tue, Mar 23, 2010 at 12:04, Mark Dickinson wrote:
>> Note that containment tests check identity before equality, so there's
>> no problem with putting (float) nans in sets or dicts:
>>
> x = float('nan')
> s = {x}
> x in s
>> Tru
On Tue, Mar 23, 2010 at 12:04, Mark Dickinson wrote:
> On Tue, Mar 23, 2010 at 5:48 PM, Adam Olsen wrote:
>> a = Decimal('nan')
>> a != a
>>
>> They don't follow the behaviour required for being hashable.
>
> What's this required behaviour? The only rule I'm aware of is that if
> a == b then has
On Tue, Mar 23, 2010 at 5:48 PM, Adam Olsen wrote:
> a = Decimal('nan')
> a != a
>
> They don't follow the behaviour required for being hashable.
What's this required behaviour? The only rule I'm aware of is that if
a == b then hash(a) == hash(b). That's not violated here.
Note that containmen
On Tue, Mar 23, 2010 at 11:31, Mark Dickinson wrote:
> Agreed, notwithstanding the above comments. Though to avoid the
> problems described above, I think the only way to make this acceptable
> would be to prevent hashing of signaling nans. (Which the decimal
> module current does; it also preve
On Tue, Mar 23, 2010 at 3:09 PM, Stefan Krah wrote:
> Mark Dickinson wrote:
>> [Stefan]
>> >
>> > strictness 2: current py3k behaviour + pure equality comparisons
>>
>> Can you explain what you mean by "+ pure equality comparisons" here?
>> If I'm understanding correctly, this is a mode that's *
On Mar 23, 2010, at 5:09 AM, Stefan Krah wrote:
>
> I like the simplicity of having a single signal (e.g. CoercionError), but
> a strictness context flag could offer greater control for people who only
> want pure decimal/integer operations.
>
>
> For example:
>
> strictness 0: completely pro
On Sat, Mar 20, 2010 at 4:38 PM, Mark Dickinson wrote:
> On Sat, Mar 20, 2010 at 7:56 PM, Guido van Rossum wrote:
>> I propose to reduce all hashes to the hash of a normalized fraction,
>> which we can define as a combination of the hashes for the numerator
>> and the denominator. Then all we hav
On Tue, 23 Mar 2010 08:50:21 -0600, Brian Curtin wrote:
> Having been active in bug triage and patch writing/reviewing since late
> 2009, it was suggested in the python-dev IRC channel that I request commit
> access to the repository. I'm primarily a Windows user and have worked with
> many of the
Mark Dickinson wrote:
> > I like the simplicity of having a single signal (e.g. CoercionError), but
> > a strictness context flag could offer greater control for people who only
> > want pure decimal/integer operations.
>
> Sounds worth considering.
>
> > For example:
> >
> > strictness 0: comp
Brian Curtin wrote:
Hi all,
Having been active in bug triage and patch writing/reviewing since late
2009, it was suggested in the python-dev IRC channel that I request
commit access to the repository. I'm primarily a Windows user and have
worked with many of the other active contributors to d
On Tue, Mar 23, 2010 at 15:50, Brian Curtin wrote:
> Having been active in bug triage and patch writing/reviewing since late
> 2009, it was suggested in the python-dev IRC channel that I request commit
> access to the repository. I'm primarily a Windows user and have worked with
> many of the othe
On 23/03/2010 16.50, Brian Curtin wrote:
Hi all,
Having been active in bug triage and patch writing/reviewing since
late 2009, it was suggested in the python-dev IRC channel that I
request commit access to the repository. I'm primarily a Windows user
and have worked with many of the other act
On Wed, 24 Mar 2010 12:35:43 am Ben Finney wrote:
> Matthias Klose writes:
> > On 23.03.2010 02:28, Ben Finney wrote:
> > > Perhaps also of note is that the FHS recommends systems use
> > > ‘/var/cache/foo/’ for cached data from applications:
> > >
> > > /var/cache : Application cache data
>
Hi all,
Having been active in bug triage and patch writing/reviewing since late
2009, it was suggested in the python-dev IRC channel that I request commit
access to the repository. I'm primarily a Windows user and have worked with
many of the other active contributors to diagnose issues and test p
Antoine Pitrou wrote:
>> or if a user installs by dragging into
>> site-packages instead of using an installer?
>
> Well... do people actually do this?
Yes. We do it all the time with unpackaged only-for-internal-use Python
code.
I wouldn't expect it to work with random packages downloaded from
Greg Ewing wrote:
> Mark Dickinson wrote:
>
>> But the Fraction type is going to mess this up: for Decimal +
>> Fraction -> Decimal, I don't see any other sensible option than to
>> convert the Fraction using the current context, since lossless
>> conversion isn't generally possible.
>
> You co
Matthias Klose writes:
> On 23.03.2010 02:28, Ben Finney wrote:
> > Perhaps also of note is that the FHS recommends systems use
> > ‘/var/cache/foo/’ for cached data from applications:
> >
> > /var/cache : Application cache data
> >
> > Purpose
> >
> > /var/cache is intended for ca
On Tue, Mar 23, 2010 at 12:09 PM, Stefan Krah wrote:
> Facundo Batista wrote:
>> On Fri, Mar 19, 2010 at 5:50 PM, Guido van Rossum wrote:
>>
>> > As a downside, there is the worry that inadvertent mixing of Decimal
>> > and float can compromise the correctness of programs in a way that is
>> > h
Facundo Batista wrote:
> On Fri, Mar 19, 2010 at 5:50 PM, Guido van Rossum wrote:
>
> > As a downside, there is the worry that inadvertent mixing of Decimal
> > and float can compromise the correctness of programs in a way that is
> > hard to detect. But the anomalies above indicate that not fix
On Tue, 23 Mar 2010 07:38:42 am Guido van Rossum wrote:
> But creating it as needed runs into at least similar problems with
> ownership as creating .pyc files when first needed (if the parent
> directory is root-owned a mere mortal can't create it at all).
Isn't that a feature though?
I don't se
On Tue, Mar 23, 2010 at 12:33 AM, Greg Ewing
wrote:
> Mark Dickinson wrote:
>>
>> It might make sense for
>> Decimal + complex mixed-type operations to be disallowed, for example.
>
> As long as you're allowing Decimal-float comparisons,
> Decimal-complex comparison for equality has an obvious
> i
> Is there a need for python to use __pycache__ directories 100% of the
> time? For 2.x it seems like being flexible would be best, and if 3.x
> is going to be strict about it, it should be strict sooner than later
> rather than have a lot of 3rd party packages break at some point down
> the road
48 matches
Mail list logo
