Re: [Python-Dev] What to do with languishing patches?
Am 20.07.2010 06:37, schrieb Stephen J. Turnbull: Mark Lawrence writes: Is this the same login as for the issue tracker or is a new one needed? It's different. Both trackers are supposed to support OpenID logins, I believe. (However, there are somewhat frequent reports of difficulties with it; I don't know if the system is fully debugged. I think most people are OK, but making a new login is the sure path.) The meta tracker doesn't support OpenID (it's a very plain roundup without customization). The OpenID support of the Python tracker is quite mature now, or so I've heard. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] OpenID login for Roundup bug trackers (was: What to do with languishing patches?)
Stephen J. Turnbull step...@xemacs.org writes: Mark Lawrence writes: On 18/07/2010 23:38, Alexander Belopolsky wrote: The direct link [to the “meta-tracker”] is http://psf.upfronthosting.co.za/roundup/meta/ Is this the same login as for the issue tracker or is a new one needed? It's different. Both trackers are supposed to support OpenID logins, I believe. The tracker at URL:http://psf.upfronthosting.co.za/roundup/meta/ doesn't mention OpenID on its login form, so I must assume it doesn't currently support it. The Python bug tracker URL:http://bugs.python.org/ does support arbitrary OpenID for authentication. It didn't in the recent past, so I'm very glad to see that it does now. I can finally get an account there without the hassle of managing a site-specific auth set. (However, there are somewhat frequent reports of difficulties with it; I don't know if the system is fully debugged. I think most people are OK, but making a new login is the sure path.) It worked for me so far on URL:http://bugs.python.org/, logging in with my OpenID and then going through the registration process. Thanks for drawing my attention to that; if the people who made OpenID auth happen are observing this, then thank you all very much! Any hope of feeding those changes back upstream so it's available to all Roundup users at some point? -- \ “Pinky, are you pondering what I'm pondering?” “Well, I think | `\ so, Brain, but first you'd have to take that whole bridge | _o__) apart, wouldn't you?” —_Pinky and The Brain_ | Ben Finney ___ 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-dev signal-to-noise processing question
On Mon, Jul 19, 2010 at 04:08:00PM -0600, average wrote: Wha? How could this not be the right place? He's not asking about USING python, but asking: WHERE in the PYTHON CODE BASE does the signal get checked? A-bit-miffed-at-the-cold-shoulderly yours, Marcos (wink wink) I know, the task of sending answers like I've sent is quite unappreciated. I know, the meaning of my answer is rude because, in short, it's simply Please, go away, and however I stress the please part it's still go away. If I were a help seeker it'd be quite a hard blow for me to receive such an answer. Yes, I know. Still, two other alternatives are even worse. The first alternative is to not answer using questions at all; quite rude. The second is answer all questions and make the developers quit the list and found a new quiet one. I don't see any other alternative, do you? Of those three - which one do you prefer? The original question was about using python, that's my understanding. Oleg. -- Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ 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] OpenID login for Roundup bug trackers
Thanks for drawing my attention to that; if the people who made OpenID auth happen are observing this, then thank you all very much! You're welcome! Any hope of feeding those changes back upstream so it's available to all Roundup users at some point? Hope dies last. It's main foundation is an openid library that I wrote (http://pypi.python.org/pypi/openid2rp). As for the roundup integration, I likely won't have much time to contribute it back. 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] mkdir -p in python
Sorry, I don't know what is the no constant arguments guideline refers to. Could you give me some more explanation? By the way, I feel adding separate functions is not quiet worthy for such a function. On Tue, Jul 20, 2010 at 7:11 AM, Greg Ewing greg.ew...@canterbury.ac.nzwrote: Ray Allen wrote: I think both os.mkdir() and os.makedirs() should add a keyword argument to suppress the OSError: [Errno 17] File exists. This could be seen as violating the no constant arguments guideline. Maybe separate function would be better? -- Greg ___ 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/ysj.ray%2Bpython-dev%40gmail.com -- Ray Allen Best wishes! ___ 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] mkdir -p in python
On Tue, 20 Jul 2010 06:49:44 pm 岳帅杰 wrote: Sorry, I don't know what is the no constant arguments guideline refers to. Could you give me some more explanation? It refers to the guideline that you shouldn't have a single function with two (or more) different behaviour and an argument that does nothing but select between them. Here is a toy example: def change_case(s, make_upper=True): if make_upper: return s.upper() else: return s.lower() By the way, I feel adding separate functions is not quiet worthy for such a function. I tend to agree. Perhaps all we need is a recipe in the docs: try: os.makedirs(path) except OSError, e: if e.errno != 17: raise I think that's all it takes to get the behaviour wanted without any false negatives, and four lines is short enough to use in-place, or if you prefer it's easy enough to wrap it in a function in your own module. Not everything needs to be a built-in. I'm -0 on adding an argument to os.makedirs, +0 on adding a variant function to os, and +0.5 on adding the variant to the shutil module. -- Steven D'Aprano ___ 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] tracker contribution
On Mon, 19 Jul 2010 00:06:32 +0100, Mark Lawrence breamore...@yahoo.co.uk wrote: You all might have gathered that I'm very dispirited by the negative attitudes that I get from a relatively small minority of Python people. I might as well quit because it doesn't do my mental health a great deal of good. That minority will of course be very happy to see me go because they'll be able to sit back on their loathsome, spotty behinds picking blackheads and resort to the usual we're far too busy to do anything routine. You might understand that I don't completely agree with this. Mark, please understand that (as far as I can tell) the small minority of people of whom you are speaking here, who have offered advice on how to make your triage work more helpful to the Python community, are some of the most *active* Python committers and community participants. I think the best thing for your mental health would be to see if you can just ignore things that seem negative, and see if there's any useful advice in what is said. And if you don't find the opinions useful, then you don't. The essence of community is cooperation, and cooperation can't happen without communication; and yes, some of it is going to sound negative (and some of it will even *be* negative...that's human nature, as your message demonstrates). Which I think you have done, since I've seen you put into practice some of the suggestions that were made. I regret that I haven't been able to follow your prolific work closely (in fact, I have had to stop following the bugs list, I now just watch the new bugs list...not just due to the volume, but because of my other commitments, but the volume certainly contributed, unfortunately[*]). I especially regret that because I was the one who gave you developer privs on the tracker, and so I have something of a responsibility to so. I'm relying on the positive feedback that you are getting here to assuage my guilt for not paying closer attention to your work, and also on the fact that I have seen the quality of your work improve over time from the bugs I have reviewed that you've commented on. -- R. David Murray www.bitdance.com [*] I think this may be a source of some of the discomfort you have sensed. I had been used to being able to keep up with the bugs list, but even before you started your work I was already thinking that that wasn't going to work for much longer...as Python becomes more popular, the number of bug reports increases, and as we add more committers and gather more people who are actively helping out, the message traffic increases. This is *good*: it means we are getting more done (well, at least if we can continue to add committers it does), but it also means that it is no longer possible for a part time volunteer to keep an overview of the bug/patch activity. The danger, of course, is that more things will slip through the cracksbut this is not, as you have observed, a new problem. ___ 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] mkdir -p in python
On Tue, Jul 20, 2010 at 11:09 PM, Steven D'Aprano st...@pearwood.info wrote: I'm -0 on adding an argument to os.makedirs, +0 on adding a variant function to os, and +0.5 on adding the variant to the shutil module. shutil seems like the place for it to me. The subtlety of getting the error suppression correct makes it worth implementing this once and for all I think. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Curious datetime method
I wonder why would anyone want to use datetime.today() instead of datetime.now()? Because this method is also present in datetime.date. Thus, you can reference stuff like d.today().day without caring whether d is a date or a datetime object. Anders ___ 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] mkdir -p in python
On Tue, 20 Jul 2010, Steven D'Aprano wrote: I tend to agree. Perhaps all we need is a recipe in the docs: try: os.makedirs(path) except OSError, e: if e.errno != 17: raise What if the path or a parent of it already exists as a file? If one has requested -p I believe one typically wants this to be an error. And I assume that one would not use the literal 17 in production code. Isaac Morland CSCF Web Guru DC 2554C, x36650WWW Software Specialist ___ 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] mkdir -p in python
I'd go with putting it in shutil. We could also add a function there that wraps up the recipe in issue 9311 to work around the quirks of os.access on FreeBSD (and possibly other platforms). -- R. David Murray www.bitdance.com ___ 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-dev signal-to-noise processing question
On 7/20/2010 11:59 AM, Oleg Broytman wrote: On Mon, Jul 19, 2010 at 04:08:00PM -0600, average wrote: Wha? How could this not be the right place? He's not asking about USING python, but asking: WHERE in the PYTHON CODE BASE does the signal get checked? A-bit-miffed-at-the-cold-shoulderly yours, Marcos (wink wink) I know, the task of sending answers like I've sent is quite unappreciated. I know, the meaning of my answer is rude because, in short, it's simply Please, go away, and however I stress the please part it's still go away. If I were a help seeker it'd be quite a hard blow for me to receive such an answer. Yes, I know. No, the reply is fine as far as it goes, and I am sure the poster did get a reply from c.l.py, but his question revealed a thirst for knowledge not usually evidenced in non-dev inquiries. Still, two other alternatives are even worse. The first alternative is to not answer using questions at all; quite rude. The second is answer all questions and make the developers quit the list and found a new quiet one. I don't see any other alternative, do you? Of those three - which one do you prefer? The original question was about using python, that's my understanding. Could we perhaps include a link to the material for Python devs, just so people realise that although they are being sent away for good reason, if they are interested in joining the dev community there is material to help and guide them. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ ___ 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-dev signal-to-noise processing question
On Tue, Jul 20, 2010 at 6:59 AM, Oleg Broytman p...@phd.pp.ru wrote: .. I know, the task of sending answers like I've sent is quite unappreciated. I know, the meaning of my answer is rude because, in short, it's simply Please, go away, and however I stress the please part it's still go away. If I were a help seeker it'd be quite a hard blow for me to receive such an answer. Yes, I know. Still, two other alternatives are even worse. The first alternative is to not answer using questions at all; quite rude. The second is answer all questions and make the developers quit the list and found a new quiet one. I don't see any other alternative, do you? Of those three - which one do you prefer? People dislike canned responses no matter how friendly and polite they sound. I believe python-dev tradition is to redirect the poster to python-list but still include at least a hint to what the answer to his or her question is. I believe this works fairly well. ___ 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] mkdir -p in python
On Tue, Jul 20, 2010 at 9:09 AM, Steven D'Aprano st...@pearwood.info wrote: It refers to the guideline that you shouldn't have a single function with two (or more) different behaviour and an argument that does nothing but select between them. In particular, when that argument is almost never given a variable value, but is specified using a constant at the call site. -Fred -- Fred L. Drake, Jr. fdrake at gmail.com A storm broke loose in my mind. --Albert Einstein ___ 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] What to do with languishing patches?
Le 18/07/2010 23:17, Alexander Belopolsky a écrit : On Sun, Jul 18, 2010 at 5:02 PM, Mark Lawrence breamore...@yahoo.co.uk wrote: Maybe going off on a tangent, but I find it frustrating because you (plural) can't find a given module on the issue tracker. Say I'm looking for issues relating to smtplib, all I can do is look in the title of the issue. Have I missed something, or is there a need to have subsections so that if Lib is selected, you can then find the appropriate module? I don't think you missed anything and I would also find this feature useful. For example, I recently took interest in datetime and pickle modules, but other than full text search, there was no way to find all issues related to either of these two modules. The Components list is somewhat arbitrary with narrow components such as ctypes and broad components such a Lib. When I suggested such a modules list on http://wiki.python.org/moin/DesiredTrackerFeatures, R. David Murray replied “This has been suggested and rejected a number of times on python-dev” but I have been unable to find those discussions. Regards ___ 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] Curious datetime method
On Tue, Jul 20, 2010 at 9:57 AM, Anders Sandvig anders.sand...@gmail.com wrote: I wonder why would anyone want to use datetime.today() instead of datetime.now()? Because this method is also present in datetime.date. Thus, you can reference stuff like d.today().day without caring whether d is a date or a datetime object. For this particular use it is not necessary for today() method to have covariant returns. In other words, if datetime.today() returned a date object in the same way as date.today() does, you could still write d.today().day. Moreover, since today() is a class method, the result does not depend on d, so you can simply do date.today().day. A more interesting use case would be a function that tells whether d is in the future: def isfuture(d): return d d.today() Here covariant return is necessary because you cannot compare datetime to date and even if you could, this is probably not what you want in this case. This implementation of isfuture() has a problem: it does not work with aware datetime objects. To make that work, we would need today(tz) method that can account for a timezone, or better have now(tz=None) available as a date class method: def isfuture(d): return d d.now(d.tzinfo) Furthermore, this use case does not explain the need to have datetime.today() respect overriding of fromtimestamp() in datetime subclasses or having to reproduce datetime.fromtimestamp(time.time()) with all its undefined behavior that comes with floating point timestamps. In the ideal world, I would like today() to accept tz and always return date object while adding covariant now([tz]) method to date and possibly even time class. (The later is the subject of http://bugs.python.org/issue8902). In the real world where we have to take backward compatibility into account, I would like to make today() and now() to be the same: both taking optional tz argument, both available as either date or datetime methods and both covariant. the justification for having two methods doing exactly the same will be just readability: date.today() and datetime.now() are more readable than date.now() and datetime.today(). ___ 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] mkdir -p in python
On 07/20/2010 10:43 AM, Fred Drake wrote: On Tue, Jul 20, 2010 at 9:09 AM, Steven D'Apranost...@pearwood.info wrote: It refers to the guideline that you shouldn't have a single function with two (or more) different behaviour and an argument that does nothing but select between them. In particular, when that argument is almost never given a variable value, but is specified using a constant at the call site. I was thinking it should have been two functions, but I realized there is more subtleties involved than simply just reusing a directory that already exists. One possibility might be... mkdir(path [, allow=None, mode=0777]) Where None can be replaced with one or more of the following. 'exists' dir can already exist (with same permissions as mode) 'case' dir case can be different. (Windows) 'files' dir can have files in it. ... or a string containing the initials. It doesn't fall under the single constant rule if done this way. Ron ___ 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] mkdir -p in python
On 20/07/2010 14:43, Nick Coghlan wrote: On Tue, Jul 20, 2010 at 11:09 PM, Steven D'Apranost...@pearwood.info wrote: I'm -0 on adding an argument to os.makedirs, +0 on adding a variant function to os, and +0.5 on adding the variant to the shutil module. shutil seems like the place for it to me. The subtlety of getting the error suppression correct makes it worth implementing this once and for all I think. Really - so we have two almost identical functions with slightly different behaviour in different standard library modules? Aren't the Python APIs for working with files and paths confused enough already. That seems crazy to me and a switch on os.makedirs much more sensible. Michael Cheers, Nick. -- http://www.ironpythoninaction.com/ ___ 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] mkdir -p in python
On 07/20/2010 11:47 AM, Ron Adam wrote: On 07/20/2010 10:43 AM, Fred Drake wrote: On Tue, Jul 20, 2010 at 9:09 AM, Steven D'Apranost...@pearwood.info wrote: It refers to the guideline that you shouldn't have a single function with two (or more) different behaviour and an argument that does nothing but select between them. In particular, when that argument is almost never given a variable value, but is specified using a constant at the call site. I was thinking it should have been two functions, but I realized there is more subtleties involved than simply just reusing a directory that already exists. One possibility might be... mkdir(path [, allow=None, mode=0777]) Where None can be replaced with one or more of the following. 'exists' dir can already exist (with same permissions as mode) 'case' dir case can be different. (Windows) 'files' dir can have files in it. Add 'path', Complete path as -p option does. ... or a string containing the initials. It doesn't fall under the single constant rule if done this way. Ron ___ 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] mkdir -p in python
On Tue, Jul 20, 2010 at 12:47 PM, Ron Adam r...@ronadam.com wrote: It doesn't fall under the single constant rule if done this way. If the value for 'allow' were almost always given as a constant, this would be an argument for three functions instead of one. The guideline has little to do with the type of the value, but the number of possible values (small) and whether they're normally given as constants in the code. If there's more than one, and combinations then to vary, then keeping them as args makes sense. Also, if we don't know what we want the functionality to be, as you suggest, then worry about that is premature. :-) Let's decide on the required functionality first. ___ 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] :program: markup in .rst documentation
While fixing the :option: markup in the library docs (http://bugs.python.org/issue9312), another question came up: In a few places, documenting a program execution with options was made with: :program:`python regrtest.py` :option:`test_spam.py` Since my patch had the :option: markup removed, this became: :program:`python regrtest.py test_spam.py` However, according to Éric Araujo's comment, due to the intention of the :program: markup this should actually just say: ``python regrtest.py test_spam.py`` Which way to choose? I will update my patch to reflect this. Eli ___ 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] :program: markup in .rst documentation
On Tue, Jul 20, 2010 at 1:16 PM, Eli Bendersky eli...@gmail.com wrote: .. ``python regrtest.py test_spam.py`` Which way to choose? I will update my patch to reflect this. Sorry to add the third way to the mix, but shouldn't the recommended way to run a module as a script be python -m modname? As in $ python -m test.regrtest test_spam ___ 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] :program: markup in .rst documentation
Switching to python -m is generally good where it applies (as in this case). The original intent for :option: and :program: were in their use as references rather than in sample command lines. Georg should be the final arbiter, but I'd be in favor of ``...`` for command lines. ___ 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] :program: markup in .rst documentation
Sorry to add the third way to the mix, but shouldn't the recommended way to run a module as a script be python -m modname? As in $ python -m test.regrtest test_spam This is true but orthogonal to our problem, which is that :program:`python -m thing` is wrong if I understood the doc rightly and should be replaced by ``python -m thing``. Regards ___ 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] Does trace modules have a unit test?
I've opened issue 9315 (http://bugs.python.org/issue9315) to address the lack of unit tests for the trace.py module. I hope to get to it in a few days and add some tests. As Terry wrote in the beginning of this thread, Lib/test/test_trace.py currently tests the sys.settrace module, so the tests of trace.py should find a new home. Does Lib/test/test_trace_module.py make sense or is something else preferable? Eli ___ 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-dev signal-to-noise processing question
On 7/20/2010 6:59 AM, Oleg Broytman wrote: I know, the task of sending answers like I've sent is quite unappreciated. *I* appreciate it. I mostly do not respond to such because I expect you or Aahz will. I know, the meaning of my answer is rude because, in short, it's simply Please, go away, and however I stress the please part it's still go away. If I were a help seeker it'd be quite a hard blow for me to receive such an answer. Yes, I know. 1. I suggested one improvement to the canned response in my previous post: expand 'using' to 'using or understanding'. 2. Here is another: mention that Python developers who are willing to answer non-development questions already participate on python-list/gmane.comp.python.general to answer such questions there. 3. That brings up: also mention gmane.comp.python.general, for those like me who prefer the newsgroup interface. 4. Alexander Belopolsky wrote: People dislike canned responses no matter how friendly and polite they sound. I believe python-dev tradition is to redirect the poster to python-list but still include at least a hint to what the answer to his or her question is. I believe you *did* do that, but it was easily missed. So: end the boilerplate with - and put hints here so they stand out. Still, two other alternatives are even worse. The first alternative is to not answer using questions at all; quite rude. The second is answer all questions and make the developers quit the list and found a new quiet one. I brought up that same possibility. I don't see any other alternative, do you? Of those three - which one do you prefer? The original question was about using python, that's my understanding. I agree that it appeared to be, but it was phrased in terms of understanding its operation, hence the claim that it was not, and hence suggestion 1) above. -- Terry Jan Reedy ___ 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] mkdir -p in python
On 7/20/2010 12:49 PM, Michael Foord wrote: On 20/07/2010 14:43, Nick Coghlan wrote: On Tue, Jul 20, 2010 at 11:09 PM, Steven D'Apranost...@pearwood.info wrote: I'm -0 on adding an argument to os.makedirs, +0 on adding a variant function to os, and +0.5 on adding the variant to the shutil module. shutil seems like the place for it to me. The subtlety of getting the error suppression correct makes it worth implementing this once and for all I think. Really - so we have two almost identical functions with slightly different behaviour in different standard library modules? Aren't the Python APIs for working with files and paths confused enough already. That seems crazy to me and a switch on os.makedirs much more sensible. Guido has twice approved changing os.makedirs. First 2 1/2 years ago in http://bugs.python.org/msg58924 from http://bugs.python.org/issue1675 and recently in this thread http://mail.python.org/pipermail/python-dev/2010-July/102027.html which lead to http://bugs.python.org/issue9299 Both issues have a patch and I reviewed their major similarities and minor differences in http://bugs.python.org/msg110770 -- Terry Jan Reedy ___ 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] Does trace modules have a unit test?
On Tue, Jul 20, 2010 at 10:51 AM, Eli Bendersky eli...@gmail.com wrote: As Terry wrote in the beginning of this thread, Lib/test/test_trace.py currently tests the sys.settrace module, so the tests of trace.py should find a new home. Does Lib/test/test_trace_module.py make sense or is something else preferable? IMO you should just rename test_trace.py to test_settrace.py, and put the trace.py tests in test_trace.py. Reid ___ 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] What to do with languishing patches?
On Tue, 20 Jul 2010 17:45:42 +0200, mer...@netwok.org wrote: On 18/07/2010 23:17, Alexander Belopolsky wrote: On Sun, Jul 18, 2010 at 5:02 PM, Mark Lawrence breamore...@yahoo.co.uk wrote: Maybe going off on a tangent, but I find it frustrating because you (plural) can't find a given module on the issue tracker. Say I'm looking for issues relating to smtplib, all I can do is look in the title of the issue. Have I missed something, or is there a need to have subsections so that if Lib is selected, you can then find the appropriate module? I don't think you missed anything and I would also find this feature useful. For example, I recently took interest in datetime and pickle modules, but other than full text search, there was no way to find all issues related to either of these two modules. The Components list is somewhat arbitrary with narrow components such as ctypes and broad components such a Lib. When I suggested such a modules list on http://wiki.python.org/moin/DesiredTrackerFeatures, R. David Murray replied âThis has been suggested and rejected a number of times on python-devâ but I have been unable to find those discussions. During the most recent discussion I can remember, I thought I remembered Stephen Trumble saying that they'd tried that in xemacs and it really hadn't worked very well. Since he now says he thinks it's a good idea (or more likely I misremembered what he said the first time), it sounds like we should consider it again. -- R. David Murray www.bitdance.com ___ 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] Does trace modules have a unit test?
On Tue, Jul 20, 2010 at 2:12 PM, Reid Kleckner reid.kleck...@gmail.com wrote: .. IMO you should just rename test_trace.py to test_settrace.py, and put the trace.py tests in test_trace.py. +1 ___ 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] mkdir -p in python
On 07/20/2010 12:00 PM, Fred Drake wrote: On Tue, Jul 20, 2010 at 12:47 PM, Ron Adamr...@ronadam.com wrote: It doesn't fall under the single constant rule if done this way. If the value for 'allow' were almost always given as a constant, this would be an argument for three functions instead of one. The guideline has little to do with the type of the value, but the number of possible values (small) and whether they're normally given as constants in the code. If there's more than one, and combinations then to vary, then keeping them as args makes sense. Also, if we don't know what we want the functionality to be, as you suggest, then worry about that is premature. :-) Let's decide on the required functionality first. That makes sense. :-) Another things that comes to mind, is it may make sense to choose either strict, and have args to *allow* different cases, or to choose lenient, and have args to *restrict* different cases. That keeps it somewhat less confusing, and doesn't require memorization to remember what the mixed mode default might be. (Unless we use a single combination 99% of the time, then that probably *should* be the default.) Ron ___ 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] What to do with languishing patches?
On Tue, Jul 20, 2010 at 2:16 PM, R. David Murray rdmur...@bitdance.com wrote: .. During the most recent discussion I can remember, I thought I remembered Stephen Trumble saying that they'd tried that in xemacs and it really hadn't worked very well. Since he now says he thinks it's a good idea (or more likely I misremembered what he said the first time), it sounds like we should consider it again. The only problem I can see with this feature is how to design a usable UI. Have you ever cursed these extra clever address forms that make you select a state from a drop-down list of 50 if not a country from the list of 100+? A text field with auto-completion/correction and validation would be the best, but may get cluttered if multiple modules are affected. We actually have similar usability issue with the nosy list. The + button was a great addition, but I would also like to see a user list integration that would allow me to add other by real name or by approximate username spelling. ___ 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-dev signal-to-noise processing question
On Tue, Jul 20, 2010 at 01:51:07PM -0400, Terry Reedy wrote: On 7/20/2010 6:59 AM, Oleg Broytman wrote: 1. I suggested one improvement to the canned response in my previous post: expand 'using' to 'using or understanding'. I changed wording to if you're having problems learning, understanding or using Python 2. Here is another: mention that Python developers who are willing to answer non-development questions already participate on python-list/gmane.comp.python.general to answer such questions there. Good addition, thank you! I'll add something like there are Python developers who participate on python-list/comp.lang.python. 3. That brings up: also mention gmane.comp.python.general, for those like me who prefer the newsgroup interface. It is referenced at http://www.python.org/community/lists/ and my text points to http://www.python.org/community/; I think it's enough. Oleg. -- Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ 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] What to do with languishing patches?
On Tue, Jul 20, 2010 at 02:53:53PM -0400, Alexander Belopolsky wrote: Have you ever cursed these extra clever address forms that make you select a state from a drop-down list of 50 if not a country from the list of 100+? Well, I have never, because in any of these drop-down lists I can press a few first letters of the name and the cursor jumps to the country. I often select countries in such lists in web browsers. Oleg. -- Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ 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] What to do with languishing patches?
On Tue, Jul 20, 2010 at 3:05 PM, Oleg Broytman p...@phd.pp.ru wrote: .. Well, I have never, because in any of these drop-down lists I can press a few first letters of the name and the cursor jumps to the country. I often select countries in such lists in web browsers. Really? What smartphone are you using? :-) ___ 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] What to do with languishing patches?
On Tue, Jul 20, 2010 at 03:13:41PM -0400, Alexander Belopolsky wrote: On Tue, Jul 20, 2010 at 3:05 PM, Oleg Broytman p...@phd.pp.ru wrote: .. Well, I have never, because in any of these drop-down lists I can press a few first letters of the name and the cursor jumps to the country. I often select countries in such lists in web browsers. Really? What smartphone are you using? :-) Are you developing an interface for smartphones? Wouldn't it hurt usability for desktops/notebooks? Oleg. -- Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ 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] What to do with languishing patches?
On Tue, Jul 20, 2010 at 3:38 PM, Oleg Broytman p...@phd.pp.ru wrote: .. Really? What smartphone are you using? :-) Are you developing an interface for smartphones? Wouldn't it hurt usability for desktops/notebooks? You missed the smiley in my response. But seriously, I do find the interfaces that work well on smartphones to improve usability for desktops/notebooks. Back on the topic, I don't think a drop-down list of all modules is workable even in browsers that display them as combo boxes. How many modules do we have in std lib? About 100? Maybe more. What if the bug affects several modules? What if the patch modifies several modules? Do we want to allow selection of multiple modules for the given issue? The components window is already hard to use if you want to select say both Extension Modules and Windows. This is with just about 20 entries. Imagine over 100 entries there. ___ 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] What to do with languishing patches?
On Tue, Jul 20, 2010 at 04:27:45PM -0400, Alexander Belopolsky wrote: On Tue, Jul 20, 2010 at 3:38 PM, Oleg Broytman p...@phd.pp.ru wrote: .. Really? What smartphone are you using? :-) Are you developing an interface for smartphones? Wouldn't it hurt usability for desktops/notebooks? You missed the smiley in my response. I am a well-known wet blanket. (-: But seriously, I do find the interfaces that work well on smartphones to improve usability for desktops/notebooks. Sometimes they do and sometimes they don't. Big screen(s) and a wheeled multi-button mouse allow quite a different interface compared to small screen and single-finger taps. Back on the topic, I don't think a drop-down list of all modules is workable even in browsers that display them as combo boxes. How many modules do we have in std lib? About 100? Maybe more. What if the bug affects several modules? What if the patch modifies several modules? Do we want to allow selection of multiple modules for the given issue? The components window is already hard to use if you want to select say both Extension Modules and Windows. This is with just about 20 entries. Imagine over 100 entries there. In this particular case I'd rather tend to agree - an editable single-line box to enter space-*and*-comma-separated modules list would be the best interface. Oleg. -- Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ 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] MSDN subscription extensions?
As one of the beneficiaries of the efforts (much appreciated) last year to obtain Microsoft MSDN subscriptions for developers/testers (in my case, primarily buildbot operation), I was wondering if anyone might know if those subscriptions will be able to be renewed this year? -- David ___ 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] What to do with languishing patches?
In any case, a module list should be separate from components. On 7/20/2010 4:43 PM, Oleg Broytman wrote: In this particular case I'd rather tend to agree - an editable single-line box to enter space-*and*-comma-separated modules list would be the best interface. An interesting idea. In any case, a module list should be separate from components. A custom app would only allow entry there if Lib is a selected component. Such could also use a selecton screen with multiple columns rather than a single column. But we are limited to what can be done with a web interface. If Lib is not selected and modules are entered, Lib could be autoselected as it is unlikely that one would type in module names if it should not be. A back-end check against would be nice, but would suffer from the update problem, as well as module name changes. -- Terry Jan Reedy ___ 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] MSDN subscription extensions?
On Tue, Jul 20, 2010 at 16:53, David Bolen db3l@gmail.com wrote: As one of the beneficiaries of the efforts (much appreciated) last year to obtain Microsoft MSDN subscriptions for developers/testers (in my case, primarily buildbot operation), I was wondering if anyone might know if those subscriptions will be able to be renewed this year? -- David I'll add your name to the list, wait a few days for others to respond, then contact Microsoft together as a group. For anyone else out there with a current subscription which will be expiring soon, email me privately and I'll get you going with an extension. ___ 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] Does trace modules have a unit test?
On Wed, Jul 21, 2010 at 4:18 AM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: On Tue, Jul 20, 2010 at 2:12 PM, Reid Kleckner reid.kleck...@gmail.com wrote: .. IMO you should just rename test_trace.py to test_settrace.py, and put the trace.py tests in test_trace.py. +1 Yep, we're pretty free to rename stuff as required inside the test suite. The only real exception is test.support, as that's a documented standard library module. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] What to do with languishing patches?
On Wed, Jul 21, 2010 at 4:53 AM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: The only problem I can see with this feature is how to design a usable UI. Have you ever cursed these extra clever address forms that make you select a state from a drop-down list of 50 if not a country from the list of 100+? A text field with auto-completion/correction and validation would be the best, but may get cluttered if multiple modules are affected. We actually have similar usability issue with the nosy list. The + button was a great addition, but I would also like to see a user list integration that would allow me to add other by real name or by approximate username spelling. Despite the nosy list's issues, I think it is actually a better model here than the components list. That is: - comma separated list in main form that you can just type into - separate search form that pops up to allow multiple selections Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] mkdir -p in python
On 20Jul2010 17:49, Michael Foord fuzzy...@voidspace.org.uk wrote: | On 20/07/2010 14:43, Nick Coghlan wrote: | On Tue, Jul 20, 2010 at 11:09 PM, Steven D'Apranost...@pearwood.info wrote: | I'm -0 on adding an argument to os.makedirs, +0 on adding a variant | function to os, and +0.5 on adding the variant to the shutil module. | shutil seems like the place for it to me. The subtlety of getting the | error suppression correct makes it worth implementing this once and | for all I think. | | Really - so we have two almost identical functions with slightly | different behaviour in different standard library modules? Three if you count os.mkdir itself as well. | Aren't | the Python APIs for working with files and paths confused enough | already. That seems crazy to me and a switch on os.makedirs much | more sensible. +1 from me. Hasn't the BDFL blessed this particular suggestion too? Disclaimer: I am _not_ a dev. Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ I am not a free man, I am a number. - Beirne Konarski beir...@summitis.com ___ 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] mkdir -p in python
On Tue, Jul 20, 2010 at 11:35 PM, Cameron Simpson c...@zip.com.au wrote: On 20Jul2010 17:49, Michael Foord fuzzy...@voidspace.org.uk wrote: | On 20/07/2010 14:43, Nick Coghlan wrote: | On Tue, Jul 20, 2010 at 11:09 PM, Steven D'Apranost...@pearwood.info wrote: | I'm -0 on adding an argument to os.makedirs, +0 on adding a variant | function to os, and +0.5 on adding the variant to the shutil module. | shutil seems like the place for it to me. The subtlety of getting the | error suppression correct makes it worth implementing this once and | for all I think. | | Really - so we have two almost identical functions with slightly | different behaviour in different standard library modules? Three if you count os.mkdir itself as well. | Aren't | the Python APIs for working with files and paths confused enough | already. That seems crazy to me and a switch on os.makedirs much | more sensible. +1 from me. Hasn't the BDFL blessed this particular suggestion too? Now I have. :-) -1 on a new function (despite the constant-argument guideline) and +1 on a flag. If it weren't for backwards compatibility I'd just change os.makedirs() to act like mkdir -p period, but the last opportunity we had for that was Python 3.0. -- --Guido van Rossum (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] What to do with languishing patches?
Am 20.07.2010 23:09, schrieb Terry Reedy: In any case, a module list should be separate from components. On 7/20/2010 4:43 PM, Oleg Broytman wrote: In this particular case I'd rather tend to agree - an editable single-line box to enter space-*and*-comma-separated modules list would be the best interface. An interesting idea. And hardly a new idea :) I don't know how often I've now proposed tags for tracker issues... Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] mkdir -p in python
岳帅杰 wrote: Sorry, I don't know what is the no constant arguments guideline refers to. Could you give me some more explanation? It's a rule of thumb that Guido says he uses when designing an API. If in the majority of use cases for a proposed function, one of its arguments would always be a constant that chooses between two or more different behaviours, then it would probably be better to have separate functions for each of the behaviours. -- Greg ___ 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] mkdir -p in python
Steven D'Aprano wrote: Perhaps all we need is a recipe in the docs: try: os.makedirs(path) except OSError, e: if e.errno != 17: raise I don't like writing code that depends on particular errno values, because I don't trust it to work cross- platform. Also it seems suboptimal to require people to use a recipe like this to get the behaviour that is wanted in the overwhelming majority of cases. I don't see what would be so bad about adding a new function for this. Think of it as correcting the mistake of not making makedirs() behave this way from the beginning. -- Greg ___ 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] mkdir -p in python
I don't see what would be so bad about adding a new function for this. Think of it as correcting the mistake of not making makedirs() behave this way from the beginning. If you want to add a new function, then what its name should be? I guess it should be too similar as existing ones. It's confusing for using because they have similar names and do the same major things except exception. For users it's easier to remember one function than tow. If we want to correct a mistake, it's better not to import another mistake. I don't like writing code that depends on particular errno values, because I don't trust it to work cross- platform. I think in this case, the errno is generate by c standard library, which can be seen as cross-platform. -- Greg ___ 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/ysj.ray%2Bpython-dev%40gmail.com -- Ray Allen Best wishes! ___ 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] What to do with languishing patches?
R. David Murray writes: During the most recent discussion I can remember, I thought I remembered Stephen Trumble saying that they'd tried that in xemacs and it really hadn't worked very well. Since he now says he thinks it's a good idea (or more likely I misremembered what he said the first time), it sounds like we should consider it again. No, you didn't misremember. I changed my mind. Now I know more about *why* it didn't appeal to me at the time: the UI for links and multilinks with large numbers of selectable value, and we had a poor configuration of nosy lists, so people weren't getting on the right issues. So, I don't recommend it with the stock Roundup UI if there are going to be more modules than would fit on a page (50), and the UI is somewhat annoying for as few as 20 checkboxes. Unfortunately, I can't offer a patch, but the basic things that need to be done are (1) make the multilink input window multicolumn (you could get 100 module names to fit in the window, but 50 should be plenty for this purpose), and (2) bump the limit on entries per page so they all fit on one page. Also, it would be nice if there were a UI to make oneself auto-nosy on certain modules. ___ 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
