Re: [Python-Dev] Please revert autofolding of tracker edit form
On Wed, Mar 30, 2011 at 10:08 PM, Terry Reedy wrote: > Yes, there is a good reason why database records are routinely displayed in > labeled and located fields rather than in variable length natural language > sentences with a monochrome font. Form letters, of course, are an exception. Yep. While I'm fine with folding away some of the verbose fields, the current implementation is jarring. I also get the flicker before the fold happens, but the sentence describing status doesn't seem like a good idea for regular users. I would expect only the "second box" from the top to get folded. Making folding a per-user setting would be appropriate. -- Fred L. Drake, Jr. "Give me the luxuries of life and I will willingly do without the necessities." --Frank Lloyd Wright ___ 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] Please revert autofolding of tracker edit form
Please see this thread in the tracker-discuss list: http://mail.python.org/pipermail/tracker-discuss/2011-March/thread.html Skip ___ 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] Please revert autofolding of tracker edit form
skip> Please see this thread in the tracker-discuss list: skip> http://mail.python.org/pipermail/tracker-discuss/2011-March/thread.html That didn't read right. I meant see that thread to see other discussion about the folding topic, not that it would necessary convince you all to change your minds. I'd still like to see some folding, but more selective and with closer attention paid to the current stage of the issue. Skip ___ 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] Please revert autofolding of tracker edit form
On Thu, 31 Mar 2011 06:20:03 -0500 s...@pobox.com wrote: > > skip> Please see this thread in the tracker-discuss list: > skip> > http://mail.python.org/pipermail/tracker-discuss/2011-March/thread.html > > That didn't read right. I meant see that thread to see other discussion > about the folding topic, not that it would necessary convince you all to > change your minds. > > I'd still like to see some folding, but more selective and with closer > attention paid to the current stage of the issue. Agreed that some folding could be beneficial, but with a better UI (no flickering, use of a jQuery-alike recommended). Also, field-based visualization of tracker properties should be retained in the "minimized" form, instead of natural language. It would be nice if someone with UI design experience was interested in maintaining/improving the tracker. Regards Antoine. ___ 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] faulthandler is now part of Python 3.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/30/2011 09:54 PM, Victor Stinner wrote: > Hi, > > I pushed my faulthandler module into the default branch (Python 3.3). > Since one week, I fixed a lot of bugs (platform issues), improved the > tests and Antoine wrote a new implementation of dump_backtraces_later() > using a thread (instead of SIGALRM+alarm()). It should now work on all > platforms (but register() is not available on Windows). > > Use "python -X faulthandler" or "PYTHONFAULTHANDLER=1 python" to install > the fault handler at startup (catch segfaults and other fatal errors). > > You can also register a signal (e.g. SIGUSR1) to dump the traceback on > this signal. > > The latest added feature is to be able to the dump the traceback after a > timeout and exit the process: we may use it on regrtest.py to learn more > about test_multiprocess and test_threadsignals hangs. Issue #11393 has a > patch implementing this issue: add --timeout option to regrtest.py. You > can also just dump the traceback after the timeout without exiting. > > Py_FatalError() always print the Python traceback (except if an > exception was raised: print the exception with its traceback). > > For more information, read the doc: > http://docs.python.org/dev/library/faulthandler.html > > Please tell me if you have any issue related to faulthandler. > > -- > > If you get "undefined reference to `_PyFaulthandler_Init'" compiler > error, copy Modules/Setup.dist to Modules/Setup (cp Modules/Setup.dist > Modules/Setup). > > test_faulthandler hangs on AMD64 Gentoo Wide 3.x and AMD64 OpenIndiana > 3.x. It looks to be related to the stack overflow test (the stack is > maybe not limited on these buildbots?). I have a patch, but I cannot > test it because these buildbots are dead (oops, sorry!). > > Most buildbots are red because a regression in test_logging (since 2 > days): I disabled temporary the test (issue #11557), I hope that the > situation will be better in a few hours. > > Thank you Antoine for your reviews! Thanks very much for you hard work on this cool new feature. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2Ud/gACgkQ+gerLs4ltQ6BVACgo822OajfnxbVQInroX8q5L7B wX0AoMpEJLNk0ffEBJs+C2CDXiaIz+yf =rf2C -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] Non-code changes on "old" branches
On 3/31/2011 12:31 AM, Mark Hammond wrote: Hi, There are a couple of changes I'd like to make and would like some guidance on policy: http://bugs.python.org/issue6498 is a documentation bug which exists in Python 2.6 and later. The patch in that bug touches the docs and a comment in one source file. Is it acceptable to push that change to the 2.6 branch, or should I start with 2.7? I believe no, not 2.6, lest you be asked to revert. Start with 2.7 -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] EuroPython 2011: call for paper is ending - Please spread the word!
Hi all members, I'm Francesco and I am writing on behalf of "Python Italia APS", a no-profit association promoting EuroPython conference. (www.europython.eu) Europython End of Call for Presentations is April 6th. I'd like to ask to you to forward this mail to anyone that you feel may be interested. We're looking for proposals on every aspects of Python: programming from novice to advanced levels, applications and frameworks, or how you have been involved in introducing Python into your organisation. **First-time speakers are especially welcome**; EuroPython is a community conference and we are eager to hear about your experience. If you have friends or colleagues who have something valuable to contribute, twist their arms to tell us about it! Presenting at EuroPython We will accept a broad range of presentations, from reports on academic and commercial projects to tutorials and case studies. As long as the presentation is interesting and potentially useful to the Python community, it will be considered for inclusion in the programme. Can you show the conference-goers something new and useful? Can you show attendees how to: use a module? Explore a Python language feature? Package an application? If so, consider submitting a talk. Talks and hands-on trainings There are two different kind of presentations that you can give as a speaker at EuroPython: * **Regular talk**. These are standard "talk with slides", allocated in slots of 45, 60 or 90 minutes, depending on your preference and scheduling constraints. A Q&A session is held at the end of the talk. * **Hands-on training**. These are advanced training sessions for a smaller audience (10-20 people), to dive into the subject with all details. These sessions are 4-hours long, and audience will be strongly encouraged to bring a laptop to experiment. They should be prepared with less slides and more source code. If possible, trainers will also give a short "teaser talk" of 30 minutes the day before the training, to tease delegates into attending the training. In the talk submission form, we assume that you intend to give a regular talk on the subject, but you will be asked if you are available for also doing a hands-on training on the very same subject. Speakers that will give a hands-on training are rewarded with a **free entrance** to EuroPython to compensate for the longer preparation required, and might also be eligible for a speaking fee (which we cannot confirm at the moment). Topics and goals Specific topics for EuroPython presentations include, but are not limited to: - Core Python - Other implementations: Jython, IronPython, PyPy, and Stackless - Python libraries and extensions - Python 3.x migration - Databases - Documentation - GUI Programming - Game Programming - Network Programming - Open Source Python projects - Packaging Issues - Programming Tools - Project Best Practices - Embedding and Extending - Science and Math - Web-based Systems Presentation goals usually are some of the following: - Introduce audience to a new topic they are unaware of - Introduce audience to new developments on a well-known topic - Show audience real-world usage scenarios for a specific topic (case study) - Dig into advanced and relatively-unknown details on a topic - Compare different options in the market on a topic Community-based talk voting --- This year, for the first time in EuroPython history, the talk voting process is fully public. Every partecipant gains the right to vote for talks submitted during the Call For Papers, as soon as they commit to their presence at the conference by buying a ticket. See all the details in the talk voting[1] page. Contacts For any further question, feel free to contact the organizers at i...@pycon.it. Thank you! [1]: http://ep2011.europython.eu/talk-voting -- ->PALLA ___ 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] Please revert autofolding of tracker edit form
On Thu, Mar 31, 2011 at 10:16 PM, Antoine Pitrou wrote: > It would be nice if someone with UI design experience was interested in > maintaining/improving the tracker. The challenge is the same as with any UI designer involvement in open source stuff though: they really need to be given the freedom to do proper workflow analysis and come up with something that *works*, but in practice things tend to get derailed into endless bikeshed arguments, since *everyone* has an opinion on the UI design of the tools they have to use. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Please revert autofolding of tracker edit form
Le jeudi 31 mars 2011 à 23:48 +1000, Nick Coghlan a écrit : > On Thu, Mar 31, 2011 at 10:16 PM, Antoine Pitrou wrote: > > It would be nice if someone with UI design experience was interested in > > maintaining/improving the tracker. > > The challenge is the same as with any UI designer involvement in open > source stuff though: they really need to be given the freedom to do > proper workflow analysis and come up with something that *works*, but > in practice things tend to get derailed into endless bikeshed > arguments, since *everyone* has an opinion on the UI design of the > tools they have to use. Well, obviously they have, since they are users and are directly impacted by any changes. The line this draws is between clean-sheet design and iterative improvement. Clearly it would be difficult to try to sell us a wholesale change in how the issue tracker organizes things. (AFAIK, Roundup itself comes from a platonic, clean-sheet design of an ideal bug tracker: we had to customize it a lot) Regards Antoine. ___ 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] faulthandler is now part of Python 3.3
2011/3/31 Tres Seaver : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 03/30/2011 09:54 PM, Victor Stinner wrote: >> Hi, >> >> I pushed my faulthandler module into the default branch (Python 3.3). >> Since one week, I fixed a lot of bugs (platform issues), improved the >> tests and Antoine wrote a new implementation of dump_backtraces_later() >> using a thread (instead of SIGALRM+alarm()). It should now work on all >> platforms (but register() is not available on Windows). >> >> Use "python -X faulthandler" or "PYTHONFAULTHANDLER=1 python" to install >> the fault handler at startup (catch segfaults and other fatal errors). >> >> You can also register a signal (e.g. SIGUSR1) to dump the traceback on >> this signal. >> >> The latest added feature is to be able to the dump the traceback after a >> timeout and exit the process: we may use it on regrtest.py to learn more >> about test_multiprocess and test_threadsignals hangs. Issue #11393 has a >> patch implementing this issue: add --timeout option to regrtest.py. You >> can also just dump the traceback after the timeout without exiting. >> >> Py_FatalError() always print the Python traceback (except if an >> exception was raised: print the exception with its traceback). >> >> For more information, read the doc: >> http://docs.python.org/dev/library/faulthandler.html >> >> Please tell me if you have any issue related to faulthandler. >> >> -- >> >> If you get "undefined reference to `_PyFaulthandler_Init'" compiler >> error, copy Modules/Setup.dist to Modules/Setup (cp Modules/Setup.dist >> Modules/Setup). >> >> test_faulthandler hangs on AMD64 Gentoo Wide 3.x and AMD64 OpenIndiana >> 3.x. It looks to be related to the stack overflow test (the stack is >> maybe not limited on these buildbots?). I have a patch, but I cannot >> test it because these buildbots are dead (oops, sorry!). >> >> Most buildbots are red because a regression in test_logging (since 2 >> days): I disabled temporary the test (issue #11557), I hope that the >> situation will be better in a few hours. >> >> Thank you Antoine for your reviews! > > Thanks very much for you hard work on this cool new feature. Furthermore, let's hope we don't have to use it much! :) -- Regards, Benjamin ___ 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] devguide: Add a table of contents to the FAQ.
On 30/03/2011 23.20, Antoine Pitrou wrote: On Tue, 29 Mar 2011 21:00:22 +0200 ezio.melotti wrote: http://hg.python.org/devguide/rev/f722956afeac changeset: 405:f722956afeac user:Ezio Melotti date:Tue Mar 29 22:00:13 2011 +0300 summary: Add a table of contents to the FAQ. Could it be collapsed by default? I don't think there's an easy way to collapse it by default. In most of the cases I anyway check the FAQ for something specific. Having a list at the top provides an overview of the questions and also an easy way to locate and jump to the right answer. It's quite long, and redundant with the sidebar. The list is indeed redundant, but the sidebar is not really usable here. Best Regards, Ezio Melotti thanks Antoine. ___ 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] devguide: Add a table of contents to the FAQ.
On Thu, 31 Mar 2011 18:47:39 +0300, Ezio Melotti wrote: > On 30/03/2011 23.20, Antoine Pitrou wrote: > > On Tue, 29 Mar 2011 21:00:22 +0200 > > ezio.melotti wrote: > >> http://hg.python.org/devguide/rev/f722956afeac > >> changeset: 405:f722956afeac > >> user:Ezio Melotti > >> date:Tue Mar 29 22:00:13 2011 +0300 > >> summary: > >>Add a table of contents to the FAQ. > > Could it be collapsed by default? > > I don't think there's an easy way to collapse it by default. > In most of the cases I anyway check the FAQ for something specific. > Having a list at the top provides an overview of the questions and also > an easy way to locate and jump to the right answer. > > > It's quite long, and redundant with the sidebar. > > The list is indeed redundant, but the sidebar is not really usable here. I agree with this point. The sidebar list of questions is effectively useless. Most FAQ lists start with the long list of questions. I don't see why this one should be different :) -- R. David Murray http://www.bitdance.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Use regrtest.py --timeout on buildbots
Hi, I just added a --timeout option to Lib/test/regrtest.py: if a test (one function, not a whole file) takes more than TIMEOUT seconds, the traceback is dumped and it exits. I tested it on 3 buildbots with a timeout of 5 minutes and it worked as expected: see #11727 for examples. It would be nice to have this feature enabled on all buildbots. We may set a default timeout of 15 minutes. If a test takes more than 15 minutes, something goes wrong! Some buildbot use a timeout of 1200 or 3600 seconds for regrtest (all tests). But the build slave should be able to override the default timeout. What do you think? Victor ___ 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] Please revert autofolding of tracker edit form
On 3/31/2011 9:59 AM, Antoine Pitrou wrote: Le jeudi 31 mars 2011 à 23:48 +1000, Nick Coghlan a écrit : On Thu, Mar 31, 2011 at 10:16 PM, Antoine Pitrou wrote: It would be nice if someone with UI design experience was interested in maintaining/improving the tracker. The challenge is the same as with any UI designer involvement in open source stuff though: they really need to be given the freedom to do proper workflow analysis and come up with something that *works*, but in practice things tend to get derailed into endless bikeshed arguments, since *everyone* has an opinion on the UI design of the tools they have to use. Well, obviously they have, since they are users and are directly impacted by any changes. The line this draws is between clean-sheet design and iterative improvement. Clearly it would be difficult to try to sell us a wholesale change in how the issue tracker organizes things. Here is my proposal for a redesign based on an analysis of my usage ;-). I have a 1600x1050 (or thereabouts), 20" (measured) diagonal, 17" across screen. The left column has a 7/8" margin, 2 3/8" text area, and 1" gutter. These could be shrunk to say, 1/4, 2, 1/4, saving 1 3/8". The comment box is 8 1/2", message boxes are wider, but the extra width is not used if one uses hard returns in the comment box. In any case, the message boxes could be narrowed by 1 1/8". This would allow a right column of 1/4+2+1/4". Except for title, comment, and file boxes, we then stack the classification and process boxes in the right column. The nosy box would be last so it can list one name per line. It would end with an [ add me ] button. It should also have a box for adding people (as with Assigned To). Having to look up tracker names in Assigned To and retype exactly in the nosy list is an error-prone nuisance. Putting all these boxes to the side leaves them visible for those who want them but out of the way and ignorable for those who do not. I would be nice is both the left and right columns had buttons to hide and show. This would help people accessing issues from smaller screens, as with a netbook. The title is not really classification and belongs at the very top. It could even go in the 1 1/8" top bar, which is currently mostly empty, along with the issue number. I would like to try putting the comment box after the last (most recent) comment, as that is the message one most ofter responds to. Having to now scroll up and down between comment box and last message(s) is often of a nuisance. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 11715: building Python from source on multiarch Debian/Ubuntu
> I would like to apply this patch (or its moral equivalent) to all active, > affected branches of Python, meaning 2.5 through 2.7, and 3.1 through 3.3, as > soon as possible. Without this, it will be very difficult for anyone on > future Ubuntu or Debian releases to build Python. Since it's not a new > feature, but just a minor fix to the build process, I think it should be okay > to back port. If I understand the policy correctly, 2.5 and 2.6 are not considered active branches, so any doc, build or bug fixes are not acceptable. Regards ___ 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] Please revert autofolding of tracker edit form
Hi, On 31/03/2011 19.52, Terry Reedy wrote: On 3/31/2011 9:59 AM, Antoine Pitrou wrote: Le jeudi 31 mars 2011 à 23:48 +1000, Nick Coghlan a écrit : On Thu, Mar 31, 2011 at 10:16 PM, Antoine Pitrou wrote: It would be nice if someone with UI design experience was interested in maintaining/improving the tracker. The challenge is the same as with any UI designer involvement in open source stuff though: they really need to be given the freedom to do proper workflow analysis and come up with something that *works*, but in practice things tend to get derailed into endless bikeshed arguments, since *everyone* has an opinion on the UI design of the tools they have to use. Well, obviously they have, since they are users and are directly impacted by any changes. The line this draws is between clean-sheet design and iterative improvement. Clearly it would be difficult to try to sell us a wholesale change in how the issue tracker organizes things. Here is my proposal for a redesign based on an analysis of my usage ;-). You can add your proposal to http://wiki.python.org/moin/DesiredTrackerFeatures There you can find several suggestions and discussions about possible changes to the tracker (it's similar to python-ideas ML, but it's about the tracker and it's on a wiki page). Bugs and concrete suggestions should be submitted to the meta-tracker (http://psf.upfronthosting.co.za/roundup/meta/) or discussed on the tracker-discuss mailing list. I have a 1600x1050 (or thereabouts), 20" (measured) diagonal, 17" across screen. The left column has a 7/8" margin, 2 3/8" text area, and 1" gutter. These could be shrunk to say, 1/4, 2, 1/4, saving 1 3/8". The comment box is 8 1/2", message boxes are wider, but the extra width is not used if one uses hard returns in the comment box. In any case, the message boxes could be narrowed by 1 1/8". This would allow a right column of 1/4+2+1/4". Except for title, comment, and file boxes, we then stack the classification and process boxes in the right column. The nosy box would be last so it can list one name per line. It would end with an [ add me ] button. It should also have a box for adding people (as with Assigned To). Having to look up tracker names in Assigned To and retype exactly in the nosy list is an error-prone nuisance. Putting all these boxes to the side leaves them visible for those who want them but out of the way and ignorable for those who do not. You can also use the "(list)" link to open a popup and search for users to add to the nosy instead of copying them from the "Assigned To" list by hand. (I know that popup are not the most usable thing and that the search has some limitation (e.g. it's case sensitive), but that's the best we have right now, and works fairly well for me.) Also one of the design goal is to keep the interface as simple as possible, so we try to avoid adding more things unless they are really useful. Having an expanded list of names doesn't sound too useful to me. I would be nice is both the left and right columns had buttons to hide and show. This would help people accessing issues from smaller screens, as with a netbook. The title is not really classification and belongs at the very top. It could even go in the 1 1/8" top bar, which is currently mostly empty, along with the issue number. I would like to try putting the comment box after the last (most recent) comment, as that is the message one most ofter responds to. Having to now scroll up and down between comment box and last message(s) is often of a nuisance. This summer I plan to participate again to GSOC and work on the bug tracker (if my proposal gets accepted). There are already a few things I want to improve and I also have some patches ready that just need to be updated and applied. In the meanwhile you can use http://wiki.python.org/moin/DesiredTrackerFeatures to list the things that you would like to see, so that they don't get lost in the archives of python-dev. Best Regards, Ezio Melotti ___ 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] [Python-checkins] cpython: Issue #11393: get more information on assertion error (test_faulthandler)
> > http://hg.python.org/cpython/rev/61626c3f3a54
> >...
> > -assert (b -a)>= pause
> > +assert (b - a)>= pause, "{{}}< {{}}".format(b - a, pause)
>
> > +assert (b - a)>= pause, "{{}}< {{}}".format(b - a, pause)
>
> >>> a,b,pause = 0,0,1
> >>> "{{}} < {{}}".format(b - a, pause)
> '{} < {}'
>
> I suspect you want 1 or 3 braces.
>
> Terry
Nope, I really want {{}}: the diff is on a template using to generate
Python code executed in a subprocess.
Victor
___
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] Please revert autofolding of tracker edit form
> What's more, it lacks the most important: the issue title. Notice that the issue title was always there, in your browser's title bar (unless you have a web browser that doesn't display the page title). 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] devguide: Add a table of contents to the FAQ.
On Fri, Apr 1, 2011 at 2:34 AM, R. David Murray wrote: > I agree with this point. The sidebar list of questions is effectively > useless. Indeed. If it's simple, I'd actually be inclined to reduce the depth of the sidebar in this case to only show the categories and not the individual questions. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Issue 11715: building Python from source on multiarch Debian/Ubuntu
On Fri, Apr 1, 2011 at 3:35 AM, Éric Araujo wrote: > If I understand the policy correctly, 2.5 and 2.6 are not considered > active branches, so any doc, build or bug fixes are not acceptable. Actual build fixes may be acceptable, if they're needed to allow people to build from a version control checkout or from source (since they need to be able to do that in order to apply security patches). However, the combination of "running on Ubuntu 11.04+" and "need to build security patched version of old Python" seems unlikely. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Issue 11715: building Python from source on multiarch Debian/Ubuntu
On Apr 01, 2011, at 08:37 AM, Nick Coghlan wrote: >On Fri, Apr 1, 2011 at 3:35 AM, Éric Araujo wrote: >> If I understand the policy correctly, 2.5 and 2.6 are not considered >> active branches, so any doc, build or bug fixes are not acceptable. > >Actual build fixes may be acceptable, if they're needed to allow >people to build from a version control checkout or from source (since >they need to be able to do that in order to apply security patches). > >However, the combination of "running on Ubuntu 11.04+" and "need to >build security patched version of old Python" seems unlikely. I'll just plead as RM for 2.6 that it's not as unlikely as it seems :). I'm happy to defer to MvL on its (non) applicability to 2.5. Cheers, -Barry signature.asc Description: 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] Please revert autofolding of tracker edit form
On 3/31/2011 9:52 AM, Terry Reedy wrote: I would like to try putting the comment box after the last (most recent) comment, as that is the message one most ofter responds to. Having to now scroll up and down between comment box and last message(s) is often of a nuisance. +1. Or +0 reverse time sequence the messages. ___ 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] Please revert autofolding of tracker edit form
On Thu, 31 Mar 2011 23:59:36 +0200, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= wrote: > Notice that the issue title was always there, in your browser's title > bar (unless you have a web browser that doesn't display the page title). I do. -- R. David Murray http://www.bitdance.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Please revert autofolding of tracker edit form
Glenn Linderman wrote: On 3/31/2011 9:52 AM, Terry Reedy wrote: I would like to try putting the comment box after the last (most recent) comment, as that is the message one most ofter responds to. Having to now scroll up and down between comment box and last message(s) is often of a nuisance. +1. Or +0 reverse time sequence the messages. -1 on reverse time sequence of messages -- no top posting! ;) ~Ethan~ ___ 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] warn_unused_result warnings
I'm rather sick of seeing this warnings on all compiles, so I propose we enable the -Wno-unused-results option. I judge that most of the cases where this occurs are error reporting functions, where not much with return code can be done. -- Regards, Benjamin ___ 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] devguide: Add a table of contents to the FAQ.
On Fri, 01 Apr 2011 08:29:29 +1000, Nick Coghlan wrote: > On Fri, Apr 1, 2011 at 2:34 AM, R. David Murray wro= > te: > > I agree with this point. =A0The sidebar list of questions is effectively > > useless. > > Indeed. If it's simple, I'd actually be inclined to reduce the depth > of the sidebar in this case to only show the categories and not the > individual questions. I believe that requires editing the sphinx page template and adding a special case of some sort. -- R. David Murray http://www.bitdance.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Impaired Usability of the Mercurial Source Viewer
The Hg source viewer needs to be tweaked to improve its usability. What we've got now is a step backwards from the previous svn viewer. Looking at http://hg.python.org/cpython/file/default/Lib/linecache.py for example, there are two issues. 1) the code cannot be cut-and-pasted because the line numbers are commingled with the source text. 2) the code is hard to read because of the alternating white and gray bars. Contrast that to the more typical, beautiful presentations with a solid background and the ability to cut-and-paste without grabbing line numbers: http://dpaste.org/qyKv/ http://code.activestate.com/recipes/577629-namedtupleabc-abstract-base-class-mix-in-for-named/ Raymond P.S. The old svn viewer worked great (looked good and could be cut), but that was changed just before the Mercurial switchover (the fonts changed, the line numbering code changed, and the leading changed), so it is not a good comparison anymore.___ 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] Please revert autofolding of tracker edit form
On Mar 31, 2011, at 9:52 AM, Terry Reedy wrote: > I would like to try putting the comment box after the last (most recent) > comment, as that is the message one most ofter responds to. Having to now > scroll up and down between comment box and last message(s) is often of a > nuisance. While that sounds logical, I think it will be a usability problem. If someone doesn't see a the comment box immediately, they may not know to scroll down past dozens of messages to find it. Rather that being trial-and-error amateur web page designers, it would be better to follow proven models. All of the following have the comment box at the top and the messages in reverse chronological order: * http://news.ycombinator.com/item?id=2393587 * http://digg.com/news/entertainment/top_12_game_shows_of_all_time * https://twitter.com/ 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] Please revert autofolding of tracker edit form
2011/3/31 Raymond Hettinger : > > On Mar 31, 2011, at 9:52 AM, Terry Reedy wrote: > > I would like to try putting the comment box after the last (most recent) > comment, as that is the message one most ofter responds to. Having to now > scroll up and down between comment box and last message(s) is often of a > nuisance. > > While that sounds logical, I think it will be a usability problem. If > someone doesn't see a the comment box immediately, they may not know to > scroll down past dozens of messages to find it. > Rather that being trial-and-error amateur web page designers, it would be > better to follow proven models. All of the following have the comment box > at the top and the messages in reverse chronological order: Please no reverse chronological order! Every bug tracker I know which isn't underconfigured roundup uses chronological order. -- Regards, Benjamin ___ 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] Please revert autofolding of tracker edit form
On Thu, 2011-03-31 at 16:27 -0700, Raymond Hettinger wrote: > > On Mar 31, 2011, at 9:52 AM, Terry Reedy wrote: > > > I would like to try putting the comment box after the last (most > > recent) comment, as that is the message one most ofter responds to. > > Having to now scroll up and down between comment box and last > > message(s) is often of a nuisance. > > > > > While that sounds logical, I think it will be a usability problem. If > someone doesn't see a the comment box immediately, they may not know > to scroll down past dozens of messages to find it. > > > Rather that being trial-and-error amateur web page designers, it would > be better to follow proven models. All of the following have the > comment box at the top and the messages in reverse chronological > order: > > > * http://news.ycombinator.com/item?id=2393587 > * http://digg.com/news/entertainment/top_12_game_shows_of_all_time > * https://twitter.com/ > > > > > Raymond How 'bout no? YouTube uses this and it's horrid and unnatural, and bulletin boards have been using chronological order for whiles with great success. Reverse chronological order has a niche for feeds, updates, whatever you want to call it, but when it comes to following a discussion it's much easier to start with the first word. ___ 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] Please revert autofolding of tracker edit form
On Mar 31, 2011, at 5:02 PM, Westley Martínez wrote: > > How 'bout no? YouTube uses this and it's horrid and unnatural, and > bulletin boards have been using chronological order for whiles with > great success. Reverse chronological order has a niche for feeds, > updates, whatever you want to call it, but when it comes to following a > discussion it's much easier to start with the first word. Perhaps the most important part is that the comment box goes at the top. 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] Please revert autofolding of tracker edit form
On 3/31/2011 7:27 PM, Raymond Hettinger wrote: On Mar 31, 2011, at 9:52 AM, Terry Reedy wrote: I would like to try putting the comment box after the last (most recent) comment, as that is the message one most ofter responds to. Having to now scroll up and down between comment box and last message(s) is often of a nuisance. While that sounds logical, I think it will be a usability problem. If someone doesn't see a the comment box immediately, they may not know to scroll down past dozens of messages to find it. Even though such is standard for the majority of web fora? Rather that being trial-and-error amateur web page designers, it would be better to follow proven models. All of the following have the comment box at the top and the messages in reverse chronological order: I really hate that since it means scrolling down before reading, and because this is unusually, so by habit I start reading at the top. * http://news.ycombinator.com/item?id=2393587 * http://digg.com/news/entertainment/top_12_game_shows_of_all_time * https://twitter.com/ In my experience, reverse is maybe 20% of sites I have visited. Forward: guido's blog, and I presume others at site; ars technica, stackoverflow, slashdot, most or all php-based web fora, -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Please revert autofolding of tracker edit form
On Thu, 31 Mar 2011 23:59:36 +0200 "Martin v. Löwis" wrote: > > What's more, it lacks the most important: the issue title. > > Notice that the issue title was always there, in your browser's title > bar (unless you have a web browser that doesn't display the page title). Sure, but it's far removed from where the rest of the issue is displayed. Regards Antoine. ___ 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] Impaired Usability of the Mercurial Source Viewer
On 3/31/2011 7:15 PM, Raymond Hettinger wrote: The Hg source viewer needs to be tweaked to improve its usability. What we've got now is a step backwards from the previous svn viewer. Looking at http://hg.python.org/cpython/file/default/Lib/linecache.py for example, there are two issues. 1) the code cannot be cut-and-pasted because the line numbers are commingled with the source text. 2) the code is hard to read because of the alternating white and gray bars. Contrast that to the more typical, beautiful presentations with a solid background and the ability to cut-and-paste without grabbing line numbers: I complete agree with this. The bars are for super long lines, especially of data, as with 132 char Fortran output on old ibm printers. Even then, the bars were 3 lines wide. 80- char text lines do not need them. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Please revert autofolding of tracker edit form
On Thu, 31 Mar 2011 12:52:23 -0400 Terry Reedy wrote: > > Here is my proposal for a redesign based on an analysis of my usage ;-). > I have a 1600x1050 (or thereabouts), 20" (measured) diagonal, 17" across > screen. > > The left column has a 7/8" margin, 2 3/8" text area, and 1" gutter. > These could be shrunk to say, 1/4, 2, 1/4, saving 1 3/8". > The comment box is 8 1/2", message boxes are wider, but the extra width > is not used if one uses hard returns in the comment box. In any case, > the message boxes could be narrowed by 1 1/8". > This would allow a right column of 1/4+2+1/4". Let's say that by using non-metric units you have already lost me, sorry. Regards Antoine. ___ 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] Impaired Usability of the Mercurial Source Viewer
On Thu, 31 Mar 2011 16:15:48 -0700 Raymond Hettinger wrote: > The Hg source viewer needs to be tweaked to improve its usability. > What we've got now is a step backwards from the previous svn viewer. > > Looking at http://hg.python.org/cpython/file/default/Lib/linecache.py for > example, > there are two issues. 1) the code cannot be cut-and-pasted because the > line numbers are commingled with the source text. 2) the code is hard > to read because of the alternating white and gray bars. > > Contrast that to the more typical, beautiful presentations with a solid > background and the ability to cut-and-paste without grabbing line > numbers: This is something you need to discuss with the Mercurial project. See http://mercurial.selenic.com/bts/ and http://mercurial.selenic.com/wiki/ContributingChanges The advantage of Mercurial over SVN is that it's written in Python ;) Regards Antoine. ___ 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] warn_unused_result warnings
On Thu, 31 Mar 2011 18:11:46 -0500 Benjamin Peterson wrote: > I'm rather sick of seeing this warnings on all compiles, so I propose > we enable the -Wno-unused-results option. I judge that most of the > cases where this occurs are error reporting functions, where not much > with return code can be done. If you manage to hack this gcc-specific option into the build chain without breaking other compilers, why not :) Regards Antoine. ___ 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] Impaired Usability of the Mercurial Source Viewer
On Mar 31, 2011, at 5:30 PM, Antoine Pitrou wrote: > On Thu, 31 Mar 2011 16:15:48 -0700 > Raymond Hettinger wrote: >> The Hg source viewer needs to be tweaked to improve its usability. >> What we've got now is a step backwards from the previous svn viewer. >> >> Looking at http://hg.python.org/cpython/file/default/Lib/linecache.py for >> example, >> there are two issues. 1) the code cannot be cut-and-pasted because the >> line numbers are commingled with the source text. 2) the code is hard >> to read because of the alternating white and gray bars. >> >> Contrast that to the more typical, beautiful presentations with a solid >> background and the ability to cut-and-paste without grabbing line >> numbers: > > This is something you need to discuss with the Mercurial project. > See http://mercurial.selenic.com/bts/ and > http://mercurial.selenic.com/wiki/ContributingChanges Are you saying that our official code viewer isn't configurable without getting a change through the Hg project itself? Does that mean that we have have to live with it in its crippled form? 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] Impaired Usability of the Mercurial Source Viewer
Le jeudi 31 mars 2011 à 17:46 -0700, Raymond Hettinger a écrit : > On Mar 31, 2011, at 5:30 PM, Antoine Pitrou wrote: > > > On Thu, 31 Mar 2011 16:15:48 -0700 > > Raymond Hettinger wrote: > >> The Hg source viewer needs to be tweaked to improve its usability. > >> What we've got now is a step backwards from the previous svn viewer. > >> > >> Looking at http://hg.python.org/cpython/file/default/Lib/linecache.py for > >> example, > >> there are two issues. 1) the code cannot be cut-and-pasted because the > >> line numbers are commingled with the source text. 2) the code is hard > >> to read because of the alternating white and gray bars. > >> > >> Contrast that to the more typical, beautiful presentations with a solid > >> background and the ability to cut-and-paste without grabbing line > >> numbers: > > > > This is something you need to discuss with the Mercurial project. > > See http://mercurial.selenic.com/bts/ and > > http://mercurial.selenic.com/wiki/ContributingChanges > > Are you saying that our official code viewer isn't configurable > without getting a change through the Hg project itself? Well, it is something that is configurable through patching. You might want to keep the patch private to hg.python.org, of course. But perhaps you can also convince Mercurial devs that they should it themselves, if you are persuasive enough ;) > Does that mean that we have have to live with it in its crippled form? Well, I'm sure we have lived with lots of things in "crippled form" along the years, including SVN itself. I don't think the "source code viewer" is impacting anybody's ability to contribute. At worse you can click the "raw" link on the left and get a nice clean view of the source in your editor of choice. Regards Antoine. ___ 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] Please revert autofolding of tracker edit form
Raymond Hettinger wrote: On Mar 31, 2011, at 9:52 AM, Terry Reedy wrote: I would like to try putting the comment box after the last (most recent) comment, as that is the message one most ofter responds to. Having to now scroll up and down between comment box and last message(s) is often of a nuisance. While that sounds logical, I think it will be a usability problem. If someone doesn't see a the comment box immediately, they may not know to scroll down past dozens of messages to find it. Are there cases where someone should be posting new comments who /hasn't/ read the existing comments? I would hope that new comments would come only after reading what has already transpired -- in which case one would find the comment box when one runs out of previous comments to read. ~Ethan~ ___ 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] Impaired Usability of the Mercurial Source Viewer
On Mar 31, 2011, at 5:55 PM, Antoine Pitrou wrote:
> Le jeudi 31 mars 2011 à 17:46 -0700, Raymond Hettinger a écrit :
>> On Mar 31, 2011, at 5:30 PM, Antoine Pitrou wrote:
>>
>>> On Thu, 31 Mar 2011 16:15:48 -0700
>>> Raymond Hettinger wrote:
The Hg source viewer needs to be tweaked to improve its usability.
What we've got now is a step backwards from the previous svn viewer.
Looking at http://hg.python.org/cpython/file/default/Lib/linecache.py for
example,
there are two issues. 1) the code cannot be cut-and-pasted because the
line numbers are commingled with the source text. 2) the code is hard
to read because of the alternating white and gray bars.
Contrast that to the more typical, beautiful presentations with a solid
background and the ability to cut-and-paste without grabbing line
numbers:
>>>
>>> This is something you need to discuss with the Mercurial project.
>>> See http://mercurial.selenic.com/bts/ and
>>> http://mercurial.selenic.com/wiki/ContributingChanges
>>
>> Are you saying that our official code viewer isn't configurable
>> without getting a change through the Hg project itself?
>
> Well, it is something that is configurable through patching.
> You might want to keep the patch private to hg.python.org, of course.
> But perhaps you can also convince Mercurial devs that they should it
> themselves, if you are persuasive enough ;)
Surely, we at least have control over our own CSS.
At http://hg.python.org/cpython/static/style-paper.css
there are two lines that control the alternating bars:
.parity0 { background-color: #f0f0f0; }
.parity1 { background-color: white; }
One of those could be changed to match the other so that we
at can at least get a solid background.
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] warn_unused_result warnings
Le 01/04/2011 01:11, Benjamin Peterson a écrit : I'm rather sick of seeing this warnings on all compiles, so I propose we enable the -Wno-unused-results option. I judge that most of the cases where this occurs are error reporting functions, where not much with return code can be done. Can't we try to fix the warnings instead of turning them off? Or is it possible to only turn off these warnings on a specific function? Modules/faulthandler.c emits a lot of such compiler warning, but there is nothing interesting to do on write() error. I tried to turn off the warning on an instruction using (void)write(...), but gcc doesn't understand that I don't care of write() result here. Victor ___ 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] warn_unused_result warnings
2011/3/31 Victor Stinner : > Le 01/04/2011 01:11, Benjamin Peterson a écrit : >> >> I'm rather sick of seeing this warnings on all compiles, so I propose >> we enable the -Wno-unused-results option. I judge that most of the >> cases where this occurs are error reporting functions, where not much >> with return code can be done. > > Can't we try to fix the warnings instead of turning them off? Or is it > possible to only turn off these warnings on a specific function? It strikes me as excessively ugly. (see below) > > Modules/faulthandler.c emits a lot of such compiler warning, but there is > nothing interesting to do on write() error. I tried to turn off the warning > on an instruction using (void)write(...), but gcc doesn't understand that I > don't care of write() result here. You have actually have an assignment, like x = write(). -- Regards, Benjamin ___ 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] Impaired Usability of the Mercurial Source Viewer
Le 01/04/2011 01:15, Raymond Hettinger a écrit : The Hg source viewer needs to be tweaked to improve its usability. What we've got now is a step backwards from the previous svn viewer. Looking at http://hg.python.org/cpython/file/default/Lib/linecache.py for example, there are two issues. 1) the code cannot be cut-and-pasted because the line numbers are commingled with the source text. 2) the code is hard to read because of the alternating white and gray bars. You can use mirrors like: https://bitbucket.org/mirror/cpython/ On Bitbucket, line numbers are displayed, but you can copy/paste code without the line number. And the background is just white. For example: https://bitbucket.org/mirror/cpython/src/3558eecd84f0/Modules/faulthandler.c Victor ___ 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] Impaired Usability of the Mercurial Source Viewer
On Mar 31, 2011, at 6:28 PM, Victor Stinner wrote: > Le 01/04/2011 01:15, Raymond Hettinger a écrit : >> The Hg source viewer needs to be tweaked to improve its usability. >> What we've got now is a step backwards from the previous svn viewer. >> >> Looking at http://hg.python.org/cpython/file/default/Lib/linecache.py for >> example, >> there are two issues. 1) the code cannot be cut-and-pasted because the >> line numbers are commingled with the source text. 2) the code is hard >> to read because of the alternating white and gray bars. > You can use mirrors like: > https://bitbucket.org/mirror/cpython/ > > On Bitbucket, line numbers are displayed, but you can copy/paste code without > the line number. And the background is just white. For example: > https://bitbucket.org/mirror/cpython/src/3558eecd84f0/Modules/faulthandler.c > That's *way* better: https://bitbucket.org/mirror/cpython/src/3558eecd84f0/Lib/linecache.py Why can't we have that for our primary source viewer. 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] Impaired Usability of the Mercurial Source Viewer
2011/3/31 Raymond Hettinger : > > On Mar 31, 2011, at 6:28 PM, Victor Stinner wrote: > > Le 01/04/2011 01:15, Raymond Hettinger a écrit : > > The Hg source viewer needs to be tweaked to improve its usability. > > What we've got now is a step backwards from the previous svn viewer. > > Looking at http://hg.python.org/cpython/file/default/Lib/linecache.py for > example, > > there are two issues. 1) the code cannot be cut-and-pasted because the > > line numbers are commingled with the source text. 2) the code is hard > > to read because of the alternating white and gray bars. > > You can use mirrors like: > https://bitbucket.org/mirror/cpython/ > > On Bitbucket, line numbers are displayed, but you can copy/paste code > without the line number. And the background is just white. For example: > https://bitbucket.org/mirror/cpython/src/3558eecd84f0/Modules/faulthandler.c > > > That's *way* better: > https://bitbucket.org/mirror/cpython/src/3558eecd84f0/Lib/linecache.py > Why can't we have that for our primary source viewer. Because it's closed source. -- Regards, Benjamin ___ 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] Impaired Usability of the Mercurial Source Viewer
On 3/31/2011 8:30 PM, Antoine Pitrou wrote: > On Thu, 31 Mar 2011 16:15:48 -0700 > Raymond Hettinger wrote: >> The Hg source viewer needs to be tweaked to improve its usability. >> What we've got now is a step backwards from the previous svn viewer. >> >> Looking at http://hg.python.org/cpython/file/default/Lib/linecache.py for >> example, >> there are two issues. 1) the code cannot be cut-and-pasted because the >> line numbers are commingled with the source text. 2) the code is hard >> to read because of the alternating white and gray bars. >> >> Contrast that to the more typical, beautiful presentations with a solid >> background and the ability to cut-and-paste without grabbing line >> numbers: > > This is something you need to discuss with the Mercurial project. > See http://mercurial.selenic.com/bts/ and > http://mercurial.selenic.com/wiki/ContributingChanges The hgweb interface is templated. You can already change it via "style" in the hgweb.conf. There are several styles already available in the templates folder of the install, and you could provide your own if you like too. -- Scott Dial sc...@scottdial.com scod...@cs.indiana.edu ___ 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] Impaired Usability of the Mercurial Source Viewer
Can someone give Raymond write access to the website already so he can fix it himself? On Thu, Mar 31, 2011 at 6:44 PM, Benjamin Peterson wrote: > 2011/3/31 Raymond Hettinger : >> >> On Mar 31, 2011, at 6:28 PM, Victor Stinner wrote: >> >> Le 01/04/2011 01:15, Raymond Hettinger a écrit : >> >> The Hg source viewer needs to be tweaked to improve its usability. >> >> What we've got now is a step backwards from the previous svn viewer. >> >> Looking at http://hg.python.org/cpython/file/default/Lib/linecache.py for >> example, >> >> there are two issues. 1) the code cannot be cut-and-pasted because the >> >> line numbers are commingled with the source text. 2) the code is hard >> >> to read because of the alternating white and gray bars. >> >> You can use mirrors like: >> https://bitbucket.org/mirror/cpython/ >> >> On Bitbucket, line numbers are displayed, but you can copy/paste code >> without the line number. And the background is just white. For example: >> https://bitbucket.org/mirror/cpython/src/3558eecd84f0/Modules/faulthandler.c >> >> >> That's *way* better: >> https://bitbucket.org/mirror/cpython/src/3558eecd84f0/Lib/linecache.py >> Why can't we have that for our primary source viewer. > > Because it's closed source. > > > > -- > Regards, > Benjamin > ___ > 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 (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Please revert autofolding of tracker edit form
Ethan Furman writes: > -1 on reverse time sequence of messages -- no top posting! ;) I'd really like this to be a browse-time option, and for bonus points, it should be "sticky". For issues I'm not familiar with, I want to read in more or less chronological order. For issues I *am* familiar with, I want reverse chronological order. ___ 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] Please revert autofolding of tracker edit form
>> I would like to try putting the comment box after the last (most >> recent) comment, as that is the message one most ofter responds >> to. Having to now scroll up and down between comment box and last >> message(s) is often of a nuisance. Raymond> While that sounds logical, I think it will be a usability Raymond> problem. If someone doesn't see a the comment box immediately, Raymond> they may not know to scroll down past dozens of messages to Raymond> find it. For me, the comment box is never available immediately. I always have to scroll. After the first two sections have been filled in, most of that information is static, excepting the nosy list changes and the occasional change of state. Almost all the action is going to be in the comments, review buttons and patches which you always have to scroll to see. That's one reason I asked for the collapsible expanders. If nothing else, You could make it easy to jump to the comments or the list of patches with a link near the top of the page labelled "Jump to comments" (or similar) which links to an anchor further down the page. Raymond> Rather that being trial-and-error amateur web page designers, Raymond> it would be better to follow proven models. I don't know who here uses Chrome, but if you have access to it, take a look at the bookmark manager. While it doesn't have what I had in mind at the leaf level (I'd like the leaves to expand under their parents, not in a separate pane), it does use expanders to reveal different amounts of detail. It's a model many other "directory traversal" GUIs use. Admittedly, we have a bit flatter hierarchy, but the leaves are huge. See attached. (Apologies for the image size. Who would have thought such a modest image would be so hard to compress?) Skip <>___ 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] Please revert autofolding of tracker edit form
Terry> Even though such is standard for the majority of web fora? I participate in a couple different web forums (914s and swimming). Both present their topics in chronological order and provide a link at the top of every page which jumps the user to the first unread message (no matter how many pages there are in the thread or where you happen to be at the moment). Reverse chronological order is a nightmare for anybody trying to bring themselves up-to-speed for the first time on a long discussion. In my mind, the only place where reverse order makes sense is in cases where messages rapidly become less important as they age. Think following the Japanese earthquake/tsunami aftermath. Skip ___ 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] Please revert autofolding of tracker edit form
Antoine> Let's say that by using non-metric units you have already lost Antoine> me, sorry. Wouldn't it be cool if you could feed the text to Google Translator and have it not only translate the English to bad French, but translate the units to metric (hopefully with more accuracy than the language conversion)? :-) Skip ___ 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] Please revert autofolding of tracker edit form
Ethan> Are there cases where someone should be posting new comments who Ethan> /hasn't/ read the existing comments? I would hope that new Ethan> comments would come only after reading what has already Ethan> transpired -- in which case one would find the comment box when Ethan> one runs out of previous comments to read. Again, drawing on the forum model, the new message box is always at the bottom (of each page) in my experience. Skip ___ 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] Please revert autofolding of tracker edit form
On 3/31/2011 5:22 PM, Raymond Hettinger wrote: Perhaps the most important part is that the comment box goes at the top. As long as it is adjacent to the last comment, that would be fine. (said while tongue removing the last bit of supper from the space outside the teeth) ___ 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] Impaired Usability of the Mercurial Source Viewer
On Thu, 31 Mar 2011 18:20:53 -0700
Raymond Hettinger wrote:
>
> Surely, we at least have control over our own CSS.
> At http://hg.python.org/cpython/static/style-paper.css
> there are two lines that control the alternating bars:
>
> .parity0 { background-color: #f0f0f0; }
> .parity1 { background-color: white; }
>
> One of those could be changed to match the other so that we
> at can at least get a solid background.
It also applies to the changelog and therefore would make the changelog
uglier (you had already asked me to make that change and I reverted it
after I tried it). The changelog is, IMHO, a bit more important than the
source viewer.
Impacting only the source viewer looks like it would require a patch
to the generation logic, although I could be mistaken.
Regards
Antoine.
___
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] Please revert autofolding of tracker edit form
On Thu, 2011-03-31 at 21:18 -0500, s...@pobox.com wrote: > Terry> Even though such is standard for the majority of web fora? > > I participate in a couple different web forums (914s and swimming). Both > present their topics in chronological order and provide a link at the top of > every page which jumps the user to the first unread message (no matter how > many pages there are in the thread or where you happen to be at the moment). > > Reverse chronological order is a nightmare for anybody trying to bring > themselves up-to-speed for the first time on a long discussion. In my mind, > the only place where reverse order makes sense is in cases where messages > rapidly become less important as they age. Think following the Japanese > earthquake/tsunami aftermath. > > Skip Exactly; my blog is in reverse chronological order because it's more of a news bulletin and less of a discussion thread. As for the comment box, why not have it at the top AND bottom. The top could have the entire form and the bottom could have just a small quick-reply box, or perhaps a back to top button (which probably exists already). ___ 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] Please revert autofolding of tracker edit form
On Thu, 2011-03-31 at 21:21 -0500, s...@pobox.com wrote: > Antoine> Let's say that by using non-metric units you have already lost > Antoine> me, sorry. > > Wouldn't it be cool if you could feed the text to Google Translator and have > it not only translate the English to bad French, but translate the units to > metric (hopefully with more accuracy than the language conversion)? :-) > > Skip It'd be accurate enough for most cases, but still limited by double precision floating-point math. ___ 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] Please revert autofolding of tracker edit form
On 3/31/2011 8:26 PM, Antoine Pitrou wrote: On Thu, 31 Mar 2011 12:52:23 -0400 Terry Reedy wrote: Here is my proposal for a redesign based on an analysis of my usage ;-). I have a 1600x1050 (or thereabouts), 20" (measured) diagonal, 17" across screen. The left column has a 7/8" margin, 2 3/8" text area, and 1" gutter. These could be shrunk to say, 1/4, 2, 1/4, saving 1 3/8". The comment box is 8 1/2", message boxes are wider, but the extra width is not used if one uses hard returns in the comment box. In any case, the message boxes could be narrowed by 1 1/8". This would allow a right column of 1/4+2+1/4". Let's say that by using non-metric units you have already lost me, My bad. Im science context I have always used S.I units, and wish U.S. would switch. Just forgot here. Multiply everything by 2.4 for cm. Screen 43 cm wide, Left column 2.2 + 6 + 2.4, perhaps shrink to .6 + 4.8 + .6. Add right column with same. Comment box is 21 cm. Message boxes wider, could lose 2.7. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Impaired Usability of the Mercurial Source Viewer
On 2011-03-31, at 8:44 PM, Antoine Pitrou wrote:
> On Thu, 31 Mar 2011 18:20:53 -0700
> Raymond Hettinger wrote:
>>
>> Surely, we at least have control over our own CSS.
>> At http://hg.python.org/cpython/static/style-paper.css
>> there are two lines that control the alternating bars:
>>
>> .parity0 { background-color: #f0f0f0; }
>> .parity1 { background-color: white; }
>>
>> One of those could be changed to match the other so that we
>> at can at least get a solid background.
>
> It also applies to the changelog and therefore would make the changelog
> uglier (you had already asked me to make that change and I reverted it
> after I tried it). The changelog is, IMHO, a bit more important than the
> source viewer.
>
> Impacting only the source viewer looks like it would require a patch
> to the generation logic, although I could be mistaken.
It shouldn't. You just need to change the template. The easiest thing to do is
probably to copy the 'paper' style into a new directory, adjust your hgweb
style parameter to point to it, and edit the 'fileline' entry in the 'map' file
for your new style.
smime.p7s
Description: S/MIME cryptographic 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] Impaired Usability of the Mercurial Source Viewer
On 3/31/2011 8:44 PM, Antoine Pitrou wrote:
Impacting only the source viewer looks like it would require a patch
to the generation logic, although I could be mistaken.
Is there not something in the context surrounding the changelog and the
source viewer that is different? And therefore something like
.something-specific-to-sourceviewer .parity0 { background-color: white; }
might be possible, to affect only one of them, and not the other? That
is the whole point of CSS, of course.
___
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
