Re: Most probably a stupid question, but I still want to ask

[Marko Rauhamaa]

Terry Reedy :

> On 4/10/2016 8:17 PM, Fillmore wrote:
>
>> apparently my 'discontinuity' is mappable to the fact that there's no
>> such thing as one-element tuples in Python, and attempts to create
>> one will result in a string (i.e. an object of a different kind!)...
>
> Please work through the tutorial before posting wrong information
> about the basics of Python.
>
 t = 1,
 t
> (1,)

However, in some languages, one-dimensional vectors/tuples and scalars
are treated as equivalent (at least APL and Scheme).


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Most probably a stupid question, but I still want to ask

[Stephen Hansen]

On Sun, Apr 10, 2016, at 10:18 PM, Rustom Mody wrote:
> On Monday, April 11, 2016 at 10:17:13 AM UTC+5:30, Stephen Hansen wrote:
> > On Sun, Apr 10, 2016, at 09:03 PM, Fillmore wrote:
> > > and the (almost always to be avoided) use of eval()
> > 
> > FWIW, there's ast.literal_eval which is safe and there's no reason to
> > avoid it.
> 
> Its error reporting is clunky:
> 
> >>> from ast import literal_eval as le
> >>> le("(1)")
> 1
> >>> le("(1,)")
> (1,)
> >>> le("1")
> 1
> >>> le("{1:x}")
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python2.7/ast.py", line 80, in literal_eval
> return _convert(node_or_string)
>   File "/usr/lib/python2.7/ast.py", line 63, in _convert
> in zip(node.keys, node.values))
>   File "/usr/lib/python2.7/ast.py", line 62, in 
> return dict((_convert(k), _convert(v)) for k, v
>   File "/usr/lib/python2.7/ast.py", line 79, in _convert
> raise ValueError('malformed string')
> ValueError: malformed string

So? Worst case scenario, someone puts invalid data into the file and it
throws an exception. Could it be more specific? Maybe, but I don't see
why it needs to be. If your input isn't reliably formatted, catch
ValueError and log it and fix (either what wrote it or change how you
read it).

--S
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: one-element tuples

[Ben Finney]

Fillmore  writes:

> I thought I had made the point clear with the REPL session below. I
> had (what seemed to me like) a list of strings getting turned into a
> tuple. I was surprised that a single string wasn't turned into a
> single-element tuple.

Sure. What about the corresponding one from my example:

>>> a = "string1"
>>> b = "string1", "string2"
>>> c = "string1", "string2", "string3"

>>> type(a)

>>> type(b)

>>> type(c)


Isn't that just as surprising as the same expressions evaluated with
‘eval’?

If not, that's what is confusing me. I can't see how one would be
expected, but the other would be surprising.

-- 
 \  “It is well to remember that the entire universe, with one |
  `\   trifling exception, is composed of others.” —John Andrew Holmes |
_o__)  |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue26200] SETREF adds unnecessary work in some cases

[Raymond Hettinger]

Raymond Hettinger added the comment:

Thank you.  Can this be closed now?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Parens do create a tuple

[Random832]

On Mon, Apr 11, 2016, at 00:08, Steven D'Aprano wrote:
> Should we say that the / and - operators therefore create tuples? I don't
> think so.

But I am talking about the tuple that is passed to FunctionType.__call__
at runtime, not a tuple created within some parser stage.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Most probably a stupid question, but I still want to ask

[Rustom Mody]

On Monday, April 11, 2016 at 10:17:13 AM UTC+5:30, Stephen Hansen wrote:
> On Sun, Apr 10, 2016, at 09:03 PM, Fillmore wrote:
> > and the (almost always to be avoided) use of eval()
> 
> FWIW, there's ast.literal_eval which is safe and there's no reason to
> avoid it.

Its error reporting is clunky:

>>> from ast import literal_eval as le
>>> le("(1)")
1
>>> le("(1,)")
(1,)
>>> le("1")
1
>>> le("{1:x}")
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/ast.py", line 80, in literal_eval
return _convert(node_or_string)
  File "/usr/lib/python2.7/ast.py", line 63, in _convert
in zip(node.keys, node.values))
  File "/usr/lib/python2.7/ast.py", line 62, in 
return dict((_convert(k), _convert(v)) for k, v
  File "/usr/lib/python2.7/ast.py", line 79, in _convert
raise ValueError('malformed string')
ValueError: malformed string


> You'll still have to deal with the fact that a single string
> on a line will return a string while multiples will return a tuple, but
> how you're doing that (checking the type of the result) is fine.

Yes...
0 and 1 length tuples are special cases even if we argue till we are blue in 
the face

To Fillmore:

Go via lists and the special cases can be obviated:
>>> def br(s): return "[" + s + "]"
>>> s0=""
>>> s1="1"
>>> s2="1,2"
>>> le(br(s0))
[]
>>> le(br(s1))
[1]
>>> le(br(s2))
[1,2]

Then tuplify (if you so wish)
>>> tuple(le(br(s0)))
()
>>> tuple(le(br(s1)))
(1,)
>>> tuple(le(br(s2)))
(1, 2)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Moderation and Usenet

[Tim Golden]

On 11/04/2016 04:32, Mario R. Osorio wrote:

hmmm...He made an extremely kind comment a couple of days ago. It
called my attention because is the first one ever (coming from) ...
Now I'm thinking he might have just been sarcastic.


Give him the benefit of the doubt.


And BTW I myself have given a couple of sour responses every now and
then. I guess we all have our bad days or moments. It's just that
Mark's are much too often.



I'm not going to discuss any individual's behaviour here. But to 
reiterate what I said either earlier in this thread or elsewhere: we're 
not interested in jumping down someone's throat because they lost their 
cool for a moment. Or because they once said something in a way which 
someone else considered too forceful.


We're more concerned with the overall effect a series of postings has on 
other list/newsgroup members. If the list/newsgroup becomes an 
unpleasant or uncomfortable place because one person is aggressive or 
rude often enough, then we need to step in.


Of course, other members of the list/community are free to do so, as 
they sometimes do, and point out to a poster where something was 
unnecessarily blunt or even outright offensive. Thus giving that person 
the opportunity to retract or apologise if they wish.


TJG
--
https://mail.python.org/mailman/listinfo/python-list

Re: one-element tuples

[Rustom Mody]

On Monday, April 11, 2016 at 9:45:20 AM UTC+5:30, Ben Finney wrote:
> Clearly there is something of interest here. I'd like to know what the
> facts of the matter were; "beginner's mind" is a precious resource, not
> to be squandered.

That's one sensible statement in a more than usually messed up thread
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: one-element tuples

[Stephen Hansen]

On Sun, Apr 10, 2016, at 09:43 PM, Fillmore wrote:
> I thought I had made the point clear with the REPL session below. 

Considering how many people expressed repeatedly they didn't know what
was surprising, it wasn't clear at all. 

In general you need to explain these things with your words: code is
good, show code, don't get me wrong, but you need to express your
expectations and how the difference between what happened and what you
expected surprised you.

Both parts, the code and the expression of your thoughts, are really
important to getting help around here :) 

---
Stephen Hansen
  m e @ i x o k a i . i o
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Most probably a stupid question, but I still want to ask

[Stephen Hansen]

On Sun, Apr 10, 2016, at 09:03 PM, Fillmore wrote:
> and the (almost always to be avoided) use of eval()

FWIW, there's ast.literal_eval which is safe and there's no reason to
avoid it. You'll still have to deal with the fact that a single string
on a line will return a string while multiples will return a tuple, but
how you're doing that (checking the type of the result) is fine.

--Stephen
m e @ i x o k a i . i o
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: one-element tuples

[Fillmore]

On 04/11/2016 12:10 AM, Ben Finney wrote:


So, will we never get your statement of what surprised you between those
examples?

Clearly there is something of interest here. I'd like to know what the
facts of the matter were; “beginner's mind” is a precious resource, not
to be squandered.



I thought I had made the point clear with the REPL session below. I had (what 
seemed
to me like) a list of strings getting turned into a tuple. I was surprised that
a single string wasn't turned into a single-element tuple.
Now that I know that commas create tuples, but lack of commas don't, I'm not 
surprised anymore.

>>> a = '"string1"'
>>> b = '"string1","string2"'
>>> c = '"string1","string2","string3"'
>>> ea = eval(a)
>>> eb = eval(b)
>>> ec = eval(c)
>>> type(ea)

>>> type(eb)

>>> type(ec)


--
https://mail.python.org/mailman/listinfo/python-list

Re: one-element tuples

[Ben Finney]

Fillmore  writes:

> On 04/10/2016 09:36 PM, Ben Finney wrote:
> > If the two examples give you different responses (one surprises you, the
> > other does not), I would really like to know*what the surprise is*.
> > What specifically did you expect, that did not happen?
>
> now that I get the role of commas it's not surprising anymore...

So, will we never get your statement of what surprised you between those
examples?

Clearly there is something of interest here. I'd like to know what the
facts of the matter were; “beginner's mind” is a precious resource, not
to be squandered.

-- 
 \   “My business is to teach my aspirations to conform themselves |
  `\  to fact, not to try and make facts harmonise with my |
_o__)   aspirations.“ —Thomas Henry Huxley, 1860-09-23 |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Parens do create a tuple

[Steven D'Aprano]

On Mon, 11 Apr 2016 12:51 pm, Random832 wrote:

> On Sun, Apr 10, 2016, at 22:32, Steven D'Aprano wrote:
>> def func(arg1, arg2, arg3):
>> pass
>> 
>> func(1, 2, 3)
>> 
>> does not create a tuple (1, 2, 3) anywhere in its execution.
> 
> Well, the second argument to PyObject_Call and function_call is a tuple,
> which had to come from somewhere.

It didn't come from any Python language feature. It is a purely internal
implementation detail.

Let me put it this way: a Python expression like 3/x-1 may be parsed into a
abstract syntax tree which might look something like this:

(OPERATOR, -, 
  (OPERATOR, /, 
(CONSTANT, 3, None, None), 
(NAME, 'x', None, None)), 
  (CONSTANT, 1, None, None)
  )


Should we say that the / and - operators therefore create tuples? I don't
think so.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Parens do create a tuple

[Ben Finney]

Steven D'Aprano  writes:

> On Mon, 11 Apr 2016 11:41 am, Ben Finney wrote:
>
> > Chris Angelico  writes:
> > 
> >> Fair enough. Let's instead say "commas create tuples", which is true
> >> in all cases except the singleton empty tuple. Is that near enough
> >> that we can avoid the detail?
> > 
> > It's a fine thing to say, because it's simply true. Commas create
> > tuples.
>
> […] there are commas that don't create a tuple.

Of course. That doesn't make the above statement false.

Commas create tuples. Also, commas do other things.

-- 
 \   “Faith, n. Belief without evidence in what is told by one who |
  `\   speaks without knowledge, of things without parallel.” —Ambrose |
_o__)   Bierce, _The Devil's Dictionary_, 1906 |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Most probably a stupid question, but I still want to ask

[Fillmore]

On 04/10/2016 11:54 PM, Steven D'Aprano wrote:

On Mon, 11 Apr 2016 12:48 pm, Fillmore wrote:



funny, but it seems to me that you are taking it personally... thank god i
even apologized in advance for what was most probably a stupid question..


I hope you did get a laugh out of it, because it wasn't meant to be nasty.
But it was meant to get you to think about statements about betraying
principles and other inflammatory remarks.


I did have a laugh.

I don't think I talked about betraying principles. I just mentioned that in my 
newbie
mind, I experienced what I perceived as a discontinuity. My limited 
understanding of
what builds tuples and the (almost always to be avoided) use of eval() were the 
origin
of my perplexities.

I'll make sure I approach the temple of pythonistas bare-footed and with 
greater humility next time




--
https://mail.python.org/mailman/listinfo/python-list

[issue26585] Use html.escape to replace _quote_html in http.server

[Martin Panter]

Martin Panter added the comment:

Thanks for the patch Xiang

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Most probably a stupid question, but I still want to ask

[Steven D'Aprano]

On Mon, 11 Apr 2016 12:48 pm, Fillmore wrote:

> 
> funny, but it seems to me that you are taking it personally... thank god i
> even apologized in advance for what was most probably a stupid question..

I hope you did get a laugh out of it, because it wasn't meant to be nasty.
But it was meant to get you to think about statements about betraying
principles and other inflammatory remarks.


-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue24291] wsgiref.handlers.SimpleHandler truncates large output blobs

[Martin Panter]

Martin Panter added the comment:

In patch v2 I integrated a version of the test into test_wsgiref. I swapped the 
sleep() calls for a threading.Event object.

Because my patch is such a large change, it would be good to get other people’s 
opinions or reviews.

--
Added file: http://bugs.python.org/file42427/wfile-partial.v2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Moderation and Usenet

[Mario R. Osorio]

On Sunday, April 10, 2016 at 2:01:00 PM UTC-4, Terry Reedy wrote:
> On 4/10/2016 1:05 PM, Ethan Furman wrote:
> 
> > If you see offensive posts from him  on the Usenet side please do not
> > respond.
> 
> Just a reminder for those who, like me, prefer a newsgroup interface for 
> python-list: gmane.comp.python.general at news.gmane.org mirrors the 
> moderated output of python-list.  (Gmane does the same for 1000s of 
> tecnhical lists.)  I believe that posts submitted from gmane are sent to 
> the list *first*, and never appear on the gmane mirror until they appear 
> on the list.  Thus one will not see and cannot accidentally respond to a 
> post that did not appear on the list.  One gets the benefits of list 
> moderation without a flooded mailbox.
> 
> -- 
> Terry Jan Reedy
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Unacceptable behavior

[Jeff Schumaker]

On Sunday, April 10, 2016 at 9:33:47 PM UTC-4, Jeff Schumaker wrote:
> On Sunday, April 10, 2016 at 10:03:37 AM UTC-4, Chris Angelico wrote:
> > On Sun, Apr 10, 2016 at 11:54 PM, Jeff Schumaker wrote
> 
> > > As a new member of this group, I am not sure on how to report 
> > > unacceptable behavior. If this is not the correct way, I apologize.
> > >
> > > Please check the following thread:
> > >
> > > Find the number of robots needed to walk through the rectangular grid
> > >
> > > I believe there was some unnecessary rudeness on the part of one of the 
> > > respondants to the original post
> > 
> > My guess is you're talking about Mark Lawrence, and yes, I agree; he's
> > been fairly vitriolic.
> > 
> > The standard way to report abusive behaviour on mailing lists is to
> > contact the owner. 
> > 
> > ChrisA
> 
> No, this was a different poster. And, thanks, Chris, for the email address. I 
> will give it a shot.
> 
> Jeff

I reread the thread. It was Mark. I mixed him up with the Thomas that was the 
person mentioned at the beginning of this thread. 

Jeff
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Moderation and Usenet

[Mario R. Osorio]

hmmm...He made an extremely kind comment a couple of days ago. It called my 
attention because is the first one ever (coming from) ... Now I'm thinking he 
might have just been sarcastic.

And BTW I myself have given a couple of sour responses every now and then. I 
guess we all have our bad days or moments. It's just that Mark's are much too 
often.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue25187] bdist_rpm fails due to wrong hardcoded assumption about RPM filename format

[David Ward]

David Ward added the comment:

Ping to review patch please...

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: one-element tuples

[Fillmore]

Thank you for trying to help, Martin. So:

On 04/10/2016 09:08 PM, Martin A. Brown wrote:

#1: I would not choose eval() except when there is no other
 solution.  If you don't need eval(), it may save you some
 headache in the future, as well, to find an alternate way.
 So, can we help you choose something other than eval()?
 What are you trying to do with that usage?


so, I do not quite control the format of the file I am trying to parse.

it has the format:

"str1","str2",,"strN" => more stuff
  :

in some cases there is just one "str" which is what created me problem.
The first "str1" has special meaning and, at times, it can be alone.

The way I handle this is:

parts = line.strip().split(" => ")
tokens = eval(parts[0])

if type(tokens) == str:   #Handle case that there's only one token
columns.add(tokens)
rowTokenString = "__Empty__"
rows.add(rowTokenString)
value = parts[1][:2]
addCell(table, rowTokenString, tokens, value)
else:
columns.add(tokens[0])
rowTokenString = '"'+'","'.join(tokens[1:]) + '"'
rows.add(rowTokenString)
value = parts[1][:2]
addCell(table, rowTokenString, tokens[0],value)

which admittedly is not very elegant. If you have suggestions on how to avoid 
the use
of eval() and still achieve the same, I would be delighted to hear them


--
https://mail.python.org/mailman/listinfo/python-list

Re: Parens do create a tuple

[Chris Angelico]

On Mon, Apr 11, 2016 at 12:51 PM, Random832  wrote:
> On Sun, Apr 10, 2016, at 22:32, Steven D'Aprano wrote:
>> def func(arg1, arg2, arg3):
>> pass
>>
>> func(1, 2, 3)
>>
>> does not create a tuple (1, 2, 3) anywhere in its execution.
>
> Well, the second argument to PyObject_Call and function_call is a tuple,
> which had to come from somewhere. That may be a CPython implementation
> detail, but what else could __call__'s prototype be but (self, *args,
> **kwargs)?

On the arrivals side, sure, *args. But on the departures side, you can
use any sequence, and there's the whole thing of positional and
keyword arguments to look at. So ultimately, all you can possibly be
seeing is an implementation detail - there's no requirement that a
tuple ever be built.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Parens do create a tuple

[Steven D'Aprano]

On Mon, 11 Apr 2016 11:51 am, Chris Angelico wrote:

> On Mon, Apr 11, 2016 at 11:41 AM, Ben Finney 
> wrote:
>>> I'd rather be correct on the one-element case and wrong on the empty
>>> than the other way around.
>>
>> To say “commas create tuples” is to say an unobjectionably true
>> statement about Python syntax. It remains true as one continues to learn
>> Python.
>>
>> To say “parens do not create tuples” is to lay a trap which needs to be
>> de-fused at some point. Better IMO never to lay that trap.
> 
> Fair. "Commas create tuples" is correct but incomplete; 

It's incorrect as well as incomplete. Not every comma is part of a tuple.

It's not even correct if you limit yourself to expressions, rather than all
Python statements. There are two commas in both the following expressions:

(lambda a, b: a+2*b)(1, 2)

"abc,def".split(",")


and yet no tuples are involved.

Yes, I'm being pedantic. I'm being more pedantic than Ben, and that's a
scary thing :-)


> "parens do not create tuples" is incorrect in a narrow way. 

It's only incorrect if you neglect to follow up by saying "with the
exception of the empty tuple". Which makes it incomplete rather than
incorrect. It is *certainly true* that in the expression:

(1, 2, 3, 4)

the parens do not create the tuple, they are only used for grouping. So it
is misleading to say that '"parens do not create tuples" is incorrect'.


> Fortunately, technical 
> correctness lines up with the more useful case of helping people
> understand the one-element case.

You know, I've never come across anyone who has failed to understand the
one-element case from an explanation similar to this:

"Parentheses or round brackets don't create tuples, they are used for
grouping. It is the commas, not the brackets, that creates the tuple. The
only exception is the empty tuple, which is written as ()."

*especially* if you give an example of a one-element tuple to reinforce the
lesson.

Short, snappy, memorable statements like "parens don't create tuples" don't
have to be pedantically correct in all the technical details to be useful.
It is allowed to follow them with a more detailed explanation, including
any exceptions to the rule.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: one-element tuples

[Fillmore]

On 04/10/2016 09:36 PM, Ben Finney wrote:

If the two examples give you different responses (one surprises you, the
other does not), I would really like to know*what the surprise is*.
What specifically did you expect, that did not happen?


now that I get the role of commas it's not surprising anymore...

thanks

--
https://mail.python.org/mailman/listinfo/python-list

Re: Parens do create a tuple

[Random832]

On Sun, Apr 10, 2016, at 22:32, Steven D'Aprano wrote:
> def func(arg1, arg2, arg3):
> pass
> 
> func(1, 2, 3) 
> 
> does not create a tuple (1, 2, 3) anywhere in its execution.

Well, the second argument to PyObject_Call and function_call is a tuple,
which had to come from somewhere. That may be a CPython implementation
detail, but what else could __call__'s prototype be but (self, *args,
**kwargs)?

> Live by pedantry, die by pedantry.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue26685] Raise errors from socket.close()

[Martin Panter]

Martin Panter added the comment:

I tweaked the test again for Windows, anticipating that it will raise ENOTSOCK 
rather than EBADF.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Most probably a stupid question, but I still want to ask

[Fillmore]

funny, but it seems to me that you are taking it personally... thank god i even 
apologized
in advance for what was most probably a stupid question..

On 04/10/2016 09:50 PM, Steven D'Aprano wrote:


Fillmore, you should feel very pleased with yourself. All the tens of
thousands of Python programmers, and millions of lines of code written in
the language, but nobody until now was able to see what you alone had the
intelligence and clarity of thought to spot. Well done!





--
https://mail.python.org/mailman/listinfo/python-list

[issue14456] Relation between threads and signals unclear

[Roundup Robot]

Roundup Robot added the comment:

New changeset 73050563053f by Martin Panter in branch '3.5':
Issue #14456: Remove contradiction about blocking signals from bad merge
https://hg.python.org/cpython/rev/73050563053f

New changeset a8dbe6016a31 by Martin Panter in branch 'default':
Issue #14456: Merge signal doc fix from 3.5
https://hg.python.org/cpython/rev/a8dbe6016a31

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask]

[Chris Angelico]

On Mon, Apr 11, 2016 at 12:22 PM, Dan Sommers  wrote:
> On Mon, 11 Apr 2016 01:33:10 +0100, MRAB wrote:
>
>> There _is_ one exception though: (). It's the empty tuple (a 0-element
>> tuple). It doesn't have a comma and the parentheses are mandatory.
>> There's no other way to write it.
>
> The other way to write it is:
>
> tuple()

There are lots of ways to construct an empty tuple, but only one
spelling for its literal.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Parens do create a tuple

[Steven D'Aprano]

On Mon, 11 Apr 2016 11:41 am, Ben Finney wrote:

> Chris Angelico  writes:
> 
>> Fair enough. Let's instead say "commas create tuples", which is true
>> in all cases except the singleton empty tuple. Is that near enough
>> that we can avoid the detail?
> 
> It's a fine thing to say, because it's simply true. Commas create
> tuples.

def func(arg1, arg2, arg3):
pass

func(1, 2, 3) 

does not create a tuple (1, 2, 3) anywhere in its execution. So there are
commas that don't create a tuple. Including these:

import math, sys, time

# Python 2
print "This", "is", "not", "a", "tuple."

# Also Python 2
try:
...
except Exception, err:
...

# Any Python
del fe, fi, fo, fum



Live by pedantry, die by pedantry.

:-)


> To say “commas create tuples” is to say an unobjectionably true
> statement about Python syntax. It remains true as one continues to learn
> Python.

Really not.


> To say “parens do not create tuples” is to lay a trap which needs to be
> de-fused at some point. Better IMO never to lay that trap.

If one wishes to be both pedantic and correct, as well as long-winded and
verbose, one needs to say something like this:


In the statement

mytuple = (1, 2, 3, 4, 5)

it is not the parentheses or round brackets which creates the tuple, it is
the commas, so this will work equally well:

mytuple = 1, 2, 3, 4, 5


In general, you create tuples in an expression by separating the values with
commas, not by surrounding them in parentheses. Parens act to group
expressions, so they're useful for ambiguous cases such as nested tuples:

mytuple = 1, 2, 3, (10, 20, 30), 5

or to overrule the default precedence rules:

lambda x, y: x+1, y+2  # a tuple of (lambda, y+2)

lambda x, y: (x+1, y+2)  # a function that returns a tuple (x+1, y+2)


or just to make the expression look nicer. As a consequence, a single item
tuple can be created with a trailing comma, with or without parens:

mytuple = 1,
mytuple = (1,)


The zero-element tuple is a special case. You can't have a comma on its own,
so the zero-element tuple has its own special syntax:

mytuple = ()



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask]

[Dan Sommers]

On Mon, 11 Apr 2016 01:33:10 +0100, MRAB wrote:

> There _is_ one exception though: (). It's the empty tuple (a 0-element
> tuple). It doesn't have a comma and the parentheses are mandatory.
> There's no other way to write it.

The other way to write it is:

tuple()
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: QWERTY was not designed to intentionally slow typists down (was: Unicode normalisation [was Re: [beginner] What's wrong?])

[pyotr filipivich]

Ian Kelly  on Sun, 10 Apr 2016 07:43:13 -0600
typed in comp.lang.python  the following:
>On Sat, Apr 9, 2016 at 9:09 PM, pyotr filipivich  wrote:
>> ASINTOER are the top eight English letters (not in any order, it
>> is just that "A Sin To Err" is easy to remember.
>
>What's so hard to remember about ETA OIN SHRDLU? Plus that even gives
>you the top twelve. :-)

Depends on what you're looking for, I suppose.  In this case,
those eight get encoded differently than the other 20 characters.
--  
pyotr filipivich
The fears of one class of men are not the measure of the rights of another. 
-- George Bancroft
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Most probably a stupid question, but I still want to ask

[Steven D'Aprano]

On Mon, 11 Apr 2016 08:51 am, Fillmore wrote:

> at which point did the language designers decide to betray the
> "path of least surprise" principle and create a 'discontinuity' in the
> language?

It was March 1996, and I was there. I don't remember the date, I'm afraid.
Some of the core Python developers and users had got together in a trendy
bar in Los Angeles to discuss the future of the language before the 1.0
release. I don't remember the name of the bar, but you had to go down some
steps to get to it from the street (like the one in Cheers), and the
barkeeper was this amazingly entertaining black man in his 40s who kept us
in stitches with his anecdotes and stories about the various places he had
worked before.

Anyway, to get back to the question on hand, we were sitting around
discussing questions about the language. Remember, this was back in the
pre-1.0 days, and there was a *lot* still open for debate:

- case sensitive or insensitive?

- tabs or spaces or both?

- should floats be C singles or doubles?

- use '' for strings or ""?

among others.

I remember Tim Peters, the Timbot, arguing strongly that using doubles was a
waste of time, nobody would ever need that much precision for floating
point calculations, but the rest of us convinced Guido to ignore him.

I don't know who exactly it was that came up with the idea, because I was at
the bar ordering a round of drinks, but when I came back I remember Guido's
words like it was yesterday:

"It's not just enough to betray the principle of least surprise," he said,
and banged his fist on the table in emphasis, "any idiot can design a
surprising language like C. We have to do it in much more subtle way."

Congratulations to Fillmore. It's taken 20 years, but somebody has finally
rumbled to the fact that Python is a joke language! Guido made it all up to
prank people.

I don't think we used the word "troll" back then, but we spent the rest of
the afternoon deciding how we could best troll people with a language which
*seemed* consistent, with a single, coherent programming model, but was
actually a hodge-podge of competing paradigms, inconsistencies and
surprises for the unwary.

I mean, come on guys, in hindsight it should be obvious. Python is a
language that supports three inconsistent language paradigms:

- object oriented
- functional
- procedural

I thought that was too obvious and would give the game away, but Guido was
right. Programmers aren't that bright.

My own contribution to the gag was mutable default function arguments. I'm
really proud of that, because I came up with what seems like a perfectly
sensible and logical explanation for the behaviour, and a name for
it, "early binding", that makes it seem kinda technical and "computer
sciency", but we really added it just to be dicks and annoy folks.

Fillmore, you should feel very pleased with yourself. All the tens of
thousands of Python programmers, and millions of lines of code written in
the language, but nobody until now was able to see what you alone had the
intelligence and clarity of thought to spot. Well done!



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Parens do create a tuple

[Chris Angelico]

On Mon, Apr 11, 2016 at 11:41 AM, Ben Finney  wrote:
>> I'd rather be correct on the one-element case and wrong on the empty
>> than the other way around.
>
> To say “commas create tuples” is to say an unobjectionably true
> statement about Python syntax. It remains true as one continues to learn
> Python.
>
> To say “parens do not create tuples” is to lay a trap which needs to be
> de-fused at some point. Better IMO never to lay that trap.

Fair. "Commas create tuples" is correct but incomplete; "parens do not
create tuples" is incorrect in a narrow way. Fortunately, technical
correctness lines up with the more useful case of helping people
understand the one-element case.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Most probably a stupid question, but I still want to ask

[Terry Reedy]

On 4/10/2016 8:17 PM, Fillmore wrote:


apparently my 'discontinuity' is mappable to the fact that there's no such
thing as one-element tuples in Python, and attempts to create one will
result in a string (i.e. an object of a different kind!)...


Please work through the tutorial before posting wrong information
about the basics of Python.

>>> t = 1,
>>> t
(1,)

--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Parens do create a tuple

[Ben Finney]

Chris Angelico  writes:

> Fair enough. Let's instead say "commas create tuples", which is true
> in all cases except the singleton empty tuple. Is that near enough
> that we can avoid the detail?

It's a fine thing to say, because it's simply true. Commas create
tuples.

There are some tuples that cannot be created as a literal by comma. That
does not make the statement untrue.

They are not the *only* thing that creates tuples; parens can also
create tuples. So we should avoid false statements on that score.

> I'd rather be correct on the one-element case and wrong on the empty
> than the other way around.

To say “commas create tuples” is to say an unobjectionably true
statement about Python syntax. It remains true as one continues to learn
Python.

To say “parens do not create tuples” is to lay a trap which needs to be
de-fused at some point. Better IMO never to lay that trap.

-- 
 \ “It’s a great idea to come in unencumbered by dogma but you |
  `\can’t also be unencumbered by evidence.” —Darren Saunders, |
_o__)   2015-12-02 |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: one-element tuples

[Ben Finney]

Fillmore  writes:

> On 04/10/2016 08:31 PM, Ben Finney wrote:
> > Can you describe explicitly what that “discontinuation point” is? I'm
> > not seeing it.
>
> Here you go:
>
> >>> a = '"string1"'
> >>> b = '"string1","string2"'
> >>> c = '"string1","string2","string3"'
> >>> ea = eval(a)
> >>> eb = eval(b)
> >>> ec = eval(c)
> >>> type(ea)
><--- HERE 
> >>> type(eb)
> 
> >>> type(ec)
> 

While I wait to find out what confuses you about the above, let me ask
another question that might get closer to the issue.

Would you find the following session confusing? Why?

>>> a = "string1"
>>> b = "string1", "string2"
>>> c = "string1", "string2", "string3"

>>> type(a)

>>> type(b)

>>> type(c)


> and mind you, I am not saying that this is wrong. I'm just saying that
> it surprised me.

If the two examples give you different responses (one surprises you, the
other does not), I would really like to know *what the surprise is*.
What specifically did you expect, that did not happen?

-- 
 \“I knew it was a shocking thing to say, but … no-one has the |
  `\right to spend their life without being offended.” —Philip |
_o__)  Pullman, 2010-03-28 |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Unacceptable behavior

[Jeff Schumaker]

On Sunday, April 10, 2016 at 10:03:37 AM UTC-4, Chris Angelico wrote:
> On Sun, Apr 10, 2016 at 11:54 PM, Jeff Schumaker wrote

> > As a new member of this group, I am not sure on how to report unacceptable 
> > behavior. If this is not the correct way, I apologize.
> >
> > Please check the following thread:
> >
> > Find the number of robots needed to walk through the rectangular grid
> >
> > I believe there was some unnecessary rudeness on the part of one of the 
> > respondants to the original post
> 
> My guess is you're talking about Mark Lawrence, and yes, I agree; he's
> been fairly vitriolic.
> 
> The standard way to report abusive behaviour on mailing lists is to
> contact the owner. 
> 
> ChrisA

No, this was a different poster. And, thanks, Chris, for the email address. I 
will give it a shot.

Jeff
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Unacceptable behavior

[Ned Batchelder]

On Sunday, April 10, 2016 at 9:29:19 PM UTC-4, Jeff Schumaker wrote:
> On Sunday, April 10, 2016 at 1:15:18 PM UTC-4, bream...@gmail.com wrote:
> > On Sunday, April 10, 2016 at 2:54:45 PM UTC+1, Jeff Schumaker wrote:
> > > On Thursday, April 7, 2016 at 2:50:32 AM UTC-4, Ethan Furman wrote:
> > > > On 04/05/2016 01:05 PM, Thomas 'PointedEars' Lahn wrote:
> > > > 
> > > >  > | >>> from email import ID10T
> > > > 
> > > > Thomas, as has been pointed out to you in previous threads it is not 
> > > > necessary to be rude to be heard.
> > > > 
> > > > You are hereby placed in moderation for the Python List mailing list.
> > > > 
> > > > Every one else:  If you see offensive posts from Thomas on the usenet 
> > > > side, please just ignore them.  I have no desire to see his posts in 
> > > > your replies.
> > > > 
> > > > --
> > > > ~Ethan~
> > > > Python List Owners
> > > 
> > > Ethan,
> > > 
> > > As a new member of this group, I am not sure on how to report 
> > > unacceptable behavior. If this is not the correct way, I apologize.
> > > 
> > > Please check the following thread:
> > > 
> > > Find the number of robots needed to walk through the rectangular grid
> > > 
> > > I believe there was some unnecessary rudeness on the part of one of the 
> > > respondants to the original post
> > > 
> > > Jeff
> > 
> > I'm been through the entire thread and haven't got the faintest idea what 
> > you're talking about. Or are you in the camp that believes when someone is 
> > too bone idle to do any work for themselves, and turns up here asking for 
> > us to write all of their code for them, we should kill the fatted calf, 
> > roll out the red carpet, and then write the code?
> 
> Certainly not, but as Random832 says, you can politely say No.
> 
> I realize there is no minimum requirement for social etiquette to be a good 
> programmer. Or a bad one, for that matter. But if the purpose of this group 
> is to help others with Python, simple courtesy seems to be common sense.
> 
> Jeff

Jeff, you are right.  Mark's behavior has been getting more aggressive, and
less like what we encourage and hope for here.  He is not representing the
ideals of the Python community.  We are mostly helpful and nice. :)

--Ned.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Parens do create a tuple (was: one-element tuples [Was: Most probably a stupid question, but I still want to ask])

[Tim Chase]

On 2016-04-11 10:45, Ben Finney wrote:
> Also, there is another obvious way to create an empty tuple: call
> the ‘tuple’ type directly:
> 
> >>> foo = tuple()
> >>> print(type(foo), len(foo))  
>  0

But here the parens make the tuple too:

  >>> foo = tuple
  >>> print(type(foo))
  
  >>> len(foo)
  Traceback (most recent call last):
File "", line 1, in 
  TypeError: object of type 'type' has no len()

(totally just yanking chains, throwing pebbles in the pond to watch
the ripples, and otherwise sewing confusion ;-)

-tkc




-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Unacceptable behavior

[Jeff Schumaker]

On Sunday, April 10, 2016 at 1:15:18 PM UTC-4, bream...@gmail.com wrote:
> On Sunday, April 10, 2016 at 2:54:45 PM UTC+1, Jeff Schumaker wrote:
> > On Thursday, April 7, 2016 at 2:50:32 AM UTC-4, Ethan Furman wrote:
> > > On 04/05/2016 01:05 PM, Thomas 'PointedEars' Lahn wrote:
> > > 
> > >  > | >>> from email import ID10T
> > > 
> > > Thomas, as has been pointed out to you in previous threads it is not 
> > > necessary to be rude to be heard.
> > > 
> > > You are hereby placed in moderation for the Python List mailing list.
> > > 
> > > Every one else:  If you see offensive posts from Thomas on the usenet 
> > > side, please just ignore them.  I have no desire to see his posts in 
> > > your replies.
> > > 
> > > --
> > > ~Ethan~
> > > Python List Owners
> > 
> > Ethan,
> > 
> > As a new member of this group, I am not sure on how to report unacceptable 
> > behavior. If this is not the correct way, I apologize.
> > 
> > Please check the following thread:
> > 
> > Find the number of robots needed to walk through the rectangular grid
> > 
> > I believe there was some unnecessary rudeness on the part of one of the 
> > respondants to the original post
> > 
> > Jeff
> 
> I'm been through the entire thread and haven't got the faintest idea what 
> you're talking about. Or are you in the camp that believes when someone is 
> too bone idle to do any work for themselves, and turns up here asking for us 
> to write all of their code for them, we should kill the fatted calf, roll out 
> the red carpet, and then write the code?

Certainly not, but as Random832 says, you can politely say No.

I realize there is no minimum requirement for social etiquette to be a good 
programmer. Or a bad one, for that matter. But if the purpose of this group is 
to help others with Python, simple courtesy seems to be common sense.

Jeff
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue26685] Raise errors from socket.close()

[Roundup Robot]

Roundup Robot added the comment:

New changeset bd665613ed67 by Martin Panter in branch 'default':
Issue #26685: Raise OSError if closing a socket fails
https://hg.python.org/cpython/rev/bd665613ed67

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26585] Use html.escape to replace _quote_html in http.server

[Roundup Robot]

Roundup Robot added the comment:

New changeset bf44913588b7 by Martin Panter in branch 'default':
Issue #26585: Eliminate _quote_html() and use html.escape(quote=False)
https://hg.python.org/cpython/rev/bf44913588b7

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: one-element tuples

[Martin A. Brown]

Hello Fillmore,

> Here you go:
>
> >>> a = '"string1"'
> >>> b = '"string1","string2"'
> >>> c = '"string1","string2","string3"'
> >>> ea = eval(a)
> >>> eb = eval(b)
> >>> ec = eval(c)
> >>> type(ea)
><--- HERE 
> >>> type(eb)
> 
> >>> type(ec)
> 
>
> I can tell you that it exists because it bit me in the butt today...
>
> and mind you, I am not saying that this is wrong. I'm just saying 
> that it surprised me.

Recently in one of these two threads on your question, people have 
identified why the behaviour is as it is.

Below, I will add one question (about eval) and one suggestion about 
how to circumvent the behaviour you perceive as a language 
discontinuity.

#1: I would not choose eval() except when there is no other 
solution.  If you don't need eval(), it may save you some 
headache in the future, as well, to find an alternate way.
So, can we help you choose something other than eval()?
What are you trying to do with that usage?

#2: Yes, but, you can outsmart Python here!  Simply include a 
terminal comma in each case, right?  In short, you can force
the consuming language (Python, because you are calling eval())
to understand the string as a tuple of strings, rather than 
merely one string.

>>> a = '"string1",'
>>> ea = eval(a)
>>> len(ea), type(ea)
(1, )

>>> b = '"string1","string2",'
>>> eb = eval(b)
>>> len(eb), type(eb)
(2, )

>>> c = '"string1","string2","string3",'
>>> ec = eval(c)
>>> len(ec), type(ec)
(3, )

Good luck in your continuing Python explorations,

-Martin

P.S. Where do your double-quoted strings come from, anyway?

-- 
Martin A. Brown
http://linux-ip.net/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: one-element tuples

[Stephen Hansen]

On Sun, Apr 10, 2016, at 05:48 PM, Fillmore wrote:
> On 04/10/2016 08:31 PM, Ben Finney wrote:
> > Can you describe explicitly what that “discontinuation point” is? I'm
> > not seeing it.
> 
> Here you go:
> 
>  >>> a = '"string1"'

Here, "a" is a string that contains a double quoted string. So if you
evaluate it, you get a string.

>  >>> b = '"string1","string2"'

Here, "b" is a string that contains two double quoted strings separated
by a comma. So if you evaluate it, you get a tuple of two strings.

>  >>> c = '"string1","string2","string3"'

This is as above, but with three items.

With that in mind:
>  >>> ea = eval(a)
>  >>> eb = eval(b)
>  >>> ec = eval(c)
>  >>> type(ea)
>  
>  >>> type(eb)
> 
>  >>> type(ec)
> 

This should all be expected. The commas, when you evaluate them, are in
B making tuples. There's only a single string in A, so you get a
string. If you wanted a one item tuple, you would have written:

>>> a = '"string1",'

Note the trailing comma.

> I can tell you that it exists because it bit me in the butt today...
> 
> and mind you, I am not saying that this is wrong. I'm just saying that it
> surprised me.

If the above doesn't explain it, then I still don't understand what
you're finding surprising and what you'd expect otherwise.

---Stephen
m e @ i x o k a i . i o
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Parens do create a tuple (was: one-element tuples [Was: Most probably a stupid question, but I still want to ask])

[Stephen Hansen]

On Sun, Apr 10, 2016, at 05:45 PM, Ben Finney wrote:
> So, let's please stop saying “parens don't create a tuple”. They do, and
> because of that I've stopped saying that false over-simplification.

I stand by "parens don't make a tuple", with the caveat that I should
have mentioned the empty tuple exception that proves the rule. The only
time you need parens is to resolve ambiguity.

To suggest that parens do make tuples confuses the issue, given things
like this:
>>> a = 1,2,3
>>> b = (1, 2, 3)

--
Stephen Hansen
  m e @ i x o k a i  . i o
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: one-element tuples

[Ned Batchelder]

On Sunday, April 10, 2016 at 8:48:49 PM UTC-4, Fillmore wrote:
> On 04/10/2016 08:31 PM, Ben Finney wrote:
> > Can you describe explicitly what that "discontinuation point" is? I'm
> > not seeing it.
> 
> Here you go:
> 
>  >>> a = '"string1"'
>  >>> b = '"string1","string2"'
>  >>> c = '"string1","string2","string3"'
>  >>> ea = eval(a)
>  >>> eb = eval(b)
>  >>> ec = eval(c)
>  >>> type(ea)
><--- HERE 
>  >>> type(eb)
> 
>  >>> type(ec)
> 
> 
> I can tell you that it exists because it bit me in the butt today...
> 
> and mind you, I am not saying that this is wrong. I'm just saying that it 
> surprised me.

Perhaps the extra complication of eval is confusing things.  This:

>>> a = '"string1"'
>>> ea = eval(a)
>>> type(ea)


is the same as:

>>> type("string1")


Does that surprise you?  "string1" sure looks like a plain-old string to
me, I'm not sure why you would think it would be a tuple.

Your three expressions are:

ea = "string1"
eb = "string1","string2"
ec = "string1","string2","string3"

ea is a string, eb is a two-element tuple (both elements are strings), 
and ec is a three-element tuple (all elements are strings).

As others have said, commas make tuples.  Your first expression has no
commas (and no parens!) so it is not a tuple.

--Ned.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Parens do create a tuple

[Chris Angelico]

On Mon, Apr 11, 2016 at 10:57 AM, Ben Finney  wrote:
> Chris Angelico  writes:
>
>> On Mon, Apr 11, 2016 at 10:45 AM, Ben Finney  
>> wrote:
>> > So the expanation that remains true when you examine it is: People
>> > wanted a literal syntax to create a zero-length tuple. A pair of parens
>> > is that literal syntax, and it's the parens that create the (empty)
>> > tuple.
>>
>> But parens do NOT create a one-element tuple, and that's usually where
>> people trip up.
>
> So let's stop saying “parens do not create a tuple”, because that's just
> wantonly creating *another* stubling block.

Fair enough. Let's instead say "commas create tuples", which is true
in all cases except the singleton empty tuple. Is that near enough
that we can avoid the detail?

I'd rather be correct on the one-element case and wrong on the empty
than the other way around.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Parens do create a tuple

[Ben Finney]

Chris Angelico  writes:

> On Mon, Apr 11, 2016 at 10:45 AM, Ben Finney  
> wrote:
> > So the expanation that remains true when you examine it is: People
> > wanted a literal syntax to create a zero-length tuple. A pair of parens
> > is that literal syntax, and it's the parens that create the (empty)
> > tuple.
>
> But parens do NOT create a one-element tuple, and that's usually where
> people trip up.

So let's stop saying “parens do not create a tuple”, because that's just
wantonly creating *another* stubling block.

-- 
 \ “Pinky, are you pondering what I'm pondering?” “I think so, |
  `\Brain, but don't you need a swimming pool to play Marco Polo?” |
_o__)   —_Pinky and The Brain_ |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: one-element tuples

[Ben Finney]

Fillmore  writes:

> Here you go:
>
> >>> a = '"string1"'
> >>> b = '"string1","string2"'
> >>> c = '"string1","string2","string3"'
> >>> ea = eval(a)
> >>> eb = eval(b)
> >>> ec = eval(c)
> >>> type(ea)
><--- HERE 
> >>> type(eb)
> 
> >>> type(ec)
> 
>
> I can tell you that it exists because it bit me in the butt today...
>
> and mind you, I am not saying that this is wrong. I'm just saying that
> it surprised me.

What behaviour did you expect instead? That's still unclear.

Can you show the fictional session that would result from the behaviour
you expect?

-- 
 \ “Education is learning what you didn't even know you didn't |
  `\  know.” —Daniel J. Boorstin, historian, 1914–2004 |
_o__)  |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Parens do create a tuple (was: one-element tuples [Was: Most probably a stupid question, but I still want to ask])

[Chris Angelico]

On Mon, Apr 11, 2016 at 10:45 AM, Ben Finney  wrote:
> So the expanation that remains true when you examine it is: People
> wanted a literal syntax to create a zero-length tuple. A pair of parens
> is that literal syntax, and it's the parens that create the (empty)
> tuple.

But parens do NOT create a one-element tuple, and that's usually where
people trip up. If you show someone this line of code:

x = ()

and ask what x will be, you might get some wrong responses, but you'll
get a lot of people correctly deducing that it's a tuple. The problem
is that people see this progression:

x = ()
y = (1)
z = (1, 2)

and assume they're all tuples. A better progression is this:

x = ()
y = (1,)
z = (1, 2,)

where every element is followed by a comma and every tuple is
surrounded by parentheses. In that situation, everything works. There
are slightly different rules about which parts are optional (the
parens everywhere except the first case, and the last comma everywhere
except the second), but this should be the basic form of tuple
progression.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: one-element tuples

[Fillmore]

On 04/10/2016 08:31 PM, Ben Finney wrote:

Can you describe explicitly what that “discontinuation point” is? I'm
not seeing it.


Here you go:

>>> a = '"string1"'
>>> b = '"string1","string2"'
>>> c = '"string1","string2","string3"'
>>> ea = eval(a)
>>> eb = eval(b)
>>> ec = eval(c)
>>> type(ea)
   <--- HERE 
>>> type(eb)

>>> type(ec)


I can tell you that it exists because it bit me in the butt today...

and mind you, I am not saying that this is wrong. I'm just saying that it 
surprised me.



--
https://mail.python.org/mailman/listinfo/python-list

Parens do create a tuple (was: one-element tuples [Was: Most probably a stupid question, but I still want to ask])

[Ben Finney]

Stephen Hansen  writes:

> […] parens don't make tuples, commas do.


Chris Angelico  writes:

> The thing you're confused at is that it's not the parentheses that
> create a tuple. Parentheses merely group.


MRAB  writes:

> As has been said already, it's the comma that makes the tuple. The
> parentheses are often needed to avoid ambiguity.

This is too simplistic, and IMO it's just sowing the seed for future
confusion.

As MRAB states in the same message:

> There _is_ one exception though: (). It's the empty tuple (a 0-element
> tuple). It doesn't have a comma and the parentheses are mandatory.
> There's no other way to write it.

So, let's please stop saying “parens don't create a tuple”. They do, and
because of that I've stopped saying that false over-simplification.

A pair of tuples as an expression is literal syntax to create a tuple
with zero items.

Also, there is another obvious way to create an empty tuple: call the
‘tuple’ type directly:

>>> foo = tuple()
>>> print(type(foo), len(foo))
 0

So the expanation that remains true when you examine it is: People
wanted a literal syntax to create a zero-length tuple. A pair of parens
is that literal syntax, and it's the parens that create the (empty)
tuple.

-- 
 \ “It is hard to believe that a man is telling the truth when you |
  `\  know that you would lie if you were in his place.” —Henry L. |
_o__)  Mencken |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask]

[Chris Angelico]

On Mon, Apr 11, 2016 at 10:33 AM, MRAB  wrote:
> For example, object are passed into a function thus:
>
> f(x, y)
>
> (In reality, it's making a tuple and then passing that in.)

Actually that's not the case; certain syntactic constructs allow you
to specify multiple of something, without packaging them up into a
tuple. Function arguments and parameters are like this; otherwise
keyword arguments would have to be some kind of magic syntax in
tuples, instead of being a feature of function calls.

But there are plenty of situations where what you're describing _is_
the case, such as assigning multiple values to multiple targets:

# Package up y and x into a tuple
# Then unpack the tuple into two names
x, y = y, x

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Most probably a stupid question, but I still want to ask

[Stephen Hansen]

On Sun, Apr 10, 2016, at 05:17 PM, Fillmore wrote:
> On 04/10/2016 07:30 PM, Stephen Hansen wrote:
> 
> > There's nothing inconsistent or surprising going on besides you doing
> > something vaguely weird and not really expressing what you find
> > surprising.
> 
> well, I was getting some surprising results for some of my data, so I can
> guarantee that I was surprised!

The point is you are not saying *what* is surprising. Nothing in your
example code looks the least bit surprising to me, but I've been using
Python for ages. If you're surprised by something, say *what* surprises
you at the very least.

But to repeat what I said that you didn't quote: the thing you need to
understand is that parentheses do not create tuples, commas do.

Parentheses only group things together.

--Stephen
m e @ i x o k a i . i o
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: one-element tuples

[Ben Finney]

Fillmore  writes:

> So, my original question makes sense. Why was a discontinuation point
> introduced by the language designer?

Can you describe explicitly what that “discontinuation point” is? I'm
not seeing it.

-- 
 \   “People are very open-minded about new things, as long as |
  `\ they're exactly like the old ones.” —Charles F. Kettering |
_o__)  |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask]

[Ben Finney]

Fillmore  writes:

> Sorry guys. It was not my intention to piss off anyone...just trying
> to understand how the languare works

Frustration is understandable when learning something new :-) Hopefully
that can be a signal to take a breath, and compose messages to minimise
frustration for the readers.

> I guess that the answer to my question is: there is no such thing as a
> one-element tuple,

Certainly there is. Tuples – like any container type – can contain zero,
one, or more items.

>>> foo = ()
>>> bar = ("spam",)
>>> baz = ("spam", "eggs")
>>> blub = ("spam", "eggs", "beans")
>>> len(foo)
0
>>> len(bar)
1
>>> len(baz)
2
>>> len(blub)
3

> and Python will automatically convert a one-element tuple to a
> string...

You appear to be confusing text representation, and program syntax, and
the values themselves.

Program syntax is the structured text you type, in order that Python
should compile it and result in program code. That source code is text
with a specific representation of values and statements.

The values themselves are what exist within the Python process while it
is executing your compiled code. There is no text representation of
that, Python manipulates the values in an internal representation
normally inaccessible to the program itself.

The text representation that objects can generate on request is yet
another matter; for convenience it sometimes matches a syntactic text
that could be used to construct an equal value, but often that's not the
case. It should not be thought of as any kind of universal rule.

> Did I get this right this time?

I hope that helps to distinguish the different matters that are
confusing you.

-- 
 \“Last year I went fishing with Salvador Dali. He was using a |
  `\  dotted line. He caught every other fish.” —Steven Wright |
_o__)  |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask]

[MRAB]

On 2016-04-11 01:13, Fillmore wrote:


Sorry guys. It was not my intention to piss off anyone...just trying to 
understand how the languare works

I guess that the answer to my question is: there is no such thing as a 
one-element tuple,
and Python will automatically convert a one-element tuple to a string... hence 
the
behavior I observed is explained...

  >>> a = ('hello','bonjour')
  >>> b = ('hello')
  >>> b
'hello'
  >>> a
('hello', 'bonjour')
  >>>


Did I get this right this time?


Nope. :-)

A one-element tuple can be written as:

>>> ('hello',)
('hello',)

As has been said already, it's the comma that makes the tuple. The 
parentheses are often needed to avoid ambiguity.


For example, object are passed into a function thus:

f(x, y)

(In reality, it's making a tuple and then passing that in.)

What if you want to pass in the tuple (1, 2) as a single argument?

f((1, 2))

If you write this:

f(1, 2)

it passes them in as 2 separate arguments.

Or consider this:

   f((1, 2), 3)

This has 2 arguments: the first is the tuple (1, 2) and the second is 
the int 3.


There _is_ one exception though: (). It's the empty tuple (a 0-element 
tuple). It doesn't have a comma and the parentheses are mandatory. 
There's no other way to write it.


--
https://mail.python.org/mailman/listinfo/python-list

Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask]

[Stephen Hansen]

On Sun, Apr 10, 2016, at 05:22 PM, Fillmore wrote:
> Hold on a sec! it turns up that there is such thing as single-element
> tuples in python:
> 
>  >>> c = ('hello',)
>  >>> c
> ('hello',)
>  >>> c[0]
> 'hello'
>  >>> c[1]
> Traceback (most recent call last):
>File "", line 1, in 
> IndexError: tuple index out of range
>  >>>
> 
> So, my original question makes sense. Why was a discontinuation point
> introduced by the language designer?

What discontinuation point? 

You keep masterfully managing to *not explain what you're asking*. What
is surprising to you? 

--S
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask]

[Chris Angelico]

On Mon, Apr 11, 2016 at 10:13 AM, Fillmore  wrote:
> Sorry guys. It was not my intention to piss off anyone...just trying to
> understand how the languare works
>
> I guess that the answer to my question is: there is no such thing as a
> one-element tuple,
> and Python will automatically convert a one-element tuple to a string...
> hence the
> behavior I observed is explained...
>
 a = ('hello','bonjour')
 b = ('hello')
 b
> 'hello'
 a
> ('hello', 'bonjour')

>
>
> Did I get this right this time?

Okay, now you're asking a question in a reasonable way, so we can answer :)

The thing you're confused at is that it's not the parentheses that
create a tuple. Parentheses merely group.

>>> 'hello', 'bonjour'
('hello', 'bonjour')
>>> 'hello',
('hello',)

One-element tuples are perfectly possible, but you MUST have a comma,
so you have one at the end. The trailing comma is perfectly legal (and
ignored) on larger tuples.

>>> 'hello', 'bonjour',
('hello', 'bonjour')

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask]

[Fillmore]

On 04/10/2016 08:13 PM, Fillmore wrote:


Sorry guys. It was not my intention to piss off anyone...just trying to 
understand how the languare works

I guess that the answer to my question is: there is no such thing as a 
one-element tuple,
and Python will automatically convert a one-element tuple to a string... hence 
the
behavior I observed is explained...

 >>> a = ('hello','bonjour')
 >>> b = ('hello')
 >>> b
'hello'
 >>> a
('hello', 'bonjour')
 >>>



Hold on a sec! it turns up that there is such thing as single-element tuples in 
python:

>>> c = ('hello',)
>>> c
('hello',)
>>> c[0]
'hello'
>>> c[1]
Traceback (most recent call last):
  File "", line 1, in 
IndexError: tuple index out of range
>>>

So, my original question makes sense. Why was a discontinuation point 
introduced by the language designer?


--
https://mail.python.org/mailman/listinfo/python-list

Re: Most probably a stupid question, but I still want to ask

[Fillmore]

On 04/10/2016 07:30 PM, Stephen Hansen wrote:


There's nothing inconsistent or surprising going on besides you doing
something vaguely weird and not really expressing what you find
surprising.


well, I was getting some surprising results for some of my data, so I can
guarantee that I was surprised!

apparently my 'discontinuity' is mappable to the fact that there's no such
thing as one-element tuples in Python, and attempts to create one will
result in a string (i.e. an object of a different kind!)...





--
https://mail.python.org/mailman/listinfo/python-list

[issue26712] Unify (r)split(), (l/r)strip() method tests

[Martin Panter]

Changes by Martin Panter :


--
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask]

[Stephen Hansen]

On Sun, Apr 10, 2016, at 05:18 PM, Stephen Hansen wrote:
> The parens are optional, I always put them in because:
> >>> b = "hello",

Ahem, "because its easy to miss the trailing comma" is what I meant to
say here.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: one-element tuples [Was: Most probably a stupid question, but I still want to ask]

[Stephen Hansen]

On Sun, Apr 10, 2016, at 05:13 PM, Fillmore wrote:
> I guess that the answer to my question is: there is no such thing as a
> one-element tuple,
> and Python will automatically convert a one-element tuple to a string...
> hence the
> behavior I observed is explained...
> 
>  >>> a = ('hello','bonjour')
>  >>> b = ('hello')
>  >>> b
> 'hello'
>  >>> a
> ('hello', 'bonjour')
>  >>>
> 
> 
> Did I get this right this time?

No, you didn't. Your mistake is again -- parens don't make tuples,
commas do.

A one element tuple is:
>>> b = ("hello,)

The parens are optional, I always put them in because:
>>> b = "hello",

The parens group an expression, they don't make a type.

--
Stephen Hansen
  m e @ i x o k a i . i o
-- 
https://mail.python.org/mailman/listinfo/python-list

one-element tuples [Was: Most probably a stupid question, but I still want to ask]

[Fillmore]

Sorry guys. It was not my intention to piss off anyone...just trying to 
understand how the languare works

I guess that the answer to my question is: there is no such thing as a 
one-element tuple,
and Python will automatically convert a one-element tuple to a string... hence 
the
behavior I observed is explained...

>>> a = ('hello','bonjour')
>>> b = ('hello')
>>> b
'hello'
>>> a
('hello', 'bonjour')
>>>


Did I get this right this time?

--
https://mail.python.org/mailman/listinfo/python-list

[issue26730] SpooledTemporaryFile doesn't correctly preserve data for text (non-binary) SpooledTemporaryFile objects when Unicode characters are written

[Martin Panter]

Martin Panter added the comment:

David: I guess the seek() is to support rollover() when you are positioned 
halfway through the file.

Serhiy’s patch seems to be about the best we can do, although it does break the 
documented promise that the “ ‘_file’ attribute is either an io.BytesIO or 
io.StringIO”.

--
nosy: +martin.panter

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Most probably a stupid question, but I still want to ask

[Stephen Hansen]

On Sun, Apr 10, 2016, at 03:51 PM, Fillmore wrote:
> 
> let's look at this:
> 
> $ python3.4
> Python 3.4.0 (default, Apr 11 2014, 13:05:11)
> [GCC 4.8.2] on linux
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> line1 = '"String1" | bla'
>  >>> parts1 = line1.split(" | ")
>  >>> parts1
> ['"String1"', 'bla']
>  >>> tokens1 = eval(parts1[0])
>  >>> tokens1
> 'String1'
>  >>> tokens1[0]
> 'S'
> 
> and now this
> 
>  >>> line2 = '"String1","String2" | bla'
>  >>> parts2 = line2.split(" | ")
>  >>> tokens2 = eval(parts2[0])

I *THINK* what you're asking is why this returns a tuple, where in the
first eval you got a string. The answer is because commas create tuples
(not parens), so:

"String1", "String2"

is a tuple expression. Whereas:

"String1"

is a string expression. 

> the question is: at which point did the language designers decide to
> betray the
> "path of least surprise" principle and create a 'discontinuity' in the
> language?

There's nothing inconsistent or surprising going on besides you doing
something vaguely weird and not really expressing what you find
surprising.

--Stephen
m e @ i x o k a i . i o
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Most probably a stupid question, but I still want to ask

[Ben Finney]

Fillmore  writes:

> let's look at this:

Can you set a “Subject” field that pertains to the actual question? As
is, it doesn't help know what you want to discuss.

> the question is: at which point did the language designers decide to
> betray the "path of least surprise" principle and create a
> 'discontinuity' in the language?

This, also, doesn't help us know what the question is.

Please describe what you expect that code to do, and if possible what it
is that surprises you about its behaviour.

-- 
 \   “Repetition leads to boredom, boredom to horrifying mistakes, |
  `\   horrifying mistakes to God-I-wish-I-was-still-bored, and it |
_o__)  goes downhill from there.” —Will Larson, 2008-11-04 |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue26731] subprocess on windows leaks stdout/stderr handle to child process when stdout/stderr overridden

[Sai]

Sai added the comment:

You can workaround this problem by adding a middleman process that sets 
close_fds=True:

### childworkaround.py #
import os
import subprocess

with open(os.devnull, 'w') as devnull:
script = "import subprocess; import sys; subprocess.Popen(sys.argv[1:], 
close_fds=True)"
proc = subprocess.Popen(['python', '-c', script, 'python', 'resident.py'], 
stdout=devnull, stderr=devnull, stdin=devnull)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Most probably a stupid question, but I still want to ask

[Chris Angelico]

On Mon, Apr 11, 2016 at 8:51 AM, Fillmore  wrote:
> the question is: at which point did the language designers decide to betray
> the
> "path of least surprise" principle and create a 'discontinuity' in the
> language?
> Open to the idea that I am getting something fundamentally wrong. I'm new to
> Python...

Can you please simplify your example and show what the discontinuity
is you're referring to? You keep messing with eval and split and
stuff, and then looking at the types of things. Which part are you
surprised at?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Most probably a stupid question, but I still want to ask

[Fillmore]

let's look at this:

$ python3.4
Python 3.4.0 (default, Apr 11 2014, 13:05:11)
[GCC 4.8.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> line1 = '"String1" | bla'
>>> parts1 = line1.split(" | ")
>>> parts1
['"String1"', 'bla']
>>> tokens1 = eval(parts1[0])
>>> tokens1
'String1'
>>> tokens1[0]
'S'

and now this

>>> line2 = '"String1","String2" | bla'
>>> parts2 = line2.split(" | ")
>>> tokens2 = eval(parts2[0])
>>> tokens2
('String1', 'String2')
>>> tokens2[0]
'String1'
>>> type(tokens1)

>>> type(tokens2)

>>>


the question is: at which point did the language designers decide to betray the
"path of least surprise" principle and create a 'discontinuity' in the language?
Open to the idea that I am getting something fundamentally wrong. I'm new to 
Python...

Thanks


--
https://mail.python.org/mailman/listinfo/python-list

[issue26729] Incorrect __text_signature__ for sorted

[Martin Panter]

Martin Panter added the comment:

This is a strange case. It looks like “iterable” is half-supported as a keyword 
argument. So Silent Ghost’s patch fixes the signature, but the code still tries 
to accept keyword arguments:

>>> sorted(iterable=None)
TypeError: 'NoneType' object is not iterable
>>> sorted(iterable=())
TypeError: 'iterable' is an invalid keyword argument for this function

The problem is that sorted() blindly passes the keyword arguments to 
list.sort(). I guess we could delete "iterable" from them, but maybe it is not 
worth the trouble.

--
nosy: +martin.panter

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26732] multiprocessing sentinel resource leak

[Davin Potts]

Changes by Davin Potts :


--
nosy: +davin

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26732] multiprocessing sentinel resource leak

[Kevin Quick]

Kevin Quick added the comment:

(Sorry, an unnamed pipe, but a pipe nonetheless.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26732] multiprocessing sentinel resource leak

[Kevin Quick]

New submission from Kevin Quick:

The sentinel creates a named pipe, but the parent's end of the pipe is 
inherited by subsequently created children.  

import multiprocessing,signal,sys
def sproc(x): signal.pause()
for each in range(int(sys.argv[1])):
  multiprocessing.Process(target=sproc, args=(each,)).start()
signal.pause()

Running the above on Linux with varying numbers of child processes (expressed 
as the argument to the above) and using techniques like "$ sudo ls 
/proc//fd" it is possible to see an ever growing number of pipe connections 
for subsequent children.

--
components: Library (Lib)
messages: 263153
nosy: quick-b
priority: normal
severity: normal
status: open
title: multiprocessing sentinel resource leak
type: resource usage
versions: Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25609] Add a ContextManager ABC and type

[Brett Cannon]

Brett Cannon added the comment:

Thanks for fixing the doc bug, Martin. Too much Markdown lately. :)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26705] logging.Handler.handleError should be called from logging.Handler.handle

[Aviv Palivoda]

Aviv Palivoda added the comment:

I see the backwards compatibility issue. I have two suggestion's how to improve 
the code without breaking backwards compatibility:

1. Add a new Handler class named SafeHandler that will implement handle in the 
way suggested in the previous patch. All the stdlib handler's will inherit from 
SafeHandler and in the documentation we will suggest using this handler. I am 
adding a patch (logging-SafeGandle.patch) with this suggestion.

2. Add new module-level attribute handleException that will deprecate 
raiseException. When raiseException is set or when handleException is at the 
default value the current behavior will remain. You can set handleException to 
the following values:
   a. print - print exception to stderr
   b. propagate - propagate exception
   c. ignore - swallow the exception

The current behavior has a few inconsistencies with raiseException. For example 
when raiseException is True the handleError method don't propagate the 
excpetion as will be expected. This patch will solve this problem in addition 
to the one named in the previous message. I am adding a patch with this 
suggested behavior (logging-handleException). 

Both patch's are in initial steps and are just to show more clearly what i am 
suggesting. There are currently no tests or documentation for either patch. 
Both patch's pass all logging test's without any changes to prove the backwards 
compatibility.

--
Added file: http://bugs.python.org/file42425/logging-SafeHandle.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26705] logging.Handler.handleError should be called from logging.Handler.handle

[Aviv Palivoda]

Changes by Aviv Palivoda :


Added file: http://bugs.python.org/file42426/logging-handleException.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26730] SpooledTemporaryFile doesn't correctly preserve data for text (non-binary) SpooledTemporaryFile objects when Unicode characters are written

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Here is a patch that fixes SpooledTemporaryFile by getting rid of StringIO.

--
keywords: +patch
nosy: +serhiy.storchaka
stage: needs patch -> patch review
Added file: http://bugs.python.org/file42424/spooled_text_tempfile.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26731] subprocess on windows leaks stdout/stderr handle to child process when stdout/stderr overridden

[Matt Peters]

New submission from Matt Peters:

Tested in on Windows 8.1 with python 2.7.5.

I have a parent process that creates a child process and calls communicate to 
get stdout/stderr from the child.  The child process calls a persistent 
process, with stdout/stderr/stdin set to os.devnull, and then exits without 
waiting on the child process.  Sample code is below.

The child process exits successfully, but communicate on the the parent process 
does not return until the persistent process is terminated.  Expected behavior 
is that the child process closes its stdout/stderr pipes on exit, and those 
pipes are not open anywhere else, so the parent process returns from 
communicate once the child process exits.

One fix that stops the bug from manifesting is to edit subprocess.py:954 and 
pass in FALSE for inherit_handles in the call to _subprocess.CreateProcess 
rather than passing in int(not close_fds).  With the current code there is no 
way for the user of subprocess to trigger this behavior, because close_fds is 
necessarily False when redirecting stdout/stderr/stdin due to an exception 
raised in the Popen constructor.

I believe the proper fix to set close_fds to True, and pass in the handles 
through startupinfo, if any one of the pipes has been redirected.  This will 
require some changes to _get_handles and some significant testing.

A workaround fix that is easier to implement is to remove the assertion in the 
Popen constructor and allow the caller to specify close_fds=True even when 
redirecting one of the inputs.

Test case:
Three programs: parent.py, child.py, and persistent.py.
Launch parent.py.
Behavior:
child.py returns immediately
resident.py exits after 10 seconds
parent.py prints its output and exits immediately after resident.py exits

Expected Behavior:
child.py returns immediately
parent.py prints its output and exits immediately after child.py exits
resident.py exits after 10 seconds


### parent.py ##
import subprocess

proc = subprocess.Popen("python child.py", stdout=subprocess.PIPE, 
stderr=subprocess.STDOUT)
(output, error) = proc.communicate()
print 'parent complete'

### child.py ###
import os
import subprocess

with open(os.devnull, 'w') as devnull:
proc = subprocess.Popen('python resident.py', stdout=devnull, 
stderr=devnull, stdin=devnull)

### resident.py 
import time
time.sleep(10)

--
components: Windows
messages: 263149
nosy: paul.moore, saifujinaro, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: subprocess on windows leaks stdout/stderr handle to child process when 
stdout/stderr overridden
versions: Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Unacceptable behavior

[Tim Golden]

On 10/04/2016 18:15, breamore...@gmail.com wrote:

[... snip Mark again, using a different address to avoid the moderation 
check ...]


Mark,

Please don't do this.

If you genuinely want this list to be a useful and friendly resource, 
which is what your posts suggest, then please step back and look at your 
own words and see whether they actually further that end.


As moderators, we don't intervene lightly or often. And it seems that 
the things for which we intervene (such as your repeated bolshy manner 
lately) are not the things for you which you would intervene (such as 
off-topic posts or ill-considered questions).


So be it. If this list isn't the thing you want it to be, and if its 
current moderators don't feel that it needs to change in the way you 
want it to change, then perhaps you should consider directing your 
undoubted energies elsewhere.


But please don't play cat-and-mouse just because you want to have the 
upper hand and get the last word. I said it before and I'll say it again 
here: have a little dignity and accept that your ideal is not everyone's 
and move on. Or be the better person and contribute usefully to the list 
as you've often done.


TJG
--
https://mail.python.org/mailman/listinfo/python-list

[issue26730] SpooledTemporaryFile doesn't correctly preserve data for text (non-binary) SpooledTemporaryFile objects when Unicode characters are written

[R. David Murray]

R. David Murray added the comment:

I can't see why it even does the seek.  The existing tests pass without it.  
Does your example?

Either way, the first step here is for someone to turn this into a unit test 
for the tempfile module (in test_tempfile).

--
nosy: +r.david.murray
stage:  -> needs patch
versions: +Python 3.5, Python 3.6 -Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Change Windows Tkinter after some time

[Terry Reedy]

On 4/10/2016 2:11 PM, Terry Reedy wrote:

On 4/10/2016 9:36 AM, Diego Lelis wrote:

I need to make a change between windows, after some time. But i am
have a little bit of trouble making my code work: My windows change
only when i click on button, i tried to put lambda in my command and
also don't work.


I and others have written multiple answers on Stackoverflow about making
root.after work.  I suggest that you search "[tkinter] root.after" there.

[snip somewhat baroque code]

I urge you to read SO's "How to create a Minimal, Complete, and
Verifiable example" https://stackoverflow.com/help/mcve
This not only helps you write questions that get answers, but may help
you find the problem yourself.

I believe that all the stuff with .now and datetime deltas is
inessential noise. The initial parameter to .after is a integer
millisecond delta. All the font stuff is irrelevant to the problem, so
is some other stuff in your code.

I think you problem is that you never call root.after to start the
process going.


I see you also posted on SO and got essentially the same answer 4 hours 
before I wasted my time saying the same thing because I thought you had 
been ignored.  Please don't do this.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

[issue26730] SpooledTemporaryFile doesn't correctly preserve data for text (non-binary) SpooledTemporaryFile objects when Unicode characters are written

[James Hennessy]

New submission from James Hennessy:

The tempfile.SpooledTemporaryFile class doesn't correctly preserve data for 
text (non-binary) SpooledTemporaryFile objects when Unicode characters are 
written.  The attached program demonstrates the failure.  It creates a 
SpooledTemporaryFile object, writes 20 string characters to it, and then tries 
to read them back.  If the SpooledTemporaryFile has rolled over to disk, as it 
does in the demonstration program, then the data is not read back correctly.  
Instead, an exception is recognized due to the data in the SpooledTemporaryFile 
being corrupted.

The problem is this statement in tempfile.py, in the rollover() method:
newfile.seek(file.tell(), 0)
The "file" variable references a StringIO object, whose tell() and seek() 
methods count in characters, not bytes, yet this value is applied to a 
TemporaryFile object, whose tell() and seek() methods deal in bytes, not 
characters.  The demonstration program writes 10 characters to the 
SpooledTemporaryFile.  Since 10 exceeds the rollover size of 5, the 
implementation writes the 10 characters to the TemporaryFile and then seeks to 
position 10 in the TemporaryFile, which it thinks is the end of the stream.  
But those 10 characters got encoded to 30 bytes, and seek position 10 is in the 
middle of the UTF-8 sequence for the fourth character.  The next write to the 
SpooledTemporaryFile starts overlaying bytes from there.  The attempt to read 
back the data fails because the byte stream no longer represents a valid UTF-8 
stream of data.

The related problem is the inconsistency of the behavior of tell() and seek() 
for text (non-binary) SpooledTemporaryFile objects.  If the data hasn't yet 
rolled over to a TemporaryFile, they count in string characters.  If the data 
has rolled over, they count in bytes.

A quick fix for this is to remove the seek() in the rollover() method.  I 
presume it's there to preserve the stream position if an explicit call to 
rollover() is made, since for an implicit call, the position would be at the 
end of the stream already.  This quick fix, therefore, would introduce an 
external incompatibility in the behavior of rollover().

Another possibility is to never use a StringIO object, but to always buffer 
data in a BytesIO object, as is done for binary SpooledTemporaryFile objects.  
This has the advantage of "fixing" the tell() and seek() inconsistency, making 
them count bytes all the time.  The downside, of course, is that data that 
doesn't end up being rolled over to a TemporaryFile gets encoded and decoded, a 
round trip that could otherwise be avoided.

This problem can be circumvented by a user of SpooledTemporaryFile by 
explicitly seeking to the end of the stream after every write to the 
SpooledTemporaryFile object:  spool.seek(0, io.SEEK_END)

--
components: Library (Lib)
files: showbug.py
messages: 263147
nosy: James Hennessy
priority: normal
severity: normal
status: open
title: SpooledTemporaryFile doesn't correctly preserve data for text 
(non-binary) SpooledTemporaryFile objects when Unicode characters are written
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file42423/showbug.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24557] Refactor LibreSSL / EGD detection

[Bernard Spil]

Bernard Spil added the comment:

This is now also required for the upcoming OpenSSL 1.1.0 which also removed EGD 
by default

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26729] Incorrect __text_signature__ for sorted

[SilentGhost]

Changes by SilentGhost :


--
components: +Interpreter Core -Extension Modules, Library (Lib)
nosy: +ncoghlan
stage:  -> patch review
versions: +Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Change Windows Tkinter after some time

[Terry Reedy]

On 4/10/2016 9:36 AM, Diego Lelis wrote:

I need to make a change between windows, after some time. But i am
have a little bit of trouble making my code work: My windows change
only when i click on button, i tried to put lambda in my command and
also don't work.


I and others have written multiple answers on Stackoverflow about making 
root.after work.  I suggest that you search "[tkinter] root.after" there.


[snip somewhat baroque code]

I urge you to read SO's "How to create a Minimal, Complete, and 
Verifiable example" https://stackoverflow.com/help/mcve
This not only helps you write questions that get answers, but may help 
you find the problem yourself.


I believe that all the stuff with .now and datetime deltas is 
inessential noise. The initial parameter to .after is a integer 
millisecond delta. All the font stuff is irrelevant to the problem, so 
is some other stuff in your code.


I think you problem is that you never call root.after to start the 
process going.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Moderation and Usenet

[Terry Reedy]

On 4/10/2016 1:05 PM, Ethan Furman wrote:


If you see offensive posts from him  on the Usenet side please do not
respond.


Just a reminder for those who, like me, prefer a newsgroup interface for 
python-list: gmane.comp.python.general at news.gmane.org mirrors the 
moderated output of python-list.  (Gmane does the same for 1000s of 
tecnhical lists.)  I believe that posts submitted from gmane are sent to 
the list *first*, and never appear on the gmane mirror until they appear 
on the list.  Thus one will not see and cannot accidentally respond to a 
post that did not appear on the list.  One gets the benefits of list 
moderation without a flooded mailbox.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Unacceptable behavior

[Random832]

On Sun, Apr 10, 2016, at 13:15, breamore...@gmail.com wrote:
> Or are you in the camp that believes when someone
> is too bone idle to do any work for themselves, and turns up here asking
> for us to write all of their code for them, we should kill the fatted
> calf, roll out the red carpet, and then write the code?

You can be polite while still saying no.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue26729] Incorrect __text_signature__ for sorted

[Erik Welch]

New submission from Erik Welch:

The first argument to sorted is positional-only, so the text signature should 
be:

sorted($module, iterable, /, key=None, reverse=False)

instead of

sorted($module, iterable, key=None, reverse=False)

To reproduce the issue, attempt to use "iterable" as a keyword argument:

>>> import inspect
>>> sig = inspect.signature(sorted)
>>> sig.bind(iterable=[])  # should raise, but doesn't
>>> sorted(iterable=[])  # raises TypeError

--
components: Extension Modules, Library (Lib)
files: sorted_1.diff
keywords: patch
messages: 263145
nosy: eriknw
priority: normal
severity: normal
status: open
title: Incorrect __text_signature__ for sorted
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file42422/sorted_1.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Unacceptable behavior

[breamoreboy]

On Sunday, April 10, 2016 at 3:03:37 PM UTC+1, Chris Angelico wrote:
> On Sun, Apr 10, 2016 at 11:54 PM, Jeff Schumaker  
> wrote:
> > As a new member of this group, I am not sure on how to report unacceptable 
> > behavior. If this is not the correct way, I apologize.
> >
> > Please check the following thread:
> >
> > Find the number of robots needed to walk through the rectangular grid
> >
> > I believe there was some unnecessary rudeness on the part of one of the 
> > respondants to the original post
> 
> My guess is you're talking about Mark Lawrence, and yes, I agree; he's
> been fairly vitriolic.
> 
> The standard way to report abusive behaviour on mailing lists is to
> contact the owner. For python-list@python.org, that's
> python-list-ow...@python.org, although the corresponding newsgroup
> isn't really 'owned' in the same way.
> 
> ChrisA

You were wrong, care to have another go?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Unacceptable behavior

[breamoreboy]

On Sunday, April 10, 2016 at 2:54:45 PM UTC+1, Jeff Schumaker wrote:
> On Thursday, April 7, 2016 at 2:50:32 AM UTC-4, Ethan Furman wrote:
> > On 04/05/2016 01:05 PM, Thomas 'PointedEars' Lahn wrote:
> > 
> >  > | >>> from email import ID10T
> > 
> > Thomas, as has been pointed out to you in previous threads it is not 
> > necessary to be rude to be heard.
> > 
> > You are hereby placed in moderation for the Python List mailing list.
> > 
> > Every one else:  If you see offensive posts from Thomas on the usenet 
> > side, please just ignore them.  I have no desire to see his posts in 
> > your replies.
> > 
> > --
> > ~Ethan~
> > Python List Owners
> 
> Ethan,
> 
> As a new member of this group, I am not sure on how to report unacceptable 
> behavior. If this is not the correct way, I apologize.
> 
> Please check the following thread:
> 
> Find the number of robots needed to walk through the rectangular grid
> 
> I believe there was some unnecessary rudeness on the part of one of the 
> respondants to the original post
> 
> Jeff

I'm been through the entire thread and haven't got the faintest idea what 
you're talking about. Or are you in the camp that believes when someone is too 
bone idle to do any work for themselves, and turns up here asking for us to 
write all of their code for them, we should kill the fatted calf, roll out the 
red carpet, and then write the code?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Untrusted code execution

[Jon Ribbens]

On 2016-04-07, Jon Ribbens  wrote:
> I've put an example script here:
>
>   https://github.com/jribbens/unsafe/blob/master/unsafe.py
>
> When run as a script, it will execute whatever Python code you pass it
> on stdin.
>
> If anyone can break it (by which I mean escape from the sandbox,
> not make it use up all the memory or go into an infinite loop,
> both of which are trivial) then I would be very interested.

I've updated the script a bit, to fix a couple of bugs, to add back in
'with' and 'import' (of white-listed modules) and to add a REPL mode
which makes experimenting inside the sandbox easier. I'm still
interested to see if anyone can find a way out of it ;-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Moderation and Usenet

[Ethan Furman]

Mark Lawrence is currently being moderated.

If you see offensive posts from him on the Usenet side please do not 
respond.


Thank you.

--
~Ethan~
Python List Owners
--
https://mail.python.org/mailman/listinfo/python-list

Re: function to remove and punctuation

[Peter Otten]

Thomas 'PointedEars' Lahn wrote:

> Peter Otten wrote:
> 
>> gesh...@gmail.com wrote:
>>> how to write a function taking a string parameter, which returns it
>>> after you delete the spaces, punctuation marks, accented characters in
>>> python ?
>> 
>> Looks like you want to remove more characters than you want to keep. In
>> this case I'd decide what characters too keep first, e. g. (assuming
>> Python 3)
> 
> However, with *that* approach (which is different from the OP’s request),
> regular expression matching might turn out to be more efficient:
> 
> ---
> import re
> print("".join(re.findall(r'[a-z]+', "...", re.IGNORECASE)))
> ---
> 
> With the OP’s original request, they may still be the better approach.
> For example:
> 
> --
> import re
> print("".join(re.sub(r'[\s,;.?!ÀÁÈÉÌÍÒÓÙÚÝ]+', "", "...",
>  flags=re.IGNORECASE)))
> --
> 
> or
> 
> --
> import re
> print("".join(re.findall(r'[^\s,;.?!ÀÁÈÉÌÍÒÓÙÚÝ]+', "", "...",
>  flags=re.IGNORECASE)))
> --
> 
> import string
> keep = string.ascii_letters + string.digits
> keep
>> 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789'
>> 
>> Now you can iterate over the characters and check if you want to preserve
>> it for each of them:
> 
> The good thing about this part of the approach you suggested is that you
> can build regular expressions from strings, too:
> 
>   keep = '[' + 'a-z' + r'\d' + ']'
>  
> def clean(s, keep):
>> ... return "".join(c for c in s if c in keep)
>> ...
> 
> Why would one prefer this over "".filter(lambda: c in keep, s)?

Because it's idiomatic Python and easy to understand if you are coming from 
the imperative

buf = []
for c in s:
if c in keep:
buf.append(c)
"".join(buf)

Because it uses Python syntax instead of the filter/map/reduce trio.

Because it avoids the extra function call (the lambda) though the speed 
difference is not as big as I expected:

$ python3 -m timeit -s 'import string; keep = string.ascii_letters + 
string.digits; s = "alphabet soup ä" * 1000' '"".join(filter(lambda c: c in 
keep, s))'
100 loops, best of 3: 4.66 msec per loop

$ python3 -m timeit -s 'import string; keep = string.ascii_letters + 
string.digits; s = "alphabet soup ä" * 1000' '"".join(c for c in s if c in 
keep)'
100 loops, best of 3: 3.11 msec per loop

For reference here is a variant using regular expressions (picked at random, 
feel free to find a faster one):

$ python3 -m timeit -s 'import string, re; keep = string.ascii_letters + 
string.digits; s = "alphabet soup ä" * 1000; sub=re.compile(r"[^a-zA-
Z0-9]+").sub' 'sub("", s)'
1000 loops, best of 3: 1.65 msec per loop

And finally str.translate():

$ python3 -m timeit -s 'import string, collections as c; keep = 
string.ascii_letters + string.digits; s = "alphabet soup ä" * 1000; trans = 
c.defaultdict(lambda: None, str.maketrans(keep, keep))' 's.translate(trans)'
1000 loops, best of 3: 997 usec per loop

> clean(" äöü ::42", keep)
>> 'alpha42'
> clean(" äöü ::42", string.ascii_letters)
>> 'alpha'
>> 
>> If you are dealing with a lot of text you can make this a bit more
>> efficient with the str.translate() method. Create a mapping that maps all
>> characters that you want to keep to themselves
>> 
> m = str.maketrans(keep, keep)
> m[ord("a")]
>> 97
> m[ord(">")]
>> Traceback (most recent call last):
>>   File "", line 1, in 
>> KeyError: 62
>> 
>> and all characters that you want to discard to None
> 
> Why would creating a *larger* list for *more* operations be *more*
> efficient?
> 

I don't understand the question. If you mean that the trans dict may become 
large -- that depends on the input data. The characters to be deleted are 
lazily added to the defaultdict. For text in european languages the total 
size should stay well below 256 entries. But you are probably aiming at 
something else...

-- 
https://mail.python.org/mailman/listinfo/python-list

[issue20210] Provide configure options to enable/disable Python modules and extensions

[Mark Lawrence]

Changes by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26200] SETREF adds unnecessary work in some cases

[Roundup Robot]

Roundup Robot added the comment:

New changeset 9cf8572abe58 by Serhiy Storchaka in branch '2.7':
Issue #26200: Added Py_SETREF and replaced Py_XSETREF with Py_SETREF
https://hg.python.org/cpython/rev/9cf8572abe58

New changeset 66fafa13a711 by Serhiy Storchaka in branch '3.5':
Issue #26200: Added Py_SETREF and replaced Py_XSETREF with Py_SETREF
https://hg.python.org/cpython/rev/66fafa13a711

New changeset d758c5965199 by Serhiy Storchaka in branch 'default':
Issue #26200: Added Py_SETREF and replaced Py_XSETREF with Py_SETREF
https://hg.python.org/cpython/rev/d758c5965199

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com