Re: [Python-Dev] Security capabilities in Python
On Sun, 10 Apr 2005, Eyal Lotem wrote: > It may be really hard to get it right, unless we are overlooking some simple > solution. To "get it right", you at least need to know exactly what your operators mean. I messed up because i failed to realize that '==' can be redefined, and 'in' depends on '==' to work properly. > What about implementing the facet in C? This could avoid the class of > problems you have just mentioned. I don't think that's a good solution. A facet is just one basic programming pattern that you can build in a capability system; it would be silly to have to go back to C every time you wanted to build some other construct. A better way would be to start with capabilities that behave simply and correctly; then you can build whatever you want. -- ?!ng ___ 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] Unified or context diffs?
Are context diffs still favoured for patches? The patch submission guidelines [1] still say that, but is it actually true these days? I personally prefer unified diffs, but have been generating context diffs because of what the guidelines say. Brett can probably guess why I'm asking :) Cheers, Nick. [1] http://www.python.org/patches/ -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ 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] super_getattro() Behaviour
In PyQt, wrapped types implement lazy access to the type dictionary through tp_getattro. If the normal attribute lookup fails, then private tables are searched and the attribute (if found) is created on the fly and returned. It is also put into the type dictionary so that it is found next time through the normal lookup. This is done to speed up the import of, and the memory consumed by, the qt module which contains thousands of class methods. This all works fine - except when super is used. The implementation of super_getattro() doesn't use the normal attribute lookup (ie. doesn't go via tp_getattro). Instead it walks the MRO hierarchy itself and searches instance dictionaries explicitly. This means that attributes that have not yet been referenced (ie. not yet been cached in the type dictionary) will not be found. Questions... 1. What is the reason why it doesn't go via tp_getattro? Bug or feature? 2. A possible workaround is to subvert the ma_lookup function of the type dictionary after creating the type to do something similar to what my tp_getattro function is doing. Are there any inherent problems with that? 3. Why, when creating a new type and eventually calling type_new() is a copy of the dictionary passed in made? Why not take a reference to it? This would allow a dict sub-class to be used as the type dictionary. I could then implement a lazy-dict sub-class with the behaviour I need. 4. Am I missing a more correct/obvious technique? (There is no need to support classic classes.) Many thanks, Phil ___ 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] IPV6 with Python- 4.2.1 on HPUX
Hi Experts, I am pretty new to Python. I have been trying to compile python on HP-UX 11.23 IPF machine. I tried to build with following configure option. ./configure --prefix=/opt/iexpress/python --enable-ipv6 --with-signal-module --with-threads machine info : HP-UX beta B.11.23 U ia64 gcc : gcc version 3.4.3 While configure, I faced the following pbm, checking ipv6 stack type... ./configure[13033]: /usr/xpg4/bin/grep: not found.unknown Then I checked the config.log to find the entires for IPV6; configure:12811: checking if --enable-ipv6 is specifiedconfigure:12822: result: yesconfigure:12954: checking ipv6 stack typeconftest.c:78:22: features.h: No such file or directoryconftest.c:78:48: /usr/local/v6/include/sys/v6config.h: No such file or directoryconfigure:13111: result: unknown But, configure didnot produce any error mesage. So plz advice whether Python supports the IPV6 option on HP-UX. Bez, I know ipv6 differs from linux and HP-UX. If I no need to worry about this and build python. How to check whether IPV6 option works well with my python. Anyone please help to how to test the IPV6 functionality test. Is there any specific IPV6 test available with python. I could not find any specific testsuit for IPV6 under test directory. Plz share ur comments Advance Thanks, Senthil Prabu.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] Unified or context diffs?
[Nick Coghlan] > Are context diffs still favoured for patches? > > The patch submission guidelines [1] still say that, but is it actually > true > these days? I personally prefer unified diffs, but have been generating > context > diffs because of what the guidelines say. Submit whichever is the most informative. For some changes, it is easier to see the changed lines immediately above and below each other. For others, it helps to be able to see the whole algorithm. Raymond ___ 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] Unified or context diffs?
Raymond Hettinger wrote: [Nick Coghlan] Are context diffs still favoured for patches? The patch submission guidelines [1] still say that, but is it actually true these days? I personally prefer unified diffs, but have been generating context diffs because of what the guidelines say. Submit whichever is the most informative. For some changes, it is easier to see the changed lines immediately above and below each other. For others, it helps to be able to see the whole algorithm. And for the 'patch' tool, it doesn't really matter what you use, right? --Irmen ___ 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] Unified or context diffs?
Nick Coghlan wrote: > Are context diffs still favoured for patches? > > The patch submission guidelines [1] still say that, but is it actually > true these days? I personally prefer unified diffs, but have been > generating context diffs because of what the guidelines say. > I personally like unified diffs a lot more since you can see exactly how a line changed compared to the previous version, but that's me. I just checked the dev FAQ and it consistently says contextual diffs as well. > Brett can probably guess why I'm asking :) > =) > Cheers, > Nick. > > [1] http://www.python.org/patches/ > I didn't even know that page existed! I thought at one point this question came up and the general consensus was that unified diffs were preferred? -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] Unified or context diffs?
On Wed, Apr 13, 2005 at 12:54:08PM -0700, Brett C. wrote: > I thought at one point this question came up and the general > consensus was that unified diffs were preferred? Guido used to prefer context diffs but says he now doesn't mind unified diffs. I think unified diffs are much more common these days so that's probably what most people are used to. As Raymond says, for certain types of changes, context diffs are more readable. Still, I always use unified diffs. Neil ___ 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] Unified or context diffs?
On Wed, 2005-04-13 at 15:54, Brett C. wrote: > I thought at one point this question came up and the general consensus was > that > unified diffs were preferred? Back in the day, we preferred context diffs, and I think of the original Python core group, Guido was the last holdout. But IIRC, a few years ago the issue came up again; Guido had changed his mind so we changed syncmail to produce unified diffs. IMO unifieds are preferred when the diffs are for human consumption, but when they're only for machine consumption, anything that the patch program accepts is fine. -Barry signature.asc Description: This is a digitally signed message part ___ 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] Unified or context diffs?
Nick Coghlan wrote: > Are context diffs still favoured for patches? Just for the record: I also prefer unified over context diffs. Regards, Martin ___ 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] Unified or context diffs?
Barry Warsaw wrote: > On Wed, 2005-04-13 at 15:54, Brett C. wrote: > > >>I thought at one point this question came up and the general consensus was >>that >>unified diffs were preferred? > > > Back in the day, we preferred context diffs, and I think of the original > Python core group, Guido was the last holdout. But IIRC, a few years > ago the issue came up again; Guido had changed his mind so we changed > syncmail to produce unified diffs. > Eh. Guido doesn't deal with patches anymore, so his opinion doesn't count. =) > IMO unifieds are preferred when the diffs are for human consumption, but > when they're only for machine consumption, anything that the patch > program accepts is fine. > OK, it seems like everyone who cares enough to speak up has said so far that unified diffs are better I will change the docs some time between now and when I keel over dead to have people use unified diffs assuming some rush of people don't suddenly start saying they prefer contextual diffs. -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] Python tests fails on HP-UX 11.11 and core dumps
Senthil Prabu.S wrote: >I tried python -4.2.1 on a HP-UX 11.11 PA machine. I was able to > python. Gmake passes, gmake test results in error. The python reported > that test_pty fails,when running this test alone. > > Can anyone help to find why core dumps at running the > *test_subprocess.py* test. > Also how can I solve it? Please understand that python-dev is not the place to get free consulting. If you are willing to investigate somewhat further, try to understand the problem, and propose patches, then I would be willing to review the patches, comment on their correctness, and perhaps integrate them into the Python CVS. As it stands, I can personally take no more time to help with HP-UX problems for the near future (say, ten years :-) I do recall that there are serious problems with pseudo-terminals in Python and HP-UX, so yes, we have heard of this before. If I knew a solution, it were applied to Python already. Please understand that this perhaps hostile-sounding response is just my personal view; if somebody else responds more gracefully, just ignore me. Regards, Martin ___ 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] Unified or context diffs?
Nick Coghlan <[EMAIL PROTECTED]> writes: > Are context diffs still favoured for patches? If you want me to review it, yes, probably, but see below... > The patch submission guidelines [1] still say that, but is it actually > true these days? I personally prefer unified diffs, but have been > generating context diffs because of what the guidelines say. Emacs 21's diff-mode can convert between the two with a keypress. People who continue to abuse themselves by not using Emacs can probably find other tools to do this job. So *I* don't regard this as a big deal. Plain diffs are of course, right out. Cheers, mwh -- It is never worth a first class man's time to express a majority opinion. By definition, there are plenty of others to do that. -- G. H. Hardy ___ 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] super_getattro() Behaviour
"Phil Thompson" <[EMAIL PROTECTED]> writes: > In PyQt, wrapped types implement lazy access to the type dictionary > through tp_getattro. If the normal attribute lookup fails, then private > tables are searched and the attribute (if found) is created on the fly and > returned. It is also put into the type dictionary so that it is found next > time through the normal lookup. This is done to speed up the import of, > and the memory consumed by, the qt module which contains thousands of > class methods. > > This all works fine - except when super is used. > > The implementation of super_getattro() doesn't use the normal attribute > lookup (ie. doesn't go via tp_getattro). Instead it walks the MRO > hierarchy itself and searches instance dictionaries explicitly. This means > that attributes that have not yet been referenced (ie. not yet been cached > in the type dictionary) will not be found. > > Questions... > > 1. What is the reason why it doesn't go via tp_getattro? Because it wouldn't work if it did? I'm not sure what you're suggesting here. > 2. A possible workaround is to subvert the ma_lookup function of the type > dictionary after creating the type to do something similar to what my > tp_getattro function is doing. Eek! > Are there any inherent problems with that? Well, I think the layout of dictionaries is fiercely private. IIRC, the only reason it's in a public header is to allow some optimzations in ceval.c (though this isn't at all obvious from the headers, so maybe I'm mistaken). > 3. Why, when creating a new type and eventually calling type_new() is a > copy of the dictionary passed in made? I think this is to prevent changes to tp_dict behind the type's back. It's important to keep the dict and the slots in sync. > Why not take a reference to it? This would allow a dict sub-class > to be used as the type dictionary. I could then implement a > lazy-dict sub-class with the behaviour I need. Well, not really, because super_getattro uses PyDict_GetItem, which doesn't respect subclasses... > 4. Am I missing a more correct/obvious technique? (There is no need to > support classic classes.) Hum, I can't think of one, I'm afraid. There has been some vague talk of having a tp_lookup slot in typeobjects, so PyDict_GetItem(t->tp_dict, x); would become t->tp_lookup(x); (well, ish, it might make more sense to only do that if the dict lookup fails). For now, not being lazy seems your only option :-/ (it's what PyObjC does). Cheers, mwh -- Many of the posts you see on Usenet are actually from moths. You can tell which posters they are by their attraction to the flames. -- Internet Oracularity #1279-06 ___ 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] IPV6 with Python- 4.2.1 on HPUX
On Wednesday 13 April 2005 21:11, Senthil Prabu.S wrote: > Hi Experts, >I am pretty new to Python. I have been trying to compile python > on HP-UX 11.23 IPF machine. I tried to build with following configure > option. > > ./configure --prefix=/opt/iexpress/python --enable-ipv6 > --with-signal-module --with-threads machine info : HP-UX beta B.11.23 U > ia64 > gcc : gcc version 3.4.3 > While configure, I faced the following pbm, Last time I tried, gcc on HPUX/ia64 was completely unable to build a working version of Python - this was not the fault of Python, but simply that gcc on that platform was utterly broken. Please try with the HP compiler instead, see if that is any better. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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] Unified or context diffs?
On Thursday 14 April 2005 07:26, Brett C. wrote: > OK, it seems like everyone who cares enough to speak up has said so far > that unified diffs are better I will change the docs some time between now > and when I keel over dead to have people use unified diffs assuming some > rush of people don't suddenly start saying they prefer contextual diffs. Should probably say either context or unified diffs - I'm sure there's vendor supplied 'diff' programs out there that don't support -u ed-style patches, of course, are RIGHT OUT. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ 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] Unified or context diffs?
On Apr 13, 2005, at 11:17 PM, Anthony Baxter wrote: On Thursday 14 April 2005 07:26, Brett C. wrote: OK, it seems like everyone who cares enough to speak up has said so far that unified diffs are better I will change the docs some time between now and when I keel over dead to have people use unified diffs assuming some rush of people don't suddenly start saying they prefer contextual diffs. Should probably say either context or unified diffs - I'm sure there's vendor supplied 'diff' programs out there that don't support -u ed-style patches, of course, are RIGHT OUT. It might be worth mentioning that if/when subversion is used to replace CVS, unified diffs are going to be the obvious way to do it, because I don't think that subversion supports context diffs without using an external diff command. -bob ___ 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
