On 6/25/06, Frank Wierzbicki <[EMAIL PROTECTED]> wrote:
> Sorry for the untrimmed conversation, but I've cc'ed jython-dev, my
> comments are at the bottom.
>
> On 6/12/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 6/12/06, Samuele Pedroni <[EMAIL PROTECTED]> wrote:
> > > Fabio Zadrozny wro
On Wednesday 05 July 2006 18:12, Guido van Rossum wrote:
> I'm asked
> occasionally what the status of Jython is; people point out that
> the last release was 2.1 many years ago and the website has no news
> since early 2005; thy're afraid that Jython is dying and that it's
> not a viable choice fo
On 7/5/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 05:49 AM 7/5/2006 +0200, Guido van Rossum wrote:
> >>* Alternate spelling of outer names when binding (e.g. ".x = whatever" to
> >>bind an outer x)
> >
> >We looked at and rejected "globals.x = whatever". I think the same
> >reasoning applie
On 7/5/06, Anthony Baxter <[EMAIL PROTECTED]> wrote:
> On Wednesday 05 July 2006 18:12, Guido van Rossum wrote:
> > I'm asked
> > occasionally what the status of Jython is; people point out that
> > the last release was 2.1 many years ago and the website has no news
> > since early 2005; thy're afr
On Wednesday 05 July 2006 18:21, Guido van Rossum wrote:
> Would this also use ..num to refer to num in an outer scope two
> levels removed?
Ew!
I don't want to even think about debugging
...x
vs
x
Anthony
--
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy c
Sorry, I should have added a ... :-)
On 7/5/06, Anthony Baxter <[EMAIL PROTECTED]> wrote:
> On Wednesday 05 July 2006 18:21, Guido van Rossum wrote:
> > Would this also use ..num to refer to num in an outer scope two
> > levels removed?
>
> Ew!
>
> I don't want to even think about debugging
>
>
Guido van Rossum wrote:
> On 7/5/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>> At 12:18 AM 7/5/2006 +0200, Guido van Rossum wrote:
>> >I don't see anything else that's attractive. The realistic options are:
>> >
>> >1. do nothing
>> >2. extend global's meaning
>> >3. add outer keyword
>>
>> Did
Guido van Rossum wrote:
> Would this also use ..num to refer to num in an outer scope two levels
> removed?
I realize this was a wink, but it is a valid problem with the
"dot"-proposal.
def foo(n):
def bar(n):
def baz():
return .n
So, which 'n' outer 'n' is being referenced? See
Guido van Rossum <[EMAIL PROTECTED]> wrote:
> 1. do nothing
> 2. extend global's meaning
> 3. add outer keyword
2.5. extend global syntax to cover both [really global] and [innermost
matching scope].
eg.
global x, y outer # trailing non-keyword
global in x, y # re-use keyword
n
Guido van Rossum wrote:
> On 7/5/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > Did you also consider and reject:
> >
> > * Alternate binding operators (e.g. ":=", ".=", etc.)
>
> Brr.
That's too bad :(
I still find a rebinding operator (":=" being my favorite) much, *much*
more appealing th
On 7/5/06, Just van Rossum <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > On 7/5/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > > Did you also consider and reject:
> > >
> > > * Alternate binding operators (e.g. ":=", ".=", etc.)
> >
> > Brr.
>
> That's too bad :(
>
> I still find a
2006/7/5, Just van Rossum <[EMAIL PROTECTED]>:
> Guido van Rossum wrote:
>
> > On 7/5/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > > Did you also consider and reject:
> > >
> > > * Alternate binding operators (e.g. ":=", ".=", etc.)
> >
> > Brr.
>
> That's too bad :(
>
> I still find a rebindi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
PCTotD (pre-coffee thought of the day):
On Jul 5, 2006, at 6:17 AM, Marek "Baczek" Baczyński wrote:
> 2006/7/5, Just van Rossum <[EMAIL PROTECTED]>:
>> Guido van Rossum wrote:
>>
>>> On 7/5/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
Did you a
Guido van Rossum wrote:
> Hallo broer! :-)
Yo :)
> I wonder what this should mean then:
>
> def outer():
> def inner():
> x := 1
>
> What is x's scope?
UnboundVariableError: variable 'x' referenced before assignment
Or a SyntaxError if the compiler can detect it.
> Also, a := operator
I know this is very similar to the "global.x =" syntax, which
was already shot down?, but wouldn't allowing access to a
functions locals from within, by prefixing the name, be a good
way to disambiguate what happens (instead of any operator to
indicate outer scope, like .x = 3 or the like)? I guess
Marek "Baczek" Baczyñski wrote:
> I suggest <- as an assignment operator instead of := - it's used in
> OCaml and it looks *very* different, yet still makes sense.
Except it's currently valid Python syntax:
>>> x = 0
>>> x <- 42
False
>>>
Just
__
Barry> Clearly we need the "as if in" operator:
Why not be more direct?
x = 0
def foo():
x = 1
def bar():
x = 2
def baz():
x in foo = 3
x in global += 1
By naming the function in which the binding is to occur you avoid
On 5 jul 2006, at 11.40, Scott Dial wrote:
> Guido van Rossum wrote:
>> Would this also use ..num to refer to num in an outer scope two
>> levels removed?
>
> I realize this was a wink, but it is a valid problem with the
> "dot"-proposal.
>
> def foo(n):
>def bar(n):
> def baz():
>
Simon Percivall wrote:
> On 5 jul 2006, at 11.40, Scott Dial wrote:
> > Guido van Rossum wrote:
> >> Would this also use ..num to refer to num in an outer scope two
> >> levels removed?
> >
> > I realize this was a wink, but it is a valid problem with the
> > "dot"-proposal.
> >
> > def foo(n):
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 5, 2006, at 9:39 AM, [EMAIL PROTECTED] wrote:
>
> Barry> Clearly we need the "as if in" operator:
>
> Why not be more direct?
Sure, why not? :)
Then we can reserve the "as if" operator for those things that Guido
has rejected, but that
Greetings all,I have attached a patch for commands.py to provide a callback ability. Example use:-import commandscmd = 'top -b -n2'def fancy(out):
print 'GOT(%s)' % out.strip()commands.cb = fancy(s,o) = commands.getstatusoutput(cmd)print 'OUTPUT (%s)' % o---
Brad Doctor wrote:
> I am not sure if this is the proper forum or means to submit something
> like this, so please forgive me and advise accordingly if I am in error.
to make sure that they don't just disappear under a zillion other mails,
patches should be submitted to the patch tracker:
Cool, thank you Fredrik -- going there now.-bradOn 7/5/06, Fredrik Lundh <[EMAIL PROTECTED]
> wrote:Brad Doctor wrote:> I am not sure if this is the proper forum or means to submit something
> like this, so please forgive me and advise accordingly if I am in error.to make sure that they don't just
Since commands.getstatusoutput() is such a trivial wrapper around
os.popen(), why bother patching commands.py?
On 7/5/06, Brad Doctor <[EMAIL PROTECTED]> wrote:
> Greetings all,
>
> I have attached a patch for commands.py to provide a callback ability.
> Example use:
>
> --
Because it is a great way to consistently use popen(). Rather than write something specific each time, our site/company prefers to use commands to keep it all consistent.-brad
On 7/5/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
Since commands.getstatusoutput() is such a trivial wrapper aroundos
> In that case, why not post a news item saying this? The website is
> probably the first place people look...
>
I think any news other than "here is the beta -- follow this link to
download it" would be kind of a waste at this point. And that will
come when I finish __slots__, subclassable "type"
Hm. It sounds like your company would be better off developing a
library of handy tools that it uses over and over, instead of on the
one hand using only standard library, and then if the standard library
doesn't provide the feature you need, proposing a patch.
I wouldn't be so critical if I thoug
2006/7/4, Guido van Rossum <[EMAIL PROTECTED]>:
> > This affect all the sockets.
>
> So, assuming your app is single-threaded, set the timeout, call
> urlopen(), and reset the timeout to None.
No, it's multithreaded, :D
> > And I hit the problem when servicing
> > information with a web service
At 10:21 AM 7/5/2006 +0200, Guido van Rossum wrote:
>Thanks for bringing this up. I'm not sure what I think of it yet. One
>problem I see is that there might end up being two ways to reference
>variables in outer scopes: .num if you plan to assign to it, or just
>num if you only reference it. I fin
OK, you've convinced me. Now where's that SF patch you were promising? :-)
--Guido
On 7/5/06, Facundo Batista <[EMAIL PROTECTED]> wrote:
> 2006/7/4, Guido van Rossum <[EMAIL PROTECTED]>:
>
> > > This affect all the sockets.
> >
> > So, assuming your app is single-threaded, set the timeout, call
>
At 05:40 AM 7/5/2006 -0400, Scott Dial wrote:
>Guido van Rossum wrote:
> > Would this also use ..num to refer to num in an outer scope two levels
> removed?
>
>I realize this was a wink, but it is a valid problem with the
>"dot"-proposal.
Actually, it isn't. :) See below.
>def foo(n):
>de
On 7/5/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> By the way, an interesting thought for Py3K is that you could maybe use
> this syntax to do away with explicit 'self', if you consider the class'
> namespace to be part of a function's closure.
Sorry, but now I am *definitely* -1.
--
--Guido
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?).
The thread pretty much stopped there
What about doing it with a per-thread-timeout in TLS (overriding the
global one if a thread does have it set in its TLS)? Not as clean,
but perhaps far easier to implement than patching dozens of
modules/functions/classes to provide timeout= options everywhere...
Alex
On 7/5/06, Guido van Ross
Guido> OK, you've convinced me. Now where's that SF patch you were
Guido> promising? :-)
A starting point is probably the patch Georg referred to a couple days ago:
Georg> There was one patch that did this: http://python.org/sf/723312.
Alas, it's assigned to me and I let it get so s
Frank> That said, I still regard Samuele Pedroni as the ultimate
Frank> authority on Jython and give him pretty much full veto power. He
Frank> fortunately continues to watch the checkins and prods me when I
Frank> go in the wrong direction.
Does that make Samele the DBPV (Dictat
In Italian that would be DBAV (Dittatore benevolo a vita)...;-)
Alex
On 7/5/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Frank> That said, I still regard Samuele Pedroni as the ultimate
> Frank> authority on Jython and give him pretty much full veto power. He
> Frank> fortu
On 7/5/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Frank> That said, I still regard Samuele Pedroni as the ultimate
> Frank> authority on Jython and give him pretty much full veto power. He
> Frank> fortunately continues to watch the checkins and prods me when I
> Frank> g
Guido writes:
[discussion of how to fix the can't-bind-outer-scope-vars wart]
> I think we have to continue to search for a solution that extends the
> idea of global declarations.
>
> I've proposed extending its meaning to refer to the nearest outer
> scope where the variable is set; if there i
Skip> Does that make Samele the DBPV (Dictator benevolo per vita)? ;-)
Alex> In Italian that would be DBAV (Dittatore benevolo a vita)...;-)
Damn Google Translator. File a bug report for me please Alex (or Guido or
Jeremy or Neal or ...). ;-)
Skip
__
On 7/5/06, Michael Chermside <[EMAIL PROTECTED]> wrote:
> Guido writes:
>[discussion of how to fix the can't-bind-outer-scope-vars wart]
> > I think we have to continue to search for a solution that extends the
> > idea of global declarations.
> >
> > I've proposed extending its meaning to refe
On 7/5/06, Frank Wierzbicki <[EMAIL PROTECTED]> wrote:
> On 7/5/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> > Frank> That said, I still regard Samuele Pedroni as the ultimate
> > Frank> authority on Jython and give him pretty much full veto power. He
> > Frank> fortunately c
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.
>
> def counter(num):
> def inc():
>
Phillip Eby writes:
> The big problem that comes to mind with that idea is that it makes
> it impossible to have argument names that are the same as attribute
> names, unless the 'whee'/'.whee' prohibition were relaxed. :( But
> it's an intriguing thought, nonetheless.
My three-year-old ha
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 other native speakers who side wit
Alex Martelli <[EMAIL PROTECTED]> wrote:
> What about doing it with a per-thread-timeout in TLS (overriding the
> global one if a thread does have it set in its TLS)? Not as clean,
> but perhaps far easier to implement than patching dozens of
> modules/functions/classes to provide timeout= opt
On 7/4/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
Hi Brett,Here are some comments on the description of the restricted executionmodel that you posted.> When referring to the state of an interpreter, it is either "trusted" or> "untrusted". A trusted interpreter has no restrictions imposed upon any
I have created a branch in svn off of HEAD for holding the sandboxing
work. It's called bcannon-sandboxing and I have checked in the design
doc in the root as sandboxing_design_doc.txt . You can keep an eye on
the checkout message for incremental changes, but I will email the list
once I have gon
Ka-Ping Yee writes:
> If you mean getting from a trusted interpreter to an untrusted
> interpreter -- then how is a resource going to travel between
> interpreters?
Brett Cannon responds:
> Beats me, but I am always scared of Armin and Samuele. =)
Okay, those two scare me also, but I would still
In response to Ka-Ping's comments on the subject of "Resource Hiding"
vs "Resource Crippling", Brett says:
> It seems that your criticisms are aimed at resource crippling
> being a "plug holes as needed but if you foul up you are screwed"
> with resource hiding being more "fix the fundamental issu
On 7/5/06, Michael Chermside <[EMAIL PROTECTED]> wrote:
Ka-Ping Yee writes:> If you mean getting from a trusted interpreter to an untrusted> interpreter -- then how is a resource going to travel between> interpreters?Brett Cannon responds:> Beats me, but I am always scared of Armin and Samuele. =)
On 7/5/06, Michael Chermside <[EMAIL PROTECTED]> wrote:
In response to Ka-Ping's comments on the subject of "Resource Hiding"vs "Resource Crippling", Brett says:> It seems that your criticisms are aimed at resource crippling> being a "plug holes as needed but if you foul up you are screwed"
> with
To make sure I don't unfairly block out capabilities as a complete security model instead of just crippling 'file's constructor (I do like capabilities and think it is a good model, really!), let's discuss how one can get to the 'file' type without importing any extension modules (that can be prote
Marek "Baczek" Baczyński wrote:
> I suggest <- as an assignment operator instead of := - it's used in
> OCaml and it looks *very* different, yet still makes sense.
But assigning to an outer scope isn't *very* different,
it's only slightly different.
--
"And now for something slightly different..
Simon Percivall wrote:
> def foo():
> def bar():
> foo.x = 3
That already had a different meaning - it assigns
to an attribute of the function object created by
executing def foo().
--
Greg
___
Python-Dev mailing list
Python-Dev@python.or
[EMAIL PROTECTED] wrote:
> By naming the function in which the binding is to occur you avoid problems
> of someone coming along and adding or deleting functions between the
> assignment (in baz) and the target of the assignment (x in foo) but then
> forgetting to increment or decrement the counter
Michael Chermside wrote:
> That leaves the other problem: auxiliary means of accessing
> objects. There are things like gc.get_objects(). In the special
> case of file, which is a type that's also dangerous, there are
> tricks like "object().__class__.__subclasses__()".
My approach to that would
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 open
files. Then it would be harmless for code to have
access to the file class.
--
Greg
_
On 7/5/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
Michael Chermside wrote:> That leaves the other problem: auxiliary means of accessing> objects. There are things like gc.get_objects(). In the special> case of file, which is a type that's also dangerous, there are
> tricks like "object().__class__._
So there's 3 choices here:
a) revert the importwarning entirely
b) make it suppressed by default
c) more complicated code in import.c to only emit the warning if the
import fails.
After a bit of a chat with Neal, I think the best combination of
prudence and functionality is (b). (a) also works
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'd really like to finish this, because having PEP 328 and 338
> not playing well together is a wart that's quite visible to end
>
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 somewhat;-).
Ok, former third-pa
At 01:24 PM 7/6/2006 +1000, Anthony Baxter wrote:
>This means Google can just turn it on in sitecustomize.py and Guido
>can avoid the hordes of peasants with pitchforks and burning torches.
Is that really true? It seems to me that Guido indicated a
sitecustomize-solution wasn't possible, in whic
In import.c starting around line 1210 (I removed a bunch of code that
doesn't matter for the problem):
if (PyUnicode_Check(v)) {
copy = PyUnicode_Encode(PyUnicode_AS_UNICODE(v),
PyUnicode_GET_SIZE(v),
Py_FileSystemDefaultEncod
[Neal Norwitz]
> In import.c starting around line 1210 (I removed a bunch of code that
> doesn't matter for the problem):
>
> if (PyUnicode_Check(v)) {
> copy = PyUnicode_Encode(PyUnicode_AS_UNICODE(v),
> PyUnicode_GET_SIZE(v),
On 7/5/06, Tim Peters <[EMAIL PROTECTED]> wrote:
>
> > Then later on we do PyString_GET_SIZE and PyString_AS_STRING. That doesn't
> > work, does it? What am I missing?
>
> The conceptual type of the object returned by PyUnicode_Encode().
Phew, I sure am glad I was missing that. :-)
I saw as th
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
> >
> Would this also use
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 versions of the
>> restrictions would be im
+1 on nonlocal.
I think that the := operator is also in case (b), but as I don't like
it I'm find with not mentioning it. :-)
Could someone write a PEP for this? Doesn't have to be very long but
I'd like it to summarize the main options proposed and discuss them,
like I did for the switch PEP. It
Brett Cannon wrote:
> Can anyone think of any other way to gain access to 'file' without
> importing a module?
In principle, it might be possible to find file in the func_defaults
or func_globals of some function, which might be defined as
orig_file = file
def file(...):
...
I couldn't find
On 7/6/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 01:24 PM 7/6/2006 +1000, Anthony Baxter wrote:
> >This means Google can just turn it on in sitecustomize.py and Guido
> >can avoid the hordes of peasants with pitchforks and burning torches.
>
> Is that really true? It seems to me that Guid
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 starting to lean towards trusted and sandboxed.
It
[Neal]
>>> Then later on we do PyString_GET_SIZE and PyString_AS_STRING. That doesn't
>>> work, does it? What am I missing?
[Tim]
>> The conceptual type of the object returned by PyUnicode_Encode().
[Neal]
> Phew, I sure am glad I was missing that. :-)
>
> I saw as the first line in PyUnicode_
After reading the messages on this thread 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.
For example, here are a few things Brett mentioned:
> Right. I am thinking more of an
74 matches
Mail list logo