On Sun, Mar 21, 2010 at 10:50 PM, Greg Ewing
greg.ew...@canterbury.ac.nz wrote:
Raymond Hettinger wrote:
Since decimal also allows arbitrary sizes, all long ints can be
exactly represented (this was even one of the design goals
for the decimal module).
There may be something we need to
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.
Be able to duck this question was
Greg Ewing wrote:
Raymond Hettinger wrote:
Remember, the notion of inexactness is a taint,
not an intrinsic property of a type. Even the Scheme numeric
tower recognizes this. LIkewise, the decimal specification also
spells-out this notion as basic to its design.
I'm not sure it really
Raymond Hettinger wrote:
On Mar 21, 2010, at 3:35 PM, Guido van Rossum wrote:
It seems to me that Decimals and floats should be considered at
the same level (i.e. both implement Real).
Agreed, but doesn't help. (Except against the idea that Decimal goes
on the integer side of Fraction, which
I have a pretty good start on PEP 3147 implementation [1], but I've
encountered a situation that I'd like to get some feedback on. Here's the
test case illustrating the problem. From test_import.py:
def test_writable_directory(self):
# The umask is not conducive to creating a
Barry Warsaw barry at python.org writes:
I'm not sure what the right answer is. Some possible choices:
* Tough luck
* Force the umask so that the directory is writable, but then the question is,
by whom? ugo+w or something less?
* Copy the permissions from the parent directory and
On Mar 16, 2010, at 07:44 PM, Nick Coghlan wrote:
In Python 3.1, *invoking* py_compile.compile() will create 2.x style
bytecode. Similarly, when force==False, compileall.compile_dir() and
compileall.compile_path() will check for 2.x style bytecode in order to
decide whether or not to compile the
Or maybe you have a better idea? What's the equivalent situation on Windows
and how would things work there?
On Windows, this problem is easy: create the directory with no
specification of an ACL, and it will (usually) inherit the ACL of the
parent directory. IOW, the same users will have
refuse to create __pycache__ if I can't create it with the same ownership
and permissions as the parent directory (and raise an ImportWarning).
I don't think an ImportWarning should be raised: AFAICT, we are not
raising one, either, when the pyc file cannot be created (and it may
well be
On Mar 22, 2010, at 2:23 AM, Mark Dickinson wrote:
Note that comparisons are a separate issue: those always need to be
done exactly (at least for equality, and once you're doing it for
equality it makes sense to make the other comaprisons exact as well),
else the rule that x == y implies
On Mon, Mar 22, 2010 at 8:39 AM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
My instinct says that we're asking for trouble if comparisons have
different coercion rules than arithmetic operations.
Sorry, no, this is a station we passed long ago when float-long
comparison was fixed to
Oh, and by the way, there can be a race condition between __pycache__
creation and deletion (if it fails the test), where an attacker can stuff
a hostile pyc file in the directory in the meantime (and the deletion
then fails because the directory isn't empty).
IMO, all these issues militate
On Mar 22, 2010, at 10:00 AM, Guido van Rossum wrote:
Decimal + float -- Decimal
If everybody associated with the Decimal implementation wants this I
won't stop you; as I repeatedly said my intuition about this one (as
opposed to the other two above) is very weak.
That's my vote.
I
On Mon, 22 Mar 2010, Antoine Pitrou wrote:
Oh, and by the way, there can be a race condition between __pycache__
creation and deletion (if it fails the test), where an attacker can stuff
a hostile pyc file in the directory in the meantime (and the deletion
then fails because the directory isn't
Michael Foord a écrit :
On 20/03/2010 12:00, Pascal Chambon wrote:
But the point which for me is still unclear, is : does the default
implementation of __getattribute__ (the one of object) call
__getattr__ by himself, or does it rely on its caller for that, by
raising an AttributeError ?
Isaac Morland ijmorlan at uwaterloo.ca writes:
IMO, all these issues militate for putting __pycache__ creation out of
the interpreter core, and in the hands of third-party package-time/
install-time tools (or distutils).
Speaking only for myself, but really for anybody who likes tidy
On Mon, Mar 22, 2010 at 1:56 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
On Mar 22, 2010, at 10:00 AM, Guido van Rossum wrote:
Decimal + float -- Decimal
If everybody associated with the Decimal implementation wants this I
won't stop you; as I repeatedly said my intuition
On Mon, Mar 22, 2010 at 10:22 AM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
On Mon, Mar 22, 2010 at 1:56 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
On Mar 22, 2010, at 10:00 AM, Guido van Rossum wrote:
Decimal + float -- Decimal
If everybody associated with
On Mon, Mar 22, 2010 at 5:56 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
On Mar 22, 2010, at 10:00 AM, Guido van Rossum wrote:
Decimal + float -- Decimal
If everybody associated with the Decimal implementation wants this I
won't stop you; as I repeatedly said my intuition
On Mar 22, 2010, at 11:26 AM, Mark Dickinson wrote:
On Mon, Mar 22, 2010 at 5:56 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
On Mar 22, 2010, at 10:00 AM, Guido van Rossum wrote:
Decimal + float -- Decimal
If everybody associated with the Decimal implementation wants
On Mon, Mar 22, 2010 at 10:26 AM, Mark Dickinson dicki...@gmail.com wrote:
On Mon, Mar 22, 2010 at 5:56 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
On Mar 22, 2010, at 10:00 AM, Guido van Rossum wrote:
Decimal + float -- Decimal
If everybody associated with the Decimal
Antoine Pitrou wrote:
Isaac Morland ijmorlan at uwaterloo.ca writes:
IMO, all these issues militate for putting __pycache__ creation out of
the interpreter core, and in the hands of third-party package-time/
install-time tools (or distutils).
Speaking only for myself, but really for anybody
On Mar 22, 2010, at 11:54 AM, Guido van Rossum wrote:
So now we have a second-order decision to make -- whether
Decimal+float should convert the float to Decimal using the current
context's precision, or do it exactly. I think we should just follow
Decimal.from_float() here, which AFAIK
Guido van Rossum gu...@python.org wrote:
Decimal + float -- Decimal
If everybody associated with the Decimal implementation wants this I
won't stop you; as I repeatedly said my intuition about this one (as
opposed to the other two above) is very weak.
I've been following the discussion
On Mon, Mar 22, 2010 at 7:00 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
On Mar 22, 2010, at 11:26 AM, Mark Dickinson wrote:
Just for the record, I'd also prefer Decimal + Fraction - Decimal.
Guido was persuasive on why float + Fraction -- float,
so this makes sense for the
One other thought.
The Decimal constructor should now accept floats as a possible input type.
Formerly, we separated that out to Decimal.from_float() because
decimals weren't interoperable with floats.
This will put decimal and float back on equal footing so that we have both:
Raymond Hettinger raymond.hettin...@gmail.com wrote:
On Mar 22, 2010, at 11:26 AM, Mark Dickinson wrote:
Just for the record, I'd also prefer Decimal + Fraction - Decimal.
Guido was persuasive on why float + Fraction -- float,
so this makes sense for the same reasons.
For the
On Mon, Mar 22, 2010 at 11:36 AM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
One other thought.
The Decimal constructor should now accept floats as a possible input type.
Formerly, we separated that out to Decimal.from_float() because
decimals weren't interoperable with floats.
Not
Sorry to intervene out of the blue, but I find the suggested rule for
fractional to decimal conversion not as clean as I'd expect.
If fractions are converted to decimals when doing arithmetics, would it be
worthwhile to at least provide a minimum of fractional conversion integrity?
What I have
On Mon, Mar 22, 2010 at 8:02 PM, Pierre B. pierre...@hotmail.com wrote:
Sorry to intervene out of the blue, but I find the suggested rule for
fractional to decimal conversion not as clean as I'd expect.
If fractions are converted to decimals when doing arithmetics, would it be
worthwhile to
On Mar 22, 2010, at 02:30 PM, Antoine Pitrou wrote:
Barry Warsaw barry at python.org writes:
* Tough luck
* Force the umask so that the directory is writable, but then the question
is,
by whom? ugo+w or something less?
* Copy the permissions from the parent directory and ignore umask
On Mar 22, 2010, at 06: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
On Mar 22, 2010, at 02:02 PM, Ron Adam wrote:
If I understand correctly, we would have the current mode as the default, and
can trigger __pycache__ behavior simply by manually creating a __pycache__
directory and deleting any byte-code files in the module/program directory.
I like this, it is
While we're on the topic, I think you should consider allowing the Fraction()
constructor to accept a decimal input.
This corresponds to common schoolbook problems and simple client requests:
Express 3.5 as a fraction.
Fraction(Decimal('3.5'))
Fraction(7, 2)
Unlike typical binary
Barry Warsaw barry at python.org writes:
When Python is being installed, either by a from-source 'make install' or by
the distro packager, then you'd expect the umask not to be insane. In the
latter case, it's a bug and in the former case you screwed up so you should be
able to delete and
On Mon, Mar 22, 2010 at 12:20 PM, Barry Warsaw ba...@python.org wrote:
On Mar 22, 2010, at 02:02 PM, Ron Adam wrote:
If I understand correctly, we would have the current mode as the default, and
can trigger __pycache__ behavior simply by manually creating a __pycache__
directory and deleting any
On 22 March 2010 19:32, Mark Dickinson dicki...@gmail.com wrote:
I think getting this to work would involve a lot of extra code and
significant 'cleverness'. I'd prefer the simple-to-implement and
simple-to-explain option of rounding the Fraction before performing
the operation, even if this
On Mon, Mar 22, 2010 at 12:33 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
While we're on the topic, I think you should consider allowing the Fraction()
constructor to accept a decimal input.
This corresponds to common schoolbook problems and simple client requests:
Express 3.5
On Mon, Mar 22, 2010 at 8:33 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
While we're on the topic, I think you should consider allowing the Fraction()
constructor to accept a decimal input.
This corresponds to common schoolbook problems and simple client requests:
Express 3.5
Barry Warsaw wrote:
On Mar 22, 2010, at 06: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
On Mon, Mar 22, 2010 at 12:45 PM, Mark Dickinson dicki...@gmail.com wrote:
On Mon, Mar 22, 2010 at 8:33 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
While we're on the topic, I think you should consider allowing the Fraction()
constructor to accept a decimal input.
This
On Mon, Mar 22, 2010 at 8:44 PM, Guido van Rossum gu...@python.org wrote:
On Mon, Mar 22, 2010 at 12:33 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
While we're on the topic, I think you should consider allowing the Fraction()
constructor to accept a decimal input.
This
For the record, I thought I would take a stab at making a single post
that recaps the trade-offs and reasoning behind the decision
to have Fraction + decimal/float -- decimal/float.
Pros:
* While we know that both decimal and binary floats have a
fixed internal precision and can be converted
Martin v. Löwis martin at v.loewis.de writes:
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.
Except
Antoine Pitrou wrote:
Martin v. Löwis martin at v.loewis.de writes:
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
On Mon, Mar 22, 2010 at 06:56, Barry Warsaw ba...@python.org wrote:
I have a pretty good start on PEP 3147 implementation [1], but I've
encountered a situation that I'd like to get some feedback on. Here's the
test case illustrating the problem. From test_import.py:
def
Martin v. Löwis martin at v.loewis.de writes:
Antoine Pitrou wrote:
Martin v. Löwis martin at v.loewis.de writes:
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
Why is it too late? Fix it, and get on.
Sure, but it is annoying, and since it's the kind of things that noone
(including sysadmins) ever thinks about in advance, it's bound to repeat
itself
quite often.
It's especially annoying, of course, if you have to ask someone else to remove
the
Le lundi 22 mars 2010 à 23:18 +0100, Martin v. Löwis a écrit :
If Apache creates a folder for me that I cannot remove, most likely,
there was a configuration error in the first place: common practice
tells that you should execute user code under user permissions, not as
www-data.
I'm sure
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
We now end with an alleged complete solution to a problem which doesn't
seem to exist, or is at least vastly overblown (the idea that having pyc
files along their source counterparts is a nuisance doesn't seem to be a
common grief against Python).
I would really recommend reexamining it,
Nick Coghlan wrote:
http://docs.python.org/library/decimal.html#decimal.Inexact
(Part of the thread context rather than the individual decimal values,
but if you use it properly it tells you whenever an inexact operation
has occurred in the current thread)
My problem was that the statement
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
Greg Ewing greg.ewing at canterbury.ac.nz writes:
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 problem is that you can't delete
Antoine Pitrou wrote:
Oh, and by the way, there can be a race condition between __pycache__
creation and deletion (if it fails the test)
You can check whether the directory would be created with
the right user beforehand, and if not, don't create one
at all.
To exploit a race condition there,
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
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.
--
Greg
On 22Mar2010 09:56, Barry Warsaw ba...@python.org wrote:
| I have a pretty good start on PEP 3147 implementation [1], but I've
| encountered a situation that I'd like to get some feedback on. Here's the
| test case illustrating the problem. From test_import.py:
|
| def
On 23Mar2010 11:40, I wrote:
| | * Raise an exception or refuse to create __pycache__ if it's not writable
| | (again, by whom?)
|
| -3
| Bleah. My python program won't run because an obscure (to the user)
| directory had unusual permissions?
Clarification: I'm -3 on the exception. Silent
Barry Warsaw wrote:
On Mar 22, 2010, at 02:02 PM, Ron Adam wrote:
If I understand correctly, we would have the current mode as the default, and
can trigger __pycache__ behavior simply by manually creating a __pycache__
directory and deleting any byte-code files in the module/program
Greg Ewing greg.ewing at canterbury.ac.nz writes:
Antoine Pitrou wrote:
Having the Web server execute ad hoc system
administration code is far from elegant and user-friendly.
With the right piece of code, you could create yourself
a setuid-apache shell and solve this problem once and
Guido van Rossum wrote:
On Mon, Mar 22, 2010 at 12:20 PM, Barry Warsaw ba...@python.org wrote:
On Mar 22, 2010, at 02:02 PM, Ron Adam wrote:
If I understand correctly, we would have the current mode as the default, and
can trigger __pycache__ behavior simply by manually creating a
Antoine Pitrou solip...@pitrou.net writes:
Barry Warsaw barry at python.org writes:
When Python is being installed, either by a from-source 'make
install' or by the distro packager, then you'd expect the umask not
to be insane. In the latter case, it's a bug and in the former case
you
On 23.03.2010 02:28, Ben Finney wrote:
Antoine Pitrousolip...@pitrou.net writes:
Barry Warsawbarryat python.org writes:
When Python is being installed, either by a from-source 'make
install' or by the distro packager, then you'd expect the umask not
to be insane. In the latter case, it's
64 matches
Mail list logo
