Re: replacing `else` with `then` in `for` and `try`

[Michael Torrie]

On 11/03/2017 09:06 PM, Chris Angelico wrote:
> On Sat, Nov 4, 2017 at 1:57 PM, Michael Torrie  wrote:
>> On 11/03/2017 07:09 PM, Steve D'Aprano wrote:
>>> On Sat, 4 Nov 2017 06:15 am, Michael Torrie wrote:
>>>
 In fact if you have no break you may as well drop the
 else entirely, because the block will always execute.
>>>
>>> That's incorrect. There are multiple ways to exit a loop that will prevent 
>>> the
>>> `else` block from executing, `break` is only one.
>>
>> Such as?
> 
> There are many. But other than break, I don't know of any that WOULD
> execute the next line of code immediately _after_ the loop.

Can you be more specific? What are some of these "many" ways of aborting
a loop?  Help a guy out here.

I know, for example, that we have exceptions. But those hardly matter in
this discussion because they wouldn't execute the else clause either.
They'd either be caught elsewhere, or end the program.  sys.exit() can
also terminate a for loop, but it terminates the whole program without
running the else statement.




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

[issue31940] copystat on symlinks fails for alpine -- faulty lchmod implementation?

[Anthony Sottile]

Change by Anthony Sottile :


--
keywords: +patch
pull_requests: +4230
stage:  -> patch review

___
Python tracker 

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

[issue31898] Add a `recommended-packages.txt` file

[Nick Coghlan]

Nick Coghlan  added the comment:

In https://mail.python.org/pipermail/python-ideas/2017-October/047599.html, 
Guido suggested managing this as an occasionally updated Informational PEP 
(somewhat akin to PEP 394), and I think that will actually work fairly well:

* it clearly gives the information PEP level status (which merely being in the 
developer guide wouldn't)
* it means the guidance can be mostly version independent (which would be a 
source of irritation if the list was in the reference documentation)
* it means we can use the same process for amendments as we do for other 
informational PEPs (a combination of python-dev discussions, bugs.python.org 
issues, and specific PR reviews)

My current thoughts on structuring that:

Title: Recommended Independently Updated Python Packages

Tone/Audience: I'll aim the PEP primarily at answering the "Why isn't  in 
the standard library?" question, as that helps us keep the list focused on 
python-dev specific concerns and avoid turning it into a general categorised 
list of Python library recommendations like 
https://github.com/vinta/awesome-python

The key criterion for something being mentioned will be when the standard 
library *already* contains comparable functionality, but there's a language 
version independent third party alternative that even core developers will 
often use instead. That list is currently:

urllib.requests -> requests (pace of change in web standards)
re -> regex (technical challenges with backend migration)
datetime.timezone -> pytz.timezone (updates driven by IANA timezone database)
ctypes -> cffi (build tools should be version independent)
distutils -> setuptools (build tools should be version independent)

I'll likely also include a list of libraries where version independence is a 
key feature, so they've never even been proposed for stdlib inclusion, despite 
their broad popularity:

- the six compatibility module
- various backport libraries (e.g. importlib2, contextlib2, unittest2)
- third party libraries like lxml

I'm not sure if or how I'll cover the scientific Python stack (especially 
NumPy.ndarray being the reference implementation for multi-dimensional arrays), 
but Nathaniel Smith has some interesting thoughts on that in 
https://mail.python.org/pipermail/python-ideas/2017-November/047636.html

--

___
Python tracker 

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

[issue31415] Add -X option to show import time

[INADA Naoki]

INADA Naoki  added the comment:

I'm +1 to remove -X option.
Supporting both form makes code ugly and benefit is too small.
And +1 to negative cache too.   It's simple for environment varianle.

--

___
Python tracker 

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

Re: replacing `else` with `then` in `for` and `try`

[Chris Angelico]

On Sat, Nov 4, 2017 at 1:57 PM, Michael Torrie  wrote:
> On 11/03/2017 07:09 PM, Steve D'Aprano wrote:
>> On Sat, 4 Nov 2017 06:15 am, Michael Torrie wrote:
>>
>>> In fact if you have no break you may as well drop the
>>> else entirely, because the block will always execute.
>>
>> That's incorrect. There are multiple ways to exit a loop that will prevent 
>> the
>> `else` block from executing, `break` is only one.
>
> Such as?

There are many. But other than break, I don't know of any that WOULD
execute the next line of code immediately _after_ the loop.

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

Re: replacing `else` with `then` in `for` and `try`

[Michael Torrie]

On 11/03/2017 07:09 PM, Steve D'Aprano wrote:
> On Sat, 4 Nov 2017 06:15 am, Michael Torrie wrote:
> 
>> In fact if you have no break you may as well drop the
>> else entirely, because the block will always execute.
> 
> That's incorrect. There are multiple ways to exit a loop that will prevent the
> `else` block from executing, `break` is only one.

Such as?
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue31941] ImportError: DLL Load Failure: The specified module cannot be found

[R. David Murray]

R. David Murray  added the comment:

Duplicate of #25655.  Any concrete proposals for how to make this better are 
welcome.

--
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Python errors related to failures loading DLL's lack information

___
Python tracker 

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

[issue31941] ImportError: DLL Load Failure: The specified module cannot be found

[xoviat]

New submission from xoviat :

Yes, I know that this isn't Python's fault. I know how to resolve the problem. 
But what's frustrating is that this error message is totally unhelpful, because 
it doesn't contain the DLL that Python is looking for.

Yes, I know that the error message is just directly from windows. But there has 
to be some way to make this error message more helpful. There has to be some 
way to tell the user what the name of the DLL is. Because the current state of 
this error message is sad.

--
messages: 305531
nosy: xoviat
priority: normal
severity: normal
status: open
title: ImportError: DLL Load Failure: The specified module cannot be found
type: enhancement

___
Python tracker 

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

[issue31889] difflib SequenceMatcher ratio() still have unpredictable behavior

[Tim Peters]

Tim Peters  added the comment:

Pass "autojunk=False" to your SequenceMatcher constructor and the ratio you get 
back will continue to increase as `i` increases.

The docs:

"""
Automatic junk heuristic: SequenceMatcher supports a heuristic that 
automatically treats certain sequence items as junk. The heuristic counts how 
many times each individual item appears in the sequence. If an item’s 
duplicates (after the first one) account for more than 1% of the sequence and 
the sequence is at least 200 items long, this item is marked as “popular” and 
is treated as junk for the purpose of sequence matching. This heuristic can be 
turned off by setting the autojunk argument to False when creating the 
SequenceMatcher.
"""

Note in particular the "at least 200 items long" there.  That's why you see a 
change in behavior at i == 200.  Before then, the autojunk heuristic is not 
triggered.

If we had it all to do over again, I'd make autojunk=False the default.  But - 
for backward compatibility - it's too late to change that now.

As to quick_ratio() and real_quick_ratio(), NOTHING about them is defined - or 
intended to be defined - beyond what the docs already say:

"""
quick_ratio()
Return an upper bound on ratio() relatively quickly.

real_quick_ratio()
Return an upper bound on ratio() very quickly.
"""

Nothing in the code you posted violates those promises (e.g., 0.99 is certainly 
an upper bound with respect to 0.0).  If they always returned 1.0, regardless 
of inputs, that would meet the docs' promises too.  Only the result of ratio() 
is defined.

As to why they exist, the docs explain that:

"""
ratio()
Return a measure of the sequences’ similarity as a float in the range [0, 1].

...

This is expensive to compute if get_matching_blocks() or get_opcodes() hasn’t 
already been called, in which case you may want to try quick_ratio() or 
real_quick_ratio() first to get an upper bound.
"""

So if the expense of calling ratio() isn't a concern in your context, there's 
no reason to call quick_ratio() or real_quick_ratio().  They exist so it's 
possible to code a cheap "early out" path in contexts where calling ratio() all 
the time may be prohibitively expensive.

For example, consider an app that has no use at all for a ratio < 0.5.  If 
quick_ratio() (or real_quick_ratio()) return something less than 0.5, then it's 
guaranteed that ratio() would too, since the quicker versions return upper 
bounds on what ratio() would return.

This is valuable where it matters, and completely useless where it doesn't 
matter ;-)

In any case, since `autojunk=False` repairs the behavior you pointed out, I'm 
closing this as Won't-Fix.

--
resolution:  -> wont fix
stage:  -> 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: Thread safety issue (I think) with defaultdict

[Steve D'Aprano]

On Sat, 4 Nov 2017 05:12 am, Israel Brewster wrote:

[...]
>> People generally understand how to move data around, and the mistakes are
>> usually pretty obvious when they happen.
> 
> I think the existence of this thread indicates otherwise :-) This mistake
> was far from obvious, and clearly I didn't understand properly how to move
> data around *between processes*. Unless you are just saying I am ignorant or
> something? :-)

Yes, you were ignorant -- you didn't even realise that you were using
processes, you thought you were using threaded code when it was actually
multiprocessing code. No wonder you got it wrong.

Of course you have a good excuse: the multiprocessing is hidden deep inside
not just the library you were using, but the library *it* was using.

(I don't know how obvious the documentation of the libraries make this --
maybe they're to blame, for not being clear enough -- or maybe you were
simply ignorant about the tools you were using.)

You can't judge multiprocessing code on the basis of bugs caused by assuming
that it was threading code, writing in a threading style with shared data. If
you misuse your tools, that's not the tool's fault.

If anything, we can say that the ultimate error was that you decided to write
in a threaded style without actually using threads: the error was your
(dangerous?) choice to write non-deterministic code using shared data.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: replacing `else` with `then` in `for` and `try`

[Steve D'Aprano]

On Sat, 4 Nov 2017 06:15 am, Michael Torrie wrote:

> In fact if you have no break you may as well drop the
> else entirely, because the block will always execute.

That's incorrect. There are multiple ways to exit a loop that will prevent the
`else` block from executing, `break` is only one.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

[issue31935] subprocess.run() timeout not working with grandchildren and stdout=PIPE

[Martin Panter]

Martin Panter  added the comment:

This proposal sounds like a race condition. Closing the output pipe as a child 
exits means you risk missing recent output. On the other hand, if you don’t 
care about the output any more, close the pipe first and then wait for the 
child.

Related discussions:

Issue 30154: Similar problem, but the grandchild does not write any output
Issue 26534: kill_group=True option for timeout
Issue 31447: Windows-specific (?)

--
nosy: +martin.panter

___
Python tracker 

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

[issue31940] copystat on symlinks fails for alpine -- faulty lchmod implementation?

[Anthony Sottile]

Anthony Sottile  added the comment:

Here's one idea for a patch (inspired by the rest of the function):

```
diff --git a/Lib/shutil.py b/Lib/shutil.py
index 464ee91..2099289 100644
--- a/Lib/shutil.py
+++ b/Lib/shutil.py
@@ -213,6 +213,13 @@ def copystat(src, dst, *, follow_symlinks=True):
 # symlink.  give up, suppress the error.
 # (which is what shutil always did in this circumstance.)
 pass
+except OSError as why:
+# lchmod on alpine will raise this with symlinks: #31940
+for err in 'EOPNOTSUPP', 'ENOTSUP':
+if hasattr(errno, err) and why.errno == getattr(errno, err):
+break
+else:
+raise
 if hasattr(st, 'st_flags'):
 try:
 lookup("chflags")(dst, st.st_flags, follow_symlinks=follow)
```

However lchmod seems to be just broken on alpine so the tests continue to fail 
(however my usecase is fixed)

--

___
Python tracker 

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

[issue31940] copystat on symlinks fails for alpine -- faulty lchmod implementation?

[Anthony Sottile]

New submission from Anthony Sottile :

Fortunately, this can be reproduced with the testsuite:

```
==
ERROR: test_copystat_symlinks (__main__.TestShutil)
--
Traceback (most recent call last):
  File "/usr/lib/python3.6/test/test_shutil.py", line 366, in 
test_copystat_symlinks
os.lchmod(src_link, stat.S_IRWXO)
OSError: [Errno 95] Not supported: '/tmp/tmplfli9msi/baz'

```

My simplest reproduction involves docker:

```dockerfile
FROM alpine
RUN apk update && apk add curl python3

RUN mkdir foo && ln -s /dev/null foo/bar

CMD [ \
"python3", "-c", \
"import shutil; shutil.copytree('foo', 'bar', symlinks=True)" \
]
```

```
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.6/shutil.py", line 359, in copytree
raise Error(errors)
shutil.Error: [('foo/bar', 'bar/bar', "[Errno 95] Not supported: 'bar/bar'")]
```


By looking at pyconfig, I get the following:

```
/ # grep -E '(HAVE_FCHMODAT|HAVE_LCHMOD)' /usr/include/python3.6m/pyconfig.h 
#define HAVE_FCHMODAT 1
#define HAVE_LCHMOD 1
```

But it seems lchmod is actually nonfunctional in this case.

I think the fix is to augment `configure` to detect faulty `lchmod` and not set 
`HAVE_LCHMOD`?  I'm not terribly familiar with the autotools pipeline but 
that's where I'm going to take a stab at it!

I'm originally finding this issue via 
https://github.com/pre-commit/pre-commit/issues/655

--
components: Build, Library (Lib), Tests
messages: 305527
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: copystat on symlinks fails for alpine -- faulty lchmod implementation?
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue31938] Convert selectmodule.c to Argument Clinic

[STINNER Victor]

STINNER Victor  added the comment:

While reviewing PR 4265, I noticed that the return type like "-> None" or "-> 
int" is removed from the function definition, so the PR removes this 
information. But it seems to be a limitation of Argument Clinic: I opened the 
issue #31939.

IHMO it's not a blocker issue. We can add it back later, once the issue #31939 
is implemented.

--

___
Python tracker 

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

[issue31939] Support return annotation in signature for Argument Clinic

[STINNER Victor]

New submission from STINNER Victor :

Argument Clinic supports a few return types like NoneType, int, bool, etc. But 
the return type is omitted in the private docstring used to build the 
__text_signature__, finally used to build a Signature object in 
inspect.signature().


For example, os.dup() is declared in Modules/posixmodule.c with:

/*[clinic input]
os.dup -> int

fd: int
/

Return a duplicate of a file descriptor.
[clinic start generated code]*/


Currently, Argument Clinic generates:

PyDoc_STRVAR(os_dup__doc__,
"dup($module, fd, /)\n"
"--\n"
"\n"
"Return a duplicate of a file descriptor.");

The return type is omitted in the first line.


Finally, the return type is not documented in the signature:

haypo@selma$ ./python -c "import os,inspect; print(inspect.signature(os.dup))"
(fd, /)


I noticed this limitation while reviewing the PR 4265 which converts the select 
module to Argument Clinic. Previously, the return type like "-> None" or "-> 
int" was documented. With Argument Clinic, it's not documented nor generated in 
the signature, the information is lost.

--
messages: 305525
nosy: brett.cannon, haypo, larry, ncoghlan, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Support return annotation in signature for Argument Clinic
type: enhancement
versions: Python 3.7

___
Python tracker 

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

[issue31934] Failure to build out of source from a not clean source

[Xavier de Gaye]

Xavier de Gaye  added the comment:

To build out of the 'src' source tree (a subdirectory of the current directory) 
in a 'build' subdirectory:

$ ls -ld src
drwxr-xr-x 21 xavier xavier 4.0K Nov  3 23:50 src/
$ mkdir build
$ cd build
$ $(cd ../src && pwd)/configure && make

This is useful when you build for multiple platform configurations. For example 
on Android one can build for multiple API versions and multiple architectures 
(x86_64, armv7, aarch64, ...).

--

___
Python tracker 

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

[issue31415] Add -X option to show import time

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

On Nov 3, 2017, at 14:23, Terry J. Reedy  wrote:
> 
> Does it set the EV for the entire session (which one likely would not want), 
> or just the one command (which has no Windows equivalent that I know of)?  
> Please leave the easily remembered and typed option.

On *nix, this sets the environment variable for just this process.

--

___
Python tracker 

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

[issue31415] Add -X option to show import time

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

On Nov 3, 2017, at 14:41, Serhiy Storchaka  wrote:
> 
> Note that with environment variable you get more information.

Fun!

--

___
Python tracker 

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

[issue31934] Failure to build out of source from a not clean source

[Xavier de Gaye]

Xavier de Gaye  added the comment:

When you build out of the source tree and this source tree has been built 
previously (by running 'make' in the source tree), then you get the error msg 
printed in msg305486 when you try to build *out* of this not clean source tree. 
The solution is to run 'make clean' in the source tree first.

The reason that one must use a clean source tree is that otherwise 'make' finds 
an existing Programs/_testembed.o file in the source tree as the prerequisite 
to the Programs/_testembed target, but cannot build this target since 
Programs/_testembed.o does not exist locally.

It is not obvious from the error message to understand the reason for the build 
failure and one can waste quite some time finding the solution.

--

___
Python tracker 

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

[issue31938] Convert selectmodule.c to Argument Clinic

[Tal Einat]

Change by Tal Einat :


--
keywords: +patch
pull_requests: +4228
stage:  -> patch review

___
Python tracker 

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

Re: replacing `else` with `then` in `for` and `try`

[Ian Kelly]

On Fri, Nov 3, 2017 at 3:25 PM, Stefan Ram  wrote:
> Jon Ribbens  writes:
>>No, it's an obvious bug. You have a 'for...else' with no 'break'.
>>Like I said, that should probably be a syntax error.
>
>   It should make the syntax of Python much more complicated,
>   when one would try to encode this rule in the /syntax/.
>
>   (Just try to write down the EBNF.)
>
>   It would be more reasonable to call it a constraint.
>   Maybe it could still be a parser error (not a runtime
>   error).

Regardless of whether it's encoded in the EBNF or a constraint on the
resulting parse tree, the eventual outcome would still be called a
syntax error.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue31938] Convert selectmodule.c to Argument Clinic

[Tal Einat]

Tal Einat  added the comment:

See PR 4265.

--

___
Python tracker 

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

[issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files

[Tal Einat]

Tal Einat  added the comment:

See issue #31938 regarding Modules/selectmodule.c.

--

___
Python tracker 

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

[issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files

[Tal Einat]

Change by Tal Einat :


--
pull_requests: +4229

___
Python tracker 

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

[issue31870] add timeout parameter for get_server_certificate in ssl.py

[Christian Heimes]

Change by Christian Heimes :


--
assignee:  -> christian.heimes
components: +SSL -Library (Lib)
nosy: +alex, christian.heimes, dstufft, janssen
stage:  -> patch review
versions: +Python 3.7

___
Python tracker 

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

[issue4356] Add "key" argument to "bisect" module functions

[Gregory P. Smith]

Gregory P. Smith  added the comment:

obviously didn't make it in 3.6 but this still seems desirable.  I just saw 
someone at work propose a trivial port of golang's sort.Search - 
https://golang.org/pkg/sort/#Search - in Python which caused me to hunt for an 
issue on bisect key= support.

--
nosy: +gregory.p.smith
versions: +Python 3.7 -Python 3.6

___
Python tracker 

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

[issue31932] setup.py cannot find vcversall.bat on MSWin 8.1 if installed in user AppData

[Hugh Fisher]

Change by Hugh Fisher :


--
keywords: +patch
pull_requests: +4227
stage:  -> patch review

___
Python tracker 

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

[issue31415] Add -X option to show import time

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

On Windows you can create a 2-line bat-file that sets the environment variable 
and runs Python.

--

___
Python tracker 

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

[issue31415] Add -X option to show import time

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Note that with environment variable you get more information.

$ ./python -X importtime -c pass
import time: self [us] | cumulative | imported package
import time:88 | 88 | _codecs
import time:   789 |876 |   codecs
import time:   602 |602 |   encodings.aliases
import time:   809 |   2287 | encodings
...

$ PYTHONPROFILEIMPORTTIME=1 ./python -c pass
import time: self [us] | cumulative | imported package
import time:  3133 |   3133 | _frozen_importlib_external
import time:   371 |371 | zipimport
import time:   327 |327 | _codecs
import time:  2656 |   2982 |   codecs
import time:  1821 |   1821 |   encodings.aliases
import time:  2604 |   7406 | encodings
...

--

___
Python tracker 

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

[issue31415] Add -X option to show import time

[Terry J. Reedy]

Terry J. Reedy  added the comment:

> `PYTHONPROFILEIMPORTTIME=x python` isn’t *too* onerous

It does not work on Windows.

C:\Users\Terry>PYTHONPROFILEIMPORTTIME=x python
'PYTHONPROFILEIMPORTTIME' is not recognized as an internal or external command, 
operable program or batch file.

Does it set the EV for the entire session (which one likely would not want), or 
just the one command (which has no Windows equivalent that I know of)?  Please 
leave the easily remembered and typed option.

--

___
Python tracker 

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

[issue31938] Convert selectmodule.c to Argument Clinic

[Tal Einat]

New submission from Tal Einat :

Continuing the work begun as part of issue #20182, this is regarding the 
Argument Clinic conversion of Modules/selectmodule.c.h.

I have a complete conversion ready and will create a PR momentarily.

--
components: Argument Clinic
messages: 305514
nosy: haypo, larry, serhiy.storchaka, taleinat
priority: normal
severity: normal
status: open
title: Convert selectmodule.c to Argument Clinic
type: enhancement
versions: Python 3.7

___
Python tracker 

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

[issue31937] Add the term "dunder" to the glossary

[Mariatta Wijaya]

Mariatta Wijaya  added the comment:

Anyway, +1 to adding dunder to glossary.

--

___
Python tracker 

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

[issue31937] Add the term "dunder" to the glossary

[Mariatta Wijaya]

Mariatta Wijaya  added the comment:

> until we have something we can call a "mifflin".

Name of next GitHub bot? :P

--
nosy: +Mariatta

___
Python tracker 

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

[issue31904] Python should support VxWorks RTOS

[Terry J. Reedy]

Terry J. Reedy  added the comment:

The following might be relevant to this issue:
https://www.python.org/dev/peps/pep-0011/#supporting-platforms

--
nosy: +terry.reedy

___
Python tracker 

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

[issue31937] Add the term "dunder" to the glossary

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

-1 until we have something we can call a "mifflin".

(Kidding of course!)

--
nosy: +barry

___
Python tracker 

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

[issue31937] Add the term "dunder" to the glossary

[Brett Cannon]

New submission from Brett Cannon :

The term "dunder" is used out in the community regularly, but if you have never 
been exposed to it before it can seem a little odd without context.

--
assignee: docs@python
components: Documentation
messages: 305509
nosy: brett.cannon, docs@python
priority: normal
severity: normal
status: open
title: Add the term "dunder" to the glossary

___
Python tracker 

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

[issue31896] In function define class inherit ctypes.structure, and using ctypes.pointer leak memory

[Terry J. Reedy]

Terry J. Reedy  added the comment:

The tracker is for patching CPython.  Please consider closing this and asking 
your question on python-list.  When you post code, do so only once, and without 
line numbers, so it can be copied and run as is.  Do include data on the ref 
leaks.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue31895] Native hijri calendar support

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Haneef, thank you for the explanation.  Any such addition would need a PEP.  
But I agree with Marc-Andre that supporting the multitude of calendars is out 
of scope for the stdlib.  So I suspect such a PEP would be rejected, with the 
suggestion already given here, that this belongs on PyPI.  An existing example 
is the time module of the astropy module,
http://docs.astropy.org/en/stable/time/index.html .

I could be wrong, but I have a vague impression that expanding calendar support 
has been requested and rejected before.  We have enough to do properly 
supporting the existing time, datetime, and calendar modules.

--
nosy: +terry.reedy
resolution:  -> rejected
stage:  -> 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

[issue31936] "5. The import system" grammatical error

[Barry A. Warsaw]

Change by Barry A. Warsaw :


--
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

[issue31936] "5. The import system" grammatical error

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:


New changeset 93952f881500053057c2e08c4b253ac61233d7db by Barry Warsaw in 
branch 'master':
Fix a grammatical problem and reword for clarity. (#4257)
https://github.com/python/cpython/commit/93952f881500053057c2e08c4b253ac61233d7db


--

___
Python tracker 

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

[issue31415] Add -X option to show import time

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

On Nov 3, 2017, at 11:05, Serhiy Storchaka  wrote:
> 
> But now, after adding the environment variable, do we still need the -X 
> option? From a user side I don't see much difference between specifying an 
> option and an environment variable, but the code for handling the environment 
> variable is much simpler.

It’s a good question.  I guess in the limited amount of time I’ve used the 
feature so far, I find it kind of nice to be able to type `python -X 
importtime` when doing general import profiling.  The use case for the 
environment variable is more compelling IMHO which is why I really wanted to 
add it.  I suppose typing `PYTHONPROFILEIMPORTTIME=x python` isn’t *too* 
onerous, even if it is kind of a weird long mashed together word.

I suppose I’m -0 on removing the -X option, and +0 on adding the negative cache.

--

___
Python tracker 

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

[issue31933] some Blake2 parameters are encoded backwards on big-endian platforms

[Christian Heimes]

Change by Christian Heimes :


--
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

[issue9678] uuid._ifconfig_getnode can't work on NetBSD

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
versions: +Python 3.6, Python 3.7 -Python 3.4, Python 3.5

___
Python tracker 

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

[issue31924] Fix test_curses on NetBSD 8

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
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

[issue31924] Fix test_curses on NetBSD 8

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 6a9a331b34f39a3df1c3a91ffcac12a9608b1e57 by Serhiy Storchaka 
(Miss Islington (bot)) in branch '2.7':
bpo-31924: Fix test_curses on NetBSD 8. (GH-4228) (#4260)
https://github.com/python/cpython/commit/6a9a331b34f39a3df1c3a91ffcac12a9608b1e57


--

___
Python tracker 

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

[issue31924] Fix test_curses on NetBSD 8

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 8ce98543ef959bb65da2fb57b0d442b3b6e8a087 by Serhiy Storchaka 
(Miss Islington (bot)) in branch '3.6':
bpo-31924: Fix test_curses on NetBSD 8. (GH-4228) (#4259)
https://github.com/python/cpython/commit/8ce98543ef959bb65da2fb57b0d442b3b6e8a087


--

___
Python tracker 

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

[issue9678] uuid._ifconfig_getnode can't work on NetBSD

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +4226
status: pending -> open

___
Python tracker 

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

[issue31889] difflib SequenceMatcher ratio() still have unpredictable behavior

[Terry J. Reedy]

Change by Terry J. Reedy :


--
nosy: +tim.peters
versions: +Python 3.7 -Python 3.5

___
Python tracker 

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

Re: python3 byte decode

[Terry Reedy]

On 11/3/2017 5:24 AM, Ali Rıza KELEŞ wrote:

Hi,

Yesterday, while working with redis, i encountered a strange case.

I want to ask why is the following `True`

```
"s" is b"s".decode()
```

while the followings are `False`?

```
"so" is b"so".decode()
"som" is b"som".decode()
"some" is b"some".decode()
```

Or vice versa?

I read that `is` compares same objects, not values. So my question is
why "s" and b"s".decode() are same objects, while the others aren't?


For the same reason as

>>> a = 1
>>> b = 1
>>> a is b
True
>>> a = 1000
>>> b = 1000
>>> a is b
False

For CPython, 'small' ints are cached on startup.  Ditto for 'small' 
strings, which I think includes all 128 ascii chars, and maybe latin1 
chars.  Details depends on the implemention and version.  The main use 
of 'is' for immutable builtins is for developers to test the 
implementation in the test suite.


--
Terry Jan Reedy


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

[issue31933] some Blake2 parameters are encoded backwards on big-endian platforms

[Christian Heimes]

Christian Heimes  added the comment:


New changeset a512493371a073e252a2e52b445aa2d66ddca7cb by Christian Heimes 
(Miss Islington (bot)) in branch '3.6':
bpo-31933: fix blake2 multi-byte params on big endian platforms (GH-4250) 
(#4262)
https://github.com/python/cpython/commit/a512493371a073e252a2e52b445aa2d66ddca7cb


--

___
Python tracker 

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

[issue30057] signal.signal should check tripped signals

[Antoine Pitrou]

Change by Antoine Pitrou :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
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

[issue30057] signal.signal should check tripped signals

[Antoine Pitrou]

Antoine Pitrou  added the comment:


New changeset c713837e91f39dc18740c74729cb7cebcf54fe6e by Antoine Pitrou in 
branch '2.7':
[2.7] bpo-30057: Fix potential missed signal in signal.signal(). (GH-4258) 
(#4263)
https://github.com/python/cpython/commit/c713837e91f39dc18740c74729cb7cebcf54fe6e


--

___
Python tracker 

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

[issue31914] Document Pool.(star)map return type

[Дилян Палаузов]

Дилян Палаузов  added the comment:

If the idea is one day to switch the return type to an iterable/generator, 
returning from starmap() before all parallel executions have completed, this 
needs to be documented and the typeshed adjusted accordingly.

--

___
Python tracker 

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

Re: Thread safety issue (I think) with defaultdict

[Rhodri James]

On 03/11/17 18:12, Israel Brewster wrote:

On Nov 3, 2017, at 7:11 AM, Rhodri James  wrote:

People generally understand how to move data around, and the mistakes are 
usually pretty obvious when they happen.


I think the existence of this thread indicates otherwise :-) This mistake was 
far from obvious, and clearly I didn't understand properly how to move data 
around *between processes*. Unless you are just saying I am ignorant or 
something? :-)


Ah, but from the point of view of this argument, you didn't make a 
mistake, you made a meta-mistake.  It wasn't that you didn't understand 
how to move data around between processes, it was that you didn't think 
you were moving between processes!  Whether or not you do understand 
remains to be seen :-)


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: replacing `else` with `then` in `for` and `try`

[Michael Torrie]

On 11/03/2017 11:44 AM, Jon Ribbens wrote:
> And that's leading you into confusion, as you've demonstrated.

And indeed I've been led into considerable confusion about the else:
clause over the years. Every time I need to use it, I run a python shell
and try it out to remind myself how it works.  However now with your
mental model, Jon, I think I finally have it! Thank you.

I can't think of any normal circumstance where for/else is useful
without a break.  In fact if you have no break you may as well drop the
else entirely, because the block will always execute.  A linter should
definitely flag this.  One reason to leave it as valid syntax is maybe I
am coding up some skeleton code that I plan to fill in later.  So for
now the loop falls through, but at some future point I'll have finished
the searching code and added the break.  But if it were a syntax error I
don't think that'd be any big deal.

Anyway, thank you again, Jon.  Your explanation and model has greatly
cleared up my confusion, and I think if the docs reasoned along the same
lines it would clear up confusion in most programmers.  Certainly it
appears your line of reasoning is what Guido had in mind when he added
the else block.

Sorry Steven, I think Jon's right in this instance and your reasoning
isn't persuasive.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue30057] signal.signal should check tripped signals

[Antoine Pitrou]

Antoine Pitrou  added the comment:


New changeset ea80ae04e2ec68c7e289048d3224a24b3c3fb107 by Antoine Pitrou (Miss 
Islington (bot)) in branch '3.6':
bpo-30057: Fix potential missed signal in signal.signal(). (GH-4258) (#4261)
https://github.com/python/cpython/commit/ea80ae04e2ec68c7e289048d3224a24b3c3fb107


--

___
Python tracker 

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

[issue30057] signal.signal should check tripped signals

[Antoine Pitrou]

Change by Antoine Pitrou :


--
pull_requests: +4225

___
Python tracker 

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

[issue31933] some Blake2 parameters are encoded backwards on big-endian platforms

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +4224

___
Python tracker 

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

[issue31933] some Blake2 parameters are encoded backwards on big-endian platforms

[Christian Heimes]

Christian Heimes  added the comment:


New changeset dcfb0e3c04f1b29a0d09bb0a81dcd5ee5a5fef1a by Christian Heimes 
(Jack O'Connor) in branch 'master':
bpo-31933: fix blake2 multi-byte params on big endian platforms (#4250)
https://github.com/python/cpython/commit/dcfb0e3c04f1b29a0d09bb0a81dcd5ee5a5fef1a


--

___
Python tracker 

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

[issue30057] signal.signal should check tripped signals

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +4223

___
Python tracker 

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

[issue30057] signal.signal should check tripped signals

[Antoine Pitrou]

Antoine Pitrou  added the comment:


New changeset f6f90ff079a22b79a58d47b6117cc8a8c7d366f3 by Antoine Pitrou in 
branch 'master':
bpo-30057: Fix potential missed signal in signal.signal(). (#4258)
https://github.com/python/cpython/commit/f6f90ff079a22b79a58d47b6117cc8a8c7d366f3


--

___
Python tracker 

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

[issue31907] Clarify error message when attempting to call function via str.format()

[mickey695]

mickey695  added the comment:

I think it should be documented properly.

In roughly two weeks I will have some time to look into it. 
So I could probably document the current behaviour by the start of 
December(unless someone beats me to it)

--

___
Python tracker 

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

[issue31924] Fix test_curses on NetBSD 8

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +4221

___
Python tracker 

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

[issue31924] Fix test_curses on NetBSD 8

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset a7723d8b09f516a2b75837a3527b8cc7bee89fad by Serhiy Storchaka in 
branch 'master':
bpo-31924: Fix test_curses on NetBSD 8. (#4228)
https://github.com/python/cpython/commit/a7723d8b09f516a2b75837a3527b8cc7bee89fad


--

___
Python tracker 

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

[issue31924] Fix test_curses on NetBSD 8

[Roundup Robot]

Change by Roundup Robot :


--
pull_requests: +4222

___
Python tracker 

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

[issue31898] Add a `recommended-packages.txt` file

[Éric Araujo]

Change by Éric Araujo :


--
nosy: +eric.araujo

___
Python tracker 

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

[issue30057] signal.signal should check tripped signals

[Antoine Pitrou]

Change by Antoine Pitrou :


--
pull_requests: +4220
stage:  -> patch review

___
Python tracker 

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

[issue30057] signal.signal should check tripped signals

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Thanks for the report! I will push your patch soon.

--
versions: +Python 3.6, Python 3.7 -Python 2.7, Python 3.5

___
Python tracker 

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

Re: Thread safety issue (I think) with defaultdict

[Israel Brewster]

---
Israel Brewster
Systems Analyst II
Ravn Alaska
5245 Airport Industrial Rd
Fairbanks, AK 99709
(907) 450-7293
---




> On Nov 3, 2017, at 7:11 AM, Rhodri James  wrote:
> 
> On 03/11/17 14:50, Chris Angelico wrote:
>> On Fri, Nov 3, 2017 at 10:26 PM, Rhodri James  wrote:
>>> On 02/11/17 20:24, Chris Angelico wrote:
 
 Thank you. I've had this argument with many people, smart people (like
 Steven), people who haven't grokked that all concurrency has costs -
 that threads aren't magically more dangerous than other options.
>>> 
>>> 
>>> I'm with Steven.  To be fair, the danger with threads is that most people
>>> don't understand thread-safety, and in particular don't understand either
>>> that they have a responsibility to ensure that shared data access is done
>>> properly or what the cost of that is.  I've seen far too much thread-based
>>> code over the years that would have been markedly less buggy and not much
>>> slower if it had been written sequentially.
>> Yes, but what you're seeing is that *concurrent* code is more
>> complicated than *sequential* code. Would the code in question have
>> been less buggy if it had used multiprocessing instead of
>> multithreading? What if it used explicit yield points?
> 
> My experience with situations where I can do a reasonable comparison is 
> limited, but the answer appears to be "Yes".
> Multiprocessing
>> brings with it a whole lot of extra complications around moving data
>> around.
> 
> People generally understand how to move data around, and the mistakes are 
> usually pretty obvious when they happen.  

I think the existence of this thread indicates otherwise :-) This mistake was 
far from obvious, and clearly I didn't understand properly how to move data 
around *between processes*. Unless you are just saying I am ignorant or 
something? :-)

> People may not understand how to move data around efficiently, but that's a 
> separate argument.
> 
> Multithreading brings with it a whole lot of extra
>> complications around NOT moving data around.
> 
> I think this involves more subtle bugs that are harder to spot.  

Again, the existence of this thread indicates otherwise. This bug was quite 
subtile and hard to spot. It was only when I started looking at how many times 
a given piece of code was called (specifically, the part that handled data 
coming in for which there wasn't an entry in the dictionary) that I spotted the 
problem. If I hadn't had logging in place in that code block, I would have 
never realized it wasn't working as intended. You don't get much more subtile 
than that. And, furthermore, it only existed because I *wasn't* using threads. 
This bug simply doesn't exist in a threaded model, only in a multiprocessing 
model. Yes, the *explanation* of the bug is simple enough - each process "sees" 
a different value, since memory isn't shared - but the bug in my code was 
neither obvious or easy to spot, at least until you knew what was happening.

> People seem to find it harder to reason about atomicity and realising that 
> widely separated pieces of code may interact unexpectedly.
> 
> Yield points bring with
>> them the risk of locking another thread out unexpectedly (particularly
>> since certain system calls aren't async-friendly on certain OSes).
> 
> I've got to admit I find coroutines straightforward, but I did cut my teeth 
> on a cooperative OS.  It certainly makes the atomicity issues easier to deal 
> with.

I still can't claim to understand them. Threads? No problem. Obviously I'm 
still lacking some understanding of how data works in the multiprocessing 
model, however.

> 
> All
>> three models have their pitfalls.
> 
> Assuredly.  I just think threads are soggier and hard to light^W^W^W^W^W 
> prone to subtler and more mysterious-looking bugs.

And yet, this thread exists because of a subtle and mysterious-looking bug with 
multiple *processes* that doesn't exist with multiple *threads*. Thus the point 
- threads are no *worse* - just different - than any other concurrency model.

> 
> -- 
> Rhodri James *-* Kynesim Ltd
> -- 
> https://mail.python.org/mailman/listinfo/python-list 
> 
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue31415] Add -X option to show import time

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

> I didn't think it's worth enough because import will be much slower than one 
> dict lookup.

I agree. The main value of my patch is handling possible (but very unlike) 
errors. Implementing negative value caching adds not many lines to the existing 
code and additional error handling.

But now, after adding the environment variable, do we still need the -X option? 
From a user side I don't see much difference between specifying an option and 
an environment variable, but the code for handling the environment variable is 
much simpler.

--

___
Python tracker 

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

[issue31934] Failure to build out of source from a not clean source

[Brett Cannon]

Brett Cannon  added the comment:

What's "unclean" in this case? I mean you can always re-run Make after making 
changes and the build succeeds, so I'm not quite sure what leads to this state.

--
nosy: +brett.cannon

___
Python tracker 

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

Re: replacing `else` with `then` in `for` and `try`

[Ian Kelly]

On Fri, Nov 3, 2017 at 8:32 AM, Chris Angelico  wrote:
> On Fri, Nov 3, 2017 at 10:49 PM, Jon Ribbens  
> wrote:
>> On 2017-11-03, Steve D'Aprano  wrote:
>>> On Fri, 3 Nov 2017 03:31 am, Jon Ribbens wrote:
 No, it's an obvious bug. You have a 'for...else' with no 'break'.
 Like I said, that should probably be a syntax error.
>>>
>>> It should absolutely not be a syntax error. There's no reason for it
>>> to be a syntax error, except to satisfy some arrogant and foolish
>>> idea of purity.
>>
>> It'd be nice if you could be a little less rude. It's not an "arrogant
>> and foolish idea of purity", it's to help people catch bugs in their
>> code, and to aid their understanding of the language.
>
> That wasn't rudeness. That was an accurate description of the
> situation. It is entirely possible for code to be opinionated,
> arrogant, foolish, and all those other adjectives that we normally
> appropriate to people.

Steve was clearly referring to the coder, not the code. Please stop
defending the use of incivility on this list.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: replacing `else` with `then` in `for` and `try`

[Jon Ribbens]

On 2017-11-03, Steve D'Aprano  wrote:
> The for loop does not necessarily perform a search:
>
> count = 1
> for obj in sequence:
> if count > MAX_OBJECTS:
> print("too many objects, halting")
> break
> process(obj)
> else:
> print("finished")
>
> According to your mental model, this code is... what? Illegal? Silly?
> Impossible? A syntax error?

That conforms to my model. It's searching for the condition
'count > MAX_OBJECTS'.

> Even when there is a search, the sense of the search may be reversed
> from your mental model:
>
> for request in sequence:
> if 'please' not in request:
> break
> process(request)
> else:
> print('done')
> return
> raise SysExit('failure to say please')

That's searching for the condition "'please' not in request".

> It doesn't matter if you can think of alternative ways of writing these code
> snippets. They're legal, and they work, and your mental model doesn't cover
> them, at all or easily. That means your mental model is at best incomplete.

You've yet to come up with one that it doesn't cover.

> In other words, it was only when I realised that `else` would be better
> written as `then` that I understood the behaviour of the statement. If I read
> it as "else", then the natural interpretation is that the block runs only if
> the loop doesn't run:

You're repeating yourself.

> You'll probably dismiss them as "silly" because they don't meet your mental
> model, and insist that I would be wrong to use them.

As above, you're mistaken.

> Your response to code that doesn't match your mental model is to say
> that it is obviously wrong and probably buggy and should be made
> into a syntax error if possible.

No, it isn't. Try reading again what I actually wrote.

> And my mental model is to treat "else" in this concept as some foreign word,
> perhaps Dutch, a false-friend that actually means "next" but due to some
> awful coincidence happens to look exactly like the English word for "else".

And that's leading you into confusion, as you've demonstrated.

> Ah yes, because it is inconceivable that anyone might have thought of a use
> for for...else without a break.

It's not inconceivable, but nobody has thought of a sensible use so far
(by which I mean one that shows it's a useful feature).

> What matters is that only code that matches your model is allowed.

You do seem to enjoy telling other people what their opinions are.
Frankly, I don't know why I even bother having opinions when you're
here to tell me what they are. In future, I'll just come to you to
find out what I think.

>> It's an incredibly obscure work-around for a different problem,
>
> You mean a different problem to "searching"? Yes indeed it is.

No, I mean a problem that has nothing to do with 'for...else' clauses.
If your door is stuck then you might climb in through a window, but
that doesn't mean that the purpose of windows is to be entrances,
or that windows should be designed to make them better entrances,
or that the problem isn't the stuck door.

>>> And while I thank you for the complement that I am the cleverest and most
>>> insightful Python coder in the world,
>> 
>> I didn't say anything even remotely resembling that.
>
> That was sarcasm.

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

[issue31936] "5. The import system" grammatical error

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

Re-reading the paragraph now, it also parsed weirdly for me.  See the linked PR 
for a suggested improvement, along with your change.

Thanks!

--

___
Python tracker 

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

[issue31936] "5. The import system" grammatical error

[Barry A. Warsaw]

Change by Barry A. Warsaw :


--
keywords: +patch
pull_requests: +4219
stage:  -> patch review

___
Python tracker 

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

[issue31936] "5. The import system" grammatical error

[Barry A. Warsaw]

Change by Barry A. Warsaw :


--
nosy: +barry
versions: +Python 3.7 -Python 3.8

___
Python tracker 

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

[issue31415] Add -X option to show import time

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

On Nov 2, 2017, at 22:50, INADA Naoki  wrote:
> 
> When adding environment variable option, it should be documented in
> man page and `python -h`.

I thought about that, but the problem is that none of the -X options are 
documented in the —help output.  So do we only document the ones (e.g. 
importtime) that have an environment variable version, or do we now have to 
document them all?

I opted to document PYTHONPROFILEIMPORTTIME only in the cmdline documentation.

--

___
Python tracker 

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

[issue31936] "5. The import system" grammatical error

[Daniel U. Thibault]

New submission from Daniel U. Thibault :

https://docs.python.org/3/reference/import.html#importsystem
"Other mechanisms for invoking the import system (such as 
importlib.import_module()) may choose to subvert __import__() and use its own 
solution to implement import semantics."
should be
"Other mechanisms for invoking the import system (such as 
importlib.import_module()) may choose to subvert __import__() and use their own 
solution to implement import semantics."

--
assignee: docs@python
components: Documentation
messages: 305489
nosy: Daniel.U..Thibault, docs@python
priority: normal
severity: normal
status: open
title: "5. The import system" grammatical error
type: enhancement
versions: Python 3.8

___
Python tracker 

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

[issue28706] msvc9compiler does not find a vcvarsall.bat of Visual C++ for Python 9.0

[Stefan Krah]

Change by Stefan Krah :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> setup.py cannot find vcversall.bat on MSWin 8.1 if installed in 
user AppData

___
Python tracker 

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

[issue31932] setup.py cannot find vcversall.bat on MSWin 8.1 if installed in user AppData

[Stefan Krah]

Change by Stefan Krah :


--
nosy: +jyrkih

___
Python tracker 

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

Re: Thread safety issue (I think) with defaultdict

[Gene Heskett]

On Friday 03 November 2017 10:50:13 Chris Angelico wrote:

> On Fri, Nov 3, 2017 at 10:26 PM, Rhodri James  
wrote:
> > On 02/11/17 20:24, Chris Angelico wrote:
> >> Thank you. I've had this argument with many people, smart people
> >> (like Steven), people who haven't grokked that all concurrency has
> >> costs - that threads aren't magically more dangerous than other
> >> options.
> >
> > I'm with Steven.  To be fair, the danger with threads is that most
> > people don't understand thread-safety, and in particular don't
> > understand either that they have a responsibility to ensure that
> > shared data access is done properly or what the cost of that is. 
> > I've seen far too much thread-based code over the years that would
> > have been markedly less buggy and not much slower if it had been
> > written sequentially.
>
> Yes, but what you're seeing is that *concurrent* code is more
> complicated than *sequential* code. Would the code in question have
> been less buggy if it had used multiprocessing instead of
> multithreading? What if it used explicit yield points? Multiprocessing
> brings with it a whole lot of extra complications around moving data
> around. Multithreading brings with it a whole lot of extra
> complications around NOT moving data around. Yield points bring with
> them the risk of locking another thread out unexpectedly (particularly
> since certain system calls aren't async-friendly on certain OSes). All
> three models have their pitfalls. It's not that threads are somehow
> worse than every other model.
>
> ChrisA

I think that this discussion of threads and threading must be a different 
context than threading as I am using it in linuxcnc.

There, one assigns a function to run in a certain sequence in an assigned 
thread, which there can be several of. There, each thread is assigned a 
repetition rate, and the higher repetition rate stuff can always 
interrupt the slower threaded function in order to get the real time 
stuff done in a usable for the job time frame, and the high frequency 
thread can be as fast as every 25 microseconds on a good motherboard.  
Surprisingly, this seems to be far more board dependent than processor 
dependent, altho its pushing an AMD processor quite hard at 40 
microseconds, while the slower intel atoms can do 25 microseconds with 
about the same effort.

This is where a stepper motor is being stepped by software which didles 
pins on a parport. And it limits how fast you can move the motor 
compared to using an fpga card running at 200 MHz, not because of the 
step rate, but because of the latency of the mobo/cpu combination.

Jitter in step rate issuance is death to high performance with stepper 
motors because torque to do usefull work vanishes when the instant speed 
of the motor is wobbling with that timing jitter.

OTOH, hand controls of a machine using an encoder dial are nicely done in 
a thread running at 100 Hz, far more reliably that I can do it from the 
keyboard on a raspberry pi 3b. Why? The dials data goes into linuxcnc by 
way of a hardware fpga card that talks to the pi over an SPI buss, with 
the pi writing 32 bit packets at 41 megabaud, and reading the results at 
25 megabaud. It doesn't have to get thru that usb2 internal hub in the 
pi that all the other i/o has to go thru. Mouse and keyboard events get 
dropped on the floor, particularly dangerous when its a keyup event that 
gets dropped. The machine keeps moving until it crashes into something, 
often breaking drive parts or cutting tooling, all of which cost real 
money.

My point is that with an interpretor such as hal managing things, threads 
Just Work(TM).

It does of course take a specially built kernel to do that magic.
I'll get me coat.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: replacing `else` with `then` in `for` and `try`

[Jon Ribbens]

On 2017-11-03, Chris Angelico  wrote:
> On Fri, Nov 3, 2017 at 10:49 PM, Jon Ribbens  
> wrote:
>>> It should absolutely not be a syntax error. There's no reason for it
>>> to be a syntax error, except to satisfy some arrogant and foolish
>>> idea of purity.
>>
>> It'd be nice if you could be a little less rude. It's not an "arrogant
>> and foolish idea of purity", it's to help people catch bugs in their
>> code, and to aid their understanding of the language.
>
> That wasn't rudeness.

Yes, it was.

>> No. Ok, so look. It's obvious that you and I have different mental
>> models of the situation here. You're thinking of 'for...else' as two
>> arbitrary clauses that run consecutively unless the whole thing is
>> aborted by a 'break', whereas I'm thinking of the 'for' clause as
>> being a search for a situation that matches a condition and the
>> 'else' clause being what happens if the condition is not matched
>> (i.e. exactly the same as 'if...else').
>>
>> Now there's nothing inherently *wrong* with your choice of mental
>> model, except it's leading you into confusion because my model means
>> the meaning of the 'else' keyword is intuitive and obvious, and yours
>> means it's counter-intuitive and confusing. Your suggestion is that
>> the fix is to change the language, my suggestion is to fix your model.
>> I'd suggest that changing your mind is easier than changing the
>> language ;-)
>
> If anything, I would say that Steven's model is at a lower abstraction
> layer than yours

Yes, absolutely.

> - though IMO your model is more of an example use-case than a
> description of what is actually happening.

It's a high-level way of thinking about it that avoids confusion and
leads to correct code. Unless you can come up with a *sensible*
use-case that it doesn't cover, it's also a comprehensive way of
thinking about it.

> TBH I prefer the "if 1:" trick to gather code into a block. But that
> requires pre-planning,

Or pressing up-arrow ;-)

> whereas slapping an "else:" after the loop can be done after the event.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: replacing `else` with `then` in `for` and `try`

[Steve D'Aprano]

On Fri, 3 Nov 2017 10:49 pm, Jon Ribbens wrote:

> On 2017-11-03, Steve D'Aprano  wrote:
>> On Fri, 3 Nov 2017 03:31 am, Jon Ribbens wrote:
>>> No, it's an obvious bug. You have a 'for...else' with no 'break'.
>>> Like I said, that should probably be a syntax error.
>>
>> It should absolutely not be a syntax error. There's no reason for it
>> to be a syntax error, except to satisfy some arrogant and foolish
>> idea of purity.
> 
> It'd be nice if you could be a little less rude. 

How else should we respond to the idea that something that has been legal
syntax for over twenty years and is in no way an error should be treated as a
syntax error, just to satisfy the opinion that nobody should write for...else
unless they are performing a search and it contains a break?


>> There are uncountable ways of writing code which is seemingly
>> "pointless", and we don't make it a syntax error.
> 
> And there's uncountable ways of writing code which we *do* make a
> syntax error. I'm not sure what your point is there.

None of these are syntax errors:

if False: do_something()

for x in '': pass

if True: pass

and uncountable other pieces of code which are, from some perspective,
pointless. We don't make them syntax errors because *pointless* doesn't imply
is is an error.

You think that a for...else loop with no break is pointless and "silly", even
when I demonstrate an actual use for it. Too bad. Even if it is "silly", in
your opinion, that still does not make it an error.

Is my point clear now?


>>> No, 'then' describes the opposite of what it does. The word 'then'
>>> implies something that always happens next,
>>
>> Right, which is what happens with the for...else block.
> 
> No.

Yes. It is not a matter of opinion that the `else` clause executes after
execution falls out the bottom of the loop, i.e. the loop runs, THEN the
`else` block runs.

It is an objective fact that in the absence of something which causes
execution to jump outside of the loop altogether (a return, a raise, or a
break) the execution order is loop first, then `else` block.

Both of these two sentences makes sense in English:

"Execution reaches the end of the loop, and THEN the `else` block runs."

"Execution reaches the end of the loop, or ELSE the `else` block runs."

but only the first describes what Python's for...else statement actually does.

This is not just my mental model, it is the actual objective behaviour of the
for...else statement.


> Ok, so look. It's obvious that you and I have different mental 
> models of the situation here. You're thinking of 'for...else' as two
> arbitrary clauses that run consecutively 

Scrub out the "arbitrary", and that is exactly what they are. They aren't
arbitrary: the `else` is optional, but if present it must follow after the
loop, and never the other way around.

The code inside the blocks can, of course, be any legal code we like. There's
no rule that says "only code approved by Jon Ribbens' is allowed", and
there's no rule that says "only searches are allowed".


> unless the whole thing is aborted by a 'break', 

Or return, raise, os._exit, os.abort, or having the process killed by the OS.
For simplicity we can ignore the last three (as well as more exotic
mechanisms such as "pull the power supply out" or "drop a two-tonne weight on
the computer"), but return and raise are common ways of exiting a loop and
should not be ignored or forgotten.


> whereas I'm thinking of the 'for' clause as 
> being a search for a situation that matches a condition and the
> 'else' clause being what happens if the condition is not matched
> (i.e. exactly the same as 'if...else').

That model conflates one specific use-case for the for...else statement with
the semantics of the statement, rather like insisting that "print displays a
greeting to the world" merely because 'print("Hello, World")' is so common.

The for loop does not necessarily perform a search:


count = 1
for obj in sequence:
if count > MAX_OBJECTS:
print("too many objects, halting")
break
process(obj)
else:
print("finished")


According to your mental model, this code is... what? Illegal? Silly?
Impossible? A syntax error?

Obviously wrong and almost certainly buggy?

Even when there is a search, the sense of the search may be reversed from your
mental model:


for request in sequence:
if 'please' not in request:
break
process(request)
else:
print('done')
return
raise SysExit('failure to say please')


It doesn't matter if you can think of alternative ways of writing these code
snippets. They're legal, and they work, and your mental model doesn't cover
them, at all or easily. That means your mental model is at best incomplete.

This is what happens when you treat one use-case for a general purpose
statement as synonymous with the statement itself. `for...else` is not just
for searching, and the `else` clause doesn't necessarily run if the search is

Re: Thread safety issue (I think) with defaultdict

[Ian Kelly]

On Thu, Nov 2, 2017 at 10:27 AM, Israel Brewster  wrote:
>
>> On Nov 1, 2017, at 4:53 PM, Steve D'Aprano  
>> wrote:
>>
>> On Thu, 2 Nov 2017 05:53 am, Israel Brewster wrote:
>>
>> [...]
>>> So the end result is that the thread that "updates" the dictionary, and the
>>> thread that initially *populates* the dictionary are actually running in
>>> different processes.
>>
>> If they are in different processes, that would explain why the second
>> (non)thread sees an empty dict even after the first thread has populated it:
>>
>>
>> # from your previous post
>>> Length at get AC:  54 ID: 4524152200  Time: 2017-11-01 09:41:24.474788
>>> Length At update:  1 ID: 4524152200  Time: 2017-11-01 09:41:24.784399
>>> Length At update:  2 ID: 4524152200  Time: 2017-11-01 09:41:25.228853
>>
>>
>> You cannot rely on IDs being unique across different processes. Its an
>> unfortunately coincidence(!) that they end up with the same ID.
>
> I think it's more than a coincidence, given that it is 100% reproducible. 
> Plus, in an earlier debug test I was calling print() on the defaultdict 
> object, which gives output like "", where 
> presumably the 0x1066467f0 is a memory address (correct me if I am wrong in 
> that). In every case, that address was the same. So still a bit puzzling.

If the empty dict is created before the process is forked then I don't
think it's all that surprising.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Thread safety issue (I think) with defaultdict

[Grant Edwards]

On 2017-11-03, Chris Angelico  wrote:
> On Sat, Nov 4, 2017 at 2:45 AM, Steve D'Aprano
> wrote:
>> So, all else being equal, which is likely to have more bugs?
>>
>>
>> 1. Multiprocessing code with very little coupling between processes; or
>>
>> 2. Threaded code with shared data and hence higher coupling between threads?
>>
>
> Obviously, option 1. But that's "all else being equal". How often can
> you actually have your processes that decoupled? And if you can write
> your code to be completely (or largely) decoupled, what's to stop you
> having your *threads* equally decoupled? You're assuming that "running
> in the same memoryspace" equates to "higher coupling", which is no
> more proven than any other assertion.

The big difference is that with threaded code you can have accidental
coupling.  With multiprocessing, code you have to explicitly work to
create coupling.

That said, I do a lot of threading coding (in both Python and C), and
have never found it particularly tricky.

It does require that you understand what you're doing and probably
doesn't work well if you're a stack-overflow, cargo-cult,
cut-and-paste programmer.  But then again, what does?

-- 
Grant Edwards   grant.b.edwardsYow! Maybe I should have
  at   asked for my Neutron Bomb
  gmail.comin PAISLEY --

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

Re: replacing `else` with `then` in `for` and `try`

[Chris Angelico]

On Sat, Nov 4, 2017 at 3:15 AM, Alexey Muranov  wrote:
> On Fri, 2017-11-03 at 22:03 +1100, Chris Angelico wrote:
>> On Fri, Nov 3, 2017 at 8:48 PM, Alexey Muranov > com> wrote:
>> > 'Then' describes what happens next indeed, unless some
>> > extraordinary
>> > situation prevents it from happening, for example:
>> >
>> > try:
>> > go_to_the_bakery()
>> > then:
>> > buy_croissants(2)
>> > except BakeryClosed:
>> > go_to_the_grociery()
>> > buy_baguette(1)
>> > finally:
>> > come_back()
>> >
>> > I know this is a poor program example (why not to use a boolean
>> > return value
>> > instead of an exception, etc.), and i know that currently in Python
>> > `except`
>> > must precede `else`, it is just to illustrate the choice of terms.
>>
>> What is the semantic difference between that code and the same
>> without the "then:"?
>
> Chris,
>
> the semantic difference is that their meanings/behaviours are not identical
> (i imply that `then` here does what `else` currently does).  I agree however
> that from practical viewpoint the difference will probably never be
> observable (unless the person enters the bakery and asks for croissants, but
> during this time the baker exits the bakery and closes it to go on
> vacation).

Okay, so what you're doing is taking the current "try/else" semantics,
and hoisting the "happy path" up to immediately underneath the part
guarded by the try. That's not unreasonable, but also not a huge
advantage. It's basically saying:

try:
do_stuff
except None: # let's pretend
print("all is well")
except ValueError:
print("do_stuff has the wrong value")
finally:
print("we're done")

But if the difference between this and the current layout (with "else"
coming *after* the except blocks) is significant to you, I would
recommend refactoring the try/finally into a context manager:

with car_trip() as trip:
try:
trip.goto(bakery)
buy_croissants(2)
except BakeryClosed:
trip.goto(grocery)
buy_baguette(1)

The context manager takes care of bringing us home unconditionally,
leaving us with cleaner logic.

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

Re: Thread safety issue (I think) with defaultdict

[Chris Angelico]

On Sat, Nov 4, 2017 at 2:45 AM, Steve D'Aprano
 wrote:
> So, all else being equal, which is likely to have more bugs?
>
>
> 1. Multiprocessing code with very little coupling between processes; or
>
> 2. Threaded code with shared data and hence higher coupling between threads?
>

Obviously, option 1. But that's "all else being equal". How often can
you actually have your processes that decoupled? And if you can write
your code to be completely (or largely) decoupled, what's to stop you
having your *threads* equally decoupled? You're assuming that "running
in the same memoryspace" equates to "higher coupling", which is no
more proven than any other assertion. Ultimately, real-world code IS
going to have some measure of coupling (you could concoct a scenario
in which requests are handled 100% independent of each other, but even
with a web application, there's going to be SOME connection between
different requests), so all you do is move it around (eg in a web app
scenario, the most common solution is to do all coupling through a
database or equivalent).

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

Re: replacing `else` with `then` in `for` and `try`

[Alexey Muranov]

On Fri, 2017-11-03 at 22:03 +1100, Chris Angelico wrote:
> On Fri, Nov 3, 2017 at 8:48 PM, Alexey Muranov  com> wrote:
> > 'Then' describes what happens next indeed, unless some
> > extraordinary
> > situation prevents it from happening, for example:
> >
> > try:
> > go_to_the_bakery()
> > then:
> > buy_croissants(2)
> > except BakeryClosed:
> > go_to_the_grociery()
> > buy_baguette(1)
> > finally:
> > come_back()
> >
> > I know this is a poor program example (why not to use a boolean
> > return value
> > instead of an exception, etc.), and i know that currently in Python
> > `except`
> > must precede `else`, it is just to illustrate the choice of terms.
>
> What is the semantic difference between that code and the same
> without the "then:"?

Chris,

the semantic difference is that their meanings/behaviours are not 
identical (i imply that `then` here does what `else` currently does).  
I agree however that from practical viewpoint the difference will 
probably never be observable (unless the person enters the bakery and 
asks for croissants, but during this time the baker exits the bakery 
and closes it to go on vacation).


I can try to think of a better example if you give me any good use-case 
for `else` in `try`.  I have searched on-line, and on StackOverflow in 
particular, but didn't find anything better that this:


 * https://stackoverflow.com/a/6051978

People seem very shy when it comes to giving a real-life example of 
`else` in `try`.


Alexey.

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

Re: Thread safety issue (I think) with defaultdict

[Steve D'Aprano]

On Sat, 4 Nov 2017 01:50 am, Chris Angelico wrote:

> On Fri, Nov 3, 2017 at 10:26 PM, Rhodri James  wrote:

>> I'm with Steven.  To be fair, the danger with threads is that most people
>> don't understand thread-safety, and in particular don't understand either
>> that they have a responsibility to ensure that shared data access is done
>> properly or what the cost of that is.  I've seen far too much thread-based
>> code over the years that would have been markedly less buggy and not much
>> slower if it had been written sequentially.
> 
> Yes, but what you're seeing is that *concurrent* code is more
> complicated than *sequential* code. Would the code in question have
> been less buggy if it had used multiprocessing instead of
> multithreading? 

Maybe.

There's no way to be sure unless you actually compare a threading
implementation with a processing implementation -- and they have to
be "equally good, for the style" implementations. No fair comparing the
multiprocessing equivalent of "Stooge Sort" with the threading equivalent
of "Quick Sort", and concluding that threading is better.

However, we can predict the likelihood of which will be less buggy by
reasoning in general principles. And the general principle is that shared
data tends, all else being equal, to lead to more bugs than no shared data.
The more data is shared, the more bugs, more or less.

I don't know if there are any hard scientific studies on this, but experience
and anecdote strongly suggests it is true. Programming is not yet fully
evidence-based.

For example, most of us accept "global variables considered harmful". With few
exceptions, the use of application-wide global variables to communicate
between functions is harmful and leads to problems. This isn't because of any
sort of mystical or magical malignity from global variables. It is because
the use of global variables adds coupling between otherwise distant parts of
the code, and that adds complexity, and the more complex code is, the more
likely we mere humans are to screw it up.

So, all else being equal, which is likely to have more bugs?


1. Multiprocessing code with very little coupling between processes; or

2. Threaded code with shared data and hence higher coupling between threads?


Obviously the *best* threaded code will have fewer bugs than the *worst*
multiprocessing code, but my heuristic is that, in general, the average
application using threading is likely to be more highly coupled, hence more
complicated, than the equivalent using multiprocessing.

(Async is too new, and to me, too confusing, for me to have an opinion on yet,
but I lean slightly towards the position that deterministic task-switching is
probably better than non-deterministic.)



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: Thread safety issue (I think) with defaultdict

[Rhodri James]

On 03/11/17 14:50, Chris Angelico wrote:

On Fri, Nov 3, 2017 at 10:26 PM, Rhodri James  wrote:

On 02/11/17 20:24, Chris Angelico wrote:


Thank you. I've had this argument with many people, smart people (like
Steven), people who haven't grokked that all concurrency has costs -
that threads aren't magically more dangerous than other options.



I'm with Steven.  To be fair, the danger with threads is that most people
don't understand thread-safety, and in particular don't understand either
that they have a responsibility to ensure that shared data access is done
properly or what the cost of that is.  I've seen far too much thread-based
code over the years that would have been markedly less buggy and not much
slower if it had been written sequentially.


Yes, but what you're seeing is that *concurrent* code is more
complicated than *sequential* code. Would the code in question have
been less buggy if it had used multiprocessing instead of
multithreading? What if it used explicit yield points?


My experience with situations where I can do a reasonable comparison is 
limited, but the answer appears to be "Yes".

 Multiprocessing

brings with it a whole lot of extra complications around moving data
around.


People generally understand how to move data around, and the mistakes 
are usually pretty obvious when they happen.  People may not understand 
how to move data around efficiently, but that's a separate argument.


 Multithreading brings with it a whole lot of extra

complications around NOT moving data around.


I think this involves more subtle bugs that are harder to spot.  People 
seem to find it harder to reason about atomicity and realising that 
widely separated pieces of code may interact unexpectedly.


 Yield points bring with

them the risk of locking another thread out unexpectedly (particularly
since certain system calls aren't async-friendly on certain OSes).


I've got to admit I find coroutines straightforward, but I did cut my 
teeth on a cooperative OS.  It certainly makes the atomicity issues 
easier to deal with.


 All

three models have their pitfalls.


Assuredly.  I just think threads are soggier and hard to light^W^W^W^W^W 
prone to subtler and more mysterious-looking bugs.


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

[issue31920] pygettext ignores directories as inputfile argument

[Oleg Krasnikov]

Oleg Krasnikov  added the comment:

Thanks for quite sensible notes Serhiy. I've fixed all that in recent commit 
and added a regression test. Still not sure about "testing conventions" here 
cause this is my first PR to python repository, so please let me know if 
something is wrong and I'll fix that.

--

___
Python tracker 

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

[issue31699] Deadlocks in `concurrent.futures.ProcessPoolExecutor` with pickling error

[Thomas Moreau]

Change by Thomas Moreau :


--
keywords: +patch
pull_requests: +4218
stage:  -> patch review

___
Python tracker 

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

[issue31935] subprocess.run() timeout not working with grandchildren and stdout=PIPE

[Martin Ritter]

New submission from Martin Ritter :

Hi,

I tried to use 

subprocess.run(..., stdout=subprocess.PIPE, timeout=N)

to run some test scripts with a given timeout. 

This works as expected with simple scripts. However if the script itself 
creates other children which write to stdout then `subprocess.run()` seems to 
wait for all of the children to finish. I've attached a minimal example.

I looked into subprocess.py and `subprocess.run()` calls 
`process.communicate()` again without timeout when handling the TimeoutExpired 
exception which then in turn waits for the pipes to be closed by all children.

If communicate() would check if the process is still alive while waiting for 
output and close the pipes once the process has finished the timeout feature 
should work as expected and descendants would get a SIGPIPE when writing to 
stdout/stderr.

--
components: Library (Lib)
files: test_killsub.py
messages: 305487
nosy: Martin Ritter
priority: normal
severity: normal
status: open
title: subprocess.run() timeout not working with grandchildren and stdout=PIPE
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47251/test_killsub.py

___
Python tracker 

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

[issue31932] setup.py cannot find vcversall.bat on MSWin 8.1 if installed in user AppData

[Zachary Ware]

Change by Zachary Ware :


--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

___
Python tracker 

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

Re: Thread safety issue (I think) with defaultdict

[Chris Angelico]

On Fri, Nov 3, 2017 at 10:26 PM, Rhodri James  wrote:
> On 02/11/17 20:24, Chris Angelico wrote:
>>
>> Thank you. I've had this argument with many people, smart people (like
>> Steven), people who haven't grokked that all concurrency has costs -
>> that threads aren't magically more dangerous than other options.
>
>
> I'm with Steven.  To be fair, the danger with threads is that most people
> don't understand thread-safety, and in particular don't understand either
> that they have a responsibility to ensure that shared data access is done
> properly or what the cost of that is.  I've seen far too much thread-based
> code over the years that would have been markedly less buggy and not much
> slower if it had been written sequentially.

Yes, but what you're seeing is that *concurrent* code is more
complicated than *sequential* code. Would the code in question have
been less buggy if it had used multiprocessing instead of
multithreading? What if it used explicit yield points? Multiprocessing
brings with it a whole lot of extra complications around moving data
around. Multithreading brings with it a whole lot of extra
complications around NOT moving data around. Yield points bring with
them the risk of locking another thread out unexpectedly (particularly
since certain system calls aren't async-friendly on certain OSes). All
three models have their pitfalls. It's not that threads are somehow
worse than every other model.

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

Re: python3 byte decode

[Chris Angelico]

On Fri, Nov 3, 2017 at 8:24 PM, Ali Rıza KELEŞ  wrote:
> Hi,
>
> Yesterday, while working with redis, i encountered a strange case.
>
> I want to ask why is the following `True`
>
> ```
> "s" is b"s".decode()
> ```
>
> while the followings are `False`?
>
> ```
> "so" is b"so".decode()
> "som" is b"som".decode()
> "some" is b"some".decode()
> ```
>
> Or vice versa?
>
> I read that `is` compares same objects, not values. So my question is
> why "s" and b"s".decode() are same objects, while the others aren't?
>
> My python version is 3.6.3.

You shouldn't be comparing string objects with 'is'. Sometimes two
equal strings will be identical, and sometimes they won't. All you're
seeing is that the interpreter happened to notice and/or cache this
particular lookup.

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

python3 byte decode

[Ali Rıza KELEŞ]

Hi,

Yesterday, while working with redis, i encountered a strange case.

I want to ask why is the following `True`

```
"s" is b"s".decode()
```

while the followings are `False`?

```
"so" is b"so".decode()
"som" is b"som".decode()
"some" is b"some".decode()
```

Or vice versa?

I read that `is` compares same objects, not values. So my question is
why "s" and b"s".decode() are same objects, while the others aren't?

My python version is 3.6.3.

Thanks.

-- 
--
Ali Rıza Keleş
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: replacing `else` with `then` in `for` and `try`

[Chris Angelico]

On Fri, Nov 3, 2017 at 10:49 PM, Jon Ribbens  wrote:
> On 2017-11-03, Steve D'Aprano  wrote:
>> On Fri, 3 Nov 2017 03:31 am, Jon Ribbens wrote:
>>> No, it's an obvious bug. You have a 'for...else' with no 'break'.
>>> Like I said, that should probably be a syntax error.
>>
>> It should absolutely not be a syntax error. There's no reason for it
>> to be a syntax error, except to satisfy some arrogant and foolish
>> idea of purity.
>
> It'd be nice if you could be a little less rude. It's not an "arrogant
> and foolish idea of purity", it's to help people catch bugs in their
> code, and to aid their understanding of the language.

That wasn't rudeness. That was an accurate description of the
situation. It is entirely possible for code to be opinionated,
arrogant, foolish, and all those other adjectives that we normally
appropriate to people.

I don't think it would do much for comprehension. And if it's to catch
bugs, that is NOT the job of syntax - it's the job of linters. By all
means, have a linter that says "else clause after loop with no break";
but don't make it *illegal*.

>> There are uncountable ways of writing code which is seemingly
>> "pointless", and we don't make it a syntax error.
>
> And there's uncountable ways of writing code which we *do* make a
> syntax error. I'm not sure what your point is there.

The point is that syntax errors are for things that cannot possibly
make sense, not for things that are likely to be bugs.

There are a very few exceptions, and they're usually things that are
massive bug magnets, or where the semantics are subtly different. And
I can't think of any examples right now other than the way "async def"
forces a function to be a coroutine even if it has no "await"s in it;
note that it does *not* make a syntax error, it simply causes the
semantics to be correct anyway.

>>> No, 'then' describes the opposite of what it does. The word 'then'
>>> implies something that always happens next,
>>
>> Right, which is what happens with the for...else block.
>
> No. Ok, so look. It's obvious that you and I have different mental
> models of the situation here. You're thinking of 'for...else' as two
> arbitrary clauses that run consecutively unless the whole thing is
> aborted by a 'break', whereas I'm thinking of the 'for' clause as
> being a search for a situation that matches a condition and the
> 'else' clause being what happens if the condition is not matched
> (i.e. exactly the same as 'if...else').
>
> Now there's nothing inherently *wrong* with your choice of mental
> model, except it's leading you into confusion because my model means
> the meaning of the 'else' keyword is intuitive and obvious, and yours
> means it's counter-intuitive and confusing. Your suggestion is that
> the fix is to change the language, my suggestion is to fix your model.
> I'd suggest that changing your mind is easier than changing the
> language ;-)

If anything, I would say that Steven's model is at a lower abstraction
layer than yours - though IMO your model is more of an example
use-case than a description of what is actually happening.

>>> Yes, I saw that. It's possible you are the only person in the world
>>> ever to have done that. It would not make the interactive interpreter
>>> 'worse' in the slightest for that silly trick to be lost.
>>
>> Just because you personally haven't used this technique doesn't make it
>> a "silly trick".
>
> It's an incredibly obscure work-around for a different problem,
> i.e. an infelicity in the way the interactive prompt parses input
> blocks. If the parsing is a genuine issue then the answer is to
> fix that, not to look for hacks that almost never help anyway.

TBH I prefer the "if 1:" trick to gather code into a block. But that
requires pre-planning, whereas slapping an "else:" after the loop can
be done after the event.

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

[issue31934] Failure to build out of source from a not clean source

[Xavier de Gaye]

Change by Xavier de Gaye :


--
keywords: +patch
pull_requests: +4217
stage:  -> patch review

___
Python tracker 

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