Re: [Python-Dev] PEP 498 f-string: please remove the special case for spaces

[Cameron Simpson]

On 11Aug2015 18:07, Greg Ewing  wrote:

Cameron Simpson wrote:
To illustrate, there's a consumer rights TV snow here with a segment 
called "F.U. Tube", where members of the public describe ripoffs and 
other product failures in video form. While a phonetic play on the 
name "YouTube", the abbreviation also colloquially means just what 
you think it might. I can just imagine reciting one of these new 
strings out loud...


We could require it to be spelled "uf" unless "from __future__
import billy_connolly_as_FLUFL" is in effect.


That seems like a reasoned and measured response.

Cheers,
Cameron Simpson 

For those who understand, NO explanation is needed,
for those who don't understand, NO explanation will be given!
   - Davey D 
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP-498: Literal String Formatting

[Stephen J. Turnbull]

Barry Warsaw writes:

 > Besides, any expression you have to calculate can go in a local
 > that will get interpolated.

Sure, but that style should be an application programmer choice.

If this syntax can't replace the vast majority of cases where the
format method is invoked on a literal string without requiring
introduction of gratuitous temporaries, I don't see the point.  By
"invoked", I mean the arguments to the format method, too, so even
function calls should be permitted.  To me it's not worth the expense
of learning and teaching the differences otherwise.

If that point of view were generally accepted, it seems to me that it
kills this idea of using the same syntax for programmer interpolation
and for translation interpolation.  The two use cases present
requirements that are too different since translators are generally
"third party volunteers", *not* "trusted contributors".  Nor are their
contributions generally reviewed by "core".

 > In an i18n context, you want to stick to the simplest possible
 > substitution placeholders.

Certainly, and in that case I think format strings with simple
variable and attribute interpolation, plus an explicit invocation of
the format method comprise TOOWDTI -- it's exactly what you want!  In
fact, I am now -1 on an implicitly formatted I18N quasi-literal.  It
seems to me that in fact we should think of such an internationalized
string as merely an obfuscated way of spelling variable_input_by_user.
The current I18N frameworks make this clear by requiring a function
call, which theoretically could return any string and have any side
effects -- but these are controlled by the programmer.

But there are other contexts, equally important, where a more compact,
implicit formatting syntax would be very valuable, starting with
scripting.

BTW, I know application programmers hate those calls.  I wonder if
they can't be folded into str.format, with a dummy string prefix of
"i" (or "_"!) being allowed solely to trigger xgettext and similar
potfile extraction utilities?  So you'd write

>>> s = i"Please translate this {adjective} string."
>>> s.format(adjective=i"beautiful", gettext=('ja', None))
"この美しい文字列を訳してくださいませ。"

where the first component of gettext is the language and the second is
the gettext domain (defaulting to the current application).  If that
works, the transformation from monolingual application to
internationalized application is sufficiently mechanical that a non-
programmer could be easily taught to perform it.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 498 f-string: please remove the special case for spaces

[Chris Angelico]

On Tue, Aug 11, 2015 at 5:08 PM, Cameron Simpson  wrote:
> On 11Aug2015 18:07, Greg Ewing  wrote:
>>
>> Cameron Simpson wrote:
>>>
>>> To illustrate, there's a consumer rights TV snow here with a segment
>>> called "F.U. Tube", where members of the public describe ripoffs and other
>>> product failures in video form. While a phonetic play on the name "YouTube",
>>> the abbreviation also colloquially means just what you think it might. I can
>>> just imagine reciting one of these new strings out loud...
>>
>>
>> We could require it to be spelled "uf" unless "from __future__
>> import billy_connolly_as_FLUFL" is in effect.
>
>
> That seems like a reasoned and measured response.

Given the levels of profanity that are not disallowed in identifier
names, I think blocking off a two-letter prefix is pretty pointless.
It'd be different if the specification _required_ it (though even
then, it's not that big a deal...), but merely permitting it? Not
Python's fault.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 498 f-string: please remove the special case for spaces

[Steven D'Aprano]

On Tue, Aug 11, 2015 at 09:51:56PM +1000, Chris Angelico wrote:
> On Tue, Aug 11, 2015 at 5:08 PM, Cameron Simpson  wrote:
> > On 11Aug2015 18:07, Greg Ewing  wrote:
> >>
> >> Cameron Simpson wrote:
> >>>
> >>> To illustrate, there's a consumer rights TV snow here with a segment
> >>> called "F.U. Tube", where members of the public describe ripoffs and other
> >>> product failures in video form. While a phonetic play on the name 
> >>> "YouTube",
> >>> the abbreviation also colloquially means just what you think it might. I 
> >>> can
> >>> just imagine reciting one of these new strings out loud...
> >>
> >>
> >> We could require it to be spelled "uf" unless "from __future__
> >> import billy_connolly_as_FLUFL" is in effect.
> >
> >
> > That seems like a reasoned and measured response.
> 
> Given the levels of profanity that are not disallowed in identifier
> names, I think blocking off a two-letter prefix is pretty pointless.
> It'd be different if the specification _required_ it (though even
> then, it's not that big a deal...), but merely permitting it? Not
> Python's fault.

Er, if it's not Python's doing, whose doing is it?

There's a difference between not censoring identifiers written by the 
user, and creating syntax. I don't think anyone would blame the language 
if I created an identifier "poop", say, but if the language included a 
keyword "poop" or a syntax feature, say, poop-lists:

poop[a, b, c, d]

then one might wonder what the language designers were thinking. I've 
already seen a bit of sniggering on Reddit about fu strings.

In the grand scheme of things, worrying about fu strings is pretty low 
on the list of priorities. But if there is no need to allow fu as a 
prefix, or if there is another equally good prefix to use instead of f, 
then there's no harm done by disappointing the 14 year olds.


-- 
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP-498: Literal String Formatting

[Barry Warsaw]

On Aug 10, 2015, at 11:05 PM, ISAAC J SCHWABACHER wrote:

>code.putlines(f"""
>static char {entry.doc_cname}[] = "{
>split_string_literal(escape_bytestring(docstr))}";
>
>{ # nested!
>f"""
>#if CYTHON_COMPILING_IN_CPYTHON
>struct wrapperbase {entry.wrapperbase_cname};
>#endif
>""" if entry.is_special else ''}
>
>{(lambda temp, argn: # my kingdom for a let!
>f"""
>for ({temp}=0; {temp}PyObject *item = PyTuple_GET_ITEM({argn}, {temp});
>}}""")(..., Naming.args_cname)}
>
>{self.starstar_arg.entry.cname} =
>({Naming.kwds_cname}) ? PyDict_Copy({Naming.kwds_cname})
>  : PyDict_New();
>
>if (unlikely(!{self.starstar_arg.entry.cname})) return {self.error_value()};
>""")
>
>What do others think of this PEP-498 sample?

No offense intended, but I put this in an Emacs Python buffer and it made me
want to cry.

Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP-498: Literal String Formatting

[Eric V. Smith]

On 08/10/2015 04:12 PM, Mike Miller wrote:
> Here are my notes on PEP 498.
> 
> 1. Title:  Literal String Formatting
> 
> - String Literal Formatting
> - Format String Expressions
> ?

I like "String Literal Formatting", but let me sleep on it.

> 2. Let's call them "format strings" not "f-strings".
>The latter sounds slightly obnoxious, and also inconsistent with the
>others:
> 
> r'' raw string
> u'' unicode object (string)
> f'' format string

People seem to have already started using f-strings. I think it's
inevitable.

> 3. " This PEP does not propose to remove or deprecate any of the existing
> string formatting mechanisms. "
> 
> Should we put this farther up with the section talking about them,
> it seems out of place where it is.
>

Done.

> 4. "The existing ways of formatting are either error prone, inflexible, or
> cumbersome."
> 
> I would tone this down a bit, they're not so bad, quite verbose is a
> phrase I might use instead.
> 

I'll try and tone it down.

> 5. Discussion Section
> How to designate f-strings, and how specify the locaton of expressions
> ^ typo

I already found that one. Thanks.

> 6. Perhaps mention string literal functionality, like triple quotes,
> line-ending backslashes, as MRAB mentions, in addition to the
> concatenation rules.

Good idea.

Eric.

> -Mike
> 
> 
> On 08/07/2015 06:39 PM, Eric V. Smith wrote:
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com
> 
> 

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP needed for http://bugs.python.org/issue9232 ?

[R. David Murray]

On Tue, 11 Aug 2015 18:09:34 +1200, Robert Collins  
wrote:
> So, there's  a patch on issue 9232 - allow trailing commas in function
> definitions - but there's been enough debate that I suspect we need a
> PEP.
> 
> Would love it if someone could correct me, but I'd like to be able to
> either categorically say 'no' and close the ticket, or 'yes and this
> is what needs to happen next'.

I think we might just need another round of discussion here.

I'm +1 myself.  Granted there haven't been many times I've wanted it
(functions with enough arguments to want to make it easy to add and
remove elements are a bit of a code smell), but I have wanted it (and
even used the form that is accepted) several times.  On the other hand,
the number of times when the detection of a trailing comma has revealed
a missing argument to me (Raymond's objection) has been...well, I'm
pretty sure it is zero.  Especially since it only happens *sometimes*.
Since backward compatibility says we shouldn't disallow it where it is
currently allowed, the only logical thing to do, IMO, is consistently
allow it.

(If you wanted to fix an 'oops' trailing comma syntax issue, I'd vote for
disallowing trailing commas outside of ().  The number of times I've
ended up with an unintentional tuple after converting a dictionary to a
series of assignments outnumbers both of the above :)  Note, I am *not*
suggesting doing this!)

--David
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP needed for http://bugs.python.org/issue9232 ?

[Chris Angelico]

On Wed, Aug 12, 2015 at 12:46 AM, R. David Murray  wrote:
> (If you wanted to fix an 'oops' trailing comma syntax issue, I'd vote for
> disallowing trailing commas outside of ().  The number of times I've
> ended up with an unintentional tuple after converting a dictionary to a
> series of assignments outnumbers both of the above :)  Note, I am *not*
> suggesting doing this!)

Outside of any form of bracket, I hope you mean. The ability to leave
a trailing comma on a list or dict is well worth keeping:

func = {
"+": operator.add,
"-": operator.sub,
"*": operator.mul,
"/": operator.truediv,
}

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 498 f-string: is it a preprocessor?

[Eric V. Smith]

On 08/10/2015 07:23 PM, Victor Stinner wrote:
> 
> 
> Le mardi 11 août 2015, Eric V. Smith  > a écrit :
> 
> Oops, I was thinking of going the other way (str.format -> f''). Yes, I
> think you're correct.
> 
> 
> Ah ok. 
> 
> But in any event, I don't see the distinction between calling
> str.format(), and calling each object's __format__ method. Both are
> compliant with the PEP, which doesn't specify exactly how the
> transformation is done.
> 
> 
> When I read the PEP for the first time, I understood that you
> reimplemented str.format() using the __format__() methods. So i
> understood that it's a new formatting language and it would be tricky to
> reimplement it, for example in a library providing i18n with f-string
> syntax (I'm not sure that it's feasible, it's just an example). I also
> expected many subtle differences between .format() and f-string.
> 
> In fact, f-string is quite standard and not new, it's just a compact
> syntax to call .format() (well, with some minor and acceptable subtle
> differences). For me, it's a good thing to rely on the existing
> .format() method because it's well known (no need to learn a new
> formatting language).
> 
> Maybe you should rephrase some parts of your PEP and rewrite some
> examples to say that's it's "just" a compact syntax to call .format().
> 
> --
> 
> For me, calling __format__() multiple times or format() once matters,
> for performances, because I contributed to the implementation of
> _PyUnicodeWriter. I spent a lot of time to keep good performances
> when the implementation of Unicode was rewritten for the PEP 393. With
> this PEP, writing an efficient implementation is much harder. The dummy
> benchmark is to compare Python 2.7 str.format() (bytes!) to Python 3
> str.format() (Unicode!). Users want similar performances! If I recall
> correctly, Python 3 is not bad (faster is some corner cases).
> 
> Concatenate temporary strings is less efficient Than _PyUnicodeWriter
> (single buffer) when you have UCS-1, UCS-2 and UCS-4 strings (1/2/4
> bytes per character). It's more efficient to write directly into the
> final format (UCS-1/2/4), even if you may need to convert the buffer
> from UCS-1 to UCS-2 (and maybe even one more time to UCS-4).

I think I've pinpointed what bothers me about building up a string for
str.format: You're building up a string which is then parsed, and after
it's parsed, you make the exact same function calls that you could
instead make directly.

When Mark Dickinson and I implemented short float repr we spent a lot of
time taking apart code that did things like this.

But yes, there are some optimizations in str.format dealing with both
_PyUncicodeWriter and with not calling __format__ for some builtin
types. So maybe there's a win to be had there, even with the extra
parsing that would happen.

In any event, it should be driven by testing.

That said, I now think that when handling nested f-strings:

f'value: {value:{width}}'

It will be easier to translate this to:

'value: {0:{1}s}'.format(value, width)

than:

''.join(['value: ',
  value.__format__(''.join([width.__format__(), 's']))
 ])

But I don't see any need to modify the PEP. The exact mechanism used
isn't specified. I just want the PEP to be clear that it's using the
__format__ protocol. The implementation can either do so explicitly or
via str.format, and which one might change in the future.

Eric.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP-498: Literal String Formatting

[Alexander Walters]

This may seam like a simplistic solution to i18n, but why not just add a 
method to string objects (assuming we implement f-strings) that just 
returns the original, unprocessed string.  If the string was not an 
f-string, it just returns self.  The gettext module can be modified, I 
think trivially, to use the method instead of the string directly.


Is this a horrible idea?

- Alex W.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP-498: Literal String Formatting

[Eric V. Smith]

On 08/11/2015 11:09 AM, Alexander Walters wrote:
> This may seam like a simplistic solution to i18n, but why not just add a
> method to string objects (assuming we implement f-strings) that just
> returns the original, unprocessed string.  If the string was not an
> f-string, it just returns self.  The gettext module can be modified, I
> think trivially, to use the method instead of the string directly.

You need the original string, in order to figure out what it translates
to. You need the values to replace into that string, evaluated at
runtime, in the context of where the string appears. And you need to
know where in the original (or translated) string to put them.

The problem is that there's no way to evaluate the values and, before
they're substituted in to the string, use a different template string
with obvious substitution points. This is what PEP 501 is trying to do.

Eric.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP-498: Literal String Formatting

[Wes Turner]

On Aug 11, 2015 10:10 AM, "Alexander Walters" 
wrote:
>
> This may seam like a simplistic solution to i18n, but why not just add a
method to string objects (assuming we implement f-strings) that just
returns the original, unprocessed string.  If the string was not an
f-string, it just returns self.  The gettext module can be modified, I
think trivially, to use the method instead of the string directly.
>
> Is this a horrible idea?

This is a backward compatible macro to elide code in strings that should
not be.

* IIUC, this would only be usable in 3.6+ (so, not at all and style guide
says NO)
  * there should be a normal functional() way to accomplish this in a
backwards compatible way
  * formatlng() / lookup() would be more future compatible

>
> - Alex W.
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP needed for http://bugs.python.org/issue9232 ?

[Guido van Rossum]

I don't think it needs a PEP. See my response in the issue.

On Tue, Aug 11, 2015 at 8:09 AM, Robert Collins 
wrote:

> So, there's  a patch on issue 9232 - allow trailing commas in function
> definitions - but there's been enough debate that I suspect we need a
> PEP.
>
> Would love it if someone could correct me, but I'd like to be able to
> either categorically say 'no' and close the ticket, or 'yes and this
> is what needs to happen next'.
>
> -Rob
>
> --
> Robert Collins 
> Distinguished Technologist
> HP Converged Cloud
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP-498: Literal String Formatting

[Alexander Walters]

On 8/11/2015 11:16, Eric V. Smith wrote:

On 08/11/2015 11:09 AM, Alexander Walters wrote:

This may seam like a simplistic solution to i18n, but why not just add a
method to string objects (assuming we implement f-strings) that just
returns the original, unprocessed string.  If the string was not an
f-string, it just returns self.  The gettext module can be modified, I
think trivially, to use the method instead of the string directly.

You need the original string, in order to figure out what it translates
to. You need the values to replace into that string, evaluated at
runtime, in the context of where the string appears. And you need to
know where in the original (or translated) string to put them.

The problem is that there's no way to evaluate the values and, before
they're substituted in to the string, use a different template string
with obvious substitution points. This is what PEP 501 is trying to do.

Eric.
I don't understand some of that.  We already trust translators with 
_('foo {bar}').format(bar=bar) to not mess up the {bar} in the string, 
so the that wont change.  Is the issue handing the string back to python 
to be formatted?  Could gettext not make the same AST as an f-string 
would, and hand that back to python?  If you add a method to strings 
that returns the un-f-string-processed version of the string, doesn't 
that make all these problems solvable without pep-501?

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP-498: Literal String Formatting

[Wes Turner]

On Aug 11, 2015 10:19 AM, "Wes Turner"  wrote:
>
>
> On Aug 11, 2015 10:10 AM, "Alexander Walters" 
wrote:
> >
> > This may seam like a simplistic solution to i18n, but why not just add
a method to string objects (assuming we implement f-strings) that just
returns the original, unprocessed string.  If the string was not an
f-string, it just returns self.  The gettext module can be modified, I
think trivially, to use the method instead of the string directly.
> >
> > Is this a horrible idea?

- [ ] review all string interpolation (for "injection")
  * [ ] review every '%'
  * [ ] review every ".format()"
  * [ ] review every f-string (AND LOCALS AND GLOBALS)
  * every os.system, os.exec*, subprocess.Popen
  * every unclosed tag
  * every unescaped control character

This would create work we don't need.

Solution: __str_shell_ escapes, adds slashes, and quotes. __str__SQL__ refs
a global list of reserved words.

>
> This is a backward compatible macro to elide code in strings that should
not be.
>
> * IIUC, this would only be usable in 3.6+ (so, not at all and style guide
says NO)
>   * there should be a normal functional() way to accomplish this in a
backwards compatible way
>   * formatlng() / lookup() would be more future compatible
>
> >
> > - Alex W.
> >
> > ___
> > Python-Dev mailing list
> > Python-Dev@python.org
> > https://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:
https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP needed for http://bugs.python.org/issue9232 ?

[Chris Barker - NOAA Federal]

> there's been enough debate that I suspect we need a
>> PEP.
>>
> I think we might just need another round of discussion here.

Please no :-)

Looking back at the previous discussion, it looked like it's all been
said, and there was almost unanimous approval (with some key mild
disapproval) for the idea, so what we need now is a pronouncement.

If it's unclear whether consensus was close, then folks that are
strongly against should speak up now. If there is a flurry of those,
then a PEP is in order. But another big long unstructured discussion
won't be useful.

-Chris




>
> I'm +1 myself.  Granted there haven't been many times I've wanted it
> (functions with enough arguments to want to make it easy to add and
> remove elements are a bit of a code smell), but I have wanted it (and
> even used the form that is accepted) several times.  On the other hand,
> the number of times when the detection of a trailing comma has revealed
> a missing argument to me (Raymond's objection) has been...well, I'm
> pretty sure it is zero.  Especially since it only happens *sometimes*.
> Since backward compatibility says we shouldn't disallow it where it is
> currently allowed, the only logical thing to do, IMO, is consistently
> allow it.
>
> (If you wanted to fix an 'oops' trailing comma syntax issue, I'd vote for
> disallowing trailing commas outside of ().  The number of times I've
> ended up with an unintentional tuple after converting a dictionary to a
> series of assignments outnumbers both of the above :)  Note, I am *not*
> suggesting doing this!)
>
> --David
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP needed for http://bugs.python.org/issue9232 ?

[Alexander Walters]

As a user who has banged my head against this more than once, its not a 
feature, its a bug, it does not need a pep (Guido said as much), just 
fix it.


On 8/11/2015 11:31, Chris Barker - NOAA Federal wrote:

there's been enough debate that I suspect we need a

PEP.


I think we might just need another round of discussion here.

Please no :-)

Looking back at the previous discussion, it looked like it's all been
said, and there was almost unanimous approval (with some key mild
disapproval) for the idea, so what we need now is a pronouncement.

If it's unclear whether consensus was close, then folks that are
strongly against should speak up now. If there is a flurry of those,
then a PEP is in order. But another big long unstructured discussion
won't be useful.

-Chris





I'm +1 myself.  Granted there haven't been many times I've wanted it
(functions with enough arguments to want to make it easy to add and
remove elements are a bit of a code smell), but I have wanted it (and
even used the form that is accepted) several times.  On the other hand,
the number of times when the detection of a trailing comma has revealed
a missing argument to me (Raymond's objection) has been...well, I'm
pretty sure it is zero.  Especially since it only happens *sometimes*.
Since backward compatibility says we shouldn't disallow it where it is
currently allowed, the only logical thing to do, IMO, is consistently
allow it.

(If you wanted to fix an 'oops' trailing comma syntax issue, I'd vote for
disallowing trailing commas outside of ().  The number of times I've
ended up with an unintentional tuple after converting a dictionary to a
series of assignments outnumbers both of the above :)  Note, I am *not*
suggesting doing this!)

--David
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/tritium-list%40sdamon.com


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP-498: Literal String Formatting

[Alexander Walters]

On 8/11/2015 11:28, Wes Turner wrote:



On Aug 11, 2015 10:19 AM, "Wes Turner" > wrote:


- [ ] review all string interpolation (for "injection")
  * [ ] review every '%'
  * [ ] review every ".format()"
  * [ ] review every f-string (AND LOCALS AND GLOBALS)
  * every os.system, os.exec*, subprocess.Popen
  * every unclosed tag
  * every unescaped control character

This would create work we don't need.

Solution: __str_shell_ escapes, adds slashes, and quotes. __str__SQL__ 
refs a global list of reserved words.



I don't understand why % and .format got interjected into this.

If you are mentioning them as 'get the unprocessed version of any string 
formatting', that is a bad idea, and not needed, since you already have 
an unprocessed string object.  Assuming the method were named 
"hypothetical":


>>> 'foo bar'.hypothetical()  # returns 'foo bar'
>>> '{0} bar'.format('foo').hypothetical()  # returns 'foo bar'
>>> ('%s bar' % ('foo',)).hypothetical() # returns 'foo bar'
>>> f'{foo} bar'.hypothetical() # returns '{foo} bar', prime for 
translation.


could gettext not be modified to create the same AST as f'{foo} bar' 
when it is translated to '{foo} le bar.' and inject it back into the 
runtime?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP-498: Literal String Formatting

[ISAAC J SCHWABACHER]

Now with syntax highlighting, if my email client cooperates:

code.putlines(f"""
static char {entry.doc_cname}[] = "{
split_string_literal(escape_bytestring(docstr))}";

{ # nested!
f"""
#if CYTHON_COMPILING_IN_CPYTHON
struct wrapperbase {entry.wrapperbase_cname};
#endif
""" if entry.is_special else ''}

{(lambda temp, argn: # my kingdom for a let!
f"""
for ({temp}=0; {temp} on 
behalf of Stefan Behnel 
Sent: Sunday, August 9, 2015 04:53
To: python-dev@python.org
Subject: Re: [Python-Dev] PEP-498: Literal String Formatting

Stefan Behnel schrieb am 09.08.2015 um 10:06:
> Eric V. Smith schrieb am 08.08.2015 um 03:39:
>> Following a long discussion on python-ideas, I've posted my draft of
>> PEP-498. It describes the "f-string" approach that was the subject of
>> the "Briefer string format" thread. I'm open to a better title than
>> "Literal String Formatting".
>>
>> I need to add some text to the discussion section, but I think it's in
>> reasonable shape. I have a fully working implementation that I'll get
>> around to posting somewhere this weekend.
>>
>> >>> def how_awesome(): return 'very'
>> ...
>> >>> f'f-strings are {how_awesome()} awesome!'
>> 'f-strings are very awesome!'
>>
>> I'm open to any suggestions to improve the PEP. Thanks for your feedback.
>
> [copying my comment from python-ideas here]
>
> How common is this use case, really? Almost all of the string formatting
> that I've used lately is either for logging (no help from this proposal
> here) or requires some kind of translation/i18n *before* the formatting,
> which is not helped by this proposal either.

Thinking about this some more, the "almost all" is actually wrong. This
only applies to one kind of application that I'm working on. In fact,
"almost all" of the string formatting that I use is not in those
applications but in Cython's code generator. And there's a *lot* of string
formatting in there, even though we use real templating for bigger things
already.

However, looking through the code, I cannot see this proposal being of much
help for that use case either. Many of the values that get formatted into
the strings use some kind of non-trivial expression (function calls, object
attributes, also local variables, sometimes variables with lengthy names)
that is best written out in actual code. Here are some real example snippets:

code.putln(
'static char %s[] = "%s";' % (
entry.doc_cname,
split_string_literal(escape_byte_string(docstr

if entry.is_special:
code.putln('#if CYTHON_COMPILING_IN_CPYTHON')
code.putln(
"struct wrapperbase %s;" % entry.wrapperbase_cname)
code.putln('#endif')

temp = ...
code.putln("for (%s=0; %s < PyTuple_GET_SIZE(%s); %s++) {" % (
temp, temp, Naming.args_cname, temp))
code.putln("PyObject* item = PyTuple_GET_ITEM(%s, %s);" % (
Naming.args_cname, temp))

code.put("%s = (%s) ? PyDict_Copy(%s) : PyDict_New(); " % (
self.starstar_arg.entry.cname,
Naming.kwds_cname,
Naming.kwds_cname))
code.putln("if (unlikely(!%s)) return %s;" % (
self.starstar_arg.entry.cname, self.error_value()))

We use %-formatting for historical reasons (that's all there was 15 years
ago), but I wouldn't switch to .format() because there is nothing to win
here. The "%s" etc. place holders are *very* short and do not get in the
way (as "{}" would in C code templates). Named formatting would require a
lot more space in the templates, so positional, unnamed formatting helps
readability a lot. And the value expressions used for the interpolation
tend to be expressions rather than simple variables, so keeping those
outside of the formatting strings simplifies both editing and reading.

That's the third major real-world use case for string formatting now where
this proposal doesn't help. The niche is getting smaller.

Stefan


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/ischwabacher%40wisc.edu
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP needed for http://bugs.python.org/issue9232 ?

[R. David Murray]

On Tue, 11 Aug 2015 08:31:57 -0700, Chris Barker - NOAA Federal 
 wrote:
> Looking back at the previous discussion, it looked like it's all been
> said, and there was almost unanimous approval (with some key mild
> disapproval) for the idea, so what we need now is a pronouncement.

And we got it, so done :)

--David
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] trailing commas on statements

[R. David Murray]

On Wed, 12 Aug 2015 01:03:38 +1000, Chris Angelico  wrote:
> On Wed, Aug 12, 2015 at 12:46 AM, R. David Murray  
> wrote:
> > (If you wanted to fix an 'oops' trailing comma syntax issue, I'd vote for
> > disallowing trailing commas outside of ().  The number of times I've
> > ended up with an unintentional tuple after converting a dictionary to a
> > series of assignments outnumbers both of the above :)  Note, I am *not*
> > suggesting doing this!)
> 
> Outside of any form of bracket, I hope you mean. The ability to leave
> a trailing comma on a list or dict is well worth keeping:
> 
> func = {
> "+": operator.add,
> "-": operator.sub,
> "*": operator.mul,
> "/": operator.truediv,
> }

Sorry, "trailing comma outside ()" was a shorthand for 'trailing comma
on a complete statement'.  That is, what trips me up is going from
something like:

dict(abc=1,
 foo=2,
 bar=3,
 )

to:

  abc = 1,
  foo = 2,
  bar = 3,

That is, I got rid of the dict(), but forgot to delete the commas.
(Real world examples are more complex and it is often that the
transformation gets done piecemeal and/or via cut and paste and I only
miss one or two of the commas...

But, for backward compatibility reasons, we wouldn't change it even if
everyone thought it was a good idea for some reason :)

--David
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP-498: Literal String Formatting

[Sven R. Kunze]

Couldn't you just store the original format string at some 
__format_str__ attribute at the formatted string? Just in case you need it.


x = f'{a}'

=>

x = '{}'.format(a) # or whatever it turns out to be
x.__format_str__ = '{a}'


On 11.08.2015 17:16, Eric V. Smith wrote:

On 08/11/2015 11:09 AM, Alexander Walters wrote:

This may seam like a simplistic solution to i18n, but why not just add a
method to string objects (assuming we implement f-strings) that just
returns the original, unprocessed string.  If the string was not an
f-string, it just returns self.  The gettext module can be modified, I
think trivially, to use the method instead of the string directly.

You need the original string, in order to figure out what it translates
to. You need the values to replace into that string, evaluated at
runtime, in the context of where the string appears. And you need to
know where in the original (or translated) string to put them.

The problem is that there's no way to evaluate the values and, before
they're substituted in to the string, use a different template string
with obvious substitution points. This is what PEP 501 is trying to do.

Eric.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/srkunze%40mail.de


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP-498: Literal String Formatting

[Eric V. Smith]

On 08/11/2015 01:25 PM, Sven R. Kunze wrote:
> Couldn't you just store the original format string at some
> __format_str__ attribute at the formatted string? Just in case you need it.
> 
> x = f'{a}'
> 
> =>
> 
> x = '{}'.format(a) # or whatever it turns out to be
> x.__format_str__ = '{a}'

Yes. But I think the i18n problem, as evidenced by the differences in
PEPs 498 and 501, relate to the expression evaluation, not to keeping
the original string.

But if people think that this helps the i18n problem, I suggest
proposing concrete changes to PEP 501.

Eric.

> 
> 
> On 11.08.2015 17:16, Eric V. Smith wrote:
>> On 08/11/2015 11:09 AM, Alexander Walters wrote:
>>> This may seam like a simplistic solution to i18n, but why not just add a
>>> method to string objects (assuming we implement f-strings) that just
>>> returns the original, unprocessed string.  If the string was not an
>>> f-string, it just returns self.  The gettext module can be modified, I
>>> think trivially, to use the method instead of the string directly.
>> You need the original string, in order to figure out what it translates
>> to. You need the values to replace into that string, evaluated at
>> runtime, in the context of where the string appears. And you need to
>> know where in the original (or translated) string to put them.
>>
>> The problem is that there's no way to evaluate the values and, before
>> they're substituted in to the string, use a different template string
>> with obvious substitution points. This is what PEP 501 is trying to do.
>>
>> Eric.
>>
>>
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/srkunze%40mail.de
> 
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com
> 
> 

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP-498: Literal String Formatting

[Wes Turner]

On Tue, Aug 11, 2015 at 10:52 AM, Alexander Walters  wrote:

> On 8/11/2015 11:28, Wes Turner wrote:
>
>
> On Aug 11, 2015 10:19 AM, "Wes Turner"  wrote:
>
> - [ ] review all string interpolation (for "injection")
>   * [ ] review every '%'
>   * [ ] review every ".format()"
>   * [ ] review every f-string (AND LOCALS AND GLOBALS)
>   * every os.system, os.exec*, subprocess.Popen
>   * every unclosed tag
>   * every unescaped control character
>
> This would create work we don't need.
>
> Solution: __str_shell_ escapes, adds slashes, and quotes. __str__SQL__
> refs a global list of reserved words.
>
> I don't understand why % and .format got interjected into this.
>
> If you are mentioning them as 'get the unprocessed version of any string
> formatting', that is a bad idea, and not needed, since you already have an
> unprocessed string object.  Assuming the method were named "hypothetical":
>
> >>> 'foo bar'.hypothetical()  # returns 'foo bar'
> >>> '{0} bar'.format('foo').hypothetical()  # returns 'foo bar'
> >>> ('%s bar' % ('foo',)).hypothetical() # returns 'foo bar'
> >>> f'{foo} bar'.hypothetical() # returns '{foo} bar', prime for
> translation.
>
> could gettext not be modified to create the same AST as f'{foo} bar' when
> it is translated to '{foo} le bar.' and inject it back into the runtime?
>

well, we're talking about a functional [series of] transformations on
__str__ (or __unicode__); with globals and locals,
and more-or-less a macro for eliding this (**frequently wrong** because
when is a string not part of an output format with control characters that
need to be escaped before they're interpolated in).

% and str.format, (and gettext), are the current ways to do this,
and they are also **frequently wrong** because HTML, SQL.

The risk with this additional syntax is that unescaped globals and locals
are transcluded (and/or translated);
with an explicit (combination of) string prefixes to indicate
forwards-compatible functional composition
(of usually mutable types).
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP-498: Literal String Formatting

[Mike Miller]

On 08/11/2015 06:47 AM, Eric V. Smith wrote:

2. Let's call them "format strings" not "f-strings".
The latter sounds slightly obnoxious, and also inconsistent with the
others:

 r'' raw string
 u'' unicode object (string)
 f'' format string


People seem to have already started using f-strings. I think it's
inevitable.


Sure, there's no way to ban it, that would be silly.  But, I think the 
documentation should not use it.


We don't normally say "r-strings" or "u-strings" when talking about them, it's 
not very accurate.  The letter they use isn't their important quality.


Also, avoiding the f- takes the spotlight off the part where f stands for words 
besides format.  ;)


-Mike
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP-498: Literal String Formatting

[Greg Ewing]

Stefan Behnel wrote:

Syntax highlighting and in-string expression completion should eventually
help, once IDEs support it.


Concerning that, this is going to place quite a
burden on syntax highlighters. Doing it properly
will require the ability to parse arbitrary Python
expressions, or at least match nested brackets. An
editor whose syntax hightlighting engine is based
on regular expressions could have trouble with
that.

--
Greg

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Can't import tkinter in Python 3.5.0rc1

[MRAB]

As the subject says, I'm unable to import tkinter in Python 3.5.0rc1.

The console says:

C:\Python35>python
Python 3.5.0rc1 (v3.5.0rc1:1a58b1227501, Aug 10 2015, 05:18:45) [MSC 
v.1900 64 bit (AMD64)] on win32

Type "help", "copyright", "credits" or "license" for more information.
>>> import tkinter
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Python35\lib\tkinter\__init__.py", line 35, in 
import _tkinter # If this fails your Python may not be configured 
for Tk

ImportError: DLL load failed: The specified module could not be found.


Is this a known problem?

I'm on Windows 10 Home (64-bit).
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Sorry folks, minor hiccup for Python 3.5.0rc1

[Matthias Klose]

On 08/11/2015 02:56 AM, Larry Hastings wrote:
> On 08/10/2015 05:55 PM, Larry Hastings wrote:
>> I yanked the tarballs off the release page as soon as I suspected something. 
>> I'm rebuilding the tarballs and the docs now.  If you grabbed the tarball as
>> soon as it appeared, it's slightly out of date, please re-grab.
> 
> p.s. I should have mentioned--the Mac and Windows builds should be fine.  
> They,
> unlike me, updated their tree ;-)

didn't see any follow-up message. are the source tarballs now fixed?

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] trailing commas on statements

[Chris Angelico]

On Wed, Aug 12, 2015 at 3:01 AM, R. David Murray  wrote:
> Sorry, "trailing comma outside ()" was a shorthand for 'trailing comma
> on a complete statement'.  That is, what trips me up is going from
> something like:
>
> dict(abc=1,
>  foo=2,
>  bar=3,
>  )
>
> to:
>
>   abc = 1,
>   foo = 2,
>   bar = 3,
>
> That is, I got rid of the dict(), but forgot to delete the commas.
> (Real world examples are more complex and it is often that the
> transformation gets done piecemeal and/or via cut and paste and I only
> miss one or two of the commas...
>
> But, for backward compatibility reasons, we wouldn't change it even if
> everyone thought it was a good idea for some reason :)

Sure. In that case, I agree with you completely. When I *do* want a
tuple, I'll usually be putting it inside parens, rather than just
tagging a comma on. But this can be the job of a linter.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Can't import tkinter in Python 3.5.0rc1

[MRAB]

On 2015-08-12 02:05, Steve Dower wrote:
We saw and fixed it before RC 1. I'll check whether that fix didn't 
stick, but go ahead, open an issue and assign me.


It's issue 24847.



From: MRAB 
Sent: ‎8/‎11/‎2015 17:25
To: Python-Dev 
Subject: [Python-Dev] Can't import tkinter in Python 3.5.0rc1

As the subject says, I'm unable to import tkinter in Python 3.5.0rc1.

The console says:

C:\Python35>python
Python 3.5.0rc1 (v3.5.0rc1:1a58b1227501, Aug 10 2015, 05:18:45) [MSC
v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
 >>> import tkinter
Traceback (most recent call last):
   File "", line 1, in 
   File "C:\Python35\lib\tkinter\__init__.py", line 35, in 
 import _tkinter # If this fails your Python may not be configured
for Tk
ImportError: DLL load failed: The specified module could not be found.


Is this a known problem?

I'm on Windows 10 Home (64-bit).


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Can't import tkinter in Python 3.5.0rc1

[Steve Dower]

We saw and fixed it before RC 1. I'll check whether that fix didn't stick, but 
go ahead, open an issue and assign me.

Cheers,
Steve

Top-posted from my Windows Phone

From: MRAB
Sent: ‎8/‎11/‎2015 17:25
To: Python-Dev
Subject: [Python-Dev] Can't import tkinter in Python 3.5.0rc1

As the subject says, I'm unable to import tkinter in Python 3.5.0rc1.

The console says:

C:\Python35>python
Python 3.5.0rc1 (v3.5.0rc1:1a58b1227501, Aug 10 2015, 05:18:45) [MSC
v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
 >>> import tkinter
Traceback (most recent call last):
   File "", line 1, in 
   File "C:\Python35\lib\tkinter\__init__.py", line 35, in 
 import _tkinter # If this fails your Python may not be configured
for Tk
ImportError: DLL load failed: The specified module could not be found.


Is this a known problem?

I'm on Windows 10 Home (64-bit).
___
Python-Dev mailing list
Python-Dev@python.org
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmail.python.org%2fmailman%2flistinfo%2fpython-dev&data=01%7c01%7csteve.dower%40microsoft.com%7c6db05dc594c0495f007508d2a2ac89c8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ylL27LiF2rTZ4WNvxI794J1I6KSmTMtmbJUw6MdRJ8o%3d
Unsubscribe: 
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmail.python.org%2fmailman%2foptions%2fpython-dev%2fsteve.dower%2540microsoft.com&data=01%7c01%7csteve.dower%40microsoft.com%7c6db05dc594c0495f007508d2a2ac89c8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=PDN11uxJyULACi3dsE3eWU4f3e01mdNKNE3ERUw01Jc%3d
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Sorry folks, minor hiccup for Python 3.5.0rc1

[Larry Hastings]

On 08/11/2015 05:29 PM, Matthias Klose wrote:

On 08/11/2015 02:56 AM, Larry Hastings wrote:

On 08/10/2015 05:55 PM, Larry Hastings wrote:

I yanked the tarballs off the release page as soon as I suspected something.
I'm rebuilding the tarballs and the docs now.  If you grabbed the tarball as
soon as it appeared, it's slightly out of date, please re-grab.

p.s. I should have mentioned--the Mac and Windows builds should be fine.  They,
unlike me, updated their tree ;-)

didn't see any follow-up message. are the source tarballs now fixed?



Yes.  I deleted the tarballs as soon as I detected a problem; I only 
re-uploaded them once everything is correct.  They were fixed within an 
hour if I remember correctly.  The correct .tgz has md5 sum 
7ef9c440b863dc19a4c9fed55c3e9093, and the correct .tar.xz has md5 sum 
984540f202abc9305435df321c91720c.



//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com