Re: [Python-Dev] 2.5 status
On 9/5/06, Brett Cannon <[EMAIL PROTECTED]> wrote: > > > [MAL] > > The proper fix would be to introduce a tp_unicode slot and let > > this decide what to do, ie. call .__unicode__() methods on instances > > and use the .__name__ on classes. > > That was my bug reaction and what I said on the bug report. Kind of > surprised one doesn't already exist. > > > I think this would be the right way to go for Python 2.6. For > > Python 2.5, just dropping this .__unicode__ method on exceptions > > is probably the right thing to do. > > Neal, do you want to rip it out or should I? Is removing __unicode__ backwards compatible with 2.4 for both instances and exception classes? Does everyone agree this is the proper approach? I'm not familiar with this code. Brett, if everyone agrees (ie, remains silent), please fix this and add tests and a NEWS entry. Everyone should be looking for incompatibilities with previous versions. Exceptions are new and deserve special attention. Lots of the internals of strings (8-bit and unicode) and the struct module changed and should be tested thoroughly. I'm sure there are a bunch of other things I'm not remembering. The compiler is also an obvious target to verify your code still works. We're stuck with anything that makes it into 2.5, so now is the time to fix these problems. n ___ Python-Dev mailing list [email protected] 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 status
On 5-sep-2006, at 6:24, Neal Norwitz wrote: > There are 3 bugs currently listed in PEP 356 as blocking: > http://python.org/sf/1551432 - __unicode__ breaks on > exception classes > http://python.org/sf/1550938 - improper exception w/ > relative import > http://python.org/sf/1541697 - sgmllib regexp bug causes hang > > Does anyone want to fix the sgmlib issue? If not, we should revert > this week before c2 is cut. I'm hoping that we will have *no changes* > in 2.5 final from c2. Should there be any bugs/patches added to or > removed from the list? > > The buildbots are currently humming along, but I believe all 3 > versions (2.4, 2.5, and 2.6) are fine. > > Test out 2.5c1+ and report all bugs! I have another bug that I'd like to fix: Mac/ReadMe contains an error: it claims that you can build the frameworkinstall into a temporary directory and then move it into place, but that isn't actually true. The erroneous paragraph is this: Note that there are no references to the actual locations in the code or resource files, so you are free to move things around afterwards. For example, you could use --enable-framework=/tmp/newversion/Library/ Frameworks and use /tmp/newversion as the basis for an installer or something. My proposed fix is to drop this paragraph. There is no bugreport for this yet, I got notified of this issue in a private e-mail. Ronald ___ Python-Dev mailing list [email protected] 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 status
Doc patches are fine, please fix. n -- On 9/7/06, Ronald Oussoren <[EMAIL PROTECTED]> wrote: > > On 5-sep-2006, at 6:24, Neal Norwitz wrote: > > > There are 3 bugs currently listed in PEP 356 as blocking: > > http://python.org/sf/1551432 - __unicode__ breaks on > > exception classes > > http://python.org/sf/1550938 - improper exception w/ > > relative import > > http://python.org/sf/1541697 - sgmllib regexp bug causes hang > > > > Does anyone want to fix the sgmlib issue? If not, we should revert > > this week before c2 is cut. I'm hoping that we will have *no changes* > > in 2.5 final from c2. Should there be any bugs/patches added to or > > removed from the list? > > > > The buildbots are currently humming along, but I believe all 3 > > versions (2.4, 2.5, and 2.6) are fine. > > > > Test out 2.5c1+ and report all bugs! > > I have another bug that I'd like to fix: Mac/ReadMe contains an > error: it claims that you can build the frameworkinstall into a > temporary directory and then move it into place, but that isn't > actually true. The erroneous paragraph is this: > > Note that there are no references to the actual locations in the > code or > resource files, so you are free to move things around afterwards. > For example, > you could use --enable-framework=/tmp/newversion/Library/ > Frameworks and use > /tmp/newversion as the basis for an installer or something. > > My proposed fix is to drop this paragraph. There is no bugreport for > this yet, I got notified of this issue in a private e-mail. > > Ronald > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] inspect.py very slow under 2.5
Ralf Schmitt wrote: > Nick Coghlan wrote: >> Good point. I modified the patch so it does the latter (it only calls >> getabspath() again for a module if the value of module.__file__ changes). > > with _filesbymodname[modname] = file changed to _filesbymodname[modname] > = f > it seems to work ok. I checked the inspect module unit tests and discovered the test for this function was only covering one of the half dozen possible execution paths. I've updated the patch on SF, and committed the fix (including PJE's and Neal's comments) to the trunk. I'll backport it tomorrow night (assuming I don't hear any objections in the meantime :). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Change in file() behavior in 2.5
Hi folks, Between 2.4 and 2.5 the behavior of file or open with the mode 'wU' has changed. In 2.4 it silently works. in 2.5 it raises a ValueError. I can't find any more discussion on it in python-dev than tangential mentions in this thread: http://mail.python.org/pipermail/python-dev/2006-June/065939.html It is (buried) in NEWS. First I found: Bug #1462152: file() now checks more thoroughly for invalid mode strings and removes a possible "U" before passing the mode to the C library function. Which seems to imply different behavior than the actual entry: bug #967182: disallow opening files with 'wU' or 'aU' as specified by PEP 278. I don't see anything in pep278 about a timeline, and wanted to make sure that transitioning directly from working to raising an error was a desired change. This actually caught a bug in an application I work with, which used an explicit 'wU', that will currently stop working when people upgrade Python but not our application. Thanks, Michael -- Michael Urman http://www.tortall.net/mu/blog ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Change in file() behavior in 2.5
"Michael Urman" <[EMAIL PROTECTED]> writes: > Hi folks, > > Between 2.4 and 2.5 the behavior of file or open with the mode 'wU' > has changed. In 2.4 it silently works. in 2.5 it raises a ValueError. > I can't find any more discussion on it in python-dev than tangential > mentions in this thread: > http://mail.python.org/pipermail/python-dev/2006-June/065939.html > > It is (buried) in NEWS. First I found: > Bug #1462152: file() now checks more thoroughly for invalid mode > strings and removes a possible "U" before passing the mode to the > C library function. > Which seems to imply different behavior than the actual entry: > bug #967182: disallow opening files with 'wU' or 'aU' as specified by PEP > 278. > > I don't see anything in pep278 about a timeline, and wanted to make > sure that transitioning directly from working to raising an error was > a desired change. That it was silently ignored was never intentional; it was a bug and it was fixed. I don't think having a release with deprecation warnings and so on is worth it. > This actually caught a bug in an application I work with, which used > an explicit 'wU', that will currently stop working when people > upgrade Python but not our application. I would hope they wouldn't do that without careful testing anyway. Cheers, mwh -- No. In fact, my eyeballs fell out just from reading this question, so it's a good thing I can touch-type. -- John Baez, sci.physics.research ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] inspect.py very slow under 2.5
Nick Coghlan wrote: > I've updated the patch on SF, and committed the fix (including PJE's and > Neal's comments) to the trunk. > > I'll backport it tomorrow night (assuming I don't hear any objections in the > meantime :). I just wanted to thank you all for taking the time to work on this, even with my 11-th hour report. Greatly appreciated, really. Looking forward to 2.5! f ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 'with' bites Twisted
When the pybot buildslave for Twisted is trying to run the Twisted test suite via 'trial', it gets an exception:Traceback (most recent call last): File "/tmp/Twisted/bin/trial", line 23, in from twisted.scripts.trial import run File "/tmp/Twisted/twisted/scripts/trial.py", line 10, in from twisted.application import app File "/tmp/Twisted/twisted/application/app.py", line 10, in from twisted.application import service File "/tmp/Twisted/twisted/application/service.py", line 20, in from twisted.python import components File "/tmp/Twisted/twisted/python/components.py", line 37, in from zope.interface.adapter import AdapterRegistry File "/tmp/python-buildbot/local/lib/python2.6/site-packages/zope/interface/adapter.py", line 201for with, objects in v.iteritems(): ^SyntaxError: invalid syntaxSo the culprit in this case is really zope.interface.The full log is here: http://www.python.org/dev/buildbot/community/all/x86%20RedHat%209%20trunk/builds/97/step-shell/0Grig-- http://agiletesting.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Twisted-Python] Newbie question
On Thu, 7 Sep 2006 11:41:48 -0400, Timothy Fitz <[EMAIL PROTECTED]> wrote: >On 9/5/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: >>You cannot stop the reactor and then start it again. > >Why don't the reactors throw if this happens? This question comes up >almost once a month. > One could just as easily ask why no one bothers to read mailing list archives to see if their question has been answered before. No one will ever know, it is just one of the mysteries of the universe. Jean-Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Twisted-Python] Newbie question
On Thu, Sep 07, 2006, Jean-Paul Calderone wrote: > On Thu, 7 Sep 2006 11:41:48 -0400, Timothy Fitz <[EMAIL PROTECTED]> wrote: >>On 9/5/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: >>> >>>You cannot stop the reactor and then start it again. >> >>Why don't the reactors throw if this happens? This question comes up >>almost once a month. > > One could just as easily ask why no one bothers to read mailing list > archives to see if their question has been answered before. > > No one will ever know, it is just one of the mysteries of the universe. One could also ask why this got x-posted to python-dev... -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ I support the RKAB ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Twisted-Python] Newbie question
Jean-Paul> One could just as easily ask why no one bothers to read Jean-Paul> mailing list archives to see if their question has been Jean-Paul> answered before. Jean-Paul> No one will ever know, it is just one of the mysteries of the Jean-Paul> universe. +1 QOTF... Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Twisted-Python] Newbie question
Sorry, brainfart. Jean-Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Unicode Imports
Hello All. I just added patch 1552880 to sourceforge. It is a patch for 2.6 (and 2.5) which allows unicode paths in sys.path and uses the unicode file api on windows. This is tried and tested on 2.5, and backported to 2.3 and is currently running on clients in china and esewhere. It is minimally intrusive to the inporting mechanism, at the cost of some string conversion overhead (to utf8 and then back to unicode). Cheers, Kristján ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Arlington sprints to occur monthly
Jeffrey Elkner has arranged things so that the 1-day Python sprints in Arlington VA will now be happening every month. Future sprints will be on September 23rd, October 21st, November 18th, and December 16th. See http://wiki.python.org/moin/ArlingtonSprint for directions and to sign up. --amk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Twisted-Python] Newbie question
Jean-Paul> Sorry, brainfart. But still... QOTF ;-) S ___ Python-Dev mailing list [email protected] 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 status
On 9/7/06, Neal Norwitz <[EMAIL PROTECTED]> wrote: On 9/5/06, Brett Cannon <[EMAIL PROTECTED]> wrote:>> > [MAL]> > The proper fix would be to introduce a tp_unicode slot and let> > this decide what to do, ie. call .__unicode__() methods on instances > > and use the .__name__ on classes.>> That was my bug reaction and what I said on the bug report. Kind of> surprised one doesn't already exist.>> > I think this would be the right way to go for Python 2.6. For> > Python 2.5, just dropping this .__unicode__ method on exceptions> > is probably the right thing to do.>> Neal, do you want to rip it out or should I?Is removing __unicode__ backwards compatible with 2.4 for bothinstances and exception classes? Should be. There was no proper __unicode__() originally so that's why this whole problem came up in the first place. Does everyone agree this is the proper approach? I'm not familiarwith this code.I am not terribly anymore either since Georg and Richard rewrote the whole thing. =) Brett, if everyone agrees (ie, remains silent),please fix this and add tests and a NEWS entry.OK.-Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new security doc using object-capabilities
On 9/6/06, Ka-Ping Yee <[EMAIL PROTECTED] > wrote: Hi Brett,Here are some comments on your proposal. Sorry this took so long.I apologize if any of these comments are out of date (but also lookforward to your answers to some of the questions, as they'll help me understand some more of the details of your proposal). Thanks!I think they are slightly outdated. The latest version of the doc is in the bcannon-objcap branch and is named securing_python.txt ( http://svn.python.org/view/python/branches/bcannon-objcap/securing_python.txt ). > Introduction> ///[...]> Throughout this document several terms are going to be used. A> "sandboxed interpreter" is one where the built-in namespace is not the > same as that of an interpreter whose built-ins were unaltered, which> is called an "unprotected interpreter".Is this a definition or an implementation choice? As in, are youdefining "sandboxed" to mean "with altered built-ins" or just "restricted in some way", and does the above mean to imply thataltering the built-ins is what triggers other kinds of restrictions(as it did in Python's old restricted execution mode)? There is no "triggering" of other restrictions. This is an implementation choice. "Sandboxed" means "with altered built-ins". > A "bare interpreter" is one where the built-in namespace has been> stripped down the bare minimum needed to run any form of basic Python> program. This means that all atomic types (i.e., syntactically > supported types), ``object``, and the exceptions provided by the> ``exceptions`` module are considered in the built-in namespace. There> have also been no imports executed in the interpreter. Is a "bare interpreter" just one example of a sandboxed interpreter,or are all sandboxed interpreters in your design initially bare (i.e."sandboxed" = "bare" + zero or more granted authorities)? You build up from a bare interpreter by adding in authorities (e.g., providing a wrapped version of open()) to reach the level of security you want. > The "security domain" is the boundary at which security is cared> about. For this dicussion, it is the interpreter.It might be clearer to say (if i understand correctly) "Each interpreter is a separate security domain." Many interpreters can run within a single operating system process, right?Yes. Could you say a bit about what sort of concurrency model you have in mind?None specifically. Each new interpreter automatically runs in its own Python thread, so they have essentially the same concurrency as using the 'thread' module. How would this interact (if at all) with use of theexisting threading functionality?See above. > The "powerbox" is the thing that possesses the ultimate power in the> system. In our case it is the Python process.This could also be the application process, right?If Python is embedded, yes. > Rationale> ///[...]> For instance, think of an application that supports a plug-in system > with Python as the language used for writing plug-ins. You do not> want to have to examine every plug-in you download to make sure that> it does not alter your filesystem if you can help it. With a proper > security model and implementation in place this hinderance of having> to examine all code you execute should be alleviated.I'm glad to have this use case set out early in the document, so thereader can keep it in mind as an example while reading about the model. > Approaches to Security> ///>> There are essentially two types of security: who-I-am> (permissions-based) security and what-I-have (authority-based) > security.As Mark Miller mentioned in another message, your descriptions of"who-I-am" security and "what-I-have" security make sense, butthey don't correspond to "permission" vs. "authority". They correspond to "identity-based" vs. "authority-based" security.Right. This was fixed the day Mark and Alan Karp made the comment. > Difficulties in Python for Object-Capabilities> //[...]> Three key requirements for providing a proper perimeter defence is > private namespaces, immutable shared state across domains, and> unforgeable references.Nice summary.> Problem of No Private Namespace> ===[...] > The Python language has no such thing as a private namespace.Don't local scopes count as private namespaces? It seems clearthat they aren't designed with the intention of being exposed,unlike other namespaces in Python. Sort of. But you can still get access to them if you have an execution frame and they are not persistent. Generators are are worse since they store their execution frame with the generator itself, completely exposing the local namespace. > It also makes providing security at the object level using> object-capabilities non-existent in pure Python code. I don't think this is necessarily the case. No Python code i've ever seen expects to
Re: [Python-Dev] Unicode Imports
On Friday 08 September 2006 02:56, Kristján V. Jónsson wrote: > Hello All. > I just added patch 1552880 to sourceforge. It is a patch for 2.6 (and 2.5) > which allows unicode paths in sys.path and uses the unicode file api on > windows. This is tried and tested on 2.5, and backported to 2.3 and is > currently running on clients in china and esewhere. It is minimally > intrusive to the inporting mechanism, at the cost of some string conversion > overhead (to utf8 and then back to unicode). As this can't be considered a bugfix (that I can see), I'd be against it being checked into 2.5. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
