Re: [Python-Dev] changing time.strftime() to accept 0s (was: User'scomplaints)
Anthony Baxter [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Making strftime accept 0s is fine to be checked in, since it's a regression (an understandable one, but what the hell). Once it is, someone should put a note back on the complainant's blog page. ___ 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] User's complaints
[EMAIL PROTECTED] wrote: The way I used to format dates using time.strftime does indeed no longer work. Python 2.3: import time time.strftime(%Y-%m-%d, (2005, 6, 4) + (0,)*6) '2005-06-04' Is there any specific reason you couldn't write %d-%02d-%02d % (2005, 6, 4) (i.e. not use strftime at all)? It seems strange to fake a time tuple just to use that function, in particular if the time formatting should not use any locale-specific output. I don't actually run into this problem as I've pretty much converted to use datetime in new code. I also realize that's not documented as the way it should be done, but I'm fairly certain it was common usage before the datetime module came along. Still, it is a bit annoying that the (undocumented, but I think de facto) commonly used idiom no longer works. I guess this was caused by this change: /* Checks added to make sure strftime() does not crash Python by indexing blindly into some array for a textual representation by some bad index (fixes bug #897625). No check for year since handled in gettmarg(). */ So this was changed in response to a bug report about a crash. 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] urllib.quote and unicode bug resuscitation attempt
on 12.07.2006 07:53 Martin v. Löwis said the following: Anthony Baxter wrote: The right thing to do is IRIs. For 2.5, should we at least detect that it's unicode and raise a useful error? That can certainly be done, sure. Martin That would be great. And I agree that updating urllib.quote for unicode should be part of a grand plan that updates all of urllib[2] and introduces an irilib / urischemes / uriparse module in 2.6 as Martin and John J Lee suggested. =) cheers, stefan ___ 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] User's complaints
Python 2.3: import time time.strftime(%Y-%m-%d, (2005, 6, 4) + (0,)*6) '2005-06-04' Martin Is there any specific reason you couldn't write Martin %d-%02d-%02d % (2005, 6, 4) Martin (i.e. not use strftime at all)? Sure, but that was just me being lazy typing at the interactive prompt. %Y-%m-%d is just about the only date format I can ever remember without consulting the strftime(3) man page. ;-) Suppose I had used time.strftime(%b %d, %Y, (2005, 6, 4) + (1,)*6) 'Jun 04, 2005' instead (switching to the all-ones default that still works)? Martin So this was changed in response to a bug report about a crash. Yeah, but it broke common (at the time) usage. Skip ___ 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] Long options support
Fredrik Lundh wrote:
Georg Brandl wrote:
I've just closed a bug report wishing for long option support,
pointing to a patch sitting in the patch tracker implementing
this.
Should we accept at least the very common options --help and
--version in 2.5?
Guido pronounced on this in May
Late it comes, but here is a patch for getopt.c implementing
this pronouncement. I think there's no need to wait for 2.6 with it,
or is there?
Cheers,
Georg
Index: Python/getopt.c
===
--- Python/getopt.c (Revision 50599)
+++ Python/getopt.c (Arbeitskopie)
@@ -24,6 +24,9 @@
* [EMAIL PROTECTED]
*---*/
+/* Modified to support --help and --version, as well as /? on Windows
+ * by Georg Brandl. */
+
#include stdio.h
#include string.h
@@ -43,15 +46,35 @@
if (*opt_ptr == '\0') {
- if (_PyOS_optind = argc || argv[_PyOS_optind][0] != '-' ||
- argv[_PyOS_optind][1] == '\0' /* lone dash */ )
+ if (_PyOS_optind = argc)
return -1;
+#ifdef MS_WINDOWS
+ else if (strcmp(argv[_PyOS_optind], /?) == 0) {
+ ++_PyOS_optind;
+ return 'h';
+ }
+#endif
+ else if (argv[_PyOS_optind][0] != '-' ||
+argv[_PyOS_optind][1] == '\0' /* lone dash */ )
+ return -1;
+
else if (strcmp(argv[_PyOS_optind], --) == 0) {
++_PyOS_optind;
return -1;
}
+ else if (strcmp(argv[_PyOS_optind], --help) == 0) {
+ ++_PyOS_optind;
+ return 'h';
+ }
+
+ else if (strcmp(argv[_PyOS_optind], --version) == 0) {
+ ++_PyOS_optind;
+ return 'V';
+ }
+
+
opt_ptr = argv[_PyOS_optind++][1];
}
@@ -62,7 +85,7 @@
if (_PyOS_opterr)
fprintf(stderr, Unknown option: -%c\n, option);
- return '?';
+ return '_';
}
if (*(ptr + 1) == ':') {
@@ -76,7 +99,7 @@
if (_PyOS_opterr)
fprintf(stderr,
Argument expected for the -%c option\n, option);
- return '?';
+ return '_';
}
_PyOS_optarg = argv[_PyOS_optind++];
Index: Modules/main.c
===
--- Modules/main.c (Revision 50599)
+++ Modules/main.c (Arbeitskopie)
@@ -40,7 +40,7 @@
static int orig_argc;
/* command line options */
-#define BASE_OPTS c:dEhim:OQ:StuUvVW:xX
+#define BASE_OPTS c:dEhim:OQ:StuUvVW:xX?
#ifndef RISCOS
#define PROGRAM_OPTS BASE_OPTS
@@ -62,7 +62,7 @@
-c cmd : program passed in as string (terminates option list)\n\
-d : debug output from parser (also PYTHONDEBUG=x)\n\
-E : ignore environment variables (such as PYTHONPATH)\n\
--h : print this help message and exit\n\
+-h : print this help message and exit (also --help)\n\
-i : inspect interactively after running script, (also PYTHONINSPECT=x)\n\
and force prompts, even if stdin does not appear to be a terminal\n\
;
@@ -78,7 +78,7 @@
static char *usage_3 = \
see man page for details on internal buffering relating to '-u'\n\
-v : verbose (trace import statements) (also PYTHONVERBOSE=x)\n\
--V : print the Python version number and exit\n\
+-V : print the Python version number and exit (also --version)\n\
-W arg : warning control (arg is action:message:category:module:lineno)\n\
-x : skip first line of source, allowing use of non-Unix forms of #!cmd\n\
file : program read from script file\n\
@@ -313,6 +313,7 @@
Py_UnicodeFlag++;
break;
case 'h':
+ case '?':
help++;
break;
case 'V':
___
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] Long options support
Georg Brandl wrote: Late it comes, but here is a patch for getopt.c implementing this pronouncement. I think there's no need to wait for 2.6 with it, or is there? check it in already. /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
[Python-Dev] Behavior change in subprocess.py
During my testing of Python 2.5b2, I've found something that may be worthy of discussion. I suspect that recent GC and finalization changes have altered the behavior of the Popen object in subprocess.py. I am now getting many many many finalization warnings in my code like: Exception exceptions.AttributeError: 'NoneType' object has no attribute 'append' in bound method Popen.__del__ of subprocess.Popen object at 0x2b910950 ignoredIs this a bug or a feature? Personally, I'd like to see these messages silenced, since it is being generated during interpreter shutdown. The following patch does the trick for me: --- /usr/local/lib/python2.5/subprocess.py 2006-07-11 14:11:59.0 -0400+++ subprocess.py 2006-07-12 10:17:09.0 -0400@@ -613,7 +613,7 @@ return # In case the child hasn't been waited on, check if it's done. self.poll(_deadstate=sys.maxint)- if self.returncode is None:+ if self.returncode is None and _active is not None: # Child is still running, keep us alive until we can wait on it. _active.append(self)Note that popen.py does something similar, though I am not convinced that the test is right or if it is doing something more subtle: def __del__(self): # In case the child hasn't been waited on, check if it's done. self.poll(_deadstate=sys.maxint) if self.sts 0: if _active: # Child is still running, keep us alive until we can wait on it. _active.append(self) Regards,-Kevin ___ 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?)
Terry Reedy wrote: Boris Borcic [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I agree with you (and argued it in scopes vs augmented assignment vs sets recently) that mutating would be sufficient /if/ the compiler would view augmented assignment as mutations operators : Mutation is an operation on objects. Binding is an operation on namespaces. The difference between objects and namespaces (and the actions thereupon) is fundamental to Python. If you want to put it that way, but I think it muddies the relevant water to confuse scopes with namespaces, or compiler with interpreter responsibilities. Deciding whether an augmented assignment results in a bona-fide mutation or in the rebinding of an already bound name in an unchanging namespace : that's the responsibility of the interpreter. [Well, nowa-pypy-days I guess we should say, not even of the interpreter, but of the object space]. Deciding how names bind to lexical scopes, that's the responsibility of the compiler. When faced with such code as below [ while mutable_int() might as well equal (lambda x : x) as far as the compiler is concerned ] def counter(num): num = mutable_int(num) def inc(): num += 1 return num return inc It is disingenuous that the /scope-binding phase/ of the compiler design feigns to believe that my num += 1 is really more like num = 2 than it is like a mutation operator, given that : whether the statement ultimately results in REbinding or mutation is /irrelevant/ to the fact that any augmented assignment requires an autonomous initial binding of the variable to ever function. - what is exactly the sort of assertions independent of run-time details that compilers are made to reason about. Asking the interpreter to view one thing as something else which it isn't can only lead to more confusion. I think its impossible to be more confused than setting things up so that the programmer of counter() above gets : UnboundLocalError: local variable 'num' referenced before assignment When what is really meant is (your drift no ?) : We think allowing you what you want would make a=b=c ; a += d ; b = b+d ; assert a == b more difficult for newbies to understand and predict in context In particular, asking that arithmetic operations on immutable numbers be seen as mutations seems wacky to me. Nobody really asked for this (I invite you to check), but even so I feel an exact analysis of the impact on use-cases would be worth its while. which it doesn't as far as concerns scopes where a variable appears as target only of /augmented/ assignments. The interpreter/compiler, as far as I can think, never views binding as mutation, nor should it. The request that it do so The request is not for the compiler/interpreter to view binding as mutation, it is for the /compiler/ to view /REbinding/ just like mutation - which it is as far as compiler responsibilities are concerned imo. makes me wonder whether it might have been a mistake to allow mutable objects in an augmented assignment to choose to implement the associated operation as an in-place mutation. I agree with you that removing this possibility would provide better consistency to your position. Best regards, Boris Borcic -- C++ is a contradiction in terms - Lorentz, Einstein, Poincaré ___ 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] Autoloading? (Making Queue.Queue easier to use)
Why do I have the feeling you sent this to the wrong list? On 7/10/06, Perkins, Christopher [EMAIL PROTECTED] wrote: John, I see what you are doing with the algorithm now, and I can easily re-factor it. What I am having issues with is how structured it is. 5 minute windows? Then running hours will always be recorded in 1/12th time steps. Would it not be more accurate to record engine time where the breaker was closed? -chris ___ 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/guido%40python.org -- --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] Long options support
On Wednesday 12 July 2006 21:55, Georg Brandl wrote: Should we accept at least the very common options --help and --version in 2.5? Guido pronounced on this in May Late it comes, but here is a patch for getopt.c implementing this pronouncement. I think there's no need to wait for 2.6 with it, or is there? Check it in. Anthony ___ 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] Support for PyGetSetDefs in pydoc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 10, 2006, at 9:52 PM, Barry Warsaw wrote: Patch #1520294 adds support for attributes defined with PyGetSetDef in extension modules to pydoc, specifically so things like help (array.array.typecode) gives something useful, like the attribute's docstring for instance. Along the way, I added types.GetSetterType and inspect.isgetsetter (), along with tests and docs. Now I definitely think that the pydoc change should go into Python 2.5 and be backported to Python 2.4, but it's a bit of a question whether the types.py and inspect.py changes should go into Python 2.5 now that we're in beta. I personal think they're worthwhile changes to go it, but I won't argue too hard for them since the pydoc fixes can be implemented with local changes to pydoc.py alone. Turns out there is at least one other type that I think should be better supported, but which I'm having a hard time figuring out the right way to do this. Member descriptors are one such type, an example of which is datetime.timedelta.days import datetime type(datetime.timedelta.days) type 'member_descriptor' Do a help(datetime.timedelta.days) and you get nothing useful. Now, I started down a similar path for solving this as I did the other day for getset descriptors, but I've run into a bit of a roadblock. What you basically want to do is add a constant to the types module, then add an is-predicate to inspect.py, then add the necessary glue to pydoc.py. The problem is that you have to have something readily available to call type() on to get a member descriptor type, and for that you have to go hunting around in Python's C layer. Basically you're looking for a type initialized with PyObject_HEAD_INIT(NULL) /and/ has a tp_members slot. There are a few of them around, such as the datetime.timedelta type mentioned above, but they all have a pretty serious problem. You cannot import their module in types.py. I'm not exactly sure why this is, but if you put import datetime in types.py, you'll get the import site failed error. Run with -v and you get buried in the output: 'import site' failed; traceback: Traceback (most recent call last): File /Users/barry/projects/python/Lib/site.py, line 62, in module import os File /Users/barry/projects/python/Lib/os.py, line 690, in module import copy_reg as _copy_reg File /Users/barry/projects/python/Lib/copy_reg.py, line 7, in module from types import ClassType as _ClassType File /Users/barry/projects/python/Lib/types.py, line 90, in module import datetime ImportError: No module named datetime I think the problem is that the platform-specific extension module directory isn't on sys.path yet, so it can't e.g. find datetime.so. Of course, datetime is perfectly importable later on. As far as I can tell, there does not seem to be any candidate member descriptors that are built into the interpreter and guaranteed to be there early enough to import into types, but maybe I'm missing something. I can think of a number of ways to address this, with varying levels of ickyness, but I wanted to see what you all thought. For example, I could change inspect locally so that it gets the type of datetime.timedelta.days without adding a constant to types.py. Or I could patch pydoc.py directly and leave even inspect.py out of it. Or I could create some stupid internal type in some stupid internal module who's only purpose would be to have a handle on member descriptors. Or I could change datetime to be built-in. (see what I mean about levels of ickyness? :). I'm up for suggestions. I think this would be worthwhile to address in Python 2.5 since I think it would be good to have an accurate representation of Python's built-in types in types.py. Ultimately, I really care about teaching pydoc.help() about instances of these types so that users can get better help when they encounter them (such as might be the case in 3rd party extension modules). Suggestions are welcome. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRLVF6XEjvBPtnXfVAQJVmAP5ATS56TtrdUamo+CxdNHrP6j7zxwEef2t fCM3XuEjv/Y+UH3goQIm34ENySjqYgC/whQqXGPWa/5GVc1MkhZo3W2BsA4NJ8yq Za8+6+KsWaR625qj/mh/Fbw5I/2vOE3MClATuQ75aCJjLpSAwhxYqleYPTD7tBiF P4zc+2OYedU= =ikCK -END PGP 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
Re: [Python-Dev] User's complaints
Hi Brett, On Tue, Jul 11, 2006 at 06:05:21PM -0700, Brett Cannon wrote: It is the last point in the first paragraph on time.strftime() discussing what changed in Python 2.4 as to what the change was. It's also in Misc/NEWS . Basically the guy didn't read the release notes or the docs to see why that changed and that it was legitimate and needed for stability. Surely everybody should read and think carefully about each (longish) NEWS file for each software package whenever they update their machines or switch to one with newer software than they last used. Or if they cannot bother, surely they should read at least Python's? I guess I'm going to side with Greg Black on his blog entry. Only two breakages is certainly nice, and I know that we all try quite hard to minimize that; that's probably still two breakages too much. Armin ___ 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] User's complaints
On 7/12/06, Armin Rigo [EMAIL PROTECTED] wrote: Only two breakages is certainly nice, and I know that we all try quite hard to minimize that; that's probably still two breakages too much. I agree, but some of this responsibility has to fall to users. Sometimes these breakages are bugs, pure and simple. Our tests don't catch everything. This is why it's really, really important to get as many alpha/beta testers as possible. Had the issues been brought up before 2.4 was released, we could have addressed them. Basically, if you care about these things, test before we release. That way the issues can be addressed. If you don't care enough to test and get bitten by a problem, quit whining, you had your chance. I have no sympathy for someone who is only willing to whine after the fact, but unwilling to do any work. That's really not helpful. n -- PS People do this all the time in politics too. They complain about someone, when they couldn't even be bothered to vote. ___ 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] Restricted execution: what's the threat model?
Ka-Ping Yee writes: A. The interpreter will not crash no matter what Python code it is given to execute. Why? We don't want it to crash the embedding app (which might be another python interpreter), but if the sandboxed interpreter itself crashes, is that so bad? The embedding app should just act as though that interpreter exited, possibly with a status code. B. Python programs running in different interpreters embedded in the same process cannot communicate with each other. Why not? Can't eavesdrop, yes. Can't force a connection, so that the other interpreter is free to ignore them. Maybe even make it lockable, like sockets -- but it isn't something worth promising. C. Python programs running in different interpreters embedded in the same process cannot access each other's Python objects. Note that Brett's assumption of shared extension modules violates this -- but I'm not sure why he needs to assume that. (Because of the init-only-once semantics, I'm not even sure it is a good idea to share them.) D. A given piece of Python code cannot access or communicate with certain Python objects in the same interpreter. Why not? Is this just a way of allowing lightweight subinterpreters? Or do you really mean that they can't replace or modify certain objects, such as the permission-controlling code? E. A given piece of Python code can access only a limited set of Python objects in the same interpreter. Does this include objects it creates? Or are you just saying that it will behave as if its builtins were segregated, and not see changes made by another interpreter? -jJ ___ 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] Restricted execution: what's the threat model?
On Jul 12, 2006, at 2:23 PM, Jim Jewett wrote: Ka-Ping Yee writes: A. The interpreter will not crash no matter what Python code it is given to execute. Why? We don't want it to crash the embedding app (which might be another python interpreter), but if the sandboxed interpreter itself crashes, is that so bad? The embedding app should just act as though that interpreter exited, possibly with a status code. When he says crash, I'd have to imagine that he means of the segfault variety. Good luck saving the embedding app after that. C. Python programs running in different interpreters embedded in the same process cannot access each other's Python objects. Note that Brett's assumption of shared extension modules violates this -- but I'm not sure why he needs to assume that. (Because of the init-only-once semantics, I'm not even sure it is a good idea to share them.) Well if you don't share them, you can't have them at all other than in the main trusted interpreter. C extensions can only be safely initialized once and they often cache objects in static variables... lots of C modules aren't even safe to use when combined with multiple interpreters and threads (e.g. PyGILState API), so I guess that perhaps the C API should be refined anyway. -bob ___ 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?)
Boris Borcic wrote: note that most examples of this type already work, if the target type is mutable, and implement the right operations: def counter(num): num = mutable_int(num) def inc(): num += 1 return num return inc I agree with you (and argued it in scopes vs augmented assignment vs sets recently) that mutating would be sufficient /if/ the compiler would view augmented assignment as mutations operators feel free to replace that += with an .add(1) method call; the point wasn't the behaviour of augmented assigment, the point was that that the most common use pattern involves *mutation* of the target object. the syntax isn't that important, really. /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] User's complaints
On 7/12/06, Armin Rigo [EMAIL PROTECTED] wrote: Hi Brett,On Tue, Jul 11, 2006 at 06:05:21PM -0700, Brett Cannon wrote: It is the last point in the first paragraph on time.strftime() discussing what changed in Python 2.4 as to what the change was.It's also in Misc/NEWS .Basically the guy didn't read the release notes or the docs to see why that changed and that it was legitimate and needed for stability.Surely everybody should read and think carefully about each (longish) NEWS file for each software package whenever they update their machinesor switch to one with newer software than they last used.Or if they cannot bother, surely they should read at least Python's? Obviously I don't expect people to read all of the docs; I know I don't. But when something I am using starts to act differently in a program (and especially a programming language), I do do at least a little investigating. I don't expect people to read Misc/NEWS upfront, but if something suddnely starts to act differently I would expect them to at least try to figure it out and hopefully report a bug if it is one. I guess I'm going to side with Greg Black on his blog entry.Only two breakages is certainly nice, and I know that we all try quite hard to minimize that; that's probably still two breakages too much.As Neal said, we are not perfect; bugs happen. If we all gave up on a piece of software after two bugs we would not be able to turn our computers. =) -Brett ___ 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] Restricted execution: what's the threat model?
On 7/12/06, Jim Jewett [EMAIL PROTECTED] wrote: Ka-Ping Yee writes: A.The interpreter will not crash no matter what Python code it is given to execute.Why?We don't want it to crash the embedding app (which might be another python interpreter), but if the sandboxed interpreter itself crashes,is that so bad?The embedding app should just act as though thatinterpreter exited, possibly with a status code.As Bob said, crash means segfaulting the Python proceess. Can't exactly save yourself from that one easily. =) B.Python programs running in different interpreters embedded in the same process cannot communicate with each other. Why not?Can't eavesdrop, yes. Can't force a connection, so thatthe other interpreter is free to ignore them.Maybe even make itlockable, like sockets -- but it isn't something worth promising. From an initial design point it is. It is an assumption I want to be able to make about the design. If we can come up with a reasonable way for it to work, great. But to begin with, I am assuming objects created within an interpreter will not be passed into another one. C.Python programs running in different interpreters embedded in the same process cannot access each other's Python objects. Note that Brett's assumption of shared extension modules violates this-- but I'm not sure why he needs to assume that.(Because of theinit-only-once semantics, I'm not even sure it is a good idea to share them.)Security reasons. If I can get a Python object in other interpreter with more rights to do something for me I have a serious problem.Do realize that things assumed might have to be made true as much as possible. And in my Threat Model list, I have the caveat that C extension modules are exempt from this. D.A given piece of Python code cannot access or communicate with certain Python objects in the same interpreter. Why not?Is this just a way of allowing lightweight subinterpreters?Or do you really mean that they can't replace or modify certainobjects, such as the permission-controlling code?This one is not in my Threat Model. E.A given piece of Python code can access only a limited set of Python objects in the same interpreter. Does this include objects it creates?Or are you just saying that itwill behave as if its builtins were segregated, and not see changesmade by another interpreter?I am going with your latter assumption in my design. -Brett ___ 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] User's complaints
On 7/12/06, Armin Rigo [EMAIL PROTECTED] wrote: I guess I'm going to side with Greg Black on his blog entry. I seem to recall that that particular one wass *not* an accidental bug. I believe I fell over exactly the problem that Greg Black complained about (or almost the same; maybe my problem was setting the month and day to zero and formatting only the time :-) and tried to convince the author to change it; but was told that the new behavior was never documented and that the new behavior was somehow better; and I didn't fight it further then. Do I remember this correctly? Does anybody else recall? -- --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] User's complaints
On 7/12/06, Guido van Rossum [EMAIL PROTECTED] wrote: On 7/12/06, Armin Rigo [EMAIL PROTECTED] wrote: I guess I'm going to side with Greg Black on his blog entry.I seem to recall that that particular one wass *not* an accidental bug. I believe I fell over exactly the problem that Greg Blackcomplained about (or almost the same; maybe my problem was setting themonth and day to zero and formatting only the time :-) and tried toconvince the author to change it; but was told that the new behavior was never documented and that the new behavior was somehow better; andI didn't fight it further then. Do I remember this correctly? Doesanybody else recall?My recollection is that we found a way to cause a crash if improper values were used. We never said 0s were allowed in the docs and that it could mask bugs if you did use them and we supported them ( e.g., setting 0 for January instead of 1 if you were thinking in terms of indexing at the time). So we said that values should be within the proper range and not above or below them.The python-dev Summary coverage can be found at http://www.python.org/dev/summary/2004-02-01_2004-02-29/#time-strftime-now-checks-its-argument-s-bounds .-Brett ___ 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] User's complaints
On 7/12/06, Brett Cannon [EMAIL PROTECTED] wrote: On 7/12/06, Guido van Rossum [EMAIL PROTECTED] wrote: On 7/12/06, Armin Rigo [EMAIL PROTECTED] wrote: I guess I'm going to side with Greg Black on his blog entry. I seem to recall that that particular one wass *not* an accidental bug. I believe I fell over exactly the problem that Greg Black complained about (or almost the same; maybe my problem was setting the month and day to zero and formatting only the time :-) and tried to convince the author to change it; but was told that the new behavior was never documented and that the new behavior was somehow better; and I didn't fight it further then. Do I remember this correctly? Does anybody else recall? My recollection is that we found a way to cause a crash if improper values were used. We never said 0s were allowed in the docs and that it could mask bugs if you did use them and we supported them ( e.g., setting 0 for January instead of 1 if you were thinking in terms of indexing at the time). So we said that values should be within the proper range and not above or below them. The python-dev Summary coverage can be found at http://www.python.org/dev/summary/2004-02-01_2004-02-29/#time-strftime-now-checks-its-argument-s-bounds Thanks for confirming memory! So it was an intentional regression; bugs happen doesn't apply in this case. And an unfortunate regression at that -- not because one guy writes a silly blog entry about it, but because it breaks real code -- undocumented be damned. Are we going to fix it, without allowing those crashes again? -- --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] User's complaints
On Thursday 13 July 2006 14:46, Guido van Rossum wrote: Thanks for confirming memory! So it was an intentional regression; bugs happen doesn't apply in this case. And an unfortunate regression at that -- not because one guy writes a silly blog entry about it, but because it breaks real code -- undocumented be damned. Are we going to fix it, without allowing those crashes again? I already said yes for 2.5. Brett, can you work up a patch? Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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] User's complaints
On 7/12/06, Anthony Baxter [EMAIL PROTECTED] wrote: On Thursday 13 July 2006 14:46, Guido van Rossum wrote: Thanks for confirmingmemory! So it was an intentional regression; bugs happen doesn't apply in this case. And an unfortunate regression at that -- not because one guy writes a silly blog entry about it, but because it breaks real code -- undocumented be damned. Are we going to fix it, without allowing those crashes again?I already said yes for 2.5. Brett, can you work up a patch? Yep, it's on my todo list and will get done. Might have to wait until next week, though (if that is okay), since my girlfriend is leaving town Sunday and thus I will have a ton more time after that. -Brett ___ 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] User's complaints
On 7/5/06, Neal Norwitz [EMAIL PROTECTED] wrote: 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? I frequent a lot of IRC channels either devoted to Python or heaving people use Python a lot next to my own use so I think I can, hopefully, give some comments. Of course, things are highly subjective. When some of us first saw what PEP 3000 suggested we were thinking: shit, there goes Python. It incredibly felt like Python's best measures were being dumbed down. The release cycle is not bothering people from what I gather, especially not given the fact that the world is still changing when it comes to things like XML. What is bothering people is how you have to reinstall all your site-packages when you go from one major version to another. I understand this might be a difficult problem to tackle, but I can also understand the hassle if people have more than 10-15 modules installed. Another point is how the module documentation is very terse in a lot of areas. Especially when it concerns what kind of exceptions a particular function can/will raise. As a professional, part-time, technical writer I wonder how to best tackle the entirety of the documentation we have. (Note that this is in no way any jibe towards Fred Drake, since I bet it's quite a bulk of documentation to work with/on every time.) Also it can get quite confusing when you need the introductory manual, when the language reference and when the module documentation. Things that struck me as peculiar is the old: if __name__ == __main__: whatever() This is so out of tune with the rest of python it becomes a nuisance. 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. :-) I've come relatively late to the Python scene, but ever since 2.2 I never once managed to crash the interpreter. I'll ask around and see what people are reporting to me as their top 3 or 5 Python complaints though. -- Jeroen Ruigrok van der Werven ___ 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
