Re: [Python-Dev] setuptools has divided the Python community
Someone asked for the input of ordinary users (i.e. non developers) which, unfortunately, most of the people on this list don't fall in. My experience with setuptools is that it's poorly documented and assumes a level of sophistication that isn't always there. While this is fine in a lot of arenas, installation of things shouldn't be an area where I have to guess between multiple interpretations of documentation AND have a thorough knowledge of some of the nuts and bolts of interdependencies. Maybe having an easily extensible language is not consistent with having an easy to extend language, but the current arrangement seems untenable. -- Haikus are easy Most make very little sense Refrigerator ___ 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] Challenge: Please break this! [Now with blog post]
I didn't see Tav actually say this but are we all agreed that compile() should be removed from __builtins__? ___ 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] A suggestion: Do proto-PEPs in Google Docs
Not that I'm expecting to be working on PEPs any time soon, but just as a different perspective, I would find the effort to open up Google docs to be a much higher barrier to doing some editing tweaks than the dvcs case. For the DVCS, I'd just write a little script that would (1) update (2) open the editor on the file (3) do the commit/push dance when the file was closed. So for me it would be as easy as editing the file locally. So for my work style, a DVCS would be the biggest win. --RDM That's funny because I would expect that for most people it's the exact opposite... just create a gmail account... boom, done... I'm not necessarily advocating that but just saying that IMO, most people will find google docs to be the fastest and easiest solution. -- Haikus are easy Most make very little sense Refrigerator ___ 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] Help! Vista symlinks and IDLE
I'm glad someone sent this out... I was having this EXACT problem today I've got it installed on my wife's computer and I'm certain that it worked when I first installed 3.0a but it stopped working (I didn't update Python but my wife has done several Vista security updates)... Hopefully, that will help in the bug tracking for this. On Sun, Jan 18, 2009 at 5:02 PM, Martin v. Löwis mar...@v.loewis.dewrote: Apparently, if you install Python into a localized version of \Program Files on Vista (such as \Programas, or \Programmer), IDLE fails to start; see http://bugs.python.org/3881 Apparently, Tcl cannot properly initialize on such a system, and apparently, this is related to these folders being symlinks. It would be good if anybody who has access to such a system can diagnose what the specific problem is, how to reproduce it on a system that has the English version of Vista installed, and preferably, how to solve the problem. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/hall.jeff%40gmail.com -- Haikus are easy Most make very little sense Refrigerator ___ 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] A wart which should have been repaired in 3.0?
I was thinking that the user could just define the delimiter character due to the differences amongst delimiters used in OS's... but if that isn't a problem (Skip seemed to think it wouldn't be) then my solution is functionally identical to the first one he proposed ___ 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] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)
Doesn't SQLlite still have a 4gb cap? I'd personally prefer an open source solution (if that's Berkeley so be it but there's plenty out there... MySQL for one) ___ 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] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)
never mind about the limit... I was thinking SQL Express On Thu, Sep 4, 2008 at 1:07 PM, Jeff Hall [EMAIL PROTECTED] wrote: Doesn't SQLlite still have a 4gb cap? I'd personally prefer an open source solution (if that's Berkeley so be it but there's plenty out there... MySQL for one) -- Haikus are easy Most make very little sense Refrigerator ___ 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] Documentation Error for __hash__
I'm not sure about the first but as for the __reversed__ we had a discussion yesterday and it was indeed added in 2.4 (oddly, my 2.5 documentation has this correct... ) -- Haikus are easy Most make very little sense Refrigerator ___ 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] Confusing listreverseiterator Behavior
Unless I'm misconstruing something the problem is that reversed returns two different object types depending on if it's a list or a tuple l = [1,2,3,4] i = iter(l) ri = reversed(l) l [1, 2, 3, 4] ri listreverseiterator object at 0x00D5C8F0 i listiterator object at 0x00D5C3F0 t = (1,2,3,4) it = iter(t) rit = reversed(t) it tupleiterator object at 0x00D5C030 rit reversed object at 0x00D5CC90 reversing a tuple (or a string) returns a reversed object reversing a list returns a listreverseiterator definitely an inconsistency ___ 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] Confusing listreverseiterator Behavior
I realized after I fired off my response that this was still bugging me... it appears that the documentation is incorrect from 2.1 Built-in Functions (v2.5 in case it matters... a quick search of bugs doesn't seem to show anything though) *reversed*( seq) Return a reverse iterator. seq must be an object which supports the sequence protocol (the __len__() method and the __getitem__()method with integer arguments starting at 0). New in version 2.4. the above appears to only be true for lists. For tuples and strings it creates a reverse OBJECT which behaves slightly differently (notably by not including a len() method as you noticed) I can't find how to actually create a tuplereverseiterator or stringreverseiterator objects... nor does there appear to be a way to create a reversed object from a list... Just tested this s = 'bob' t = (1,2,3,4) l = [1,2,3,4) rs = reversed(s) rt = reversed(t) rl = reversed(l) type(rs) type 'reversed' type(rt) type 'reversed' type(rl) type 'listreverseiterator' type(rs) == type(rt) True type(rs) == type(rl) False Surely this isn't intentional? Haikus are easy Most make very little sense Refrigerator ___ 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 unquote - Unicode issues
quote_from_bytes = quote So either name can be used on either input type, with the idea being that you should use quote on a str, and quote_from_bytes on a bytes. Is this a good idea or should it be rewritten so each function permits only one input type? so you can use quote_from_bytes on strings? I assumed Guido meant it was okay to have quote accept string/byte input and have a function that was redundant but limited in what it accepted (i.e. quote_from_bytes accepts only bytes) I suppose your implementation doesn't break anything... it just strikes me as odd ___ 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 unquote - Unicode issues
(Aside: I dislike functions that have a different return type based on the value of a parameter.) I wanted to stay out of the whole discussion as it's largely over my head... But I did want to express support for this idea which I think almost rises to the level of a standard... I see more bugs created in our software because of the above issues then anything else... I have no problem with functions that accept various input but producing various outputs just seems to wreak havoc... ___ 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] repeated keyword arguments
That's all fine and good but in this case there may be stealth errors. If the user/programmer is expecting the first value to hold but instead On Fri, Jun 27, 2008 at 7:03 PM, Guido van Rossum [EMAIL PROTECTED] wrote: On Fri, Jun 27, 2008 at 2:54 PM, Fred Drake [EMAIL PROTECTED] wrote: On Jun 27, 2008, at 5:23 PM, Benjamin Peterson wrote: I think code that uses this is probably already quite broken in some fundamental way and putting the fix in 2.5 isn't much of a risk. I suspect the risk has more to do with breaking something else in Python than in breaking 3rd-party code in this case. I think it should be fixed for 2.5 as well, myself. Let me clarify why I want to be so careful with this. If there is code that was expected to work but due to a bug in our code raises an exception, it's generally safe to fix this: people who ran into the issue found that their code didn't work, used a work-around, and that's the end of the story. But if there is code that was expected to *break* but due to a bug in our code *doesn't* raise an exception, people can very well have harmless occurrences of such code, and never noticed. Maybe their code is broken in the sense that it doesn't produce the correct result, but it may well be in a don't care way -- but if an upgrade suddenly starts raising the exception, they are likely to get unhandled exceptions where before they had none. This is particularly annoying when the author of the program that breaks is not the user of the program, to whose machine the upgrade was applied. In such cases I think it's better not to introduce new exceptions in point-point releases. -- --Guido van Rossum (home page: http://www.python.org/~guido/http://www.python.org/%7Eguido/ ) ___ 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/hall.jeff%40gmail.com -- Haikus are easy Most make very little sense Refrigerator ___ 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] repeated keyword arguments
oops... baby jumped in my lap... i pretty much said it all though... I think the error of the software functioning incorrectly may necessitate the patch... I certainly understand Guido's concern, however. ___ 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] Community buildbots and Python release quality metrics
To me (and I'm an outsider not a direct developer), it's Python developers responsibility to handle the Python problems and the Python build bots. The community build bots are the responsibility of their authors. If JP is handling the Twisted one then great. It's got a gatekeeper. If no one is handling the Django build bot that's not the Python Dev Team's problem but is a problem on the Django side and someone involved in that should be tasked with monitoring. Having said all that, I agree that the community bots ought to at least be looked at. If I check in a patch in and I notice that a community bot went from green to red then I probably should double check my code. The problem is that, as you said, the community bots haven't been well maintained... They've been red for awhile. So asking the developers to then go do the leg work to find the original error, fix it and then back check everything between then and now that might have ALSO caused a problem is alot of effort. It's not the Bank's responsibility to balance my check book. They give me the tools to do it and then I have to check. A similar principle applies here, I believe. ___ 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] C API for gc.enable() and gc.disable()
It seems to me that the root problem is allocation spikes of legitimate, useful data. Perhaps then we need some sort of test to determine if those are legitimate. Perhaps checking every nth (with n decreasing as allocation bytes increases) object allocated during a spike could be useful. Then delay garbage collection until x consecutive objects are found to be garbage? It seems like we should be attacking the root cause rather than finding some convoluted math that attempts to work for all scenarios. On a side note, the information about not GCing on string objects is interesting? Is there a way to override this behavior? I've found that re.py chokes on large text files (4MB plus) without line ends (don't ask, they're not our files but we have to parse them). I wonder if this isn't the reason... If the answer to that is, no, strings are always ignored I'd recommend rethinking this (or providing an option to override somehow. -- Haikus are easy Most make very little sense Refrigerator ___ 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] C API for gc.enable() and gc.disable()
On Wed, Jun 25, 2008 at 4:55 PM, Martin v. Löwis [EMAIL PROTECTED] wrote: It seems to me that the root problem is allocation spikes of legitimate, useful data. Perhaps then we need some sort of test to determine if those are legitimate. Perhaps checking every nth (with n decreasing as allocation bytes increases) object allocated during a spike could be useful. Then delay garbage collection until x consecutive objects are found to be garbage? It seems like we should be attacking the root cause rather than finding some convoluted math that attempts to work for all scenarios. I think exactly the other way 'round. The timing of thing should not matter at all, only the exact sequence of allocations and deallocations. I trust provable maths much more than I trust ad-hoc heuristics, even if you think the math is convoluted. I probably chose my wording poorly (particularly for a newcomer/outsider). What I meant was that the numbers used in GC currently appear arbitrary. The idea of three groups (youngest, oldest and middle) is also arbitrary. Would it not be better to tear that system apart and create a sliding scale. If the timing method is undesirable then make it slide based on the allocation/deallocation difference. In this way, the current breakpoints and number of groups (all of which are arbitrary and fixed) could be replaced by one coefficient (and yes, I recognize that it would also be arbitrary but it would be one, tweakable number rather than several). My gut tells me that your current fix is going to work just fine for now but we're going to end up tweaking it (or at least discussing tweaking it) every 6-12 months. On a side note, the information about not GCing on string objects is interesting? Is there a way to override this behavior? I think you misunderstand. Python releases unused string objects just fine, and automatically. It doesn't even need GC for that. I took the statement, Current GC only takes into account container objects, which, most significantly, ignores string objects (of which most applications create plenty) to mean that strings were ignored for deciding when to do garbage collection. I mistakenly thought that was because they were assumed to be small. It sounds like they're ignored because they're automatically collected and so they SHOULD be ignored for object garbage collection. Thanks for the clarification... Back to the drawing board on my other problem ;) -- Haikus are easy Most make very little sense Refrigerator ___ 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] [Python-checkins] r62916 - sandbox/trunk/release/release.py
I think a better stump the guido would be to just have people write the most convoluted things for simple processes and see how minimalist he could make the final code... I think we could have some fun with this ;) ___ 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] PEP 8: Discourage named lambdas?
+1 For what it's worth from a newbie ___ 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
