Re: [Python-Dev] PEP 8: Discourage named lambdas?
On Fri, 2 May 2008 19:03:55 -0400 "Terry Reedy" <[EMAIL PROTECTED]> wrote: > Some people write > somename = lambda args: expression > instead of the more obvious (to most people) and, dare I say, standard > def somename(args): return expression [...] > There are currently uses of named lambdas at least in urllib2. This to me > is a bad example for new Python programmers. > > What do our style mavens think? Speaking as one of those "some people", my position is that functions created with lambda are first-class objects the same as everything else in Python, and a rule that says "You must not assign a lambda to a name, ever" would be a terrible rule. (And I don't do it to save three characters. I don't do it often, and I can't exactly articulate why I do it, only that I do it when it feels right. It's a style thing.) However, I'm happy for "no named lambdas" to be a guideline or recommendation. I'm even happy for a stronger prohibition to apply to the standard library. I don't dislike named lambdas, but I don't expect others to like them. -- Steven D'Aprano ___ 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 8: Discourage named lambdas?
Terry Reedy wrote: Some people write somename = lambda args: expression instead of the more obvious (to most people) and, dare I say, standard def somename(args): return expression The difference in the result (the only one I know of) is that the code and function objects get the generic name '' instead of the more informative (in repr() output or tracebacks) 'somename'. I consider this a disadvantage. In the absence of any compensating advantages (other than the trivial saving of 3 chars), I consider the def form to be the proper Python style to the point I think it should be at least recommended for the stdlib in the Programming Recommendations section of PEP 8. There are currently uses of named lambdas at least in urllib2. This to me is a bad example for new Python programmers. What do our style mavens think? I found only an example in my personal recent code: START = "" END = "" TITLEPATTERN = lambda s: "%s" % s this three are later used in a very few .find() and .replace() expressions in the same module. I suppose my point is that while I agree it should be discouraged and is really silly to do it for the few chars gain, it can be used to some effect in very rare cases. ___ 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 8: Discourage named lambdas?
Alex Martelli wrote: On Fri, May 2, 2008 at 4:11 PM, Jesse Noller <[EMAIL PROTECTED]> wrote: +1 from me +2 from me -- of all abuses of lambdas, this one's the worst. What Alex said :) 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
[EMAIL PROTECTED] wrote: Fred> If user-local package installs went to ~/ by default ... with a Fred> way to set an alternate "prefix" instead of ~/ using a distutils Fred> configuration setting, I'd be happy enough. +1 from me. But then we clutter up people's (read *my*) home directory with no way for them to do anything about it. We should stay out of people's way by default, while making it easy for them to poke around if they want to. The ~/.local convention does that, but using ~/ directly does not. The major reasons why I think staying out of people's way by default is important: - for people like me (glyph, Georg, etc), it allows us to keep our home directory organised the way we like it. As far as I am concered, applications can store whatever user-specific configuration and data files they like inside hidden files or directories, but they shouldn't be inflicting any visible files on me that aren't related to things I am working on. - for novice users, the fact that it's hidden helps keep them from deleting it by accident - for experienced users (Barry, skip, etc) that want ~/.local to be more easily accessible, creating a visible ~/local symlink is an utterly trivial exercise. Switching the default to use public directories instead of hidden ones helps the third group at the expense of the first two groups. Given that the third group already has an easy workaround to get the behaviour they want, that seems like a bad trade-off to me. 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] PEP 8: Discourage named lambdas?
Samuele Pedroni wrote: > I found only an example in my personal recent code: > > START = "" > END = "" > TITLEPATTERN = lambda s: "%s" % s > > this three are later used in a very few .find() and .replace() > expressions in the same module. I suppose my point is that while > I agree it should be discouraged and is really silly to do it > for the few chars gain, it can be used to some effect in very > rare cases. i.e. anywhere you need a portable expression (as opposed to a portable set of statements). I have a feeling that if it were named 'expr' instead of 'lambda' we wouldn't be having this discussion. Robert Brewer [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8: Discourage named lambdas?
Nick Coghlan wrote: Samuele Pedroni wrote: I found only an example in my personal recent code: START = "" END = "" TITLEPATTERN = lambda s: "%s" % s this three are later used in a very few .find() and .replace() expressions in the same module. I suppose my point is that while I agree it should be discouraged and is really silly to do it for the few chars gain, it can be used to some effect in very rare cases. The way that's written currently, I think I could *very* easily miss the fact that TITLEPATTERN is a callable while glancing over the code (and be very confused if I later saw it being called or passed as a callback). confused? maybe, "very" seems an overstatement ___ 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 8: Discourage named lambdas?
Steven schrieb: > Speaking as one of those "some people", my position is that functions > created with lambda are first-class objects the same as everything else > in Python, and a rule that says "You must not assign a lambda to a > name, ever" would be a terrible rule. PEP 8 is for the standard library and Python core only. You can write your own code like you prefer. Nobody is going to enforce the PEP 8 style guide unless you write code for the stdlib. (By the way +1 from me, too). 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
Nick> [EMAIL PROTECTED] wrote: Fred> If user-local package installs went to ~/ by default ... with a Fred> way to set an alternate "prefix" instead of ~/ using a distutils Fred> configuration setting, I'd be happy enough. Skip> +1 from me. Nick> But then we clutter up people's (read *my*) home directory with no Nick> way for them to do anything about it. Fred asked for a --prefix flag (which is what I was voting on). I don't really care what you do by default as long as you give me a way to do it differently. 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
>> - for experienced users (Barry, skip, etc) that want ~/.local to be >> more easily accessible, creating a visible ~/local symlink is an >> utterly trivial exercise. Barry> Hey Nick, I agree with everything above, except that I'd probably Barry> put myself more in Glyph's camp :). Can't speak for Skip Barry> though... I already install everything in ~/local and just have ~/local/bin in my PATH. If I lived in a truly platform-dependent world I'd add platform-dependent ~/local-plat1, ~/local/plat2, etc directories and extend PATH a bit more. 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] PEP 8: Discourage named lambdas?
Christian Heimes schrieb: Steven schrieb: Speaking as one of those "some people", my position is that functions created with lambda are first-class objects the same as everything else in Python, and a rule that says "You must not assign a lambda to a name, ever" would be a terrible rule. PEP 8 is for the standard library and Python core only. You can write your own code like you prefer. Nobody is going to enforce the PEP 8 style guide unless you write code for the stdlib. Well, most sane people I know use it at least as a strong guideline for their own code as well, so we should always consider the impact when changing PEP 8. This specific case though is a good guideline to have. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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 3, 2008, at 5:05 AM, Nick Coghlan wrote: The major reasons why I think staying out of people's way by default is important: - for people like me (glyph, Georg, etc), it allows us to keep our home directory organised the way we like it. As far as I am concered, applications can store whatever user-specific configuration and data files they like inside hidden files or directories, but they shouldn't be inflicting any visible files on me that aren't related to things I am working on. - for novice users, the fact that it's hidden helps keep them from deleting it by accident - for experienced users (Barry, skip, etc) that want ~/.local to be more easily accessible, creating a visible ~/local symlink is an utterly trivial exercise. Hey Nick, I agree with everything above, except that I'd probably put myself more in Glyph's camp :). Can't speak for Skip though... - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBSBxkSXEjvBPtnXfVAQKSigP/d6HIeQ5QLZR4QZ7GAIttb0d+8JI6PM0e 3E2+br0jZ9IeDwjjCLIAx1kbfgIX56++NGoU7tQqiQtbcapI3H3Vb+X+VSAcs30L ORj709MDtF2oqXSzEHww5HHeKoZiQ8/FfiaZoXrXzqPVP5k9MSZu1zLrT3rpWAUP 8YLFekz/LUA= =l5be -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] Invitation to try out open source code review tool
Guido van Rossum wrote: > What I'm announcing now is the next best thing: an code review tool > for use with Subversion, inspired by Mondrian and (soon to be) > released as open source. Some of the code is even directly derived > from Mondrian. Most of the code is new though, written using Django > and running on Google App Engine. > > To try it out, go here: > > http://codereview.appspot.com Any chance to try it without signing contracts with Google? Stefan ___ 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 8: Discourage named lambdas?
On Fri, May 2, 2008 at 11:32 PM, Mike Klaas <[EMAIL PROTECTED]> wrote:
...
> Sorry, that was a bad example. It is obviously silly if the return value
> of the function is callable.
...and yet it's *exactly* what keeps happening to lambda-happy
programmers -- in production code as well as examples, and in
major/famous projects too. E.g., a simple google code search shows
many Zope versions containing "Bucket=lambda:{}" instead of the
obvious "Bucket=dict", Chandler with an intricate
t = threading.Thread(target=lambda x=activePort:testcon(x),verbose=0)
instead of
t = threading.Thread(target=testcon, args=(activePort,), verbose=0)
SQLAlchemy with "callable_=lambda i: self.setup_loader(i)" instead of
"callable_=self.setup_loader" ... apparently the existence of lambda
may easily blind one to the fact that one can simply pass a callable.
I guess that's inevitable (given lambda's existence... and human
nature;-) and about on the same plane as another hatefully redundant
construct I find myself having to beat upon over and over in code
reviews:
if :
result = True
else:
result = False
return result
vs the simple "return " [[or bool() if it's
actually mandatory to return a bool and can't be relied
upon to produce one]].
Alex
___
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] Duplicate tests
test_builtin tests most of the builtin types some how or another. All of these also have complete suites elsewhere in the tests. Shouldn't the tests in test_builtin be moved to the type specific tests? -- 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] PEP 8: Discourage named lambdas?
Samuele Pedroni wrote: I found only an example in my personal recent code: START = "" END = "" TITLEPATTERN = lambda s: "%s" % s this three are later used in a very few .find() and .replace() expressions in the same module. I suppose my point is that while I agree it should be discouraged and is really silly to do it for the few chars gain, it can be used to some effect in very rare cases. The way that's written currently, I think I could *very* easily miss the fact that TITLEPATTERN is a callable while glancing over the code (and be very confused if I later saw it being called or passed as a callback). Converting to a def makes it obvious that one of these lines is not like the others: START = "" END = "" def TITLEPATTERN(s): return "%s" % s 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
Barry Warsaw wrote: On May 3, 2008, at 5:05 AM, Nick Coghlan wrote: - for experienced users (Barry, skip, etc) that want ~/.local to be more easily accessible, creating a visible ~/local symlink is an utterly trivial exercise. Hey Nick, I agree with everything above, except that I'd probably put myself more in Glyph's camp :). Can't speak for Skip though... I was actually looking at something Fred wrote and managed to misread it as something you had posted - and it turns out Skip was just agreeing with Fred about the 'provide an option to tell distutils to use a different user-specific directory name than the default one' idea, and isn't particularly worried about where the packages go by default. Sorry for the confusion. 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] Invitation to try out open source code review tool
"Stefan Behnel" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | Any chance to try it without signing contracts with Google? Depends: Yes. You may read anything without an account. No. You may not write anything to a Google hosted service without a Google account, agreeing to standard Terms of Service, and signing in. This will not change. Maybe. You might someday be able to write without a Google account IF Guido can release as open source and IF someone adapts it to work on a different platform (Django with regular DB backend) and then hosts it elsewhere. Of course, any such alternative would probably also require an account and Terms of Service agreement. 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] PEP 8: Discourage named lambdas?
On Sat, 3 May 2008, Brett Cannon wrote: > On Sat, May 3, 2008 at 1:03 AM, Terry Reedy <[EMAIL PROTECTED]> wrote: > > Some people write > > somename = lambda args: expression > > instead of the more obvious (to most people) and, dare I say, standard > > def somename(args): return expression > > > > The difference in the result (the only one I know of) is that the code and > > function objects get the generic name '' instead of the more > > informative (in repr() output or tracebacks) 'somename'. I consider this a > > disadvantage. > > > > In the absence of any compensating advantages (other than the trivial > > saving of 3 chars), I consider the def form to be the proper Python style > > to the point I think it should be at least recommended for the stdlib in > > the Programming Recommendations section of PEP 8. > > > > There are currently uses of named lambdas at least in urllib2. This to me > > is a bad example for new Python programmers. > > > > What do our style mavens think? > > +1. A superfluous +1 from me too, although I will mention that lists of lambdas have saved my butt more than a few times. -- Cheers, Leif ___ 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 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
On Sat, May 3, 2008 at 11:46 AM, Terry Reedy <[EMAIL PROTECTED]> wrote: > > "Stefan Behnel" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > | Any chance to try it without signing contracts with Google? > > Depends: > > Yes. You may read anything without an account. > > No. You may not write anything to a Google hosted service without a Google > account, agreeing to standard Terms of Service, and signing in. This will > not change. That's not true for apps hosted under AppEngine. Apps are not required to request users to log in before they upload things. I chose to do this for the review app because I don't like the idea of anonymous comments and uploads (and the spam danger). > Maybe. You might someday be able to write without a Google account IF Guido > can release as open source It will be released as open source (Apache 2) on Monday. I'm just cleaning up the code a bit. > and IF someone adapts it to work on a different > platform (Django with regular DB backend) and then hosts it elsewhere. No, that won't be necessary. If someone contributes an alternate authentication system I'd be happy to adopt it. > Of > course, any such alternative would probably also require an account and > Terms of Service agreement. You're seeing this to strictly. While developers hosting their app are held by an Google terms of service agreement, they are not required to hold their users to such an agreement. -- --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] Duplicate tests
On Sat, May 3, 2008 at 10:25 AM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > test_builtin tests most of the builtin types some how or another. All > of these also have complete suites elsewhere in the tests. Shouldn't > the tests in test_builtin be moved to the type specific tests? > The test duplication issue has been discussed and needs to be addressed as an overall problem. But in this specific case this sounds fine to me. -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] Invitation to try out open source code review tool
> > To try it out, go here: > >http://codereview.appspot.com > > Please use the Help link in the top right to read more on how to use > the app. Please sign in using your Google Account (either a Gmail > address or a non-Gmail address registered with Google) to interact > more with the app (you need to be signed in to create new issues and > to add comments to existing issues). > > Don't hesitate to drop me a note with feedback -- note though that > there are a few known issues listed at the end of the Help page. The > Help page is really a wiki, so feel free to improve it! I'd be great to integrate this with the bug tracker so that all submitted patches automagically show up in codereview with links to one another. ___ 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] Invitation to try out open source code review tool
On Sat, May 3, 2008 at 1:20 PM, Gregory P. Smith <[EMAIL PROTECTED]> wrote: > > > > > > To try it out, go here: > > > >http://codereview.appspot.com > > > > Please use the Help link in the top right to read more on how to use > > the app. Please sign in using your Google Account (either a Gmail > > address or a non-Gmail address registered with Google) to interact > > more with the app (you need to be signed in to create new issues and > > to add comments to existing issues). > > > > Don't hesitate to drop me a note with feedback -- note though that > > there are a few known issues listed at the end of the Help page. The > > Help page is really a wiki, so feel free to improve it! > > I'd be great to integrate this with the bug tracker so that all submitted > patches automagically show up in codereview with links to one another. Yeah, or a simple button to move it over there. Either way some integration would be cool. Since this is being open-sourced we could probably have a python-dev instance installed that has all this bonus functionality for us if we can get an appspot account for the tracker team and there is some API we can tap into in order to create new issues. -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] Invitation to try out open source code review tool
On Sat, May 3, 2008 at 2:28 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: ... > > I'd be great to integrate this with the bug tracker so that all submitted > > patches automagically show up in codereview with links to one another. > > Yeah, or a simple button to move it over there. Either way some > integration would be cool. > > Since this is being open-sourced we could probably have a python-dev > instance installed that has all this bonus functionality for us if we > can get an appspot account for the tracker team and there is some API > we can tap into in order to create new issues. Given the app engine model, I guess any "API" to an app engine-hosted service would have to be of the RESTful kind, i.e., some URLs to which client-code can POST appropriately. Alex ___ 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 May 3, 2008, at 7:51 AM, [EMAIL PROTECTED] wrote: Fred asked for a --prefix flag (which is what I was voting on). I don't really care what you do by default as long as you give me a way to do it differently. What's most interesting (to me) is that no one's commented on my note that my preferred approach would be that there's no default at all; the location would have to be specified explicitly. Whether on the command line or in the distutils configuration doesn't matter, but explicitness should be required. -Fred -- Fred Drake ___ 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
Fred Drake wrote: On May 3, 2008, at 7:51 AM, [EMAIL PROTECTED] wrote: Fred asked for a --prefix flag (which is what I was voting on). I don't really care what you do by default as long as you give me a way to do it differently. What's most interesting (to me) is that no one's commented on my note that my preferred approach would be that there's no default at all; the location would have to be specified explicitly. Whether on the command line or in the distutils configuration doesn't matter, but explicitness should be required. I thought Christian said something about that defeating one of the main points of the PEP - to allow per-user installation of modules to "just work" for non-administrators. (It may not have been Christian, and it may not have been directly in response to you, but I'm pretty sure I read it somewhere in this thread ;) Anyway, a per-user site-packages directly only "just works" if the standard behaviour of a Python installation is to provide access to the per-user packages without requiring any additional action on the part of the user. A couple of paragraphs in the PEP may also be of interest to you: """For security reasons the user site directory is not added to sys.path when the effective user id or group id is not equal to the process uid / gid [9]. It's an additional barrier against code injection into suid apps. However Python suid scripts must always use the -E and -s option or users can sneak in their own code. The user site directory can be suppressed with a new option -s or the environment variable PYTHONNOUSERSITE. The feature can be disabled globally by setting site.ENABLE_USER_SITE to the value False. It must be set by editing site.py. It can't be altered in sitecustomize.py or later.""" So Python itself turns the feature off automatically for invocation via sudo and the like, and the sysadmin can disable the feature completely through site.py. 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] PEP 8: Discourage named lambdas?
> I guess that's inevitable (given lambda's existence... and human > nature;-) and about on the same plane as another hatefully redundant > construct I find myself having to beat upon over and over in code > reviews: > > if : > result = True > else: > result = False > return result > > vs the simple "return " [[or bool() if it's > actually mandatory to return a bool and can't be relied > upon to produce one]]. Indeed, I think these are the same phenomenons. If lambdas where not available, people would, instead of writing Thread(target = lambda: foo()) write def target(): foo() Thread(target = target) Your example above demonstrates that the boolean type is a concept that is *very* difficult to grasp (not the notion of boolean expressions, which are easy to understand - it's the boolean *type* that is difficult, i.e. that a boolean expression can be used not just in conditional statements, but also assigned to variables, returned, etc.). When I ask students in the exam to rewrite your code above (and assuming they use Java), so that "it is a single line", they typically write return ? true : false; Likewise, apparently, the notion of generic callables is difficult to understand. Unless you have written it yourself, you won't recognize an expression as callable. 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
