[Python-Dev] Windows download links not working for 2.7.2rc1 and 3.1.4rc1
Hey all, The links to the Windows downloads for 2.7.2rc1 and 3.1.4rc1 are 404. (From the release pages.) http://python.org/ftp/python/3.1.3/python-3.1.4rc1.msi http://python.org/ftp/python/2.7.1/python-2.7.2rc1.msi All the best, Michael Foord -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.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] [Python-checkins] cpython: The compiler class for EMX was removed
On Thu, Jun 2, 2011 at 3:47 AM, eric.araujo wrote: > http://hg.python.org/cpython/rev/c3f8991cd74d > changeset: 70587:c3f8991cd74d > user: Éric Araujo > date: Wed Jun 01 15:20:44 2011 +0200 > summary: > The compiler class for EMX was removed This is the kind of checkin comment where the phrasing is a little confusing. It could mean either "was removed by mistake and has now been restored" or else "is no longer supported and has been removed". (Checking the diff resolves the ambiguity in favour of the latter interpretation, but not all diffs are as simple as this one). It's worth trying to make the final state of the source tree explicit in the checkin message (no need to edit the history, just a note for future reference). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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-checkins] cpython: The compiler class for EMX was removed
Le 02/06/2011 15:56, Nick Coghlan a écrit : > On Thu, Jun 2, 2011 at 3:47 AM, eric.araujo > wrote: >> The compiler class for EMX was removed > This is the kind of checkin comment where the phrasing is a little > confusing. Yep. Next time I’ll be longer and use something like “Remove obsolete mentions of a compiler that was removed”. ___ 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-checkins] peps: Add rules for indenting continuation lines.
On Jun 02, 2011, at 08:09 PM, guido.van.rossum wrote:
>+Continuation lines should align wrapped elements either vertically using
>+Python's implicit line joining inside parentheses, brackets and braces,
>+or using a hanging indent of double your code indention, in which case
>+there should be no argument on the first line. For example:
>+
>+Yes: # Aligned with opening delimiter
>+ foo = long_function_name(var_one, var_two,
>+ var_three, var_four)
>+
>+ # Double code indention for hanging indent; nothing on first line
>+ foo = long_function_name(
>+ var_one, var_two, var_three,
>+ var_four)
>+
>+No: # Stuff on first line forbidden
>+ foo = long_function_name(var_one, var_two,
>+ var_three, var_four)
>+
>+ # 2-space hanging indent forbidden
>+ foo = long_function_name(
>+var_one, var_two, var_three,
>+var_four)
As I mentioned to Guido, I'm not sure where the double-indent recommendation
comes from, but it's entirely possible I missed that discussion. I agree with
the recommendations, but think a single-indentation level looks fine. E.g.
return dict(
fqdn_listname=member.mailing_list,
address=member.address.email,
role=role,
user=path_to('users/{0}'.format(member.user.user_id)),
self_link=path_to('members/{0}'.format(member.member_id)),
)
or
return b'{0}://{1}:{2}/{3}/{4}'.format(
('https' if as_boolean(config.webservice.use_https) else 'http'),
config.webservice.hostname,
config.webservice.port,
config.webservice.api_version,
(resource[1:] if resource.startswith('/') else resource),
)
-Barry
signature.asc
Description: 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] [Python-checkins] peps: Add rules for indenting continuation lines.
On 6/2/2011 11:19 AM, Barry Warsaw wrote:
On Jun 02, 2011, at 08:09 PM, guido.van.rossum wrote:
+Continuation lines should align wrapped elements either vertically using
+Python's implicit line joining inside parentheses, brackets and braces,
+or using a hanging indent of double your code indention, in which case
+there should be no argument on the first line. For example:
+
+Yes: # Aligned with opening delimiter
+ foo = long_function_name(var_one, var_two,
+ var_three, var_four)
+
+ # Double code indention for hanging indent; nothing on first line
+ foo = long_function_name(
+ var_one, var_two, var_three,
+ var_four)
+
+No: # Stuff on first line forbidden
+ foo = long_function_name(var_one, var_two,
+ var_three, var_four)
+
+ # 2-space hanging indent forbidden
+ foo = long_function_name(
+var_one, var_two, var_three,
+var_four)
As I mentioned to Guido, I'm not sure where the double-indent recommendation
comes from, but it's entirely possible I missed that discussion. I agree with
the recommendations, but think a single-indentation level looks fine. E.g.
return dict(
fqdn_listname=member.mailing_list,
address=member.address.email,
role=role,
user=path_to('users/{0}'.format(member.user.user_id)),
self_link=path_to('members/{0}'.format(member.member_id)),
)
or
return b'{0}://{1}:{2}/{3}/{4}'.format(
('https' if as_boolean(config.webservice.use_https) else 'http'),
config.webservice.hostname,
config.webservice.port,
config.webservice.api_version,
(resource[1:] if resource.startswith('/') else resource),
)
-Barry
One place a double indent is extremely nice is for lines that initiate a
new indentation, but are themselves continued:
if some_function(
Some,
Parameters,
To,
Pass,
)
If_True_Operations()
is much more readable than:
if some_function(
Some,
Parameters,
To,
Pass,
)
If_True_Operations()
___
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-checkins] peps: Add rules for indenting continuation lines.
Bingo. That's why. (Though you are missing some colons in your examples. :-)
--Guido
On Thu, Jun 2, 2011 at 11:50 AM, Glenn Linderman wrote:
> On 6/2/2011 11:19 AM, Barry Warsaw wrote:
>
> On Jun 02, 2011, at 08:09 PM, guido.van.rossum wrote:
>
> +Continuation lines should align wrapped elements either vertically
> using
> +Python's implicit line joining inside parentheses, brackets and braces,
> +or using a hanging indent of double your code indention, in which case
> +there should be no argument on the first line. For example:
> +
> +Yes: # Aligned with opening delimiter
> + foo = long_function_name(var_one, var_two,
> + var_three, var_four)
> +
> + # Double code indention for hanging indent; nothing on first line
> + foo = long_function_name(
> + var_one, var_two, var_three,
> + var_four)
> +
> +No: # Stuff on first line forbidden
> + foo = long_function_name(var_one, var_two,
> + var_three, var_four)
> +
> + # 2-space hanging indent forbidden
> + foo = long_function_name(
> +var_one, var_two, var_three,
> +var_four)
>
> As I mentioned to Guido, I'm not sure where the double-indent recommendation
> comes from, but it's entirely possible I missed that discussion. I agree
> with
> the recommendations, but think a single-indentation level looks fine. E.g.
>
> return dict(
> fqdn_listname=member.mailing_list,
> address=member.address.email,
> role=role,
> user=path_to('users/{0}'.format(member.user.user_id)),
> self_link=path_to('members/{0}'.format(member.member_id)),
> )
>
> or
>
> return b'{0}://{1}:{2}/{3}/{4}'.format(
> ('https' if as_boolean(config.webservice.use_https) else 'http'),
> config.webservice.hostname,
> config.webservice.port,
> config.webservice.api_version,
> (resource[1:] if resource.startswith('/') else resource),
> )
>
> -Barry
>
> One place a double indent is extremely nice is for lines that initiate a new
> indentation, but are themselves continued:
>
> if some_function(
> Some,
> Parameters,
> To,
> Pass,
> )
> If_True_Operations()
>
> is much more readable than:
>
> if some_function(
> Some,
> Parameters,
> To,
> Pass,
> )
> If_True_Operations()
>
>
>
>
> ___
> 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/guido%40python.org
>
>
--
--Guido van Rossum (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-checkins] peps: Add rules for indenting continuation lines.
On Thu, 02 Jun 2011 14:19:00 -0400, Barry Warsaw wrote: > On Jun 02, 2011, at 08:09 PM, guido.van.rossum wrote: > >+Yes: # Aligned with opening delimiter > >+ foo = long_function_name(var_one, var_two, > >+ var_three, var_four) > >+ > >+ # Double code indention for hanging indent; nothing on first li= > ne > >+ foo = long_function_name( > >+ var_one, var_two, var_three, > >+ var_four) > >+ > >+No: # Stuff on first line forbidden > >+ foo = long_function_name(var_one, var_two, > >+ var_three, var_four) > >+ > >+ # 2-space hanging indent forbidden > >+ foo = long_function_name( > >+var_one, var_two, var_three, > >+var_four) > > As I mentioned to Guido, I'm not sure where the double-indent recommendation > comes from, but it's entirely possible I missed that discussion. I agree with > the recommendations, but think a single-indentation level looks fine. E.g. Personally, I use "enough" indentation. Sometimes that is a single indentation level, but sometimes it is more. Two spaces is definitely right out, though :) The place where a single indentation level is *not* enough is when the line being indented is the statement starting a suite: for x in long_function_name( var_one, var_two, var_three): print x vs for x in long_function_name( var_one, var_two, var_three): print x That's a case where I'd be likely to use even more than two indentation levels. Usually, though, I try to refactor the statement so it fits on one line. -- R. David Murray http://www.bitdance.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows download links not working for 2.7.2rc1 and 3.1.4rc1
> The links to the Windows downloads for 2.7.2rc1 and 3.1.4rc1 are 404. > (From the release pages.) Thanks, fixed. 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-checkins] peps: Add rules for indenting continuation lines.
On Jun 02, 2011, at 03:07 PM, R. David Murray wrote: >Personally, I use "enough" indentation. Sometimes that is a single >indentation level, but sometimes it is more. Two spaces is definitely >right out, though :) > >The place where a single indentation level is *not* enough is when the >line being indented is the statement starting a suite: > >for x in long_function_name( >var_one, var_two, var_three): >print x > >vs > >for x in long_function_name( >var_one, var_two, var_three): >print x > >That's a case where I'd be likely to use even more than two indentation >levels. Usually, though, I try to refactor the statement so it fits >on one line. That's a recommendation I can definitely get on board with! I do exactly the same thing, although sometimes I use a comment between the compound statement and the indented stanza. -Barry signature.asc Description: 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] [Python-checkins] peps: Add rules for indenting continuation lines.
On 6/2/2011 12:01 PM, Guido van Rossum wrote: Bingo. That's why. (Though you are missing some colons in your examples.:-) --Guido You operate as a good Python compiler :) ___ 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-checkins] peps: Add rules for indenting continuation lines.
On Jun 02, 2011, at 12:57 PM, Glenn Linderman wrote: >On 6/2/2011 12:01 PM, Guido van Rossum wrote: >> Bingo. That's why. (Though you are missing some colons in your examples.:-) >> >> --Guido > >You operate as a good Python compiler :) Actually, this is a key insight, which I just mentioned in a private response to Steve. How about this for the rule: If the hanging line ends in a colon, then double-indent (or "more-ly indented") seems appropriate. If not, then a single indent is sufficient. That handles cases like this, where double indent makes sense: def some_really_long_function_name( an_argument, another_argument, and_a_third_argument): foo() --- if some_really_long_function_name( an_argument, another_argument, and_a_third_argument): foo() --- and these cases where a single indent is fine: x = some_really_long_function_name( an_argument, another_argument, and_a_third_argument) foo(x) --- d = dict( a=1, b=2, c=3, d=4) return d Does that cover it? -Barry signature.asc Description: 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] [Python-checkins] peps: Add rules for indenting continuation lines.
On Thu, Jun 2, 2011 at 3:15 PM, Barry Warsaw wrote: > On Jun 02, 2011, at 12:57 PM, Glenn Linderman wrote: > >>On 6/2/2011 12:01 PM, Guido van Rossum wrote: >>> Bingo. That's why. (Though you are missing some colons in your examples.:-) >>> >>> --Guido >> >>You operate as a good Python compiler :) > > Actually, this is a key insight, which I just mentioned in a private response > to Steve. How about this for the rule: > > If the hanging line ends in a colon, then double-indent (or "more-ly > indented") seems appropriate. If not, then a single indent is sufficient. > > That handles cases like this, where double indent makes sense: > > def some_really_long_function_name( > an_argument, > another_argument, > and_a_third_argument): > foo() > > --- > > if some_really_long_function_name( > an_argument, > another_argument, > and_a_third_argument): > foo() > > --- > > and these cases where a single indent is fine: > > x = some_really_long_function_name( > an_argument, > another_argument, > and_a_third_argument) > foo(x) > > --- > > d = dict( > a=1, > b=2, > c=3, > d=4) > return d > > Does that cover it? Except that the rule gets more complicated. I don't think that always using the double indent is going to mean a lot more line breaks, so I don't think there's much benefit to the added complication. -- --Guido van Rossum (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-checkins] peps: Add rules for indenting continuation lines.
On 6/2/2011 3:49 PM, Guido van Rossum wrote: Except that the rule gets more complicated. I don't think that always using the double indent is going to mean a lot more line breaks, so I don't think there's much benefit to the added complication. Further, tools like python-mode would have to go back and fix the indent to be double indented when there are multiple lines, and the : is not typed until the last line... not impossible, but more complicated, and some of the intervening lines might be too long for the double indent, and then manual adjustments would have to happen. Ick. Double indent from the beginning, if there is nothing after the (. Or key the double indent off the leading keywords that end with : Here's a language question, though: if there are keywords that imply the need for a :, and it isn't on the same line, why is \ needed to continue to the next line (or parentheses, etc.)? If the : is truly omitted, like I did in my example, there'll be other syntax errors to report. If it is just on a later line, why complain about it missing? With complex conditions, I wind up adding extra () rather than trailing \, and that is about the only time I have ever found the need to use \ (but my workaround is to add the ()). ___ 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-checkins] peps: Add rules for indenting continuation lines.
Guido van Rossum wrote: Bingo. That's why. (Though you are missing some colons in your examples. :-) --Guido On Thu, Jun 2, 2011 at 11:50 AM, Glenn Linderman wrote: One place a double indent is extremely nice is for lines that initiate a new indentation, but are themselves continued: if some_function( Some, Parameters, To, Pass, ) If_True_Operations() Another way to approach that is if some_function( Some, Parameters, To, Pass, ): If_True_Operations() i.e. indent the *body* one more place. This avoids the jarriness of seeing an outdent that doesn't correspond to the closing of a suite. -- 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-checkins] peps: Add rules for indenting continuation lines.
On 6/2/2011 3:18 PM, Greg Ewing wrote: i.e. indent the *body* one more place. This avoids the jarriness of seeing an outdent that doesn't correspond to the closing of a suite. -1. There are likely many more lines in the suite than in the conditional, that, by being double indented, would now need continuations 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-checkins] peps: Add rules for indenting continuation lines.
Greg Ewing writes: > Another way to approach that is > > if some_function( > Some, > Parameters, > To, > Pass, > ): > If_True_Operations() > > i.e. indent the *body* one more place. This avoids the jarriness of > seeing an outdent that doesn't correspond to the closing of a suite. −1. Continuation lines for a single statement *should* look different (I disagree with “jarring”) from a suite of statements. -- \ “Simplicity and elegance are unpopular because they require | `\ hard work and discipline to achieve and education to be | _o__)appreciated.” —Edsger W. Dijkstra | Ben Finney ___ 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
