[issue4963] mimetypes.guess_extension result changes after mimetypes.init()

[Marcin Szewczyk]

Changes by Marcin Szewczyk :


--
nosy: +wodny

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

[issue24755] asyncio.wrap_future undocumented

[Marcin Szewczyk]

New submission from Marcin Szewczyk:

While asyncio.wrap_future is mentioned in PEP 3156 and has its docstring it is 
undocumented in the reference. run_in_executor is documented but doesn't 
mention wrap_future either.

$ grep -r wrap_future Doc; echo $?
1

--
assignee: docs@python
components: Documentation
messages: 247659
nosy: docs@python, wodny
priority: normal
severity: normal
status: open
title: asyncio.wrap_future undocumented
type: enhancement
versions: Python 3.5

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

[issue24654] PEP 492 - example benchmark doesn't work (TypeError)

[Marcin Szewczyk]

Marcin Szewczyk added the comment:

Thanks for the update.

Regarding the "plain generator" part -- am I right thinking it's simply a 
generator not decorated with @asyncio.coroutine?

--

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

[issue24654] PEP 492 - example benchmark doesn't work (TypeError)

[Marcin Szewczyk]

New submission from Marcin Szewczyk:

Using benchmark from the section 
https://www.python.org/dev/peps/pep-0492/#async-await raises:
Traceback (most recent call last):
  File "./bench.py", line 28, in 
timeit(abinary, 19, 30)
  File "./bench.py", line 23, in timeit
list(gen(depth))
TypeError: 'coroutine' object is not iterable

Am I missing something or is a correction needed in code or documentation?

BTW, PEP 492 uses the term "plain generator", but unlike "generator-based 
coroutine" or "native coroutine" it's not defined in section 
https://www.python.org/dev/peps/pep-0492/#glossary. I think adding a definition 
would be beneficial.

--
assignee: docs@python
components: Documentation, asyncio
messages: 246856
nosy: docs@python, gvanrossum, haypo, wodny, yselivanov
priority: normal
severity: normal
status: open
title: PEP 492 - example benchmark doesn't work (TypeError)
type: enhancement
versions: Python 3.5

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

[issue21324] dbhash leaks random memory fragments to a database

[Marcin Szewczyk]

New submission from Marcin Szewczyk:

As stated in the subject. Example is in a remote Git repository:
https://bitbucket.org/wodny/python-dbm-experiments/
It shows how some random data gets into the database (into some gaps between 
keys and values). There is also a C example which hasn't been caught on leaking.

--
components: Library (Lib)
messages: 216966
nosy: wodny
priority: normal
severity: normal
status: open
title: dbhash leaks random memory fragments to a database
type: security
versions: Python 2.7

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

[issue17018] Inconsistent behaviour of methods waiting for child process

[Marcin Szewczyk]

New submission from Marcin Szewczyk:

I've done some experiments with:
1) multiprocessing.Process.join()
2) os.waitpid()
3) subprocess.Popen.wait()

These three methods behave completely different when interrupted with a signal 
which I find disturbing.

Reactions are:
1) exit with no exception or special return code
2) OSError exception
3) quiet retry (no exit)

The 1) case is very impractical.

Is there any movement towards standardization of those 3?

Now I know I can loop around Process.join() and check exitcode or is_alive, but 
it requires more code.

It has been pointed out that it changed between 2.6 and 2.7.

Associated bug: http://bugs.python.org/issue1731717

Relevant sources:
http://svn.python.org/view/python/branches/release26-maint/Lib/multiprocessing/forking.py?revision=84031&view=markup
http://hg.python.org/releasing/2.7.3/file/7bb96963d067/Lib/multiprocessing/forking.py
http://hg.python.org/cpython/rev/41aef062d529/

I think the behaviour of those three should be at least documented, especially 
if every one of them behaves differently and it changes between versions.

My environment is:
$ python --version
Python 2.7.3rc2

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux 7.0 (wheezy)
Release:7.0
Codename:   wheezy

$ uname -a
Linux magazyn-ziarno 3.2.0-4-686-pae #1 SMP Debian 3.2.35-2 i686 GNU/Linux

Filing a bug as advised on python-dev mailing list 
().

--
messages: 180465
nosy: wodny
priority: normal
severity: normal
status: open
title: Inconsistent behaviour of methods waiting for child process
type: behavior
versions: Python 2.7

___
Python tracker 
<http://bugs.python.org/issue17018>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com