[issue8838] Remove codecs.readbuffer_encode() and codecs.charbuffer_encode()

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

STINNER Victor wrote:
> 
> STINNER Victor  added the comment:
> 
> MAL agreed to remove "t#" parsing format (#8839), whereas charbuffer_encode() 
> main goal was to offer "t#" parsing format to Python object space. 
> charbuffer_encode() is now useless in Python3. bytes() accepts any buffer 
> object (read-only and read/write buffer), so readbuffer_encode() became 
> useless in Python3.
> 
> readbuffer_encode() and charbuffer_encode() were never documented, and are 
> not used by any 3rd party library.
> 
> Can we remove these two functions?

Like I said before:

We can remore charbuffer_encode() now and perhaps
add it again later on when buffers have learned (again) to
provide access to a text version of their data. In this
case, we'd likely add t# back again as well.

Please leave readbuffer_encode() as-is.

--
title: Remove codecs.readbuffer_encode() andcodecs.charbuffer_encode() -> 
Remove codecs.readbuffer_encode() and codecs.charbuffer_encode()

___
Python tracker 

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

[issue7989] Transition time/datetime C modules to Python

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Brett Cannon wrote:
> 
> Brett Cannon  added the comment:
> 
> So I see a couple of objections here to the idea that I will try to address.
> 
> First is MAL's thinking that this will undo any C code, which it won't. The 
> idea is that stdlib modules that do not inherently rely on other C code (e.g. 
> sqlite3 does not fall underneath this) would have a pure Python 
> implementation with possible C enhancements. In the case of datetime that  
> code is done, so it won't go anywhere. In this case it would be bringing in a 
> pure Python implementation like the one PyPy maintains. You can look at heapq 
> if you want an existing example of what it looks like to maintain a pure 
> Python and C version of a module.

So the proposal is to have something like we have for pickle, with
cPickle being the fast version and pickle.py the slow Python one ?

Since no CPython would use the Python version, who would be supporting
the Python-only version ?

--
title: Add pure Python implementation of datetime module to CPython -> 
Transition time/datetime C modules to Python

___
Python tracker 

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

[issue7989] Add pure Python implementation of datetime module to CPython

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Oops, sorry. Looks like the Roundup email interface changed the ticket
title back to the old one again (I was replying to Brett's comment under the 
old title).

--
title: Transition time/datetime C modules to Python -> Add pure Python 
implementation of datetime module to CPython

___
Python tracker 

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

[issue7839] Popen should raise ValueError if pass a string when shell=False or a list when shell=True

[Larry Hastings]

Larry Hastings  added the comment:

I noticed this a while ago.  And FWIW it's not just 3.x; I see this same 
behavior in 2.6.

I've whipped up a test case, attached, which runs in both Python 2 and Python 
3.  The test runs "sys.interpreter -V" four times: it tries all the 
combinations of shell=True/False and the cmdline argument as either a list or a 
string.

When shell=True and cmdline is an array, Python runs as an interactive shell.  
(You have to press Ctrl-D to close it; the test warns you this is happening.)
When shell=False and cmdline is a string, Python raises OSError, "[Errno 2] No 
such file or directory".
In the other two cases the code runs correctly, producing the version number of 
Python.

The test would probably be better if I used stdin=PIPE too, so you didn't have 
to press Ctrl-D.  But I couldn't figure out how to make it produce the 
interactive session stuff when I did that.  Anyway, it wouldn't be hard to make 
this into a proper regression test.

My two cents: I assume from the discussion that this is not fixable; that is, 
it's not possible to have a shell and a string, or no shell and a list.  
Failing that, the right decision is what R. David discussed on 2010-02-28: 
ignore the shell argument passed in and infer it ourselves from whether cmdline 
is a list or a string.  I don't buy the security argument--since the invalid 
combinations of shell and cmdline mean the function doesn't work, existing 
callers have already made the decision whether they can live with shell=True.  
We should deprecate the shell argument and update the documentation to make the 
behavior crystal clear.

--
nosy: +larry
Added file: http://bugs.python.org/file17587/test_subprocess.py

___
Python tracker 

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

[issue7839] Popen should raise ValueError if pass a string when shell=False or a list when shell=True

[Larry Hastings]

Larry Hastings  added the comment:

I realize we're down to the wire, but would it be too late to fix this in 2.7?  
It is a genuine bug, and it won't break any correct code.

--

___
Python tracker 

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

[issue7839] Popen should raise ValueError if pass a string when shell=False or a list when shell=True

[Larry Hastings]

Changes by Larry Hastings :


--
versions: +Python 2.7

___
Python tracker 

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

[issue7989] Add pure Python implementation of datetime module to CPython

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Even from pypy perspective, a pure python implementation is not ideal because 
it makes it difficult to implement the C API.

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue7839] Popen should raise ValueError if pass a string when shell=False or a list when shell=True

[Larry Hastings]

Larry Hastings  added the comment:

Sorry for spamming updates, but here's two more things to consider.

1) What does it do on Windows?  For all I know all four combinations work fine 
there and we should preserve the existing functionality.

2) All four combinations work fine if you call a program without arguments.  I 
tried it with both "/bin/ls" and sys.executable and it worked like a champ.  
The problem *only* happens if you specify command-line arguments.

--

___
Python tracker 

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

[issue8938] Mac OS dialogs(Save As..., Load) translation

[Pavel Denisow]

New submission from Pavel Denisow :

We have a problem with using native Mac OS dialogs (Save As..., Load) on 
Russian Mac:
Dialogs are not translated even with file-translation. See attached screenshots.
Same code in Linux works perfect. C++ QT project in Mac has translation in 
native dialogs.
Test project on python and PyQT contains not-translated dialogs.
For tk and EasyDialogs result is the same - not translated.

Mac OS: 10.5.2, Russian locale.
Python: 2.5.1


PyQt test project

from PyQt4 import QtGui, QtCore


app = QtGui.QApplication(sys.argv)

QtGui.QFileDialog().getSaveFileName()
QtGui.QFileDialog().getOpenFileName()

sys.exit(app.exec_())





tk test project

from tkCommonDialog import Dialog


class OpenDialog(Dialog):
command = "tk_getOpenFile"
class SaveDialog(Dialog):
command = "tk_getSaveFile"


OpenDialog().show()
SaveDialog().show()




EasyDialogs test project

import EasyDialogs

EasyDialogs.AskFileForSave()
EasyDialogs.AskFileForOpen()


--
assignee: ronaldoussoren
components: Macintosh, Unicode
files: filedialogs_mac.zip
messages: 107314
nosy: Pavel.Denisow, ronaldoussoren
priority: normal
severity: normal
status: open
title: Mac OS  dialogs(Save As..., Load) translation
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file17588/filedialogs_mac.zip

___
Python tracker 

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

[issue3173] external strftime for Python?

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

PyPy also calls the platform's strftime().

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue7839] Popen should raise ValueError if pass a string when shell=False or a list when shell=True

[R. David Murray]

R. David Murray  added the comment:

Unless we go the proliferating-interfaces route, it does represent a behavior 
change, and so if accepted would need to go through a deprecation cycle.  And 
if we did go that route, it would be a new feature.  So nothing can happen in 
2.7, since it is already in the RC stage.

By the way, I did not suggest dropping the shell parameter, I argued against 
doing that.  The 'security' I referred to is that when you use a shell you are 
subject to shell-metacharacter-based attacks (and bugs!) if any elements of the 
command line come from user input and you don't sanitize them.  This problem 
doesn't exist with shell=False, which is why it is the default.

--
versions:  -Python 2.7

___
Python tracker 

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

[issue7989] Add pure Python implementation of datetime module to CPython

[anatoly techtonik]

anatoly techtonik  added the comment:

On Tue, Jun 8, 2010 at 2:06 PM, Amaury Forgeot d'Arc
 wrote:
>
> Even from pypy perspective, a pure python implementation is not ideal because 
> it makes it difficult to implement the C API.

C API
must die
a shadow of Go

--

___
Python tracker 

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

[issue8838] Remove codecs.readbuffer_encode() and codecs.charbuffer_encode()

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Please leave readbuffer_encode() as-is.

Then please add documentation for it.

--
title: Remove codecs.readbuffer_encode()and 
codecs.charbuffer_encode() -> Remove codecs.readbuffer_encode() and 
codecs.charbuffer_encode()

___
Python tracker 

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

[issue8838] Remove codecs.readbuffer_encode() and codecs.charbuffer_encode()

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou  added the comment:
> 
>> Please leave readbuffer_encode() as-is.
> 
> Then please add documentation for it.

Will do.

--
title: Remove codecs.readbuffer_encode()and codecs.charbuffer_encode() 
-> Remove codecs.readbuffer_encode() and codecs.charbuffer_encode()

___
Python tracker 

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

[issue8939] Use C type names (PyUnicode etc;) in the C API docs

[Antoine Pitrou]

New submission from Antoine Pitrou :

Following r81811 (and issue8925), perhaps we should start using e.g. PyUnicode, 
PyBytes, PyLong, etc. in the C API docs to more closely follow the C API rather 
than use the type names you see at the Python level.

--
assignee: haypo
components: Documentation
messages: 107320
nosy: haypo, lemburg, pitrou
priority: normal
severity: normal
status: open
title: Use C type names (PyUnicode etc;) in the C API docs
versions: Python 3.1, Python 3.2

___
Python tracker 

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

[issue8939] Use C type names (PyUnicode etc;) in the C API docs

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +d...@python

___
Python tracker 

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

[issue8940] *HTTPServer need a summary page with API inheritance table

[anatoly techtonik]

New submission from anatoly techtonik :

The abundance of methods and hierarchy depth of various servers from "Internet 
Protocols and Support" section makes it extremely hard to navigate information. 
You need a strong OOP background to be able to use this doc effectively, as 
examples are not intuitive otherwise.

Usually you need a decent IDE (such as Eclipse) to get a picture of class 
hierarchy and a table of all available methods with a mark where they were 
inherited from.

Such table (at least Class Hierarchy view screenshot from Eclipse) should be 
available in reference for descendant classes.

--
assignee: d...@python
components: Documentation
messages: 107321
nosy: d...@python, techtonik
priority: normal
severity: normal
status: open
title: *HTTPServer need a summary page with API inheritance table
versions: Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

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

[issue7839] Popen should raise ValueError if pass a string when shell=False or a list when shell=True

[Zsolt Cserna]

Zsolt Cserna  added the comment:

I would say that both string and list should be accepted in args, and depending 
on the shell parameter, the module should create a list or a string from the 
specified list/string.

We already have a list2cmdline function to convert a list to string, we would 
only need to create the inverse of this function to convert a string to a list.

Executing a program whose parameters are coming from external source (eg. user 
input) can result security problems if those are not specified as a list and in 
this case I would be really happy to specify my parameters as a list to Popen 
and it would do the appropriate conversions as above.

--
nosy: +csernazs

___
Python tracker 

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

[issue6641] strptime doesn't support %z format ?

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
dependencies: +datetime lacks concrete tzinfo impl. for UTC
stage:  -> unit test needed
type: behavior -> feature request
versions: +Python 3.2 -Python 2.6

___
Python tracker 

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

[issue7384] curses crash on FreeBSD

[Stefan Krah]

Stefan Krah  added the comment:

Committed in r81669,r81672,r81683 (trunk) and r81830,81831 (py3k).


What to do with the releases? To recap, the fix is:

  1) Detect if readline is already linked against ncurses and
 if so, skip any further selection. This must be done.

  2) Use the same version of ncurses for readline.so and _curses.so.


1) should be done in any case. 2) could change the behavior for
users who previously had readline/ncurses, cursesmodule/ncursesw,
but only use the cursesmodule in an application.

--

___
Python tracker 

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

[issue8850] Remove "w" format of PyParse_ParseTuple()

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +loewis

___
Python tracker 

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

[issue8850] Remove "w" format of PyParse_ParseTuple()

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I'd point out that "w#" is mostly useless too. It's supposed to return a 
read-write buffer, but as the doc says it also doesn't support "mutable 
objects", since it isn't able to properly lock/pin the buffer; therefore it 
probably doesn't support anything useful.

--
nosy: +pitrou

___
Python tracker 

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

[issue7768] raw_input should encode unicode prompt with std.stdout.encoding.

[INADA Naoki]

INADA Naoki  added the comment:

I agree to close this bug without fix.
I hope that Python3 will be mainstream soon.

--

___
Python tracker 

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

[issue7768] raw_input should encode unicode prompt with std.stdout.encoding.

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
resolution:  -> wont fix
status: open -> closed

___
Python tracker 

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

[issue8941] utf-32be codec failing on 16-bit python build for 32-bit value

[Dave Opstad]

New submission from Dave Opstad :

The utf-32 little-endian codec works fine, but the big-endian codec is 
producing incorrect results:

Python 3.1.2 (r312:79360M, Mar 24 2010, 01:33:18) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> str(b'\x00\x00\x01\x00', 'utf-32le') # works
'\U0001'
>>> str(b'\x00\x01\x00\x00', 'utf-32be') # doesn't work
'\ud800\x02'

--
components: Unicode
messages: 107326
nosy: opstad
priority: normal
severity: normal
status: open
title: utf-32be codec failing on 16-bit python build for 32-bit value
type: behavior
versions: Python 3.1

___
Python tracker 

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

[issue8942] __path__ attribute of modules loaded by zipimporter is untested

[Jean-Paul Calderone]

New submission from Jean-Paul Calderone :

Packages loaded from zip files have a __path__ sort of like any other package.  
The zipimport tests don't verify that this attribute has the correct value, 
though.

--
components: Tests
messages: 107327
nosy: exarkun
priority: normal
severity: normal
status: open
title: __path__ attribute of modules loaded by zipimporter is untested

___
Python tracker 

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

[issue8943] Bug in InteractiveConsole

[Fabio Zadrozny]

New submission from Fabio Zadrozny :

Unable to pickle classes used in the InteractiveConsole. The code attached 
works in python 2.5 and fails on python 3.1.2.

--
components: Library (Lib)
files: fast_test.py
messages: 107328
nosy: fabioz
priority: normal
severity: normal
status: open
title: Bug in InteractiveConsole
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file17589/fast_test.py

___
Python tracker 

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

[issue6641] strptime doesn't support %z format ?

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Attached patch includes issue 5094 patch.

--
keywords: +patch
nosy: +mark.dickinson
stage: unit test needed -> commit review
Added file: http://bugs.python.org/file17590/issue6641.diff

___
Python tracker 

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

[issue2651] Strings passed to KeyError do not round trip

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

KeyError.patch is out of date.  Is anyone motivated enough to update it for 
py3k?  I like the idea, but don't have spare cycles at the moment.

--

___
Python tracker 

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

[issue8902] add datetime.time.now() for consistency

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Anatoly,

msg107191 belongs to issue8903, not here and it is not a use case, but rather a 
demonstration of how the proposed feature would work.

My question is why would an application need current time without current date? 
 I feel providing time.now() may lead so people to call date.today() and 
time.now() separately instead of datetime.now() leading to interesting bugs.

One think I would consider an improvement over the current situation, would be 
to rename date.today() to date.now().  There are too many ways to spell the 
same thing:

date.today()
datetime.today()
datetime.now().date()

and no easy way to write a "how long ago" function that would work for both 
date and datetime:

def ago(t):
t.now() - t

--

___
Python tracker 

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

[issue8903] Add module level now() and today() functions to datetime module

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Note that it is important to keep class methods because in some cases it is 
convenient to obtain now/today from datetime/date instances instead of 
importing them from the module.  So deprecating class methods is not an option 
and adding module level functions that are equivalent to existing class methods 
is not TOOWTDI.

--
resolution:  -> rejected
status: open -> pending
title: datetime functions -> Add module level now() and today() functions to 
datetime module
type:  -> feature request

___
Python tracker 

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

[issue7989] Add pure Python implementation of datetime module to CPython

[Brett Cannon]

Brett Cannon  added the comment:

So yes, cPickle/pickle, cStringIO/StringIO, heapq, etc. are all examples of the 
approach. One could choose to write the pure Python version first, profile the 
code, and only write extension code for the hot spots, but obviously that 
typically doesn't happen.

As for who maintains it, that's python-dev, just like every other module that 
is structured like this. When the stdlib gets more of a clear separation from 
CPython I suspect the other VM maintainers will contribute more.

As for PyPy not specifically needing this, that still doesn't solve the problem 
that Jython and IronPython have with extension code or any other future VM that 
doesn't try to come up with a solution for extensions.

--

___
Python tracker 

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

[issue8907] time module documentation differs in trunk and py3k

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

There seems to be a few legitimate differences such as "int or long" vs. 
integer, or parenthesis for print.  Patch is forthcoming.

--

___
Python tracker 

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

[issue8907] time module documentation differs in trunk and py3k

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

.. also 3.x does not track versionadded from 2.x

--

___
Python tracker 

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

[issue8907] time module documentation differs in trunk and py3k

[Mark Dickinson]

Mark Dickinson  added the comment:

r81489 should probably also be svnmerged to py3k before applying this doc 
change.  (As far as I can tell, this is the only outstanding unmerged trunk 
change.)

--
nosy: +mark.dickinson

___
Python tracker 

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

[issue8944] test_winreg.test_reflection_functions fails on Windows Server 2003

[Brian Curtin]

New submission from Brian Curtin :

The key/subkey used in this test causes a failure when run on Windows Server 
2003 x64.

--
assignee: brian.curtin
components: Tests, Windows
messages: 107337
nosy: brian.curtin
priority: normal
severity: normal
stage: needs patch
status: open
title: test_winreg.test_reflection_functions fails on Windows Server 2003
type: behavior
versions: Python 2.7, Python 3.2

___
Python tracker 

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

[issue8945] Bug in **kwds expansion on call?

[Terry J. Reedy]

New submission from Terry J. Reedy :

In 2.6, the requirement for **kwds keyword argument expansion in calls (LangRef 
5.3.4. Calls) is relaxed from "(subclass of) dictionary" (2.5) to "mapping".  
The requirement in this context for 'mapping' is not specified. LRef3.2 merely 
says "The subscript notation a[k]  selects the item indexed by k from the 
mapping a;". Here, .keys seems to be needed in addition to .__getitem__. 
(.items alone does not make an object a mapping.)

In python-list thread "Which objects are expanded by double-star ** operator?", 
Peter Otten posted 2.6 results for

class A(object):
 def keys(self): return list("ab")
 def __getitem__(self, key):
 return 42

class B(dict):
 def keys(self): return list("ab")
 def __getitem__(self, key):
 return 42

def f(**kw):
 print(kw)

f(**A())
# {'a': 42, 'b': 42}

b = B(); print(b['a'], b['b']) # I added this
# 42, 42
f(**b)
# {}

I get same with 3.1. It appears .keys() is called in the first case, but not 
the second, possibly due to an internal optimization.

The different of outcome seems like a bug, though one could argue that the doc 
is so vague that it makes no promise to be broken.

--
components: Interpreter Core
messages: 107338
nosy: tjreedy
priority: normal
severity: normal
status: open
title: Bug in **kwds expansion on call?
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

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

[issue8832] automate minidom.unlink() with a context manager

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

Any comments?

--

___
Python tracker 

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

[issue614557] LookupError etc. need API to get the key

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

It looks like issue2651 is the first step for this.  See msg66432. I am merging 
the nosy lists.

--
assignee:  -> belopolsky
dependencies: +Strings passed to KeyError do not round trip
nosy: +amaury.forgeotdarc, belopolsky, pitrou, rharris
stage:  -> needs patch
type:  -> feature request
versions: +Python 3.2 -Python 3.0

___
Python tracker 

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

[issue8832] automate minidom.unlink() with a context manager

[Fred L. Drake, Jr.]

Fred L. Drake, Jr.  added the comment:

+1

--
nosy: +fdrake

___
Python tracker 

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

[issue8946] PyBuffer_Release signature in 3.1 documentation is incorrect

[Dave Opstad]

New submission from Dave Opstad :

According to the 3.1 documentation, the prototype for PyBuffer_Release is:

void PyBuffer_Release(PyObject *obj, Py_buffer *view);

However, abstract.h has this prototype:

PyAPI_FUNC(void) PyBuffer_Release(Py_buffer *view);

The documentation's reference to "obj" should be removed.

--
assignee: d...@python
components: Documentation
messages: 107342
nosy: d...@python, opstad
priority: normal
severity: normal
status: open
title: PyBuffer_Release signature in 3.1 documentation is incorrect
type: behavior
versions: Python 3.1

___
Python tracker 

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

[issue836035] strftime month name is encoded somehow

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Is this still an issue in 3.x?  With time.strftime() returning unicode, I don't 
think any encoding issues remain.

--
assignee:  -> belopolsky
nosy: +belopolsky

___
Python tracker 

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

[issue887237] Machine integers

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
assignee:  -> belopolsky
components: +Extension Modules, ctypes -Library (Lib)
nosy:  -Alexander.Belopolsky
stage:  -> patch review
versions: +Python 3.2

___
Python tracker 

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

[issue7768] raw_input should encode unicode prompt with std.stdout.encoding.

[STINNER Victor]

STINNER Victor  added the comment:

> I hope that Python3 will be mainstream soon.

What do you mean by "mainstream"? Python3 is available in Ubuntu (since 
Karmic), Fedora 13, Mandriva 2010.0, Gentoo, Debian (only Sid for now), ...

--

___
Python tracker 

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

[issue8947] Provide as_integer_ratio() method to Decimal

[Alexander Belopolsky]

New submission from Alexander Belopolsky :

Here is my use case: recently implemented timedelta * float operation starts 
with converting float to an int ratio.  The same algorithm can be used for 
decimals, but they don't support as_integer_ratio().

--
components: Extension Modules
messages: 107345
nosy: belopolsky
priority: normal
severity: normal
status: open
title: Provide  as_integer_ratio() method to Decimal
type: feature request
versions: Python 3.2

___
Python tracker 

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

[issue8948] cleanup functions are not executed with unittest.TestCase.debug()

[Michael Foord]

New submission from Michael Foord :

Also class / module tearDowns are not executed with TestSuite.debug()

--
assignee: michael.foord
components: Library (Lib)
messages: 107346
nosy: michael.foord
priority: normal
severity: normal
status: open
title: cleanup functions are not executed with unittest.TestCase.debug()
versions: Python 2.7, Python 3.2

___
Python tracker 

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

[issue8945] Bug in **kwds expansion on call?

[Benjamin Peterson]

Benjamin Peterson  added the comment:

This falls under the usual category of dict subclasses not having their methods 
called. Especially since the B dict doesn't actually contain anything.

--
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

___
Python tracker 

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

[issue8947] Provide as_integer_ratio() method to Decimal

[Mark Dickinson]

Mark Dickinson  added the comment:

This seems like a reasonable request to me;  I'd like to see a little bit of 
convergence between the float and Decimal APIs.

One difference between the two types that's worth noting is that the 
float.as_integer_ratio() method can never take a ridiculous amount of time or 
memory, whereas Decimal.as_integer_ratio() could:  e.g., consider 
Decimal('1e9').as_integer_ratio().  But I don't really see that as a 
problem.

--
nosy: +mark.dickinson

___
Python tracker 

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

[issue8832] automate minidom.unlink() with a context manager

[Éric Araujo]

Éric Araujo  added the comment:

Looks good to me.

--
nosy: +merwok

___
Python tracker 

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

[issue8832] automate minidom.unlink() with a context manager

[R. David Murray]

R. David Murray  added the comment:

The test passes if __exit__ doesn't call unlink.  Otherwise the patch looks 
good to me.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue8947] Provide as_integer_ratio() method to Decimal

[Mark Dickinson]

Changes by Mark Dickinson :


--
assignee:  -> mark.dickinson

___
Python tracker 

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

[issue8949] PyArg_Parse*(): "z" should not accept bytes

[STINNER Victor]

New submission from STINNER Victor :

"z" is supposed to be the same format than "s" but accepts None Except that 
"z" does also accept bytes. I suppose that "s" was "fixed" between Python2 and 
Python3, but "z" is not fixed yet.

I think that it can be fixed in Python 3.2 without any deprecation process.

--
components: Interpreter Core
messages: 107351
nosy: haypo
priority: normal
severity: normal
status: open
title: PyArg_Parse*(): "z" should not accept bytes
versions: Python 3.2

___
Python tracker 

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

[issue8949] PyArg_Parse*(): "z" should not accept bytes

[STINNER Victor]

Changes by STINNER Victor :


--
keywords: +patch
Added file: http://bugs.python.org/file17591/pyarg_z_no_bytes.patch

___
Python tracker 

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

[issue8950] In getargs.c, make 'L' code raise TypeError for float arguments.

[Mark Dickinson]

New submission from Mark Dickinson :

Currently all but one of the integer format codes for getargs.c raise TypeError 
when passed a float.  The 'L' code produces a warning rather than raising an 
error.

This was deliberate at the time, because all except the 'L' code already raised 
a DeprecationWarning in Python 3.1, and were converted to raise TypeError for 
3.2.  Since the 'L' code didn't raise a warning for float inputs in 3.1, 
directly raising a TypeError in 3.2 seemed a bit abrupt.

However, I'd like to revisit this decision, and make the 'L' code raise a 
TypeError in 3.2.  Note that

(1) The 'L' code represents the Py_LONG_LONG type, and isn't used very much;  I 
think the risk of unexpected breakage from this change is fairly small.

(2) One of the places that the 'L' code *is* used is when parsing strange C 
types (like off_t) that are matched with either size_t, long or long long at 
configure + build time.  So one platform might end up parsing off_t types with 
the 'n' code, while another parses them with the 'L' code.  It would be 
desirable for both platforms to have the same behaviour when passed a float.

Any objections to making this change?

See also issue 5080.

--
assignee: mark.dickinson
components: Interpreter Core
messages: 107352
nosy: haypo, mark.dickinson
priority: normal
severity: normal
status: open
title: In getargs.c, make 'L' code raise TypeError for float arguments.
type: behavior
versions: Python 3.2

___
Python tracker 

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

[issue7839] Popen should raise ValueError if pass a string when shell=False or a list when shell=True

[Larry Hastings]

Larry Hastings  added the comment:

Zsolt: an excellent idea!  That shouldn't change the semantics of the function, 
and therefore is strictly a bug fix.  Which means we could potentially backport 
it, yes?

Obviously we only need to change it between string / list if we're going to 
have this problem, and that only happens when there are parameters.  So the 
change could be very narrow in scope.  Lovely!

R. David: Why did you remove Python 2.7 from the list?  We see the behavior 
there too.

--

___
Python tracker 

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

[issue8950] In getargs.c, make 'L' code raise TypeError for float arguments.

[STINNER Victor]

STINNER Victor  added the comment:

> One of the places that the 'L' code *is* used is when parsing
> strange C types (like off_t)

It has unexepected consequences. Example:

   >>> x=open("x", "w")
   >>> x.seek(0.0)
   0.0
   >>> x.seek(-0.0)
   -0.0
   >>> x.seek(0.1)
   0.1
   >>> x.tell()
   0

I think that we should just raise an error in Python 3.2 because I consider 
this as a bug. It remembers me another bug related to file and float: 
http://bugs.python.org/issue5080#msg92400

--

___
Python tracker 

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

[issue8907] time module documentation differs in trunk and py3k

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Merged r81489 to py3k (r81840), but this affects datetime module docs, not 
time.  On a closer examination, the differences in time.rst are correct.

--
resolution:  -> invalid
status: open -> closed

___
Python tracker 

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

[issue8951] PyArg_Parse*(): factorize code of 's' and 'z' formats, and 'u' and 'Z' formats

[STINNER Victor]

New submission from STINNER Victor :

Code of 's' and 'z' formats is *mostly* the same... except a bug (#8949).

Code of 'u' and 'Z' formats can also easily be factorized.

I don't really understand why the code was duplicated.

--
components: Interpreter Core
files: factorize_getargs_sz_uZ.patch
keywords: patch
messages: 107356
nosy: haypo
priority: normal
severity: normal
status: open
title: PyArg_Parse*(): factorize code of 's' and 'z' formats, and 'u' and 'Z' 
formats
versions: Python 3.2
Added file: http://bugs.python.org/file17592/factorize_getargs_sz_uZ.patch

___
Python tracker 

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

[issue8949] PyArg_Parse*(): "z" should not accept bytes

[STINNER Victor]

STINNER Victor  added the comment:

Hum, the patch doesn't update the documentation (at least Porting section of 
the What's new in Python 3.2).

--

___
Python tracker 

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

[issue8939] Use C type names (PyUnicode etc;) in the C API docs

[STINNER Victor]

STINNER Victor  added the comment:

Big patch:
 - replace Python types by C Python types (eg. str => PyUnicodeObject* and None 
=> Py_None)
 - fix "w" / "w*" / "w#" doc: similar to "y" / "y*" / "y#" (and not "s" / "s*" 
/ "s#")
 - add quotes to the formats, eg. s => "s"
 - use :ctype: to add links to some terms (eg. Py_BEGIN_ALLOW_THREADS) and use 
a fixed width font
 - replace "the default encoding" by "'utf-8' encoding"
 - replace true by 1, and false by 0 (C API of Python doesn't use stdbool.h but 
classic int)
 - use a list for the two modes of "es#"
 - Py_BuildValue(), "s" and "s#" formats: specify that the Python object is a 
str

1 and 0 were formatted with ``1`` and ``0``. I don't understand why, so I 
removed the italic style.

Sorry for the length of the patch, but it was easy to work on only one aspect.

--
keywords: +patch
Added file: http://bugs.python.org/file17593/c_api_arg.patch

___
Python tracker 

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

[issue8946] PyBuffer_Release signature in 3.1 documentation is incorrect

[Brian Curtin]

Brian Curtin  added the comment:

Fixed in r81851 (py3k) and r81852 (release31-maint). Thanks!

--
assignee: d...@python -> brian.curtin
nosy: +brian.curtin
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.2

___
Python tracker 

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

[issue8939] Use C type names (PyUnicode etc;) in the C API docs

[Fred L. Drake, Jr.]

Changes by Fred L. Drake, Jr. :


--
nosy: +fdrake

___
Python tracker 

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

[issue8939] Use C type names (PyUnicode etc;) in the C API docs

[STINNER Victor]

STINNER Victor  added the comment:

Other changes of the patch:
 - "u#": remove "Non-Unicode objects are handled by interpreting their 
read-buffer pointer ...", it's no more true
 - "es", "es#": remove "... and objects convertible to Unicode into a character 
buffer", it's no more true
 - Py_BuildValue(), "K" and "L" formats: specify the name of the C type on 
Windows (_int64 / unsigned _int64) as done for PyArg_Parse*() long long types

If the patch is too long, I can try to split it into smaller parts.

--

___
Python tracker 

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

[issue7768] raw_input should encode unicode prompt with std.stdout.encoding.

[INADA Naoki]

INADA Naoki  added the comment:

>What do you mean by "mainstream"? Python3 is available in Ubuntu (since 
>Karmic), Fedora 13, Mandriva 2010.0, Gentoo, Debian (only Sid for now), ...

It means most of Pythonista uses Python3 rather than Python2 and
most of libraries supports Python3.

Currently, many new Pythonista starts with Python2 because libraries
they want support only it, and are suffered by UnicodeError.

--

___
Python tracker 

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

[issue8839] PyArg_ParseTuple(): remove "t# format

[STINNER Victor]

STINNER Victor  added the comment:

> t# was meant to provide access to text data, so replacing it with a
> parser code that is meant for binary data is not correct. The
> closes Python3 gets to t# from Python2 is s# or s*, so please use
> those in the NEWS entry and s* in charbuffer_encode().

Done. Patch commited as r81854 in 3.2: it removes also 
codecs.charbuffer_encode(). Commit blocked in 3.1 (r81855).

--

___
Python tracker 

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

[issue8838] Remove codecs.readbuffer_encode() and codecs.charbuffer_encode()

[STINNER Victor]

STINNER Victor  added the comment:

r81854 removes codecs.charbuffer_encode() (and t# parsing format) from Python 
3.2 (blocked in 3.1: r81855).

--

My problem with codecs.readbuffer_encode() is that it does accept byte *and* 
character strings. If you want to get a byte string, just use bytes(input). If 
you want to convert a character string to a byte string, use 
input.encode("utf-8"). But accepting both types may lead to mojibake as we had 
in Python2.

MAL> That's a common misunderstanding. The codec system does not
MAL> mandate a specific type combination. Only the helper methods
MAL> .encode() and .decode() on bytes and str objects in Python3 do.

This is related to #7475: we have to decide if we drop completly this  
(currently unused) feature (eg. remove codecs.readbuffer_encode()), or if we 
"reenable" this feature again (reintroduce hex, bz2, rot13, ... codecs). This 
discussion should occur on the mailing list.

--

___
Python tracker 

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

[issue8839] PyArg_ParseTuple(): remove "t# format

[STINNER Victor]

Changes by STINNER Victor :


--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue8948] cleanup functions are not executed with unittest.TestCase.debug()

[Michael Foord]

Michael Foord  added the comment:

Committed revision 81853. Still needs porting to py3k (and unittest2).

--

___
Python tracker 

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

[issue7839] Popen should raise ValueError if pass a string when shell=False or a list when shell=True

[R. David Murray]

R. David Murray  added the comment:

Because we use the versions field to indicate which versions a patch will be 
applied to, if it is, and I created this bug as a feature request, and as such 
it is not a candidate for 2.7.

Changing list to string for shell=True is a behavior change (currently excess 
list elements are passed to the shell...and I don't *know* that that is 
useless, someone might be exploiting it) and hard to get right.  Changing 
string to list might be possible on unix using shlex, but is a distinctly 
non-trivial change, would need to be considered carefully with regard to its 
implications, and I have no idea what it would mean on Windows.

Since 2.7 is in RC status, there is no way such a fix will be accepted for 2.7. 
 You can try to make a case for this proposal as a bug fix for 2.7.1, but I'm 
not sanguine about its chances.  Personally I'm -0.5 on such a change.  I think 
it is better to leave the control of the command formatting in the hands of the 
programmer.  Doing such a conversion is too close to guessing for my taste.

If you want a wider selection of opinions you can post the issue to python-dev 
and request feedback.

--

___
Python tracker 

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

[issue8945] Bug in **kwds expansion on call?

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Might that 'usual' fact be somehow documented? I am hard put to suggest 
anything since it is a fact I, like others, am not aware of. Is this a general 
rule for subclasses of builtins? or specific to dicts?

--

___
Python tracker 

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

[issue8850] Remove "w" format of PyParse_ParseTuple()

[STINNER Victor]

STINNER Victor  added the comment:

See also #8592: 'y' does not check for embedded NUL bytes.

--

___
Python tracker 

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

[issue8592] 'y' does not check for embedded NUL bytes

[STINNER Victor]

STINNER Victor  added the comment:

See also #8850: Remove "w" format of PyParse_ParseTuple().

--

About "y": the parser HAVE TO check for embedded NUL bytes, because the caller 
doesn't know the size of the buffer (and strlen() would give the wrong size).

--

___
Python tracker 

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

[issue7839] Popen should raise ValueError if pass a string when shell=False or a list when shell=True

[Eric Smith]

Eric Smith  added the comment:

I agree with David. For the issue raised here, at most I would make (list, 
shell=True) and (str, shell=False) raise errors.

There's an issue (that I can't find right now) for creating functions that 
convert from str->list and list->str for cases such as this. shlex is sort of 
str->list, but it has issues on Windows. I've mentioned elsewhere that for 
Windows list->str is not always possible, because there is no standard for the 
corresponding str->list that each program is responsible for.

On Unix-like systems, when the called programs are run they get a pre-parsed 
list (argv). This list is created by the caller, either directly or through a 
shell. When a shell is doing this, at least the behavior is somewhat standard.

On Windows, the called programs get a string, and they're in charge of parsing 
it, if they want to. Many programs use the C library to create argv, but 
exactly how that parsing works changes between runtime vendors and over time 
within a vendor. There's no solution that will work in all cases.

Which is not to suggest that we shouldn't try, just that it will be hard.

--

___
Python tracker 

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

[issue8945] Bug in **kwds expansion on call?

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Somewhere, we should document the-facts-of-life for subclassing builtins.

1) For the most part, C code has the pattern
   if isinstance(obj, some_builtin_type):
   call the built_type's methods directly using slotted methods
   otherwise:
   use slower getattribute style calls

2) A subclasser of a dict needs to actually populate the dict with the values 
they want used.   The built-in dict class is "open for extension and closed for 
modification" -- the open/closed principle.  This is necessary or else a 
subclasser could easily break the built-in type's invariants and crash python.

3) For the most part, only something like subclassing UserDict gives you full 
control.

--
nosy: +rhettinger

___
Python tracker 

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

[issue3831] Multiprocessing: Expose underlying pipe in queues

[Andres Freund]

Andres Freund  added the comment:

As soon as some bytes are signalled as being available one can simply do a 
normal get(). I don't really see the problem here?
Sure, the get() might not be completely non-blocking (especially if the 
transferred event is more than the size of a pipe-buffer) but I have a hard 
time seing that as a problem as that should be both rare and only last a short 
time.

My personal use-case is being able to efficiently wait for evens from different 
queues - using the standard api one currently can only do that by busy 
looping...

The biggest thing I see where you have to be careful here is some stomping herd 
phenomenon you will get into if you have multiple readers doing a poll().
Namely *all* off those processes will awake and run into .get() which isnt 
exactly nice, but thats hardly solvable on python level.

--
nosy: +andresfreund

___
Python tracker 

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