Re: [Python-Dev] Invitation to try out open source code review tool
-On [20080505 18:28], Guido van Rossum ([EMAIL PROTECTED]) wrote: >- AppEngine has a built-in API for dealing with Google Accounts, but >not for OpenID > >- Apparently OpenID requires some crypto that would be slow without >additional API support > >- I'm not personally familiar with OpenID Check out http://openid-provider.appspot.com/ Apparently it was created by your colleague Ryan Barrett. :) -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B If Winter comes, can Spring be far behind..? ___ 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] Invitation to try out open source code review tool
-On [20080505 05:38], Guido van Rossum ([EMAIL PROTECTED]) wrote: > http://code.google.com/p/rietveld/source/browse Is it a reference to Gerrit Rietveld (Dutch architect and furniture designer)? I guess the architect part would make sense for a code review tool. :) -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B If Winter comes, can Spring be far behind..? ___ 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 about mktemp once again?
pobox.com> writes: > > Back in r29829, Guido commented out the security hole warning for > tempfile.mktemp: > [...] > > Comment out the warnings about mktemp(). These are too annoying, and > often unavoidable. > > Any thought about whether this warning should be restored? We're 5+ years > later. Hopefully many uses of mktemp have been removed. If we're not going > to restore the warning perhaps the commented code should just be deleted. Sorry to revive this thread, but mktemp() is very useful when the file is meant to be created by another application (e.g. launched by subprocess, but it could even be a daemon running under a different user). For example if I have a processing chain to converts a PDF to a temporary JPEG using an external tool and then does other things with the JPEG: I don't want Python to actually create the file, just to generate an unique filename. Of course one can use NamedTemporaryFile, retrieve the name, close the file handle and then pass the name to the other application. But it's an useless complication compared to the simplicity of writing "my_filename = tempfile.mktemp()" ___ 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-3000] Reminder: last alphas next Wednesday 07-May-2008
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 1, 2008, at 8:03 PM, [EMAIL PROTECTED] wrote: Am I the only guy who finds software that insists on visible, fixed files in my home directory rude? vmware, for example, wants a "~/ vmware" directory, but pretty much every other application I use is nice enough to use dotfiles (even cedega, with a roughly-comparable- to- lib "applications I've installed for you" folder). No Glyph, you are not alone! I don't even like the OS putting stuff like Pictures, Music, Movies, Videos and Desktop in my home directory, but I guess that's the price we pay for a modrin desktopy operatin' systum. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBSCBAXHEjvBPtnXfVAQJdrgP+Mw0qZebL+MqUk3wKMsRt5mHzT/uHhQ0Z NVwyooWKWnvLMMifCbaG3pjVs7MehfcbAK8uLTlF8Ss9/w1Q5SWJkdhLMWOvHdA6 CJMvGyuokElD5e2cKXiakUWUshN/CeGNElTpxHUBdwmkirfXLQzQll9jlYbnr0I8 du2+rTj/oAc= =015L -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] Warn about mktemp once again?
* Antoine Pitrou <[EMAIL PROTECTED]> [2008-05-06 10:47:23 +]: > pobox.com> writes: > > > > Back in r29829, Guido commented out the security hole warning for > > tempfile.mktemp: > > > [...] > > > > Comment out the warnings about mktemp(). These are too annoying, and > > often unavoidable. > > > > Any thought about whether this warning should be restored? We're 5+ years > > later. Hopefully many uses of mktemp have been removed. If we're not going > > to restore the warning perhaps the commented code should just be deleted. > > Sorry to revive this thread, but mktemp() is very useful when the file is > meant > to be created by another application (e.g. launched by subprocess, but it > could > even be a daemon running under a different user). For example if I have a > processing chain to converts a PDF to a temporary JPEG using an external tool > and then does other things with the JPEG: I don't want Python to actually > create the file, just to generate an unique filename. The correct way to do this is to create a temporary directory, and then generate a filename underneath that directory to use. -- mithrandi, i Ainil en-Balandor, a faer Ambar signature.asc Description: Digital 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] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
2008/5/6 Barry Warsaw <[EMAIL PROTECTED]>: > On May 1, 2008, at 8:03 PM, [EMAIL PROTECTED] wrote: > > Am I the only guy who finds software that insists on visible, fixed files > in my home directory rude? vmware, for example, wants a "~/vmware" > directory, but pretty much every other application I use is nice enough to > use dotfiles (even cedega, with a roughly-comparable-to- lib "applications > I've installed for you" folder). > > No Glyph, you are not alone! I don't even like the OS putting stuff like > Pictures, Music, Movies, Videos and Desktop in my home directory, but I > guess that's the price we pay for a modrin desktopy operatin' systum. I too find this irritating. FWIW my vote is for ~/.python. ~/.local comes in a distant second due to non-obviousness and ~/Python is several light years beyond that. -- Evolution: Taking care of those too stupid to take care of themselves. ___ 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-3000] Reminder: last alphas next Wednesday 07-May-2008
Alec Thomas wrote: FWIW my vote is for ~/.python. ~/.local comes in a distant second due to non-obviousness and ~/Python is several light years beyond that. I think if the obviousness (or lack thereof) of the chosen directory name ever really matters to anyone, we did it wrong. After all, unless you're trying to use something other than distutils to get a package ready for installation, how often does it really matter that the site-packages directory for an installed python interpreter actually lives somewhere inside /usr/local? The main advantage I see to using the "~/.local" approach is that a lot of questions about file layout (e.g. where to put architecture specific code) are automatically (and fairly obviously) answered "Do whatever is done for the system-wide equivalent in /usr/local". Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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-3000] Reminder: last alphas next Wednesday 07-May-2008
Alec> FWIW my vote is for ~/.python. ~/.local comes in a distant second Alec> due to non-obviousness and ~/Python is several light years beyond Alec> that. I guess we're going to have to agree to disagree. I find hiding directories which contain executable code extremely non-obvious. Would you prefer /usr/.local to /usr/local? If not, then why prefer ~/.local to ~/local? 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] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
2008/5/7 <[EMAIL PROTECTED]>: > > Alec> FWIW my vote is for ~/.python. ~/.local comes in a distant second > Alec> due to non-obviousness and ~/Python is several light years beyond > Alec> that. > > I guess we're going to have to agree to disagree. I find hiding directories > which contain executable code extremely non-obvious. Would you prefer Python would not be unique. Mozilla/Firefox does exactly this, putting per-user plugins in ~/.mozilla. > /usr/.local to /usr/local? If not, then why prefer ~/.local to ~/local? Because unlike a home directory, users don't frequently perform directory listings or tab completion of /usr/. For a frequently used personal directory one wants the minimum of noise. Also: 1. If every application followed the convention of creating non-hidden paths in home directories the directory listing would be *incredibly* noisy. To illustrate, I have 160 dotfiles, most of which were created by applications. I have only 8 non-hidden directories, all of which I have created myself. 2. Non-hidden directories interfere with tab completion muscle memory. 3. On a more subjective note, home directories are personal space. People shape them to their personality, and interfering with this is impolite. 4. Per-application dotfiles have 30 years of convention behind them. Conversely, only a few applications use ~/.local (for example, Openbox and Audacious both look for configuration here) and none that I'm aware of default to ~/local. 5. Applications that create non-hidden directories in user home directories are generally perceived as being obnoxious. -- Evolution: Taking care of those too stupid to take care of themselves. ___ 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-3000] Reminder: last alphas next Wednesday 07-May-2008
> > /usr/.local to /usr/local? If not, then why prefer ~/.local to ~/local? > > Because unlike a home directory, users don't frequently perform > directory listings or tab completion of /usr/. For a frequently used > personal directory one wants the minimum of noise. Glad someone around here knows actual facts about the statistics of using "ls" :-). Can you point to published user studies about this? If not, let me just say that I perform directory listings of /usr a whole lot *more* than my home directory. Um, isn't this all argument about what color to paint the shed? Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
On Fri, 02 May 2008 00:03:24 - [EMAIL PROTECTED] wrote: > On 11:45 pm, [EMAIL PROTECTED] wrote: > >I like this, except one issue: I really don't like the .local > >directory. I don't see any compelling reason why this needs to be > >~/.local/lib/ -- IMO it should just be ~/lib/. There's no need to hide > >it from view, especially since the user is expected to manage this > >explicitly. > > I've previously given a spirited defense of ~/.local on this list ( > http://mail.python.org/pipermail/python-dev/2008-January/076173.html ) > among other places. > > Briefly, "lib" is not the only directory participating in this > convention; you've also got the full complement of other stuff that > might go into an installation like /usr/local. So, while "lib" might > annoy me a little, "bin etc games include lib lib32 man sbin share src" > is going to get ugly pretty fast, especially if this is what comes up in > Finder or Nautilus or Explorer every time I open a window. You have a problem with 10 directories? Well, ok - if you have that on top of all the clutter that you normally get, yeah, I might object too. On the other hand, if *every* application used those 10 directories - and *only* those 10 directories - for all the files it needed that weren't for user-created data, that would be heaven. The fallacy you're falling into is that users never have to deal with those dot-files (or directories). They do. One of the most common operations when trying to diagnose a misbehaving application is "delete the configuration files" (my favorite is that I fix gnucash printing failures by deleting CUPS config files), and the user has to figure out which, if any, of those magic files need to be deleted. If you're using Finder, you wind up turning on the preference that says "show me those", and suddenly your nice, clean directory explodes into ... Well, here's my home directory, shared between a Mac and a Unix box: mbook-fbsd% cd mbook-fbsd% ls | wc -l 42 mbook-fbsd% ls -d .* | wc -l 174 It's not very clean. Because it's a Mac, it's got some directories that the Mac felt I needed that I really have no use for. And there's maybe a dozen files there that are scratch files from various things I haven't cleaned up yet. Of course, the dot-files are much worse, because I normally don't see them, so there's not incentive to clean them up at all. But if i could trade those 172 (can't lose . and ..) "hidden" .files for 10 visible directories in ~, I'd do it in an instant - even if I didn't already have bin, etc, src & lib directories there. > Put another way - it's trivial to make ~/.local/lib show up by > symlinking ~/lib, but you can't make ~/lib disappear, and lots of > software ends up looking at ~. Just for the record, it's equally trivial - but better - to make ".local" disappear by symlinking '.local' to '.'. But providing an option is even cleaner, and then the fact that you can't use symlink to hide one is moot. As far as I'm concerned, .local is the worst possible choice for this choice for this name. Not only does it wind up in the more cluttered of the two name spaces, it doesn't tell me anything about the application(s) it belongs to, so I have to worry about it pretty much every time I'm mucking about with the config files. .python would be much better - at least I'd know what it was for by the name. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ 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] Optimization of Python ASTs: How should we deal with constant values?
On Fri, May 2, 2008 at 1:38 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Thomas Lee wrote: > > Martin v. Löwis wrote: > >>> This leaves us with a few options: > >>> > >> > >> 5. Reuse/Abuse Num(object) for arbitrary constants. > >>AFAICT, this should work out of the box. > >> > >> > > Eek. It *does* seem like Num would work out of the box, but would this > > be a good idea? > > No. I suggested it just for completeness. > > > > What about *replacing* Num with Const? Might make optimizations > > specifically for numeric values slightly hairier, and semantically I > > think they might be different enough to warrant separate AST nodes > > despite the similarity in implementation at the compiler level. > > I think they should be separate. Const would be a mere addition; > for compatibility with other uses of the AST, that's actually better > than simultaneous removal of Num. Adding Const sounds good to me. Jeremy > > 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/jeremy%40alum.mit.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] AST Optimization: Branch Elimination in Generator Functions
I'm not sure I understand the problem exactly. If we have one pass converting the concrete syntax to the AST, we can mark functions as generators as part of that pass. In a later pass, you can remove the unreachable code. Jeremy On Sat, May 3, 2008 at 12:51 AM, Thomas Lee <[EMAIL PROTECTED]> wrote: > The next problem that cropped up during the implementation of the AST code > optimizer is related to branch elimination and the elimination of any code > after a return. > > Within a FunctionDef node, we would (ideally) like to blow away If nodes > with a constant - but false - test expression. e.g.: > > def foo(): > if False: > # ... stuff ... > > For most functions, this will cause no problems and the code will behave as > expected. However, if the eliminated branch contains a "yield" expression, > the function is actually a generator function - even if the yield expression > can never be reached: > > def foo(): > if False: > yield 5 > > In addition to this, the following should also be treated as a generator > even though we'd like to be able to get rid of all the code following the > "return" statement: > > def foo(): > return > yield 5 > > Again, blowing away the yield results in a normal function instead of a > generator. Not what we want: we need to preserve the generator semantics. > > Upon revisiting this, it's actually made me reconsider the use of a Const > node for the earlier problem relating to arbitrary constants. We may be > better off with annotations after all ... then we could mark FunctionDef > nodes as being generators at the AST level to force the compiler to produce > code for a generator, but eliminate the branches anyway. > > The other alternative I can think of is injecting a yield node somewhere > unreachable and ensuring it doesn't get optimized away, but this seems > pretty hacky in comparison. > > Any other ideas? > > Cheers, > Tom > ___ > 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/jeremy%40alum.mit.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] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
On Tue, May 6, 2008 at 8:11 AM, Alec Thomas <[EMAIL PROTECTED]> wrote: > Python would not be unique. Mozilla/Firefox does exactly this, putting > per-user plugins in ~/.mozilla. Note that this is moot since I'm going to accept the PEP as it stands (i.e. ~/.local) but I want to point out something that seems to be lost occasionally. Hiding stuff in dot files is the right thing to do when there's a separate API (like Mozilla) to manage those files. It is IMO much more questionable when the user is expected to manage things directly using the standard filesystem API. That's why Pictures etc. are not dot files. Of course, there's a gray area -- grizzled Unix wizards manage dozens of dot files like .profile and .exrc -- but I still think this is a useful (partial) guiding principle. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
On Tue, May 6, 2008 at 7:37 AM, Steve Holden <[EMAIL PROTECTED]> wrote: > If you want it visible, make a visible symbolic link! Note that the point is moot, since I'm going to accept Christian's PEP, i.e. ~/.local, but this argument "you can make it visible yourself" is bogus. The point of visibility (when it's brought up) isn't that you *can* make it visible -- you can always do that with ls -a or whatever Finder option. The point is that (in some people's view) the results of an action should be left *in plain sight* so that the user has clear evidence of what happened. I'm fine in this case with the counterarguments though, so I'll be accepting the PEP in a minute. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
>> /usr/.local to /usr/local? If not, then why prefer ~/.local to ~/local? Alec> Because unlike a home directory, users don't frequently perform Alec> directory listings or tab completion of /usr/. For a frequently Alec> used personal directory one wants the minimum of noise. I don't mind the system clearly telling me about code I've installed. That's a lot different than Mozilla hiding it's internal stuff in ~/.mozilla. 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
[Python-Dev] ctypes documentation
I just made another attempt to use ctypes to wrap a library, and am facing the same problem I had the last time: the documentation doesn't really work. I'm wondering if we have any projects underway to re-write it? Bill ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] PEP 370 (was Re: Reminder: last alphas next Wednesday 07-May-2008)
All, I've accepted PEP 370, Christian Heimes's proposal to add a per-user site-package directory. The location will be somewhere under ~/.local for Unix/Linux/OS X, and %APPDATA%/Python for Windows (per the original proposal in the PEP). Congratulations Christian, and thanks for championing this. Thanks also to everyone who contributed to the discussion and showed the error of my ways -- especially those who did so in under 100 words. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Warn about mktemp once again?
On Tue, May 6, 2008 at 4:19 AM, Tristan Seligmann <[EMAIL PROTECTED]> wrote: > * Antoine Pitrou <[EMAIL PROTECTED]> [2008-05-06 10:47:23 +]: > > Sorry to revive this thread, but mktemp() is very useful when the file is > meant > > to be created by another application (e.g. launched by subprocess, but it > could > > even be a daemon running under a different user). For example if I have a > > processing chain to converts a PDF to a temporary JPEG using an external > tool > > and then does other things with the JPEG: I don't want Python to actually > > create the file, just to generate an unique filename. > > The correct way to do this is to create a temporary directory, and then > generate a filename underneath that directory to use. Good catch. The problem with mktemp() is exactly its convenience, which opens it up for well-documented symlink attacks. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Invitation to try out open source code review tool
On Tue, May 6, 2008 at 12:48 AM, Jeroen Ruigrok van der Werven wrote: > -On [20080505 18:28], Guido van Rossum ([EMAIL PROTECTED]) wrote: > >- AppEngine has a built-in API for dealing with Google Accounts, but > >not for OpenID > > > >- Apparently OpenID requires some crypto that would be slow without > >additional API support > > > >- I'm not personally familiar with OpenID > > Check out http://openid-provider.appspot.com/ > > Apparently it was created by your colleague Ryan Barrett. :) It solves the opposite problem -- using a Google Account to log in to an app that requires OpenID. People are clamoring for the opposite here. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Invitation to try out open source code review tool
On Tue, May 6, 2008 at 12:51 AM, Jeroen Ruigrok van der Werven <[EMAIL PROTECTED]> wrote: > -On [20080505 05:38], Guido van Rossum ([EMAIL PROTECTED]) wrote: > > http://code.google.com/p/rietveld/source/browse > > Is it a reference to Gerrit Rietveld (Dutch architect and furniture > designer)? Yes, as I explain here: http://code.google.com/p/rietveld/wiki/CodeReviewBackground > I guess the architect part would make sense for a code review > tool. :) That's purely a coincidence. My dad was an architect and took me on trips of Rietveld's work. I also own some fairly original Zig Zag chairs (much to my family's despair, as they aren't too comfortable. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Invitation to try out open source code review tool
On Tue, May 6, 2008 at 1:26 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On Tue, May 6, 2008 at 12:51 AM, Jeroen Ruigrok van der Werven > <[EMAIL PROTECTED]> wrote: > > -On [20080505 05:38], Guido van Rossum ([EMAIL PROTECTED]) wrote: > > > http://code.google.com/p/rietveld/source/browse > > > > Is it a reference to Gerrit Rietveld (Dutch architect and furniture > > designer)? > > Yes, as I explain here: > http://code.google.com/p/rietveld/wiki/CodeReviewBackground > > > > I guess the architect part would make sense for a code review > > tool. :) > > That's purely a coincidence. My dad was an architect and took me on > trips of Rietveld's work. I also own some fairly original Zig Zag > chairs (much to my family's despair, as they aren't too comfortable. > :-) Was it also a coincidence that Mondrian and Rietveld were both members of the De Stijl movement? If so, a very nice one! ___ 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] Invitation to try out open source code review tool
On Tue, May 6, 2008 at 10:41 AM, Alexander Michael <[EMAIL PROTECTED]> wrote: > Was it also a coincidence that Mondrian and Rietveld were both members > of the De Stijl movement? If so, a very nice one! No, that's my naming scheme. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Invitation to try out open source code review tool
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | On Tue, May 6, 2008 at 10:41 AM, Alexander Michael <[EMAIL PROTECTED]> wrote: | > Was it also a coincidence that Mondrian and Rietveld were both members | > of the De Stijl movement? If so, a very nice one! | | No, that's my naming scheme. :-) Neat. I think I see a few echoes of De Stijl esthetic in Python. "Proponents of De Stijl sought to express a new utopian ideal of spiritual harmony and order. They advocated pure abstraction and universality by a reduction to the essentials of form and colour" from http://en.wikipedia.org/wiki/De_stijl The group was one of the best things to come out of the Great Stupid War. I wonder who is next. Van Doesburg, the group's BDFL? (I know... wait ;-) tjr ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ctypes documentation
On Tue, May 6, 2008 at 11:43 AM, Bill Janssen <[EMAIL PROTECTED]> wrote: > I just made another attempt to use ctypes to wrap a library, and am > facing the same problem I had the last time: the documentation doesn't > really work. I'm wondering if we have any projects underway to > re-write it? So what exactly is eating you about it? -- Cheers, Benjamin Peterson ___ 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] Another GSoC Student Introduction
Hi Everybody. My name is Robert Schuppenies and I also got accepted for this years Google Summer of Code. I will be working on the Python Core with the Memory Usage Profiler project and my mentor will be Martin von Löwis. I am very happy that I got selected and look forward to work on my project. Many thanks to Martin and everybody else making this possible. cheers, robert ___ 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] Invitation to try out open source code review tool
Jeroen Ruigrok van der Werven wrote: Is it a reference to Gerrit Rietveld (Dutch architect and furniture designer)? I guess the architect part would make sense for a code review tool. :) According to Wikipedia, he was also a friend of Mondrian and incorporated some of Mondrian's ideas into his designs. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Warn about mktemp once again?
Tristan Seligmann wrote: The correct way to do this is to create a temporary directory, and then generate a filename underneath that directory to use. Yes, otherwise you can get bitten by the race condition that's the reason for mktemp being deprecated. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 370 heads up
Dear fellow Pythonistas! Guido has accepted my user site directory PEP today. http://python.org/dev/peps/pep-0370/ I'm about the merge the code. But first I like to let you know some things and get your opinion. The location of the user site-package directory stays as written in my PEP. The master himself said "The location will be somewhere under ~/.local for Unix/Linux/OS X, and %APPDATA%/Python for Windows (per the original proposal in the PEP)." Please do NOT take my check-in message as an opportunity to start yet the third bike shed discussion. Thank you very much! :) The PEP adds two environment vars to adjust the location of the user site directory to your liking or to disable the feature entirely. If you are still not convinced you are better off by adding a single line to your .profile file. For now the unit tests are creating the user site directory tree. I'm going to chance that in a few days unless everybody is fine with it. The docs aren't finished yet. Unless somebody is faster than me (*wink*) I'm going to work on the docs after I've finished the rework of the json module. As Brett suggested I'm going to module its input and return values after the pickle module before I merge it into the py3k branch. It's currently mixing unicode and str in a way which is not compatible with py3k. I've added some additional code to the site module. It should become in handy for scripters, debugging and unit tests: $ ./python -m site sys.path = [ '/home/heimes/dev/python/trunk', '/usr/local/lib/python26.zip', '/home/heimes/dev/python/trunk/Lib', '/home/heimes/dev/python/trunk/Lib/plat-linux2', '/home/heimes/dev/python/trunk/Lib/lib-tk', '/home/heimes/dev/python/trunk/Modules', '/home/heimes/dev/python/trunk/build/lib.linux-i686-2.6-pydebug', '/home/heimes/.local/lib/python2.6/site-packages', ] USER_BASE: '/home/heimes/.local' (exists) USER_SITE: '/home/heimes/.local/lib/python2.6/site-packages' (exists) ENABLE_USER_SITE: True $ ./python -m site --help /home/heimes/dev/python/trunk/Lib/site.py [--user-base] [--user-site] Without arguments print some useful information With arguments print the value of USER_BASE and/or USER_SITE separated by ':'. Exit codes with --user-base or --user-site: 0 - user site directory is enabled 1 - user site diretory is disabled by user 2 - uses site directory is disabled by super user or for security reasons >2 - unknown error $ ./python -m site --user-base --user-site /home/heimes/.local:/home/heimes/.local/lib/python2.6/site-packages $ echo $? 0 $ ./python -s -m site --user-base --user-site /home/heimes/.local:/home/heimes/.local/lib/python2.6/site-packages $ echo $? 1 Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 370 heads up
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 6, 2008, at 6:38 PM, Christian Heimes wrote: Guido has accepted my user site directory PEP today. http://python.org/dev/peps/pep-0370/ I'm about the merge the code. But first I like to let you know some things and get your opinion. Very awesome Christian! I'm psyched for this to get into the last alpha releases, which I remind everyone happens tomorrow. Plan on svn tree freeze at approximately 6pm EDT (2200 UTC). Cheers, - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBSCDe+nEjvBPtnXfVAQJJMAP/XiZvXPptw8tZ4/01hD7r39/lWgoDUmjp gVzne4+XMfz8NcLQMP2+Y38cPrQziyG8BYDqN/vWT641bOwv20QHuZYFvI9Kr09q jTEC39DzNRfD6ThzD/na6M1M7glpXiWr3hj4Va56JEnn1ekj6Ejb7BoW1oyuyz6T gUuAgVT2lOw= =2IIq -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 370 heads up
Barry Warsaw schrieb: > Very awesome Christian! I'm psyched for this to get into the last alpha > releases, which I remind everyone happens tomorrow. Plan on svn tree > freeze at approximately 6pm EDT (2200 UTC). Thanks Barry! Also thanks to Glyph, Nick and all the other people that stepped in during the discussion in favor of ~/.local! Christian PS: I'll try to get json into shape for Python 3.0. It's going to be tricky for various reasons For example the re module still doesn't support bytes. ___ 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] r62778 - in python/branches/py3k: Lib/io.py Lib/test/test_StringIO.py Lib/test/test_io.py Lib/test/test_largefile.py Lib/test/test_memoryio.py Lib/test/test_mimetools.py Modules/_byte
alexandre.vassalotti schrieb: > Author: alexandre.vassalotti > Date: Tue May 6 21:48:38 2008 > New Revision: 62778 > > Log: > Added fast alternate io.BytesIO implementation and its test suite. > Removed old test suite for StringIO. > Modified truncate() to imply a seek to given argument value. Thanks for your great work! But what about the trunk? :] Can you port your code to the trunk before the alpha gets out? Christian ___ 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-3000] Reminder: last alphas next Wednesday 07-May-2008
[EMAIL PROTECTED] wrote: > I guess we're going to have to agree to disagree. I find hiding directories > which contain executable code extremely non-obvious. I'm worried by this too. I don't like the idea of putting large and important things in hidden directories automatically without being told about it. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
Steve Holden wrote: If you want it visible, make a visible symbolic link! I have to know it's there first. The idea of an installer deliberately hiding stuff from me in a very unconventional and non-obvious way makes me uncomfortable. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] PEP 370 (was Re: Reminder: last alphas next Wednesday 07-May-2008)
Guido van Rossum wrote: The location will be somewhere under ~/.local for Unix/Linux/OS X, Can I just put in a plea for this to be somewhere under ~/Library on OSX, and not hidden? MacOSX already has clear conventions for this sort of thing -- there's no need to use a dot-name there. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] A Python-Dev bundle for TextMate
I just checked in Misc/TextMate/Python-Dev.tmbundle for those of you use TextMate. I have been using this bundle for a while and I figured others could use it. Usage tends to expect that you have opened a project from the top-level directory of a Python checkout. There is support to run the Makefile, build the docs, open the documentation index file (which can be set to an environment variable when you are not in a checkout), open an issue in the browser, and open a PEP in a browser. There is even a command to generate the boilerplate for marking a file to be removed in 3.0, complete with automatic fill-in of the module name in the message string and set up to be triggered as a tab trigger. I am hoping to continue to tweak the bundle as time goes on (and permits) with more stuff that is useful. This is not meant to replace the Python bundle, though! This is merely to add stuff specific to hack on Python itself. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] PEP 370 (was Re: Reminder: last alphas next Wednesday 07-May-2008)
Greg Ewing schrieb: > Guido van Rossum wrote: >> The location will be somewhere under ~/.local >> for Unix/Linux/OS X, > > Can I just put in a plea for this to be somewhere > under ~/Library on OSX, and not hidden? > > MacOSX already has clear conventions for this sort > of thing -- there's no need to use a dot-name there. ~/Library is only used by framework builds of Python so far. Framework builds include ~/Library/Python/2.6/site-packages and ~/.local/.. and non-framework builds just the ~/.local directory. Can you come up with a path that fits the purpose of a base directory? Christian ___ 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] urllib unicode handling
Hi, While trying to use urllib in python 2.5.1 to HTTP GET content from various web sites, I've run into a problem with urllib.quote (and .quote_plus): they don't accept unicode strings. I see that this is an issue that has been discussed before: see this thread: http://mail.python.org/pipermail/python-dev/2006-July/067248.html especially this post: http://mail.python.org/pipermail/python-dev/2006-July/067335.html While I don't really want to re-open a can of worms, it seems that the current implementation of urllib.quote and urllib.quote_plus is painfully incompatible with how the web (circa 2008) actually works. While the standards may say there is no official way to represent unicode strings in URLs, in practice the world uses UTF-8 quite heavily. For example, I found the following URLs in Google pretty quickly by looking for percent encoded utf-8 encoded accented e's. http://www.last.fm/music/Jos%C3%A9+Gonz%C3%A1lez http://en.wikipedia.org/wiki/Joseph_Fouch%C3%A9 http://apps.facebook.com/ilike/artist/Jos%C3%A9+Gonz%C3%A1lez/track/Stay+In+The+Shade?apv=1 While in theory UTF-8 is not a standard, sites like Last.fm, Facebook and Wikipedia seem to have embraced it (as have pretty much all other major web sites). As with HTML, there is what the standard says and what the actual browsers have to accept in order to work in the real world. urllib.urlencode already converts unicode characters to their UTF-8 representation before percent encoding them. Why not urllib.quote and urllib.quote_plus? Thanks for any thoughts on this, Tom ___ 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] Invitation to try out open source code review tool
>> Check out http://openid-provider.appspot.com/ >> >> Apparently it was created by your colleague Ryan Barrett. :) I found that to be of limited use. If I use my proper gmail account ([EMAIL PROTECTED]), I managed to log into the OpenID directory, but not, say, into SourceForge (probably because SF doesn't accept that specific provider - so it's not truly open, and probably shouldn't be). If I used it with the Google account associated with my regular email address, I couldn't login anywhere at all. In any case, this provider apparently didn't provide an email address to the site. That makes it useless for most applications I can think of, unless it's acceptable to go through a setup procedure again at the new site that asks for all the user details (real name, email address) again. > It solves the opposite problem -- using a Google Account to log in to > an app that requires OpenID. People are clamoring for the opposite > here. Apparently, this comes from the appengine samples, http://code.google.com/p/google-app-engine-samples/ which also includes an OpenID consumer. I'm fairly skeptical about this OpenID thing. I personally couldn't remember any of my OpenIDs, because they are just too long; plus I haven't actually seen this really work anywhere yet. 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] urllib unicode handling
> Thanks for any thoughts on this, The proper way to implement this would be IRIs (RFC 3987), in particular section 3.1. This is not as simple as just encoding it as UTF-8, as you might have to apply IDNA to the host part. Code doing so just hasn't been contributed yet. 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] urllib unicode handling
-On [20080507 04:06], Tom Pinckney ([EMAIL PROTECTED]) wrote: >While in theory UTF-8 is not a standard, sites like Last.fm, Facebook and >Wikipedia seem to have embraced it (as have pretty much all other major web >sites). As with HTML, there is what the standard says and what the actual >browsers have to accept in order to work in the real world. I agree with you. The dictionary project I am working on (Dutch <> Japanese) uses in the URLs UTF-8 characters and things just worked with reasonably new browsers (at least no problems with Opera 9, Firefox 2 and 3, Internet Explorer 7 and Safari 3). Then later Armin Ronacher warned me that you still have to URL-escape these things in order to not be in lala-land. Would people object if such functionality got added to urllib? -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B If Winter comes, can Spring be far behind..? ___ 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-3000] Reminder: last alphas next Wednesday 07-May-2008
Greg Ewing writes: > [EMAIL PROTECTED] wrote: > > I guess we're going to have to agree to disagree. I find hiding > directories > > which contain executable code extremely non-obvious. > > I'm worried by this too. I don't like the idea of putting > large and important things in hidden directories automatically > without being told about it. So what we need is a PEP specifying that installers have -q and -v switches, defaulting to -v, right? ___ 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 about mktemp once again?
> Sorry to revive this thread, but mktemp() is very useful when the file is > meant > to be created by another application (e.g. launched by subprocess, but it > could > even be a daemon running under a different user). For example if I have a > processing chain to converts a PDF to a temporary JPEG using an external tool > and then does other things with the JPEG: I don't want Python to actually > create the file, just to generate an unique filename. Are you (or are you not) aware that this strategy allows for malicious code to provide you with a fake JPEG file? If so, does it not concern you? As others have said: the reason the function is deprecated is that it is easy to run into security problems while using it, and users are often unaware of the security implications. Of course, for many applications, there is no real threat, and any risk might be acceptable. Unfortunately, if a security catastrophe results from the function, blame is (correctly) also upon Python for providing the function in the first place. 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
