[issue26067] test_shutil fails when gid name is missing

[Ezio Melotti]

Ezio Melotti added the comment:

We looked at this at the PyLadies Sprint in Helsinki.
When the group has an id but not a name (see "gid=203135016" in the "id" output 
-- the name is missing), its entry is missing from the list returned by 
grp.getgrall().

If this behaviour is expected and desired, then the test should be fixed to 
handle cases where the name is missing and the KeyError is raised.
Otherwise, the entry could still be included with "None" as name.

--
nosy: +serhiy.storchaka
stage:  -> needs patch
type:  -> behavior

___
Python tracker 

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

[issue26083] ValueError: insecure string pickle in subprocess.Popen on Python 2

[Gregory P. Smith]

Gregory P. Smith added the comment:

note: this was not a security issue nor was it a crash.  an exception was being 
raised anyways from the forked child prior to the exec(), this bug just caused 
that to be swallowed and this ValueError raised instead.

--
resolution:  -> fixed
stage:  -> commit review
status: open -> closed
type: crash -> behavior

___
Python tracker 

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

[issue25517] regex howto example in "Lookahead Assertions"

[Ezio Melotti]

Ezio Melotti added the comment:

Fixed, thanks for the patch!

--
resolution:  -> fixed
stage: needs patch -> 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

[issue25517] regex howto example in "Lookahead Assertions"

[Roundup Robot]

Roundup Robot added the comment:

New changeset c6b5c03183e3 by Ezio Melotti in branch '2.7':
#25517: fix regex in the regex howto.  Patch by Elena Oat.
https://hg.python.org/cpython/rev/c6b5c03183e3

New changeset 6bd4a4907f66 by Ezio Melotti in branch '3.5':
#25517: fix regex in the regex howto.  Patch by Elena Oat.
https://hg.python.org/cpython/rev/6bd4a4907f66

New changeset 48e2f5915d49 by Ezio Melotti in branch 'default':
#25517: merge with 3.5.
https://hg.python.org/cpython/rev/48e2f5915d49

--
nosy: +python-dev

___
Python tracker 

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

[issue25887] awaiting on coroutine more than once should be an error

[Brett Cannon]

Brett Cannon added the comment:

I don't like "coroutine was already awaited". I feel like either "on" should be 
appended to that or another sentence like "coroutine had 'await' called on it" 
or something.

--

___
Python tracker 

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

[issue25887] awaiting on coroutine more than once should be an error

[Yury Selivanov]

Yury Selivanov added the comment:

Nick,

> After all, waiting for the result with "await" is only one way to terminate a 
> coroutine - you can also get there with direct calls to next(), send(), 
> throw() and close().

Yes, but I expect that almost nobody will use 'send', 'throw' etc on 
coroutines, it's too low level.  In asyncio there is only one place where this 
magic happens.  Regular user will only understand the 'await' part -- that's 
why I wanted to mention it in the error message.

  async def something():
  await coro
  ^ RuntimeError('Cannot resume terminated coroutine')

The above use case might be a bit hard for users to actually understand, as 
opposed to

  async def something():
  await coro
  ^ RuntimeError('coroutine was already awaited on')

What do you think?

Martin, thanks for the review!

--

___
Python tracker 

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

[issue25486] Resurrect inspect.getargspec() in 3.6

[Martin Panter]

Martin Panter added the comment:

Now the documentation says it will be removed in 3.6. I guess the 3.5 
documentation also needs updating.

--
nosy: +martin.panter

___
Python tracker 

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

[issue26068] re.compile() repr end quote truncated

[Ezio Melotti]

Ezio Melotti added the comment:

FTR the repr was added in #13592.

--
nosy: +serhiy.storchaka
type:  -> behavior
versions: +Python 3.5, Python 3.6 -Python 3.4

___
Python tracker 

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

[issue25967] Devguide: add 2to3 to the "Changing CPython's Grammar" checklist

[Roundup Robot]

Roundup Robot added the comment:

New changeset 367486fbab84 by Ezio Melotti in branch 'default':
#25967: add note about updating lib2to3 when the grammar is updated.  Patch by 
Chris Thomas.
https://hg.python.org/devguide/rev/367486fbab84

--
nosy: +python-dev

___
Python tracker 

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

[issue23942] Explain naming of the patch files in the bug tracker

[Martin Panter]

Martin Panter added the comment:

I guess if people wonder about this, you could at least say the naming doesn’t 
matter very much for the review system.

If I am generating my own patches, I try to name them with one or two concise 
words describing the particular solution, and then insert “.v2”, “.v3” etc for 
the revised patches. If I just gave them an issue number, it would get lost my 
Mercurial patch queue among a sea of other numbers. If I did not add the “.v2” 
revision number, people would have to refer to the patches by upload date 
rather than name or version.

--
nosy: +martin.panter

___
Python tracker 

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

[issue26082] functools.lru_cache user specified cachedict support

[Josh Rosenberg]

Josh Rosenberg added the comment:

Given that lru_cache uses the cache dict in very specific ways, supporting 
arbitrary mapping types would be extremely hard. Among other things:

1. The C code uses the concrete dict APIs (including private APIs) that would 
not work on arbitrary mappings that don't directly inherit from dict (and often 
wouldn't work properly even if they do inherit from dict). Changing to use the 
abstract mapping APIs would slow all use cases for an extremely uncommon use 
case.

2. The C code is operating under the assumption that specific operations cannot 
release the GIL (e.g. dict insertion and deletion is done after precomputing 
the hash of the key, so it's impossible for Python byte code to be executed), 
so it can safely ignore thread safety issues. If a non-dict mapping was 
provided, implemented in Python rather than C, these assumptions could easily 
be violated.

3. This is basically a superset of the request from #23030, which rhettinger 
has rejected (you can read the rationale there)

--
nosy: +josh.r, rhettinger

___
Python tracker 

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

[issue26063] Update copyright in the devguide

[Roundup Robot]

Roundup Robot added the comment:

New changeset a4c18139d9b0 by Ezio Melotti in branch 'default':
#26063: future-proof copyright updating.
https://hg.python.org/devguide/rev/a4c18139d9b0

--

___
Python tracker 

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

[issue25888] awaiting on coroutine that is being awaited should be an error

[Yury Selivanov]

Yury Selivanov added the comment:

Will commit this patch tomorrow to 3.5 and 3.6.

It only affects coroutines (async defs): if an await expression is used on a 
coroutine object while it's being already awaited by another coroutine, a 
`RuntimeError("coroutine is being awaited already")` will be triggered.

--

___
Python tracker 

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

[issue25887] awaiting on coroutine more than once should be an error

[Nick Coghlan]

Nick Coghlan added the comment:

The patch looks good to me, but I'd like to see the error message convey two 
points:
- the coroutine has already terminated (regardless of how that happened)
- the calling code attempted to resume it anyway

That is, something like "Cannot resume terminated coroutine", rather than 
specifically referring to "await".

After all, waiting for the result with "await" is only one way to terminate a 
coroutine - you can also get there with direct calls to next(), send(), throw() 
and close().

--

___
Python tracker 

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

[issue25888] awaiting on coroutine that is being awaited should be an error

[Martin Panter]

Martin Panter added the comment:

Missing word in a comment on the review

--
nosy: +martin.panter

___
Python tracker 

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

[issue25887] awaiting on coroutine more than once should be an error

[Martin Panter]

Martin Panter added the comment:

The patch looks like it adds checks for the special generator-like send() etc 
methods, but I was expecting __await__() to also (or instead) do this check. 
That way you wouldn’t have to break the iterator protocol by the iterator not 
raising StopIteration a second time.

Also left some other review comments.

--

___
Python tracker 

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

[issue19251] bitwise ops for bytes of equal length

[Gregory P. Smith]

Changes by Gregory P. Smith :


--
nosy: +gregory.p.smith

___
Python tracker 

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

[issue25994] File descriptor leaks in os.scandir()

[Guido van Rossum]

Guido van Rossum added the comment:

It was a bit more subtle. I think like this:

def f():
with some_lock:
yield 0
yield 1

def g():
with another_lock:
it = f()
for i in it:
raise

We determined that another_lock was freed *before* some_lock.  This is because 
the local variable 'it' keeps the generator object returned by f() alive until 
after the with-block in g() has released another_lock.

I think this does not strictly require f to be a generator -- it's any kind of 
closable resource that only gets closed by its destructor.

The solution is to add a try/finally that calls it.close() before leaving the 
with-block in g().

Hope this helps.

--

___
Python tracker 

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

[issue26083] ValueError: insecure string pickle in subprocess.Popen on Python 2

[Roundup Robot]

Roundup Robot added the comment:

New changeset 268d13c7e939 by Gregory P. Smith in branch '2.7':
Fixes issue #26083: Workaround a subprocess bug that raised an incorrect
https://hg.python.org/cpython/rev/268d13c7e939

--
nosy: +python-dev

___
Python tracker 

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

[issue26086] Bug in standardmodule os

[Eryk Sun]

Changes by Eryk Sun :


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

[issue26086] Bug in standardmodule os

[Eryk Sun]

Eryk Sun added the comment:

The "yield from" syntax was added in Python 3.3, so somehow you're using the 
3.5 standard library with either an old 3.x or 2.x version. The older version 
shouldn't use 3.5's standard library, unless you have either PYTHONHOME or 
PYTHONPATH defined. Generally neither of these variables should be defined, 
especially not PYTHONHOME. In the command prompt run "set PYTHON" to list all 
environment variables that start with "PYTHON".

You also appear to be running with the 3.5 site-packages as the working 
directory. Even without the other problems, I recommend against this since the 
current directory has precedence in sys.path. You're moving site-packages to 
the head of the list, in front of the standard library. For example:

C:\Program Files\Python35\Lib\site-packages>type subprocess.py
print("This isn't the subprocess you're looking for.")

C:\Program Files\Python35\Lib\site-packages>py -3 -c "import subprocess"
This isn't the subprocess you're looking for.

Save your scripts in the top-level Scripts directory or a directory in your 
user profile. Generally leave everything under Lib alone, to be managed by pip 
and other installers.

--
nosy: +eryksun

___
Python tracker 

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

[issue25887] awaiting on coroutine more than once should be an error

[Yury Selivanov]

Yury Selivanov added the comment:

Attaching another patch.  Please review (I plan to commit it tomorrow in 3.5 
and 3.6 branches).

The patch affects generators machinery in the following way:

1. Generators behaviour isn't touched, the patch is only for 'async def' 
coroutines.

2. Calling 'send()' or 'throw()' on a coroutine object after it is exhausted or 
closed triggers a `RuntimeError("coroutine was already awaited")`

3. Calling 'close()' method on an exhausted or closed coroutines is a no-op.  
'close()' can be called multiple times -- same as for generators.

--
Added file: http://bugs.python.org/file41587/Issue25887_3.patch

___
Python tracker 

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

[issue25994] File descriptor leaks in os.scandir()

[Martin Panter]

Martin Panter added the comment:

Guido are you saying in the following code, the “finally” message is not 
guaranteed to be printed out? Or just that you cannot limit a ResourceWarning 
to garbage collection?

def g():
try:
yield "item"
finally:
# Run at exhaustion, close(), and garbage collection
print("finally")

gi = g()
try:
item = next(gi)
print(item / 2)  # Oops, TypeError
finally:
# Should be run as the exception passes through. GeneratorExit is raised 
inside the generator, causing the other “finally” block to execute. All before 
the original exception is caught and a traceback is printed.
gi.close()

But as I understand it, os.scandir() is not a generator, so none of these 
problems would apply.

--
nosy: +martin.panter

___
Python tracker 

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

[issue26083] ValueError: insecure string pickle in subprocess.Popen on Python 2

[Gregory P. Smith]

Gregory P. Smith added the comment:

I strongly recommend people use https://pypi.python.org/pypi/subprocess32/ 
instead of Python 2.7's subprocess module whenever possible.

That said, the fix is pretty easy.

--
assignee:  -> gregory.p.smith

___
Python tracker 

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

[issue26083] ValueError: insecure string pickle in subprocess.Popen on Python 2

[Eryk Sun]

Eryk Sun added the comment:

> I strongly recommend people use https://pypi.python.org/pypi/subprocess32/

I think this warrants a note that draws more attention to itself than the "see 
also" text.

--
nosy: +eryksun

___
Python tracker 

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

[issue25967] Devguide: add 2to3 to the "Changing CPython's Grammar" checklist

[Ezio Melotti]

Ezio Melotti added the comment:

Fixed, thanks for the patch!

--
resolution:  -> fixed
stage: needs patch -> 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

[issue25887] awaiting on coroutine more than once should be an error

[Yury Selivanov]

Yury Selivanov added the comment:

> I don't like "coroutine was already awaited". I feel like either "on" should 
> be appended to that or another sentence like "coroutine had 'await' called on 
> it" or something.

Fine with me to have "coroutine was already awaited on".

--

___
Python tracker 

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

[issue25994] File descriptor leaks in os.scandir()

[Martin Panter]

Martin Panter added the comment:

Okay I understand. You have to explicitly call the close() method if you want a 
generator to be cleaned up properly, which parallels how Serhiy’s proposal 
would be used.

--

___
Python tracker 

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

[issue25887] awaiting on coroutine more than once should be an error

[Yury Selivanov]

Yury Selivanov added the comment:

Attaching an updated patch.  The RuntimeError says 'coroutine was already 
awaited on' for now.

--
Added file: http://bugs.python.org/file41588/Issue25887_4.patch

___
Python tracker 

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

[issue25991] readline example eventually consumes all memory

[Martin Panter]

Martin Panter added the comment:

Thanks Ezio for handling this. Ignore my previous comment; I missed the key 
word “example” :)

--

___
Python tracker 

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

[issue25788] fileinput.hook_encoded has no way to pass arguments to codecs

[Terry J. Reedy]

Terry J. Reedy added the comment:

fileinput is in Python, hence the source is in Lib.  Online version is
https://hg.python.org/cpython/file/tip/Lib/fileinput.py
https://hg.python.org/cpython/file/tip/Lib/test/test_fileinput.py

Patching openhook itself looks trivial.  A test is the hard part. Laura, can 
you provide a test case? -- a short (one line?) file that fails with 
errors=strict and passes with something else?  A new test_errors method should 
be added to class Test_hook_encoded (the last testCase in the file).  I think 
the 'test' method would need revision.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue25348] Update pgo_build.bat to use --pgo flag for regrtest

[Roundup Robot]

Roundup Robot added the comment:

New changeset 113c524aed93 by Zachary Ware in branch '2.7':
Issue #25348: Add --pgo and --pgo-job flags to PCbuild\build.bat
https://hg.python.org/cpython/rev/113c524aed93

New changeset 01ab138f4133 by Zachary Ware in branch '3.5':
Issue #25348: Add --pgo and --pgo-job flags to PCbuild\build.bat
https://hg.python.org/cpython/rev/01ab138f4133

New changeset 9442b4a60379 by Zachary Ware in branch 'default':
Closes #25348: Merge with 3.5
https://hg.python.org/cpython/rev/9442b4a60379

--
nosy: +python-dev
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

[issue25348] Update pgo_build.bat to use --pgo flag for regrtest

[Zachary Ware]

Zachary Ware added the comment:

Thanks for the review, Steve.

--
assignee: brett.cannon -> zach.ware

___
Python tracker 

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

[issue21955] ceval.c: implement fast path for integers with a single digit

[Zach Byrne]

Zach Byrne added the comment:

Anybody still looking at this? I can take another stab at it if it's still in 
scope.

--

___
Python tracker 

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

[issue25887] awaiting on coroutine more than once should be an error

[Yury Selivanov]

Yury Selivanov added the comment:

"Cannot await previously awaited coroutine" might be confusing if raised on 
"coro.send(..)"-like code...

So far "coroutine was already awaited on" (do you want to drop "was", btw?) is 
less of all evil IMHO.

--

___
Python tracker 

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

[issue21955] ceval.c: implement fast path for integers with a single digit

[Zach Byrne]

Zach Byrne added the comment:

> Can you figure why unpack_sequence and other benchmarks were slower?
I didn't look really closely, A few of the slower ones were floating point 
heavy, which would incur the slow path penalty, but I can dig into 
unpack_sequence.

--

___
Python tracker 

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

[issue25887] awaiting on coroutine more than once should be an error

[Yury Selivanov]

Yury Selivanov added the comment:

Oh, choosing a good error message is hard :(

I've a few comments.  Sorry, this thread is growing rather rapidly, but please 
help me to pick one of them:


> From the point of view of the error message, the reason I changed my 
> suggestion was because I liked your idea of optimising it for the "only using 
> await" case and trusting that the folks delving into the lower level plumbing 
> of calling methods manually can figure it out. [...]

We either have to use a sub-optimal error message tailored for 'await' 
expression users, or we can choose a longer error message.  I'm not very fond 
of this option, but maybe it's because I can't come up with something long and 
concise at the same time.  Maybe something along the lines of: "cannot resume 
terminated coroutine (was it awaited on before?)"


> That is, "Cannot resume terminated coroutine" is always accurate, but relies 
> on the reader knowing that "await" both resumes a coroutine and waits for it 
> to terminate.

Not sure I like the "terminated" word here.  The coroutine was either awaited 
before, which means that the coroutine object is now exhausted, or it was 
manually closed at some point.  To me "terminated" is closer to the latter.


> "Coroutine was previously awaited on" may be wrong about how the coroutine 
> was originally terminated, but at least hints that the error may be related 
> to awaiting the coroutine.

Agree.


> "Cannot resume previously awaited coroutine" would be inaccurate under the 
> same circumstances.

Thinking about "resume"...  If a user sees this message pointing to an "await" 
expression, it might confuse them, since "await coro" does not just resume 
"coro".  It inits and consumes "coro" until it raises a StopIteration.


"Cannot await previously awaited coroutine" would only be entirely accurate for 
"double await" errors, but doesn't rely on the reader making any assumptions at 
all in that case.

Agree.  But I don't like that we have two "await" words in one short message.


> (The bulk of the problem here is that my brain is happy to accept "awaited" 
> as a novel adjective modifying "coroutine", but balks at "awaited" as a verb 
> or "awaited on" as a verb phrase. I'm extrapolating from that to guess that 
> other folks would find the verb form similarly jarring)

I trust your brain here, you're a native speaker ;)  If you think that "Cannot 
await previously awaited coroutine" is the best option here, let's stick to it.

--

___
Python tracker 

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

[issue25486] Resurrect inspect.getargspec() in 3.6

[Yury Selivanov]

Yury Selivanov added the comment:

> Now the documentation says it will be removed in 3.6. I guess the 3.5 
> documentation also needs updating.

Good catch!

--

___
Python tracker 

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

[issue21955] ceval.c: implement fast path for integers with a single digit

[Yury Selivanov]

Yury Selivanov added the comment:

> Anybody still looking at this? I can take another stab at it if it's still in 
> scope.

There were some visible speedups from your patch -- I think we should merge 
this optimization.  Can you figure why unpack_sequence and other benchmarks 
were slower?

--
nosy: +yselivanov

___
Python tracker 

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

[issue25887] awaiting on coroutine more than once should be an error

[Nick Coghlan]

Nick Coghlan added the comment:

Sorry, dropping the "was" was a typo (I should have copied & pasted it instead 
of rewriting).

>From the point of view of the error message, the reason I changed my 
>suggestion was because I liked your idea of optimising it for the "only using 
>await" case and trusting that the folks delving into the lower level plumbing 
>of calling methods manually can figure it out. Anything that mentions await 
>*at all* will be wrong in some cases, since what we're actually reporting is 
>an attempt to resume (by some means) a coroutine that was previously 
>terminated (by some means).

That is, "Cannot resume terminated coroutine" is always accurate, but relies on 
the reader knowing that "await" both resumes a coroutine and waits for it to 
terminate.

"Coroutine was previously awaited on" may be wrong about how the coroutine was 
originally terminated, but at least hints that the error may be related to 
awaiting the coroutine.

"Cannot resume previously awaited coroutine" would be inaccurate under the same 
circumstances.

"Cannot await previously awaited coroutine" would only be entirely accurate for 
"double await" errors, but doesn't rely on the reader making any assumptions at 
all in that case.

(The bulk of the problem here is that my brain is happy to accept "awaited" as 
a novel adjective modifying "coroutine", but balks at "awaited" as a verb or 
"awaited on" as a verb phrase. I'm extrapolating from that to guess that other 
folks would find the verb form similarly jarring)

--

___
Python tracker 

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

[issue25887] awaiting on coroutine more than once should be an error

[Nick Coghlan]

Nick Coghlan added the comment:

I expect whatever message we use will become a Stack Overflow question in 
fairly short order, so "good enough" is almost certainly good enough here, and 
I'm massively overthinking the problem :)

However, combining my last suggestion with a variant of Martin's would give us:

"Cannot reuse already awaited coroutine"

The generic "reuse" both eliminated the repetition of "await", and also gets us 
away from worrying about exactly what the caller was doing.

--

___
Python tracker 

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

[issue25887] awaiting on coroutine more than once should be an error

[Yury Selivanov]

Yury Selivanov added the comment:

> IMO “yield from coroutine_iterator” might be plausable for some strange 
> combination of 3.4 code and a 3.5 coroutine, but I think it would be rare. 
> And if you added a check in __await__() then the using “await” wouldn’t need 
> to rely on next() raising the RuntimeError.

Adding the check *only* to __await__ will allow you to wrap an exhausted 
coroutine in an 'asyncio.Task' and await on it (the await will do nothing, 
which this patch fixes).

I think it's important to fix all coroutines' APIs to throw an error if they're 
manipulated in any way after being exhausted/closed, that's why I decided to 
fix the lower level.

To be honest, I don't care too much about 'yield from coro.__await__()' raising 
a RuntimeError (if the coro is an 'async def' coroutine that *is* 
closed/exhausted).  To me it's a clear behaviour.  Again, coroutine-iterators 
(objects returned by native coroutines from their __await__() method) aren't 
classical iterators meant to produce a fibonacci sequence in a for..in loop.  
They are a low level interface to their coroutine objects.

--

___
Python tracker 

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

[issue25887] awaiting on coroutine more than once should be an error

[Martin Panter]

Martin Panter added the comment:

Isn’t the combined point of this issue and Issue 25888 to make it only legal to 
“await” a coroutine instance that has not yet been started? Perhaps “Cannot 
[re]start terminated coroutine” would be better.

--

___
Python tracker 

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

[issue24712] Docs page's sidebar vibrates on mouse wheel scroll on Chrome.

[Mike Taylor]

Mike Taylor added the comment:

I can reproduce on Chrome and Firefox Nightly --

Carol, if I'd like to write a patch where would I do that? I see 
https://github.com/python/pythondotorg, but am not sure that's the right repo. 
Thanks!

--
nosy: +Mike Taylor

___
Python tracker 

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

[issue25887] awaiting on coroutine more than once should be an error

[Nick Coghlan]

Nick Coghlan added the comment:

Good point about having "await" in the error message to make it more obvious 
what it's referring to in the "awaiting twice" case.

I'll tender "Cannot await previously awaited coroutine" as one final 
alternative, but if you don't like that, I can cope with "Coroutine already 
awaited on" :)

--

___
Python tracker 

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

[issue26087] PEP 0373 should be updated

[Chi Hsuan Yen]

New submission from Chi Hsuan Yen:

Current PEP 0373 lists Python 2.7.11 as a future release, and there's no 
information about Python 2.7.12. Please update it, thanks!

--
assignee: docs@python
components: Documentation
messages: 258063
nosy: Chi Hsuan Yen, docs@python
priority: normal
severity: normal
status: open
title: PEP 0373 should be updated
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

[issue25887] awaiting on coroutine more than once should be an error

[Yury Selivanov]

Yury Selivanov added the comment:

>"Cannot reuse already awaited coroutine"

Great, I like it!  Thanks Martin and Nick.

Please check out issue #25888 just in case.

--

___
Python tracker 

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

[issue25486] Resurrect inspect.getargspec() in 3.6

[Roundup Robot]

Roundup Robot added the comment:

New changeset 36a54e30bcbd by Yury Selivanov in branch '3.5':
Issue #25486: Drop "removed in 3.6" wording from inspect.getargspec docs.
https://hg.python.org/cpython/rev/36a54e30bcbd

New changeset 4f1a0e5deca6 by Yury Selivanov in branch 'default':
Merge 3.5 (issue #25486)
https://hg.python.org/cpython/rev/4f1a0e5deca6

--

___
Python tracker 

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

[issue25887] awaiting on coroutine more than once should be an error

[Martin Panter]

Martin Panter added the comment:

If the coroutine-iterator is going to raise RuntimeError rather than 
StopIteration, do you think the __await__() documentation 
 should 
be clarified?

IMO “yield from coroutine_iterator” might be plausable for some strange 
combination of 3.4 code and a 3.5 coroutine, but I think it would be rare. And 
if you added a check in __await__() then the using “await” wouldn’t need to 
rely on next() raising the RuntimeError.

--

___
Python tracker 

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

[issue26085] Tkinter spoils the input text

[fresh_nick]

New submission from fresh_nick:

Hello, I have Python 3.4.3 and Tk/Tcl 8.5 (built in Python; reported by 
tk.TclVersion and tk.TkVersion). When I assign printing 'This works' to a 
hotkey, the program prints 'This worsk'. After pressing the hotkey again, 
'worsk' is replaced with 'works', but when the hotkey is pressed repeatedly, we 
can see 'worsk' sometimes (see the attachment).

Have a nice day.

--
components: Tkinter
files: 2016-01-11--1452545267_1920x1080_scrot.png
messages: 258019
nosy: fresh_nick
priority: normal
severity: normal
status: open
title: Tkinter spoils the input text
type: behavior
versions: Python 3.4
Added file: 
http://bugs.python.org/file41585/2016-01-11--1452545267_1920x1080_scrot.png

___
Python tracker 

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

[issue26083] ValueError: insecure string pickle in subprocess.Popen on Python 2

[Ned Deily]

Changes by Ned Deily :


--
nosy: +gregory.p.smith

___
Python tracker 

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

[issue25991] readline example eventually consumes all memory

[Roundup Robot]

Roundup Robot added the comment:

New changeset 9a2c891a4333 by Ezio Melotti in branch '2.7':
#25991: fix readline example to limit history size.  Patch by Daniel Dye.
https://hg.python.org/cpython/rev/9a2c891a4333

New changeset 416db1a2fb81 by Ezio Melotti in branch '3.5':
#25991: fix readline example to limit history size.  Patch by Daniel Dye.
https://hg.python.org/cpython/rev/416db1a2fb81

New changeset cb08e5271cc0 by Ezio Melotti in branch 'default':
#25991: merge with 3.5.
https://hg.python.org/cpython/rev/cb08e5271cc0

--
nosy: +python-dev

___
Python tracker 

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

[issue25991] readline example eventually consumes all memory

[Ezio Melotti]

Ezio Melotti added the comment:

Fixed, thanks for the patch!

--
resolution:  -> fixed
stage: needs patch -> 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

[issue25995] os.walk() consumes a lot of file descriptors

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Both patches are basically equivalent. The first one collects all scandir() 
results in a list, the second one collects only directory names in a list. The 
purpose of using os.scandir() in os.walk() was a speed up (issue23605), and 
both patches preserve it.

Yes, the number of FDs used is equivalent to the depth of the tree which can be 
very deep (I just created a tree depth of 1000 levels). And what is worse, all 
these FDs can be effectively leaked if the walking was not finished. This is 
unwanted behavior change.

--

___
Python tracker 

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

[issue26086] Bug in standardmodule os

[Hana Larsen]

New submission from Hana Larsen:

I get a error in the stardard module "os" (I use Python 3.5.1 64bit for Windows 
10!)
What is wrong and have someone a patch
See the "os-bug.PNG"-file.

--
files: os-bug.PNG
messages: 258023
nosy: Johano
priority: normal
severity: normal
status: open
title: Bug in standardmodule os
type: crash
versions: Python 3.5
Added file: http://bugs.python.org/file41586/os-bug.PNG

___
Python tracker 

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

[issue24918] Docs layout bug

[Ezio Melotti]

Ezio Melotti added the comment:

Georg, do you have any opinion on this?
AFAIK all the div.highlight contain a  with the actual code and it's own 
background color, so using background: none; should be fine.

--
nosy: +georg.brandl
stage: needs patch -> patch review

___
Python tracker 

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

[issue26041] Update deprecation messages of platform.dist() and platform.linux_distribution()

[Ezio Melotti]

Changes by Ezio Melotti :


--
stage: needs patch -> patch review

___
Python tracker 

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

[issue25995] os.walk() consumes a lot of file descriptors

[Guido van Rossum]

Guido van Rossum added the comment:

I am all for preventing the leaks. But using FDs proportional to the tree
depth seems reasonable to me. (If you are worried about some kind of DoS
attack on the algorithm by someone who can build a tree with depth 1000,
well, if they can do that they can also create a flat folder with a million
files in it.)

Is there a potential hybrid strategy, where for small directories we close
the FD but for large directories we keep it open?

--

___
Python tracker 

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

[issue25486] Resurrect inspect.getargspec() in 3.6

[Roundup Robot]

Roundup Robot added the comment:

New changeset 32c8bdcd66cc by Yury Selivanov in branch 'default':
Issue #25486: Resurrect inspect.getargspec in 3.6. Backout a565aad5d6e1.
https://hg.python.org/cpython/rev/32c8bdcd66cc

--
nosy: +python-dev

___
Python tracker 

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

[issue26083] ValueError: insecure string pickle in subprocess.Popen on Python 2

[Chi Hsuan Yen]

New submission from Chi Hsuan Yen:

Originally reported at [1] and [2].

On Mac OS X, read() on pipes may return only the first 512 bytes. The remaining 
bytes are not read into `data` in _execute_child(). There's a patch proposal at 
[3]. I didn't test it myself because I can't reproduce the broken situation.

[1] https://github.com/rg3/youtube-dl/issues/6840
[2] https://github.com/matplotlib/matplotlib/issues/5386
[3] https://github.com/matplotlib/matplotlib/issues/5386#issuecomment-16817

--
components: Library (Lib), Macintosh
messages: 258011
nosy: Chi Hsuan Yen, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: ValueError: insecure string pickle in subprocess.Popen on Python 2
type: crash
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

[issue26084] HTMLParser mishandles last attribute in self-closing tag

[Tom Anderl]

New submission from Tom Anderl:

When the HTMLParser encounters a start tag element that includes:
  1. an unquoted attribute as the final attribute 
  2. an optional '/' character marking the start tag as self-closing
  3. no space between the final attribute and the '/' character

the '/' character gets attached to the attribute value and the element is 
interpreted as not self-closing.  This can be illustrated with the following:

===

import HTMLParser

# Begin Monkeypatch
#import re
#HTMLParser.attrfind = re.compile(
#r'((?<=[\'"\s/])[^\s/>][^\s/=>]*)(\s*=+\s*'
#r'(\'[^\']*\'|"[^"]*"|(?![\'"])[^/>\s]*))?(?:\s|/(?!>))*')
# End Monkeypatch

class MyHTMLParser(HTMLParser.HTMLParser):
def handle_starttag(self, tag, attrs):
print('got starttag: {0} with attributes {1}'.format(tag, attrs))

def handle_endtag(self, tag):
print('got endtag: {0}'.format(tag))

MyHTMLParser().feed('')

==

Running the above code yields the output:

got starttag: img with attributes [('height', '1.0'), ('width', '2.0/')]

Note the trailing '/' on the 'width' attribute.  If I uncomment the monkey 
patch, the script then yields:

got starttag: img with attributes [('height', '1.0'), ('width', '2.0')]
got endtag: img

Note that the trailing '/' is gone, and an endtag event was generated.

--
components: Library (Lib)
messages: 258013
nosy: Tom Anderl
priority: normal
severity: normal
status: open
title: HTMLParser mishandles last attribute in self-closing tag
type: behavior
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

[issue23942] Explain naming of the patch files in the bug tracker

[Maciej Szulik]

Maciej Szulik added the comment:

Ezio, I've meant we should provide some guidelines with information the system 
will pick whatever they choose based on submission date. More informational 
than as a requirement.

--

___
Python tracker 

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

[issue25596] Use scandir() to speed up the glob module

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Not this version of the path. It accumulates all scandir results in a list 
before yielding values. Otherwise globbing will consume a lot of open file 
descriptors and could leak them (see issue25994, issue25995).

--

___
Python tracker 

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

[issue25994] File descriptor leaks in os.scandir()

[Guido van Rossum]

Guido van Rossum added the comment:

Note there's also a nasty corner case related to generators and GC. If a 
generator contains a with-block or finally-clause, and the generator is not run 
until its end because the caller hit an exception on one of the items returned, 
and the generator object is somehow kept alive (either because it's stored in 
some longer-living state or because the Python implementation doesn't use 
reference counting) then the close() call in the finally-clause or in the 
__exit__ method doesn't run until the generator object is garbage-collected.

IOW even making it a context manager doesn't completely solve this issue 
(though it can certainly help).

--
nosy: +gvanrossum

___
Python tracker 

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

[issue25486] Resurrect inspect.getargspec() in 3.6

[Yury Selivanov]

Yury Selivanov added the comment:

inspect.getargspec is back to Python 3.6 (it was never removed from <= 3.5, 
fwiw)

--
resolution:  -> fixed
stage: needs patch -> 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

[issue25486] Resurrect inspect.getargspec() in 3.6

[Stefan Krah]

Stefan Krah added the comment:

On Mon, Jan 11, 2016 at 08:17:11PM +, Yury Selivanov wrote:
> inspect.getargspec is back to Python 3.6 (it was never removed from <= 3.5, 
> fwiw)

Yay! Thank you very much!

--

___
Python tracker 

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

[issue24705] sysconfig._parse_makefile doesn't expand ${} vars appearing before $() vars

[Roundup Robot]

Roundup Robot added the comment:

New changeset ef84d21f5292 by doko in branch '3.5':
- Issue #24705: Fix sysconfig._parse_makefile not expanding ${} vars
https://hg.python.org/cpython/rev/ef84d21f5292

--
nosy: +python-dev

___
Python tracker 

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

[issue26084] HTMLParser mishandles last attribute in self-closing tag

[Ezio Melotti]

Changes by Ezio Melotti :


--
assignee:  -> ezio.melotti
nosy: +ezio.melotti
stage:  -> test needed

___
Python tracker 

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

[issue23942] Explain naming of the patch files in the bug tracker

[R. David Murray]

Changes by R. David Murray :


--
nosy:  -r.david.murray

___
Python tracker 

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

[issue25596] Use scandir() to speed up the glob module

[Guido van Rossum]

Guido van Rossum added the comment:

Oh well. Too bad. Never mind then.

--

___
Python tracker 

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

[issue25995] os.walk() consumes a lot of file descriptors

[Guido van Rossum]

Guido van Rossum added the comment:

I don't like the first solution (it just collects all scandir() results in a 
list, which defeats one of the purposes of using scandir()), but I don't 
understand the second solution.

Ideally the number of FDs used should be limited by the depth of the tree being 
walked, right?

--
nosy: +gvanrossum

___
Python tracker 

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

[issue25596] Use scandir() to speed up the glob module

[Guido van Rossum]

Guido van Rossum added the comment:

Looks like switching to scandir will also resolve 
http://bugs.python.org/issue22167 without further action.

--

___
Python tracker 

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

[issue22167] iglob() has misleading documentation (does indeed store names internally)

[Guido van Rossum]

Guido van Rossum added the comment:

Once http://bugs.python.org/issue25596 (switching glob to use scandir) is 
solved this issue can be closed IMO.

--
nosy: +gvanrossum

___
Python tracker 

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

[issue11245] Implementation of IMAP IDLE in imaplib?

[Maciej Szulik]

Changes by Maciej Szulik :


--
nosy: +maciej.szulik

___
Python tracker 

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

[issue25596] Use scandir() to speed up the glob module

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
title: Use scandir() to speed the glob module -> Use scandir() to speed up the 
glob module

___
Python tracker 

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

[issue22642] trace module: unclear error message

[Senthil Kumaran]

Senthil Kumaran added the comment:

I reviewed the patch. It looks like the problem is not just with list functions 
but with other options too. Like.

$ ./python.exe -m trace -t
$ ./python.exe -m trace -c
$ ./python.exe -m trace -T

Will throw the same error. So, any changes should address all these cases 
instead of a single listfunctions (-l) case only.

--
nosy: +orsenthil

___
Python tracker 

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

[issue26079] Build with Visual Studio 2015 using PlatformToolset=v120

[Bjoern Thiel]

New submission from Bjoern Thiel:

Fixing the build output folder for tix-8.4.3.6.

--
components: Build
files: build.patch
keywords: patch
messages: 257956
nosy: bjoernthiel
priority: normal
severity: normal
status: open
title: Build with Visual Studio 2015 using PlatformToolset=v120
type: crash
versions: Python 3.5
Added file: http://bugs.python.org/file41578/build.patch

___
Python tracker 

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

[issue25596] Use scandir() to speed up the glob module

[Ben Hoyt]

Ben Hoyt added the comment:

Nice! Good to see scandir() getting used to speed up other functions, functions 
that folks are using a ton already, like glob().

--

___
Python tracker 

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

[issue26032] Use scandir() to speed up pathlib globbing

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Proposed minimal patch implements globbing in pathlib using os.scandir(). Here 
are results of microbenchmarks:

$ ./python -m timeit -s "from pathlib import Path; p = Path()" -- 
"list(p.glob('**/*'))"
Unpatched: 598 msec per loop
Patched:   372 msec per loop

$ ./python -m timeit -s "from pathlib import Path; p = Path('/usr/')" -- 
"list(p.glob('lib*/**/*'))"
Unpatched: 1.33 sec per loop
Patched:   804 msec per loop

$ ./python -m timeit -s "from pathlib import Path; p = Path('/usr/')" -- 
"list(p.glob('lib*/**/'))"
Unpatched: 750 msec per loop
Patched:   180 msec per loop

See msg257954 in issue25596 for comparison with the glob module.

--
assignee:  -> serhiy.storchaka
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file41577/pathlib_glob_scandir.patch

___
Python tracker 

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

[issue26079] Build with Visual Studio 2015 using PlatformToolset=v120

[SilentGhost]

Changes by SilentGhost :


--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
type: crash -> compile error

___
Python tracker 

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

[issue26071] bdist_wininst created binaries fail to start and find 32bit Pythons

[Steve Dower]

Steve Dower added the comment:

The downside of the preprocessor - no errors when you spell an ifdef wrong ;)

It looks good to me.

--

___
Python tracker 

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

[issue7559] TestLoader.loadTestsFromName swallows import errors

[Matej Cepl]

Changes by Matej Cepl :


--
nosy: +mcepl

___
Python tracker 

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

[issue25348] Update pgo_build.bat to use --pgo flag for regrtest

[Steve Dower]

Steve Dower added the comment:

LGTM

--

___
Python tracker 

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

[issue26080] "abandonned" -> "abandoned" in PEP 510's https://hg.python.org/peps/rev/b463c740990c

[Roundup Robot]

Roundup Robot added the comment:

New changeset 63151533cebf by Victor Stinner in branch 'default':
PEP 510: abandonned => abandoned
https://hg.python.org/peps/rev/63151533cebf

--
nosy: +python-dev

___
Python tracker 

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

[issue26059] Integer Overflow in strop.replace()

[Ramin Farajpour Cami]

Ramin Farajpour Cami added the comment:

The issue can be triggered by performing a large substitution that overflows 
the arithmetic used in mymemreplace() to calculate the size of the new string:

--

___
Python tracker 

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

[issue26079] Build with Visual Studio 2015 using PlatformToolset=v120

[Steve Dower]

Steve Dower added the comment:

It's better than using the Visual Studio version, which isn't necessarily tied 
to any VC version. To support another compiler will require more code like this 
anyway.

An alternative may be to patch Tcl et al. to not put the VC version into the 
output path? That's likely to lead to different problems for people though...

--

___
Python tracker 

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

[issue26059] Integer Overflow in strop.replace()

[Ramin Farajpour Cami]

Ramin Farajpour Cami added the comment:

please look image : 


Thanks,

--
Added file: http://bugs.python.org/file41580/123.PNG

___
Python tracker 

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

[issue26058] PEP 509: Add ma_version to PyDictObject

[STINNER Victor]

STINNER Victor added the comment:

Patch version 3 updated for the second version of the PEP 509. Main changes:

* ma_version now has the type PY_UINT64_T
* remove dict.__version__ property: replace with _testcapi.dict_get_version() 
for tests

--
versions: +Python 3.6 -Python 2.7
Added file: http://bugs.python.org/file41581/dict_version-3.patch

___
Python tracker 

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

[issue24955] webbrowser broken on Mac OS X when using the BROWSER variable

[Senthil Kumaran]

Senthil Kumaran added the comment:

The patch is correct and will fix the issue. It will require test coverage to 
be complete so that we don't land upon similar issues in future.

--
nosy: +orsenthil
stage:  -> test needed
versions: +Python 3.5, Python 3.6 -Python 3.4

___
Python tracker 

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

[issue26081] Implement asyncio Future in C to improve performance

[Yury Selivanov]

New submission from Yury Selivanov:

Some info on this: 
https://github.com/python/asyncio/issues/282#issuecomment-155957235  Long story 
short, Future implemented in C can speedup some asyncio code up to 25%.

I'm attaching a patch with a WIP implementation.  There are some failing 
assertions deep in GC, which I need to track down.  
'Future.remove_done_callback' still needs to be properly implemented.

--
assignee: yselivanov
components: asyncio
files: futures.patch
keywords: patch
messages: 257984
nosy: gvanrossum, haypo, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: Implement asyncio Future in C to improve performance
type: performance
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41579/futures.patch

___
Python tracker 

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

[issue26050] Add new StreamReader.readuntil() method

[Yury Selivanov]

Changes by Yury Selivanov :


--
Removed message: http://bugs.python.org/msg257983

___
Python tracker 

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

[issue26059] Integer Overflow in strop.replace()

[Ramin Farajpour Cami]

Ramin Farajpour Cami added the comment:

Do you have any idea how to fix it?

--

___
Python tracker 

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

[issue26050] Add new StreamReader.readuntil() method

[Roundup Robot]

Roundup Robot added the comment:

New changeset db11d0db1598 by Yury Selivanov in branch '3.4':
Issue #26050: Add asyncio.StreamReader.readuntil() method.
https://hg.python.org/cpython/rev/db11d0db1598

New changeset a6288fe5420f by Yury Selivanov in branch '3.5':
Merge 3.4 (Issue #26050)
https://hg.python.org/cpython/rev/a6288fe5420f

New changeset c2cd3b435afe by Yury Selivanov in branch 'default':
Merge 3.5 (issue #26050)
https://hg.python.org/cpython/rev/c2cd3b435afe

--
nosy: +python-dev

___
Python tracker 

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

[issue26050] Add new StreamReader.readuntil() method

[Yury Selivanov]

Yury Selivanov added the comment:

Leaving this issue open until we have the docs committed.

--

___
Python tracker 

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

[issue26059] Integer Overflow in strop.replace()

[STINNER Victor]

Changes by STINNER Victor :


--
title: Integer Overflow -> Integer Overflow in strop.replace()

___
Python tracker 

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

[issue26079] Build with Visual Studio 2015 using PlatformToolset=v120

[Zachary Ware]

Zachary Ware added the comment:

I'm on the fence about this one.  MSVC 12.0 is not officially supported for any 
Python release.  Also, using PlatformToolset makes things difficult for ICC 
builds (which set PlatformToolset to e.g. "Intel C++ Compiler 16.0").

On the other hand, this is a very simple change, and building tkinter with ICC 
is pretty well completely broken anyway (it only works if you first build 
Tcl/Tk with MSVC).

Call me +0; +1 if you can get around using PlatformToolset directly.

--

___
Python tracker 

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

[issue26059] Integer Overflow in strop.replace()

[Guido van Rossum]

Guido van Rossum added the comment:

I cannot reproduce this on Mac (the code form 1.py just gives a very long 
answer). I don't have a Windows machine to try it on.

Do you have a patch or fix?

--

___
Python tracker 

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

[issue26080] "abandonned" -> "abandoned" in PEP 510's https://hg.python.org/peps/rev/b463c740990c

[STINNER Victor]

STINNER Victor added the comment:

Fixed, thanks for the report.

--
nosy: +haypo
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue26059] Integer Overflow in strop.replace()

[Ramin Farajpour Cami]

Ramin Farajpour Cami added the comment:

static char *
mymemreplace(const char *str, Py_ssize_t len,   
 const char *pat, Py_ssize_t pat_len,pattern string to find 
*/
 const char *sub, Py_ssize_t sub_len,substitution string */
 Py_ssize_t count,   number of replacements 
*/
 Py_ssize_t *out_len)
{
[...]

new_len = len + nfound*(sub_len - pat_len);  Unchecked arithmetic can 
overflow here.
if (new_len == 0) {
/* Have to allocate something for the caller to free(). */
out_s = (char *)PyMem_MALLOC(1);
if (out_s == NULL)
return NULL;
out_s[0] = '\0';
}
else {
assert(new_len > 0);
new_s = (char *)PyMem_MALLOC(new_len);  An allocation is performed 
using overflowed value.
if (new_s == NULL)
return NULL;
out_s = new_s;

for (; count > 0 && len > 0; --count) {  Memory is copied to new_s 
using len, which can be greater than the overflowed new_len value.
/* find index of next instance of pattern */
offset = mymemfind(str, len, pat, pat_len);
if (offset == -1)
break;

/* copy non matching part of input string */
memcpy(new_s, str, offset);
str += offset + pat_len;
len -= offset + pat_len;

/* copy substitute into the output string */
new_s += offset;
memcpy(new_s, sub, sub_len);
new_s += sub_len;
}
/* copy any remaining values into output string */
if (len > 0)
memcpy(new_s, str, len);
}

--

___
Python tracker 

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

[issue26059] Integer Overflow in strop.replace()

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

The code in msg257977 doesn't match current sources.

--

___
Python tracker 

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