Re: [Python-Dev] Rationale for NamedTemporaryFile?
Greg Ewing schrieb: I've just discovered the hard way that NamedTemporaryFile automatically deletes the file when you close it. That doesn't seem very useful to me, since surely the reason you're using NamedTemporaryFile instead of TemporaryFile is that you want to do something else with it afterwards? What's the rationale for this behaviour? It now (2.6) has a keyword argument for not closing the file. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Encouraging developers
Tony Meyer schrieb: ISTM that there is value in submitting a patch (including tests and documentation, and making appropriate comment in related patches), even if that is all that is done (i.e. no follow-up). That's certainly, absolutely, true. It's also true that there are very many kinds of different contributions, e.g. a bug report is a contribution, too. However, some contributions bring the project forward more than others, e.g. a patch often brings it further along than a bug report, and a patch contributor willing to rework the patch brings it further along than a contributor that just drops the patch into the tracker (after developing it first, of course). Given that we are not able to process all contributions, we clearly have to make choices what contributions to look at, and what contributions to ignore. This, unfortunately, means that some patches get rejected just because neither the submitter nor any of the reviewers is willing to complete it, if it is incomplete at the time of submission. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
Now that this thread has celebrated its 100th message, I feel compelled to say something. My first observation is that this is a tempest in a teacup. My second observation is that there seems to have been a lack of people skills all around. That is perhaps to expect in a community of geeks, but given the length of the previous thread on this topic (before Martin checked it in) I think all the participants might have done wiser by taking each others' feelings into account rather than attempting to relentlessly arguing the technical point at hand. My third observation is tha a policy that would have disallowed or allowed (depending on your POV) this particular change is not an option. A policy isn't going to solve all disagreements, there will always be debate possible about the interpretations of the rules. What's needed is a way to handle such debate in a way that produces an outcome without wearing everyone out. It's important that the participants in the debate respect each other -- before, during and after the debate. If you want, I can make a decision. But I will only do that if I hear from both sides of the debate that they are willing to accept my choice even if it favors the other party. Can I hear agreement to that? In particular; Phillip and Glyph, if I decide that Martin's change is OK for 2.6, will you accept it and stop debating it and get on with your lives? And Martin, if I decide that the change should be rolled back, will you be okay with that? This is an experiment for me as well; if you all would prefer me to stay out of it, I will. I haven't made up my mind yet about the technical issue, but I'm not interested in hearing the arguments repeated; I've heard them all and just need to mull it over. Let me know. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
Guido van Rossum schrieb: And Martin, if I decide that the change should be rolled back, will you be okay with that? Certainly. I would wish somebody contributed a documentation patch pointing out that specific detail in the documentation (and in the process making the documentation match the implementation in the first place), but if nobody comes along, I would do that myself. This is an experiment for me as well; if you all would prefer me to stay out of it, I will. I would hope that we can agree to something that has been proposed as an alternative in http://python.org/sf/1681842 (suggesting a warning message and keyword arguments), or the two-step change that Thomas proposed, so you may want to watch this going on for a little while longer. However, I don't feel qualified anymore to trust my intuition on what changes are acceptable and which aren't, so it would be for some other committer (perhaps Thomas or Phillip) to actually implement such a change. HTH, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
Guido van Rossum wrote: If you want, I can make a decision. But I will only do that if I hear from both sides of the debate that they are willing to accept my choice even if it favors the other party. Can I hear agreement to that? From me - definitely. I put my position forward (anti this change, partly because it only addressed one of the special cases), and then stayed out of it. Happy mulling! Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
Delaney, Timothy (Tim) wrote: From me - definitely. Damned Outlook, reformatting sent emails! That statement was obviously from me ... Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rewrite of cmath module?
[Mark Dickinson] The current cmath module has some significant numerical problems, particularly in the inverse trig and inverse hyperbolic trig functions. IIRC, cmath was essentially whipped up over a weekend by a scientist, transcribing formulas from a math reference. Such an approach is bound to suffer significant numerical problems, but has the advantage of taking little time to implement ;-) A few of the worst have been improved (e.g., see c_quot(), which contains the original code in a comment), but no systematic effort has been made. ... I'm wondering whether anyone would be interested in a rewrite of the cmath module. I have a drop-in replacement written in pure Python, based largely on the formulas given by Kahan in his `Much Ado about Nothing's Sign Bit' article, which I believe eliminates the vast majority of the current numerical problems. I believe that :-) Besides the numerical fixes, the only significant difference from the current behaviour is that the branch cuts for asinh have been moved. (The docs suggest that the current branch cuts for asinh should be regarded as buggy). I'm offering to translate this into C and add appropriate documentation and test cases, but I have a couple of questions before I start. Make the Python implementation available first and solicit feedback from the Numeric community? (1) Is there actually any interest in fixing this module? I guess that the cmath module can't be used that much, otherwise these problems would have surfaced before. That's the rub: most people don't use cmath, while most who do have no idea what these functions should return. If there's a gross problem, most wouldn't even notice. The few places in cmath that have been improved were due to users who did notice. Of course all should be fixed. (2) (Disregard if the answer to question 1 is `No'.) What should be done about branch cuts? The value of a function on a branch cut is going to depend on signs of zeros, so it'll be pretty much impossible to make any guarantees about the behaviour. Even so, there are two approaches that seem feasible: ... Follow the C99 standard whenever possible. C99 added a complex type to C, and added complex-valued math functions too. Alas, C99 hasn't been widely adopted yet, but Python should be compatible with the platform C implementation to the extent possible. Of course the easiest way to do that is to /use/ the platform C implementation when possible. ... (3) Is it worth trying to be consistent in exceptional cases? The current math module documentation notes that math.log(0) might produce -inf on one platform and raise ValueError on another, so being consistent about whether a non-representable result gives a NaN, an infinity or a Python exception seems as though it would be tricky. I should also note that I've made no effort to do the right thing when the argument to any of the functions contains a NaN or an infinity in either the real or imaginary part. Welcome to the club ;-) To the extent that your code relies on real-valued libm functions, you inherit uncertainties from the platform C's implementation of those too. There's a long debate about whether that's a feature (Python math functions act the same way as the platform C's, and likely the platform Fortran's too) or a bug (Python acts differently on different platforms). Feature is the traditional answer to that. ... [list of specific bad behaviors] ... One more thing: since this is my first post to python-dev I should probably introduce myself. I'm a mathematician, working mostly in number theory. I learnt programming and numerical analysis the hard way, coding service-life prediction algorithms for rocket motors in Fortran 77 during several long summers. I've been using Python for more than ten years, mainly for teaching but also occasionally for research purposes. Of course a strong background in math is very helpful for this. If you also spent several long summers cleaning sewers with your bare hands, your qualifications for working on libm functions are beyond reproach ;-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rationale for NamedTemporaryFile?
Damien Miller wrote: That annoyed me too, so I submitted a patch[1] that was recently committed. That looks good. Seems to me it should really be the default behaviour, but I suppose that would break code that was relying on the automatic deletion. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
On 18 Mar, 07:53 pm, [EMAIL PROTECTED] wrote: My second observation is that there seems to have been a lack of people skills all around. That is perhaps to expect in a community of geeks, but given the length of the previous thread on this topic (before Martin checked it in) I think all the participants might have done wiser by taking each others' feelings into account rather than attempting to relentlessly arguing the technical point at hand. Let me take the opportunity to make this clear, then. I have the utmost respect for Martin and his contributions for Python. I have been following commits for quite a while and I know that Martin, in particular, is often the one who deals with the crap work of reviewing huge piles of orphaned patches and fixing piles of minor issues, and he is therefore responsible for much of the general upward trend in Python's overall quality in the last few releases. I appreciate that very much. My first observation is that this is a tempest in a teacup. On the one hand I agree. This particular change is trivial, most likely doesn't affect me, and I accept that, in practice, it probably won't even break too many programs (and may even fix a few). On the other, I think it is important to quell the tempest before it exits the teacup. Previously in this discussion, both I and PJE have repeatedly declared that this _particular_ change is not really what's at issue here, merely the pattern of reasoning that comes to consider this change acceptable. At some point a large number of small breakages are actually worse than one big one, and it's hard to point to the exact place where that happens. On the gripping hand, I am almost glad that it was a relatively minor change that triggered this avalanche of posts. Even with such a small change, the change itself threatens to obscure a larger issue, and if the change itself were any bigger, it would eclipse the other discussion completely. My third observation is tha a policy that would have disallowed or allowed (depending on your POV) this particular change is not an option. A policy isn't going to solve all disagreements, there will always be debate possible about the interpretations of the rules. What's needed is a way to handle such debate in a way that produces an outcome without wearing everyone out. The allow vs. disallow issue is not *really* what the policy should be addressing. A major problem with this thread is the differing definitions that some people have, beginning with extension, but I can't see that a policy will fix *that*. Words like bug, fix, compatible, and so on, all have obvious general meanings but much more nuanced and specific meanings in particular contexts. A policy should outline specifics of what, for example, is to be considered an incompatible change, and what must be done in that case. A policy could not outright forbid changes of a certain type, since that is pretty much asking that it be broken any time a sufficiently important change is requested and the core team likes it. Maybe policy isn't even the right word here, since the part of it that would facilitate discussions like this one would be more lexicon than policy. It's important that the participants in the debate respect each other -- before, during and after the debate. Agreed. Any lack of people skills notwithstanding, I hope I haven't said anything that implied (or stated, of course) that I did not *respect* the other participants of the discussion. If I have, I retract it. Strong disagreement is different than disrespect. If you want, I can make a decision. But I will only do that if I hear from both sides of the debate that they are willing to accept my choice even if it favors the other party. Can I hear agreement to that? In particular; Phillip and Glyph, if I decide that Martin's change is OK for 2.6, will you accept it and stop debating it and get on with your lives? And Martin, if I decide that the change should be rolled back, will you be okay with that? I will certainly accept the decision. I don't *like* generating trouble on this mailing list, believe me. Once a BDFL pronouncement is made, further discussion is just generating trouble. That isn't the same as *agreeing* with the decision, of course :-). The important thing for me is not reaching a decision on this particular issue (or even a particular decision on this particular issue). It is that we achieve some kind of consensus around how backward compatibility is supposed to work in the large rather than in a particular instance. For those of you who don't think this issue is important in and of itself, consider the secondary consequence of this ruckus happening every time someone commits a potentially-incompatible change. I would not mind if, for example, this patch were grandfathered in to the lack of any clear backwards compatibility policy, as long as similar future changes were subject to
