Re: [Python-Dev] how can I review? [was: Encouraging developers]
Jim Jewett schrieb: > It has been quite a while since I worried about my own patches going > stale; I just want to know how my review time can be more useful. > > Once a committer has already decided to look at a patch, comments may > make the next step easier. > > But is there anyway to flag an issue as either ready for that look, or > already judged not-yet-ready? Not in the current tracker, no. There is the "accepted/open" state, but we use it to indicate "just needs committing"; if a reviewer doesn't have the authority to actually approve the patch, it would give the submitter the false impression that the patch will go in (which it might, depending on whether the committer agrees with the review). > I had assumed that doing this patch-at-a-time would quickly get > annoying. To some, perhaps. However, they should unsubscribe from python-dev if they get annoyed. As glyph said: this is the list where patches should be discussed. I can see why automated messages shouldn't go to python-dev; if python-development-related hand-written messages annoy people, they clearly subscribed to the wrong list (these days, some of them better subscribe to python-ideas). > Is batching several patches together part of what you want? Not sure I understand. You mean several related bugs/patches? I tend to look at patches for a single module often at one time, in particular to find out whether they overlap or conflict, and what the best order to apply them would be. Often, submitters will have to redo their patch if a conflicting one is applied, so here batching is important. If you mean "do I work on python patches in batches?", then: sometimes. I tried "a bug a day" for some time, but couldn't sustain it. At the moment, I have some free time at hand, so I look at many patches. If you have a list of patches to be rejected, this could be easily batched (rejecting is more easy than applying). For committing, I still need to understand the issue in detail, and the proposed patch. Of course, I would hope that the review already lays it out so that it is more easy to understand pros and cons, and that it will give information that the submitter omitted (mostly because it was clear to him), so for trivial patches, batch-committing them is feasible. > (If so, I would personally still rather that the tracker or at least > a wiki page did that grouping.) Sure. I just created http://wiki.python.org/moin/PatchTriage Feel free to add patches there (if you want to, along with a date on which you added it) >> (I think a second >> check is still needed, as the case of splitext shows: you were in >> favor of rejecting it because of the incompatibility, ... > > (I think that was actually John J. Lee; I did just add a note that it > should no longer be considered bugfix candidate for 2.4) Oops, sorry, confusing different JJs here (this may have happened in the past also, I guess). 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
Barry Warsaw schrieb: > Jira had a way of automatically assigning certain categories to certain > people. I think the term was project leader or some such. Of course, > this didn't mean that someone else couldn't fix the bug or that the bug > couldn't be reassigned to someone else, but at least it initially gives > all issues to the person nominally responsible for it. The SF tracker has this also. I'm auto-assigned for Tkinter bugs, for example - not that I review them in a timely manner. 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] Lack of sequential decompression in the zipfile module
Nilton Volpato wrote: > If you open many member files concurrently how does file cache will > work? Or how many seeks you will have to do if you read from one > member file and from other alternatingly? If the OS file system cache is doing its job properly, I don't think the seeking should be a problem. > Or, if you need to open more than > one member file for writing in the same zip file, then this is not > possible at all. I don't think it would be unreasonable to just not support writing to more than one member at a time. -- 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] splitext('.cshrc')
[EMAIL PROTECTED] schrieb:
> More to the point, we know the cost, what's the benefit? Is there any
> sort of bug that it is likely to prevent in *new* code?
Yes. People are more likely to classify the file as "no extension",
which more likely meets the user's expectation. Also, it won't happen
that splitext gives an empty file name, which otherwise may cause crashes.
> It clearly isn't going to help any old code.
That's not at all clear. Instead, old code will suddenly work correctly
(in the user's point of view), where it before gave nonsensical results
(which users have likely ignored).
For example, from the standard library:
py> import pydoc
py> pydoc.importfile("/Users/loewis/.pythonrc")
This is non-sensical: the module isn't an empty string. Instead, it
should be '.pythonrc' - just as it would be 'pythonrc' if the file
name was 'pythonrc'.
So old code in the standard library will be improved.
> It seems there are people who see it
> both ways, and I haven't seen anything compelling to indicate that
> either behavior is particularly less surprising in the edge case.
Maybe you aren't grounded so much in Unix history. It really feels
wrong that a dotfile is considered as having an extension.
> In cases like this, historical context should be considered, even for a
> major overhaul like 3.0. Of course, if the newly proposed semantics
> provided a solution to a real problem or common error, compatibility
> might be determined to be a less important issue.
All of these apply here.
> The use-cases being discussed here would be better served by having new
> APIs that do particular things and don't change existing semantics,
> though. For example, a "guess_mime_type(path)" function which could
> examine a path and figure out its mime type based on its extension
> (among other things).
I disagree. The current behavior is incorrect (and always has been);
the new behavior is clearly correct.
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')
Terry Jones schrieb: > I do think the behavior can be improved, and that it should be fixed, but > at a place where other incompatible changes will also be being made, Indeed, 2.6 is such a place. Any feature release can contain incompatible behavior, and any feature release did contain incompatible behavior. Just look at the "porting to" sections of past whatsnew files. 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
Ron Adam schrieb: > But the tracker needs to be able to actually track the status of individual > items for this to work. Currently there's this huge list and you have to > either wade though it to find out the status of each item, or depend on > someone bring it to your attention. Well, the tracker does have a status for each individual report: open or closed. open means "needs more work", closed means "no more work needed". So don't wade through a report - just assume that if it is open, it needs work. 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] Lack of sequential decompression in the zipfile module
Nilton Volpato schrieb: > My Google Summer of Code project was just about this, and I > implemented a lot of nice features. These features include: file-like > access to zip member files (which solves your problem, and also > provides a real file-like interface including .read(), .readline(), > etc); support for BZIP2 compression; support for removing a member > file; support for encrypting/decrypting member files. Unfortunately (?), the 2.6 zipfile module will have much of that, also, please take a look. 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: > On 06/03/2007 10.52, Martin v. Löwis wrote: > >> 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. I can feel your pain that your (only) patch was unreviewed for three years. If it makes you happy to blame somebody feel free to, but I feel it is unfair to blame the single person that eventually *did* review and commit your patch. You may ask yourself why this specific patch was unreviewed for so long. My own explanation is that it is a highly complicated algorithm (as any kind of cryptographical algorithm), so nobody felt qualified to review it. I'm pretty sure it was *looked at* often (contrary to your remark in [1]), but none of the people reading it were qualified to comment. So if you want to work on encryption still, please go ahead. Regards, Martin [1] http://mail.python.org/pipermail/python-list/2004-November/293510.html ___ 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
As an outsider who has submitted a handful of patches and has always wanted to become more involved.. I would like to comment as I feel like I am the target audience in question. I apologize ahead of time if I am speaking out of place. Martin v. Löwis wrote: > Phil Thompson schrieb: >> 1. Don't suggest to people that, in order to get their patch reviewed, they >> should review other patches. The level of knowledge required to put together >> a patch is much less than that required to know if a patch is the right one. > > People don't *have* to review patches. They just can do that if they > want expedite review of their code. > While I understand that this tit-for-tat mechanism is meant to ensure participation, I believe in reality it doesn't, as the 400-some outstanding patches you referenced elswhere indicate. I can personally attest to having a patch that is over a year old with no "core developer" having any interest at all with the subject matter. And to be frank, nor did I really, but I saw a problem and was capable of solving it. My lack of caring about the patch means I am not going to beat people over the head to pay attention. This system is broken for someone like me (coder) that just wants to help out (non-coders). >> 2. Publically identify the core developers and their areas of expertise and >> responsibility (ie. which parts of the source tree they "own"). > > I doubt this will help. Much of the code isn't owned by anybody > specifically. Those parts that are owned typically find their patches > reviewed and committed quickly (e.g. the tar file module, maintained by > Lars Gustäbel). If nothing else, as an outsider there is no way to know why your patch gets ignored while others get swiftly dealt with. Any sort of information like this would at least provide more transparency in what may appear to be elitest processes. -Scott -- Scott Dial [EMAIL PROTECTED] [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] Encouraging developers
Martin v. Löwis wrote: > Paul Moore schrieb: >> Here's a random offer - let me know the patch number for your patch, >> and I'll review it. > > Surprisingly (and I hope Scott can clarify that), I can't find anything. > Assuming Scott's SF account is "geekmug", I don't see any open patches > (1574068 was closed within 20 days by amk, last October). > Sadly the sf tracker doesn't let you search for "With comments by". The patch I was making reference to was 1410680. Someone else actually had wrote a patch that contained bugs and I corrected them. And with that, I was the last person to comment or review the patch in question. -Scott -- Scott Dial [EMAIL PROTECTED] [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] cross-compile patches
Han-Wen Nienhuys schrieb: > 1608267 - added comment, asking for explanation. looks bogus. > 1608579 - problem analysis + solution looks good > 1507247 - I can reproduce the problem it tries to fix. Fix looks ok. > 1520879 - trivial fix; should go in. disregard the comment about relative > --prefix > 1339673 - superseeded by #1597850 Thanks. Comming back to it only now, I added them into http://wiki.python.org/moin/PatchTriage 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] [ 1669539 ] Change (fix!) os.path.isabs() semantics on Win32
On 3/7/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Terry Jones schrieb: > > I do think the behavior can be improved, and that it should be fixed, but > > at a place where other incompatible changes will also be being made, > > Indeed, 2.6 is such a place. Any feature release can contain > incompatible behavior, and any feature release did contain incompatible > behavior. Just look at the "porting to" sections of past whatsnew files. While we're at it, patch 1669539 makes a similar incompatible change to ntpath.isabs(). On Windows there are: - true relative paths, like Lib\ntpath.py - true absolute paths, like C:\Python25 and \\server\share - oddities, like C:ntpath.py and \Python25 isabs() is inconsistent about oddities: >>> ntpath.isabs(r'C:ntpath.py') False >>> ntpath.isabs(r'\Python25') True I don't think there's any logic behind this behavior. The current documentation for isabs() is: isabs(path) Return True if path is an absolute pathname (begins with a slash). The patch makes isabs(oddity) return False. I don't think existing code is a huge concern here. Google Code Search suggests that no one thinks about the oddities. Most existing code using isabs() has acceptable-but-slightly-odd behavior for oddities, and that kind of code would have different acceptable-but-slightly-odd behavior under the proposed change. And oddities are rare. The patch is incomplete (no docs) but ripe for a note of encouragement (or summary rejection) from a committer. -j ___ 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] Access to bits for a PyLongObject
Martin v. Löwis wrote: > Ah, I had missed the point that it's just binary formatting that > you are concerned with (and then I missed that binary is "base 2", > rather than "sequence of bits") Apologies for not being clear. It's easy to forget that others don't share the context of something you've been immersed in. >> Having written all of this, I'm now thinking that Nick's suggestion of >> _PyLong_AsByteArray might be the way to go. I would use that for all of >> my formatting for longs. > > How would you do negative numbers, then? AsByteArray gives you two's > complement. _PyLong_Sign >> But I'd like PEP 3101 to be as efficient as possible, >> because once it's available I'll replace all of the '%' string >> formatting in my code with it. > > That is fine. However, don't trade efficiency for maintainability. > Keep encapsulation of types, this is what OO is for. Modularize > along with type boundaries. If that loses efficiency, come up with > interfaces that still modularize in that way but are efficient. > Don't "hack" to achieve performance. (Any other way I can formulate > the same objective :-?) Point taken. I currently have it using PyLong internals, just to get our tests to pass and so Pat can work on his part. As we still want to be a standalone module for a while, I'm going to modify the code to use AsByteArray and Sign to do the binary formatting only. When/if we integrate this into 3.0 (and 2.6, I hope), I'll look at adding __format__ to long, and possibly the other built in types. To do so we'll need to factor some code out to a library, because it doesn't make sense for all the built-in types to understand how to parse and operate on the format specifiers (the [[fill]align][sign][width][.precision][type] stuff). Thanks for your comments! Eric. ___ 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
A.M. Kuchling wrote: > FWIW, I have a related perception that we aren't getting new core > developers. These two problems are probably related: people don't get > patches processed and don't become core developers, and we don't have > enough core developers to process patches in a timely way. And so > we're stuck. > > Any ideas for fixing this problem? I think that there's a barrier entry: there's no place to ask for help on silly problems when you're trying to help (!). Let me explain my bad english wording, with an example. Yesterday night I started modifying socket.py and test_socket.py. "Of course", I said, "let's see if the tests pass ok *before* start changing anything". Went to ~/devel/reps/python/trunk/Lib, and made: $ python2.5 test/test_socket.py... Wrong! Damn! Tried a lot of stuff... $ cd test $ python2.5 test_socket.py... Wrong! $ python2.5 regrtest.py test_socket ... Wrong! $ python2.5 regrtest.py test_socket.py ... Wrong! $ python2.5 regrtest.py socket ... Wrong! And thousand more combinations. The best I could do is actually execute the tests, but python was getting the installed socket module, and not the repository socket module (even that I was in the same directory of the latter). I didn't know what to try. I was stuck. This never happened to me when working on Decimal. What went wrong in my head in the middle? I finally understood the problem, and build python from the repository, and made the tests from *this* python (actually, this was an easy step because I'm on Ubuntu, but *I* would be dead if working in Windows, for example). Ok. *Me*, that I'm not ashame of asking what I don't know, if I didn't resolve it I'd finally asked in python-dev. But how many people would have throw the towel withoug getting so far? How many people want to submit a patch, or even a bug, or finds a patch to review, but don't know how to do something and thinks that python-dev is not the place to ask (too high minds and experienced people and everything)? What I propose is a dedicated place (mailing list, for example), that is something like a place where you can go and ask the silliest questions about helping in the developing process. - How can I know if a patch is still open? - I found a problem, and know how to fix it, but what else need to do? - Found a problem in the docs, for this I must submit a patch or tell something about it? How? - 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? Me, for example, has an actual question to this list: "How can I know, if I change something in the doc's .tex files, that I'm not broking the TeX document structure?". Just my two argentinian cents. 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] splitext('.cshrc')
Martin v. Löwis wrote: > I never considered it an extension. Ask 10 people around you to see > what a leading dot on Unix in a file name means, and I would be > suprised if more than one answered "it separates the file name from > the extension". Most of them likely include "hidden file" in their > answer, and the rest (of those who know anything about it) will > say "dotfiles, not displayed by ls, and not included in globbing". 10 Unix programmers, perhaps. Windows users may disagree; after all, the Windows Explorer considers both foo.bar and .bar to be BAR files, and considers .py to be an unnamed Python file. ___ 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 06/03/07, Scott Dial <[EMAIL PROTECTED]> wrote: > Martin v. Löwis wrote: > > Paul Moore schrieb: > >> Here's a random offer - let me know the patch number for your patch, > >> and I'll review it. > > > > Surprisingly (and I hope Scott can clarify that), I can't find anything. > > Assuming Scott's SF account is "geekmug", I don't see any open patches > > (1574068 was closed within 20 days by amk, last October). > > > > Sadly the sf tracker doesn't let you search for "With comments by". The > patch I was making reference to was 1410680. Someone else actually had > wrote a patch that contained bugs and I corrected them. And with that, I > was the last person to comment or review the patch in question. OK, as promised, I've reviewed it. I've recommended some actions from the original poster, or if they aren't forthcoming, then rejection. If you (Scott) want to pick this up, I'd recommend: 1. Open a new patch, with your recommended changes. 2. Address the comments made against Tony's patch, in yours. 3. Add a recommendation to Tony's patch that it be closed in favour of yours. Wait and/or canvas further opinion. That's about all I can do - to get the code *into* Python (if it's appropriate - remember that I've recommended rejection!) then you need someone with commit privileges to apply it. On the other hand, what I've done is similar to what you did - comment on someone else's patch. It seems relevant to me that the original poster (Tony Meyer) hasn't felt strongly enough to respond on his own behalf to comments on his patch. No disrespect to Tony, but I'd argue that the implication is that the patch should be rejected because even the submitter doesn't care enough to respond to comments! 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] splitext('.cshrc') (and encouraging developers)
Martin v. Löwis wrote: > Terry Jones schrieb: > >> I do think the behavior can be improved, and that it should be fixed, but >> at a place where other incompatible changes will also be being made, >> > > Indeed, 2.6 is such a place. Any feature release can contain > incompatible behavior, and any feature release did contain incompatible > behavior. Just look at the "porting to" sections of past whatsnew files. > > Now that Martin has made the changes and rejected the original patch I remember that it was written by me. This raises a point which is related to the 'encouraging developers' thread. I created this patch as part of a Python bug day over a year ago. The bug day was trumpeted as being a good place for 'newbies' who wanted to contribute to Python could start, and implied that some kind of mentoring would be in place. I enthusiastically turned up on IRC and asked how to join in. I was told (more or less) to 'pick a bug and fix it'. That one seemed to be the only one on the list I could tackle alone (and I still managed to screw it up it seems!). I submitted the patch to sourceforge, posted to IRC that I had done this - and then kind of hung around a while waiting to see what would happen. There was no response and after a while of waiting and nothing much else happening either I returned to working on my own projects... The bug days do seem like an opportunity to involve new developers - but some kind of active engagement would seem appropriate... All the best, Michael Foord > 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/fuzzyman%40voidspace.org.uk > > ___ 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] Bug Days
Michael Foord schrieb: > This raises a point which is related to the 'encouraging developers' thread. > > I created this patch as part of a Python bug day over a year ago. The > bug day was trumpeted as being a good place for 'newbies' who wanted to > contribute to Python could start, and implied that some kind of > mentoring would be in place. > > I enthusiastically turned up on IRC and asked how to join in. I was told > (more or less) to 'pick a bug and fix it'. That one seemed to be the > only one on the list I could tackle alone (and I still managed to screw > it up it seems!). I submitted the patch to sourceforge, posted to IRC > that I had done this - and then kind of hung around a while waiting to > see what would happen. > > There was no response and after a while of waiting and nothing much else > happening either I returned to working on my own projects... > > The bug days do seem like an opportunity to involve new developers - but > some kind of active engagement would seem appropriate... If it was the last bug day you speak about, this was a bit unfortunate since it was only me and Tim who were present for a longer time, and not busy with some server maintenance tasks. I guess I just picked the wrong day ;) 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] splitext('.cshrc')
"Martin v. Löwis" <[EMAIL PROTECTED]> 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... What about changing the semantics of splitext and creating a new function (available on all platforms) that does what the Windows version currently does? For people who want the one semantic on all platforms, they can pick their semantic explicitly. Alternatively, offer a flag argument in splitext to differentiate between the two cases. - Josiah ___ 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] Bug Days
On 07/03/07, Georg Brandl <[EMAIL PROTECTED]> wrote: > If it was the last bug day you speak about, this was a bit unfortunate since > it > was only me and Tim who were present for a longer time, and not busy with some > server maintenance tasks. I guess I just picked the wrong day ;) Agreed - the earlier bug day which I attended seemed to go pretty well, with a reasonable number of people to help with my (dumb) questions, and a fairly quick followup of someone (AMK, if I recall) going through the various patches/fixes and committing stuff. It seems to me that managing a good bug day requires a fair bit of effort - but when it works, it's a good way to get people involved. 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
Facundo Batista schrieb: > How many people want to submit a patch, or even a bug, or finds a patch > to review, but don't know how to do something and thinks that python-dev > is not the place to ask (too high minds and experienced people and > everything)? > > What I propose is a dedicated place (mailing list, for example), that is > something like a place where you can go and ask the silliest questions > about helping in the developing process. In my experience, direct communication, e.g. via IRC channels, is much less "intimidating" for newcomers than a publicly read and archived mailing list. That said, I'm in #python-dev on Freenode most of the time and I'd be happy to help out new developers (as soon as the questions are still so simple for me to answer ;). Of course, the channel would have to be made an "official" Python development tool and advertised on e.g. the website. Also, it couldn't hurt if some of the other devs would frequent it too, then :) 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] Bug Days
Paul Moore schrieb: > On 07/03/07, Georg Brandl <[EMAIL PROTECTED]> wrote: >> If it was the last bug day you speak about, this was a bit unfortunate since >> it >> was only me and Tim who were present for a longer time, and not busy with >> some >> server maintenance tasks. I guess I just picked the wrong day ;) > > Agreed - the earlier bug day which I attended seemed to go pretty > well, with a reasonable number of people to help with my (dumb) > questions, and a fairly quick followup of someone (AMK, if I recall) > going through the various patches/fixes and committing stuff. > > It seems to me that managing a good bug day requires a fair bit of > effort - but when it works, it's a good way to get people involved. Speaking of which -- is anyone interested in holding a Bug Day in the near future? 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] PEP 364, Transitioning to the Py3K standard library
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 6, 2007, at 10:16 PM, [EMAIL PROTECTED] wrote: > Does the proposed renaming include any restructuring (e.g. making > hierarchies out of all or part of the stdlib where none existed > before)? It > wasn't obvious to me. For example, might there be a restructuring > of the > entire stdlib? Skip, that's really for PEP 3108 to decide, not really my PEP 364. I believe that the mechanism I describe in PEP 364 could support a restructured stdlib, at least as far as renamed modules go. Basically, it's just a hack to support aliasing an import of one name (the old name) through the import of another name (the new name). - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRe7p+HEjvBPtnXfVAQKFDQP9HSL0o6mWj4iNMKJNjVy1qcbK1HCHbDVv JlnqPlegRiZR+KwDhPiGLD8epepuZ3d92F4ptORcTsiulC2H/nIAiYTRJWdqFj7I sCIXZkRc0lFskxEf4p9t2aOHOWq6D9VYrcHeZ8L5KYxck35M8KfGVmSWvbSoIXBs qx+nFWrBVwA= =rrCG -END PGP SIGNATURE- ___ 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] Bug Days
Why not offer a Python patching tutorial at the next US/Euro PyCon? It seems like there's plenty that could be taught. I'd attend. I'd suggest that that specific tutorial be offered free, or be paid for by sponsors. Similarly, the first day of the post-PyCon sprints could have a group learning about the patching process. While I'd probably not attend a "sprint" (because I'd imagine I'd be doing more harm than good) I'd certainly be interested in showing up for a day explicitly aimed at those interested in learning / sprinting on patching python. Terry ___ 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
Paul Moore schrieb: > 1. Open a new patch, with your recommended changes. I'd like to second this. If you are creating a patch by responding in a comment, it likely gets ignored. > 2. Address the comments made against Tony's patch, in yours. > 3. Add a recommendation to Tony's patch that it be closed in favour of > yours. This also sounds good. 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] Adding socket timeout to urllib2
On 3/6/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 3/6/07, Adam Olsen <[EMAIL PROTECTED]> wrote: > > I think calling it "timeout" in the API is fine. The documentation > > can then clarify that it's an idle timeout, except it only applies > > when blocked in a network operation. > > Since "idel timeout" is not a commonly understood term it would be > even better if it was explained without using it. I disagree, but meh, I'll stick to my http://pink.bikeshed.org/ -- Adam Olsen, aka Rhamphoryncus ___ 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] Adding socket timeout to urllib2
> > Guido> Since "idel timeout" is not a commonly understood term it would > Guido> be even better if it was explained without using it. > > I think it's commonly understood, but it doesn't mean what the socket > timeout is used for. It's how long a connection can be idle (the client > doesn't make a request of the server) before the server will close the > connection. Let me chime it to support Skip here. "idle timeout" seems a really bad name for the new timeout feature under discussion. It's not about idling; it's about how long you'll wait for something you're expecting from the other end of the connection before assuming that something has gone wrong over there (infinite loop, etc.) and aborting the connection. OTOH, "idling" is when the TCP connection exists, but neither side wants anything from the other side. If you really need a name other than "timeout" (which seems fine to me), how about "waiting-with-mild-trepidation-timeout"? Bill ___ 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] Fwd: Re: Encouraging developers
[Scott Dial] >While I understand that this tit-for-tat mechanism is meant to ensure >participation, I believe in reality it doesn't, as the 400-some >outstanding patches you referenced elswhere indicate. . . . >If nothing else, as an outsider there is no way to know why your patch >gets ignored while others get swiftly dealt with. Any sort of >information like this would at least provide more transparency in what >may appear to be elitest processes. This thread is getting dull and is wasting everyone's time. If you want to contribute, then contribute. If you want to rant about elitism, bag on volunteer developers, or expound conspiracy theories about insiders and outsiders, then your scottdial.com blog would make a better forum. Raymond ___ 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] Bug Days
On Wed, Mar 07, 2007 at 04:32:27PM +0100, Georg Brandl wrote: > If it was the last bug day you speak about, this was a bit unfortunate > since it > was only me and Tim who were present for a longer time, and not busy with > some > server maintenance tasks. I guess I just picked the wrong day ;) Bug days would be a good idea, but we'd need to firmly commit to having several committers around for the duration, and to helping people with bugs instead of working on our own things. --amk ___ 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: > Ron Adam schrieb: >> But the tracker needs to be able to actually track the status of >> individual items for this to work. Currently there's this huge list >> and you have to either wade though it to find out the status of each >> item, or depend on someone bring it to your attention. > > Well, the tracker does have a status for each individual report: open or > closed. open means "needs more work", closed means "no more work > needed". So don't wade through a report - just assume that if it is > open, it needs work. > > Regards, > Martin I should have said... ... the status of individual items *in more detail* for this to work *well*. Sorry, Ron ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | [EMAIL PROTECTED] schrieb: | Maybe you aren't grounded so much in Unix history. It really feels | wrong that a dotfile is considered as having an extension. I have not been on *nix for nearly 20 years and I agree that the current behavior is a bug. If I were to prepare a file list like name .ext I would be annoyed is .cshrc was stuck in the ext column instead of the name column. tjr ___ 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"" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >You may ask yourself why this specific patch was unreviewed for >so long. My own explanation is that it is a highly complicated >algorithm (as any kind of cryptographical algorithm), so nobody >felt qualified to review it. I'm pretty sure it was *looked at* >often (contrary to your remark in [1]), but none of the people >reading it were qualified to comment. I have looked at nunerous patches without commenting because I could not or did not do a full review. You and Neal have convinced me that I have been too shy and that even little comments like 'the doc revision looks good' might help. tjr ___ 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] Tracker rights
Hi, Could I be granted rights to the SF tracker? I'm going through and reviewing some older patches, and I'd like to be able to close invalid/rejected patches (eg, 1492509) and upload changed patches. My SF username is collinwinter. Thanks, 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] Encouraging developers
Giovanni Bajo <[EMAIL PROTECTED]> wrote: > On 3/6/2007 3:11 AM, Josiah Carlson wrote: > > Giovanni Bajo <[EMAIL PROTECTED]> wrote: > >> I think this should be pushed to its extreme consequences for the standard > >> library. Patching the standard library requires *much less* knowledge than > >> patching the standard core. Basically, almost any Python developer in the > >> wild > >> can quickly learn a module and start patching it in a few days/weeks -- > >> still, > >> the stdlib is a total mess of outdated and broken modules. > > > > Sometimes code is correct. Sometimes code is complete. Just because a > > module hasn't been significantly altered or updated recently doesn't > > mean that it is outdated or broken. > > You can't decide this unless you are a maintainer of that module. If a > programmer felt the urge to pack up a patch and submit it to SF.NET, he > probably has an idea. It might be a good idea. It might not be the best, > but at least it's an idea. It might even be just a bugfix. > > If you see the patch, know the module well, and can express a judgement, > you just need to review it and discuss it. But I really can't see what's > *worse* than getting a patch unreviewed and unapplied. And who is advocating for patches to be unreviewed and unapplied? I'm not. If *anyone* is advocating such a position, then I claim that they are idiots. > > Asyncore, for example, is more or > > less feature complete for a minimal asynchronous socket framework. Could > > it gain more features (like good SSL support) or have better error > > handling? Of course. But it passes the test suite (via test_asynchat), > > so I would consider it *not* broken. > > Because you are the maintainer and you know well. I used asyncore once, > and I felt it was incomplete. So I went looking for something else. > That's fine. You probably know asyncore very well, so your judgement is > important and you'll be reviewing the patches and vetoing them if you > don't like. I'll tell you the biggest problem with asyncore: there are few *good* samples of asyncore usage in the wild, and there isn't even one really in the standard library (smtpd does OK, but it could be better). The asynchat module is supposed to add *just enough* functionality to get people started, but its lack of a sample collect_incoming_data() and found_terminator() that generally do the right thing, are sticking points for many people. Among the changes I'm going to be pushing for is the inclusion of sample implementations of those two methods in asynchat (as well as a fix for when a string terminator is longer than ac_in_buffer_size). If asynchat had them in the summer of 2001, I probably wouldn't have more or less reimplemented my own asynchronous sockets framework that summer and fall 3 different times. > But there are modules without maintainers. We agree that every module > should have a maintainer, and that's fine. But you seem to ignore the > fact that we ought to find a solution for modules and packages without > maintainers. What is your proposed solution, once if we agree that the > current state of affairs suck? You can't force people to step up for > maintainership of course, so you have to find something in the middle. > 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? That's a bit like inviting everyone who has ever programmed to be an IEEE or ACM fellow. That's nice and inclusive, but not the way you gather together people who can and will develop quality code. > > Just because a patch doesn't break a module, doesn't mean the patch > > should be applied. Take, for example, any one of the patches currently > > offered against asyncore. One of them more or less changes the internal > > structure of the module for no other reason than to (in my opinion) be > > gratuitous. Certainly it has some good ideas, but it would be better to > > adapt portions rather than take it completely - which is what you are > > suggesting, and which is what would have happened due to the absence of > > an asyncore maintainer (until I took it up). > > Engineering is a matter of tastes and opinions, more often than not. > Once you are a maintainer, your taste wins. But if there are no > maintainers, I prefer to trust someone who wasted his time to produce a > patch, rather than just blatantly ignore his job. At least, he had an > urge and produced some code. He did put forward his opinion. Certainly opinions differ, which is what this is. However, even high-quality patches (like the one produced
Re: [Python-Dev] Tracker rights
[Collin Winter]> >Could I be granted rights to the SF tracker? Done. Raymond ___ 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] PEP 364, Transitioning to the Py3K standard library
On 3/6/07, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > >> Supported Renamings > >> === > >> > >> There are at least 4 use cases explicitly supported by this PEP: > >> > >> - - Simple top-level package name renamings, such as ``StringIO`` to > >>``stringio``; > >> > >> - - Sub-package renamings where the package name may or may not be > >>renamed, such as ``email.MIMEText`` to ``email.mime.text``; > >> > >> - - Extension module renaming, such as ``cStringIO`` to > >> ``cstringio``; > >> > > > > This feels a little misleading. The renaming is not restricted to > > extension modules but also works with any top-level module. > > Possibly. It's just a use case that illustrates the solution isn't > tied to pure-Python modules. But I'm not wedded to making this > distinction in the PEP. > > >> Third party package renaming is also supported, via several public > >> interfaces accessible by any Python module. > >> > > > > I guess a .pth file could install the mappings for the third-party > > modules. > > How would that work? .pth files don't execute arbitrary Python code, It does through imports, though. > but it seems like that would be necessary to make this work. OTOH, > your suggestion does make me think that it might be possible to > piggyback the module name mappings onto .pth file processing. It > already understand the 'import' command, so why not a 'rename' command? > Not needed. Just put your mapping code in a module in your package and have a .pth file import that module. > >> ``.mv`` files can appear anywhere in the file system, and there is a > >> programmatic interface provided to parse them, and register the > >> remappings inside them. By default, when Python starts up, all the > >> ``.mv`` files in the ``oldlib`` package are read, and their > >> remappings > >> are automatically registered. This is where all the module > >> remappings > >> should be specified for top-level Python 2.x standard library > >> modules. > >> > > > > I personally prefer to just have this info in a dict with a specified > > format for the dict. I think that should at least be an Open Issue or > > address why a new file format was chosen over that solution (don't > > remember what you said at PyCon =). > > Think about what that big dictionary would look like. It would > essentially be like a text file with mappings one per line, but you'd > have a lot of extra goo on each line (quotes, colons, and commas). I > thought it was important to decentralize the mappings and then to put > them in the simplest format that would serve the purpose. > Right, but I am just not a big special-purpose format guy. =) Plus mappings for third-parties can be kept to a single file for the module they import by keeping the dict in that file. > > Probably should mention that sys.path_importer_cache is then set for > > the magic string. > > Yep. > > > There is no mention of what the sys.meta_path importer/loader is > > used for. > > Good point. > > >> Programmatic Interface > >> == > >> > >> Several methods are added to the ``sys.stdlib_remapper`` object, > >> which > >> third party packages can use to register their own remappings. > > > > Is this really necessary? It might be helpful if this use of mapping > > old to new names gets picked up and used heavily, but otherwise this > > might be overkill. You can easily get the object from > > sys.path_importer_cache as long as you know the magic string used on > > sys.path. > > So, I was thinking that third party packages could use the same > mechanism to provide their own remappings to PEP 8 names. Certainly > if that's something that third party packages want to do, it would be > better to use some common Python API to do that rather than have them > bake their own (or worse, avoid PEP 8-ifying their module names > because of backward compatibility concerns). > > If we agree that's a use case we should support, then either we > support this programmatically or we don't expose the API and do > something automatic when the package is imported. I'm of two > different minds on this. Probably the way I'd rather see this work > is for a package to include a package.mv file in its package > directory, and that file would get automatically loaded when the > package was first imported. > I guess I would want to minimize the API in case we decide to directly integrate this into import itself so we don't have to have both a meta_path and path_importer_cache object. I think the solution works for PEP 3108 and the mail package but I think I would a more integrated solution if we went all out in terms of providing the support outside of the stdlib (at least eventually). > If people really don't like the separate data file, and really want > to just use a Python dictionary, then the way to keep the > decentralization would be to reserve a __*__ symbol in the package > namespace that containe
Re: [Python-Dev] Adding socket timeout to urllib2
Bill Janssen wrote: > If you really need a name other than "timeout" (which seems fine to > me), how about "waiting-with-mild-trepidation-timeout"? Something like "response timeout" might be more descriptive. -- 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] PEP 364, Transitioning to the Py3K standard library
> When Python's import machinery is initialized, the oldlib package is > imported. Inside oldlib there is a class called ``OldStdlibLoader``. > This class implements the PEP 302 interface and is automatically > instantiated, with zero arguments. The constructor reads all the > ``.mv`` files from the oldlib package directory, automatically > registering all the remappings found in those ``.mv`` files. This is > how the Python 2.x standard library is remapped. Will not reading all those .mv files add a lot of overhead? Disk seeks is not cheap. -- 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] Encouraging developers
On Wed, Mar 07, 2007 at 11:10:22AM +0100, "Martin v. L?wis" wrote: -> Giovanni Bajo schrieb: -> > On 06/03/2007 10.52, Martin v. L?wis wrote: -> > -> >> 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. Hi, I just wanted to interject -- when I used the word "mafia", I meant it in this sense: """ Informal. A tightly knit group of trusted associates, as of a political leader: [He] is one of the personal mafia that [the chancellor] brought with him to Bonn. """ (Martin, I certainly didn't intend to offend anyone by implying that they were part of a criminal organization. ;) I have a longer explanation of my view in the blog entry, and anyway I don't want to belabor my own experiences too much, but I would like to point out three things: * there's definitely a group of "trusted associates" -- committers, perhaps? -- and it's not at all clear to outsiders like me how new features, old patches, and old bugs are dealt with. * python-dev is an all-volunteer community. In true open-source fashion, that means that it's incumbent upon people who HAVE problems/issues with a process (like me, and Giovanni) to propose solutions that either someone wants to implement, or that we can implement. I certainly don't expect any of the committers to put tons of effort into a new initiative. * Much of the discussion on this issue of encouraging developers comes down to communicating better with non-python-dev people. Unless someone is already doing it, I will try to write a summary of the last few days of discussion and post it for review. The idea would be to provide a simple one stop wiki page for people who want to contribute. cheers, --titus ___ 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] PCBuild8
Martin v. Löwis wrote: > David Abrahams schrieb: > >> I tried building with MS Visual Studio 2005 from PCBuild8/pcbuild.sln, >> and for me it fails miserably. The first major complaint comes when >> linking pythoncore, where the _init_types symbol can't be found. On >> the other hand, allowing MSVS to convert PCBuild/pcbuild.sln works >> okay. Am I missing something? >> > > Yes, it doesn't work in Python 2.5 as released. This specific problem > has been fixed in the trunk and the 2.5 branch several months ago, > so I recommend to use either of these (or use VS 2003 to build the > released version). > Is there a scheduled date for the release of Python-2.5.1 ? I presume that the PCBuild8 directory should be used when building in 64 bit on Win64. Andrew > 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/andrew%40mackeith.net > > ___ 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] with_traceback
Greg Ewing wrote: > Michael Foord wrote: > >> With the >> proposed changes, modules that do this would *continue* to work, surely >> ? >> > > Probably, but it might mean they were no longer thread > safe. An exception caught and raised in one thread would > be vulnerable to having its traceback clobbered by > another thread raising the same instance. > Right - but that would still be *no worse* than the current situation where that information isn't available on the instance. The current patterns would continue to work unchanged, but the new information wouldn't be available because a single instance is being reused. > There's also the possibility of a traceback unexpectedly > kept alive causing GC problems -- cycles, files not > closed when you expect, etc. > That *could* be a problem, although explicitly closing files is always a good practise :-) Michael Foord > -- > 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/fuzzyman%40voidspace.org.uk > > ___ 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] GeneratorExit inheriting from Exception
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Re: the discussion in: http://mail.python.org/pipermail/python-dev/2006-March/062823.html Just as an FYI, the tlslite package (http://trevp.net/tlslite/) got broken in Python 2.5 and needed the exact fix quoted in the URL above. It was an easy fix, but the argument isn't hypothetical any more! A little late to bother changing anything, though. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF5S1Zhk3bo0lNTrURAjIuAKC1ASOfx0L2+hf+3EKa2hktZYRjEgCeNRAn n395GwS11yM2AMSK67b5oNA= =+iBp -END PGP SIGNATURE- ___ 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] git (Was: Encouraging developers)
Hi python-dev, MvL wrote: >>> the on-disk repository is mighty big and it doesn't work very well >>> on non-Linux systems (at least, not last I looked.) Yes, mercurial or Bazaar do its job better on Windows etc. (and are written in Python :-) >> Not true. The on-disk repository is now one of the more efficient >> ones. After packing the repository, yes (which has to be done manually). > If this still makes git one of the more efficient > dvcs systems, I don't want to see the other ones :-( I do not know about speed issues in git, but I think that mercurial is said to be nearly as fast as git - and at least updating repos seems to work for me quickly. Thomas A. Hein has setup a one-shot mirror of the CPython SVN with branch support here: http://hg.intevation.org/tmp/python/python/ And there is a mirror here: http://hg.alexanderweb.de/python-temp/ You can clone it by running `hg clone URL`, and then `hg serve` to see the repo in your web browser. For me that needed less than 5 minutes on a well-connected machine. For beginners, there is a nice explanation about DVCS here: http://www.selenic.com/mercurial/wiki/index.cgi/UnderstandingMercurial Kind regards, Alexander ___ 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] Google Summer of Code 2007
Google's Summer of Code is on again! I'm in the process of submitting the application for PSF to again be a mentoring organization. A mailing list has been set up for people who are interested in mentoring for the PSF. If you aren't able or willing to mentor but still want to participate in discussion of possible project ideas, you are more than welcome to join also. You can subscribe at: http://mail.python.org/mailman/listinfo/soc2007-mentors/ Because I would like core Python projects to be well represented, I particularly encourage python-devers to participate. James -- James Tauber http://jtauber.com/ journeyman of some http://jtauber.com/blog/ ___ 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] [ 1669539 ] Change (fix!) os.path.isabs() semantics on Win32
Hi, Jason Orendorff wrote: > While we're at it, patch 1669539 makes a similar incompatible change > to ntpath.isabs(). > > The patch is incomplete (no docs) After reading your mail, I've just posted a new version of the patch which adds documentation. > but ripe for a note of encouragement (or summary rejection) from a committer. Comments welcome. Kind regards, Jon Foster ___ 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] PEP 364, Transitioning to the Py3K standard library
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mar 7, 2007, at 4:36 PM, Brett Cannon wrote:
>> >> Third party package renaming is also supported, via several public
>> >> interfaces accessible by any Python module.
>> >>
>> >
>> > I guess a .pth file could install the mappings for the third-party
>> > modules.
>>
>> How would that work? .pth files don't execute arbitrary Python code,
>
> It does through imports, though.
I think it's important to import on demand only though. I should
probably make that clear in the PEP . IOW, "import email"
should not by side-effect import all sub-modules just because there's
a remapping involved. This actually would be quite easy to do, but
it's one of the reasons why the Python 2.5 email package hack goes
through so much trouble.
>> but it seems like that would be necessary to make this work. OTOH,
>> your suggestion does make me think that it might be possible to
>> piggyback the module name mappings onto .pth file processing. It
>> already understand the 'import' command, so why not a 'rename'
>> command?
>
> Not needed. Just put your mapping code in a module in your package
> and have a .pth file import that module.
>> Think about what that big dictionary would look like. It would
>> essentially be like a text file with mappings one per line, but you'd
>> have a lot of extra goo on each line (quotes, colons, and commas). I
>> thought it was important to decentralize the mappings and then to put
>> them in the simplest format that would serve the purpose.
>
> Right, but I am just not a big special-purpose format guy. =) Plus
> mappings for third-parties can be kept to a single file for the module
> they import by keeping the dict in that file.
If you went with the dictionary approach, then you wouldn't need
the .pth file. I guess a question for either approach is what you do
if the top-level module is renamed. E.g. if we rename Carbon to
carbon, where do we put the remapping for this? You can't keep both
directories because of case-insensitive file systems (this has
already been a "fun" pep to develop on a Mac ;). If we narrow the
scope to only the official stdlib, then it's probably not an issue
because we can stick it anywhere and arrange for it to get loaded.
> I guess I would want to minimize the API in case we decide to directly
> integrate this into import itself so we don't have to have both a
> meta_path and path_importer_cache object. I think the solution works
> for PEP 3108 and the mail package but I think I would a more
> integrated solution if we went all out in terms of providing the
> support outside of the stdlib (at least eventually).
It depends on how explicit or magical you want the hooks to be. More
magic is more convenient to hook into, but perhaps harder to decipher.
>> If people really don't like the separate data file, and really want
>> to just use a Python dictionary, then the way to keep the
>> decentralization would be to reserve a __*__ symbol in the package
>> namespace that contained this remapping. Something like __renames__
>> = {...}.
>
> I think the .pth file solution alleviates this need.
At the cost of immediately importing all sub-modules when the package
is imported. Do you agree that lazy loading is a requirement we
should keep?
>> > If you are going to have the object accessible from outside
>> > sys.path_importer_cache I would also add an attribute that contains
>> > the magic string used on sys.path.
>>
>> Of course, that magic string is also available via oldlib._magic. I
>> tend to think it won't be necessary, but if people really want it, I
>> can see putting the magic string as an attribute on the
>> OldStdlibLoader object, e.g. sys.stdlib_remapper.importer_cache_key.
>
> Yeah, that was what I was thinking of. When you manipulate sys.path
> you will need to be aware of it and what it is named.
Good point. Yes, I like putting the magic key on the remapper
object. That does give us a bit of a chicken and egg though because
until you know the magic string, you can't know the
path_importer_cache key, so I think putting the remapper in sys is
useful.
- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRe9OFHEjvBPtnXfVAQIVhwP+Oloyxi/ldlbQ7RM2ifmgN03jc/SYN5Ht
suxsXiK3xwiCU5B/J6uAKDSol/WtxKV/EI2yN42xJIUFV0B0C8DCLHDZHLDAI67V
dfsJMAV+wgn8RjPVSuEw9vOFaVaoyIVvdDn+XMKKfKX6YOBnjLpnLaZJtEVx2QMg
ZigImiWp3VI=
=EHOG
-END PGP SIGNATURE-
___
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] PEP 364, Transitioning to the Py3K standard library
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 7, 2007, at 5:46 PM, BJörn Lindqvist wrote: >> When Python's import machinery is initialized, the oldlib package is >> imported. Inside oldlib there is a class called ``OldStdlibLoader``. >> This class implements the PEP 302 interface and is automatically >> instantiated, with zero arguments. The constructor reads all the >> ``.mv`` files from the oldlib package directory, automatically >> registering all the remappings found in those ``.mv`` files. This is >> how the Python 2.x standard library is remapped. > > Will not reading all those .mv files add a lot of overhead? Disk seeks > is not cheap. I don't think so. There will likely be just a few .mv files in the stdlib and they'd all get loaded at Python startup time. A package's .mv file would only get loaded when the package gets imported. Once read I don't think we'd need to stat for those or read them again. It would definitely be worth measuring, but my guess is the additional overhead will be negligible. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRe9OhnEjvBPtnXfVAQLjYAP7BeVkCMGCVeVt/oqIoywtyP1+B4Ndgmdo uj0JQUSmu2ikRXRoSNtNSoSKdQsco9FI+LHYHwBRJmLKC+IIZ0glP/y+re6hkdOa vWfj1QLYBzWY6EzXRgf92xiR9dXJx92vsiSWAjibRwLlE7d+3eFYqrBa+fvEzQGv pkKjOlTYIKo= =5OL3 -END PGP SIGNATURE- ___ 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 3/7/07, Titus Brown <[EMAIL PROTECTED]> wrote: > On Wed, Mar 07, 2007 at 11:10:22AM +0100, "Martin v. L?wis" wrote: > -> Giovanni Bajo schrieb: > -> > On 06/03/2007 10.52, Martin v. L?wis wrote: > -> > > -> >> 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. > > > > Hi, I just wanted to interject -- when I used the word "mafia", I meant > it in this sense: > > """ > Informal. A tightly knit group of trusted associates, as of a political > leader: [He] is one of the personal mafia that [the chancellor] > brought with him to Bonn. > """ > > (Martin, I certainly didn't intend to offend anyone by implying that > they were part of a criminal organization. ;) > > I have a longer explanation of my view in the blog entry, and anyway I > don't want to belabor my own experiences too much, but I would like to > point out three things: > > * there's definitely a group of "trusted associates" -- committers, >perhaps? -- and it's not at all clear to outsiders like me how new >features, old patches, and old bugs are dealt with. > > * python-dev is an all-volunteer community. In true open-source >fashion, that means that it's incumbent upon people who HAVE >problems/issues with a process (like me, and Giovanni) to propose >solutions that either someone wants to implement, or that we can >implement. I certainly don't expect any of the committers to put >tons of effort into a new initiative. > > * Much of the discussion on this issue of encouraging developers comes >down to communicating better with non-python-dev people. > > Unless someone is already doing it, I will try to write a summary of the > last few days of discussion and post it for review. The idea would be to > provide a simple one stop wiki page for people who want to contribute. > My hope (along with many other hopes =), is to get a good document that explains exactly what is expected for bugs and patches in general and then what is specifically expected for things like new modules for the stdlib or new syntax proposals. With it all written in one place we have something to point people towards (basically what http://www.python.org/dev/intro/ was meant to be, but replaces most of what is in http://www.python.org/dev/). And I hope that once the tracker is up and we have some experience we can make it help us by possibly annotating issues with that they hare or are lacking (e.g., needs tests, needs docs, etc.). That way people can read this doc, understand what is expected for code and such, and then search the tracker for stuff that needs those thing and help deal with it. Basically make it so that if someone goes, "I want to help write a test", they can find out what needs a test. But I get the docs for the new tracker written first. Once that is done I plan to start working on this doc (or docs if it gets too long) as my next big Python project. -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')
Josiah Carlson schrieb: >> 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? > > For people who want the one semantic on all platforms, they can pick > their semantic explicitly. Most people object because of the potential breakage; this change wouldn't remove the breakage (people asking for the old, compatible, behavior still need to change their code). > Alternatively, offer a flag argument in splitext to differentiate > between the two cases. This isn't compatible, either, as older versions will raise an exception because of the extra argument. 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] PEP 364, Transitioning to the Py3K standard library
On 3/7/07, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Mar 7, 2007, at 4:36 PM, Brett Cannon wrote: > > >> >> Third party package renaming is also supported, via several public > >> >> interfaces accessible by any Python module. > >> >> > >> > > >> > I guess a .pth file could install the mappings for the third-party > >> > modules. > >> > >> How would that work? .pth files don't execute arbitrary Python code, > > > > It does through imports, though. > > I think it's important to import on demand only though. And I agree. > I should > probably make that clear in the PEP . IOW, "import email" > should not by side-effect import all sub-modules just because there's > a remapping involved. This actually would be quite easy to do, but > it's one of the reasons why the Python 2.5 email package hack goes > through so much trouble. > I am not suggesting that every rename be imported. All I am saying is that a .pth file could ``import pkg.old_names`` and that old_names module adds the mappings, that's all. It doesn't do anything that you are not proposing be done automatically. -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] Encouraging developers
Titus Brown schrieb: > Hi, I just wanted to interject -- when I used the word "mafia", I meant > it in this sense: > > """ > Informal. A tightly knit group of trusted associates, as of a political > leader: [He] is one of the personal mafia that [the chancellor] > brought with him to Bonn. > """ > > (Martin, I certainly didn't intend to offend anyone by implying that > they were part of a criminal organization. ;) Apology accepted. As to your specific comments: > there's definitely a group of "trusted associates" -- committers, > perhaps? Yes, but not all of the committers are part of the "mafia", i.e. some never review any patches. Also, the "mafia" isn't "tightly nit". I.e. they don't have a hidden agenda they follow, to implement a political quest or some such. > 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. > Much of the discussion on this issue of encouraging developers comes > down to communicating better with non-python-dev people. This is a two-sided thing, of course. The non-python-dev people should also communicate with the python-dev ones, instead of forming false (and unconfirmed) assumptions on how things really work. It's easy to assume conspiracy everywhere, much harder to understand that the people you are interacting with are regular humans who contribute to open source for the same reasons as the next guy. 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
Facundo Batista schrieb: > I finally understood the problem, and build python from the repository, > and made the tests from *this* python (actually, this was an easy step > because I'm on Ubuntu, but *I* would be dead if working in Windows, for > example). > > Ok. *Me*, that I'm not ashame of asking what I don't know, if I didn't > resolve it I'd finally asked in python-dev. But how many people would > have throw the towel withoug getting so far? > > How many people want to submit a patch, or even a bug, or finds a patch > to review, but don't know how to do something and thinks that python-dev > is not the place to ask (too high minds and experienced people and > everything)? If people want to contribute to open source, they just need to learn the rules. One of the primary rules is that most of it is a meritocracy: it's not "high minds" that give reputation, but past contributions. Sure, some people will be shied (sp?) away by merely thinking about python-dev. For them, the barrier is high for *any* contribution to open source software. > What I propose is a dedicated place (mailing list, for example), that is > something like a place where you can go and ask the silliest questions > about helping in the developing process. In principle, python-dev should be such a place, but I can see how it isn't (due to nobody's fault). However, people should feel free to ask any question on [EMAIL PROTECTED], and actually do so. > - 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? > Me, for example, has an actual question to this list: "How can I know, > if I change something in the doc's .tex files, that I'm not broking > the TeX document structure?". You don't have to know. As a general contributor, just submit your 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. 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
Georg Brandl schrieb: > > Of course, the channel would have to be made an "official" Python development > tool and advertised on e.g. the website. Also, it couldn't hurt if some of the > other devs would frequent it too, then :) > I definitely won't: I don't use IRC (or any other chat infrastructure), as a matter of principle. The only way to talk to me "in real time" is in person, or on the phone. (I do make an exception for the PSF board). 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] Fwd: Re: [Python-3000] Removing functions from the operator module
[Collin Winter] >> I don't suppose you've changed your mind about removing operator.truth >> and operator.abs in the seven months since this discussion? [GvR] >No, though I think that operator.truth should be renamed to operator.bool. > >I like the idea that for each built-in op there's a callable in operator. It makes sense to me that built-in ops like + have a corresponding operator function like operator.__add__(), but I don't follow how this logic applies to abs() and bool(). ISTM, operator.bool and operator.abs would not add any value beyond what is already provided by __builtin__.bool and __builtin__.abs. Raymond ___ 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] Fwd: Re: [Python-3000] Removing functions from the operator module
They do, by emphasizing the relationship with special methods. On 3/7/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [Collin Winter] > >> I don't suppose you've changed your mind about removing operator.truth > >> and operator.abs in the seven months since this discussion? > > [GvR] > >No, though I think that operator.truth should be renamed to operator.bool. > > > >I like the idea that for each built-in op there's a callable in operator. > > It makes sense to me that built-in ops like + have a corresponding operator > function like operator.__add__(), but I don't follow how this logic applies > to abs() and bool(). ISTM, operator.bool and operator.abs would not add any > value beyond what is already provided by __builtin__.bool and __builtin__.abs. > > > Raymond > ___ > 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
[Python-Dev] Fwd: Re: Encouraging developers
[Facundo] >> Me, for example, has an actual question to this list: "How can I know, >> if I change something in the doc's .tex files, that I'm not broking >> the TeX document structure?". [MvL] >You don't have to know. As a general contributor, just submit your >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. We should try to keep the documentation buildable at all times so that it will remain visible to everyone at http://docs.python.org/dev/ . The script in Tools/scripts/texcheck.py does a pretty good job of detecting the most common LaTeX markup errors. For small doc changes, it is usually not too much of a challenge because you're either modifying existing text or are copying in existing markup from the surrounding text. Raymond ___ 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 3/7/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > > Me, for example, has an actual question to this list: "How can I know, > > if I change something in the doc's .tex files, that I'm not broking > > the TeX document structure?". > > You don't have to know. As a general contributor, just submit your > 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. Even better, the same machine running refleaks every 12 hours also builds the docs. It will complain if the docs don't build, so be aggressive with the docs. Any failures are sent do python-checkins. You can also see the results from trunk here: http://docs.python.org/dev/ http://docs.python.org/dev/results/ Here are the 2.5 results (only builds doc, not refleak test): http://docs.python.org/dev/2.5/ http://docs.python.org/dev/2.5/results/ These pages are generated from Misc/build.sh. As I mentioned, build.sh runs every 12 hours. n ___ 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] Fwd: Re: Encouraging developers
On 3/7/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > We should try to keep the documentation buildable at all times so that it > will remain visible to everyone at http://docs.python.org/dev/ . Broken doc doesn't get pushed though. So the worst that will happen is that the dev doc will be slightly out of date if it doesn't build. Since we (or George Yoshida) tends to fix these pretty fast, the worst that happens is the docs are a day behind. To reiterate from my other msg to Martin, the building of doc (and the refleak test run) is all done in Misc/build.sh. This also does a make install in case something breaks there. n ___ 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] Google Summer of Code 2007
On 3/7/07, James Tauber <[EMAIL PROTECTED]> wrote: > Google's Summer of Code is on again! > > I'm in the process of submitting the application for PSF to again be > a mentoring organization. > Because I would like core Python projects to be well represented, I > particularly encourage python-devers to participate. Just to be sure -- Jython is under the umbrella of the PSF for the purposes of the SoC, right? Thanks, -Frank ___ 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] Google Summer of Code 2007
While I guess there's nothing to stop Jython applying in its own right, it makes far more sense to be under the umbrella of PSF. PyPy projects last year were under PSF, for example. I would *strongly* encourage the submission of some Jython projects under the PSF umbrella. James On 07/03/2007, at 9:13 PM, Frank Wierzbicki wrote: > On 3/7/07, James Tauber <[EMAIL PROTECTED]> wrote: >> Google's Summer of Code is on again! >> >> I'm in the process of submitting the application for PSF to again be >> a mentoring organization. > >> Because I would like core Python projects to be well represented, I >> particularly encourage python-devers to participate. > Just to be sure -- Jython is under the umbrella of the PSF for the > purposes of the SoC, right? > > Thanks, > > -Frank ___ 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] Google Summer of Code 2007
On 3/7/07, James Tauber <[EMAIL PROTECTED]> wrote: > I would *strongly* encourage the submission of some Jython projects > under the PSF umbrella. Great! I'll do my best to get some submitted. -Frank ___ 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] PEP 364, Transitioning to the Py3K standard library
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 7, 2007, at 7:39 PM, Brett Cannon wrote: >> I think it's important to import on demand only though. > > And I agree. Cool. >> I should >> probably make that clear in the PEP . IOW, "import email" >> should not by side-effect import all sub-modules just because there's >> a remapping involved. This actually would be quite easy to do, but >> it's one of the reasons why the Python 2.5 email package hack goes >> through so much trouble. > I am not suggesting that every rename be imported. All I am saying is > that a .pth file could ``import pkg.old_names`` and that old_names > module adds the mappings, that's all. It doesn't do anything that you > are not proposing be done automatically. Cool, I see. What advantage do you see with importing the pkg.old_names from a .pth file rather than just including whatever is necessary right in pkg/__init__.py? - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAwUBRe9+wHEjvBPtnXfVAQI60AP8D7PFDNVR/BiLEoz8iQKYJUOsd8vtXTF5 lcmDi+L0SZ8N95KxlI2icQmaRk2wNhO+0Djp3XJA/aKiHTWa3ImIksuGFb7WIRSY HhSi2NXPRJOitHz3NhDrfMOFXbDq+Ci4E1YU/+XjtfnsEYqkcLvehvlpY3Urod/j Z/9g6BDGOuM= =pxLk -END PGP SIGNATURE- ___ 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] PEP 364, Transitioning to the Py3K standard library
On 3/7/07, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Mar 7, 2007, at 7:39 PM, Brett Cannon wrote: > > >> I think it's important to import on demand only though. > > > > And I agree. > > Cool. > > >> I should > >> probably make that clear in the PEP . IOW, "import email" > >> should not by side-effect import all sub-modules just because there's > >> a remapping involved. This actually would be quite easy to do, but > >> it's one of the reasons why the Python 2.5 email package hack goes > >> through so much trouble. > > I am not suggesting that every rename be imported. All I am saying is > > that a .pth file could ``import pkg.old_names`` and that old_names > > module adds the mappings, that's all. It doesn't do anything that you > > are not proposing be done automatically. > > Cool, I see. What advantage do you see with importing the > pkg.old_names from a .pth file rather than just including whatever is > necessary right in pkg/__init__.py? > It is only needed if the name of the package itself changed since you need a bootstrap before you try to import the package itself. Otherwise __init__.py is the right place if the root package name has not changed. -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')
Hi Martin, "Martin v. Löwis" wrote: > [EMAIL PROTECTED] schrieb: [...] > > The use-cases being discussed here would be better served by having new > > APIs that do particular things and don't change existing semantics, > > though. For example, a "guess_mime_type(path)" function which could > > examine a path and figure out its mime type based on its extension > > (among other things). > > I disagree. The current behavior is incorrect (and always has been); > the new behavior is clearly correct. 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. You silently omitted this part of glyph's objection: [EMAIL PROTECTED] wrote: [...] > > Incompatible changes may be *acceptable* for feature releases, but that > doesn't > mean they are desirable. The cost of incompatibility should be considered for > every change. This cost is particularly bad when the incompatibility is of > the > "silent breakage" variety - the change being discussed here would not be the > sort of thing that one could, say, produce a warning about or gently > deprecate; > anything relying on the old behavior would suddenly be incorrect, and any > software wishing to straddle the 2.5<->2.6 boundary would be better off just > implementing their own splitext() than relying on the stdlib. 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. 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. This will cause some code that was working correctly to give wrong answers, rather than an exception or any indication that this previously correct use is now incorrect and causing bugs. 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. See also the comment at the bottom of http://sourcefrog.net/weblog/software/aesthetics/interface-levels.html about "perverse interface design". I wonder if "First, do no harm" should be an explicit guideline when it comes evaluating incompatible changes, even if they fix other things? There seems to be the problem that all existing users of splitext that may encounter '.foo' will need to audit their code to see if they are relying on previously undefined behaviour that will change. I think it would be much more helpful for python to somehow help users discover this fact, than simply define the previously undefined behaviour to be different to what they might have been relying on. 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. -Andrew. ___ 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] new 2.5.1 release schedule
Sorry for the delay. We really wanted to put out a 2.5.1 release earlier. Due to busy and conflicting schedules, we had to postpone a bit. We are on track for the following schedule: 2.5.1c1 - Tuesday, April 3 2.5.1 -Thursday April 12 (assuming a c2 is not necessary) I don't know of any release blocking problems. If you have any issues, please let me know. Cheers, n ___ 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 <[EMAIL PROTECTED]> wrote: > 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. 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. 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 . - Josiah ___ 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] Fwd: Re: [Python-3000] Removing functions from the operator module
On 3/7/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [Collin Winter] > >> I don't suppose you've changed your mind about removing operator.truth > >> and operator.abs in the seven months since this discussion? > > [GvR] > >No, though I think that operator.truth should be renamed to operator.bool. > > > >I like the idea that for each built-in op there's a callable in operator. > > It makes sense to me that built-in ops like + have a corresponding operator > function like operator.__add__(), but I don't follow how this logic applies > to abs() and bool(). ISTM, operator.bool and operator.abs would not add any > value beyond what is already provided by __builtin__.bool and __builtin__.abs. > FWIW, I've always thought of the operator module as a place to look when I need to pass some bit of syntax (eg., attribute lookup, "in", addition) to a higher-order function. bool() and abs() aren't syntax, so I would never look in operator. 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] splitext('.cshrc')
Josiah Carlson wrote:
[...]
>
> 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.
>
> 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 .
It's not about cross-platform behaviour. It's already the same:
>>> import posixpath, ntpath
>>> ntpath.splitext('.cshrc')
('', '.cshrc')
>>> posixpath.splitext('.cshrc')
('', '.cshrc')
And as I understand it, the current proposal would change this behaviour the
same way on win32 and POSIX, although I may not have kept up with that part of
the discussion enough. Is there a genuine desire for this to behave differently
on different platforms?
I think what I'd probably like to see is the existing undefined (but
well-understood and predictable) behaviour to be declared defined, and a warning
put in the documentation that it probably doesn't do what you expect for this
case. And then for those that want the new behaviour, provide a new function
(and prominently advertise it in the relevant part of the documentation). Yes
it sucks having two similar functions, which will inevitably have similar names,
but that's the price you pay for getting the interface wrong the first time
around.
-Andrew.
___
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 <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> [...]
> >
> > 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.
> >
> > 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 .
>
> It's not about cross-platform behaviour. It's already the same:
>
> >>> import posixpath, ntpath
> >>> ntpath.splitext('.cshrc')
> ('', '.cshrc')
> >>> posixpath.splitext('.cshrc')
> ('', '.cshrc')
>
> And as I understand it, the current proposal would change this behaviour the
> same way on win32 and POSIX, although I may not have kept up with that part of
> the discussion enough. Is there a genuine desire for this to behave
> differently
> on different platforms?
Ahh, I thought that it was different on different platforms. Nevermind
then. Add a new function and be done with it.
- Josiah
___
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
