Re: [Python-Dev] Time-out in URL Open
[EMAIL PROTECTED] wrote: Facundo I need a timeout in urlopen, just to be able to make: urllib2.urlopen(http://no.host.org;, timeout=2) Facundo This is actually not possible, but I'll make it work. Facundo I want to know, please, if this is useful in general, for me to Facundo post a patch in SF. As others have posted, yes, it would be useful for 2.6. However, you should consider how that might be applied to the other Internet service modules (ftplib, telnetlib, urllib, etc). There was one patch that did this: http://python.org/sf/723312. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Explicit Lexical Scoping (pre-PEP?)
This is sort of a re-do of an earlier proposal which seems to have gotten lost in the shuffle of the larger debate. 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. Definitions: Implicit scoping is what we have now - a variable is defined within a scope implicitly by assignment. More specifically, when a name is assigned, the name is defined at the innermost function-level scope from where the assignment took place. Explicit scoping is where the programmer explicitly specifies which scope the variable should be defined in. Unlike implicit scoping, assignments to a named variable do not automatically redefine that variable within the current scope. Syntax: Borrowing from Perl, the keyword 'my' is used to declare an explicitly scoped variable: def f1(): my x = 1 def f2(): x = 2 # Does not create a new x In the above example, the statement 'my x = 1' declares that the scope of the variable 'x' is the outer function f1. Any assignment to x will modify the existing x, rather than creating a new definition. Note that the 'my' prefix can be combined with an assignment operation. It is anticipated that the 'my' prefix will be used quite frequently (and encouraged), so it makes sense to cut down on the number of statements by combining declaration and assignment. Explicitly scoped variables can also be declared at the module level: my x = 1 def f1(): x = 2 # Modifies the global X Declaring a module-level variable with an explicit scope eliminates the need for a 'global' statement for that variable. Nested Scopes: Each occurance of the keyword 'my' creates a new scope which hides any outer definitions of the name. So for example: my x = 1 def f1(): my x = 2 # This is a different 'x' than the global def f2(): x = 3 # This is the 'x' defined within f1() Interaction between explicit scoping and globals: The 'global' statement, when used with explicitly scoped variables, means exactly the same as it does with implicitly scoped variables: It allows access to the outermost scope, overriding any intermediate definitions in surrounding scopes: x = 1 def f1(): my x = 2 def f2(): global x x = 3 # This is the module-level 'x' Explicit scoping and code block structure: Implicitly scoped variables are always defined at the nearest enclosing function scope, even if they are created within a code block. It might be worth considering allowing explicitly scoped variables to be defined within other scopes. For example, we might choose to allow explicit scope declarations to be limited to the current suite: def f1(): for x in range(0,10): my y = x*x # A new definition of y for each iteration Note that this is a speculation only, and not a core part of the proposal (so please don't reject the proposal on this one point.) Formal definition: When a value is assigned to a local variable name, the rules for determining which scope the variable will be defined in are as follows: 1) Starting with the current (innermost) scope, examine all of the currently active scopes: 1a) If the current scope contains a 'global' statement for the given name, then set the result scope to the outermost (module-level) scope. 1b) If the current scope contains a 'my' statement for the given name, then set the result scope to the scope in which the 'my' statement occurred. 2) Otherwise, continue until we run out of scopes. If neither a 'global' or 'my' declaration was discovered, then use the innermost scope as the result scope. How is this different from 'outer'? The explicit scope proposal requires that the scope be specified at the place where the variable is *defined* as opposed to where it is *used*. This definition is inherited by all inner scopes. This allows a finer degree of control, for less typing, than the 'outer' proposal. With explicit scoping, there is no confusion as to which scope is being considered; And explicit scoping allows a single declaration of a variable to be shared by many different inner scopes, which would otherwise require a separate 'outer' statement for each one. Explicit scoping and static analysis: It should be easier to do static analysis of code with explicit scoping, since you always know what scope a variable is defined in (as opposed to implicit scoping, where a variable may switch from global to local as a result of an assignment.) Note that this implies that the creation of the scope does not occur at the time of the assignment, but rather at the time the function is entered. Thus: x = 1 def f1(): print x # Error, unassigned value my x = 2 In the above example, even though the 'my' statement occurs after the
Re: [Python-Dev] doc for new restricted execution design for Python
Hi Brett,
Here are some comments on the description of the restricted execution
model 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
resource. An untrusted interpreter has at least one, possibly more, resource
with a restriction placed upon it.
In response to Guido's comment about confusing the words trusted and
untrusted, how about empowered and restricted?
When the Interpreter Is Embedded
Single Untrusted Interpreter
This use case is when an application embeds the interpreter and never has more
than one interpreter running.
The main security issue to watch out for is not having default abilities be
provided to the interpreter by accident.
I'd rather rephrase this in the opposite direction. The onus shouldn't
be on the application to hunt down each possible dangerous authority and
deactivate them all one by one. The main security issue is to let the
application choose which abilities it wants the restricted interpreter
to have, and then ensure that the restricted interpreter gets only those
abilities.
Multiple Untrusted Interpreters
---
When multiple interpreters, all untrusted at varying levels, need to be
running within a single application. This is the key use case that this
proposed design is targetted for.
On top of the security issues from a single untrusted interpreter,
there is one additional worry. Resources cannot end up being leaked
into other interpreters where they are given escalated rights.
What is your model here for communication between interpreters? If two
interpreters can communicate, any attempt to prevent leakage of
resources is meaningless. When you say leaked into other interpreters
are you talking about a Python object leaking or something else at a
lower level?
Suppose for example that the application wants to embed two interpreters,
P and Q, and that the application wants P to be able to write files but
Q to be restricted against writing files. When you say leaked above,
that suggests to me that you want to prevent something like
# code running in P
import spam
f = open('/home/doofus/.ssh/authorized_keys', 'a')
spam.f = f
# code running in Q
import spam
spam.f.write('blargh')
The above example supposes that P and Q can communicate through a
shared module, spam, where they can pass Python objects.
But notice that even if you prevent them from passing Python objects
like open files, any form of communication is sufficient to leak
resources:
# code running in P
def add_key(key):
f = open('/home/doofus/.ssh/authorized_keys', 'a')
f.write(key + '\n')
f.close()
import socket
s = socket.socket()
s.bind(('', ))
s.listen(1)
ns, addr = s.accept()
add_key(ns.recv(100))
# code running in Q
import webbrowser
webbrowser.open('http://localhost:/zebra')
As long as P can listen for instructions from Q, it can give Q
the power to write to the filesystem.
Filesystem
===
The most obvious facet of a filesystem to protect is reading from it.
One does not want what is stored in ``/etc/passwd`` to get out. And
one also does not want writing to the disk unless explicitly allowed
for basically the same reason; if someone can write ``/etc/passwd``
then they can set the password for the root account.
There's a big difference between modifying (or erasing) an existing file
and writing a new file (e.g. for temporary storage). If i give you a
little filesystem of your own to play in, and it starts out empty, you
can put whatever you want in it without violating my secrecy or the
integrity of my files.
I think you should be talking about this in terms of specifically
what abilities you want to be able to allow, based on examples of
real-life applications.
Physical Resources
===
Memory should be protected. It is a limited resource on the system
that can have an impact on other running programs if it is exhausted.
Being able to restrict the use of memory would help alleviate issues
from denial-of-service (DoS) attacks.
Networking
===
Networking is somewhat like the filesystem in terms of wanting similar
protections. You do not want to let untrusted code make tons of socket
connections or accept them to do possibly nefarious things (e.g., acting
as a zombie).
You also want to prevent finding out information about the network you are
connected to. This includes doing DNS resolution since that allows one
to find out what addresses your intranet has or what subnets you use.
Again, it's risky to describe only individual cases of things to
prevent. What networking abilities are safe or necessary for the
kinds of applications you have in mind? Start from nothing and
work up from
Re: [Python-Dev] 2.5 and beyond
Neal Norwitz schrieb:
I'm glad to see Anthony ratcheting down. At this point, we need to be
fixing bugs and improving doc. Maybe Anthony and I should have a
contest to see who can revert the most changes. :-)
Neal (and/or Anthony),
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;-).
I intend to do these changes, the first is a small and trivial one, but allows
a lot of flexibility:
- Remove the restriction that the argtypes attribute of foreign functions must
be ctypes types. Instead they are only required to implement a .from_param
class method. The advantage is that custom objects can be used as function
parameters. One usecase is to allow numpy arrays as function parameters
without any conversion - this change at least allows to code this in Python.
The patch is attached as from_param.patch.
The second one is more involved, and not yet complete. I can post the patch
or a link to it for review when it is implemented completely:
- Implement the __array_struct__ attribute as describes by the numpy pep at
http://numpy.scipy.org/array_interface.html. The properties needed to
implement
the __array_struct__ attribute could be calculated from a given ctypes array
type,
however, it would be more efficient to calculate them at type creation time.
This requires the StgDSictObject that holds information about the ctypes type
to grow a few fields: 'int nd' - contains the number of dimensions,
'char typekind' - a struct-like character for the item type, and
'Py_intptr_t *shape' - an array of size 'nd' containing shape information.
Thanks for investigating this,
Thomas
Index: _ctypes.c
===
RCS file: /cvsroot/ctypes/ctypes/source/_ctypes.c,v
retrieving revision 1.340
diff -u -r1.340 _ctypes.c
--- _ctypes.c 22 Jun 2006 19:21:28 - 1.340
+++ _ctypes.c 4 Jul 2006 09:56:06 -
@@ -1633,9 +1633,8 @@
for (i = 0; i nArgs; ++i) {
PyObject *tp = PyTuple_GET_ITEM(ob, i);
- StgDictObject *dict = PyType_stgdict(tp);
PyObject *cnv = PyObject_GetAttrString(tp, from_param);
- if (!dict || !cnv)
+ if (!cnv)
goto argtypes_error_1;
PyTuple_SET_ITEM(converters, i, cnv);
}
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Proposed beta 2 changes (Q for Anthony/Neal)
I've got a couple of changes ready to go for beta 2, but need a go ahead from
one of the release managers before committing either of them:
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 users. I'd rather not have
people's first encounter with the features provided by either PEP involve
discovering that they're broken.
The patch to fix this also takes care of adding a couple of paragraphs to
the tutorial about explicit relative imports (which aren't currently written
up in the main documentation). The patch is attached directly to the beta 1
bug report about the problem [1].
(Guido gave a +1 to the concept, but explicitly deferred to Anthony and
Neal as to whether or not the fix should go in for beta 2)
2. Adding an 'ignore' filter for ImportWarning at the end of warnings.py
This is a safe and easy fix to silence import warning spam for people that
don't want it. I don't believe there are any Pending Deprecation Warnings at
the moment, so -Wd at the command line would be sufficient to enable
ImportWarning for people that want to see it.
Adding the line warnings.simplefilter('default', ImportWarning) to
sitecustomize.py would be sufficient for organisations to turn the warning on
across the board if they so chose.
The reason I haven't checked this in directly is that there's no point if
Anthony and/or Neal intend to accept one of the patches that tries to make the
import machinery more intelligent about missing __init__.py files.
Cheers,
Nick.
[1] http://www.python.org/sf/1510172
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)
Talin wrote: This is sort of a re-do of an earlier proposal which seems to have gotten lost in the shuffle of the larger debate. 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. Interesting. What if for-loops implicitally used my on the iteration variable? That would solve the binding problem we were discussing and make lambdas Do The Right Thing(TM) when used in loops. -- Giovanni Bajo ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)
Borrowing from Perl, the keyword 'my' is used to declare an explicitly scoped variable: def f1(): my x = 1 def f2(): x = 2 # Does not create a new x In the above example, the statement 'my x = 1' declares that the scope of the variable 'x' is the outer function f1. Any assignment to x will modify the existing x, rather than creating a new definition. -1, for this reason: def f() x = 2 # Does this create a local variable? Today, the answer is yes. Under this proposal, you can't answer the question without inspecting the entire context in which f is defined. For that reason, I would much rather have the first assignment in a block say explicitly whether it is intended to create a local variable: def f1(): x = 1 def f2(): global x x = 2# Does not create a new x This might even be abbreviated: def f1(): x = 1 def f2(): global x = 2 # Equivalent to the last example above ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)
Please move this to the python-3000 list. Also please explain what problem you are solving before proposing a solution. I note that we are seeing quite a flurry of language change proposals. I have to recommend restraint; I *don't* want to turn the entire language upside down. That's not a comment on this particular proposal, but on the issue of too many proposals. From actual users of the language I get more complaints about the breakneck speed of Python's evolution than about the brokenness of the current language. --Guido On 7/4/06, Talin [EMAIL PROTECTED] wrote: This is sort of a re-do of an earlier proposal which seems to have gotten lost in the shuffle of the larger debate. 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. Definitions: Implicit scoping is what we have now - a variable is defined within a scope implicitly by assignment. More specifically, when a name is assigned, the name is defined at the innermost function-level scope from where the assignment took place. Explicit scoping is where the programmer explicitly specifies which scope the variable should be defined in. Unlike implicit scoping, assignments to a named variable do not automatically redefine that variable within the current scope. Syntax: Borrowing from Perl, the keyword 'my' is used to declare an explicitly scoped variable: def f1(): my x = 1 def f2(): x = 2 # Does not create a new x In the above example, the statement 'my x = 1' declares that the scope of the variable 'x' is the outer function f1. Any assignment to x will modify the existing x, rather than creating a new definition. Note that the 'my' prefix can be combined with an assignment operation. It is anticipated that the 'my' prefix will be used quite frequently (and encouraged), so it makes sense to cut down on the number of statements by combining declaration and assignment. Explicitly scoped variables can also be declared at the module level: my x = 1 def f1(): x = 2 # Modifies the global X Declaring a module-level variable with an explicit scope eliminates the need for a 'global' statement for that variable. Nested Scopes: Each occurance of the keyword 'my' creates a new scope which hides any outer definitions of the name. So for example: my x = 1 def f1(): my x = 2 # This is a different 'x' than the global def f2(): x = 3 # This is the 'x' defined within f1() Interaction between explicit scoping and globals: The 'global' statement, when used with explicitly scoped variables, means exactly the same as it does with implicitly scoped variables: It allows access to the outermost scope, overriding any intermediate definitions in surrounding scopes: x = 1 def f1(): my x = 2 def f2(): global x x = 3 # This is the module-level 'x' Explicit scoping and code block structure: Implicitly scoped variables are always defined at the nearest enclosing function scope, even if they are created within a code block. It might be worth considering allowing explicitly scoped variables to be defined within other scopes. For example, we might choose to allow explicit scope declarations to be limited to the current suite: def f1(): for x in range(0,10): my y = x*x # A new definition of y for each iteration Note that this is a speculation only, and not a core part of the proposal (so please don't reject the proposal on this one point.) Formal definition: When a value is assigned to a local variable name, the rules for determining which scope the variable will be defined in are as follows: 1) Starting with the current (innermost) scope, examine all of the currently active scopes: 1a) If the current scope contains a 'global' statement for the given name, then set the result scope to the outermost (module-level) scope. 1b) If the current scope contains a 'my' statement for the given name, then set the result scope to the scope in which the 'my' statement occurred. 2) Otherwise, continue until we run out of scopes. If neither a 'global' or 'my' declaration was discovered, then use the innermost scope as the result scope. How is this different from 'outer'? The explicit scope proposal requires that the scope be specified at the place where the variable is *defined* as opposed to where it is *used*. This definition is inherited by all inner scopes. This allows a finer degree of control, for less typing, than the 'outer' proposal. With explicit scoping, there is no confusion as to which scope is being considered; And explicit scoping allows a single declaration of a variable to be shared by many different inner scopes, which would otherwise require a separate 'outer'
Re: [Python-Dev] Time-out in URL Open
2006/7/3, Guido van Rossum [EMAIL PROTECTED]: To fake things like this, socket.setdefaulttimeout() was added, though I don't know if it actually works. Have you tried that? This affect all the sockets. And I hit the problem when servicing information with a web service (TCPServer), and I need to timeout the connection of the URLOpen *only*. Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 and beyond
Thomas Heller 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;-). I intend to do these changes, the first is a small and trivial one, but allows a lot of flexibility: [...] I'd just like to provide a bit of context for Thomas' request (disclaimer: he did NOT ask me to write this, nor did anyone else). I understand the release managers' need to be strict with the freeze, but perhaps knowing what's behind this particular change will help them make a more informed decision. Numpy (http://numpy.scipy.org/) is the new python array package for numerical computing, which has been developed at enormous effort by Travis Oliphant (with community help) over the last year, as a way to unify the old Numeric package (written by Jim Hugunin, of Jython and IronPython fame) and Numarray (written by the Hubble telescope team). The effect of numpy in the community, even in its current pre-1.0 form, has been tremendous. There is a real, pressing need in the scientific world for open source and technically superior replacements to Matlab and IDL, the propietary 800-lb gorillas of the field. Many major research institutions across the world are seriously looking at python as fulfilling this role, but the previous situation of a divided library (Numeric/numarray) was keeping a lot of people on the fence. With Travis' effort and numpy maturing towards a 1.0 release right around the time of python 2.5, a LOT of people have come out of the woodwork to contribute code, ideas, documentation, etc. There is a real sense that the combination of python2.5 (with better 64-bit and __index__ support) and numpy will provide a significant advancement for scientific computing with modern, high-level tools. In this particular community, the need to interface with low-level existing libraries is probably much more common than in other fields. There are literally millions of lines of C/C++ code for scientific work which we have to use efficiently, and this is an everyday need for us. While there are a number of tools for this (SWIG, Boost::Python, pyrex, scipy.weave,...), very recently people have discovered how useful ctypes can be for this task. One of the Google SoC projects (http://2006.planet-soc.com/blog/140) started trying to wrap libsvm with SWIG and a week of frustrated efforts led nowhere. Albert then discovered ctypes and in a few hours was up and running. This has generated a lot of interest in the numpy crowd for ctypes, and people would really, really like to see python2.5 come 'out of the box' with as solid a support as possible from ctypes for numpy array interfacing. Ultimately the decision is up to the release team, I know that. But at least with this info, I hope you can understand: 1. why this is important to this community 2. why the timing isn't ideal: it is only /very/ recently that the numpy team 'discovered' how much ctypes could truly help with a necessary (and often very unpleasant) task in the numerical/python world. Thanks for reading, f ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Time-out in URL Open
On 7/4/06, Facundo Batista [EMAIL PROTECTED] wrote: 2006/7/3, Guido van Rossum [EMAIL PROTECTED]: To fake things like this, socket.setdefaulttimeout() was added, though I don't know if it actually works. Have you tried that? This affect all the sockets. So, assuming your app is single-threaded, set the timeout, call urlopen(), and reset the timeout to None. And I hit the problem when servicing information with a web service (TCPServer), and I need to timeout the connection of the URLOpen *only*. That's not so easy even if you were to have a timeout parameter to urlopen(). You'd have to implement that peculiarity in all the layers (in this case, urllib and httplib; and possibly ftplib, gopherlib etc. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)
On 7/4/06, Talin [EMAIL PROTECTED] wrote: Guido van Rossum wrote: Also please explain what problem you are solving before proposing a solution. Actually, the problem I am trying to solve is the debate on the mailing list. That is, I listen to what people are asking for, and what disagreements they have, and then I try to provide a solution that resolves the debate. In this case, there was a lot of discussion about lexical scoping, and various people proposing solutions (such as redefining the behavior of 'global') that I thought were (a) problematic, and (b) not a lot of bang for the buck (i.e. the disruption vs. utility tradeoff was poor IMHO.) To be honest, I really have no stake in this proposal, and I don't intend to spend any time defending it other than to correct misperceptions - however, I offer it as a potential starting point for people who are interested in the whole lexical scoping issue. If someone feels that this proposal gives them what they want, then great - otherwise I'll drop it. Thanks; I appreciate the attempt. I just think that we're not quite ready for more proposals (and certainly not for radical ones). Instead, I'd like to go back to review the needs and desires first. I think the needs are actually pretty simple. Python currently doesn't allow assignment to variables in an outer non-global scope, and people have shown by their behavior that they cannot get used to this (otherwise the debate would have fizzled by now). There are two fundamentally different mechanisms seen in programming languages to control the binding of such variables. The most common approach is to require declaration of variables in the scope to which they belong. But Python doesn't do this, and I think it would be a shame if we had to start doing this now -- the objections against your proposal clearly show the problems if we try to mix this with Python's traditional assignment is declaration philosophy. The other approach is an extension of what Python already does for variables in the global scope. ABC did this too (the SHARE command, see http://homepages.cwi.nl/~steven/abc/qr.html#HOWTOs). 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 is no such scope it's an error. This will break a small number of program but probably not very many; still, it'll require a future statement or waiting until Python 3.0. The downside is that global is not a very intuitive word for this new meaning. (Maybe ABC's SHARE would have been better.) We could use a different keyword instead, e.g. 'outer'. I believe I've also seen proposals in the past that used a number to indicate how many scopes to go out; I don't like that at all. 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 Personally I think I'd vote for (2) since it doesn't require a new keyword. But that's only a slight preference over the other two. Personally it's not a burning need; by the time you start feeling the need to modify variables in an outer scope you should probably consider refactoring using an explicit class to hold the state. But I used the same argument to keep the current form of nested scopes (can we say closures? But what exactly is the closure?) out of the door and I lost that argument. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] User's complaints
On 7/4/06, Guido van Rossum [EMAIL PROTECTED] wrote: From actual users of the language I get more complaints about the breakneck speed of Python's evolution than about the brokenness of the current language. Guido, I'm really interested in your perspective here. I assume you hear far more average complaints from Joe Random User. Can you help give the rest of us an idea about the top 10 complaints/problems people have? I realize this will be subjective, that's ok. Perhaps we should try to focus our energies on some of these issues. For example, we heard grumblings about the releases coming too often. Once we went to an 18 month release schedule, there was minimal complaining. It should be fairly safe to assume this silence means people think we are doing a good job. What are the things that could be fixed that would silence the most number of user's complaints? n -- PS. One thing I tend to talk to users about is stability of the interpreter. When I talk about crashing the interpreter, the most common first reaction I get is you can crash the interpreter? How do you do that? I take that answer as a good sign. :-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5b1 Windows install
On Mon, Jun 26, 2006, Martin v. L?wis wrote: Aahz wrote: Has anyone else tried doing an admin install with compile .py files checked? It's causing my install to blow up, but I'd prefer to assume it's some weird Windows config/bug unless other people also have it, in which case I'll file an SF report. It works fine for me. One way for it to fail is if you uncompilable modules in the target directory. Currently, it invokes [TARGETDIR]python.exe -Wi [TARGETDIR]Lib\compileall.py -f -x bad_coding|badsyntax|site-packages [TARGETDIR]Lib where TARGETDIR is, well, the target directory of the installation. You could try to run this after you installed Python without pyc compilation, to see whether it succeeds. Ah-ha! I haven't actually tested this directly, but I bet I know what's going on: this isn't properly quoted and fails with TARGETDIR of C:\Program Files\Python25 because of the space. I did test to see that it works fine with C:\Python25 Shall I file a bug? Or do you want to just document this as a limitation? -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ I saw `cout' being shifted Hello world times to the left and stopped right there. --Steve Gonedes ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)
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 reject: * Alternate binding operators (e.g. :=, .=, etc.) Brr. * 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. If so, then these should probably be added to the rejected alternatives for Py3K so they don't get rehashed. Georgbot? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5b1 Windows install
Aahz wrote: Ah-ha! I haven't actually tested this directly, but I bet I know what's going on: this isn't properly quoted and fails with TARGETDIR of C:\Program Files\Python25 because of the space. I did test to see that it works fine with C:\Python25 Shall I file a bug? Or do you want to just document this as a limitation? If this is indeed the problem, it should be fixed. Before filing the bug report, please confirm that this actually is a problem. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] zlib module build failure on Mac OSX 10.4.7
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 either enhance configure or roll back my change to setup.py. I'd prefer to do the former, but if beta2 gets too close I'll just change setup.py. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
