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
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
Pyt
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
> ja
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
>
On 6/30/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> >
> >There are at least 6 bugs that really, really need to be fixed before
> >release. Several of these are AST bugs. Jeremy knows about them and
> >plans to fix them once he's back from vacation. Anyone else wanna
> >help out? One is
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
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 returns the list of attributes of the object.
> >
> > rationale:
> > * remove deprecated __methods__, etc.
> > * sym
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
Python-
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
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
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
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
>
Martin v. Löwis schrieb:
> 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
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) h
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 i
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 o
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 t
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 ac
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
+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 t
On 7/7/06, Just van Rossum <[EMAIL PROTECTED]> wrote:
> Why couldn't at least augmented assignment be implicitly rebinding?
Well, personally I'm for allowing full rebinding semantics but only
when a 'global' (or 'nonlocal') statement is used first. Making
augmented assignment automatically imply '
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 th
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' w
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
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 pre
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 i
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 regres
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 ine
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 p
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 ca
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 aroun
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. se
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
>>
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 arbi
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 prude
41 matches
Mail list logo
