Frank Wierzbicki wrote:
> On 7/5/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
>>Hi Frank,
>>
>>Have you and/or the Jython community made up your mind about this? The
>>thread seems to have disappeared after you posted (or perhaps it
>>continued only on jython-dev, which I don't read?).
>
> T
Neal Norwitz schrieb:
> On 7/4/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
>>
>> I would like to ask about the possibility to add some improvements to ctypes
>> in Python 2.5, although the feature freeze is now in effect. Hopefully
>> former
>> third-party libraries can have the freeze relaxed s
On Jul 5, 2006, at 7:35 AM, Ronald Oussoren wrote:
On Jul 4, 2006, at 11:21 PM, Neal Norwitz wrote:
Ronald, Bob,
I know Skip found and fixed his problem, however, is this problem
likely to affect other users? Is there anything we can do to help
alleviate/diagnose this problem?
I'll eithe
Hi Brett,
On Wed, Jul 05, 2006 at 05:01:48PM -0700, Brett Cannon wrote:
> And if Armin and/or Samuele sign off that what we find is most likely (with
> "most likely" equalling 99% chance) all there is, then bonus points and I
> will *really* be convinced. =)
I don't think I can "sign off" that.
Anthony Baxter wrote:
> On Tuesday 04 July 2006 22:32, Nick Coghlan wrote:
>> 1. Finishing the __module_name__ workaround to allow relative
>> imports from the main module when using -m.
>
> I have some nervousness about this. Are there cases in the stdlib
> where this is an issue, today? Are the
Phillip J. Eby wrote:
> At 07:27 PM 7/5/2006 +0200, Guido van Rossum wrote:
>> However I still don't believe "global" has the stretchiness in its
>> meaning that you claim it has. Have you ever heard a Python programmer
>> talking about closures use the word "global variable"?
>>
>> Are there any o
Hi all,
In reference to:
http://sourceforge.net/tracker/index.php?func=detail&aid=1514451&group_id=5470&atid=105470
I wrote a patch for this "bug", but a valid point was raised by Ronald
Oussorren: this borders on being more of a "feature" than a bug fix,
although - IMHO - this fix improves c
I wrote:
> I would still rather not spread FUD.
Brett Cannon responds:
> I don't consider it FUD. Armin in an email said that he thought it
> was a losing battle to try to hide 'file' from an interpreter. That
> is what I am worried about, period. Everythign else can be
> protected through reso
Ka-Ping Yee writes:
> i'm starting to think
> that it would be good to clarify what kinds of threats we are
> trying to defend against, and specify what invariants we are
> intending to preserve.
Yes!
> So here are a couple of questions for clarification (some with my
> guesses as to their answer
Michael Chermside <[EMAIL PROTECTED]> writes:
> Phillip Eby writes:
>> I don't see a problem with requiring '.x' to be used for both
>> reading and writing of outer-scope names; it just shouldn't be
>> required for an outer-scope name that you don't rebind in the
>> current scope.
>>
>>
Ka-Ping Yee wrote:
> On Wed, 5 Jul 2006, Guido van Rossum wrote:
>> On 7/5/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>>> Using the classic nonsense example:
>>>
>>> def counter(num):
>>> def inc():
>>> .num += 1
>>> return .num
>>> return inc
>>>
So.. are we only thinking about implementing this outer scope
assignment because
there's lots of talk about it on the list, or are there actually use
cases that
would become clearer if assigning to an outer scope variable was allowed? I
tend to think that almost _any_ piece of code that could be
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> clearer if assigning to an out
Armin Rigo writes:
> I don't think I can "sign off" [on hiding the file type]. Really hiding
> Python objects is quite hard IMHO.
I agree. But we don't have to give up yet. How about instead of hiding
file, we cripple it. Completely. Modify the file type so that when
executing on a sandboxed inte
> However I still don't believe "global" has the stretchiness in its
> meaning that you claim it has. Have you ever heard a Python programmer
> talking about closures use the word "global variable"?
I guess the term I've heard most often is "free variable," but I wouldn't be
surprised if I saw the
On 7/6/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
+1 on nonlocal.I think that the := operator is also in case (b), but as I don't likeit I'm find with not mentioning it. :-)Could someone write a PEP for this? Doesn't have to be very long butI'd like it to summarize the main options proposed an
At 10:05 AM 7/6/2006 -0500, [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
On 7/5/06, Talin <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:> On 7/5/06, Michael Chermside <[EMAIL PROTECTED]> wrote:>> If you were using capabilities, you would need to ensure that>> restricted interpreters could only get the file object that they
>> were given. But then _all_ of these fancy ve
On 7/6/06, Michael Chermside <[EMAIL PROTECTED]> wrote:
I wrote:> I would still rather not spread FUD.Brett Cannon responds:> I don't consider it FUD. Armin in an email said that he thought it> was a losing battle to try to hide 'file' from an interpreter. That
> is what I am worried about, perio
On 7/5/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
On Wed, 5 Jul 2006, Brett Cannon wrote:> On 7/4/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:> > In response to Guido's comment about confusing the words "trusted" and
> > "untrusted", how about "empowered" and "restricted"?>> Maybe. I am really start
I quoted this unwritten bit of Python Zen, attributing it to Tim:
> Syntax should not look like grit on my monitor.
mwh writes:
> I think it was Anthony:
>
> http://mail.python.org/pipermail/python-dev/2005-July/054581.html
But that's not the original. Turns out, it WAS Anthony, and I had
mis
On 7/5/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:> Armin in an email said that he thought it was> a losing battle to try to hide 'file' from an interpreter.And I would change file() so that it didn't openfiles. Then it would be harmless for code to have
access to the file class.R
i'd guess this has been brought up before, but i'm not aware of it.
anyway --
by what i've gathered, today's dir() "collects" the attributes of the
object from __dict__, __methods__, __members__, and ultimately
__class__. also, if i understood correctly, __methods__ and
__members__ are deprecated.
[replying to both Ping and Michael in the same email]On 7/6/06, Michael Chermside <[EMAIL PROTECTED]> wrote:
Ka-Ping Yee writes:> i'm starting to think> that it would be good to clarify what kinds of threats we are
> trying to defend against, and specify what invariants we are> intending to preserv
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.
> * symmetry -- just like hex() calls __hex__,
On 7/6/06, Michael Chermside <[EMAIL PROTECTED]> wrote:
Armin Rigo writes:> I don't think I can "sign off" [on hiding the file type]. Really hiding> Python objects is quite hard IMHO.
I agree. But we don't have to give up yet. How about instead of hidingfile, we cripple it. Completely. Modify the
On 7/6/06, Armin Rigo <[EMAIL PROTECTED]> wrote:
Hi Brett,On Wed, Jul 05, 2006 at 05:01:48PM -0700, Brett Cannon wrote:> And if Armin and/or Samuele sign off that what we find is most likely (with> "most likely" equalling 99% chance) all there is, then bonus points and I
> will *really* be convince
Me:
> I agree. But we don't have to give up yet. How about instead of hiding
> file, we cripple it. Completely. Modify the file type so that when
> executing on a sandboxed interpreter, all of the dangerous methods
> and attributes of file throw exceptions.
Brett:
> This is basically what I propos
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.
The outage shouldn't last longer than one hour;
most likely, it will be much faster.
Regards,
Martin
___
On 7/6/06, Michael Chermside <[EMAIL PROTECTED]> wrote:
Me:> I agree. But we don't have to give up yet. How about instead of hiding> file, we cripple it. Completely. Modify the file type so that when> executing on a sandboxed interpreter, all of the dangerous methods
> and attributes of file throw
On Wed, 21 Jun 2006, Brett Cannon wrote:
> I have been working on a design doc for restricted execution of Python
> as part of my dissertation for getting Python into Firefox to replace
> JavaScript on the web.
I've been doing a bunch of Firefox extension programming in Javascript
and suddenly a f
Back at the beginning of June, the Python Software Foundation's Infrastructure committee sent out an email requesting people to help us find a replacement tracker for SourceForge (the original announcement can be found at
http://wiki.python.org/moin/CallForTrackers ). We asked that people put tes
At 05:17 PM 7/6/2006 -0500, Ka-Ping Yee wrote:
>On Wed, 21 Jun 2006, Brett Cannon wrote:
> > I have been working on a design doc for restricted execution of Python
> > as part of my dissertation for getting Python into Firefox to replace
> > JavaScript on the web.
>
>I've been doing a bunch of Fire
Talin wrote:
> I propose to create a new type of scoping rule, which I will call
> "explicit" lexical scoping, that will co-exist with the current
> "implicit" scoping rule that exists in Python today.
I'd like to toss one more variant into the mix. If we really need to
address variables in an
On Thu, 06 Jul 2006 18:28:12 +0200, Phillip J. Eby <[EMAIL PROTECTED]>
wrote:
> Here's the reason I think this keeps coming up, and why Guido's "just
> use a class" argument doesn't really address the actual problem that's
> taking place.
I agree this argument is not generally applicable in
At 01:00 AM 7/7/2006 +0200, Jan Kanis wrote:
>On Thu, 06 Jul 2006 18:28:12 +0200, Phillip J. Eby <[EMAIL PROTECTED]>
>wrote:
>
>>Here's the reason I think this keeps coming up, and why Guido's "just
>>use a class" argument doesn't really address the actual problem that's
>>taking place.
>
>I agree
On Fri, 07 Jul 2006 01:25:19 +0200, Phillip J. Eby <[EMAIL PROTECTED]>
wrote:
>
>>> - or so it feels like to the person who's experiencing it.
>>
>> Have you ever been that person, or come across such a situation?
>
> Many times. The hard thing about trying to provide use cases for this
> is
On Thu, 6 Jul 2006, Phillip J. Eby wrote:
> As much as I'd love to have the nested scope feature, I think it's only
> right to point out that the above can be rewritten as something like this
> in Python 2.5:
>
> def spam():
> local_A = do_work()
> result_1 = yield do_network
On 7/6/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> Here's the reason I think this keeps coming up, and why Guido's "just use a
> class" argument doesn't really address the actual problem that's taking place.
(And note that I've recently gone on record as doubting that argument myself.)
> When
On Jul 6, 2006, at 5:04 PM, Ka-Ping Yee wrote:
> On Thu, 6 Jul 2006, Phillip J. Eby wrote:
>> As much as I'd love to have the nested scope feature, I think it's
>> only
>> right to point out that the above can be rewritten as something
>> like this
>> in Python 2.5:
>>
>> def spam():
>>
On 7/6/06, Evan Simpson <[EMAIL PROTECTED]> wrote:
Talin wrote:> I propose to create a new type of scoping rule, which I will call> "explicit" lexical scoping, that will co-exist with the current> "implicit" scoping rule that exists in Python today.
I'd like to toss one more variant into the mix.
At 07:04 PM 7/6/2006 -0500, Ka-Ping Yee wrote:
>On Thu, 6 Jul 2006, Phillip J. Eby wrote:
> > As much as I'd love to have the nested scope feature, I think it's only
> > right to point out that the above can be rewritten as something like this
> > in Python 2.5:
> >
> > def spam():
> >
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 w
43 matches
Mail list logo
