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 applies here.
I thought the 'globals.x' proposal required that 'x' always be
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 wrote:
Python
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 applies here.
I
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 afraid that
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
Sorry, I should have added a wink... :-)
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
...x
vs
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 you also consider and
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? Seems
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
not
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 than any of the
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 rebinding operator (:= being
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 rebinding operator (:= being my
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 allows
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():
return .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 we sneak
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)' %
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
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, and
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
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 find
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
urlopen(),
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):
def bar(n):
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 van
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. I
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
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
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 (Dictator
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 fortunately
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 go in the
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 refer to the
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 continues to
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():
.num
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 has
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 with
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= options
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 gone
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 issues and
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.=)
Okay,
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
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.org
[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 counters
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 be to
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
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-party
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 which
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),
[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 the first
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 ..num to refer to
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 immediately
+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.
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 Guido
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 can be risky to
[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_Encode
68 matches
Mail list logo
