[issue6598] calling email.utils.make_msgid frequently has a non-trivial probability of generating colliding ids

[Gavin Panella]

Changes by Gavin Panella :


--
nosy: +allenap

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

[issue7403] Race condition in logging._acquireLock()?

[Gavin Panella]

New submission from Gavin Panella :

The logging module create a global _lock in what looks like a
thread-unsafe manner:

{{{
_lock = None

def _acquireLock():
"""
Acquire the module-level lock for serializing access to shared data.

This should be released with _releaseLock().
"""
global _lock
if (not _lock) and thread:
_lock = threading.RLock()
if _lock:
_lock.acquire()
}}}

If two threads call _acquireLock() at the same time, and _lock is
None, it's possible that two locks will be created, one of which will
get clobbered.

I think the above could be made thread-safe if written as:

{{{
if thread:
_lock = threading.RLock()
else:
_lock = None

def _acquireLock():
"""
Acquire the module-level lock for serializing access to shared data.

This should be released with _releaseLock().
"""
if _lock:
_lock.acquire()
}}}

--
components: Library (Lib)
messages: 95764
nosy: allenap
severity: normal
status: open
title: Race condition in logging._acquireLock()?
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6

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

[issue23372] defaultdict.fromkeys should accept a callable factory

[Gavin Panella]

Gavin Panella added the comment:

It's inconsistent that defaultdict([]) should be rejected:

  >>> defaultdict([])
  Traceback (most recent call last):
File "", line 1, in 
  TypeError: first argument must be callable or None

but defaultdict.fromkeys([]) is okay:

  >>> defaultdict.fromkeys([])
  defaultdict(None, {})

The constructor signature differs between defaultdict and dict, and 
defaultdict.fromkeys is an alternate constructor, so it seems reasonable to 
also change its signature.

Also confusing is that I can call fromkeys on an instance of defaultdict:

  >>> dd = defaultdict(list)
  >>> dd.fromkeys([1])
  defaultdict(None, {1: None})

Instinctively I expect the default_factory to be carried over, even though I 
realise that would be odd behaviour for Python. If defaultdict.fromkeys were to 
expect a mandatory default_factory argument there wouldn't be this moment of 
confusion.

--
nosy: +allenap

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

[issue28725] Awaiting an awaitable returned from an async function does nothing

[Gavin Panella]

New submission from Gavin Panella:

The following will sleep:

  async def one():
  await asyncio.sleep(10)

  async def two():
  await one()

  loop.run_until_complete(two())

but the following will not:

  async def one():
  return asyncio.sleep(10)

  async def two():
  await one()

  loop.run_until_complete(two())

I would expect run_until_complete to keep bouncing awaitable results back into 
the event-loop until a non-awaitable is returned. In my code I work around this 
with:

  result = loop.run_until_complete(...)
  while inspect.isawaitable(result):
  result = loop.run_until_complete(result)

I would also expect that the await in `two` would have DTRT with the returned 
generator/coroutine.

--
components: asyncio
messages: 281043
nosy: allenap, gvanrossum, yselivanov
priority: normal
severity: normal
status: open
title: Awaiting an awaitable returned from an async function does nothing
type: behavior
versions: Python 3.5

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