Re: [Python-Dev] More C API abstraction for user defined types
On Sun, Jul 18, 2010 at 3:12 PM, Petre Galan wrote: > 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. What's your basis for making that assertion? As one of the devs involved in adding PyNumber_Index and getting it to work properly, I like to think I have some idea as to the purpose of the slot. nb_int = can be coerced to int, but may lose numerical precision in the process nb_index = can be coerced to int without losing numerical precision (used for indexing, slicing and sequence repetition) It's somewhat unintuitive, but that's backwards compatibility for you. To quote the relevant part of PEP 357: Why not use nb_int which is already there? The nb_int method is used for coercion and so means something fundamentally different than what is requested here. This PEP proposes a method for something that *can* already be thought of as an integer communicate that information to Python when it needs an integer. The biggest example of why using nb_int would be a bad thing is that float objects already define the nb_int method, but float objects *should not* be used as indexes in a sequence. Why the name __index__? Some questions were raised regarding the name __index__ when other interpretations of the slot are possible. For example, the slot can be used any time Python requires an integer internally (such as in "mystring" * 3). The name was suggested by Guido because slicing syntax is the biggest reason for having such a slot and in the end no better name emerged. See the discussion thread: http://mail.python.org/pipermail/python-dev/2006-February/thread.html#60594 for examples of names that were suggested such as "__discrete__" and "__ordinal__". So, what spec are you using to say that you're right and I'm wrong? (Now, I'd agree the documentation is a little lacking in this area, as the docs for operator.index, PyNumber_Index and __index__ don't explain very well how they differ semantically from int, PyNumber_Int and __int__, but that's a separate issue. PEP 357 explains the intent quite clearly, even if the published documentation doesn't do so) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] Windows process creation flags
I was reading http://msdn.microsoft.com/en-us/library/ms684863%28v=VS.85%29.aspx and http://stackoverflow.com/questions/89228/how-to-call-external-command-in-python#2251026 when I realized that the process creation flags for subprocess.Popen on Windows are not specified anywhere in the standard library. I was thinking of putting them in os or subprocess by prepending a P_ to their MSVC++ names as listed above. It seems like a fairly minor, uncontroversial idea. Can we patch it in? Please CC all replies to this message back to [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows process creation flags
On 18/07/2010 00:25, [email protected] wrote: I was reading http://msdn.microsoft.com/en-us/library/ms684863%28v=VS.85%29.aspx and http://stackoverflow.com/questions/89228/how-to-call-external-command-in-python#2251026 when I realized that the process creation flags for subprocess.Popen on Windows are not specified anywhere in the standard library. I was thinking of putting them in os or subprocess by prepending a P_ to their MSVC++ names as listed above. It seems like a fairly minor, uncontroversial idea. Can we patch it in? Please CC all replies to this message back to [email protected] Could you create an issue on the Python bug tracker for this, preferably with a patch. Thanks Michael Foord ___ 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/ ___ 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] mkdir -p in python
On 17/07/2010 23:03, Peng Yu wrote: 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/ Presumably a new keyword argument could be added to os.makedirs. Could you raise a feature request on the python bug tracker, preferably with patch and tests of course! It would be worth searching to see if there is an existing feature request for this, and if so you can add a comment to it. All the best, Michael Foord -- http://www.ironpythoninaction.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] mkdir -p in python
On 17/07/2010 11:03 PM, Peng Yu wrote: 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'? If I were you I'd ping Tarek who's taken ownership of the shutil module. It would go there if it went anywhere. That said, it's not clear just how far the stdlib should go to mimic every switch and option of shell commands... TJG ___ 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:44, Eli Bendersky wrote: On Sat, Jul 17, 2010 at 16:26, Michael Foord mailto:[email protected]>> 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. :option: is "reserved" for Python command line options so *shouldn't* be used for module options. We don't have specific markup for module options, so just ``code`` markup I guess. 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/ ___ 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] mkdir -p in python
On Sun, Jul 18, 2010 at 11:30 AM, Tim Golden wrote: > On 17/07/2010 11:03 PM, Peng Yu wrote: >> >> 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'? > > If I were you I'd ping Tarek who's taken ownership of the shutil > module. It would go there if it went anywhere. > > That said, it's not clear just how far the stdlib should go to > mimic every switch and option of shell commands... Well, it really should have behaved like mkdir -p in the first place. Eric Raymond submitted the code ages ago, and at the time I wasn't familiar with mkdir -p, otherwise, I would have made him change it. I believe every single use of os.mkdirs() I've made goes something like this: if not os.path.exists(x): os.mkdirs(x) or perhaps like this: try: os.mkdirs(x) except os.error: pass (Though the latter masks a bunch of other rare but possible failure modes -- often this is in throw-away code though where it doesn't matter or the next line will raise an exception that's good enough to diagnose the situation anyway.) -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] tracker contribution
Hello Mark, On Sun, 18 Jul 2010 00:45:09 +0100 Mark Lawrence wrote: > 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. Well, I would still encourage you to adopt a different approach. Simply bumping up bugs without adding any useful content to the discussion does not help much. Especially if you do so several times in a day, because it increases a lot the bandwidth of messages we have to deal to. And, given we have a limited amount of time and cognitive capacity to devote to Python (we're all volunteers), that means we either spend a lot of time reading your messages and context switching between several issues per day, or start filtering out your messages in order to stay focussed. And if we start doing the latter, it means you are just wasting your own time. It would be IMHO much more useful if you concentrated on a couple of issues which interest you, or which you feel competent in, and where you either: - produce a review of a posted patch - post a patch yourself - give suggestions as to how the issue could be solved (or, alternatively, explain why it is detrimental, or useless, or too late (etc.) to solve the issue) - ask questions to the original submitter if things seem fuzzy It is especially useful if you manage to produce a negative review, that is point out something wrong with the patch/issue. Things that can get wrong with a patch (non-exhaustive list follows): - the patch doesn't apply cleanly anymore (on the py3k or 2.7 SVN branch, depending on whether the issue regards 3.x or only 2.x) - the proposed solution breaks compatibility in an obvious or subtle way - the patch lacks unit tests - unit tests don't adequately test behaviour (too strict, too laxist, too fragile, etc.) - portability problems, i.e. patch wouldn't have guaranteed or proper behaviour on all platforms - inconsistent or improper coding style - performance problems on arguably performance-critical code - undesireable side effects - etc. I would stress that this kind of involvment would also be able to get you much higher on the learning curve than your current involvment does: i.e., non-trivial contributions will build the competences to improve both yourself (assuming that's something you're interested in) and the complexity, correctness and completeness of your future contributions. Which in the middle-term is generally quite gratifying. Regards Antoine. ___ 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] Function Operators
Dear python-dev, In mathematical notation, f*g = z->f(g(z)) and f^n = f*f*f... (n times). I often run into situations in python where such operators could result in cleaner code. Eventually, I decided to implement it myself and see how it worked in practice. However, my intuitive implementation [1] doesn't seem to work. In particular, despite what it says in function's documentation, function does not seem to be in __builtin__. Furthermore, when I try to implement this through type(f) (where f is a function) I get invalid syntax errors. I hope I haven't made some trivial error; I'm rather inexperienced as a pythonist. Christopher Olah [1] Sketch: def __builtin__.function.__mul__(self, f): return lambda x: self(f(x)) def __builtin__.function.__pow__(self, n): return lambda x: reduce(lambda a,b: [f for i in range(n)]+[x]) ___ 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] Function Operators
Usual disclaimer: python-dev is for the development *of* python, not *with*. See python-list, etc. That said, def declares new functions or methods, so you can't put arbitrary expressions in there like type(f).__mul__ . You can usually assign to things like that though, but in this case you run into trouble, as shown below: >>> def func(): pass ... >>> type(func) >>> def compose(f, g): ... return lambda x: f(g(x)) ... >>> type(func).__mul__ = compose Traceback (most recent call last): File "", line 1, in TypeError: can't set attributes of built-in/extension type 'function' As the interpreter says, it doesn't like people mucking with operator slots on built in types. Finally, if you like coding in that very functional style, I'd recommend Haskell or other ML derived languages. Python doesn't support that programming style very well by choice. Reid On Sun, Jul 18, 2010 at 8:34 AM, Christopher Olah wrote: > Dear python-dev, > > In mathematical notation, f*g = z->f(g(z)) and f^n = f*f*f... (n > times). I often run into situations in python where such operators > could result in cleaner code. Eventually, I decided to implement it > myself and see how it worked in practice. > > However, my intuitive implementation [1] doesn't seem to work. In > particular, despite what it says in function's documentation, function > does not seem to be in __builtin__. Furthermore, when I try to > implement this through type(f) (where f is a function) I get invalid > syntax errors. > > I hope I haven't made some trivial error; I'm rather inexperienced as > a pythonist. > > Christopher Olah > > > [1] Sketch: > > def __builtin__.function.__mul__(self, f): > return lambda x: self(f(x)) > > def __builtin__.function.__pow__(self, n): > return lambda x: reduce(lambda a,b: [f for i in range(n)]+[x]) > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/reid.kleckner%40gmail.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] tracker contribution
Antoine, You've just saved me from composing essentially the same message. I am top-posting because I have very little to add. Mark, I actually reviewed the issues that got closed thanks to your "bumping them up". That was 30+ issues over the last week or two. Quite impressive. However, I see you "nosy" on about 180 open issues. This raises a question about signal to noise ratio that Antoine mentioned. I would like to join Antoine recommending that you concentrate on issues that you are competent in. In addition, I think your breadth first approach is also valuable, but don't comment of every issue that you read. Unless you feel that the issue was simply forgotten (last message is from OP and no response from assignee or issue is not assigned), it may be better to move on when you don't have something meaningful to contribute. On Sun, Jul 18, 2010 at 10:34 AM, Antoine Pitrou wrote: .. > On Sun, 18 Jul 2010 00:45:09 +0100 > Mark Lawrence wrote: .. >> 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. > > Well, I would still encourage you to adopt a different approach. > Simply bumping up bugs without adding any useful content to the > discussion does not help much. Especially if you do so several times in > a day, because it increases a lot the bandwidth of messages we have to > deal to. And, given we have a limited amount of time and cognitive > capacity to devote to Python (we're all volunteers), that means we > either spend a lot of time reading your messages and context switching > between several issues per day, or start filtering out your messages in > order to stay focussed. And if we start doing the latter, it means you > are just wasting your own time. > > It would be IMHO much more useful if you concentrated on a > couple of issues which interest you, or which you feel competent in, > and where you either: > > - produce a review of a posted patch > - post a patch yourself > - give suggestions as to how the issue could be solved (or, > alternatively, explain why it is detrimental, or useless, or too late > (etc.) to solve the issue) > - ask questions to the original submitter if things seem fuzzy > > It is especially useful if you manage to produce a negative review, > that is point out something wrong with the patch/issue. Things that can > get wrong with a patch (non-exhaustive list follows): > > - the patch doesn't apply cleanly anymore (on the py3k or 2.7 SVN > branch, depending on whether the issue regards 3.x or only 2.x) > - the proposed solution breaks compatibility in an obvious or subtle way > - the patch lacks unit tests > - unit tests don't adequately test behaviour (too strict, too laxist, > too fragile, etc.) > - portability problems, i.e. patch wouldn't have guaranteed or proper > behaviour on all platforms > - inconsistent or improper coding style > - performance problems on arguably performance-critical code > - undesireable side effects > - etc. > > I would stress that this kind of involvment would also be able to get > you much higher on the learning curve than your current involvment does: > i.e., non-trivial contributions will build the competences to improve > both yourself (assuming that's something you're interested in) and the > complexity, correctness and completeness of your future contributions. > Which in the middle-term is generally quite gratifying. > > Regards > > Antoine. ___ 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] What to do with languishing patches?
On Sat, Jul 17, 2010 at 7:45 PM, Mark Lawrence wrote: > On 17/07/2010 22:57, Terry Reedy wrote: .. >> 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? > If this is the reputation that Python gets as a project, I think it is alarming. I was going to dismiss Mark's comment as over dramatizing the situation, but unfortunately it is not. Let me focus on a specific example not because it is important, but because it illustrates many different problems in an easy to understand case. The issue is http://bugs.python.org/issue1699259, which is a very simple patch submitted back in 2007. I came across that patch a year an a half later and posted a review. OP responded the next day and posted an updated patch. I gave the resulting patch a positive review, but the timing was unfortunate because it was during RC phase for 3.0. At the time, I made a prediction that 'deferring [the patch] to 2.7 and 3.1 [was] virtually equivalent to closing with "won't fix"'. That was quite right: the next comment came a year later with "Moving the 3.1 target to 3.2, since 3.1 is out" only to be forgotten for another year to be rediscovered in Mark's recent crusade. As I said, the issue is not an important one, but I noticed that OP did not submit any other patch or commented on any other issue since then. It is impossible to tell if he was turned off by the lack of attention to his patch, but I think it is likely that Python is loosing contributors when they submit a patch, respond to reviews and see their patch languish for no specified reason. I think there is at least one improvement that we can make. We can set up a mechanism that will assure that acceptable patches that don't get applied because they come at the wrong time in development cycle, get applied early in the development of the next release. We already have "posponed" and "remind" resolutions, but these are exclusive of "accepted". I think there should be a clear way to mark the issue "accepted and would be applied if X.Y was out already." Chances are one of the resolution labels already has such meaning, but in this case it should be more prominently documented as such. ___ 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] Function Operators
On 07/18/2010 05:52 PM, Reid Kleckner wrote: > Usual disclaimer: python-dev is for the development *of* python, not > *with*. See python-list, etc. Moving to python-list. Please keep discussion there. > > That said, def declares new functions or methods, so you can't put > arbitrary expressions in there like type(f).__mul__ . > > You can usually assign to things like that though, but in this case > you run into trouble, as shown below: > def func(): pass > ... type(func) > def compose(f, g): > ... return lambda x: f(g(x)) > ... type(func).__mul__ = compose > Traceback (most recent call last): > File "", line 1, in > TypeError: can't set attributes of built-in/extension type 'function' > > As the interpreter says, it doesn't like people mucking with operator > slots on built in types. > > Finally, if you like coding in that very functional style, I'd > recommend Haskell or other ML derived languages. Python doesn't > support that programming style very well by choice. > > Reid > > On Sun, Jul 18, 2010 at 8:34 AM, Christopher Olah > wrote: >> Dear python-dev, >> >> In mathematical notation, f*g = z->f(g(z)) and f^n = f*f*f... (n >> times). I often run into situations in python where such operators >> could result in cleaner code. Eventually, I decided to implement it >> myself and see how it worked in practice. >> >> However, my intuitive implementation [1] doesn't seem to work. In >> particular, despite what it says in function's documentation, function >> does not seem to be in __builtin__. Furthermore, when I try to >> implement this through type(f) (where f is a function) I get invalid >> syntax errors. >> >> I hope I haven't made some trivial error; I'm rather inexperienced as >> a pythonist. >> >> Christopher Olah >> >> >> [1] Sketch: >> >> def __builtin__.function.__mul__(self, f): >>return lambda x: self(f(x)) >> >> def __builtin__.function.__pow__(self, n): >>return lambda x: reduce(lambda a,b: [f for i in range(n)]+[x]) As Reid explained, you can't just muck around with built-in types like that. However, you can "use a different type". If you're not familiar with Python decorators, look them up, and then have a look at this simple implementation of what you were looking for: >>> class mfunc: ... def __init__(self, func): ... self.func = func ... self.__doc__ = func.__doc__ ... self.__name__ = func.__name__ ... def __call__(self, *args, **kwargs): ... return self.func(*args, **kwargs) ... def __mul__(self, f2): ... @mfunc ... def composite(*a, **kwa): ... return self.func(f2(*a, **kwa)) ... return composite ... def __pow__(self, n): ... if n < 1: ... raise ValueError(n) ... elif n == 1: ... return self.func ... else: ... return self * (self ** (n-1)) ... >>> @mfunc ... def square(x): return x*x ... >>> @mfunc ... def twice(x): return 2*x ... >>> (square*twice)(1.5) 9.0 >>> addthree = mfunc(lambda x: x+3) >>> addfifteen = (addthree ** 5) >>> addfifteen(0) 15 >>> ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tracker contribution
On 18/07/2010 15:34, Antoine Pitrou wrote: Hello Mark, On Sun, 18 Jul 2010 00:45:09 +0100 Mark Lawrence wrote: 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. Well, I would still encourage you to adopt a different approach. Simply bumping up bugs without adding any useful content to the discussion does not help much. Especially if you do so several times in a day, because it increases a lot the bandwidth of messages we have to deal to. And, given we have a limited amount of time and cognitive capacity to devote to Python (we're all volunteers), that means we either spend a lot of time reading your messages and context switching between several issues per day, or start filtering out your messages in order to stay focussed. And if we start doing the latter, it means you are just wasting your own time. It would be IMHO much more useful if you concentrated on a couple of issues which interest you, or which you feel competent in, and where you either: - produce a review of a posted patch - post a patch yourself - give suggestions as to how the issue could be solved (or, alternatively, explain why it is detrimental, or useless, or too late (etc.) to solve the issue) - ask questions to the original submitter if things seem fuzzy It is especially useful if you manage to produce a negative review, that is point out something wrong with the patch/issue. Things that can get wrong with a patch (non-exhaustive list follows): - the patch doesn't apply cleanly anymore (on the py3k or 2.7 SVN branch, depending on whether the issue regards 3.x or only 2.x) - the proposed solution breaks compatibility in an obvious or subtle way - the patch lacks unit tests - unit tests don't adequately test behaviour (too strict, too laxist, too fragile, etc.) - portability problems, i.e. patch wouldn't have guaranteed or proper behaviour on all platforms - inconsistent or improper coding style - performance problems on arguably performance-critical code - undesireable side effects - etc. I would stress that this kind of involvment would also be able to get you much higher on the learning curve than your current involvment does: i.e., non-trivial contributions will build the competences to improve both yourself (assuming that's something you're interested in) and the complexity, correctness and completeness of your future contributions. Which in the middle-term is generally quite gratifying. Regards Antoine. I'm extremely offended by your comments. I'll just back off and let the number of outstanding bugs grow and grow and grow, until such time as people get fed up with Python and go to (say) Ruby. 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] What to do with languishing patches?
On Jul 18, 2010, at 1:46 PM, Alexander Belopolsky wrote: > We already have "posponed" and "remind" resolutions, but these are > exclusive of "accepted". I think there should be a clear way to mark > the issue "accepted and would be applied if X.Y was out already." > Chances are one of the resolution labels already has such meaning, but > in this case it should be more prominently documented as such. This is what branches are for. When the X.Y release cycle starts, there should be a branch for X.Y. Any "would be applied" patches can simply be applied to trunk without interrupting anything; the X.Y release branch can be merged back into trunk as necessary. ___ 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] What to do with languishing patches?
On 18 July 2010 20:57, Glyph Lefkowitz wrote: > > On Jul 18, 2010, at 1:46 PM, Alexander Belopolsky wrote: > > We already have "posponed" and "remind" resolutions, but these are > exclusive of "accepted". I think there should be a clear way to mark > the issue "accepted and would be applied if X.Y was out already." > Chances are one of the resolution labels already has such meaning, but > in this case it should be more prominently documented as such. > > This is what branches are for. > When the X.Y release cycle starts, there should be a branch for X.Y. Any > "would be applied" patches can simply be applied to trunk without > interrupting anything; the X.Y release branch can be merged back into trunk > as necessary. Agreed. If that isn't already the recommended workflow under Mercurial, I'd suggest making it so. (I can imagine that under Subversion, where branching and merging is more awkward, it might have been deemed not worth doing). Paul. ___ 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] What to do with languishing patches?
On 18/07/2010 18:46, Alexander Belopolsky wrote: On Sat, Jul 17, 2010 at 7:45 PM, Mark Lawrence wrote: On 17/07/2010 22:57, Terry Reedy wrote: .. 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? If this is the reputation that Python gets as a project, I think it is alarming. I was going to dismiss Mark's comment as over dramatizing the situation, but unfortunately it is not. Let me focus on a specific example not because it is important, but because it illustrates many different problems in an easy to understand case. The issue is http://bugs.python.org/issue1699259, which is a very simple patch submitted back in 2007. I came across that patch a year an a half later and posted a review. OP responded the next day and posted an updated patch. I gave the resulting patch a positive review, but the timing was unfortunate because it was during RC phase for 3.0. At the time, I made a prediction that 'deferring [the patch] to 2.7 and 3.1 [was] virtually equivalent to closing with "won't fix"'. That was quite right: the next comment came a year later with "Moving the 3.1 target to 3.2, since 3.1 is out" only to be forgotten for another year to be rediscovered in Mark's recent crusade. As I said, the issue is not an important one, but I noticed that OP did not submit any other patch or commented on any other issue since then. It is impossible to tell if he was turned off by the lack of attention to his patch, but I think it is likely that Python is loosing contributors when they submit a patch, respond to reviews and see their patch languish for no specified reason. I think there is at least one improvement that we can make. We can set up a mechanism that will assure that acceptable patches that don't get applied because they come at the wrong time in development cycle, get applied early in the development of the next release. We already have "posponed" and "remind" resolutions, but these are exclusive of "accepted". I think there should be a clear way to mark the issue "accepted and would be applied if X.Y was out already." Chances are one of the resolution labels already has such meaning, but in this case it should be more prominently documented as such. Alexander, This strikes me as being simple, straight forward common sense, well put. Until such time as this happens, I'll carry on ploughing through the outstanding issues flagging up things to try and get them moved. Apologies to all and sundry if I tread on toes. 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? 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] What to do with languishing patches?
On Sun, Jul 18, 2010 at 4:32 PM, Paul Moore wrote: > On 18 July 2010 20:57, Glyph Lefkowitz wrote: .. >> This is what branches are for. >> When the X.Y release cycle starts, there should be a branch for X.Y. Any >> "would be applied" patches can simply be applied to trunk without >> interrupting anything; the X.Y release branch can be merged back into trunk >> as necessary. > > Agreed. If that isn't already the recommended workflow under > Mercurial, I'd suggest making it so. (I can imagine that under > Subversion, where branching and merging is more awkward, it might have > been deemed not worth doing). Do I understand it correctly that the proposal is to create an X.Y-maint branch at the time when alpha (or beta) release goes out rather than the current practice of creating the branch at the time of the final release? In this case issue1699259 patch could be committed to py3k branch without affecting what goes into 3.0. I still don't understand why "Python 2.6 is already out" was a reason not to commit it to trunk at the time. ___ 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] What to do with languishing patches?
[Removing idle-dev from CC] On Sun, Jul 18, 2010 at 5:02 PM, Mark Lawrence 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. If you could make a specific proposal on how this can be reorganized without adding much clutter to the interface and creating submitter confusion, I think it will be very helpful. Another feature that comes to mind is to allow searing for issues with patches that touch a particular file. I have not looked at the tracker code, but I think this should not be hard to implement. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tracker contribution
On Mon, Jul 19, 2010 at 4:43 AM, Mark Lawrence wrote: > I'm extremely offended by your comments. I'll just back off and let the > number of outstanding bugs grow and grow and grow, until such time as people > get fed up with Python and go to (say) Ruby. Please don't take it that way - Antoine and Alexander are just trying to help you make the most effective use of the time you spend contributing (which *is* appreciated!). In my case, I don't spend much time trawling the tracker for issues, so I'm reliant on other people kicking import related issues in my direction by adding me to the nosy list or bringing them up here on python-dev. I think a couple of the items you have commented on ended up on my plate and I should be able to do something about them. Cheers, Nick. P.S. 30 closures for 180 comments actually sounds like a reasonable SNR to me. Maybe my perspective is skewed by the fact that I'm not involved in most of them :) -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tracker contribution
On Sun, Jul 18, 2010 at 5:22 PM, Nick Coghlan wrote: > On Mon, Jul 19, 2010 at 4:43 AM, Mark Lawrence > wrote: >> I'm extremely offended by your comments. I'll just back off and let the >> number of outstanding bugs grow and grow and grow, until such time as people >> get fed up with Python and go to (say) Ruby. > > Please don't take it that way - Antoine and Alexander are just trying > to help you make the most effective use of the time you spend > contributing (which *is* appreciated!). > > In my case, I don't spend much time trawling the tracker for issues, > so I'm reliant on other people kicking import related issues in my > direction by adding me to the nosy list or bringing them up here on > python-dev. I think a couple of the items you have commented on ended > up on my plate and I should be able to do something about them. > > Cheers, > Nick. > > P.S. 30 closures for 180 comments actually sounds like a reasonable > SNR to me. Maybe my perspective is skewed by the fact that I'm not > involved in most of them :) And I'm with Nick here. I don't have the time or bandwidth to trawl the tracker :( So you bumping things to/for me helps. ___ 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] Fast Implementation for ZIP decryption
Hello list, resurrecting a rather old thread from here: http://mail.python.org/pipermail/python-dev/2009-August/091450.html I've actually come across a use case where faster zipfile decryption would be very helpful to me (though one could certainly argue that it's a frivolous case). I'm writing a map editor for a game whose graphics datafiles are stored inside an encrypted zipfile. I've received the game developer's blessing for my editor to be able to read inside the zipfile, so legality isn't an issue here, but the pure-Python decryption currently available in the 'zipfile' module really is dog-slow. When I have my app load directly from already-uncompressed files on the HD, it's rare for a map to take more than 1 second to load; when the app has to use the pure-Python decryption routines to load all the graphics images, it can take over a minute (and this is on a 3GHz Core 2 Duo). Bundling the necessary graphics with my app isn't an option, nor is asking users to crack the zipfile encryption themselves to provide an uncompressed directory to read from. So anyway, I'd at least love to have a peek at the C code mentioned in the thread; if nothing more, perhaps I could bundle it into something that could be installed optionally by someone who wants it. Does anyone still have this code available somewhere? Thanks a bunch, CJ -- WOW: Flemmy| "Happiness isn't good enough for me! I [email protected] | demand euphoria!" 24.24.2.3171 | - Calvin ___ 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] What to do with languishing patches?
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? If you think any specific feature is missing in the tracker, please post a report to the meta-tracker. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] What to do with languishing patches?
On Sun, Jul 18, 2010 at 6:10 PM, "Martin v. Löwis" 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? > > If you think any specific feature is missing in the tracker, please post > a report to the meta-tracker. This is an excellent point and for those who don't know what "meta-tracker" is, see the link to "Report Tracker Problem" at the bottom of left column on the main tracker page. The direct link is http://psf.upfronthosting.co.za/roundup/meta/ . (I did not know about the "meta-tracker" myself until a couple of months ago.) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tracker contribution
On 18/07/2010 22:24, Jesse Noller wrote: On Sun, Jul 18, 2010 at 5:22 PM, Nick Coghlan wrote: On Mon, Jul 19, 2010 at 4:43 AM, Mark Lawrence wrote: I'm extremely offended by your comments. I'll just back off and let the number of outstanding bugs grow and grow and grow, until such time as people get fed up with Python and go to (say) Ruby. Please don't take it that way - Antoine and Alexander are just trying to help you make the most effective use of the time you spend contributing (which *is* appreciated!). In my case, I don't spend much time trawling the tracker for issues, so I'm reliant on other people kicking import related issues in my direction by adding me to the nosy list or bringing them up here on python-dev. I think a couple of the items you have commented on ended up on my plate and I should be able to do something about them. Cheers, Nick. P.S. 30 closures for 180 comments actually sounds like a reasonable SNR to me. Maybe my perspective is skewed by the fact that I'm not involved in most of them :) And I'm with Nick here. I don't have the time or bandwidth to trawl the tracker :( So you bumping things to/for me helps. Nick, Jesse, Thank you for your kind comments, they're much appreciated. Now the fighter bombers dive in to finish of the last pockets of resistance. (from a Monty Python album in case you didn't know) What am I meant to do when as happened earlier today, I see an issue that was first raised two years ago, then a year later the OP has asked what if anything is happening? Leave it? That's a great advert for Python. How do I apply a patch that was raised *SEVEN* years ago to modern versions of Python? The issue is still open. I do my best to run the unit tests if they're available on an issue, but so often they're so old that it's all but impossible to apply them without a hell of a lot of manual work. If this had been done in the first place it wouldn't have been an issue. I believe that by now you get my drift. But to me the most infuriating thing on the bug tracker is when someone else has simply bumped the Python versions and that's it. No attempt at contacting the OP as to whether the issue is still applicable. No attempt to try the patches, all in all zilch. So I come along and attempt to backtrack years and get slagged off for it. Hell, I just wish I was fully healthy and had my MBCS/CEng status back, then I'd really feel capable of letting fly. Having worked on massive UK MOD projects (can't say much, Official Secrets Acts and all that stuff) and knowing a hell of a lot about change control, configuration management, call it what you like, quite frankly Python is years behind. But there I go again, can't rock the boat because someone might get upset, to hell with the poor sods putting in their patches years ago and being completely ignored. 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. But to hell with it, I'm as usual feeling absolutely shattered so I'm going to bed, please don't try to close too many issues whilst I'm sleeping, I won't have anything to do tomorrow afternoon. 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] Use of coding cookie in 3.x stdlib
I was looking at the inspect module and noticed that it's source starts with "# -*- coding: iso-8859-1 -*-". I have checked and there are no non-ascii characters in the file. There are several other modules that still use the cookie: Lib/ast.py:# -*- coding: utf-8 -*- Lib/getopt.py:# -*- coding: utf-8 -*- Lib/inspect.py:# -*- coding: iso-8859-1 -*- Lib/pydoc.py:# -*- coding: latin-1 -*- Lib/shlex.py:# -*- coding: iso-8859-1 -*- Lib/encodings/punycode.py:# -*- coding: utf-8 -*- Lib/msilib/__init__.py:# -*- coding: utf-8 -*- Lib/sqlite3/__init__.py:#-*- coding: ISO-8859-1 -*- Lib/sqlite3/dbapi2.py:#-*- coding: ISO-8859-1 -*- Lib/test/bad_coding.py:# -*- coding: uft-8 -*- Lib/test/badsyntax_3131.py:# -*- coding: utf-8 -*- I understand that coding: utf-8 is strictly redundant in 3.x. There are cases such as Lib/shlex.py where using encoding other than utf-8 is justified. (See http://svn.python.org/view?view=rev&revision=82560). What are the guidelines for other cases? Should redundant cookies be removed? Since not all editors respect the -*- cookie, I think the answer should be "yes" particularly when the cookie is setting encoding other than utf-8. ___ 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
Am 18.07.2010 00:45, schrieb Mark Lawrence: > 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. That phrasing implies that there is purpose behind letting issues rot. Believe me that this is not the case. > 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? If no developer can invest the time necessary before, yes. Better not to apply a patch than to rush in something that might have a negative impact in the long run. For code such as Python's standard library, we have to think very carefully about everything that could affect compatibility or introduce new bugs or regressions. I don't want to say that all patches are seriously flawed, but for most patches I applied I had to make some changes before committing, and I needed time enough to think about them. > 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. And this is what is great about what you're doing, because many issues can be closed immediately, and some after minor work. > 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. Of course committers are different. I guess that most who complained did what I did, saying "I think you're doing a great job, but try to ...". Why not take the advice? 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tracker contribution
On Sun, Jul 18, 2010 at 7:06 PM, Mark Lawrence wrote: .. > What am I meant to do when as happened earlier today, I see an issue that > was first raised two years ago, then a year later the OP has asked what if > anything is happening? Leave it? That's a great advert for Python. > > How do I apply a patch that was raised *SEVEN* years ago to modern versions > of Python? The issue is still open. I do my best to run the unit tests if > they're available on an issue, but so often they're so old that it's all but > impossible to apply them without a hell of a lot of manual work. If this > had been done in the first place it wouldn't have been an issue. > Don't get frustrated and don't give up. Python is valued for its stability and most patches are delayed for good reasons. Oftentimes the problem is simply nontrivial and the proposed patch is not obviously correct. In other cases the patch addresses a rare use case and is deemed not important enough to take priority over other things that are on developer's todo list. What to do with old patches? I would suggest the following steps: 1. Verify that the issue is still present in the latest releases. 2. Add a comment confirming that you were able to reproduce the bug and explain how. 3. Try to apply the patch. With a 7-year old patch your chances that it will apply cleanly are slim. Try both 2.x and 3.x branches. If patch contains tests, tests may apply but not code or the other way around. If you get any success, post your results. 4. If you find really egregious cases where you think that a valuable patch fell through the cracks, - bring it up here. By this time you probably have at least in your mind the list of issues that should have been closed long ago. Pick top three by value you think they would add and post here. I know first hand that posting a patch and see it linger until it does not apply anymore can be frustrating. One of the issues you flagged recently (http://bugs.python.org/issue4335) has a patch that I posted 1.5 years ago. It does not apply cleanly anymore and it would get a low priority on my list these days. Nevertheless, I appreciate the thorough approach that python developers take when it comes to accepting contributions or even committing their own changes. You may have noticed that developers with commit privileges often post their patches on the tracker first and get them reviewed before checking in. This is why python is such a high quality product. Once again, don't get frustrated. Your work is appreciated. There is room for all kinds of approaches to improving python and as long as you have time and desire to contribute, your contributions will make a difference. ___ 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] mkdir -p in python
Tim Golden wrote: That said, it's not clear just how far the stdlib should go to mimic every switch and option of shell commands... I don't think it's a matter of mimicking switches just because they're there. The operation of "make sure this directory and all its parents exist" is very commonly required, e.g. when installing software. It makes sense to have it easily available. -- Greg ___ 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/18/2010 7:42 PM, Georg Brandl wrote: That phrasing implies that there is purpose behind letting issues rot. Believe me that this is not the case. This seems like a good place to mention that doc issues have become a bright spot in the last few years, with a couple of days turnaround not unusual for an issue ready for commit review. This is one reason I have focused a bit on doc issues. It is rewarding. As I remember, a reason to switch from latex to sphinx/rst was so that more people could/would work on doc issues. That seems to have worked. And I do not think it bad is the docs catch up to the code by getting extra attention. -- 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
Re: [Python-Dev] Markup of command-line options in Python's .rst documentation
On Sat, Jul 17, 2010 at 16:44, Éric Araujo wrote: > > 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. > How would you guys recommend to proceed from here? The simplest approach for me is just use :cmdoption: instead of :option: in my work on trace.py . However, a few more things can be done if this is indeed "official policy": 1. Fix other modules that use :option: to use :cmdoption: instead (timeit, unittest and others) 2. Fix Doc/documenting/markup.rst to clarify which option kind goes where If these steps get approved I'll be happy to create an issue and submit patches to the relevant files. 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] What to do with languishing patches?
On 7/18/2010 5:05 PM, Alexander Belopolsky wrote: On Sun, Jul 18, 2010 at 4:32 PM, Paul Moore wrote: On 18 July 2010 20:57, Glyph Lefkowitz wrote: .. This is what branches are for. When the X.Y release cycle starts, there should be a branch for X.Y. Any "would be applied" patches can simply be applied to trunk without interrupting anything; the X.Y release branch can be merged back into trunk as necessary. Agreed. If that isn't already the recommended workflow under Mercurial, I'd suggest making it so. (I can imagine that under Subversion, where branching and merging is more awkward, it might have been deemed not worth doing). Do I understand it correctly that the proposal is to create an X.Y-maint branch at the time when alpha (or beta) release goes out rather than the current practice of creating the branch at the time of the final release? I would understand it to be at the point when some commits would otherwise be deferred and possibly forgotten. Whick is to say, first beta. I would expect that partial and then nearly complete closure of 'trunk' would work best if there were only a few committers who nearly all turn to bugs and then critical bugs during the beta and rc phases and who would not look at anything else during those phases. Of course, it would be best if pending patches for known bugs were applied before the split, so that the only patches applied to the new branch were for newly discovered bugs. -- 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
Re: [Python-Dev] Markup of command-line options in Python's .rst documentation
On Mon, Jul 19, 2010 at 05:57, Eli Bendersky wrote: > On Sat, Jul 17, 2010 at 16:44, Éric Araujo wrote: > >> > 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. >> > > How would you guys recommend to proceed from here? > > The simplest approach for me is just use :cmdoption: instead of :option: in > my work on trace.py . However, a few more things can be done if this is > indeed "official policy": > > 1. Fix other modules that use :option: to use :cmdoption: instead (timeit, > unittest and others) > 2. Fix Doc/documenting/markup.rst to clarify which option kind goes where > > If these steps get approved I'll be happy to create an issue and submit > patches to the relevant files. > > Eli > More input on this issue: 'cmdoption' is a directive, while 'option' is inline markup. Therefore I wouldn't say they're completely similar, just meant for different purposes. Both a directive and inline markup is useful for describing "official python executable options/flags". Regarding per-module options, I'm not sure special markup is needed at all. So a policy has to be define regarding the correct usage of these directives/markups, and probably documented in Doc/documenting/markup.rst 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 Sun, Jul 18, 2010 at 11:28 PM, Eli Bendersky wrote: > .. So a policy has to be define regarding the > correct usage of these directives/markups, and probably documented in > Doc/documenting/markup.rst I wonder if in addition to documenting proper markup you could add an option to argparse to generate help in ReST format. I understand that this will not be immediately useful for trace.py which uses getopt and getopt does not have enough structured data to generate good help. On the other hand, upgrading trace.py to use argparse may not be a bad idea. ___ 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 Mon, Jul 19, 2010 at 06:40, Alexander Belopolsky < [email protected]> wrote: > On Sun, Jul 18, 2010 at 11:28 PM, Eli Bendersky wrote: > > .. So a policy has to be define regarding the > > correct usage of these directives/markups, and probably documented in > > Doc/documenting/markup.rst > > I wonder if in addition to documenting proper markup you could add an > option to argparse to generate help in ReST format. I understand that > this will not be immediately useful for trace.py which uses getopt and > getopt does not have enough structured data to generate good help. On > the other hand, upgrading trace.py to use argparse may not be a bad > idea. > I actually considered switching to argparse when I noticed that trace.py still lives with getopt (personally I've long been using optparse). However, I wonder what this means for backwards compatibility. Is it valid to switch trace.py to use the newer command-line argument parsing module that's only available in the newest versions of Python? I guess it could be since trace.py is stdlib which always arrives with its relevant version of Python. This *would* mean, however, that trace.py would be incompatible between 2.7 (argparse) and 2.6 (which doesn't have argparse), but I'm not sure how much of a problem this is. 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 Sun, Jul 18, 2010 at 11:46 PM, Eli Bendersky wrote: .. > However, I wonder what this means for backwards compatibility. Is it valid > to switch trace.py to use the newer command-line argument parsing module > that's only available in the newest versions of Python? I guess it could be > since trace.py is stdlib which always arrives with its relevant version of > Python. This *would* mean, however, that trace.py would be incompatible > between 2.7 (argparse) and 2.6 (which doesn't have argparse), but I'm not > sure how much of a problem this is. As long as 3.x trace supports all command line options and switches that 2.x does, I don't see any compatibility problems. Adding more options or using new language or library features in implementation should be fine. ___ 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] Does trace modules have a unit test?
In reviewing http://bugs.python.org/issue9282 the issue came up, where is the unit test for trace.py? test/test_trace.py is actually a test of the line trace facility of sys.settrace (and should have been called test_linetrace or test_settrace). The only trace import Eli could find in Lib/test is the one in regrtest.py for the -T option. Have we missed something? If you say 'make one', what should be its name? Can the existing file be renamed (I gather this can be a bit of a problem)? -- 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
Re: [Python-Dev] Does trace modules have a unit test?
On Mon, Jul 19, 2010 at 07:02, Terry Reedy wrote: > In reviewing > http://bugs.python.org/issue9282 > the issue came up, where is the unit test for trace.py? > > test/test_trace.py is actually a test of the line trace facility of > sys.settrace (and should have been called test_linetrace or test_settrace). > The only trace import Eli could find in Lib/test is the one in regrtest.py > for the -T option. Have we missed something? > > If you say 'make one', what should be its name? Can the existing file be > renamed (I gather this can be a bit of a problem)? > I'd like to ask pydev another question on this issue. When thinking about adding unit tests for trace.py, I quickly realized it's not a usual module. Most of its output is either tracing reports to stdout, or even worse, to special files named .cover stdout output can be captured, but what about the .cover files? Can a Python unit test create temporary files in tmp/ (or somewhere else) as part of its testing, or is this forbidden? 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] Does trace modules have a unit test?
On Mon, Jul 19, 2010 at 12:12 AM, Eli Bendersky wrote: .. > stdout output can be captured, but what about the .cover files? Can a Python > unit test create temporary files in tmp/ (or somewhere else) as part of its > testing, or is this forbidden? > That's perfectly fine. Grep in the Lib/test directory for 'tempfile.mkdtemp()' to see examples. ___ 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] Does trace modules have a unit test?
On Mon, Jul 19, 2010 at 12:21 AM, Alexander Belopolsky wrote: > On Mon, Jul 19, 2010 at 12:12 AM, Eli Bendersky wrote: > .. >> stdout output can be captured, but what about the .cover files? Can a Python >> unit test create temporary files in tmp/ (or somewhere else) as part of its >> testing, or is this forbidden? >> > > That's perfectly fine. Grep in the Lib/test directory for > 'tempfile.mkdtemp()' to see examples. > Actually the first hit is Lib/test/script_helper.py which contains several utilities that you may find useful. ___ 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] Use of coding cookie in 3.x stdlib
Sounds like a good idea to try to remove redundant cookies *and* to remove most occasional use of non-ASCII characters outside comments (except for unittests specifically trying to test Unicode features). Personally I would use \xXX escapes instead of spelling out the characters in shlex.py, for example. Both with or without the coding cookies, many ways of displaying text files garble characters outside the ASCII range, so it's better to stick to ASCII as much as possible. --Guido On Mon, Jul 19, 2010 at 1:21 AM, Alexander Belopolsky wrote: > I was looking at the inspect module and noticed that it's source > starts with "# -*- coding: iso-8859-1 -*-". I have checked and there > are no non-ascii characters in the file. There are several other > modules that still use the cookie: > > Lib/ast.py:# -*- coding: utf-8 -*- > Lib/getopt.py:# -*- coding: utf-8 -*- > Lib/inspect.py:# -*- coding: iso-8859-1 -*- > Lib/pydoc.py:# -*- coding: latin-1 -*- > Lib/shlex.py:# -*- coding: iso-8859-1 -*- > Lib/encodings/punycode.py:# -*- coding: utf-8 -*- > Lib/msilib/__init__.py:# -*- coding: utf-8 -*- > Lib/sqlite3/__init__.py:#-*- coding: ISO-8859-1 -*- > Lib/sqlite3/dbapi2.py:#-*- coding: ISO-8859-1 -*- > Lib/test/bad_coding.py:# -*- coding: uft-8 -*- > Lib/test/badsyntax_3131.py:# -*- coding: utf-8 -*- > > I understand that coding: utf-8 is strictly redundant in 3.x. There > are cases such as Lib/shlex.py where using encoding other than utf-8 > is justified. (See > http://svn.python.org/view?view=rev&revision=82560). What are the > guidelines for other cases? Should redundant cookies be removed? > Since not all editors respect the -*- cookie, I think the answer > should be "yes" particularly when the cookie is setting encoding other > than utf-8. > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
