Re: [Python-Dev] Encouraging developers
Josiah Carlson writes: And the best way to encourage someone to maintain a package is... accepting their patches. And that's what I think is bull. Whether or not we want or need maintainers for module or package X is independant of the fact that user Y has submitted a patch for it. If they say, I would like to become maintainer of package X, ok, if they are better than not having a maintainer, great. But to ask them to be a maintainer of an unmaintained package because they submitted a patch? Actually, I regularly do this (three or four times a year, I'd guess, it would be more if there were more submitters) if the person seems sane. But I *don't* apply the patch! The condition is that he sign on to our process and shepherd his own patch through it (including the risk that a reviewer will ask for changes). The answer I typically get is No, I'd rather wait than work. But thanks for asking! :-) Caveat: the XEmacs packages where I do this are mostly end-user applications like MUAs or programmer editor modes, so it doesn't matter to anyone but the end-users if they break. Our process provides multiple workarounds for such a situation, and we do keep an eye on new maintainers to help out with emergency response in those cases, so that risk is considered acceptable. The users themselves generally accept one or two new maintainer problems with good humor, since they're proof positive that somebody has taken an interest in their package. The cost to this system is that you need people willing to mentor the new package maintainers. It works well for XEmacs because the cost is very low (as I just described). I think for Python's stdlib the cost would be substantially higher, but it might very well be worth it. A little game: without looking at this patch of mine, how much are you willing to bet that committing that patch is going to cause pain the Python community and other stdlib maintainers, to cause headaches like deprecations because of broken interfaces, and whatnot? I'm glad you asked. More than half of my commits (and way more than half the LOC) in February were due to broken previous patches that were approved merely because they addressed a bug and applied without fuzz to HEAD. :-( Committing patches unreviewed is a terrible idea. ___ 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] splitext('.cshrc')
Andrew Bennetts schrieb: Glyph's proposing that rather than risk breaking existing code (and in the worst possible way: silently, giving wrong answers rather than exceptions), we examine what benefits changing splitext would bring, and see if there's a way to get those benefits without that risk. I don't think that's an idea to dismiss out of hand. But I did list what I consider the benefits of the change to be, in http://mail.python.org/pipermail/python-dev/2007-March/071675.html (the message you are responding to). I don't see any other way of achieving these benefits without changing splitext, so I didn't propose any alternatives. I haven't seen any other proposal, either. At the moment you seem to be saying that because you're possibly fixing some currently buggy code, it's ok to possibly break some currently working code. I'm not sure that's a good idea, and I expect it will create headaches for someone trying to be compatible with both 2.5 and 2.6. I personally don't expect severe or massive breakage. It's a small detail. If the existing behaviour was clearly buggy by the existing documentation, rather than undefined, this would be less of a concern. The point about silent failures is an important one too. I see all these objections. I just don't see them outweigh the advantages. If splitext was removed and replaced with, say, a split_ext that behaves as you (and basically everyone, myself included) agrees it should behave, then code won't silently do the wrong thing. It will immediately and visibly fail, in an understandable way. Similarly, if split_ext was added side-by-side with splitext, and splitext changed to emit DeprecationWarnings for a release, there's minimal risk that existing code that works would break. I considered these alternatives, and rejected them. Outright removing splitext would break a lot of code, period. I can't see how this could possibly be better than the currently implemented change. Raising a DeprecationWarning would also break a lot code, although in a less aggressive way. Who is going to see these warnings? The end users, running Python applications and using libraries they have not written. Fixing them will involve a very large cost in the community (spread over many people). Raising a DeprecationWarning should not be taken lightly. OTOH, silently changing the current behavior might break some applications. Again, it is the users who will notice, but for this change, it will be less users, as I expect that breakage will be really uncommon. I wonder if First, do no harm should be an explicit guideline when it comes evaluating incompatible changes, even if they fix other things? If possible, sure. However, I don't see how this is possible here. All your proposed alternatives do more harm than the one implemented. All that said, I don't think I've ever used splitext myself, so I don't care so much about what happens to it. But I do worry about the general approach to backwards compatibility. It's not a general approach. It's a case-by-case decision. Please understand that *any* change is incompatible, in the sense that I can come up with an application that breaks under the change. Really. *ANY CHANGE*. So the only way to get 100% compatibility is to not change anything at all. 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] Encouraging developers
Giovanni Bajo schrieb: I can't see that the barrier at contributing is high. I think this says it all. It now appears obvious to me that people inside the mafia don't even realize there is one. Thus, it looks like we are all wasting time in this thread, since they think there is nothing to be changed. But I am blaming you because you don't admit the fact that there *is* a problem with the patch submission process. And we can't a solve a problem if we don't admit there is one in the first place. I do think there is a problem with patch processing - I just don't think the barrier at contributing is high. The fact that there are so many patches contributed is proof that the barrier is not high: many people feel they can submit a patch. You might be right, there's no way to really know of course. I think my patch is a good example of how my proposal can be good for the Python stdlib. My proposal (to recall) is to *automatically* apply any patch to stdlib which follows normal guidelines if the package has no maintainer and nobody objects in X days. While it would have worked in your case (although I still wonder who the automatic application of the patch should execute), please be ensured that this couldn't possibly work in general. Many patches are really really not acceptable in their initial form; for many of them, the biggest problem is that they lack documentation. There was a phase when patches got accepted with no documentation, for these modules, it was very difficult to come up with documentation in the following years. 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] splitext('.cshrc')
Josiah Carlson schrieb: Because we should refuse the temptation to guess, what about: Rename the posix splitext to X (for some X), and offer a function with identical functionality to the posix variant under win32, also available as X for that platform. Rename the (current) win32 splitext to Y (for some Y) and offer a function with identical functionality to the posix platform as name Y. Offer a new splitext that uses X on posix and Y on win32, but causes a DeprecationWarning with pointers to the two renamed functions that are available on both platforms. See my comment to Andrew. This would cause severe harm: there are many applications of splitext which work just fine and won't see any behavior change; there are those which actually got fixed; and then there are those that break. With the change, you are putting a burden on all three cases, and more so, on the users of the software. In addition, splitext should not be deprecated. It is a fine function, and I really don't see a conceptual need for two versions of it: you will only ever need the current one. For people who want the old platform-specific functionality in previous and subsequent Pythons, offer the ability to disable the DeprecationWarning via a module global; at least until the function is removed in some future Python, at which point path.splitext would cause an AttributeError . That assumes there is a need for the old functionality. I really don't see it (pje claimed he needed it once, but I remain unconvinced, not having seen an actual fragment where the old behavior is helpful). 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] Encouraging developers
On 08/03/07, Martin v. Löwis [EMAIL PROTECTED] wrote: Titus Brown schrieb: and it's not at all clear to outsiders like me how new features, old patches, and old bugs are dealt with. The simple answer is when we have time. There really is not more to it. Some patches get higher attention, e.g. because they fix serious bugs. Proposed new features of don't get any attention by the mafia, because Python will just work fine without the new feature. Just to elaborate a bit on Martin's comment. I (very occasionally) scan SF and review patches - I have no commit privilege, so that's all I can do. I find that having enough time is amazingly infrequent. Often, I start looking with all the best intentions, and get bogged down on one item, then find that real life has caught up and I've done what feels like nothing. As regards prioritisation, I don't know of any way of realistically doing this. All I do is scan the list (either from oldest to newest or vice versa depending on my mood) and look for interesting or important looking subjects. I suppose that emphasizes the need for using good subject lines, but not much else :-) As you can see, it's anything but scientific - and there's a lot of ways that important items could get missed. But it's not that way because I'm slacking, or snubbing particular areas or authors - it's just the best way I can find. If anyone can find a better way (and write it up as How to do bug/patch reviews and triage or something) that would be brilliant. I suspect there isn't one, though - at least with SF (Roundup may be better) and given the time and resources I have available. Paul. ___ 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
Martin v. Löwis wrote: - How can I know if a patch is still open? Easy: if it's marked as Open. - I found a problem, and know how to fix it, but what else need to do? Go to www.python.org, then CORE DEVELOPMENT, then Patch submission. - Found a problem in the docs, for this I must submit a patch or tell something about it? How? Read CORE DEVELOPMENT, Intro to development. - I found an error in the docs, and fixed it, but I'm spanish speaker and my english sucks, can I submit a patch with bad wording or I must ask somebody to write it ok? What would your intuition tell you to do? Really didn't the answers to this, just were examples of questions that people may need to do, and feel shy to do it in python-dev... Ok, but I know now that python-dev *is* the place to ask. It's important, to redirect new possible developers and people willing to help. patch, and perhaps the reviewer will catch the error. As a submitter, just submit the code, and George Yoshida will catch it. It's not strictly necessary that the documentation actually builds all the time. If you want to be sure it builds, run make html in Doc. Didn't know about the make html, :) Thanks! -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Italic text in the manual
(This might be a silly question..) In the dev stdlib reference there are lots of pages in which all text is in italics. Such as all chapters after chapter 18. Is it supposed to be that way? It looks quite ugly. -- mvh Björn ___ 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] Italic text in the manual
BJörn Lindqvist schrieb: (This might be a silly question..) In the dev stdlib reference there are lots of pages in which all text is in italics. Such as all chapters after chapter 18. Certainly not. In today's copy (8.3.07, 13:30 GMT), this starts between 18.17 and 18.17.1. However, looking at the tex, I cannot find anything suspicious. texcheck complains about a missing ), which I added, but it only was a problem of the text, not of the markup. Some tex guru will have to figure this out; please submit a bugreport (if you can't figure it out yourself). 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] splitext('.cshrc')
Martin v. Löwis wrote:
Phillip J. Eby schrieb:
I consider it correct, or at the least, don't think it should be
changed, as it would make the behavior more difficult to reason about
and introduce yet another thing to worry about when writing
cross-version code.
Now it's becoming difficult: several people in favor, some opposed...
I'll wait a bit longer, but will still likely commit it, unless
opposition gets stronger: If the current behavior is incorrect
(in the sense that it contradicts wide-spread intuition), then
an application worrying about this detail should surely make the
2.6 behavior also appear in 2.5 and earlier.
I'm not sure what people actually use splitext for: I guess there
are two applications:
a) given a list of file names, give me all those belonging to a
hard-coded list of extensions (e.g. .py, .pyc, .c, .h). These
won't break, since they likely won't search for all files
ending in .bash_profile - there is only one per directory,
and if the want it, they use the entire filename.
b) given a list of file names, classify them for display (the
way the Windows explorer works, and similar file managers).
They use MIME databases and the like, and if they are unix-ish,
they probably reject the current splitext implementation already
as incorrect, and have work-arounds. As these files now show
up with no extension, I rather expect that the work-around
won't trigger, and the default behavior will be the correct one.
c) Given a filename, make an appropriately named associated file.
pyo_name = os.path.splitext(name)[0] + '.pyo'
This argues for os.path.splitext('.pythonrc') == ('.pythonrc','')
--
-- Scott David Daniels
[EMAIL PROTECTED]
___
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] splitext('.cshrc')
On 3/7/07, Josiah Carlson [EMAIL PROTECTED] wrote:
Martin v. Löwis [EMAIL PROTECTED] wrote:
Now it's becoming difficult: several people in favor, some opposed...
What about changing the semantics of splitext and creating a new
function (available on all platforms) that does what the Windows version
currently does?
I don't understand only one thing, why do people need new functions?
You can anticipate the change today, and write functions that do
exactly what you need no matter which way (current or proposed) python
implements:
def ensurenew(path):
a,b = os.path.splitext(path)
if a == '': # also possibly check if a contains dots only
return b,a
return a,b
def ensureold(path):
a,b = os.path.splitext(path)
if b == '' and a.startswith('.'): # also possibly check if a
starts with multiple dots
return b,a
return a,b
Best regards,
Alexey.
___
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] splitext('.cshrc')
Scott David Daniels schrieb:
c) Given a filename, make an appropriately named associated file.
pyo_name = os.path.splitext(name)[0] + '.pyo'
This argues for os.path.splitext('.pythonrc') == ('.pythonrc','')
Indeed, somebody found that people apparently do
back_name = splitext(name[0]) + '.bak'
which would severely break if somebody tried to create backups of
dotfiles that way.
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] splitext('.cshrc')
On Thu, Mar 08, 2007 at 06:54:30PM +0100, Martin v. L?wis wrote: back_name = splitext(name[0]) + '.bak' back_name = splitext(name)[0] + '.bak' Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
On 3/8/07, Alexey Borzenkov [EMAIL PROTECTED] wrote: On 3/7/07, Josiah Carlson [EMAIL PROTECTED] wrote: Martin v. Löwis [EMAIL PROTECTED] wrote: Now it's becoming difficult: several people in favor, some opposed... What about changing the semantics of splitext and creating a new function (available on all platforms) that does what the Windows version currently does? I don't understand only one thing, why do people need new functions? You can anticipate the change today, and write functions that do exactly what you need no matter which way (current or proposed) python implements: [...snip...] On second thought I completely forgot about path parts. Best regards, Alexey. ___ 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] splitext('.cshrc')
Alexey Borzenkov schrieb: I don't understand only one thing, why do people need new functions? You can anticipate the change today, and write functions that do exactly what you need no matter which way (current or proposed) python implements: Indeed, that's also true. When people actually care, they can easily achieve compatibility across versions. 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
[Python-Dev] Moving test_unittest up in the test order
Now that unittest has a test suite, it would seem to make sense that it should be fairly high up in the testing order, since most of the regression suite depends on it. I'd like to have it included with test_grammar, test_opcodes, test_operations, etc, so that if a bug in unittest is causing other tests to fail, we don't have to wait until the end of the test run to find out. Thoughts? Collin Winter ___ 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] Moving test_unittest up in the test order
On 3/8/07, Collin Winter [EMAIL PROTECTED] wrote: Now that unittest has a test suite, it would seem to make sense that it should be fairly high up in the testing order, since most of the regression suite depends on it. I'd like to have it included with test_grammar, test_opcodes, test_operations, etc, so that if a bug in unittest is causing other tests to fail, we don't have to wait until the end of the test run to find out. Thoughts? Sounds reasonable to me, along with any tests for doctest. -Brett ___ 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] splitext('.cshrc')
At 11:53 AM 3/8/2007 +0100, Martin v. Löwis wrote: That assumes there is a need for the old functionality. I really don't see it (pje claimed he needed it once, but I remain unconvinced, not having seen an actual fragment where the old behavior is helpful). The code in question was a type association handler that looked up loader functions based on file extension. This was specifically convenient for recognizing the difference between .htaccess files and other dotfiles that might appear in a web directory tree -- e.g. .htpasswd. The proposed change of splitext() would break that determination, because .htpasswd and .htaccess would both be considered files with empty extensions, and would be handled by the empty extension handler. ___ 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] Moving test_unittest up in the test order
On 3/8/07, Brett Cannon [EMAIL PROTECTED] wrote: On 3/8/07, Collin Winter [EMAIL PROTECTED] wrote: Now that unittest has a test suite, it would seem to make sense that it should be fairly high up in the testing order, since most of the regression suite depends on it. I'd like to have it included with test_grammar, test_opcodes, test_operations, etc, so that if a bug in unittest is causing other tests to fail, we don't have to wait until the end of the test run to find out. Thoughts? Sounds reasonable to me, along with any tests for doctest. I've moved test_unittest, test_doctest and test_doctest2 up (rs 54226-8, in p3yk, trunk and release25-maint respectively). They'll now run right after test_types. Collin Winter ___ 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] Renaming Include/object.h
On 1/3/07, Neal Norwitz [EMAIL PROTECTED] wrote: On 1/3/07, Thomas Wouters [EMAIL PROTECTED] wrote: On 1/3/07, Guido van Rossum [EMAIL PROTECTED] wrote: On 1/3/07, Fred L. Drake, Jr. [EMAIL PROTECTED] wrote: On Wednesday 03 January 2007 11:06, Martin v. Löwis wrote: In #1626545, Anton Tropashko requests that object.h should be renamed, because it causes conflicts with other software. I would like to comply with this requests for 2.6, assuming there shouldn't be many problems with existing software as object.h shouldn't be included directly, anyway. +1 Maybe this should be done in a more systematic fashion? E.g. by giving all internal header files a py_ prefix? I was thinking the same, and I'm sure Neal Norwitz is/was too (he suggested this a few times in the past, at least outside of python-dev.) Wow, I didn't realize I was that much of a broken record. :-) I don't even remember talking to Thomas about it, only Guido. I definitely would like to see all private header files clearly denoted by their name or directory. I saw Jack's comment about Apple's naming scheme, but I'm ignoring that for the moment. I have bad memories from the Motif days of including everything with one file. I prefer to see includes with the directory. This provides a sort of namespace: #include python/foo.h Though, if the user only has to include a single Python.h like currently, this wouldn't make as much sense. I don't recall the same problems in Python that existed when using Motif. Here are some options (python/ can be omitted too): #include python/public.h #include python/internal/foo.h #include python/private/foo.h #include python/_private.h I don't really like prefixing with py_ because from a user's perspective I interpret py_ to be a public header that gives me a namespace. I prefer a directory that indicates its intent because it can't be misunderstood. IIRC Guido didn't want to introduce a new directory. In that case my second choice is to prefix the filename with an underscore as a leading underscore often is interpreted as private. Going along with this change I would like to see all identifiers in public header files prefixed with [_]Py. And public header files shouldn't be able to include private header files (by convention). Or we should have some other way of denoting which files must prefix all their identifiers and which can use anything because they are only used in Python code. For example, right now node (struct _node) is exported in node.h in 2.4. I think it moved in 2.5, but it's still exported IIRC. Was any course of action ever decided on for this issue, or was the consensus that it would break too much code? If the latter, what about making the change for Python 3000? Collin Winter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Adding timeout to socket.py and httplib.py
I studied Skip patch, and I think he is in good direction: add a NetworkConnection object to socket.py, and then use it from the other modules. This NetworkConnection basically does what all the other modules do once and again, so no mistery about it (basically calls getaddrinfo over the received address, and try to open a socket to that address). I opened a new patch (#1676823) with the changes I propose regarding socket.py, because the goal from the two patches are different (my plan is go with the basic: first the change in socket.py and httplib, and no in all the other modules at this time). I do not know what to do with the previous patch (#723312), I guess it'll remain open until all the other modules get the timeout. Here're the differences between Skip patch and mine: - I only left changes regarding httplib and socket modules (both .py, docs, and NEWS). - I even removed a change in Python-ast.c (regarding __version__), but I don't know what's that for, so please enlighten me (thank you). - The NetworkConnection won't have a ``get_family`` method, if you need the family of the open socket, just ask the socket. - Added some test cases to test_socket.py regarding attributes, timeout and family; and a nice threaded test to actually try the timeout. - Added tests cases to test_httplib.py Feel free to review the patch, and commit it if you want (or tell me to do it after the review, it's just a command for me). Regards, -- . Facundo . Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Renaming Include/object.h
Collin Winter schrieb: Was any course of action ever decided on for this issue, or was the consensus that it would break too much code? If the latter, what about making the change for Python 3000? Neither, nor. If a grand renaming is not feasible, I'd atleast do something about object.h for Python 2.6. 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
[Python-Dev] Policy Decisions, Judgment Calls, and Backwards Compatibility (was Re: splitext('.cshrc'))
[EMAIL PROTECTED] wrote: That assumes there is a need for the old functionality. I really don't see it (pje claimed he needed it once, but I remain unconvinced, not having seen an actual fragment where the old behavior is helpful). This passage is symptomatic of the thing that really bothers me here. I have rarely used splitext before (since what I really want is determineMIMEType(), and that is easier to implement with one's own string-munging) and certainly won't use it again after following this discussion. The real issue I have here is one of process. Why is it that PJE (or any python user who wishes their code to keep working against new versions of Python) must frequent python-dev and convince you (or whatever Python developer might be committing a patch) of each use-case for old functionality? I would think that the goal here would be to keep all the old Python code running which it is reasonably possible to, regardless of whether the motivating use-cases are understood or not. It is the nature of infrastructure code to be used in bizarre and surprising ways. My understanding of the current backwards-compatibility policy for Python, the one that Twisted has been trying to emulate strictly, is that, for each potentially incompatible change, there will be: * at least one release with a pending deprecation warning and new, better API * at least one release with a deprecation warning * some number of releases later, the deprecated functionality is removed I was under the impression that this was documented in a PEP somewhere, but scanning the ones about backwards compatibility doesn't yield anything. I can't even figure out why I had this impression. *Is* there actually such a policy? If there isn't, there really should be. Deciding each one of these things on a case-by-case basis leaves a lot of wiggle room for a lot of old code to break in each release. For example, if you put me in charge of Python networking libraries and I simply used my judgment about what usages make sense and which don't, you might find that all the synchronous socket APIs were mysteriously gone within a few releases... ;-) Perhaps policy isn't the right way to solve the problem, but neither is asking every python application developer to meticulously follow and participate in every discussion on python-dev which *might* affect their code. As recently as last week, Guido commented that people build mental models of performance which have no relation to reality and we must rely on empirical data to see how things *really* perform. This is a common theme both here and anywhere good software development practices are discussed. These broken mental models are not limited to performance. In particular, people who develop software have inaccurate ideas about how it's really used. I am avoiding being specific to Python here because I've had a similarly broken idea of how people use Twisted, heard extremely strange ideas from kernel developers about the way programs in userland behave, and don't get me started on how C compiler writers think people write C code. If Python is not going to have an extremely conservative (and comprehensive, and strictly enforced) backwards-compatibility policy, we can't rely on those mental models as a way of determining what changes to allow. One way to deal with the question of how do people really use python in the wild is to popularize the community buildbots and make it easy to submit projects so that at least we have a picture of what Python developers are really doing. Buildbot has a build this branch feature which could be used to settle these discussions more rapidly, except for the fact that the community builders are currently in pretty sad shape: http://www.python.org/dev/buildbot/community/all/ By my count, currently only 9 out of 22 builders are passing. The severity of these failures varies (many of the builders are simply offline, not failing) but they should all be passing. If they were, rather than debating use-cases, we could at *least* have someone check this patch into a branch, and then build that branch across all these projects to see if any of them failed. Unfortunately open source code is quite often better tested and understood than the wider body of in-house and ad-hoc Python code out there, so it will be an easier target for changes like this than reality. I don't really have a problem with that though, because it creates a strong incentive for Python projects to both (A) be open source and (B) write comprehensive test suites, both of which are useful goals for many other reasons. In the past I've begged off of actually writing PEPs because I don't have the time, but if there is interest in codifying this I think I don't have the time *not* to write it. I'd prefer to document the pending/deprecate/remove policy first, but I can write up something more complicated about
Re: [Python-Dev] splitext('.cshrc')
On 8 Mar, 06:02 pm, [EMAIL PROTECTED] wrote: On Thu, Mar 08, 2007 at 06:54:30PM +0100, Martin v. L?wis wrote: back_name = splitext(name[0]) + '.bak' back_name = splitext(name)[0] + '.bak' This is really totally secondary to the point I actually care about, but seeing this antipattern bandied about as a reason to make the change is starting to bother me. There's no way to fix this idiom. Forget the corner case; what if you have a foobar.py and a foobar.txt in the same directory? This is not at all uncommon, and your backup function here will clobber those files in any case. Furthermore, although the module documentation is vague, the docstring for splitext specifically says either part may be empty and extension is everything from the last dot to the end. Again, this is a case of needing a function designed to perform a specific task, and instead relying on half-broken idioms which involve other functions. make_backup_filename(x) might *use* splitext, but it is not what splitext is *for*. A correct implementation which did use splitext would look like this: def make_backup_filename(filename): base, extension = splitext(filename) return base + '.bak' + extension although personally I would probably prefer this: def make_backup_filename(filename): return filename + '.bak' If the behavior of the old code is going to be buggy in any case, it might as well be buggy and consistent. Consider a program that periodically makes and then cleans up backup files, and uses the correct splitext-using function above. Perhaps .cshrc.bak makes more sense than .bak.cshrc to some people, but that means that on a system where python is upgraded, .bak.cshrc will be left around forever. Even on a program whose functionality is improved by this change, the incompatibility between versions might create problems. ___ 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] splitext('.cshrc')
I'm a long-term lurker and Python coder, and although I've never really
contributed much to the list, I do make a point to keep up on it so I'm
prepared at least when changes come through. This thread's gone on forever,
so I thought I'd offer my opinion :) Mwha.
Ahem.
First of all, I think the current behavior is clearly broken; .cshrc is a
file without an extension and marked as 'hidden' according to the
conventions of the operating system. I totally think it should be fixed; but
with others I'm worried about backwards compatability and more importantly
the possibility of silent failures. Although none of my company's code will
be hit (as I've always done fn.split('.')[-1] just... because it strikes me
as more natural -- then again I'm in a situation where I don't have
user-supplied filenames.), the thought that it's OK to make such changes
even in a 'major' release is a bit disconcerting.
Its not that I don't think there can be backwards-incompatible changes, but
if at all possible they should be done in such a way that the change causes
a hard failure or at least a clear warning in the offending code. I read
that someone (... No idea who) suggested an optional keyword argument, and
someone else objected to that on the grounds that it would let a second
argument be passed in to alter the signature, and it would no longer throw
an exception as people would be expecting.
Well, I think it was a great idea-- whoever said it :) And gives the
oppertunity to use the transitory period before 3.0 to loudly warn people
about this fix. I don't expect a lot of people will be hit by it, but isn't
that why this whole 2.6-to-3.0 thing is going on?
Why wouldn't this work? I could submit a patch with a doc modification and
tests even :P But it could begin the process of 'fixing' it, and warn people
of the upcoming breakage, and although it slightly complicates the
function... I think it only does it slightly :)
(BTW, it raises a TypeError if the allow_dotfile isn't specified
specifically, to address someone's objection that it would alter the
signature)
-
import warnings
def splitext(p, **kwargs):
allow_dotfile = kwargs.pop('allow_dotfile', False)
if kwargs:
raise TypeError, splitext() takes at most 2 arguments (%s given) %
(1 + len(kwargs))
i = p.rfind('.')
if i=max(p.rfind('/'), p.rfind('\\')):
fn, ext = p, ''
else:
fn, ext = p[:i], p[i:]
if allow_dotfile is False:
if p.find('.') == 0:
warnings.warn(FutureWarning('In Python 3.0, allow_dotfile
default will become True.'))
return fn, ext
else:
if p.find('.') == 0:
return ext, ''
else:
return fn, ext
-
___
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] Policy Decisions, Judgment Calls, and Backwards Compatibility (was Re: splitext('.cshrc'))
On 3/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Buildbot has a build this branch feature which could be used to settle these discussions more rapidly, except for the fact that the community builders are currently in pretty sad shape: http://www.python.org/dev/buildbot/community/all/ By my count, currently only 9 out of 22 builders are passing. The severity of these failures varies (many of the builders are simply offline, not failing) but they should all be passing. If they were, rather than debating use-cases, we could at *least* have someone check this patch into a branch, and then build that branch across all these projects to see if any of them failed. Titus and I are thinking about mentoring a Google Summer of Code project that would use the 'buildbot try' feature: set up a bunch of buildbot slaves and set them up so sending them a patch will trigger a checkout of the latest Python svn, followed by the application of the patch, followed by building and running unit tests for Python, followed by running test suites for various projects (similar to how it's being done in the community buildbot farm). This will hopefully give us a better grasp about how good a patch is, and will make the process of accepting patches more smooth. What do people think? Grig ___ 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] Policy Decisions, Judgment Calls, and Backwards Compatibility (was Re: splitext('.cshrc'))
[EMAIL PROTECTED] wrote: In the past I've begged off of actually writing PEPs because I don't have the time, but if there is interest in codifying this I think I don't have the time *not* to write it. I'd prefer to document the pending/deprecate/remove policy first, but I can write up something more complicated about community buildbots and resolving disputes around potential breakages if there is actually no consensus about that. Please do write this up. It's a good policy and should be codified. # Steve ___ 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] splitext('.cshrc')
At 2:16 PM -0500 3/8/07, Phillip J. Eby wrote: At 11:53 AM 3/8/2007 +0100, Martin v. Löwis wrote: That assumes there is a need for the old functionality. I really don't see it (pje claimed he needed it once, but I remain unconvinced, not having seen an actual fragment where the old behavior is helpful). The code in question was a type association handler that looked up loader functions based on file extension. This was specifically convenient for recognizing the difference between .htaccess files and other dotfiles that might appear in a web directory tree -- e.g. .htpasswd. The proposed change of splitext() would break that determination, because .htpasswd and .htaccess would both be considered files with empty extensions, and would be handled by the empty extension handler. So, .htaccess and foo.htaccess should be treated the same way? Is that what Apache does? -- TonyN.:' mailto:[EMAIL PROTECTED] ' http://www.georgeanelson.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] version-specific PYTHONPATH env var
What do people think about the idea of a version-specific PYTHONPATH environment variable? Something like PYTHON25PATH or the like. Reason I ask is that on our production systems, we have a couple of versions of Python being used by different systems. Yes, yes, in a perfect world they'd be all updated at the same time, sure. There's occasionally issues with the PYTHONPATH being pointed at something like .../lib/python2.4/site-packages or the like, and then have issues when python2.3 or some other different version is run. If we allowed people to optionally specify a more specific version this problem would go away. Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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] Policy Decisions, Judgment Calls, and Backwards Compatibility (was Re: splitext('.cshrc'))
[EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: My understanding of the current backwards-compatibility policy for Python, the one that Twisted has been trying to emulate strictly, is that, for each potentially incompatible change, there will be: * at least one release with a pending deprecation warning and new, better API * at least one release with a deprecation warning * some number of releases later, the deprecated functionality is removed = There is not and hardly can be any such policy for bug fixes. Unfortunately, * Honest people can disagree about whether a change is a bug fix or feature addition or replacement. And there will be borderline cases regardless of one's definition, unless one makes either category empty. (Having only one category and hence only one change policy would simplify life but at some cost.) * Fixing bugs can break code just as it fixes other code. I believe the current policy is that depending on buggy behavior, as opposed to working around it, is proceed at your own risk. Bugs can be fixed without notice, at the next bug fix release. On the other hand, bug fixes can and sometime are delayed or modified in recognition of degrees of bugginess and differences of opinions and cost-benefit analyses. But deviations from a rigid procedure require case-by-case judgments, to me preferably based on information-gathering and discussion and a chance to influence judgment. For new features that don't break code (that doesn't depend on the features absence), the current (and somewhat new) policy is to wait until the next minor .x feature release, skipping any micro .x.y releases (now called bug-fix releases). For replacement features, the policy is what you give above. Example: f(*args) instead of apply(f, args). At one time, the expectation was that removal could be and possibly would be one release after deprecation. It is currently to wait until 3.0. What it will be after that I have not seen discussed. Semantic changes are trickier. We don't want a different API when we want a different meaning for the currently API. The integer division change is a mixture. Int//int replaces int/int and is already available. But int/int will change meaning to float(int)/float(int) rather than being removed. So I see five categories of code change -- clear bug, possibly fuzzy bug, semantic change, replacement, and addition -- each with different appropriate policies. And there are mixtures that belong together in a package. Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] version-specific PYTHONPATH env var
I recommend not setting these variables at all, or to use wrapper scripts that set them instead. But there's probably some reason why you can't do that... On 3/8/07, Anthony Baxter [EMAIL PROTECTED] wrote: What do people think about the idea of a version-specific PYTHONPATH environment variable? Something like PYTHON25PATH or the like. Reason I ask is that on our production systems, we have a couple of versions of Python being used by different systems. Yes, yes, in a perfect world they'd be all updated at the same time, sure. There's occasionally issues with the PYTHONPATH being pointed at something like .../lib/python2.4/site-packages or the like, and then have issues when python2.3 or some other different version is run. If we allowed people to optionally specify a more specific version this problem would go away. Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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/guido%40python.org -- --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] Policy Decisions, Judgment Calls, and Backwards Compatibility (was Re: splitext('.cshrc'))
[EMAIL PROTECTED] schrieb: The real issue I have here is one of process. Why is it that PJE (or any python user who wishes their code to keep working against new versions of Python) must frequent python-dev and convince you (or whatever Python developer might be committing a patch) of each use-case for old functionality? Because this is the way free software works. I'm the one contributing (actually, merely integrating changes proposed by others, Larry Hastings in particular), so I get to make decisions. This patch had been open for three years. If pje had any problems with it, he could have rejected it. If you had problems with it, you could have commented that it should not be applied. Nobody did, so I decide. I would think that the goal here would be to keep all the old Python code running which it is reasonably possible to, regardless of whether the motivating use-cases are understood or not. Exactly: which it is reasonably possible to. In this case, I found no reasonable way to keep it running while still fixing the bug, and not breaking too much other stuff in order to keep that particular code running. So the only alternative would have been to reject the change and live with the bug forever, something that many people here considered bad. My understanding of the current backwards-compatibility policy for Python, the one that Twisted has been trying to emulate strictly, is that, for each potentially incompatible change, there will be: * at least one release with a pending deprecation warning and new, better API * at least one release with a deprecation warning * some number of releases later, the deprecated functionality is removed If you want to contribute a patch that changes splitext to follow this policy, please go ahead and submit one. I personally consider a deprecation warning unacceptable in this specific case. I was under the impression that this was documented in a PEP somewhere, but scanning the ones about backwards compatibility doesn't yield anything. I can't even figure out why I had this impression. *Is* there actually such a policy? There is PEP 5, which is not followed, since it requires backwards-incompatible behavior to go through the PEP process. If there isn't, there really should be. So submit a PEP. Or better, take over maintenance of PEP 5 (or better, cooperate with the author of the PEP on maintaining it). Perhaps policy isn't the right way to solve the problem, but neither is asking every python application developer to meticulously follow and participate in every discussion on python-dev which *might* affect their code. And there is no need to. If they find that their code breaks, they can submit bug reports, or, better, contribute patches. This is what alpha releases are for, and the trunk is buildable all the time, so you can test your code against the new release even before it happens. If you want to study the changes, you can read Misc/NEWS from time to time. If Python is not going to have an extremely conservative (and comprehensive, and strictly enforced) backwards-compatibility policy, we can't rely on those mental models as a way of determining what changes to allow. One way to deal with the question of how do people really use python in the wild is to popularize the community buildbots and make it easy to submit projects so that at least we have a picture of what Python developers are really doing. I was going to say that. Now, if the community doesn't pick up the concept of community buildbots, the community has no right to complain (IMO, and I put that deliberately into quotes, knowing that the community doesn't exist as such, but is made up of individuals, some interested in the buildbots, stability, and so on, and others being less conservative). In the past I've begged off of actually writing PEPs because I don't have the time, but if there is interest in codifying this I think I don't have the time *not* to write it. If you think it needs codification, I think you will need to write it yourself - nobody else will do it for you. Depending on what it will say, I might disagree. I do disagree with the requirement that every incompatible go through the PEP, and I understand incompatible change as programs only relying on document behavior might break. In the case that triggered the discussion, the change implemented was not an incompatible change, because the new implementation still met the old specification (which, of course, was underspecified). 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
