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 expression: result = True else: result = False return result vs the simple return expression [[or bool(expression) if it's actually mandatory to return a bool and expression 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 expression ? 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
Re: [Python-Dev] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
On Fri, May 02, 2008, Barry Warsaw wrote: On May 2, 2008, at 1:48 AM, [EMAIL PROTECTED] wrote: In the long term, if everyone followed suit on ~/.local, that would be great. But I don't want a ~/Python, ~/Java, ~/Ruby, ~/PHP, ~/Perl, ~/OCaml and ~/Erlang and a $PATH as long as my arm just so I can run a few applications without system- installing them. I hate to send a me too messages, but I have to say Glyph is exactly right here. +1 -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Help a hearing-impaired person: http://rule6.info/hearing.html ___ 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 08:27:27 pm Nick Coghlan wrote: Samuele Pedroni wrote: I found only an example in my personal recent code: START = !-- *db-payload-start* -- END = !-- *db-payload-end* -- TITLEPATTERN = lambda s: title%s/title % 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). I think you're exaggerating a tad here. Why would you be very confused when you see TITLEPATTERN() or foo(callback=TITLEPATTERN)? What else would TITLEPATTERN be but a callable when it's being used as a callable? Converting to a def makes it obvious that one of these lines is not like the others: Do you get confused by factory functions? (or for that matter callable class instances, types, etc.) TITLEPATTERN = factory(args) # note the lack of def ... lots of code ... foo(callback=TITLEPATTERN) # Note: TITLEPATTERN is a callable I think that if I argued that factory functions were bad because 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), most people would dismiss the concern and tell me it was my problem. It certainly isn't a good reason for discouraging factory functions, and I don't think it should be considered a good reason for discouraging lambdas. -- 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] Invitation to try out open source code review tool
Hi, Guido van Rossum wrote: On Sat, May 3, 2008 at 11:46 AM, Terry Reedy [EMAIL PROTECTED] wrote: 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. Personally, I would consider the following sufficient: 1) people who have authenticated themselves against the underlying VCS (i.e. project members) may post public comments and comment on other comments 2) anonymous users can post comments that won't become publicly visible until an authenticated user acknowledges them or comments on them. That should be enough to keep the system open to everybody and to keep spam away. 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. I agree with that, it's about commensurability. People who use my service shouldn't be bothered with the contracts I signed with my own service provider. Imagine you'd have to sign a contract with my web hoster to visit my web site. 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 Sun, 4 May 2008 01:24:54 am Alex Martelli wrote:
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,
In fairness, up until a few years ago, Bucket=dict wouldn't have worked.
I'm sure there's a lot of Python programmers who learnt the language
with version 2.0 who still have blind-spots when it comes to types. I
know I do (but I'm getting better with practice).
Besides, would that be any better written as this?
def Bucket(): return {}
I think not. This is not a named lambda problem, this is a developer
doesn't know how to use types problem.
While we're discussing named lambdas, and at the risk of dragging this
thread out even longer, here's one example where I would use one:
def parrot(args, transformation=None):
if transformation is None: # Use an identity function.
transformation = lambda x: x
for arg in args:
do_something_with(transformation(arg))
Does anybody have any constructive comments to make about this usage?
--
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?
Steven D'Aprano steve at pearwood.info writes: I think you're exaggerating a tad here. Why would you be very confused when you see TITLEPATTERN() or foo(callback=TITLEPATTERN)? What else would TITLEPATTERN be but a callable when it's being used as a callable? The real problem is this example is not the fact that there is a lambda, but that the variable name doesn't reflect it is a callable. It is common practice to use verbs for callables, and nouns for non-callables. Thus I'd expect the variable to be called something like make_title_pattern rather than TITLEPATTERN (and what's with the ugly allcaps by the way?). Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 Visually I find the second form very ugly. The colon indicates to me that a new line is expected, and breaking that expectation breaks my flow of code reading. I very *rarely* use lambdas in the form you show, but where you do I prefer them to the single line function. Michael Foord The difference in the result (the only one I know of) is that the code and function objects get the generic name 'lambda' 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? Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk ___ 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] 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 Though def-statements are usually the best way to go, there are some reasonable cases where the first form reads better. I say leave it to the programmer to decide. Experience will quickly teach the def-statement is more flexible. Another thought is that I often give the advice that if a long-line becomes hard to read, then an easy solution is to pull-out an inner expression and give it a name. This is especially true when the intended purpose of the inner expression isn't obvious and giving it a name adds clarity. I would have to burden this advice with an admonition to go further and move the relevant code farther away from where it is used: for k,g in groupby(iterable, key=lambda r: (r[0].lower(), r[5].lower())): ... lastname_firstname = lambda r: (r[0].lower(), r[5].lower()) for k, g in groupby(iterable, key=lastname_firstname): ... That transformation adds clarity. Going further and creating a separate def-statement outside the current function would just move the relevant code farther away and impair readability. Also, I'm somewhat opposed to using PEP 8 in this way. Somehow, the PEPs recommendations seem to get occasionally interpreted as law. IMO, the PEP should be limited to things that have a real impact on code being maintained by multiple programmers. It should not grow into a general purpose set of situation independent prejudgments about which constructs should be favored over others (i.e. programmer x hates for-else so those should be avoided in favor of using flags or programmer y thinks it's uncool to have a return-statement anywhere but the end of a function). What do our style mavens think? -1 Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Invitation to try out open source code review tool
Guido van Rossum wrote: On Thu, May 1, 2008 at 4:37 PM, Neal Becker [EMAIL PROTECTED] wrote: It would be really nice to see support for some other backends, such as Hg or bzr (which are both written in python), in addition to svn. Once it's open source feel free to add those! trac supports a pretty wide set of VCSes. http://trac.edgewall.org/wiki/VersioningSystemBackend Maybe your tools could integrate these backends somehow instead of re-implementing yet another suite of VCS backend connectors. 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] [Python-3000] Reminder: last alphas next Wednesday 07-May-2008
On 3 May, 11:34 pm, [EMAIL PROTECTED] 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 I responded to it in my initial response, but let me be clearer. First, Skip, I *only* care about the default behavior. There's already a way to do it differently: PYTHONPATH. So, Fred, I think what you're arguing for is to drop this feature entirely. Or is there some other use for a new way to allow users to explicitly add something to sys.path, aside from PYTHONPATH? It seems that it would add more complexity and I can't see what the value would be. As I've said a dozen times in this thread already, the feature I'd like to get from a per-user installation location is that 'setup.py install', or at least some completely canonical distutils incantation, should work, by default, for non-root users; ideally non-administrators on windows as well as non-root users on unixish platforms. ___ 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
glyph As I've said a dozen times in this thread already, the feature glyph I'd like to get from a per-user installation location is that glyph 'setup.py install', or at least some completely canonical glyph distutils incantation, should work, by default, for non-root glyph users; ideally non-administrators on windows as well as non-root glyph users on unixish platforms. I'm unclear why anything needs changing then. At work we have idiosyncratic central install locations for everything, not just Python. None of this stuff is installed by root. When I want to install some package to test without polluting the central waters I simply run setup.py install with a --prefix arg then set PYTHONPATH to pick up my stuff before the central stuff. I see no reason to change the behavior of setup.py's install command. It gives you the flexibility needed to handle a number of different scenarios. 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
On Sun, May 4, 2008 at 9:58 AM, [EMAIL PROTECTED] wrote: ...snip... As I've said a dozen times in this thread already, the feature I'd like to get from a per-user installation location is that 'setup.py install', or at least some completely canonical distutils incantation, should work, by default, for non-root users; ideally non-administrators on windows as well as non-root users on unixish platforms. This is a big +1 from me. The way I currently work around the must be root to install stuff on both OS/X and other Lin/Uni(xes) is via virtualenv.py and a lot of bash environment trickery. If nothing else comes out of this, I think what glyph points out is the ideal, and simplest goal. Ignoring the directory name debate, I would like to see this local user dir mirror the normal directory tree that packages installed from distutils/setuptools typically use, namely it should have the: lib/site-packages/your module here and bin/your scripts here directories, and a known parent name. One thing that could be done is pick a default name for the parent, ala ~/Python - but let users override it with an environment variable if they so desire (PYTHON_USER_DIR?) so that those who want it hidden can have it hidden, and those of us who don't, don't. -jesse ___ 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 (was Re: [Python-3000] Reminder: last alphas next Wednesday 07-May-2008)
[EMAIL PROTECTED] wrote: As I've said a dozen times in this thread already, the feature I'd like to get from a per-user installation location is that 'setup.py install', or at least some completely canonical distutils incantation, should work, by default, for non-root users; ideally non-administrators on windows as well as non-root users on unixish platforms. This is what I see as the goal of PEP 370 as well. Perhaps the PEP could be more explicit in spelling that out? The primary goal of this PEP is to provide a standard mechanism allowing Python users to install distutils packages for their own use without affecting other users of the same machine, and without requiring any change to the packages themselves. I think the current Rationale section kind of assumes that the reader already recognises the above paragraph as the reason for the PEP. In the UNIX Notes section, the PEP should probably also state that the reason for choosing a hidden dot-file directory is that users generally aren't going to have any interest in the source files for the Python packages that they install, and that users that would prefer for the files to be visible can easily make a symbolic link to the directory. 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
[Python-Dev] Next PyPy sprint in Berlin, 17-22 May
Hi all, Our next PyPy sprint will take place in Berlin, 17-22nd May 2008. More precisely, the sprint will be in the crashed c-base space station, Berlin, Germany, Earth, Solar System. This is a fully public sprint: newcomers (from all planets) and topics other than those proposed in the announcement are welcome. For more information: http://codespeak.net/pypy/extradoc/sprintinfo/berlin-2008/announcement.html A bientot, Armin. ___ 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
First, Skip, I *only* care about the default behavior. There's already a way to do it differently: PYTHONPATH. So, Fred, I think what you're arguing for is to drop this feature entirely. Or is there some other use for a new way to allow users to explicitly add something to sys.path, aside from PYTHONPATH? It seems that it would add more complexity and I can't see what the value would be. PYTHONPATH is lacking one feature which is important for lots of packages and setuptools. The directories in PYTHONPATH are just added to sys.path. But setuptools require a site package directory. Maybe a new env var PYTHONSITEPATH could solve the problem. As I've said a dozen times in this thread already, the feature I'd like to get from a per-user installation location is that 'setup.py install', or at least some completely canonical distutils incantation, should work, by default, for non-root users; ideally non-administrators on windows as well as non-root users on unixish platforms. The implementation of my PEP provides a new option for install: $ python setup.py install --user Is it sufficient for you? 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 Coghlan schrieb:
- for experienced users (Barry, skip, etc) that want ~/.local to be more
easily accessible, creating a visible ~/local symlink is an utterly
trivial exercise.
Our you can set the environment variable PYTHONUSERBASE to $HOME.
PYTHONUSERBASE is the root directory for user specific data:
def addusersitepackages(known_paths):
Add a per user site-package to sys.path
Each user has its own python directory with site-packages in the
home directory.
USER_BASE is the root directory for all Python versions
USER_SITE is the user specific site-packages directory
USER_SITE/.. can be used for data.
global USER_BASE, USER_SITE
env_base = os.environ.get(PYTHONUSERBASE, None)
def joinuser(*args):
return os.path.expanduser(os.path.join(*args))
#if sys.platform in ('os2emx', 'riscos'):
## Don't know what to put here
#USER_BASE = ''
#USER_SITE = ''
if os.name == nt:
base = os.environ.get(APPDATA) or ~
USER_BASE = env_base if env_base else joinuser(base, Python)
USER_SITE = os.path.join(USER_BASE,
Python + sys.version[0] + sys.version[2],
site-packages)
else:
USER_BASE = env_base if env_base else joinuser(~, .local)
USER_SITE = os.path.join(USER_BASE, lib,
python + sys.version[:3],
site-packages)
if os.path.isdir(USER_SITE):
addsitedir(USER_SITE, known_paths)
return known_paths
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] Reminder: last alphas next Wednesday 07-May-2008
Jesse Noller schrieb: One thing that could be done is pick a default name for the parent, ala ~/Python - but let users override it with an environment variable if they so desire (PYTHON_USER_DIR?) so that those who want it hidden can have it hidden, and those of us who don't, don't. Has anybody read my PEP or do I need a Christian's English to real English converter? *g* From my PEP 370: --- The path to the user base directory can be overwritten with the environment variable PYTHONUSERBASE. The default location is used when PYTHONUSERBASE is not set or empty. --- PYTHONUSERBASE defaults to ~/.local/ on Unix. In order to install packages in ~/lib, ~/bin etc directly you can do export PYTHONUSERBASE=$HOME in your .bashrc or .profile. 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
On 2008-05-04 18:14, Christian Heimes wrote: First, Skip, I *only* care about the default behavior. There's already a way to do it differently: PYTHONPATH. So, Fred, I think what you're arguing for is to drop this feature entirely. Or is there some other use for a new way to allow users to explicitly add something to sys.path, aside from PYTHONPATH? It seems that it would add more complexity and I can't see what the value would be. PYTHONPATH is lacking one feature which is important for lots of packages and setuptools. The directories in PYTHONPATH are just added to sys.path. But setuptools require a site package directory. Maybe a new env var PYTHONSITEPATH could solve the problem. We don't need another setup variable for this. Just place a well-known module into the site-packages/ directory and then query it's __file__ attribute, e.g. site-packages/site_packages.py The module could even include a few helpers to query various settings which apply to the site packages directory, e.g. site_packages.get_dir() site_packages.list_packages() site_packages.list_modules() etc. As I've said a dozen times in this thread already, the feature I'd like to get from a per-user installation location is that 'setup.py install', or at least some completely canonical distutils incantation, should work, by default, for non-root users; ideally non-administrators on windows as well as non-root users on unixish platforms. The implementation of my PEP provides a new option for install: $ python setup.py install --user Is it sufficient for you? Just in case you don't know... python setup.py install --home=~ will install to ~/lib/python The problem is not getting the packages installed in a non-admin location. It's about Python looking in a non-admin location per default (as well as in the site-packages location). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 04 2008) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ 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 Sun, May 4, 2008 at 2:58 AM, Stefan Behnel [EMAIL PROTECTED] wrote: Personally, I would consider the following sufficient: 1) people who have authenticated themselves against the underlying VCS (i.e. project members) may post public comments and comment on other comments Tell me how to authenticate against a SVN project using HTTP only. 2) anonymous users can post comments that won't become publicly visible until an authenticated user acknowledges them or comments on them. Can you work out this design more? I don't understand how an authenticated user can acknowledge an anonymous comment if it isn't publicly visible. Also, AFAIK our bug tracker doesn't support anonymous comments either, so I don't think this is an important use case. That should be enough to keep the system open to everybody and to keep spam away. It's also more work to code. Once I've released the code I'll let others decide whether they want to contribute such features. -- --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 Sun, May 4, 2008 at 5:52 AM, Stefan Behnel [EMAIL PROTECTED] wrote: Guido van Rossum wrote: On Thu, May 1, 2008 at 4:37 PM, Neal Becker [EMAIL PROTECTED] wrote: It would be really nice to see support for some other backends, such as Hg or bzr (which are both written in python), in addition to svn. Once it's open source feel free to add those! trac supports a pretty wide set of VCSes. http://trac.edgewall.org/wiki/VersioningSystemBackend Maybe your tools could integrate these backends somehow instead of re-implementing yet another suite of VCS backend connectors. That depends. If it requires more than plain HTTP requests it currently cannot be done on AppEngine. Anyway, I will continue to say, I'm making it open source Monday and then you can see for yourself how to add this. I don't want to be writing all the code for this project; I want it to grow with user contributions. -- --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 wrote: On Sun, May 4, 2008 at 2:58 AM, Stefan Behnel [EMAIL PROTECTED] wrote: Personally, I would consider the following sufficient: 1) people who have authenticated themselves against the underlying VCS (i.e. project members) may post public comments and comment on other comments Tell me how to authenticate against a SVN project using HTTP only. Good question. :) 2) anonymous users can post comments that won't become publicly visible until an authenticated user acknowledges them or comments on them. Can you work out this design more? I don't understand how an authenticated user can acknowledge an anonymous comment if it isn't publicly visible. I was suggesting that you'd sign in as a project member and would then see all comments. They just wouldn't show up on the public web sites without further action. I think that matches the normal work flow. External users usually do some kind of upstream talk anyway. It would be rare that no project member is involved in a patch contribution. And new contributions would go through the bug tracker first anway, right? Also, AFAIK our bug tracker doesn't support anonymous comments either, so I don't think this is an important use case. That should be enough to keep the system open to everybody and to keep spam away. It's also more work to code. Sure, it's also just an idea from my side. 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] Invitation to try out open source code review tool
[Stefan, can you please keep python-dev in the CC list?] On Sun, May 4, 2008 at 9:52 AM, Stefan Behnel [EMAIL PROTECTED] wrote: Guido van Rossum wrote: On Sun, May 4, 2008 at 2:58 AM, Stefan Behnel [EMAIL PROTECTED] wrote: 2) anonymous users can post comments that won't become publicly visible until an authenticated user acknowledges them or comments on them. Can you work out this design more? I don't understand how an authenticated user can acknowledge an anonymous comment if it isn't publicly visible. I was suggesting that you'd sign in as a project member and would then see all comments. Hm. Since most users of the site are project members this means most people would see the anonymous comments (= potential spam). However, the anonymous user couldn't see their *own* comments back later (or be allowed to edit them). Doesn't sound like a good idea to me. They just wouldn't show up on the public web sites without further action. I think that matches the normal work flow. External users usually do some kind of upstream talk anyway. It would be rare that no project member is involved in a patch contribution. And new contributions would go through the bug tracker first anway, right? Not necessarily. Unless there's an uprising, I'll keep support for anonymous comments a non-goal for now. Also, AFAIK our bug tracker doesn't support anonymous comments either, so I don't think this is an important use case. That should be enough to keep the system open to everybody and to keep spam away. It's also more work to code. Sure, it's also just an idea from my side. Stefan -- --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] PEP 8: Discourage named lambdas?
On Sun, May 4, 2008 at 3:31 AM, Raymond Hettinger [EMAIL PROTECTED] wrote: ... for k,g in groupby(iterable, key=lambda r: (r[0].lower(), r[5].lower())): ... lastname_firstname = lambda r: (r[0].lower(), r[5].lower()) for k, g in groupby(iterable, key=lastname_firstname): ... That transformation adds clarity. Going further and creating a separate def-statement outside the current function would just move the relevant code farther away and impair readability. And that would be totally silly and uncalled for -- why ever would it be placed *outside the current function*?! What a straw-man...! Just do def last_first(r): return r[0].lower(), r[5].lower() for k, g in groupby(iterable, key=last_first): ... putting the def right where you now have the name = lambda ... of course! 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] Py3k and asyncore/asynchat
On Mon, Mar 31, 2008 at 12:11 AM, Neal Norwitz [EMAIL PROTECTED] wrote: On Sun, Mar 30, 2008 at 7:44 PM, Josiah Carlson [EMAIL PROTECTED] wrote: I haven't really had time to update the tests/documentation, but again, I wasn't experiencing any strange test failures with asyncore/asynchat, nor have I been able to find the buildbot failures that you are referring to. Could someone please link the failures that are not related to being unable to discover a port number? 3 different platforms, 3 different problems: http://www.python.org/dev/buildbot/all/alpha%20Tru64%205.1%20trunk/builds/2790/step-test/0 http://www.python.org/dev/buildbot/all/x86%20FreeBSD%203%203.0/builds/0/step-test/0 http://www.python.org/dev/buildbot/all/x86%20XP-4%203.0/builds/643 According to the release schedule, we should have at least a couple more months for documentation and tests to be updated (I can get patches ready for alpha 3). When you get the patches with tests and doc, I'll be happy to check in. n I have updated the documentation, and as much of the tests as was required to pass on my Windows XP machine. In looking at the buildbots, I'm not seeing any more common issues. Unfortunately, I also hit the urls provided above too late, and I wasn't able to see the actual issues (if they still persist). If possible, the syntax in the documentation that I added should be checked, as I needed to convert from my older TeX docs to the new ReST doc format. I have attached the patch file, and am in the process of regaining access to the bug tracker. In the mean time, Giampaolo will be posting the patch to the tracker in issue 1736190. If anyone has any questions, please ask. - Josiah full_async_patch.patch Description: Binary data ___ 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 Sun, May 4, 2008 at 11:24 AM, Gregory P. Smith [EMAIL PROTECTED] wrote: Rather than svn authentication i suggest just piggybacking on top of the bug trackers authentication. that is an integration i think we should aim for anyways and it should keep the no-google-account fear mongers happy. code comments (as bug comments are today) should not require svn commit access. The problem with this is that I'd like to have a single codereview webapp that serves many projects, as long as they use subversion. The scalability of AppEngine should make this a very attractive solution. Integrating with each separate bug tracker however would be a pain. anyways, i expect someone else may implement that once the code is out there. I sure hope so. :-) -- --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
M.-A. Lemburg schrieb: PYTHONPATH is lacking one feature which is important for lots of packages and setuptools. The directories in PYTHONPATH are just added to sys.path. But setuptools require a site package directory. Maybe a new env var PYTHONSITEPATH could solve the problem. We don't need another setup variable for this. Just place a well-known module into the site-packages/ directory and then query it's __file__ attribute, e.g. site-packages/site_packages.py The module could even include a few helpers to query various settings which apply to the site packages directory, e.g. site_packages.get_dir() site_packages.list_packages() site_packages.list_modules() etc. I don't see how it is going to solve the use case Add another site package directory when I don't have write access to the global site package directory and I don't want to modify my apps. Just in case you don't know... python setup.py install --home=~ will install to ~/lib/python The problem is not getting the packages installed in a non-admin location. It's about Python looking in a non-admin location per default (as well as in the site-packages location). I know the --home option. For one the --home option is Unix only and not supported on Windows Also the --user option takes all options of my PEP 370 user site directory into account, includinge the PYTHONUSERBASE env var. 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 (was Re: Reminder: last alphas next Wednesday 07-May-2008)
Nick Coghlan schrieb: This is what I see as the goal of PEP 370 as well. Perhaps the PEP could be more explicit in spelling that out? The primary goal of this PEP is to provide a standard mechanism allowing Python users to install distutils packages for their own use without affecting other users of the same machine, and without requiring any change to the packages themselves. I think the current Rationale section kind of assumes that the reader already recognises the above paragraph as the reason for the PEP. Good point ;) The author of the PEP was kinda sure all readers would recognize the ratio. Again explicit is better than implicit. I'll update the PEP later. In the UNIX Notes section, the PEP should probably also state that the reason for choosing a hidden dot-file directory is that users generally aren't going to have any interest in the source files for the Python packages that they install, and that users that would prefer for the files to be visible can easily make a symbolic link to the directory. Good point, too. Thanks Nick! 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
On 2008-05-04 21:57, Christian Heimes wrote: M.-A. Lemburg schrieb: PYTHONPATH is lacking one feature which is important for lots of packages and setuptools. The directories in PYTHONPATH are just added to sys.path. But setuptools require a site package directory. Maybe a new env var PYTHONSITEPATH could solve the problem. We don't need another setup variable for this. Just place a well-known module into the site-packages/ directory and then query it's __file__ attribute, e.g. site-packages/site_packages.py The module could even include a few helpers to query various settings which apply to the site packages directory, e.g. site_packages.get_dir() site_packages.list_packages() site_packages.list_modules() etc. I don't see how it is going to solve the use case Add another site package directory when I don't have write access to the global site package directory and I don't want to modify my apps. No, but it's going to solve the issue which of the sys.path directories is to be considered the site packages directory. I was under the impression that this is what you were after. Just in case you don't know... python setup.py install --home=~ will install to ~/lib/python The problem is not getting the packages installed in a non-admin location. It's about Python looking in a non-admin location per default (as well as in the site-packages location). I know the --home option. For one the --home option is Unix only and not supported on Windows Also the --user option takes all options of my PEP 370 user site directory into account, includinge the PYTHONUSERBASE env var. Ok. Just wanted to mention that there is a precedent in distutils for doing user home directory installations. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, May 04 2008) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ 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?
Raymond Hettinger wrote: lastname_firstname = lambda r: (r[0].lower(), r[5].lower()) for k, g in groupby(iterable, key=lastname_firstname): ... That transformation adds clarity. Going further and creating a separate def-statement outside the current function would just move the relevant code farther away and impair readability. It doesn't have to be outside the function -- it can be in exactly the same place as the lambda assignment above. def lastname_firstname(r): return (r[0].lower(), r[5].lower()) for k, g in groupby(iterable, key=lastname_firstname): ... Maybe def is an executable statement is another thing people have a blind spot about? -- 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] Next PyPy sprint in Berlin, 17-22 May
Armin Rigo wrote: More precisely, the sprint will be in the crashed c-base space station, Berlin, Germany, Earth, Solar System. You have a crashed space station in Berlin? Wow! I hope it didn't come down on anything important... -- 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] Invitation to try out open source code review tool
This code is now open source! Browse it here: http://code.google.com/p/rietveld/source/browse --Guido On Thu, May 1, 2008 at 9:41 AM, Guido van Rossum [EMAIL PROTECTED] wrote: Some of you may have seen a video recorded in November 2006 where I showed off Mondrian, a code review tool that I was developing for Google (http://www.youtube.com/watch?v=sMql3Di4Kgc). I've always hoped that I could release Mondrian as open source, but it was not to be: due to its popularity inside Google, it became more and more tied to proprietary Google infrastructure like Bigtable, and it remained limited to Perforce, the commercial revision control system most used at Google. 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. I'm inviting the Python developer community to try out the tool on the web for code reviews. I've added a few code reviews already, but I'm hoping that more developers will upload at least one patch for review and invite a reviewer to try it out. 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! -- --Guido van Rossum (home page: http://www.python.org/~guido/) -- --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
I forgot -- you need to link or copy the 'django' directory from Django 0.97.pre into the app directory. Otherwise you'll be using the Django 0.96.1 that's included with the AppEngine runtime, and the code is not compatible with that version. On Sun, May 4, 2008 at 8:38 PM, Guido van Rossum [EMAIL PROTECTED] wrote: This code is now open source! Browse it here: http://code.google.com/p/rietveld/source/browse --Guido On Thu, May 1, 2008 at 9:41 AM, Guido van Rossum [EMAIL PROTECTED] wrote: Some of you may have seen a video recorded in November 2006 where I showed off Mondrian, a code review tool that I was developing for Google (http://www.youtube.com/watch?v=sMql3Di4Kgc). I've always hoped that I could release Mondrian as open source, but it was not to be: due to its popularity inside Google, it became more and more tied to proprietary Google infrastructure like Bigtable, and it remained limited to Perforce, the commercial revision control system most used at Google. 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. I'm inviting the Python developer community to try out the tool on the web for code reviews. I've added a few code reviews already, but I'm hoping that more developers will upload at least one patch for review and invite a reviewer to try it out. 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! -- --Guido van Rossum (home page: http://www.python.org/~guido/) -- --Guido van Rossum (home page: http://www.python.org/~guido/) -- --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] Module Suggestion: ast
I'm in the process of writing C code for the purposes of traversing AST nodes in the AST optimization branch. This seems to be an ideal case for code generation based on the ASDL representation of the AST as we're currently doing for Python-ast.[ch]. I'm already considering this approach for some code I need to visit the C AST representation. We could likely write a similar generator for the PyObject representation of the AST, which might be useful for the proposed ast module. This would ensure that both implementations of the AST visitation code are always kept in step with the ASDL. The only real problem I can foresee with this is that the code in asdl_c.py is already getting pretty hairy. Adding to the mess is going to make it worse still. Maybe this will serve as a good opportunity to clean it up a little? Any objections? Cheers, T Paul Moore wrote: 2008/5/1 Georg Brandl [EMAIL PROTECTED]: Armin Ronacher schrieb: I would like to propose a new module for the stdlib for Python 2.6 and higher: ast. If there are no further objections, I'll add this to PEP 361 so that the proposal doesn't get lost. Excuse my confusion over process, but if this is to go into 2.6, does that mean it needs to be ready before the first beta? Or is there a more relaxed schedule for the stdlib (and if so, what is the deadline for the stdlib)? The same question probably applies to the stdlib reorg... Paul. ___ 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/tom%40vector-seven.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
