Re: [Python-Dev] Proposal: add odict to collections
On Sun, 2008-06-15 at 00:12 -0700, Raymond Hettinger wrote:
> From: "Cesare Di Mauro" <[EMAIL PROTECTED]>
> > The same problem happens with dictionary updates:
> >
> > d = {}
> > d[k1] = v1
> > d[k2] = v2
> > d[k1] = v3
> >
> > The last instruction just replaces the existing entry, so I'm +0 for the
> > first result.
>
> There's a difference. With dicts, the third insertion *replaces* the value
> while leaving data structure unmolested. Also, the key
> doesn't update (an equal but identical key doesn't get substituted).
>
> With an odict that preserves insertion order, you're talking about *deleting*
> the old entry and *appending* the new one, complete
> with both the new key and new value. If that is the desired behavior, then
> it becomes impossible to update the value of an odict
> entry while leaving its insertion order unchanged. What a bummer.
>
> An alternative behavior is to replace the value, leaving the key in its
> original position. But then, you've messed-up the
> expectation that v2 occurs before v3 eventhough v3 was inserted later. This
> is especially weird because you keep k1 which was
> inserted earlier, not k3 which is equivalent but not necessarily identical.
An other behavior making sense would be to append a new position for the
key. With your example above:
d.index(k1) = [0, 2]
d.index(k2) = [1, ]
Deletion of a key would have to be explicit (and
delete all associated indexes).
An other way to think of such a structure would be as a list, for which
each item would also have an associated key.
I think someone mentioned the link with a list during this thread, but
here I am not referring to implementation, but the feature of a
container-like class that would allow to access elements either by
position (index), and that would be a one-to-one association, or key,
and that would be a one-to-possibly-many association.
> Neither behavior is de facto, TheRightWay(tm). Each has its uses. Each has
> its oddities. Each will have its fans who find that
> particular way to be the best and most intuitive.
>
> One other issue arises if you choose the approach where updating a value
> triggers re-ordering -- the the dict view concept no longer
> translates very well. With regular dicts, you can update values while
> iterating. Losing that would be a bummer too.
>
> I don't favor one over the other. Am just pointing-out that the proposal is
> a little more complex than simply wishing for an
> ordered verion of a dictionary and expecting that that wish is self-defining
> in a way the matches everyone's intuition, use cases,
> and expectations.
>
>
> 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/lgautier%40gmail.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] Looking for VCS usage scenarios
On Mon, 2008-11-03 at 08:46 +0100, Ralf Schmitt wrote: > On Mon, Nov 3, 2008 at 1:05 AM, Brett Cannon <[EMAIL PROTECTED]> wrote: > > I have started the DVCS PEP which can be seen at > > http://docs.google.com/Doc?id=dg7fctr4_40dvjkdg64 . Not much is there > > beyond the rationale, usage scenarios I plan to use, and what other > > sections I plan to write. > > > > I think you really should not exclude any dvcs based on it's > implementation language. > I.e. requiring it being written in python for the sake of "eating your > own dogfood" is just a very weak argument. > git is certainly missing from your list. It does certainly miss from the list, but the argument might be more "favor your users"; call it nepotism if you like. If I understand it clearly, it is not a requirement, but more a good point. If it does "taste like dog food" in places, then it might be easier to: - make informed statements about what might be the reason (on an implementation standpoint - regarding features, that's an other story) - have the cook more receptive to comments L. > Regards, > - Ralf > ___ > 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/lgautier%40gmail.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] VS 2010 compiler
Hi Carl, Looks promising. Any chance the effort would consider cross-compiling (from Linux) as a possible objective ? Best, Laurent On Wed, Sep 30, 2015, 3:58 PM Carl Kleffner wrote: > Concerning the claims that mingw is difficult: > > The mingwpy package is a sligthly modified mingw-w64 based gcc toolchain, > that is in development. It is designed for simple use and for much better > compatibility to the standard MSVC python builds. It should work out of the > box, as long as the \Scripts folder is in the PATH. > > It is not 'officially' released and announced, due to the fact that some > features are missing, the documentation has to be written and the build > scripts for the toolchain are not (yet) published. > > Install a prerelease of mingwpy with pip: > > pip install -i https://pypi.anaconda.org/carlkl/simple mingwpy > > or with conda: (thanks to omnia-md) > > conda install -c https://conda.anaconda.org/omnia mingwpy > > and use it at usual with pip install or python setup.py > > You may need to configure %USERPROFILE%\pydistutils.cfg to use mingwpy if > you have an MSVC compiler installed: > > [config] > compiler=mingw32 > [build] > compiler=mingw32 > [build_ext] > compiler=mingw32 > > Or you install the latest portable winpython distribution > https://winpython.github.io that contains the toolchain as well and works > out of the box. > > Future releases of mingwpy will be deployed on Pypi. > > That has to be said: the main emphasis of the toolchain is building python > binary extension (C, C++, GFORTRAN) on windows, not building python itself. > > Carl > > 2015-09-30 21:15 GMT+02:00 Paul Moore : > >> On 30 September 2015 at 16:57, Chris Barker - NOAA Federal >> wrote: >> >> 1. Install "Windows SDK for Windows 7 and .NET Framework 4" (v7.1) >> >> 2. Work from an SDK command prompt (with the environment variables >> >> set, and the SDK on PATH). >> >> 3. Set DISTUTILS_USE_SDK=1 >> >> 4. Done. >> > >> > This, unfortunately is non-trivial, and really a pain if you want to >> > automate builds. >> >> Please clarify. What is non-trivial? Installing the SDK? I know, but >> we said that's out of scope. Using an SDK command prompt? It is, sort >> of, particularly if (like me) you use powershell. But again, not our >> issue. I assume setting the environment variable isn't an issue - you >> can do it for the session rather than globally, so even restrictive >> permissions aren't a problem. >> >> I appreciate you mightn't be intending this as criticism of the >> instructions, but many people do criticise in exactly this sort of >> way. Unix developers, in particular, who have limited Windows >> knowledge, find this level of instruction really frustrating to deal >> with. That's not a complaint - I have *huge* appreciation for >> non-Windows users who bother to make builds for Windows users - but it >> is an acknowledgement that often the audience for this sort of >> instruction are stumped by Microsoft's less than intuitive install >> processes... >> >> For context, installing mingw is just as messy, complicated and error >> prone (I speak from experience :-)) so it's unfair to complain that >> the above is a non-trivial pain. I know of no install option that's >> *less* straightforward than this (except of course for "install any >> version of Visual Studio 2010, even the free ones" - if you have >> access to those, use them!) >> >> For automation, why not use Appveyor? See >> https://packaging.python.org/en/latest/appveyor/ Unless you meant >> setting up a local build machine. If you want a simple "install a >> Python build environment" process, you could look at >> https://github.com/pfmoore/pybuild - I haven't used it in a while (as >> it's of no relevance to me, because I have VS2010) but it does work. I >> never publicised or distributed it, because I got too much pushback in >> terms of "but it doesn't work right on my system" (typically because >> the system in question usually *wasn't* a clean build of Windows) that >> I didn't have time or energy to address. But if it works for you, go >> for it. >> >> I'll push an addition to packaging.python.org, probably tomorrow. >> >> Paul >> > ___ >> Python-Dev mailing list >> Python-Dev@python.org >> https://mail.python.org/mailman/listinfo/python-dev >> > Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/cmkleffner%40gmail.com >> > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/lgautier%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] (Adaptive) Shivers sort variant of Tim sort
Hello,
I developed a C sorting algorithms library that currently has a few
dozens of algorithms and thousands of variants when choosing
parameters (like threshold for switching to insertion sort, etc.).
(I compile each variant on demand in custom tests
to avoid having a bloated source file.)
My benchmarks could be improved but however I found that Shivers' sort
and adaptive Shivers' sort (aka Jugé's sort) performs better than
Tim's sort.
I don't know if it will still be true with the benchmarks in Python.
If you're open to the idea that maybe Tim's sort can be improved and
are willing to benchmark it, it can be done easily by switching the
main natural merge strategy like I did here :
https://github.com/LLyaudet/TSODLULS/commit/2968c4b4ca58ae794157dc9636ed87017e5f7a17
The relevant code is not very long :
/**
* This strategy is from ShiversSort:
* see the research report by Olin Shivers, Georgia Institute of
Technology, 2002.
* It uses bitwise tricks to check condition on floor of logarithms in
base 2 of runs lengths.
* When I benchmark it, it is slightly faster than Tim's sort strategy.
*/
#define TSODLULS_natural_merge_main_strategy__Shivers_sort \
while(merge_state.i_run_instances_count > 1){\
size_t i_merge_at = merge_state.i_run_instances_count - 2;\
size_t i_order_of_magnitude =
merge_state.arr_run_instances[i_merge_at + 1].i_length;\
if(i_order_of_magnitude < ((~i_order_of_magnitude) &
merge_state.arr_run_instances[i_merge_at].i_length) ){\
break;\
}\
i_compare_result = TSODLULS_MERGE_TWO_RUNS(&merge_state, i_merge_at);\
if(i_compare_result != 0){\
goto clean_and_return_error;\
}\
}\
/**
* This strategy is from AdaptiveShiversSort:
* see the articles by Vincent Jugé, for example 1024 Bulletin de la
SIF, avril 2020, in French,
* or the preprint on arXiv or SODA 2020 proceedings.
* It uses bitwise tricks to check condition on floor of logarithms in
base 2 of runs lengths.
* When I benchmark it, it is slightly faster than Tim's sort strategy.
* Despite its ressemblance with Shivers's sort,
* the distinct properties of this strategy make that JugéSort would
probably be a better name than AdaptiveShiversSort,
* or an even better name for the whole algorithm should be
TimShiversJugéSort and I must have missed many names ;)
* With AdaptiveShiversSort we avoid 'é' and diacritics in function names ;P
*/
#define TSODLULS_natural_merge_main_strategy__adaptive_Shivers_sort \
while(merge_state.i_run_instances_count > 2){\
size_t i_merge_at = merge_state.i_run_instances_count - 3;\
size_t i_order_of_magnitude =
merge_state.arr_run_instances[i_merge_at + 1].i_length |
merge_state.arr_run_instances[i_merge_at + 2].i_length;\
if(i_order_of_magnitude < ((~i_order_of_magnitude) &
merge_state.arr_run_instances[i_merge_at].i_length) ){\
break;\
}\
i_compare_result = TSODLULS_MERGE_TWO_RUNS(&merge_state, i_merge_at);\
if(i_compare_result != 0){\
goto clean_and_return_error;\
}\
}\
In my library the merge strategy is a parameter and I switch its macro
when compiling competitors algorithms on demand.
I hope it may help.
Thanks for your time.
If you want to look further at my library, it works with gcc and
glibc. I have not tested it on other platforms and whilst I have no
compilation warning on my personal dev laptop, I do have one when I
run it on the laptop I'm currently writing this email. The tests
passes nevertheless.
Best regards,
Laurent Lyaudet
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/MHK54GBJRKUKMTXKUK3S52LMCWDNMZCK/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: (Adaptive) Shivers sort variant of Tim sort
Hello, Le sam. 28 août 2021 à 19:38, Tim Peters a écrit : > [Laurent Lyaudet ] > > ... > > My benchmarks could be improved but however I found that Shivers' sort > > and adaptive Shivers' sort (aka Jugé's sort) performs better than > > Tim's sort. > > Cool! Could you move this to the issue report already open on this? > > Replace list sorting merge_collapse()? > https://bugs.python.org/issue34561 > > Thanks for the fast and kind answer :) I just did. Sorry for not checking the bugs reports before posting. I only checked that Shivers and Jugé did not appear in the archive of the python-dev mailing list. (If it does then the search here: https://mail.python.org/archives/list/python-dev@python.org/ is broken.) > Alas, that's been inactive for nearly 3 years, but we _were_ making > some decent progress before everyone got distracted by "more > important" stuff. > > You'll see there that Vincent Jugé contributed another version, > designed to address that his sort did substantially worse than what we > already have in some cases with very few runs. Which, for reasons > explained there, is likely important. > > Before that, the best alternative known was - and by far - Munro & > Wild's "powersort" merge strategy. That's deeply rooted in theory > about fast approximations to optimal binary search trees. > > Where that left off, Vincent was going to try proving properties of > his new variant, plus investigate other ideas. Alas, that's where it > ended, as Vincent ran out of time too. > > In any case, yes, I'm entirely in favor of replacing timsort's merge > strategy, by something with provably good properties even in worst > cases. As explained in the issue report, the merge strategy I made up > was merely the first thing I tried that didn't obviously suck ;-) - > almost all the work went into making merging itself as zippy as > reasonably possible.. > I will try to provide a patch before the end of the week. But first I will read https://www.python.org/psf/contrib/ https://devguide.python.org/ I took 5 minutes to fork and do a PR on my fork with the code for merge collapse : https://github.com/LLyaudet/cpython/pull/1 As soon as I have something more polished I'll do a PR on python repo. Any early feedback is welcome :) Best regards, Laurent ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/O3U3DWBLMG67TS55UJ3F2D5CYQZMMRJT/ Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-Dev] Python 3 as a Default in Linux Distros
On 07/24/2013 05:56 PM, Lennart Regebro wrote: On Wed, Jul 24, 2013 at 3:54 PM, Lennart Regebro wrote: On Wed, Jul 24, 2013 at 11:12 AM, Bohuslav Kabrda wrote: - Should we point /usr/bin/python to Python 3 when we make the move? No. To be more explicit. I think it's perfectly fine to not provide a /usr/bin/python at all, but I think pointing it to Python 3 will provide unhelpful error messages. Also having a /usr/bin/python that does nothing but say "You should use either /usr/bin/python2 or /usr/bin/python3" would work. But pointing it to Python 3 will make for unhelpful and confusing error messages for anyone having Python scripts using /usr/bin/python, which is the majority of people having python scripts at all. I guess that the underlying idea is to make the majority of python scripts working with Python 3. What about the following idea ? - errors that are typical of "Python 2 script running with Python 3"-specific are probably limited (e.g., use of unicode, use of xrange, etc...) - /usr/bin/python could be a wrapper that tries to run it with Python 3 and display an informative message if the errors above are occurring (e.g., "Python 3 is the current release, and this script might be designed for the older Python 2 - please explicitly use python2 if you need it" - /usr/bin/python could issue a warning in any case about the need to be explicit about python2/python3 //Lennart ___ 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/lgautier%40gmail.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] Python 3 as a Default in Linux Distros
On 07/24/2013 06:30 PM, Chris Angelico wrote: On Thu, Jul 25, 2013 at 2:21 AM, Laurent Gautier wrote: - errors that are typical of "Python 2 script running with Python 3"-specific are probably limited (e.g., use of unicode, use of xrange, etc...) The most common, in interactive scripts at least, is likely to be: print "Hello, world!" SyntaxError: invalid syntax How helpful it's possible to make that one, I don't know. Is it safe to presume that it's more likely a syntax error will come from an interpreter version mismatch than a code bug? The wrapper in /usr/bin/python: - could use what is in 2to3. I think that most of the cases are solved there. - whenever interactive, could have an intermediate layer between the input in the console and execution. ChrisA ___ 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/lgautier%40gmail.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] Python 3 as a Default in Linux Distros
On 07/25/2013 11:45 AM, Maciej Fijalkowski wrote: On Wed, Jul 24, 2013 at 7:22 PM, Laurent Gautier wrote: On 07/24/2013 06:30 PM, Chris Angelico wrote: On Thu, Jul 25, 2013 at 2:21 AM, Laurent Gautier wrote: - errors that are typical of "Python 2 script running with Python 3"-specific are probably limited (e.g., use of unicode, use of xrange, etc...) The most common, in interactive scripts at least, is likely to be: print "Hello, world!" SyntaxError: invalid syntax How helpful it's possible to make that one, I don't know. Is it safe to presume that it's more likely a syntax error will come from an interpreter version mismatch than a code bug? The wrapper in /usr/bin/python: - could use what is in 2to3. I think that most of the cases are solved there. - whenever interactive, could have an intermediate layer between the input in the console and execution. So you suggest that instead of a clear SyntaxError you should end up with a confusing error (something has no attribute xyz or so) after a while (if say somone tries to load twisted via 2to3). In a sense, yes. I think that the a priori (expectations) a user has plays a role in whether something is confusing or not. Consider the two following situations: - a programmer is working on code, and is testing it. If the program fails, this is because he/she made a mistake and the error message should indicate where the error originates from - a user is running a python script (he expects to be working), and is using the default /usr/bin/python (formerly Python 2, now Python 3). If the program fails because of obvious Python 2-only idioms, reporting this rather that the SyntaxError is much less confusing. Having that said, the comments are pointing out that this is may be not a completely good idea (most notably because of how slow 2to3 is). A wrapper producing an unconditional warning about the default python being changed to Python 3, and differences between Python 2 and Python 3 the possible source of errors, (as I think it was suggested) is going to be a better idea. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3 as a Default in Linux Distros
On 07/25/2013 01:19 PM, Lennart Regebro wrote: On Thu, Jul 25, 2013 at 12:41 PM, Laurent Gautier wrote: - a user is running a python script (he expects to be working), and is using the default /usr/bin/python (formerly Python 2, now Python 3). If the program fails because of obvious Python 2-only idioms, reporting this rather that the SyntaxError is much less confusing. 2to3 will not report this. My meaning was the use of 2to3's machinery (and fire a message if a translation occurs) not 2to3 itself, obviously. It will get rid of the SyntaxError (which at least is fairly clear) and give you a completely different and even more obscure error. You have replaced a somewhat unclear error with a very unclear error. If we want to report a problem, then /usr/bin/python should just report that you should use /usr/bin/python2 or /usr/bin/python3. That's clear. //Lennart ___ 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 3 as a Default in Linux Distros
On 07/25/2013 06:03 PM, Lennart Regebro wrote: On Thu, Jul 25, 2013 at 1:53 PM, Laurent Gautier wrote: My meaning was the use of 2to3's machinery (and fire a message if a translation occurs) not 2to3 itself, obviously. I don't understand what you mean is the difference. //Lennart bullet-point version: - 2to3 is a code translator - to function, it needs to identify Python 2-only idioms so they can be translated - the idea _was_ (*) to re-use that engine (identification-only, not translation) so the presence of Python 2-only idioms would cause a "Python 3 is now the default for "python", buddy. This script was seemingly written for Python 2, so you should run it with the command python2" sort of error message. The speed issue could be smaller than an full run of 2to3 since the error would be triggered at the first snippet of Python 2-only code encountered, but *. (*: I withdrew the suggestion few emails back) L. ___ 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] intobject.c free_list and int_dealloc()
Hello, I am trying to understand how the free list linked-list evolves when an int object is deallocated. At the beginning, free_list is pointing to the last int object (n-1) in the block. We initialize two int objects, free_list now points to the int object: n-3. free_list -> n-3 n-1 -> n-2 n-2 -> n-3 n-3 -> n-4... We delete the first int object initialized: n-1 -> n-3 free_list -> n-1 It seems to me that two elements are now pointing to the n-3 element: n-1 and n-2. I am pretty sure I am missing something here. Can someone let me know? Thanks, Laurent___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] GSoC 2010 is on -- projects?
On 3/19/10 3:36 AM, C. Titus Brown wrote: Hi all, once again, the PSF has been accepted as a mentoring foundation for the Google Summer of Code! This year, we're going to emphasize python 3 porting, so please think of projects you'd like to see tackled. Hi, Does this mean that any other python project could potentially see itself ported to Python 3 in the course of this SoC ? If so, can any project owner submit a request for help, or is there going to be a list of projects that would nice to port, or will a voting system of some sort be put in place ? Best, Laurent ___ 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] GSoC 2010 is on -- projects?
On 3/19/10 12:57 PM, Arc Riley wrote: Hi Laurent If your community project would like help porting to Python 3, and you feel this work is enough for a student to work full time for several weeks on, then please do add it to the GSoC ideas page on the wiki. Whether this is worth weeks of work or not will depend on a given student's knowledge about Python 3, and I'd suspect that the GSoC would be an opportunity for a number of applicant to actually learn the intricacies of Python 3. Developing Python 3-specific features could be used to increase the amount of work on the project, but I am uncertain of whether this is worth a full GSoC. There will be another program running for high school students which is more suitable for smaller tasks (2-3 days each), more on-par with the actual time it takes to port most Python packages. My project is roughly 6000 lines of Python and 6000 lines of C (Mostly C-level Python API bindings). I tried porting to Python 3 in the past, and it went fast (less than a day). The hurdle is that this resulted in segfaults for a lot of string-related features (You know, the byte/string thing). Tracing issues at the C level can be time-consuming, so I am hesitating to claim that 2-3 days of an high-school student would be enough. Could several ports be bundled in a GSoC (the target projects would be grouped by theme, somehow). L. On Fri, Mar 19, 2010 at 2:23 AM, Laurent Gautier mailto:lgaut...@gmail.com>> wrote: Hi, Does this mean that any other python project could potentially see itself ported to Python 3 in the course of this SoC ? If so, can any project owner submit a request for help, or is there going to be a list of projects that would nice to port, or will a voting system of some sort be put in place ? Best, Laurent ___ Python-Dev mailing list Python-Dev@python.org <mailto:Python-Dev@python.org> http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/arcriley%40gmail.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] GSoC 2010 is on -- projects?
On 3/20/10 4:13 AM, C. Titus Brown wrote: On Sat, Mar 20, 2010 at 12:00:48AM +0100, "Martin v. L?wis" wrote: Whether this is worth weeks of work or not will depend on a given student's knowledge about Python 3, and I'd suspect that the GSoC would be an opportunity for a number of applicant to actually learn the intricacies of Python 3. Developing Python 3-specific features could be used to increase the amount of work on the project, but I am uncertain of whether this is worth a full GSoC. I'd say this would definitely make a GSoC project; any non-trivial porting will be. Sounds good to me. Line up a good student and bob's your uncle. --titus I may have a student that is looking interested, and I have inserted the porting project to the Wiki table. Laurent. PS: Editing that table felt like a test in disguise ;-) ___ 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] Pydoc Improvements / Rewrite
Ron, I agree that pydoc could benefit a bit from some cleanup. As you point it out, the ability to write quick viewers would be very helpful. I came across that when wanting to develop script on a remote web server for which I only had FTP access: I ended up having to study pydoc more than I wanted in order to be able to build a display-the-doc cgi. However having two different modules might not be needed. Introspection is probably already available in the separate module 'inspect', and what a code pydoc would have to do is model the documentation (as a tree) and offer convenience function to navigate the data. Beside that, there would be sub-modules for the different viewers for the documentation data - the interactive console being just one of the viewers. Finally, I would suspect that an API-breaking modification of the module would need time to be accepted. May be the original author of pydoc is considering changes as well, and joining effort would be possible ? L. PS: I would also not go for a module name deliberately prefixed with "_" (as some people might associate that with protected or private objects). ___ 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] Pydoc Improvements / Rewrite
Ron, Thanks for your detailed answer. I inserted comments below. 2007/1/5, Ron Adam <[EMAIL PROTECTED]>: > Laurent Gautier wrote: [cut] > > > Introspection is probably already available in the separate module > > 'inspect', > > and what a code pydoc would have to do is model the documentation > > (as a tree) and offer convenience function to navigate the data. Beside > > that, > > there would be sub-modules for the different viewers for the documentation > > data - the interactive console being just one of the viewers. > > Pydoc currently uses functions from the inspect module along with directly > accessing attributes and other information where it is available. It's not a > replacement for the inspect module. > > My first attempt used an xml tree to store the information, but to make that > work requires also storing a fair amount of meta information in the tree as > well. I found parsing the tree and the meta information to be more complex > than > using an objective approach which is (to me) more readable and easier to > extend. > But if you want to try it again, please do. You may come up with something > far better than I did. Well, I was coining the idea from the understanding that the main split was console viewer vs other viewer. I was thinking of something a design along the lines of the Model-View-Presenter pattern and I guess that you will have to read your code if I want to debate on that ;-). > > Finally, I would suspect that an API-breaking modification of the module > > would > > need time to be accepted. > > I was considering this for python 3.0, but one of the developers suggested it > would be nice to have in python 2.6 and to move the discussion here. > > I think any API issues could be worked out. Are there any programs you know > of, > (yours?), that import pydoc besides the python console? What I did barely qualifies as a hack for my own usage -it won't count-. >From the top of my head, there might be "ipython" (the excellent interactive console) is possibly using pydoc (in any case, I would say that the authors would be interested in developments with pydoc) Otherwise a quick search lead to: - "cgitb" (!? - it seems that the HTML formatting functions of pydoc are only in use - wouldn't these functions belong more naturally to "cgi" ?) - "DocXMLRPCServer" (hey ! it looks like kind-of what I was needing !!!). - "happydoc" (reportedly having problems with python 2.4 - I am not sure that it is maintained) "cgitb" and "DocXMLRPCServer" are both distributed bundled with Python. "cgitb" seems to be mostly using HTML formatting helpers (and that would suggest the need for an HTML-rendering module - may be for a future improvement, a first step would be separate the rendering/viewing from extraction and modeling of documentation data). "DocXMLRPCServer" looks (at first sight), like a viewer that would be bundled with pydoc as a sub-module (i.e., module in a package). > [cut: Ka-Ping Yee <[EMAIL PROTECTED]> is now in the loop] > > Pydoc is a fairly complex program and it would definitely help if others took > a > look at various parts and made contributions and or suggestions to making it > better. Well, I stumbled upon your recent posts in python-ideas (that I tracked up the one in python-devel) because I looked into it I thought that it would be a *lot* of work for one person. (more on that in the next inlined comment) > I may have also gotten a bit over my head, but I'm willing to stick it out and > try to get it finished with any suggestions (and help) that any one is willing > to give me. There are also too many important issues for me to be decided, so > this isn't something that can be done in isolation. > > The download link again is: > > http://ronadam.com/dl/_pydoc.zip I would be willing to help out, as probably others will as well (I found blogs and posts of people discussing pydoc, it might be worthwhile dropping a line to the people - we can discuss that off-list if you wish), but may be at one condition. I do not think it will work as a zip file shuttled around (in my experience). A versioning system would be extremely helpful (SVN, or CVS. would come to my mind). Well, if you are ok with having the source tree hosted in a SVN/CVS/alike I am on (opening an account on sourceforge or savannah -for example- would be the next step then, as it can take few days for a project to be approved) > It's not fully functional yet, but does run. Some parts like the command line > file output options still need to be reimplemented. Some output formatting > still > needs to be cleaned up, and the MRO tree parsing section still n
Re: [Python-Dev] Pydoc Improvements / Rewrite
2007/1/5, Ka-Ping Yee <[EMAIL PROTECTED]>: [cut] > On the other hand, I've often seen the question of why pydoc does > both text and HTML generation instead of generating some intermediate > data structure from which both kinds of output are produced. The > answer is: I tried it. The result turned out to be longer than > I expected and needlessly more complicated than what we have now. > It may be that a better job could have been done, but I think there > is a rational basis for why it turned out that way. > > The Python objects themselves already are a data structure containing > all of the information we need. I discovered that translating this > data structure into another data structure and then producing text > or HTML was more work than simply producing text or HTML. With CSS, > the last step gets even easier and so the intermediate stage becomes > even less necessary. Also, the intermediate step required me to > essentially invent an API, and I decided that I trusted the stability > of Python's API more than that of some API I invented just for this. Point well taken. This is very sensible. I would still try to keep common-and-presenter-independent component. Rather than a sole distinction console/HTML, I would think of a distinction between stateless and interactive presenters, and still have the console and static HTML as specific presenters. The search functions Ron suggested would be part of that presenter-independent part (and for the refinement, stateless vs. interactive would make sense for performances). The distinction may look like an unnecessary complication... but I would think that it does not have to be complicated, and that the number of practical things it would allow would make it almost necessary (ah ! delusions ;-) ). There a number of python editors/consoles/IDE around, some of which are implemented in python, and having the necessary infrastructute to let implement easily documentation presenters would be very nice. > This is not to say that text and HTML generation can't be separated; > it's just a caution against attempting to overgeneralize by creating > an intermediate format. I'm glad you backed away from XML (or I'd > have warned you that processing the XML would be a lot of extra work). Your warning regarding the creation of a n-th data structure is completely agreed upon. I also understand your point about the dangers of overgeneralizing. > The inspect module was intended to pull out as much as possible of > the extraction functionality that's shared by the text and HTML > documentation generators. But pydoc is still big. At the time I was > proposing pydoc for addition to the standard library, I didn't want > to pollute the top-level module namespace with too many names, so I > tried hard to minimize the number of modules. And of course it has > grown since then with bits of new functionality and support for new > language features in Python. > > But now if a package is being considered, it makes sense to split > out some of the pieces (as you have done), such as the web server, > the search function, and the interactive interpreter help prompt. > It may even enable pydoc to provide search from the interactive help > prompt, which would be a nice feature! The package could contain > several modules for ease of maintenance, while still providing a > single, convenient command for running pydoc from the Unix prompt. Having things already split by Ron is probably a good starting base (and generalization introduced progressively, if agreed upon). I see that there is debating on the format for documentation strings, may there is as well room for flexibility regarding how the strings are utilized. The search would be not only useful to the python console, but also to other editors, as well as to editor (as well as python programs), as well as to stateless presenters (the case I had was to work on a server (web-hosting) on which I only had FTP access and on which I did not know the python version or the package installed -hey, what about an Ajax-capable HTML viewer for the documentation ?) - Laurent > > -- ?!ng > ___ 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] Pydoc Improvements / Rewrite
2007/1/5, Ka-Ping Yee <[EMAIL PROTECTED]>: > On Thu, 4 Jan 2007, Talin wrote: > > One issue that needs to be worked out, however, is the division of > > responsibility between markup processor and output formatter. Does a > > __markup__ plugin do both jobs, or does it just do parsing, and leave > > the formatting of output to the appropriate HTML / text output module? > > How does the HTML output module know how to handle non-standard metadata? > [...] > > I guess the markup processor has to deliver some kind of DOM tree, which > > can be rendered either into text or into HTML. CSS can take over from > > that point on. > > If the markup processor is going to deliver a tree, let me just point > out that it would be a pretty major project to define the format of > that tree -- about as large as inventing ReST or any other markup > language, except that the design of such an intermediate format has > to foresee future changes to the input and be flexible enough to target > multiple output formats. The design would also have to tackle the > question of whether the intermediate format should contain semantic > information (what about cross-references?) and what types of such > information should be allowed (e.g. names of modules, arguments, > exceptions, Python expressions, etc.) > Wouldn't it be conceivable to have the processing of the markup performed by a separate function, that could eventually be overridden/passed as a parameter when specific needs regarding the markup are needed ? L. > -- ?!ng > ___ > 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/lgautier%40gmail.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] Pydoc Improvements / Rewrite
2007/1/5, A.M. Kuchling <[EMAIL PROTECTED]>: > On Fri, Jan 05, 2007 at 06:01:22PM +0800, Laurent Gautier wrote: > > Well, if you are ok with having the source tree hosted in a > > SVN/CVS/alike I am on > > (opening an account on sourceforge or savannah -for example- would be > > the next step then, as it can take few days for a project to be > > approved) > > The Python SVN repository has a sandbox/ directory that's intended for > storing code in development; you could certainly use that. I suspect that this is aside from the rest of the python source tree. (or I would anticipate peppered emails if the module is broken during its early days -and it will- ). I also suspect that write access is not granted easily (as I know a number of python modules being on sourceforge before being ultimately included in the standard modules). > --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/lgautier%40gmail.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] Pydoc Improvements / Rewrite
2007/1/6, Ron Adam <[EMAIL PROTECTED]>: > Laurent Gautier wrote: [cut] > >> I think any API issues could be worked out. Are there any programs > >> you know of, > >> (yours?), that import pydoc besides the python console? > > > > What I did barely qualifies as a hack for my own usage -it won't count-. > > It could be these changes will give you a way to do the same thing in a less > haskish way. > This precisely why I get myself into the present trouble ;-) > > From the top of my head, there might be "ipython" (the excellent > > interactive console) is possibly using pydoc > > (in any case, I would say that the authors would be interested in > > developments with pydoc) > > According to the web site, ipython is based on twisted, and is currently still > limited to python 2.3 and 2.4. Also, the output of the help() function will > not > change much so I doubt it would be a problem for them. Sorry for answering a bit off-the-question. My meaning was that they would be interested in knowning that "pydoc" is changing (and would surely have ideas). > > Otherwise a quick search lead to: > > - "cgitb" (!? - it seems that the HTML formatting functions of pydoc > > are only in use - wouldn't these functions belong more naturally to > > "cgi" ?) > > Thanks!, These html formatting functions still exist or are small enough to > move > into cgitb, so it will be just a matter of making sure they can be reached. I > don't think they will be a problem. > I read your comment about having not too many things changed for 2.6. (or that will be bumped to 3000). A suggestion I would have would be to create an html/htmlrender module in the pydoc-package-to-be and start putting all the html formatting function (as they are completely independent of pydoc, as far as I can see, over there). You can then create wrappers to the original functions including a deprecation warning. You can refer to Michael Chermside's recipe for an example of implementation with a deprecation decorator - http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/391367 ) The suggestion above would actually apply to *anything* that is changed in pydoc, providing the benefit of allowing the necessary changes while having a temporary API to provide back-compatibility. > > > - "DocXMLRPCServer" (hey ! it looks like kind-of what I was needing !!!). > > Thanks again. This might be better to move into the pydoc package. Any > opinions? > We both pretty much agree, but now we've got to find the modules depending on DocXMLRPCServer (and hope the recursion won't go on for too long). We would also have to contact the author of DocXMLRPCServer (moving it would go with potential changes, and he would certainly have suggestions about that). > > - "happydoc" (reportedly having problems with python 2.4 - I am not > > sure that it is maintained) > > Happydoc does not import pydoc as far as I could tell, so this won't effect > them > in any direct way I think. They've pretty much implemented everything from > scratch. At worse they would just need to copy the parts from the older > version > into their distribution. > > I think you got a false positive on this because pydoc is a substring of > happydoc. > Yes this was a false positive. I kept it in the list thinking there might be interesting ideas there as well (but I forget to label it as such - sorry for the confusion). > > "cgitb" and "DocXMLRPCServer" are both distributed bundled with Python. > > > > "cgitb" seems to be mostly using HTML formatting helpers (and that would > > suggest the need for an HTML-rendering module - may be for a future > > improvement, a first step would be separate the rendering/viewing > > from extraction and modeling of documentation data). > > Making sure these still work would be a good sub project for someone a little > later. (I'll do it if no one else has time or wants to.) I'm trying not to > change thing to drastically. If the changes are too big, ie... introducing > and > altering a lot of other modules. Then this will need to move back to the > python-3000 list. > I agree that altering a number of other modules would be a little tricky to manage for version 2.6, but I would think that the makeover of pydoc would benefit from being made early (back-compatibility being ensured by the deprecation decorator mentioned above, for example). > > "DocXMLRPCServer" looks (at first sight), like a viewer that would be > > bundled > > with pydoc as a sub-module (i.e., module in a package). > > Yes, that w
Re: [Python-Dev] Pydoc Improvements / Rewrite
2007/1/7, Ron Adam <[EMAIL PROTECTED]>: > Laurent Gautier wrote: > > 2007/1/6, Ron Adam <[EMAIL PROTECTED]>: [...] > I'd like to know more about using the sandbox, I know it would be easy for > people to read the source there, but who all can have write access to it > without > having write access to other python areas? I would not mind giving that a try > if someone who already knows how could point me to the correct how-to > documentation with some advice on what not to do. Limiting where different people can commit code changes is possible... it's just that I am not certain whether sourceforge allows it or not. I asked A.M. Kuchling about that. > I'm actually more concerned about the what not to do stuff. I really would > not > like to clobber someone else's work or create problems because of my > inexperience with CVS. I see that you are under Microsoft windows, so you may want to check TortoiseSVN. (The python project is stored on a SVN server, so it would make sense to favor this one over CVS - in the case the project administrators have directory-level control -). Regarding the possibility of jeopardizing something in the repository, the directory-level sandbox should only allow you trash your own work ;-) (but even then, you should always be able to recover from mistakes). > > >[...] > > >> If someone who has more experience with group projects would like to > >> manage it, > >> that would be good too. That may speed things up considerably. > > > > I have some experience in it (in companies, and in an open source project) > > I can always file a application for a sourceforge project, > > and can help you with managing it until you feel like taking it on your own > > (or it is merged with the python trunk) > > I don't see this as taking a long time if we keep it to cleaning up with some > API and user interface improvements. That's all in the meaning of "some" I guess... ;-) > I know there are some here who want a smart parsing engine, which probably > would > take a long term commitment to maintain and fix bugs, etc. But lets look at > the > actual use's that pydoc serves first. > > Use's for pydoc in order of importance and frequency of use: > > 1. Console (builtin) help. ie.. the help() function. > 2. HTML browsing and quick reference. > 3. Document generation in text. > 4. Document generation in html. > 5. Document generation in other formats. (not currently possible) > > I'm concentrating on 1 and 2. Use cases 3 and 4 are just an easy to do > byproduct of doing 1 and 2. I think the cleaning up may make doing 5 > possible. I am fully on that line, with the remark that thinking about point 5 early is that could make the cut. The exercise will be in avoiding over-complication in a design that is not used in the end. Reactions on this thread brought a lot of good ideas and pointers to existing work. It loo > Lets turn the question around. How well would other document generators > supply > pydoc with the equivalent text of the help() function, interactive help > session > output, and the equivalent html needed for dynamic html browsing? > > Also keep in mind the help function is always by default imported into python, > so keeping that small and relatively simple with a minimum of external > dependencies is good. > > > > I am willing to contribute to the implementation (I suspect that > > things like unit tests be needed). > > Yes, there will need to be some unit tests. It may even help for those be > written now. That would help us identify things that still need to be done. Regarding tests, it is never early enough to think about them (that let one write code that is actually "test-able"). > > [...] ___ 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] pydoc - revised
Hi all, This is a somehow an update to the thread on pydoc started by Ron. Since the last entry we took the bull by the horns (so to speak), and are seriously aiming at delivering something that can qualify as: - a revision of the module pydoc - something that will facilitate the inclusion of ideas explored in efforts like the nice epydoc - something that is in general easily extensible to answer most of the need (both regarding the output that is returned, and what are the capabilities regarding the exploration of the documentation). We are probably setting the bar a little high, but we hope to get somewhere at least with the first point thanks to a number of advices on this list, some of which by pydoc's or ipython's original authors (beside that, the bar could not be elsewhere since I am not a very good limbo dancer ;-) ). There is a sourceforge page for that project, since it lets us work with SVN without risking to disturb a larger project, but we are ready to have that moved to the sandbox in the python tree (although it would be neat to wait a little until there are more tests). svn co https://pydoc-r.svn.sourceforge.net/svnroot/pydoc-r pydoc-r Still, the thought process is not over and we were thinking of having discussions recorded either in the form of posts on python-dev, or say using the mailing list on the sourceforge page. An example of discussions we had are about whether we should already name the module pydoc or an other name, Posting on python-dev would give exposure to what is discussed, but at the same could be perceived as off-topic until the module is in the sandbox. Posting on the sourceforge page would have pretty much opposite points (no exposure, but no one would feel annoyed) Any suggestion ? Thanks, Laurent ___ 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] pydoc II
Hi, There was a thread some weeks ago about work on pydoc, with the admitted aim of proposing something as an upgrade to the current pydoc. We had a number of suggestions, on this very list or privately, and we looked into having something that would not only retain the capabilities of the current pydoc but facilitate customization when it comes to formatting the help, or process the docstrings. Looking at things, and implementing along to see how it would look like, we are coming to something that looks very much like a new implementation... and before going further I would like to ensure that that does not mean an automatic "no way". The obvious question is "why change something that is working ?", and the answer is as simple as although pydoc is a very helpful, there are a number of functionalities that appeared wished so much that other modules appeared. What is proposed here is along the line of "the same but more extensible". The pydoc envisioned is both a library for extracting documentation, as well as few standalone applications using that library (a documentation browser, an interactive console help... just like pydoc currently has). A prototype is being worked on, and I have been looking at code and/or functionalities in pydoc, epydoc, pydoctor, and ipython (for the interactive console), and there a lot of nice things in all these efforts. The name of the game is now to have something that likely to offer the best of all (although it can be an easy way to get no one happy in the end). Hopefully someone kept reading up to here... Some of the key points so far: library: - ability to browse documentation inside module/package files without loading them - ability to browse documentation attached to "live" (that is loaded) objects - documentation API that is independent of whether the object is loaded or not - low-energy barrier for adding support for "other-than-plain-text" docstrings - features like searching objects by name, or by content in their doctring applications: - HTML server to consult the documentation for installed packages - interactive console to consults the documentation for installed and/or loaded objects - generation of HTML documentation How does this sound so far ? Laurent ___ 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] pydoc II
2007/3/11, Gustavo Carneiro <[EMAIL PROTECTED]>: > On 3/11/07, Laurent Gautier <[EMAIL PROTECTED]> wrote: > [...] > > A prototype is being worked on, and I have been looking at code and/or > > functionalities in pydoc, epydoc, pydoctor, and ipython (for the > > interactive console), and there a lot of nice things in all these > > efforts. The name of the game is now to have something that likely to > > offer the best of all (although it can be an easy way to get no one > > happy in the end). > > > > Hopefully someone kept reading up to here... > > > > Some of the key points so far: > > > > library: > > - ability to browse documentation inside module/package files without > > loading them > > Most importantly, we also need the reserve: ability to attach external > documentation to modules/packages without increasing their size. I suspect that this will sparkle a long thread about python documentation system, but I will comment nevertheless while trying to avoid being caught in the middle. Well this sort of thing is technically feasible, and when I am looking solely at pydoc the deal for me is how can it be made easily and as little hackish as possible. > For instance, one of the reasons no one ever bothered to add pydoc > documentation to PyGTK (beyond a few docstrings that can be generated in > runtime) is that the entire documentation for PyGTK would be far too large > to place directly into the module readonly data segment. > > Documentation should be able to live in another file, separate from the > module source code, and loaded on demand. Loading the pydoc file should be > preferably done through read-only memory mapping a file. Well, that's an interesting idea... and the structure we start having could see something along those lines implemented. Being something non-standard for the time being, that would be something that the maintainer of the module having that particular request would take care of. (the deal with pydoc would be to make plugging that in easy) Instructions to use that "other-documentation" through pydoc could be included in the top-level docstring for the pygtk module for example... how does this sound ? L. > -- > Gustavo J. A. M. Carneiro > "The universe is always one step beyond logic." ___ 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] The docs, reloaded
I would agree with the point that python core should be considered first, but I would also only see beneficial to leave the door open to the need of other packages. I have (briefly but intensely) worked on a revamp of pydoc earlier on this year, and while collecting requirements from a number of places having maths expressions or else appeared important for a number of cases (and a very reasonable request in a case) . That particular point leads to something that I see important for what a new/better documentation system should provide: a good and modular interface to access the documentation, process it, and navigate it. When looking at the particular example discussed here, it could be implemented by allowing a "pluggable" processing components for docstrings (and let a given package developer the possibility to use as much as the default documentation machinery as possible and implement the processing mathml, latex, whatever, as wanted). One can consider the possibility to have the "custom" processing of the docstring embedded in the package itself. Laurent 2007/5/21, Brett Cannon <[EMAIL PROTECTED]>: > > > On 5/20/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > > Georg> So, that's not really a concern of mine ;) > > > > > > You must realize that people will use the core tools to create > documentation > > > for third party packages which aren't in the core. If you replace LaTeX > > > with something else I think you need to keep math in mind whether it's > used > > > in the core documentation or not. > > > > I disagree. The documentation infrastructure of Python should only > > consider the needs of Python itself. If other people can use that > > infrastructure for other purposes, fine - if they find that it does > > not meet their needs, they have to look elsewhere. > > > Martin beat me to my comment. =) Python's needs should come first, period. > If Georg wants to add math support, fine. But honestly I would rather he > spend his time on Python-specific stuff then get bogged down to support > possible third parties. > > -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/lgautier%40gmail.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] The docs, reloaded
2007/5/23, Nick Craig-Wood <[EMAIL PROTECTED]>: > Georg Brandl <[EMAIL PROTECTED]> wrote: > > Nick Craig-Wood schrieb: > > > Being a seasoned unix user, I tend to reach for pydoc as my first stab > > > at finding some documentation rather than (after excavating the mouse > > > from under a pile of paper) use a web browser. > > > > > > If you've ever used pydoc you'll know it reads docstrings and for some > > > modules they are great and for others they are sorely lacking. > > > > > > If pydoc could show all this documentation as well I'd be very happy! > > > > > > Maybe your quick dispatch feature could be added to pydoc too? > > > > It is my intention to work together with Ron Adam to make the pydoc <-> > > documentation integration as seamless as possible. > > So I'll be able to read the main docs for a module in a terminal > without reaching for the web browser (or info)? That would be great! One option is to use a text-mode browser (lynx, links, or the likes). The other is to develop a terminal mode application (currently in pydoc, I believe) > How would pydoc decide which bit of docs it is going to show? > > If I type "pydoc re" is it going to give me the rather sparse __doc__ > from the re module or the nice reST docs? Or maybe both, one after > the other? Or will I have to use a flag to dis-ambiguate? I really think that making pydoc a solid library to extract/search/navigate the documentation offers a lot of interesting perspectives. When one think beyond the application discussed here, there are a lot of tools (ipython, or any IDE for example) that could make great use of the facility. [note: Ron and I seemed to disagree on what (and how) pydoc should be, and that in particular, but I keep a keen interest in having such a library.] > If you type "pydoc re" at the moment then it says in it > > MODULE DOCS > http://www.python.org/doc/current/lib/module-re.html > > which is pretty much useless to me when ssh-ed in to a linux box half > way around the world... > > > > It is missing conversion of ``comment'' at the moment as I'm sure you > > > know... > > > > Sorry, what did you mean? > > ``comment'' produces smart quotes in latex if I remember correctly. > You probably want to convert it somehow because it looks a bit odd on > the web page as it stands. I'm not sure what the reST replacement > might be, but converting it just to "comment" would probably be OK. > Likewise with `comment' to 'comment'. > > For an example see the first paragraph here: > > http://pydoc.gbrandl.de/reference/index.html > > -- > Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick > ___ > 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/lgautier%40gmail.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] [poll] New name for __builtins__
I find __root_namespace__ rather explicit without being unbearably long. If length is an issue, and __root__ not found explicit, I am suggesting __session__. L. 2007/11/28, Stephen Hansen <[EMAIL PROTECTED]>: > (The lurker awakes...) > > > > > > > If not that I suggest something like __inject_builtins__. This > > > implies it's a command to eval/exec, and doesn't necessarily reflect > > > your current builtins (which are canonically accessible as an > > > attribute of your frame.) > > > > You're misunderstanding the reason why __builtins__ exists at all. It > > is used *everywhere* as the root namespace, not just as a special case > > to inject different builtins. > > > > ATM I'm torn between __root__ and __python__. > > > Something with the word "global" speaks to it's real effect, except that the > word already has an established meaning in Python as being 'global to the > module level', and modifying __builtins__ lets you be "global to the entire > universe of that instance" > > So I would humbly suggest __universal__. The names within are available > everywhere. 'root' speaks to me too much of trees, and while namespaces may > be tree-like, __root__ alone doesn't say "root namespace"... and > __root_namespace__ is long. > > (Then again, long for a feature that should only be used with care isn't a > bad thing) > > --Stephen > ___ > 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/lgautier%40gmail.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
