Re: [Python-Dev] __pycache__ creation

2010-03-23 Thread Martin v. Löwis 
> 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.

For 2.x, nothing will happen, anyway (except for Linux distributions
perhaps integrating a patch on their own): 2.7b1 is about to be
released, after which point 2.x will not see any new features.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Mark Dickinson 
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
> interpretation.

Agreed.  Decimal-to-complex equality and inequality comparisons should
be permitted.  Order comparisons would raise TypeError (just as
complex-to-complex and float-to-complex comparisons do at the moment.)

Mark
___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Steven D'Aprano 
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 see why this is a problem, perhaps somebody can explain what I'm 
missing.

Current system:
If the user doesn't have write permission in the appropriate directory, 
no .pyc file is created and the import uses the .py file only.

New system (proposal):
If the user doesn't have write permission in the appropriate directory, 
no __pycache__ folder is created and the import uses the .py file only. 
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.

Why bother to delete the unwritable __pycache__ directory? If you can't 
write to it, neither can any process with the same or fewer 
permissions. If some other process has more permissions, it could write 
something nasty to the directory, but surely it's not Python's 
responsibility to be secure in the face of a compromised root or admin 
account?

As I see it, the only question is, should we warn the user that we can't 
write to the newly-created __pycache__ directory? I'm +0 on that. To be 
clear:

Can't create __pycache__? That's a feature. Fail silently and fall back 
to using the .py file alone.

Existing __pycache__ directory, but can't write to it? That's a feature 
too, treat it just like the above.

No __pycache__ directory, and creating it succeeds, but then import 
can't write to the freshly created directory? That's just weird, so I'm 
+0 on raising a warning and -1 on raising an exception.


-- 
Steven D'Aprano
___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Stefan Krah 
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 fixing the
> 
> Decimal already has something that we can use in this case, and fits
> very nice here: Signals.

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 promiscuous behaviour

  strictness 1: current py3k behaviour

  strictness 2: current py3k behaviour + pure equality comparisons

  strictness 3: current py3k behaviour + pure equality comparisons +
disallow NaN equality comparisons [1]


Just as an illustration, here is a quick and dirty diff using the
DefaultContext for simplicity:

Index: Lib/decimal.py
===
--- Lib/decimal.py  (revision 78352)
+++ Lib/decimal.py  (working copy)
@@ -3765,8 +3765,8 @@
 def __init__(self, prec=None, rounding=None,
  traps=None, flags=None,
  Emin=None, Emax=None,
- capitals=None, _clamp=0,
- _ignored_flags=None):
+ capitals=None, strictness=1,
+ _clamp=0, _ignored_flags=None):
 if flags is None:
 flags = []
 if _ignored_flags is None:
@@ -5785,7 +5785,9 @@
 return other
 if isinstance(other, int):
 return Decimal(other)
-if raiseit:
+if isinstance(other, float) and DefaultContext.strictness == 0:
+return Decimal.from_float(other)
+if raiseit or DefaultContext.strictness > 1:
 raise TypeError("Unable to convert %s to Decimal" % other)
 return NotImplemented
 
@@ -5800,7 +5802,8 @@
 flags=[],
 Emax=9,
 Emin=-9,
-capitals=1
+capitals=1,
+strictness=1
 )



Stefan Krah


[1] See: http://mail.python.org/pipermail/python-dev/2009-November/093910.html,
 http://mail.python.org/pipermail/python-dev/2009-November/093952.html


___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Mark Dickinson 
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
>> > hard to detect. But the anomalies above indicate that not fixing the
>>
>> Decimal already has something that we can use in this case, and fits
>> very nice here: Signals.
>
> 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: completely promiscuous behaviour
>
>  strictness 1: current py3k behaviour
>
>  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 *more* strict
than the current py3k behaviour;  what's it disallowing that the
current py3k behaviour allows?

>  strictness 3: current py3k behaviour + pure equality comparisons +
>                disallow NaN equality comparisons [1]

Sorry, no.  I think there are good reasons for the current NaN
equality behaviour:  2.0 really *isn't* a NaN, and Decimal(2) ==
Decimal('nan') should return False rather than raising an exception.
And the decimal module provides compare and compare_signal for those
who want complete standards-backed control here.  Besides, this seems
to me to be an orthogonal issue to the issue of mixing Decimal with
other numeric types.

Mark
___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Ben Finney 
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 cached data from applications. Such data is
> >  locally generated as a result of time-consuming I/O or calculation. The
> >  application must be able to regenerate or restore the data. Unlike
> >  /var/spool, the cached files can be deleted without data loss. The data
> >  must remain valid between invocations of the application and rebooting
> >  the system.
> >
> >  
> > http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#VARCACHEAPPLICATIONCACHEDATA>
> >
> > This would suggest that Python could start using ‘/var/cache/python/’
> > for its cached bytecode tree on systems that implement the FHS.
>
> it reads *data*, not code.

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.

-- 
 \  “It seems intuitively obvious to me, which means that it might |
  `\   be wrong.” —Chris Torek |
_o__)  |
Ben Finney

___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Nick Coghlan 
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 could convert the Decimal to a Fraction, do the arithmetic
> as Fractions, and convert the result back to Decimal using the
> current precision.

It gets rather messy implementation-wise if you do it that way. As
Stefan pointed out, given the Decimal module's existing execution model
of invoking "convert_other" to create a Decimal instance and then
proceeding from there, it seems most straightforward to adopt the same
approach for floats and Fractions (i.e. keep the changes to handle the
new types inside the existing argument conversion algorithm).

Such a change should make Decimal/float and Decimal/Fraction arithmetic
work in a comprehensible way, albeit with double-rounding in the case of
the latter.

Comparisons would still need to be handled separately to avoid the lossy
conversions.

Regards,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Nick Coghlan 
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 the
'net, but it works fine for our own stuff (since it expects to be used
this way).

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Request for commit access

2010-03-23 Thread Brian Curtin 
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 patches
when they don't have direct access to Windows.

Brian Curtin

p.s. My contributor form in on file as of 2010-01-31.
___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Steven D'Aprano 
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
> > >
> > >  Purpose
> > >
> > >  /var/cache is intended for cached data from applications.
> > > Such data is locally generated as a result of time-consuming I/O
> > > or calculation. The application must be able to regenerate or
> > > restore the data. Unlike /var/spool, the cached files can be
> > > deleted without data loss. The data must remain valid between
> > > invocations of the application and rebooting the system.
> > >
> > > 
> > > http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html
> > >#VARCACHEAPPLICATIONCACHEDATA>
> > >
> > > This would suggest that Python could start using
> > > ‘/var/cache/python/’ for its cached bytecode tree on systems that
> > > implement the FHS.
> >
> > it reads *data*, not code.
>
> 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.


While I strongly approve of the concept of a central cache directory for 
many things, I don't think that .pyc files fit the bill.

Since there is no privileged python user that runs all Python code, and 
since any unprivileged user needs to be able to write .pyc files, the 
cache directory needs to be world-writable. But since the data being 
stored is code, that opens up a fairly nasty security hole: user fred 
could overwrite the cached .pyc files used by user barney and cause 
barney to run any arbitrary code fred likes.

The alternative would be to have individual caches for every user. Apart 
from being wasteful of disk space ("but who cares, bigger disks are 
cheap") that just complicates everything. You would need:

/var/cache/python//

which would essentially make it impossible to ship pre-compiled .pyc 
files, since the packaging system couldn't predict what usernames (note 
plural) to store them under.

It is not true that one can necessarily delete the cached files without 
data loss. Python still supports .pyc-only packages, and AFAIK there 
are no plans to stop that, so deleting the .pyc file may delete the 
module.


-- 
Steven D'Aprano
___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Ezio Melotti 

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 active contributors to diagnose 
issues and test patches when they don't have direct access to Windows.


Brian Curtin

p.s. My contributor form in on file as of 2010-01-31. 


+1
___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Dirkjan Ochtman 
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 other active contributors to diagnose issues and test patches
> when they don't have direct access to Windows.

I have usefully cooperated with Brian, so +1.

Cheers,

Dirkjan
___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Eric Smith 

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 diagnose issues and 
test patches when they don't have direct access to Windows.


Brian Curtin


Having worked with Brian at PyCon and via email, I support this. 
Especially if it can be done soon so he can work on committing 
http://bugs.python.org/issue1578269, which I have not had time to focus on.


--
Eric.
___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Stefan Krah 
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: completely promiscuous behaviour
> >
> >  strictness 1: current py3k behaviour
> >
> >  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 *more* strict
> than the current py3k behaviour;  what's it disallowing that the
> current py3k behaviour allows?


It's disallowing all comparisons between e.g. float and decimal. The idea
is that the context can provide a cheap way of enforcing types for people
who like it:


>>> from decimal import *
>>> DefaultContext.strictness = 1
>>> Decimal(9) == 9.0
False
>>> Decimal(9) in [1, 4.0 ,9]
True


>>> DefaultContext.strictness = 2
>>> Decimal(9) == 9.0
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/stefan/svn/py3k/Lib/decimal.py", line 858, in __eq__
other = _convert_other(other)
  File "/home/stefan/svn/py3k/Lib/decimal.py", line 5791, in _convert_other
raise TypeError("Unable to convert %s to Decimal" % other)
TypeError: Unable to convert 9.0 to Decimal
>>> Decimal(9) in [1, 4.0 ,9]
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/stefan/svn/py3k/Lib/decimal.py", line 858, in __eq__
other = _convert_other(other)
  File "/home/stefan/svn/py3k/Lib/decimal.py", line 5791, in _convert_other
raise TypeError("Unable to convert %s to Decimal" % other)
TypeError: Unable to convert 4.0 to Decimal
>>> Decimal(9) in [1, 4 ,9]
True


This mode could help catch bugs like:

n = 7 / 3 # Programmer thinks this is an integer
x = Decimal(100)
while x != n:
pass # do something
x -= 1



> >  strictness 3: current py3k behaviour + pure equality comparisons +
> >                disallow NaN equality comparisons [1]
> 
> Sorry, no.  I think there are good reasons for the current NaN
> equality behaviour:  2.0 really *isn't* a NaN, and Decimal(2) ==
> Decimal('nan') should return False rather than raising an exception.
> And the decimal module provides compare and compare_signal for those
> who want complete standards-backed control here.

I'd like to make it an option for people who don't want to write:

while x.compare_signal(7) != 0

And I think that an sNaN should really signal by default.


> Besides, this seems
> to me to be an orthogonal issue to the issue of mixing Decimal with
> other numeric types.

Yes, it would kind of overload the strictness parameter. I see it as another
type of strictness, so I brought it up here. Level 3 would be a bit like
the highest warning level of a compiler.

But of course there's no need to discuss NaNs further in this thread other
than to show a possible use of the flag.


Stefan Krah



___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread R. David Murray 
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 other active contributors to diagnose issues and test patches
> when they don't have direct access to Windows.
> 
> Brian Curtin

+1 from me too.  I've been working with Brian in IRC, and also at the Pycon
sprint.  Brian is careful with his code and very responsive to feedback.
And we need more Windows devs :)

--
R. David Murray  www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Decimal <-> float comparisons in py3k.

2010-03-23 Thread Bob Ippolito 
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 have to do is figure fairly efficient
>> ways to convert floats and decimals to normalized fractions (not
>> necessarily Fractions). I may be naive but this seems doable: for a
>> float, the denominator is always a power of 2 and removing factors of
>> 2 from the denominator is easy (just right-shift until the last bit is
>> zero). For Decimal, the unnormalized denominator is always a power of
>> 10, and the normalization is a bit messier, but doesn't seem
>> excessively so. The resulting numerator and denominator may be large
>> numbers, but for typical use of Decimal and float they will rarely be
>> excessively large, and I'm not too worried about slowing things down
>> when they are (everything slows down when you're using really large
>> integers anyway).
>
> I *am* worried about slowing things down for large Decimals:  if you
> can't put Decimal('1e1234567') into a dict or set without waiting for
> an hour for the hash computation to complete (because it's busy
> computing 10**1234567), I consider that a problem.
>
> But it's solvable!  I've just put a patch on the bug tracker:
>
> http://bugs.python.org/issue8188
>
> It demonstrates how hashes can be implemented efficiently and
> compatibly for all numeric types, even large Decimals like the above.
> It needs a little tidying up, but it works.

I was interested in how the implementation worked yesterday,
especially given the lack of explanation in the margins of
numeric_hash3.patch. numeric_hash4.patch has much better comments, but
I didn't see this patch until after I had sufficiently deciphered the
previous patch and wrote most of this:
http://bob.pythonmac.org/archives/2010/03/23/py3k-unified-numeric-hash/

I'm not really qualified to review the patch, what little formal math
training I had has atrophied quite a bit over the years, but as far as
I can tell it seems to work. The results also seem to match the Python
implementations that I created.

-bob
___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Raymond Hettinger 

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 promiscuous behaviour
> 
>  strictness 1: current py3k behaviour
> 
>  strictness 2: current py3k behaviour + pure equality comparisons
> 
>  strictness 3: current py3k behaviour + pure equality comparisons +
>disallow NaN equality comparisons [1]
> 

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.


Raymond
___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Mark Dickinson 
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 *more* strict
>> than the current py3k behaviour;  what's it disallowing that the
>> current py3k behaviour allows?
>
> It's disallowing all comparisons between e.g. float and decimal. The idea
> is that the context can provide a cheap way of enforcing types for people
> who like it:

 DefaultContext.strictness = 2
 Decimal(9) == 9.0
> Traceback (most recent call last):
>  File "", line 1, in 
>  File "/home/stefan/svn/py3k/Lib/decimal.py", line 858, in __eq__
>    other = _convert_other(other)
>  File "/home/stefan/svn/py3k/Lib/decimal.py", line 5791, in _convert_other
>    raise TypeError("Unable to convert %s to Decimal" % other)
> TypeError: Unable to convert 9.0 to Decimal

Hmm.  It seems to me that deliberately making an __eq__ method between
hashable types raise an exception isn't something that should be done
lightly, since it can *really* screw up sets and dicts.  For example,
with your proposal, {9.0, Decimal(x)} would either raise or not,
depending on whether Decimal(x) happened to hash equal to 9.0 (if they
don't hash equal, then __eq__ will never be called).  If the hash is
regarded as essentially a black box (which is what it should be for
most users) then you can easily end up with code that almost always
works, but *very* occasionally and unpredicatably raises an exception.

> And I think that an sNaN should really signal by default.

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 prevents hashing of quiet NaNs, but I
can't see any good rationale for that.)

Mark
___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Adam Olsen 
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 prevents hashing of quiet NaNs, but I
> can't see any good rationale for that.)

a = Decimal('nan')
a != a

They don't follow the behaviour required for being hashable.

float NaN should stop being hashable as well.


-- 
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Mark Dickinson 
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 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
True

Mark
___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Adam Olsen 
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 hash(a) == hash(b).  That's not violated here.
>
> 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
> True

Ergh, I thought that got changed.  Nevermind then.


-- 
Adam Olsen, aka Rhamphoryncus
___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Mark Dickinson 
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
>> True
>
> Ergh, I thought that got changed.  Nevermind then.

Hmm.  I think you're right:  it did get changed at some point early in
py3k's history;  I seem to recall that the identity-checking behaviour
got restored before 3.1 was released, though.  There was an issue
about this somewhere, but I'm failing to find it.

Mark
___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Russell E. Owen 
In article <[email protected]>,
 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 (think __pycache__ files created by the 
> > Apache
> > user).
> 
> Doesn't the existing .pyc mechanism have the same problem? Seems
> to me it's just as insecure to allow the Apache user to create
> .pyc files, since an attacker could overwrite them with arbitrary
> bytecode.
> 
> The only safe way is to pre-compile under a different user and
> make everything read-only to Apache. The same thing would apply
> under the __pycache__ regime.

This does sound like a bit security hole both in existing Python and the 
new __pycache__ proposed mechanism. It seems like this is the time to 
address it, while changing the caching mechanism.

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, 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.

-- Russell

___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Guido van Rossum 
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 dicts:
>>>
>> x = float('nan')
>> s = {x}
>> x in s
>>> True
>>
>> Ergh, I thought that got changed.  Nevermind then.
>
> Hmm.  I think you're right:  it did get changed at some point early in
> py3k's history;  I seem to recall that the identity-checking behaviour
> got restored before 3.1 was released, though.  There was an issue
> about this somewhere, but I'm failing to find it.

Raymond and I don't see this the same way. It looks like he won. :-)

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Henning von Bargen 

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/site-packages directory.

I prefer it that way because it gives a clean separation between
standard library files and application specific files.
For example, if I want to use another Python version, I can just
delete the python26 directory because I know it doesn't contain
any application-specific code, just the standard library files.

Considering the complexity, the risks and the benefit of the
whole __pycache__ thingie, I'm -1...

Henning
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Attribute lookup ambiguity

2010-03-23 Thread Pascal Chambon 

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 would be incorrect to say that "__getattribute__
raises an exception".

When we say that a function raises an exception, we normally
mean that the exception propagates out of the function and
can be seen by the caller, not that it was raised and caught
somewhere inside the function.

Indeed, but I've never run into any doc mentionning that the default 
__getattribute__ raised in exception instead of forwarding to 
__getattr__ by itself.
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 
"; 
that sentence which simply offers two alternatives for the behaviour of 
customized __gettattribute__ methods, without giving any hint on the 
behaviourthat was chosen when implementing object.__gettattribute__.


Or am I missing some other doc which I'm supposed to know  :?

"In the face of ambiguity, refuse the temptation to guess", as we say 
anyway, so I propose we patch the doc to clarify this point for newcomers ^^


Regards,
Pascal

___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Greg Ewing 

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 would benefit most from it during development.
I hardly ever look in the directories of installed packages,
so I don't care what they look like.

--
Greg
___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Greg Ewing 

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 make a
copy of /bin/sh and suid it.

Of course, if you have permission to su apache, then this
is not necessary. But then you wouldn't have to go through
web server contortions to fix apache-generated botchups
either.

--
Greg
___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Steven D'Aprano 
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 hash(a) == hash(b).  That's not violated here.
>
> 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
> True


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.


-- 
Steven D'Aprano
___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Greg Ewing 

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.

--
Greg


___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Greg Ewing 

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 think so. Currently, when you install a package (by
whatever means) in a directory that's not writable by the people
who will be running it, there are two possibilities:

1) Precompiled .pyc files are generated at installation time,
which are then read-only to users.

2) No .pyc files are installed, in which case none can or will be
created by users either, since they don't have write permission
to the directory.

None of this would change if __pycache__ directories were used.
The only difference would be that there would be an additional
mode for failure to create .pyc files, i.e. __pycache__ could
be created but nothing could be written to it because of a
umask issue.

If you install in a shared site-packages by dragging, you
already have to be careful about setting the permissions. You'd
just have to be sure to extended that diligence to any
contained __pycache__ directories.

--
Greg
___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Barry Warsaw 
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.

>I see only two reasonable solutions for __pycache__ creation -- either
>we change all setup/install scripts (both for core Python and for 3rd
>party packages) to always create a __pycache__ subdirectory for every
>directory (including package directories) installed; or we somehow
>create it the first time it's needed.
>
>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). So even
>apart from the security issue (which I haven't thought about deeply) I
>think precreation should at least be an easily accessible option both
>for the core (where it can be done by compileall) and for 3rd party
>packages (where I guess it's up to distutils or whatever install
>mechanism is used).

So you're +1 on Tough Luck?  I think that's the best answer.  You will be able
to arrange pre-creation though compileall with the right layout and presumably
the right umask if you want.

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Martin v. Löwis 
>> 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 patches
>> when they don't have direct access to Windows.
>>
>> Brian Curtin
> 
> +1 from me too.  I've been working with Brian in IRC, and also at the Pycon
> sprint.  Brian is careful with his code and very responsive to feedback.
> And we need more Windows devs :)

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.

With all that said: I'm also fine with giving access to Brian (in
particular due to the endorsements that have already been posted). I
still would like somebody to step forward as a mentor, and I would need
Brian to send me his SSH key.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Attribute lookup ambiguity

2010-03-23 Thread Greg Ewing 

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 catch an AttributeError
and call __getattr__ for you. Given the existence of that
mechanism, it seems unlikely that the same thing would be
implemented over again in the standard __getattribute__
method.

So I don't think it requires very much guesswork to infer
that the standard __getattribute__ won't call __getattr__ on
its own.

I concede that the wording could be improved to remove any
possibility of doubt, though.

--
Greg
___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Barry Warsaw 
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 byte code generation at all might be
>sufficient.

That's what I'm thinking.  Of course it will always be possible to run
compileall and get the __pycache__ directories pre-created, presumably with
the right umask.

>As for the original question (funny umasks), I think my proposal is
>"tough luck". Don't try to be super-smart; as Antoine explains, it gets
>worse, not better. If the user has arranged that Python will create
>unusable directories, the user better changes his setup.

I completely agree; +1

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Barry Warsaw 
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 option which would be essentially
equivalent to

find . -name '__pycache__' | xargs rmdir

-Barry



signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
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__ directorie s and umask

2010-03-23 Thread Antoine Pitrou 
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 the *main* one.

It's the only reason the PEP was originally designed, and proposed.

> Personally I would benefit most from it during development.

Why? What benefit would it bring to you?

> I hardly ever look in the directories of installed packages,
> so I don't care what they look like.

Neither do I, but Ubuntu/Debian packagers want to share the source code of
third-party libraries across Python versions while keeping distinct bytecode
files (obviously).
Again, that's the original point of the PEP as proposed by Barry.


___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Barry Warsaw 
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 user, with the right umask.

I don't think they're mutually exclusive.  We will definitely give users the
tool to do compilation at install time via compileall.  That needn't preclude
on-demand creation, which will generally Just Work.

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Barry Warsaw 
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 would PEP 3147 change that?

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread 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.

If the process goes differently, it probably deserves documenting somewhere.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Barry Warsaw 
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, either via your distribution's installer or distutils.  I think
most on-demand creation of pyc files will be when you're developing your own
code.  I don't want to have to run a separate step to get the benefit of
__pycache__, but I admit it's outside the scope of the PEP's original
intention.  I leave it to the BDFL.

-Barry


signature.asc
Description: PGP signature
___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Ben Finney 
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 Python could start using
> > > > ‘/var/cache/python/’ for its cached bytecode tree on systems
> > > > that implement the FHS.
> > […] 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.
>
> While I strongly approve of the concept of a central cache directory
> for many things, I don't think that .pyc files fit the bill.
>
> Since there is no privileged python user that runs all Python code,
> and since any unprivileged user needs to be able to write .pyc files,

Hold up; my understanding is that, as Antoine Pitrou says:

> 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.

So, the packaging system will, by definition, have access to write to
FHS directories and those directories don't need to be world-writable.

-- 
 \ “Pinky, are you pondering what I'm pondering?” “I think so, |
  `\ Brain, but how will we get a pair of Abe Vigoda's pants?” |
_o__)   —_Pinky and The Brain_ |
Ben Finney

___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Barry Warsaw 
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
[email protected]
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__ directorie s and umask

2010-03-23 Thread Isaac Morland 

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 one point, but I'm not sure it's the *main* one.


It's the only reason the PEP was originally designed, and proposed.


At least one additional use case has appeared.  Actually, my use case was 
mentioned long ago, but I didn't really push (e.g. by writing a patch) and 
nobody jumped on it.  But this PEP solves my case too, so it should not be 
ignored just because the immediate impetus for the PEP is another case.



Personally I would benefit most from it during development.


Why? What benefit would it bring to you?


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 will be much easier to see what is actually there.


Or if we're using SVN and we do "svn status", the only spurious result 
will be "? __pycache__" rather than "? X.pyc" for every X.py in the 
directory.


Or whatever other good effects come from having less junk in our source 
directories.


Directory tidiness is a positive general feature with at least a few 
specific benefits.


Isaac Morland   CSCF Web Guru
DC 2554C, x36650WWW Software Specialist
___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Antoine Pitrou 
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 will be much easier to see what is actually there.

I don't really get it. I have never had any problem to see "what is
actually here" in a Python source directory, despite the presence of pyc
files.

> Or if we're using SVN and we do "svn status", the only spurious result 
> will be "? __pycache__" rather than "? X.pyc" for every X.py in the 
> directory.

Well, I was assuming that everyone had been using svn:ignore,
or .hgignore, for years.
Similarly, you will configure svn, hg, or any other system, to ignore
__pycache__ directories (or .pyc files) so that they don't appear in
"svn status".

> Directory tidiness is a positive general feature with at least a few 
> specific benefits.

It's still mostly cosmetic and I don't think it's as serious as any
positive or negative system administration effects the change may have.


___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Ron Adam 



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 compileall --pycache", if someone implements it.

Creation of the __pycache__ /contents/ (files inside the directory) 
would still
be part of core Python, but only if the directory exists and is 
writable by the

current process.


-1

If, as I have done several times recently, I create a directory and 
insert an empty __init__.py and several real module.py files, I want the 
.pycs to go into __pycache__ *automatically, by default, without me also 
having to remember to create an empty __pycache__ *directory*, *each 
time*.  Ugh.


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 startup time may just be a tad longer, but probably not enough to be 
much of a problem.  If it is a problem you can just create the __pycache__ 
directory, but nothing bad will happen if you don't.


Ron





___
Python-Dev mailing list
[email protected]
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?

2010-03-23 Thread Laurent Gautier 

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 actually learn the
intricacies of Python 3.
Developing Python 3-specific features could be used to increase the
amount of work on the project, but I am uncertain of whether this is
worth a full GSoC.


I'd say this would definitely make a GSoC project; any non-trivial
porting will be.


Sounds good to me.  Line up a good student and bob's your uncle.

--titus



I may have a student that is looking interested, and I have inserted the 
porting project to the Wiki table.



Laurent.


PS: Editing that table felt like a test in disguise ;-)
___
Python-Dev mailing list
[email protected]
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

2010-03-23 Thread Stephen J. Turnbull 
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 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"?
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com