Re: [Python-Dev] A suggestion
On Sat, 17 Jul 2010 12:38:40 pm Brandon Hayden wrote: > In the Python language, or any other language for that matter, I have > never understood why they don't have a loop function. Here's what I > mean, every time someone wants something to repeat itself, they have > to write a while loop like this: > > x = 0 > while x < 10: > function() > x = x + 1 Perhaps you should learn a little more Python before criticising it. The idiomatic way to write the above is: for x in range(10): function() Anyway, this is the wrong forum for this discussion. If you're still interested in it, please take it to comp.lang.python or [email protected]. -- Steven D'Aprano ___ 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] IDLE contributors and committers
On 7/17/2010 7:33 AM, Antoine Pitrou wrote: > > Hello, > > On Sun, 11 Jul 2010 02:05:22 +0300 > Tal Einat wrote: >> >> I would like to propose removing IDLE from the standard library. >> >> I have been using IDLE since 2002 and have been doing my best to help >> maintain and further develop IDLE since 2005. > > I haven't seen any conclusive statement or action to this thread. > Without being an IDLE user myself (for good reason), I think that if > IDLE should stay, active contributors such as Tal should be given commit > access and enough free rein to maintain and improve it. > > Otherwise there's no reason to continue claiming that IDLE is important > while discouraging such people's contributions. The current situation, > where several core developers support IDLE's continued inclusion but > none actually cares for the issues and patches in the tracker, is > schizophrenic. > > Regards > > Antoine. +1 There's no reason why Tal should be obstructed in his goal of making IDLE at least acceptable again. It's fairly obvious thaat there aren't any committers who have both the inclination /and/ the time to do this, so adding Tal (and other interested parties) as a developer makes a lot of sense. 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 [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] IDLE contributors and committers
On 17/07/2010 12:47, Steve Holden wrote: On 7/17/2010 7:33 AM, Antoine Pitrou wrote: Hello, On Sun, 11 Jul 2010 02:05:22 +0300 Tal Einat wrote: I would like to propose removing IDLE from the standard library. I have been using IDLE since 2002 and have been doing my best to help maintain and further develop IDLE since 2005. I haven't seen any conclusive statement or action to this thread. Without being an IDLE user myself (for good reason), I think that if IDLE should stay, active contributors such as Tal should be given commit access and enough free rein to maintain and improve it. Otherwise there's no reason to continue claiming that IDLE is important while discouraging such people's contributions. The current situation, where several core developers support IDLE's continued inclusion but none actually cares for the issues and patches in the tracker, is schizophrenic. Regards Antoine. +1 There's no reason why Tal should be obstructed in his goal of making IDLE at least acceptable again. It's fairly obvious thaat there aren't any committers who have both the inclination /and/ the time to do this, so adding Tal (and other interested parties) as a developer makes a lot of sense. Guilherme's *existing* patch for IDLE looks like it improves it a great deal, at the cost of potentially requiring Tk 8.5 (?). Can this just be committed? https://code.google.com/p/python-ttk/wiki/Screenshots Michael Foord regards Steve -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] IDLE contributors and committers
On 17/07/2010 12:50, Michael Foord wrote: On 17/07/2010 12:47, Steve Holden wrote: On 7/17/2010 7:33 AM, Antoine Pitrou wrote: Hello, On Sun, 11 Jul 2010 02:05:22 +0300 Tal Einat wrote: I would like to propose removing IDLE from the standard library. I have been using IDLE since 2002 and have been doing my best to help maintain and further develop IDLE since 2005. I haven't seen any conclusive statement or action to this thread. Without being an IDLE user myself (for good reason), I think that if IDLE should stay, active contributors such as Tal should be given commit access and enough free rein to maintain and improve it. Otherwise there's no reason to continue claiming that IDLE is important while discouraging such people's contributions. The current situation, where several core developers support IDLE's continued inclusion but none actually cares for the issues and patches in the tracker, is schizophrenic. Regards Antoine. +1 There's no reason why Tal should be obstructed in his goal of making IDLE at least acceptable again. It's fairly obvious thaat there aren't any committers who have both the inclination /and/ the time to do this, so adding Tal (and other interested parties) as a developer makes a lot of sense. Guilherme's *existing* patch for IDLE looks like it improves it a great deal, at the cost of potentially requiring Tk 8.5 (?). Can this just be committed? https://code.google.com/p/python-ttk/wiki/Screenshots Michael Foord regards Steve IIRC Terry Reedy is also interested in moving IDLE forward. Some help will certainly be needed to work on the 3 high, 80 normal and 13 low priority issues that are open against IDLE on the issue tracker. Kindest regards. Mark Lawrence. ___ 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] Markup of command-line options in Python's .rst documentation
Hello, I'm currently working, together with Terry Reedy, on improving the documentation of the trace module, and I ran into a peculiar convention of marking command-line options which seems to be widespread. Consider the documentation of timeit, for instance: http://docs.python.org/dev/py3k/library/timeit.html The "--help" option appears as a hyperlink leading to http://docs.python.org/dev/py3k/using/cmdline.html#cmdoption--help, which is hardly relevant or useful. The same applies for several command-line options documented for the trace module (for example -m and -s). This is a result of the following markup (again, taking the timeit module as an example) in the relevant .rst file (Doc/library/timeit.rst): -h/:option:`--help` print a short usage message and exit The :option: markup seems to be translated by Sphinx into a link to the Python executable's own command line arguments. This creates the aforementioned problem in other modules as well, for example unittest. Is there really any merit in marking command-line options for modules with :option:, if it's only useful for Python's own options? Eli ___ 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] Markup of command-line options in Python's .rst documentation
On 17/07/2010 14:23, Eli Bendersky wrote: Hello, I'm currently working, together with Terry Reedy, on improving the documentation of the trace module, and I ran into a peculiar convention of marking command-line options which seems to be widespread. Consider the documentation of timeit, for instance: http://docs.python.org/dev/py3k/library/timeit.html The "--help" option appears as a hyperlink leading to http://docs.python.org/dev/py3k/using/cmdline.html#cmdoption--help, which is hardly relevant or useful. The same applies for several command-line options documented for the trace module (for example -m and -s). This is a result of the following markup (again, taking the timeit module as an example) in the relevant .rst file (Doc/library/timeit.rst): -h/:option:`--help` print a short usage message and exit The :option: markup seems to be translated by Sphinx into a link to the Python executable's own command line arguments. This creates the aforementioned problem in other modules as well, for example unittest. Is there really any merit in marking command-line options for modules with :option:, if it's only useful for Python's own options? If it links to the wrong thing then the markup is incorrect (unless it is due to a regression in Sphinx but I think that is unlikely). Michael Eli ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies ("BOGUS AGREEMENTS") that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] Markup of command-line options in Python's .rst documentation
> The "--help" option appears as a hyperlink leading to > http://docs.python.org/dev/py3k/using/cmdline.html#cmdoption--help, which is > hardly relevant or useful. [...] > > -h/:option:`--help` >print a short usage message and exit I think this is a doc bug in Doc/documenting/markup.rst :cmdoption: and :option: are not clearly distinguished; the latter creates references to using/cmdline, the former is what you’re looking for for documenting trace.py. Regards ___ 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] Markup of command-line options in Python's .rst documentation
On Sat, Jul 17, 2010 at 16:26, Michael Foord wrote: > On 17/07/2010 14:23, Eli Bendersky wrote: > > Hello, > > I'm currently working, together with Terry Reedy, on improving the > documentation of the trace module, and I ran into a peculiar convention of > marking command-line options which seems to be widespread. > > Consider the documentation of timeit, for instance: > http://docs.python.org/dev/py3k/library/timeit.html > > The "--help" option appears as a hyperlink leading to > http://docs.python.org/dev/py3k/using/cmdline.html#cmdoption--help, which > is hardly relevant or useful. > > The same applies for several command-line options documented for the trace > module (for example -m and -s). This is a result of the following markup > (again, taking the timeit module as an example) in the relevant .rst file > (Doc/library/timeit.rst): > > -h/:option:`--help` >print a short usage message and exit > > The :option: markup seems to be translated by Sphinx into a link to the > Python executable's own command line arguments. This creates the > aforementioned problem in other modules as well, for example unittest. Is > there really any merit in marking command-line options for modules with > :option:, if it's only useful for Python's own options? > > > If it links to the wrong thing then the markup is incorrect (unless it is > due to a regression in Sphinx but I think that is unlikely). > > Michael > Michael, What *should* it link to in case of modules, however? Is there some streamlined policy as to how module command line options should look and where they should be listed? From a cursory look on some documentation files, it's unlikely. Perhaps the answer is not to markup module options with :option: at all, because it's reserved for Python's own command-line options. Eli ___ 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] profiler decorator - is it worth for inclusion?
Provided a patch on the tracker: http://bugs.python.org/issue9285 Further comments can be submitted there, if any. --- Giampaolo http://code.google.com/p/pyftpdlib http://code.google.com/p/psutil 2010/7/15 Giampaolo Rodolà : > 2010/7/15 Brian Curtin : >> On Thu, Jul 15, 2010 at 13:45, Giampaolo Rodolà wrote: >>> >>> Today I was looking for a quick and dirty way to profile a method of a >>> class. >>> I was thinking that cProfile module had a decorator for this but I was >>> wrong so I decided to write one based on hotshot. >>> Would it be worth for inclusion? >> >> Since hotshot is gone in 3.x, I'd guess the chances are probably slim. >> ___ >> Python-Dev mailing list >> [email protected] >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com >> >> > > > Here's one using cProfile instead. > I was using hotshot because I wasn't aware of cProfile.Profile.runcall > which is currently not documented (I'm going to file a bug report). > > > def profile(sort='cumulative', lines=30, strip_dirs=True): > """A decorator which profiles a callable. > > Example usage: > > >>> @profile() > ... def factorial(n): > ... n = abs(int(n)) > ... if n < 1: > ... n = 1 > ... x = 1 > ... for i in range(1, n+1): > ... x = i * x > ... return x > ... > >>> factorial(5) > Thu Jul 15 20:58:21 2010 /tmp/tmpIDejr5 > > 4 function calls in 0.000 CPU seconds > > Ordered by: internal time, call count > > ncalls tottime percall cumtime percall filename:lineno(function) > 1 0.000 0.000 0.000 0.000 profiler.py:120(factorial) > 1 0.000 0.000 0.000 0.000 {range} > 1 0.000 0.000 0.000 0.000 {abs} > 1 0.000 0.000 0.000 0.000 {method 'disable' of > '_lsprof.Profiler' objects} > > 120 > """ > def outer(fun): > def inner(*args, **kwargs): > file = tempfile.NamedTemporaryFile() > prof = cProfile.Profile() > try: > ret = prof.runcall(fun, *args, **kwargs) > except: > file.close() > raise > > prof.dump_stats(file.name) > stats = pstats.Stats(file.name) > if strip_dirs: > stats.strip_dirs() > if isinstance(sort, tuple): > stats.sort_stats(*sort) > else: > stats.sort_stats(sort) > stats.print_stats(lines) > > file.close() > return ret > return inner > > return outer > > > --- Giampaolo > http://code.google.com/p/pyftpdlib > http://code.google.com/p/psutil > ___ 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] [Idle-dev] IDLE contributors and committers
On Sat, Jul 17, 2010 at 2:47 PM, Steve Holden wrote: > On 7/17/2010 7:33 AM, Antoine Pitrou wrote: >> >> Hello, >> >> On Sun, 11 Jul 2010 02:05:22 +0300 >> Tal Einat wrote: >>> >>> I would like to propose removing IDLE from the standard library. >>> >>> I have been using IDLE since 2002 and have been doing my best to help >>> maintain and further develop IDLE since 2005. >> >> I haven't seen any conclusive statement or action to this thread. >> Without being an IDLE user myself (for good reason), I think that if >> IDLE should stay, active contributors such as Tal should be given commit >> access and enough free rein to maintain and improve it. >> >> Otherwise there's no reason to continue claiming that IDLE is important >> while discouraging such people's contributions. The current situation, >> where several core developers support IDLE's continued inclusion but >> none actually cares for the issues and patches in the tracker, is >> schizophrenic. >> > +1 > > There's no reason why Tal should be obstructed in his goal of making > IDLE at least acceptable again. It's fairly obvious thaat there aren't > any committers who have both the inclination /and/ the time to do this, > so adding Tal (and other interested parties) as a developer makes a lot > of sense. I would certainly accept this as a first step. Although I now use IDLE much less than I have in previous years, I would be willing to put in some time towards fixing the major current issues and integrating the few polished enhancements. However, in the long run just allowing "heavy" contributors such as myself commit rights won't be enough. There's definitely a need for one or more active maintainers of IDLE who can take care of incoming bug reports and patches. We may hope that at least one serious contributor who is given commit rights will take up this position naturally, but perhaps a more active approach would be beneficial? I also think that there is a need for a guiding hand for IDLE, as Guido is for Python. It took a bit of time until I "got" the goals and principles of IDLE (e.g. easy to learn, minimal and obvious interface) by having KBK explain them in detail and explain the drawbacks of certain proposed changes. Having some kind of central authority is especially important in order to keep IDLE on track because the active development of IDLE is slow and done by various contributors -- there is currently no central group of active developers making such decisions. This doesn't have to be one person who also takes care of bugs, patches and testing, it could be someone who is just readily available via the idle-dev mailing list and keeps up with development of IDLE. Going along these lines of thought, I reach my original conclusion: IDLE is somewhat a project of its own. Perhaps considering IDLE a daughter-project of Python is appropriate, and continuing to develop it as part of the Python codebase could be reasonable, if more active maintainers can be found. I certainly support continuing to package it as part of the standard distribution. ___ 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] IDLE contributors and committers
On 7/17/2010 8:41 AM, Mark Lawrence wrote: IIRC Terry Reedy is also interested in moving IDLE forward. Interested, yes. But until either a) I can commit patches, or b) there is someone who will respond to commit review recommendations with "No, here is why not" or "Yes, committed", I will work on other issues, such as doc issues, for which I can get responses. I am certainly reluctant to recruit others to help, as I did for #9222, if there will be no action indefinitely. -- Terry Jan Reedy ___ 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] mkdir -p in python
I don't see that there is a function in the library that mimic the behavior of 'mkdir -p'. If 'makedirs' is used, it will generate an error if the file already exists. There are some functions available on the website to close the gap. But I'd prefer this is in the library. Is there any plan to add a function that mimic the behavior of 'mkdir -p'? http://code.activestate.com/recipes/82465-a-friendly-mkdir/ -- Regards, Peng ___ 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] IDLE contributors and committers
On 17/07/2010 22:57, Terry Reedy wrote: On 7/17/2010 8:41 AM, Mark Lawrence wrote: IIRC Terry Reedy is also interested in moving IDLE forward. Interested, yes. But until either a) I can commit patches, or b) there is someone who will respond to commit review recommendations with "No, here is why not" or "Yes, committed", I will work on other issues, such as doc issues, for which I can get responses. I am certainly reluctant to recruit others to help, as I did for #9222, if there will be no action indefinitely. This is standard Python behavour. The worst case I've come across is a patch that dated back to 2001 that had not been dealt with. But I'm staggered as to how a third party supplies a patch for (say) 2.3, it doesn't get applied, then the issue tracker simply keeps updating the version targeted until we're now at 3.2. That of course doesn't mean that anything will get done, better wait until py4.7? My approach is very simple, maybe even ruthless, but in the long term I believe it's better for everybody. Does this patch stay open, yes or no? At least it gets the mind focused. Some people have complained at me about my approach. Others have said great job. Obviously there's no correct or incorrect way, there's nowt as queer as folk. Reminds me of Canned Heat, "Let's stick together". Kindest regards. Mark Lawrence. ___ 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] More C API abstraction for user defined types
Nick Coghlan gmail.com> writes: > >On Wed, Jul 14, 2010 at 11:50 PM, Petre Galan gmail.com wrote: >> No. The right interface is PyNumber_Long. The purpose of the PyNumber_Index >> (and nb_index slot) is as index in slicing. > > Allowing other objects to say "I'm a real integer, treat me as one" is > exactly what the nb_index slot is for (see PEP 357). The use as an > index in slicing was just the primary initial use case and the one > that was chosen as the name for the new slot because nb_int was > already taken for the lossy transformation. Indexing is not (and never > has been) intended to be the only use case. > PyNumber_Long is the right interface as it's the right way to do it. PyNumber_Index allows me to compute a value as index in slicing, value that may be different that the integer behaviour of object. PyNumber_Index is serving it's purpose as index in slicing, beyond that it's getting abused. As for related discussions, float should not implement nb_int slot but be resolved in int's constructor. Petre ___ 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
