gmane.comp.python.ideas

Re: Let's be more orderly!

Haoyi Li — 2013-05-19T02:13:12

Forgive me if this has been mentioned before (i don't think it has) but how
about an option somehow to take the list of **kwargs as an
association-list? I am approaching this from a point of view of "why am I
putting everything into a hashmap just to iterate over it later", as you
can see in the way the namedtuple constructor is implemented:

http://docs.python.org/2/library/collections.html#namedtuple-factory-function-for-tuples-with-named-fields

This may be rather out-there, and I'm not sure if it'll speed things up
much, but I'm guessing iterating over an assoc list is faster than
iterating over anything else. Building an assoc list is also probably
faster than building anything else and it's also the most easily
convertible (either to OrderedDict or unordered dict) since it preserves
all information.

-Haoyi


On Fri, May 17, 2013 at 5:07 AM, Steven D'Aprano <steve-iDnA/YwAAsAk+I/owrrOrA< at >public.gmane.org>wrote:

_______________________________________________
Python-ideas mailing list
Python-ideas-+ZN9A

Re: Implicit string literal concatenation consideredharmful (options)

Ron Adam — 2013-05-18T22:20:55


On 05/18/2013 03:58 PM, Steven D'Aprano wrote:

Correct, there isn't a very strong consensus for the removal.  But the 
discussion has been focused more on a replacement than on a eventual future 
removal down the road.

If it was to be removed (as I said), there is a strong consensus for some 
sort of an explicit variation to replace it.  But there isn't any agreement 
on how to do that.

The discussion is split between not removing it and removing it with some 
sort of replacement.  We need to know how many people are ok with removing 
it even if a replacement is not found.  (It doesn't mean one won't be found.)


it is only that some of the people supporting the removal



I agree.




LOL.. Yes quirky.  Definitely not the cheese.   ;-)



Correct, and is why I believe we should start the process... with the 
intention of doing it in python 4 or possibly earlier if there is support 
for doing it sooner.  (I had put that in, but it got edited out.)

Any way, this is my vote.



I agree with this also.  I

Re: Implicit string literal concatenation considered harmful (options)

Steven D'Aprano — 2013-05-18T20:58:05


I don't think there is. From what I have seen, there have been nearly as many people objecting to the proposed removal as there have been people supporting it, it is only that some of the people supporting the removal are more vocal, proposing alternative after alternative, none of which are particularly nice. Single dot, ellipsis, yet another string prefix c'', forced backslashes, ampersand... Have I missed any?




They might be related, but they are orthogonal. We could change one, or the other, or both, or neither. There are virtues to changing the behaviour of \ line concatenation independent of any changes made to strings.



Do you mean "quirky"? Quarky would mean "like quark(s)", which could refer to something being like a type of German cream cheese, or possibly like fundamental subatomic particles that make up protons and neutrons.




We can't just "remove implicit concatenation", because that will break code which is currently working perfectly. And probably it will break more working code than

Re: Implicit string literal concatenation considered harmful?

Steven D'Aprano — 2013-05-18T20:35:29

[...]


Actually, no, his error was inside a function call, and he was getting a TypeError of one too few arguments:

     [quote]
     I got a mysterious argument count error because instead of
     foo('a', 'b') I had written foo('a' 'b').
     [end quote]




I think that in a realistic example, this sort of error is less likely than it might appear from such a trivial example. Normally you don't just create a string and do nothing with it. Here's an example from my own code:

         standardMsg = (
             "actual and expected sequences differ in length; expected %d"
             " items but found %d." % (len(expected), len(actual))
             )
         msg = self._formatMessage(msg, standardMsg)

If I were to accidentally insert an unwanted comma in the middle of the concatenation, I would find out immediately.

Python performs very little compile-time checking for you, and that's a virtue. The cost of this is that if you type something you didn't want, Python will do it for you regardless, an

Implicit string literal concatenation consideredharmful (options)

Ron Adam — 2013-05-18T18:16:29


On 05/17/2013 04:41 PM, rurpy-/E1597aS9LQAvxtiuMwx3w< at >public.gmane.org wrote:

If we didn't have implicit string concatenation, I'd probably write it with 
each part on a separate line to make it easier to read.

     pattern = '[^\uFF1B\u30FB\u3001' \
               + r'+:=.,\/\[\]\t\r\n]+' \
               + '[\#\uFF03]+'


I think in this case the strings are joined at compile time as Guido 
suggested in is post.

You could also write it as...

pattern = ('[^\uFF1B\u30FB\u3001' +
            r'+:=.,\/\[\]\t\r\n]+' +
            '[\#\uFF03]+')

If implicit string concatenation is removed, it would be nice if there was 
an explicit replacement for it.  There is a strong consensus for doing it, 
but there isn't strong consensus on how to do it.



About line continuations:

Line continuations are a related issue to string concatenations because 
they are used together fairly often.

The line continuation behaviour is a bit quarky, but not in any critical 
way.  There has even been a PEP to remove it in pyth

Re: Implicit string literal concatenation considered harmful?

2013-05-17T21:41:34


On Friday, May 17, 2013 8:14:39 AM UTC-6, Ron Adam wrote:


"Can't" is an unrealistically high a bar but I posted a real example at
  http://mail.python.org/pipermail/python-ideas/2013-May/020847.html
that is *better* written IMO as adjacently-concatenated string literals.

_______________________________________________
Python-ideas mailing list
Python-ideas-+ZN9ApsXKcEdnm+yROfE0A< at >public.gmane.org
http://mail.python.org/mailman/listinfo/python-ideas

Re: Allowing comments after line continuations

Bruce Leban — 2013-05-17T21:04:08


\ is not only an escape character as you define it. Sometimes it means the
exact opposite of that: the following character has special meaning, e.g.,
\n \t etc.

And it is also not the case that \ only applies to the single following
character. \123 is a four-character escape sequence, \u1234 is a
six-character sequence and \U12345678 is a ten-character sequence! (And
Python is not the only language that recognizes long escape sequences.)

So in this case, while the current escape sequence is \<newline>, the new
proposed one is

\<whitespace-other-than-newline>*[#<anything-but-newline>*]<newline>


Or writing this in the style used in the python docs:

"\" *whitespace**-other-than-newline* * [ "#" *anything-but-newline* * ] *
newline*


I understand if you disagree with the proposal. But I don't think an
argument that it is fundamentally ill-defined and ignorant of history is
valid.

--- Bruce
Latest blog post: Alice's Puzzle Page http://www.vroospeak.com
Learn how hackers think: http://j.mp/gruyere-securi

Re: sqlite3

M.-A. Lemburg — 2013-05-17T20:44:47

Right, and that will need a new Python module (or at least one
that also supports SQLite 4):

http://sqlite.org/src4/doc/trunk/www/porting.wiki

According to the wiki, it is intended to be used as alternative
to SQLite 3, not as replacement:

http://sqlite.org/src4/doc/trunk/www/design.wiki

Re: Allowing comments after line continuations

Terry Jan Reedy — 2013-05-17T20:34:54


Python never requires trailing whitespace, so there never a need for 
trailing white space (except possibly within a multi-line string) and 
therefore no need (with the exection above) of getting into the habit of 
adding whitespace. Decent programming editors should have a means to 
strip trailing whitespace (Idle does)*. Run that (a good habit) and 
'xys\ ' is fixed. The Python repository now rejects (new) code with 
trailing whitespace.

Idle's Strip Trailing Whitespace does so on all lines, even if part of a 
multiline string. That may or may not be what one wants. To avoid the 
stripping, appending '\n\' to the line -- which also makes the 
whitespace visible and the intention clear.

s = '''abd \n\
efg'''
print(s)
# produces
abd
efg
(move cursor to detect space after d)

--
Terry Jan Reedy

Re: sqlite3

Markus — 2013-05-17T20:33:29

Please consider sqlite will come in version 4 some day -
http://sqlite.org/src4/doc/trunk/www/index.wiki

--
Markus

Re: Allowing comments after line continuations

Terry Jan Reedy — 2013-05-17T20:06:30

Yes, it is a rather imperious opinion ;-)


'Escape' means 'ignore the normal meaning of the following character'.
That is exactly what \<newline> means. 'Excape' had that meaning long 
before there were python string literals. Ditto for the use of \ as an 
escape character, as in relational expressions. Relational expressions 
are typically not quoted, and the fact that they are in Python code, to 
first turn them into string objects rather than pattern objects, is a 
nuisance that lead to the r prefix hack.

Do you really think Guido just coincidentally choose \ to escape 
newline, ignorant of its two decade history in unix?

Anyway, this is all moot unless the syntax is changed in a way that 
forces a different interpretation. I don't think that is needed.

Terry

Re: Implicit string literal concatenation considered harmful?

2013-05-17T17:14:15

And here's a non-contrived one (almost) verbatim from 
working code:

 pattern = '[^\uFF1B\u30FB\u3001' r'+:=.,\/\[\]\t\r\n]+' '[\#\uFF03]+'

In Python 2 this had been:

 pattern = ur'[^\uFF1B\u30FB\u3001+:=.,\/\[\]\t\r\n]+[\#\uFF03]+'

but was changed to first form above due to Python 3's 
removal of lexical evaluation of \u literals in raw 
strings (see http://bugs.python.org/issue14973).

Obviously the concatenation could have been done with
the + operator but I felt the given form was clearer
than trying to visually get whether any particular "+" 
was inside or outside of a string.  There are other 
more complex regex with more +'s and my preference is 
to adopt a particular form I can use for most/all such 
rather than to tweak forms based on a particular 
string's content.

I am assuming this discussion is regarding a possible 
Python 4 feature -- adjacent string literal concatenation 
has been documented behavior of Python going back to at
least version 1.4.0 (the earliest doc available on 
python.or

Re: Implicit string literal concatenation consideredharmful?

Jim Jewett — 2013-05-17T18:23:33


In theory.  In practice, the times when I'm having trouble fitting
something onto a single line *and* cannot find a good place to break
it (using parens), the problem almost always involves a string.

And the number of times I needed to concatenate two strings on the
same line (but wasn't willing to use a +) has been ... only when when
a seemingly arbitrary syntax restriction requires a literal string --
basically, when writing a docstring.





Today, (if you're not writing a docstring) you can write

    "abcd"
    "efgh"

and it magically turns into "abcdefgh".  He proposes that -- eventually --
you would have to write

    "abcd" \
    "efgh"

so that the \ would be an explicit indicator that you were continuing
the line, and hadn't just forgotten a comma.


I understand "create a string demonstrating all the quoting conventions".
I don't understand why an explicit + is so bad in that case.  Nor do I
understand what would be so horrible about breaking the physical line
there.

So the only use I know ab

Re: Implicit string literal concatenation consideredharmful?

Chris Angelico — 2013-05-17T17:12:57

Ahh, true. Good point. I guess literals follow slightly different
rules. Still, I don't like the idea of:

"hello" . "world"

not being an operator. Removing all the whitespace doesn't help, since
this notation is specifically about line continuation.

ChrisA

Re: Implicit string literal concatenation consideredharmful?

Chris Kaynor — 2013-05-17T17:07:49



Just to point out that the "." is already overloaded in some cases in
Python. Take a look at this literal: 1.2
Surely, that should mean the 2 attribute of the integer 1, correct?
_______________________________________________
Python-ideas mailing list
Python-ideas-+ZN9ApsXKcEdnm+yROfE0A< at >public.gmane.org
http://mail.python.org/mailman/listinfo/python-ideas

Re: Implicit string literal concatenation consideredharmful?

Ron Adam — 2013-05-17T14:14:39


On 05/17/2013 06:41 AM, Steven D'Aprano wrote:

Can you think of, or find an example of two adjacent strings on the same 
line that can't be written as a single string?

     s = "Label:\t Data containing \ backslashes"

I'm curious about how much of a problem not having implicit string 
concatenations really is?



This is why they are trying to find an explicit alternative.



But it is also a source of errors which appears to happen often enough, or 
is annoying enough, to be worth changing.

Guido's example was a situation where a comma was left out and two strings 
were joined inside a list without an error message.

If you accidentally put a comma in a multi line expression inside 
parentheses, it becomes a tuple without an error message.

 >>> ('abc'
... 'def',
... 'ghi')
('abcdef', 'ghi')


By removing implicit string concatenations, an error can be raised in some 
of these situations.  The fact that these errors are silent and may not be 
noticed until a programs actually used is an important part

Re: Implicit string literal concatenation considered harmful?

Steven D'Aprano — 2013-05-17T11:41:44


They clearly should be in different threads. Line continuation is orthogonal to string continuation. You can have string concatenation on a single line:

s = "Label:\t" r"Data containing \ backslashes"


And you can have line continuations not involving strings:

result = math.sin(23*theta) + cos(17*theta) - \
     sin(3*theta**2)*cos(5*theta**3)


Since the two things under discussion are independent, they should be discussed in different threads.



-1

Implicit string concatenation is useful, and used by many people without problems.



+0

It's not really that important these days. If you want comments, use brackets to group a multi-line expression.



I don't understand what this sentence means.



The backslashes are redundant, since the square brackets already enable a multi-line expression.




-1 since there are uses for concatenating strings on a single line.



I don't understand this objection, since the parentheses are being used to group an expression.
And they are being used to group express

Re: Implicit string literal concatenation consideredharmful?

Chris Angelico — 2013-05-17T11:09:53

One of the things I love about Python is that a "thing" can be used in
the same ways whether it's from a literal, a variable/name lookup, a
function return value, a class member, an instance member, etc, etc,
etc. (Sometimes this requires strange magic, like member function
calling, but you still have the principle that "a=foo.bar(quux)" and
"_=foo.bar; a=_(quux)" do the same thing.) So anything that makes
str.str mean something weird gets a -1 from me. The proposals
involving ellipsis have at least the virtue that it's clearly a
syntactic element and not an operator, but I suspect the syntax will
be more problematic than useful.

If it looks like an operator, it should BE an operator.

ChrisA

Re: Implicit string literal concatenation consideredharmful?

Joao S. O. Bueno — 2013-05-17T09:55:20

But you are suggesting it should be string concatenation.
It is already in use for attribute access, as you can see -
and one writting a program, or reading one should not
have to be thinking """ah - but here I can't use the "." because
I am concatenating a string in a variable, not  a literal
string""""



What is that? One thing that works in a way for literals and
in another way for expressions?
Sorry, but there is onlye one word for this: Insanity!

Re: Implicit string literal concatenation consideredharmful?

Vernon D. Cole — 2013-05-17T09:37:17

where the literals ended and started.

s = "'Aren't you supposed to be " ... '"working"?' ... "', he asked with a
wink."

Is easier to read and understand. So is:

s = "'Aren't you supposed to be " + '"working"?' + "', he asked with a
wink."

Which works today, if you don't mind doing it at run time. You can also use:

s = """'Aren't you supposed to be "working"? ', he asked with a wink."""

Which also works fine, although the triple-double single-single combination
is a bit frightening to look at.
--
Vernon Cole
_______________________________________________
Python-ideas mailing list
Python-ideas-+ZN9ApsXKcEdnm+yROfE0A< at >public.gmane.org
http://mail.python.org/mailman/listinfo/python-ideas

Re: Allowing comments after line continuations

Serhiy Storchaka — 2013-05-17T09:37:02

16.05.13 21:41, Bruce Leban написав(ла):

I'm strong -1 on "\" line continuation working after comment. This is 
backward incompatible, contr-intuitive (it expected meaning that a 
comment continues on the next line) and error-prone (placing "#" at the 
start of line is used just to temporary exclude some fragment of code).

I'm -0.5 on allowing comments after "\" line continuation. This 
complicates parser (and the one in human mind) and looks contrary to all 
other languages which use "\" for line continuation.

I'm only -0.1 on allowing spaces after "\" line continuation. While "\ " 
causes SyntaxError at compile time it is not an issue. And trailing 
whitespaces should be avoided in any cases, after "\" or not.


_______________________________________________
Python-ideas mailing list
Python-ideas< at >python.org
http://mail.python.org/mailman/listinfo/python-ideas