On 23.03.2010 02:28, Ben Finney wrote:
Antoine Pitrou writes:
Barry Warsaw 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 ca
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", i
Antoine Pitrou writes:
> Barry Warsaw 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 y
Guido van Rossum wrote:
On Mon, Mar 22, 2010 at 12:20 PM, 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 d
Greg Ewing 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 for
>
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 directory
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 for
all. :-)
--
Greg
__
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 failu
On 22Mar2010 09:56, Barry Warsaw 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 test_writable_directory(self):
|
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
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 t
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,
Greg Ewing 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 the __py
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 mechani
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 "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 i
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 Fracti
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 sur
Raymond Hettinger wrote:
> * The coercion logic for comparisons won't match the
> coercion logic for arithmetic operations. The former
> strives to be exact and to be consistent with hashing
> while the latter goes in the opposite direction.
Although Guido pointed out that float/long comparisons
>> 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 rem
Martin v. Löwis v.loewis.de> writes:
>
> Antoine Pitrou wrote:
> > Martin v. Löwis 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 machi
On Mon, 22 Mar 2010 18:15:01 -, Antoine Pitrou wrote:
> Isaac Morland 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).
> >
On Mon, Mar 22, 2010 at 06:56, Barry Warsaw 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 test_writable_directory(self)
Antoine Pitrou wrote:
> Martin v. Löwis 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
Martin v. Löwis 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 tha
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 los
On Mon, Mar 22, 2010 at 8:44 PM, Guido van Rossum wrote:
> On Mon, Mar 22, 2010 at 12:33 PM, Raymond Hettinger
> 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 a
On Mon, Mar 22, 2010 at 12:45 PM, Mark Dickinson wrote:
> On Mon, Mar 22, 2010 at 8:33 PM, Raymond Hettinger
> 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
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
On Mon, Mar 22, 2010 at 8:33 PM, Raymond Hettinger
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 as a fraction".
>
>
On Mon, Mar 22, 2010 at 12:33 PM, Raymond Hettinger
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 as a fraction".
>
>
On 22 March 2010 19:32, Mark Dickinson 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 means that the
On Mon, Mar 22, 2010 at 12:20 PM, 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-cod
Barry Warsaw 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 rein
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
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 i
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 --p
On Mar 22, 2010, at 02:30 PM, Antoine Pitrou wrote:
>Barry Warsaw 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 um
Pierre B. hotmail.com> writes:
>
> 4. Since the repeating pattern is present at least twice at the end,
> one can augment the precision of the conversion by detecting the
> repetition and adding more. This detection is trivial.
Wrong of me. This point is acutally invalid, since it is i
On Mon, Mar 22, 2010 at 8:02 PM, Pierre B. 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 at least provide a
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 i
On Mon, Mar 22, 2010 at 11:36 AM, Raymond Hettinger
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 sure this follows; Fra
Raymond Hettinger 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 implementation, is
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:
float(some_deci
On Mon, Mar 22, 2010 at 7:00 PM, Raymond Hettinger
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.
>
>
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.
I've been following the discussion only passiv
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
On Mon, Mar 22, 2010 at 11:00 AM, Raymond Hettinger
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.
>
>
Antoine Pitrou wrote:
Isaac Morland 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 ti
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 implementation, is there a way to avoid the double rounding
in
On Mon, Mar 22, 2010 at 10:26 AM, Mark Dickinson wrote:
> On Mon, Mar 22, 2010 at 5:56 PM, Raymond Hettinger
> 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
On Mon, Mar 22, 2010 at 12:26, Mark Dickinson wrote:
> I don't want to let the abstractions of the numeric tower get in the
> way of the practicalities: we should modify the abstractions if
> necessary! In particular, it's not clear to me that all numeric types
> have to be comparable with each
On Mar 22, 2010, at 11:26 AM, Mark Dickinson wrote:
> On Mon, Mar 22, 2010 at 5:56 PM, Raymond Hettinger
> 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
On Mon, Mar 22, 2010 at 5:56 PM, Raymond Hettinger
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 about this one (as
> op
On Mon, Mar 22, 2010 at 10:22 AM, Alexander Belopolsky
wrote:
> On Mon, Mar 22, 2010 at 1:56 PM, Raymond Hettinger
> 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
>>
On Mon, Mar 22, 2010 at 1:56 PM, Raymond Hettinger
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 about this one (as
> op
Isaac Morland 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 sour
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 ?
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
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
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 fo
On Mon, Mar 22, 2010 at 8:39 AM, Raymond Hettinger
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 do the comparison exactly (
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
> 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 t
> 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 wri
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 t
Barry Warsaw 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 igno
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 writabl
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 Frac
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
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 pre
On Sun, Mar 21, 2010 at 10:50 PM, Greg Ewing
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 clarify here. I've bee
72 matches
Mail list logo
