Re: [Python-Dev] Broader iterable support for xmlrpclib
[Skip] > I then proposed the > even wackier idea to simply allow all currently unsupported iterables > (sets > and arrays seem the most obvious candidates to me) to be marshalled as > lists Doesn't the appropriate conversion depend on the contract between the sender and receiver (i.e. an array of type 'c' may either be converted as list(arr) or arr.tostring() depending on the app)? Is the goal to save writing explicit conversions by presuming that most iterables aspire to be lists for transport purposes? 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
[Python-Dev] Tracker anonymity
In c.l.py Paul Rubin wrote: Paul> In the old days, it was possible to post stuff to Python's Paul> sourceforge pages without logging in. That was turned off for Paul> various reasons that weren't bogus, but that didn't strike me as Paul> overwhelmingly compelling. Maybe that could be revisited, at Paul> least for the category of documentation bugs and patches. Any thoughts about maybe relaxing the login restriction? I know we had problems with anonymous submissions in the past (mostly inability to contact the requester for more info I think), but perhaps that downside is less important than the perception some people have that logging in is a barrier to submission. Try it for a few months and see? 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] Tracker anonymity
[EMAIL PROTECTED] wrote: > In c.l.py Paul Rubin wrote: > > Paul> In the old days, it was possible to post stuff to Python's > Paul> sourceforge pages without logging in. That was turned off for > Paul> various reasons that weren't bogus, but that didn't strike me as > Paul> overwhelmingly compelling. Maybe that could be revisited, at > Paul> least for the category of documentation bugs and patches. > > Any thoughts about maybe relaxing the login restriction? I know we had > problems with anonymous submissions in the past (mostly inability to contact > the requester for more info I think), but perhaps that downside is less > important than the perception some people have that logging in is a barrier > to submission. > > Try it for a few months and see? If the submitter is anonymous, not only can we not follow up with any questions, neither does the submitter get notified of status changes on their tracker. IMO, allowing anonymous access will lead to people getting ticked that their bug reports were closed "not enough information" or "works for me" and they weren't notified about it. Then again, there are some genuinely simple reports (especially with docs), where the overhead of having to log in (or worse, create a SF account) means the problem doesn't get reported, and hence, doesn't get fixed. Can we put a warning on the anonymous submission page pointing out the problems with using it for non-trivial bug reports? 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
Re: [Python-Dev] Documentation about Python's GC, python-dev list messages referenced in Modules/gcmodule.c not reachable anymore
Hi Neil, Hi Tim, Hi Simon, your responsive and valuable answers cleared up most of the open questions and gave a very positive impression to my project leader about the python community and python itself. Thank you very much! I'm trying to get more into the GC implementation before asking more about some still open points. Gregoire ___ 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] Broader iterable support for xmlrpclib
>> I then proposed the even wackier idea to simply allow all currently >> unsupported iterables (sets and arrays seem the most obvious >> candidates to me) to be marshalled as lists Raymond> Doesn't the appropriate conversion depend on the contract Raymond> between the sender and receiver (i.e. an array of type 'c' may Raymond> either be converted as list(arr) or arr.tostring() depending on Raymond> the app)? Is the goal to save writing explicit conversions by Raymond> presuming that most iterables aspire to be lists for transport Raymond> purposes? Sure, I suspect it depends on the contract. The contract my patch enforces is whether or not list(obj) succeeds. If that fails, a TypeError is raised as before. If it succeeds incorrectly, I suspect the programmer will figure that out soon enough and make the appropriate adjustment. In the common case though, I suspect it will work though. As indicated in the patch submission, the goals are to: * extend the set of sequences that can be marshalled transparently * keep the caller from caring as much about the limitations of the XML-RPC datatypes 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] Tracker anonymity
>> Any thoughts about maybe relaxing the login restriction? Nick> If the submitter is anonymous, not only can we not follow up with Nick> any questions, neither does the submitter get notified of status Nick> changes on their tracker. You're preaching to the choir. I'm made the same argument over and over on c.l.py, but there is a vocal minority there that believes the current state of affairs is a barrier that prevents submissions. Here's my latest post on that topic explaining all the reasons why the way we do it today is the best we can do -- for now at least. http://mail.python.org/pipermail/python-list/2005-December/314298.html Nick> Can we put a warning on the anonymous submission page pointing out Nick> the problems with using it for non-trivial bug reports? I don't think we have any control over the boilerplate SF displays. My biggest frustration is that SF doesn't support tracker interaction via email. That would present its own set of problems (think spam & virii), but seems like it ought to lower the barrier to submission a bit. 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] Broader iterable support for xmlrpclib
On 12/7/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > >> I then proposed the even wackier idea to simply allow all currently > >> unsupported iterables (sets and arrays seem the most obvious > >> candidates to me) to be marshalled as lists > > Raymond> Doesn't the appropriate conversion depend on the contract > Raymond> between the sender and receiver (i.e. an array of type 'c' may > Raymond> either be converted as list(arr) or arr.tostring() depending on > Raymond> the app)? Is the goal to save writing explicit conversions by > Raymond> presuming that most iterables aspire to be lists for transport > Raymond> purposes? > > Sure, I suspect it depends on the contract. The contract my patch enforces > is whether or not list(obj) succeeds. If that fails, a TypeError is raised > as before. If it succeeds incorrectly, I suspect the programmer will figure > that out soon enough and make the appropriate adjustment. In the common > case though, I suspect it will work though. As indicated in the patch > submission, the goals are to: > > * extend the set of sequences that can be marshalled transparently > > * keep the caller from caring as much about the limitations of the XML-RPC > datatypes I think this is a bad idea. XML-RPC is severely limited in what it can handle; it is NOT a general marshalling protocol for Python data types. It's better to be aware of this than to try and ignore it. Having to write list(x) means that you are aware that you're consuming any iterators. It also means that mistakes (e.g. passing in a file) are caught earlier. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Tracker anonymity
On 12/7/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > You're preaching to the choir. I'm made the same argument over and over on > c.l.py, but there is a vocal minority there that believes the current state > of affairs is a barrier that prevents submissions. I definitely don't want anonymous bug reports (even for trivial ones). I expect the problem is more that in order to submit non-anonymously not only do you have to provide an email address, but you have to go through the whole rigmarole of signing up as a SF user. I don't think that the issue is so much the need for anonymity but the signup hassle. (After all, if you really want to be anonymous you can sign up under an alias or use an anonymizer; if you really don't want to read the SF email you can direct the mail to /dev/null.) Anyway, now that we've moved to our own Subversion, the trackers are the lsat part of the Python infrastructure that remains on SF. There's a perfectly capable replacement ready to wait on python.org. Maybe we should finally switch to roundup so we can abandon SF? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Tracker anonymity
Guido> Anyway, now that we've moved to our own Subversion, the trackers Guido> are the lsat part of the Python infrastructure that remains on Guido> SF. There's a perfectly capable replacement ready to wait on Guido> python.org. Maybe we should finally switch to roundup so we can Guido> abandon SF? Fine with me. Is it ready to go though? If not, what more needs to be done? I was under the assumption that it wasn't ready for prime time and solicited inputs on c.l.py in a couple messages yesterday and today. 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] Tracker anonymity
[EMAIL PROTECTED] writes: > In c.l.py Paul Rubin wrote: > > Paul> In the old days, it was possible to post stuff to Python's > Paul> sourceforge pages without logging in. That was turned off for > Paul> various reasons that weren't bogus, but that didn't strike me as > Paul> overwhelmingly compelling. Maybe that could be revisited, at > Paul> least for the category of documentation bugs and patches. > > Any thoughts about maybe relaxing the login restriction? I know we had > problems with anonymous submissions in the past (mostly inability to contact > the requester for more info I think), but perhaps that downside is less > important than the perception some people have that logging in is a barrier > to submission. > > Try it for a few months and see? No way. I see no reason to force the people who complain about this to find another excuse to not do anything useful. Cheers, mwh (harsh, but...) -- MacOSX: Sort of like a pedigree persian cat. Very sleek, very sexy, but a little too prone to going cross-eyed, biting you on your thumb and then throwing up on your trousers. -- Jim's pedigree of operating systems, asr ___ 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] hasattr and properties
Hi, I've noticed some behaviour of hasattr when used on properties which I'm inclined to call a bug, or at least unexpected behaviour: Python 2.4.2 (#1, Oct 29 2005, 13:11:33) [GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on linux2 [...] >>> class Foo(object): ... def get(self): ... print "hi there" ... raise Exception ... bar = property(get) ... >>> hasattr(Foo, "bar") True >>> hasattr(Foo(), "bar") hi there False One would expect hasattr to yield the same result in both cases, and the result to be True. Apparently, when applied to a class instance, hasattr calls getattr and decides that the attribute doesn't exist if the call raises any exception. - Wouldn't it make sense to only report a missing attribute if an AttributeError is raised? - As far as properties are concerned, it would make even more sense to not call getattr but try to look up the attribute the same way getattr would. This would, however, not work consistently anymore if one customizes attribute access. Has anyone thought about that matter? -- Thomas ___ 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] Tracker anonymity
[Nick] >> Can we put a warning on the anonymous submission page pointing out >> the problems with using it for non-trivial bug reports? [Skip] > I don't think we have any control over the boilerplate SF displays. There must be some control. There's a "Outlook users please see the list of frequently reported bugs" message on the bugs page for spambayes. My guess would be that Mark Hammond put it there, so he probably knows (or knew :) how to do it. =Tony.Meyer ___ 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] ast-objects branch created
"Martin v. Löwis" wrote: > Nick Coghlan wrote: >> As Fredrik pointed out a while back, the PyObject approach doesn't >> *have* to involve manual decref operations - PyObject's come with a >> ready made arena structure, in the form of PyList. > > That doesn't really work: PyList_Append (which you would have to use) > duplicates the reference, so you would still have to decref it > explicitly. Hmm - perhaps we should have a set of Arena functions/macros e.g. PyArena_Add - works like PyList_Append, but doesn't duplicate the reference (or immediately decrefs it). I'm sure there are other parts of the code base that would benefit from this. Tim Delaney ___ 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] ast-objects branch created
"Delaney, Timothy (Tim)" wrote: > > Nick Coghlan wrote: > >> As Fredrik pointed out a while back, the PyObject approach doesn't > >> *have* to involve manual decref operations - PyObject's come with a > >> ready made arena structure, in the form of PyList. > > > > That doesn't really work: PyList_Append (which you would have to use) > > duplicates the reference, so you would still have to decref it > > explicitly. > > Hmm - perhaps we should have a set of Arena functions/macros e.g. PyArena_Add > - works like > PyList_Append, but doesn't duplicate the reference (or immediately decrefs > it). > > I'm sure there are other parts of the code base that would benefit from this. if you check my original post, you'll find code for a new list helper function, which would solve this in a convenient way. ___ 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] ast-objects branch created
On 12/7/05, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote: > "Martin v. Löwis" wrote: > > > Nick Coghlan wrote: > >> As Fredrik pointed out a while back, the PyObject approach doesn't > >> *have* to involve manual decref operations - PyObject's come with a > >> ready made arena structure, in the form of PyList. > > > > That doesn't really work: PyList_Append (which you would have to use) > > duplicates the reference, so you would still have to decref it > > explicitly. > > Hmm - perhaps we should have a set of Arena functions/macros e.g. PyArena_Add > - works like PyList_Append, but doesn't duplicate the reference (or > immediately decrefs it). > > I'm sure there are other parts of the code base that would benefit from this. There is such a function on the ast-arena branch. The current implementation uses a linked list, so it consumes more memory than using a PyList. Jeremy ___ 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] hasattr and properties
Thomas Lotze wrote: > Apparently, when applied to a class instance, hasattr calls getattr and > decides that the attribute doesn't exist if the call raises any exception. > - Wouldn't it make sense to only report a missing attribute if an > AttributeError is raised? That would be an improvement, but calling the property access code as a side effect of hasattr seems like a misfeature to me in the first place. > - As far as properties are concerned, it would make even more sense to not > call getattr but try to look up the attribute the same way getattr would. > This would, however, not work consistently anymore if one customizes > attribute access. Maybe descriptors need a fourth slot for hasattr customisation? The logic would then be if there is a descriptor for the attribute: if the descriptor's hasattr slot is populated: return the result of calling it else: return True else: look in the instance dict for the attribute There wouldn't be a need to rely on catching exceptions at all, then. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ 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] hasattr and properties
On 12/7/05, Greg Ewing <[EMAIL PROTECTED]> wrote: > Maybe descriptors need a fourth slot for hasattr > customisation? > > The logic would then be > >if there is a descriptor for the attribute: > if the descriptor's hasattr slot is populated: >return the result of calling it > else: >return True >else: > look in the instance dict for the attribute Um, that does't work for types which customize __getattribute__ or __getattr__ in various ways. IMO a property that has a side effect (other than updating a cache or statistics or perhaps logging) is a misfeature anyway, so I don't see what's wrong with hasattr() trying getattr() and reporting False IFF that raises an exception. If you want only AttributeError to be handled, use getattr(x, 'name', None). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Short-circuiting iterators
On Tue, 2005-12-06 at 19:58 -0500, Raymond Hettinger wrote: > Any real-world use cases or compelling contrived examples? > > ISTM, that the code calling it.stop() would already be in position to > break-out of the iteration directly or set a termination flag. Instead > of: > > it = itertools.interruptable(iterable): > for x in it: > . . . > if cond(x): > it.stop() > > Why not write: > > for x in iterable: > . . . > if cond(x): > break > > If needed, the for-loop can have an else-clause for any processing > needed in the event of interruption. The idea was motivated by a case of nested loops, similar to: for x in iterable1: for y in iterable2: for z in iterable3: . . . if cond1(x): iterable1.stop() if cond2(y): iterable2.stop() if cond3(z): iterable3.stop() . . . It seemed more convenient at the time than having to deal with multiple termination flags, or breaks, or a combination thereof. The ability to remotely terminate a for-loop also struck me as somewhat interesting: def estimate(item, iterable): . . . if good_enough: iterable.stop() return result for x in iterable: . . . approx *= estimate(x, iterable) But these are highly contrived and hardly compelling. I was primarily interested in whether anyone recalls discussing the ability to prematurely terminate an iterator and whether there are any technical drawbacks other than it being redundant. Matthew Barnes ___ 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] Tracker anonymity
Nick Coghlan wrote: > If the submitter is anonymous, not only can we not follow up with any > questions, neither does the submitter get notified of status changes on their > tracker. Would not simply requesting an email address along with the report provide enough information for questioning and notifying the submitter? I don't see why a full-blown registration and login should be required. If the submitter chooses not to supply an email address, then they have no grounds for being upset at not receiving any notifications! -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ 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] Short-circuiting iterators
[Matthew F. Barnes] > The ability to remotely terminate a for-loop also struck me as somewhat > interesting: > > def estimate(item, iterable): > . . . > if good_enough: > iterable.stop() > return result > > for x in iterable: > . . . > approx *= estimate(x, iterable) Good inspiration; wrong technique. For the RightWay(tm), try a functional approach composing a target calculation with a function generating successively more accurate approximations and a consumer function that stops when the desired accuracy is achieved. The idea is to decouple the steps into side-effect-free, reusable components. For a worked-out, comprehensive example, see http://www.md.chalmers.se/~rjmh/Papers/whyfp.pdf . > But these are highly contrived and hardly compelling. That suggests an answer to your earlier question as to whether itertools.interruptable(iterable) would be a useful addition ;-) 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] hasattr and properties
On 12/7/05, Greg Ewing <[EMAIL PROTECTED]> wrote: > Thomas Lotze wrote: > > > Apparently, when applied to a class instance, hasattr calls getattr and > > decides that the attribute doesn't exist if the call raises any exception. > > - Wouldn't it make sense to only report a missing attribute if an > > AttributeError is raised? > > That would be an improvement, but calling the property access > code as a side effect of hasattr seems like a misfeature to me > in the first place. I will have to disagree with you there. If hasattr(a,b) returns True, one should be able to expect a.b will work properly. Otherwise, the majority of use cases for hasattr will be completely thrown out the window. How can hasattr work properly with properties if it doesn't call the property access code? > > - As far as properties are concerned, it would make even more sense to not > > call getattr but try to look up the attribute the same way getattr would. > > This would, however, not work consistently anymore if one customizes > > attribute access. > > Maybe descriptors need a fourth slot for hasattr > customisation? > > The logic would then be > >if there is a descriptor for the attribute: > if the descriptor's hasattr slot is populated: >return the result of calling it > else: >return True >else: > look in the instance dict for the attribute > > There wouldn't be a need to rely on catching exceptions > at all, then. If there is a descriptor with no hasattr slot, it should call __get__ to make sure it is successful (ie, doesn't raise any exceptions). ___ 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
