Brett Cannon wrote:
On 7/5/06, Talin [EMAIL PROTECTED] wrote:
Transitioning from the checked to the unchecked state could only be done
via C code. So the 'file' wrapper, for example, would switch over to the
unchecked interpreter before calling the actual methods of 'file'. That
C wrapper
Brett Cannon wrote:
On 7/5/06, *Greg Ewing* [EMAIL PROTECTED]
And I would change file() so that it didn't open
files. Then it would be harmless for code to have
access to the file class.
Right, that is essentially what I proposed initially with the whole
crippling idea.
Guido van Rossum [EMAIL PROTECTED] wrote:
So, my proposal is to give up on static, accept PEP 3103 with the
following options:
- Syntax alternative 2+B (unindented cases, 'case in ...' for
multiple cases).
- Semantics option 3 (def-time freezing)
I know it's only a bikeshed issue here,
Another thing I perhaps should point out is that
I'm proposing the separation of open() and file()
for *all* code, not just restricted code. So it's
not a matter of crippling file() specially for
restricted code.
--
Greg
___
Python-Dev mailing list
Evan Simpson wrote:
I'd like to toss one more variant into the mix. If we really need to
address variables in an intermediate scope, the most explicit way
that I can think of doing so is to write (using Philip's example):
def counter(num):
scope as outer # outer is an arbitrary
[EMAIL PROTECTED] wrote:
jan-python So.. are we only thinking about implementing this outer
jan-python scope assignment because there's lots of talk about it on
jan-python the list, ...
:-)
jan-python ... or are there actually use cases that would become
jan-python
Just van Rossum wrote:
Why couldn't at least augmented assignment be implicitly rebinding? It
has been suggested before (in the context of a rebinding operator), but
I'm wondering, is this also off the table?
def counter(num):
def inc():
num += 1
Greg Ewing wrote:
Another thing I perhaps should point out is that
I'm proposing the separation of open() and file()
for *all* code, not just restricted code. So it's
not a matter of crippling file() specially for
restricted code.
What would the signature of the file constructor be in that
I just turned the subversion write access back on.
Unfortunately, I did not manage to perform the changes
I wanted (import ctypes), so I'll have to retry later
when the open issues have been clarified.
Regards,
Martin
___
Python-Dev mailing list
Ronald Oussoren schrieb:
On 20-jun-2006, at 20:50, Ronald Oussoren wrote:
On 20-jun-2006, at 20:06, Thomas Heller wrote:
Trent Mick schrieb:
Thomas and others,
Has anyone else seen failures in test_ctypes on older Mac OS X/
PowerPC?
Results are below. This is running a build of the
Martin v. Löwis wrote:
I plan to do some subversion administration
tomorrow; in order to be able to roll back changes,
I have to disable write access during these
changes.
I'm going to make a second attempt ten minutes from
now.
Regards,
Martin
___
Martin v. Löwis wrote:
Martin v. Löwis wrote:
I plan to do some subversion administration
tomorrow; in order to be able to roll back changes,
I have to disable write access during these
changes.
I'm going to make a second attempt ten minutes from
now.
I completed importing the ctypes
On 7/6/06, Talin [EMAIL PROTECTED] wrote:
Brett Cannon wrote: On 7/5/06, Talin [EMAIL PROTECTED] wrote: Transitioning from the checked to the unchecked state could only be done via C code. So the 'file' wrapper, for example, would switch over to the
unchecked interpreter before calling the actual
Kevin Jacobs [EMAIL PROTECTED] wrote:
Why not extend the interface to the locals builtin and add a __getitem__
that returns a proxy to access locals defined in other lexical scopes
via __{get/set/del}attr_:
def counter(num):
num = 1
def inc():
locals[1].num += 1
Guido van Rossum wrote:
On 7/5/06, Michael Chermside [EMAIL PROTECTED] wrote:
Guido writes:
[discussion of how to fix the can't-bind-outer-scope-vars wart]
...
Are there any other native speakers who side with Michael?
A bit OT, but why should native speakers (eg of English) have
On 7/7/06, Greg Ewing [EMAIL PROTECTED] wrote:
Brett Cannon wrote: On 7/5/06, *Greg Ewing* [EMAIL PROTECTED] And I would change file() so that it didn't open files. Then it would be harmless for code to have
access to the file class. Right, that is essentially what I proposed initially with the
On 7/7/06, Greg Ewing [EMAIL PROTECTED] wrote:
Another thing I perhaps should point out is thatI'm proposing the separation of open() and file()for *all* code, not just restricted code. So it'snot a matter of crippling file() specially forrestricted code.
Well, that's fine with me since I use
At 09:56 PM 7/6/2006 -0400, Kevin Jacobs [EMAIL PROTECTED] wrote:
Why not extend the interface to the locals builtin and add a __getitem__
that returns a proxy to access locals defined in other lexical scopes via
__{get/set/del}attr_:
def counter(num):
num = 1
def inc():
Brett Cannon wrote:
On 7/6/06, Talin [EMAIL PROTECTED] wrote:
And if we can call it for every operation, then we don't have to spend
time hunting down all of the possible loopholes and ways in which 'file'
or other restricted objects might be accessed.
Not true. You have to set this object
On 7/7/06, Talin [EMAIL PROTECTED] wrote:
Brett Cannon wrote: On 7/6/06, Talin [EMAIL PROTECTED] wrote: And if we can call it for every operation, then we don't have to spend time hunting down all of the possible loopholes and ways in which 'file'
or other restricted objects might be accessed.
On 7/7/06, Ka-Ping Yee [EMAIL PROTECTED] wrote:
I've been doing a bunch of Firefox extension programming in Javascript
and suddenly a few of the recent topics here came together in my head
in a silent kapow of thoughts. This is kind of a side note to the
security discussion, but they're all
+1 here too. This could be added easily to Python 2.6.
--Guido
On 7/7/06, Nick Coghlan [EMAIL PROTECTED] wrote:
Fred L. Drake, Jr. wrote:
On Thursday 06 July 2006 13:22, tomer filiba wrote:
my suggestion is simple -- replace this mechanism with a __dir__ -
a special method that
On 7/7/06, Brett Cannon [EMAIL PROTECTED] wrote:
I guess I am just not seeing where your approach is better than preventing
the constructor in 'file' and having open() return the 'file' object or
proxy object. With your approach 'file' would be flagged, but with the
other you just put the
On 7/7/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 7/7/06, Brett Cannon [EMAIL PROTECTED] wrote: I guess I am just not seeing where your approach is better than preventing the constructor in 'file' and having open() return the 'file' object or
proxy object.With your approach 'file' would be
On Fri, 7 Jul 2006, Guido van Rossum wrote:
On 7/7/06, Ka-Ping Yee [EMAIL PROTECTED] wrote:
I've been doing a bunch of Firefox extension programming in Javascript
and suddenly a few of the recent topics here came together in my head
in a silent kapow of thoughts. This is kind of a side
Guido Well, personally I'm for allowing full rebinding semantics but
Guido only when a 'global' (or 'nonlocal') statement is used
Guido first. Making augmented assignment automatically imply 'global'
Guido etc. seems too magical to me.
So, if I understand correctly, in the
On Jul 7, 2006, at 1:08 PM, Guido van Rossum wrote:
On 7/7/06, Ka-Ping Yee [EMAIL PROTECTED] wrote:
I've been doing a bunch of Firefox extension programming in
Javascript
and suddenly a few of the recent topics here came together in my head
in a silent kapow of thoughts. This is kind of
Neal Norwitz wrote:
The current list of serious bugs are in the PEP:
http://www.python.org/dev/peps/pep-0356/
If there are any bugs you think should be considered show stoppers,
mail them to the list and I will update the PEP.
http://www.python.org/sf/1519018
I believe this regression
Nick Coghlan wrote:
What would the signature of the file constructor be in that case?
If it's possible to call it at all, I think it would
have to take a file descriptor, or whatever the
platform's OS-level representation of an open file
is.
The other possibility is to just raise an exception
Boris Borcic wrote:
I believe that in this case native linguistic intuition made the decision...
The reason has nothing to do with language. Guido didn't
want sum() to become an attractive nuisance by *appearing*
to be an obvious way of joining a list of strings, while
actually being a very
On 7/7/06, Greg Ewing [EMAIL PROTECTED] wrote:
Nick Coghlan wrote: What would the signature of the file constructor be in that case?If it's possible to call it at all, I think it wouldhave to take a file descriptor, or whatever theplatform's OS-level representation of an open file
is.The other
Brett Cannon wrote:
Good point. C code could circumvent the bit check by doing all of the
work behind the scenes without pushing the object on the stack. But if
the check is in the C code for the object itself it is much harder to
get around.
C code can circumvent the bit check by
On 7/7/06, Nick Coghlan [EMAIL PROTECTED] wrote:
Brett Cannon wrote:Good point.C code could circumvent the bit check by doing all of the work behind the scenes without pushing the object on the stack.But if the check is in the C code for the object itself it is much harder to
get around.C code
On 7/8/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Guido Well, personally I'm for allowing full rebinding semantics but
Guido only when a 'global' (or 'nonlocal') statement is used
Guido first. Making augmented assignment automatically imply 'global'
Guido etc. seems too
Brett Cannon wrote:
On 7/7/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 7/7/06, Brett Cannon [EMAIL PROTECTED] wrote:
I guess I am just not seeing where your approach is better than
preventing
the constructor in 'file' and having open() return the 'file' object or
proxy object.
On Fri, 7 Jul 2006, Talin wrote:
While I was typing this, I did realize a drawback to poisoned objects,
which I will illustrate by the following example:
Suppose we want to grant to the sandboxed program permission to read and
write cofiguration properties. We don't want to give them
On 7/8/06, Ka-Ping Yee [EMAIL PROTECTED] wrote:
The situation you're describing here is a classic case of one
component keeping a closely held authority while using it to
provide some limited capability to some other component. This
comes up quite often when you're trying to write secure
Anthony Baxter wrote:
On Saturday 01 July 2006 12:55, Guido van Rossum wrote:
It's up to the release manager now to decide whether the pitchforks
at Google or the pitchforks in the larger Python community are
sharper. ;-)
At this point, I think removing the warning code is the prudent
38 matches
Mail list logo
