Re: [Python-Dev] A suggestion: Do proto-PEPs in Google Docs
On 20-02-2009, Guido van Rossum wrote: > On Fri, Feb 20, 2009 at 3:21 AM, Antoine Pitrou wrote: >> Georg Brandl gmx.net> writes: >>> >>> The Python Wiki should also be considered: >>> >>> * Comparing versions is easy, and versions are only saved on "Save" >>> >>> * It supports reStructuredText, so there is no need for conversion >>> afterwards. >> >> And it's vendor-neutral :-) > > Touche. > > I still don't like wikis for this purpose very much -- a person > editing effectively grabs a lock on the whole file. (Wikimedia > addresses this to some extend by allowing sections to be edited, but I > don't see this feature in moinmoin yet, and I don't see us switching.) > Also there is no access control -- anyone who can create a login can > edit. Isn't it the good oportunity to try a DVCS ? -- William Dodé - http://flibuste.net Informaticien Indépendant ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A suggestion: Do proto-PEPs in Google Docs
On 21-02-2009, Stephen J. Turnbull wrote: > Summary: > > Google Docs is easy to use, featureful, and here now. Since AIUI the > PEPs eventually need to be hosted at python.org, I see Google Docs as > an immediate replacement for email transmission of early drafts of > PEPs, not as a permanent solution to PEP storage. > > William Dode writes: > > > Isn't it the good oportunity to try a DVCS ? My point was more to try a DVCS to give food to the 374e pep than to resolv the issues you mention. -- William Dodé - http://flibuste.net Informaticien Indépendant ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A suggestion: Do proto-PEPs in Google Docs
On 21-02-2009, Guido van Rossum wrote: > On Sat, Feb 21, 2009 at 6:25 AM, wrote: >> On Sat, 21 Feb 2009 at 01:12, Jeff Hall wrote: Not that I'm expecting to be working on PEPs any time soon, but just as a different perspective, I would find the effort to open up Google docs to be a much higher barrier to doing some editing tweaks than the dvcs case. For the DVCS, I'd just write a little script that would (1) update (2) open the editor on the file (3) do the commit/push dance when the file was closed. So for me it would be as easy as editing the file locally. So for my work style, a DVCS would be the biggest win. --RDM >>> >>> That's funny because I would expect that for most people it's the exact >>> opposite... just create a gmail account... boom, done... I'm not >>> necessarily >>> advocating that but just saying that IMO, most people will find google >>> docs >>> to be the "fastest" and "easiest" solution. >> >> The ease of creating a gmail account has nothing to do with the point >> to which I was responding (context which is lost from your reply). >> That's setup. I was responding to a point talking about in-the-moment >> workflow. A browser and a GUI javascript program are slower than a unix >> command line based editor such as vim or emacs both to open up and to use. >> Thus for me, by using a script to automate the part that the OP suggested >> would slow the dvcs user down (the update/commit/push cycle), I make >> the dvcs in-the-moment workflow much faster _for me_ than Google Docs. >> >> As I said it's a matter of personal style. Some people _will_ find >> Google Docs easier and more productive than a dvcs. My point was that >> not all people will. > > That's a discussion that can never come to a decent conclusion. We > will never find a solution that works for *everyone* Maybe not for everyone but maybe a DVCS could work for everythings. I mean, work for the code, for the doc, for the peps, for the website... And also the same tools for core devs and for occasional contributors. -- William Dodé - http://flibuste.net Informaticien Indépendant ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython
Hi (as a simple user), I'd like to know why you didn't followed the same way as V8 Javascript, or the opposite, why for V8 they didn't choose llvm ? I imagine that startup time and memory was also critical for V8. thanks -- William Dodé - http://flibuste.net Informaticien Indépendant ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython
On 27-01-2010, Collin Winter wrote: > Hi William, > > On Wed, Jan 27, 2010 at 7:26 AM, William Dode wrote: >> Hi (as a simple user), >> >> I'd like to know why you didn't followed the same way as V8 Javascript, >> or the opposite, why for V8 they didn't choose llvm ? >> >> I imagine that startup time and memory was also critical for V8. > > Startup time and memory usage are arguably *more* critical for a > Javascript implementation, since if you only spend a few milliseconds > executing Javascript code, but your engine takes 10-20ms to startup, > then you've lost. Also, a minimized memory profile is important if you > plan to embed your JS engine on a mobile platform, for example, or you > need to run in a heavily-multiprocessed browser on low-memory consumer > desktops and netbooks. > > Among other reasons we chose LLVM, we didn't want to write code > generators for each platform we were targeting. LLVM has done this for > us. V8, on the other hand, has to implement a new code generator for > each new platform they want to target. This is non-trivial work: it > takes a long time, has a lot of finicky details, and it greatly > increases the maintenance burden on the team. We felt that requiring > python-dev to understand code generation on multiple platforms was a > distraction from what python-dev is trying to do -- develop Python. V8 > still doesn't have x86-64 code generation working on Windows > (http://code.google.com/p/v8/issues/detail?id=330), so I wouldn't > underestimate the time required for that kind of project. Thanks for this answer. The startup time and memory comsumption are a limitation of llvm that their developers plan to resolve or is it only specific to the current python integration ? I mean the work to correct this is more on U-S or on llvm ? thanks (and sorry for my english !) -- William Dodé - http://flibuste.net Informaticien Indépendant ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Psyco for -OO or -O
On 13-12-2008, Michael Foord wrote: > Lie Ryan wrote: >> I'm sure probably most of you knows about psyco[1], the optimizer. Python >> has an -O and -OO flag that is intended to be optimization flag, but we >> know that currently it doesn't do much. Why not add psyco as standard >> library and let -O or -OO invoke psyco? >> > > This really belongs on Python-ideas and not Python-dev. > > The main reason why not is that someone(s) from the Python core team > would then need to 'own' maintaining Psyco (which is x86 only as well). > Psyco is so hard to maintain that even the original author wants to drop > it. :-) It could be the killer feature wich will push python3 adoption ;-) Bloggers like so much benchings ! Sorry... -- William Dodé - http://flibuste.net Informaticien Indépendant ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
