[issue23098] mknod devices can be >32 bits

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

And here are patches for 2.7 and 3.4 (unfortunately none of patches is applied 
clear to other version).

--
Added file: http://bugs.python.org/file37532/posix_dev_t_converter-2.7.patch
Added file: http://bugs.python.org/file37533/posix_dev_t_converter-3.4.patch

___
Python tracker 

___diff -r c6491d91d59a Modules/posixmodule.c
--- a/Modules/posixmodule.c Sat Dec 20 17:42:24 2014 +0200
+++ b/Modules/posixmodule.c Tue Dec 23 09:48:10 2014 +0200
@@ -474,6 +474,29 @@ OverflowUp:
 #endif /* MS_WINDOWS */
 
 
+#if defined(HAVE_MKNOD) && defined(HAVE_MAKEDEV)
+static int
+_Py_Dev_Converter(PyObject *obj, void *p)
+{
+#ifdef HAVE_LONG_LONG
+*((dev_t *)p) = PyLong_AsUnsignedLongLong(obj);
+#else
+*((dev_t *)p) = PyLong_AsUnsignedLong(obj);
+#endif
+if (PyErr_Occurred())
+return 0;
+return 1;
+}
+
+#ifdef HAVE_LONG_LONG
+#  define _PyLong_FromDev PyLong_FromLongLong
+#else
+#  define _PyLong_FromDev PyLong_FromLong
+#endif
+
+#endif
+
+
 #if defined _MSC_VER && _MSC_VER >= 1400
 /* Microsoft CRT in VS2005 and higher will verify that a filehandle is
  * valid and raise an assertion if it isn't.
@@ -1426,11 +1449,10 @@ static PyObject*
 #else
 PyStructSequence_SET_ITEM(v, 1, PyInt_FromLong((long)st->st_ino));
 #endif
-#if defined(HAVE_LONG_LONG) && !defined(MS_WINDOWS)
-PyStructSequence_SET_ITEM(v, 2,
-  PyLong_FromLongLong((PY_LONG_LONG)st->st_dev));
+#ifdef MS_WINDOWS
+PyStructSequence_SET_ITEM(v, 2, PyLong_FromUnsignedLong(st->st_dev));
 #else
-PyStructSequence_SET_ITEM(v, 2, PyInt_FromLong((long)st->st_dev));
+PyStructSequence_SET_ITEM(v, 2, _PyLong_FromDev(st->st_dev));
 #endif
 PyStructSequence_SET_ITEM(v, 3, PyInt_FromLong((long)st->st_nlink));
 #if defined(MS_WINDOWS)
@@ -7009,9 +7031,11 @@ posix_mknod(PyObject *self, PyObject *ar
 {
 char *filename;
 int mode = 0600;
-int device = 0;
+dev_t device = 0;
 int res;
-if (!PyArg_ParseTuple(args, "s|ii:mknod", &filename, &mode, &device))
+if (!PyArg_ParseTuple(args, "s|iO&:mknod",
+&filename, &mode,
+_Py_Dev_Converter, &device))
 return NULL;
 Py_BEGIN_ALLOW_THREADS
 res = mknod(filename, mode, device);
@@ -7031,8 +7055,8 @@ Extracts a device major number from a ra
 static PyObject *
 posix_major(PyObject *self, PyObject *args)
 {
-int device;
-if (!PyArg_ParseTuple(args, "i:major", &device))
+dev_t device;
+if (!PyArg_ParseTuple(args, "O&:major", _Py_Dev_Converter, &device))
 return NULL;
 return PyInt_FromLong((long)major(device));
 }
@@ -7044,8 +7068,8 @@ Extracts a device minor number from a ra
 static PyObject *
 posix_minor(PyObject *self, PyObject *args)
 {
-int device;
-if (!PyArg_ParseTuple(args, "i:minor", &device))
+dev_t device;
+if (!PyArg_ParseTuple(args, "O&:minor", _Py_Dev_Converter, &device))
 return NULL;
 return PyInt_FromLong((long)minor(device));
 }
@@ -7060,7 +7084,7 @@ posix_makedev(PyObject *self, PyObject *
 int major, minor;
 if (!PyArg_ParseTuple(args, "ii:makedev", &major, &minor))
 return NULL;
-return PyInt_FromLong((long)makedev(major, minor));
+return _PyLong_FromDev(makedev(major, minor));
 }
 #endif /* device macros */
 
@@ -8522,7 +8546,6 @@ setup_confname_table(struct constdef *ta
 {
 PyObject *d = NULL;
 size_t i;
-
 qsort(table, tablesize, sizeof(struct constdef), cmp_constdefs);
 d = PyDict_New();
 if (d == NULL)
diff -r c4643b32cd9a Modules/posixmodule.c
--- a/Modules/posixmodule.c Mon Dec 22 22:09:50 2014 +0100
+++ b/Modules/posixmodule.c Tue Dec 23 09:37:08 2014 +0200
@@ -623,6 +623,29 @@ fail:
 #endif /* MS_WINDOWS */
 
 
+#if defined(HAVE_MKNOD) && defined(HAVE_MAKEDEV)
+static int
+_Py_Dev_Converter(PyObject *obj, void *p)
+{
+#ifdef HAVE_LONG_LONG
+*((dev_t *)p) = PyLong_AsUnsignedLongLong(obj);
+#else
+*((dev_t *)p) = PyLong_AsUnsignedLong(obj);
+#endif
+if (PyErr_Occurred())
+return 0;
+return 1;
+}
+
+#ifdef HAVE_LONG_LONG
+#  define _PyLong_FromDev PyLong_FromLongLong
+#else
+#  define _PyLong_FromDev PyLong_FromLong
+#endif
+
+#endif
+
+
 #ifdef AT_FDCWD
 /*
  * Why the (int) cast?  Solaris 10 defines AT_FDCWD as 0xffd19553 (-3041965);
@@ -2218,11 +2241,8 @@ static PyObject*
 #endif
 #ifdef MS_WINDOWS
 PyStructSequence_SET_ITEM(v, 2, PyLong_FromUnsignedLong(st->st_dev));
-#elif defined(HAVE_LONG_LONG)
-PyStructSequence_SET_ITEM(v, 2,
-  PyLong_FromLongLong((PY_LONG_LONG)st->st_dev));
-#else
-PyStructSequence_SET_ITEM(v, 2, PyLong_FromLong((long)st->st_dev));
+#else
+PyStructSequence_SET_ITEM(v, 2, _PyLong_FromDev(st->st_dev));
 #endif
 PyStructSequence_SET_ITEM(v, 3, PyLong_FromLong((long)st->st_nlink));
 #if defined(MS_WINDOWS)
@@ -8633,16 +865

[issue23099] BytesIO and StringIO values unavailable when closed

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Here is a patch which rejects close() when a buffer is exported.

--
keywords: +patch
stage:  -> patch review
versions: +Python 2.7, Python 3.5
Added file: http://bugs.python.org/file37531/bytesio_exported_reject_close.patch

___
Python tracker 

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

[issue19548] 'codecs' module docs improvements

[Martin Panter]

Martin Panter added the comment:

New patch version addressing many of the comments; thanks for reviewing! Also 
adds and extends some unit tests to confirm some of the corner cases I am 
documenting.

--
Added file: http://bugs.python.org/file37530/codecs-doc.v3.patch

___
Python tracker 

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

[issue23100] multiprocessing doc organization impedes understanding

[Ned Deily]

Changes by Ned Deily :


--
nosy: +sbt

___
Python tracker 

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

[issue23102] distutils: tip-toe around quirks owing to setuptools monkey-patching Extension

[Greg Turner]

New submission from Greg Turner:

Clinical Presentation:
Sometimes a developer consuming distutils will write what seems like a 
perfectly sensible setup.py, but something inscrutable happens: setup.py bombs 
out claiming "error: each element of 'ext_modules' option must be an Extension 
instance or 2-tuple".

Prognosis:
Once she manages to capture this error in pdb (takes some doing), intrepid 
developer may discover that, bizarrely, it IS an Extension instance, yet, 
somehow, (not isinstance(that_thing, Extension)) == True.  Sooner or later 
she'll likely throw up her hands and follow some far-seeing dude's advice on 
StackOverflow([1]), which will probably work.

If she undertakes a more thorough investigation, she may figure out the true 
etiology (see below), at which point, various minor tweaks will likely present 
themselves to her as obvious situation-specific solutions to the problem.

Etiology:
Developer likely employed code early in her module like:

  from distutils.extension import Extension

  .
  . (some other imports)
  .

  setup(..., ext_modules = [
  Extension(...), 
  ...,
  ], ...)

What happened was that setuptools got imported by (presumably) some third-party 
code, at which point, setuptools monkey-patched 
distutils.extension.Extension(*), as is setuptools' SOP.

However, in setup.py, a reference to the un-monkey-patched Extension was 
already saved off as __main__.Extension (along with, in all probability, other 
un-patched distutils things, as folks tend to consistently use one style or 
another of import).  So __main__ calls (an un-monkey-patched version of) 
distutils.core.setup, which ultimately iterates through the list of Extensions, 
checking isinstance(item, Extension), or so, which, as can now be seen, is not 
going to be true.

So, the error message is correct, it just fails to mention the possibility that 
there are multiple things called "Extension" floating around with identical 
repr's.

Epidemiological Outlook:
Seemingly this is a rare condition, but when a case develops, it can be costly, 
due to the likelihood of misdiagnosis and/or partial remission and relapse.

One possible vaccine has been developed and is enclosed.  It has not been 
subjected to clinical trial, nor peer-review (until now).  It is enclosed as a 
patch which applies to python 2.7-3.5 and seems to do the trick in the 
particular case that was buggin' me (wish I could say it will do the trick for 
any non-broken use-case, but I can't, as if I made such a claim, I'd clearly 
jinx it).

--
* Arguably, this is a bug or misfeature of setuptools, as here setuptools 
appears to too liberally assume that, if its modules were even casually 
imported, then it's a good time to monkey-patch distutils.  However, IME, 
fixing this putative bug, threatens to be a non-trivial undertaking and cause a 
bunch of regressions and contingent hassles.

Background URLS:

[1] 
http://stackoverflow.com/questions/21594925/error-each-element-of-ext-modules-option-must-be-an-extension-instance-or-2-t

https://bitbucket.org/pypa/setuptools/issue/309

https://bugs.gentoo.org/show_bug.cgi?id=532708

--
components: Distutils
files: distutils_accomodate_extension_ducktypes.patch
keywords: patch
messages: 233034
nosy: dstufft, eric.araujo, gmt
priority: normal
severity: normal
status: open
title: distutils: tip-toe around quirks owing to setuptools monkey-patching 
Extension
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: 
http://bugs.python.org/file37529/distutils_accomodate_extension_ducktypes.patch

___
Python tracker 

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

[issue23101] bleh, sorry, my cat reported this non-bug :)

[Éric Araujo]

New submission from Éric Araujo:

:-)

--
resolution:  -> not a bug
stage:  -> resolved

___
Python tracker 

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

[issue23101] bleh, sorry, my cat reported this non-bug :)

[Greg Turner]

Changes by Greg Turner :


--
status: open -> closed
title: \\di -> bleh, sorry, my cat reported this non-bug :)

___
Python tracker 

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

[issue23101] \\di\\\\

[Greg Turner]

Changes by Greg Turner :


--
components: Distutils
nosy: dstufft, eric.araujo, gmt
priority: normal
severity: normal
status: open
title: \\di

___
Python tracker 

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

[issue22952] multiprocessing doc introduction not in affirmative tone

[Davin Potts]

Davin Potts added the comment:

Procedural question (wanting to understand the label given to this issue):  
when documentation does not adhere to the Python Developer's Guide, is a fix 
for this considered an "enhancement"?

--
versions: +Python 3.6

___
Python tracker 

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

[issue23100] multiprocessing doc organization impedes understanding

[Davin Potts]

Davin Potts added the comment:

I am happy to provide proposed patches but first can someone please clarify for 
me whether I should have those patches depend upon the patches from Issue 22952?

--

___
Python tracker 

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

[issue23100] multiprocessing doc organization impedes understanding

[Davin Potts]

New submission from Davin Potts:

The organization and multiple sections of the multiprocessing module's 
documentation do not adhere to the Python Dev Guidelines for economy of 
expression, affirmative tone, and/or code examples.

Problem description:
The raw material and information in the multiprocessing module docs are good to 
excellent and very information rich -- the presentation of that information 
suffers primarily from its organization.
(1)  Too much information is presented in the same or neighboring subsections 
where the economy of expression guidelines would advocate for a different 
approach.  Specifically, section 17.2.2 "Reference" co-mingles discourses on 
usage topics with a description of the available objects and apis.  Section 
17.2.1 "Introduction" does something similar and though some of this can be 
helpful in an intro section, it takes discourse a bit far at times, arguably 
losing its focus which is to clearly introduce the reader to the module and 
efficiently set them on a healthy path to understanding topics and establish 
sufficient comfort to begin working with the module.  Economy of expression 
would have us maintain focus in an Introduction or Reference section and 
re-organize such helpful discourses into supporting but distinct sections.
(2) Affirmative tone is not consistently used throughout the docs.  Multiple of 
the items under section 17.2.3 "Programming guidelines" leverage negative 
examples to motivate what should be done instead -- each of these can be 
rewritten in the way advocated in the Python Dev Guidelines for affirmative 
tone.
(3) Per the Python Dev Guidelines for code examples, examples should accelerate 
understanding versus alternative prose.  Code snippets showcasing internal 
behavior to the module, such as the "Beware of replacing sys.stdin" subsection 
inside 17.2.3.1 "All start methods", should arguably have their example code 
blocks replaced with prose.  Section 17.2.4 "Examples" provides examples 
showcasing many facets all in the same example code block yet little to no 
supporting or motivating explanation is offered for each (more could be offered 
inline as well as outside as prose).

Suggested changes:
* Re-organize the single multiprocessing module doc into multiple in the style 
of the logging module.  Specifically, tutorials should be created to house the 
"bunny trail" discourses from the Introduction/Reference sections and a 
cookbook should be created to house the material from the Examples section.
* By de-bunny-trailing the Introduction/Reference sections, a more focused set 
of sections in the style of the threading module should result.
* Limited modifications to code examples are advocated only so far as they 
restore the affirmative tone as needed.
* New examples are not advocated as part of this issue; they are out-of-scope.

This issue is intended to add to the path started/advocated by Issue 22952.  It 
does not supplant but rather expands upon that issue.

--
assignee: docs@python
components: Documentation
messages: 233030
nosy: davin, docs@python, rhettinger
priority: normal
severity: normal
status: open
title: multiprocessing doc organization impedes understanding
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

___
Python tracker 

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

[issue22671] Typo in class io.BufferedIOBase docs

[Martin Panter]

Martin Panter added the comment:

Adding patch v2 with readinto1() as a “mixin method” and dropped many of my 
earlier changes for better consistency with the introduction of the classes 
(which I never really read before :P)

--
Added file: http://bugs.python.org/file37528/read-defaults.v2.patch

___
Python tracker 

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

[issue23088] Document that PyUnicode_AsUTF8() returns a null-terminated string

[Antoine Pitrou]

Antoine Pitrou added the comment:

This looks good to me.

--
nosy: +pitrou
stage:  -> commit review
type:  -> behavior
versions: +Python 3.5

___
Python tracker 

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

[issue23096] Implementation-depended pickling floats with protocol 0

[Antoine Pitrou]

Antoine Pitrou added the comment:

This looks less like a bug than an enhancement request.

--

___
Python tracker 

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

[issue23098] mknod devices can be >32 bits

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

As pointed by Antoine there are other affected functions. Updated patch fixes 
converting of arguments or results in makedev(), major() and minor().

--
Added file: http://bugs.python.org/file37527/posix_dev_t_converter-3.5_2.patch

___
Python tracker 

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

[issue21279] str.translate documentation incomplete

[Martin Panter]

Martin Panter added the comment:

The problem with mappings and sequences is that they both require len() and 
iter() implementations, but str.translate() only requires __getitem__(). 
Perhaps a qualifier could work, like:

The table must implement the __getitem__() method of mappings and sequences.

--

___
Python tracker 

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

[issue23096] Implementation-depended pickling floats with protocol 0

[Alexandre Vassalotti]

Alexandre Vassalotti added the comment:

The repr for floats was changed some time ago to use a shorter decimal strings 
when possible. Both representations should yield the same float value once 
decoded. If we want to make the C and Python implementations of pickle 
consistent, then we should pick on what the Python version does currently: 
i.e., call repr on the float.

--

___
Python tracker 

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

[issue23099] BytesIO and StringIO values unavailable when closed

[Antoine Pitrou]

Antoine Pitrou added the comment:

> Even worse, the memoryview gets corrupted on close():

The BytesIO object should probably reject closing when a buffer is exported.

> writing to the file seems to be completely disallowed, even if it 
> would not seem to change the size:

An enhancement is probably possible there.

--
nosy: +pitrou

___
Python tracker 

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

[issue19548] 'codecs' module docs improvements

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti

___
Python tracker 

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

[issue23098] mknod devices can be >32 bits

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Here is a patch against 3.5. Unsigned bitwise int converter is used for dev_t 
because dev_t can be unsigned (and it is on Linux). This is not ideal solution, 
there is no overflow check, but at least it should work for correct code.

--
keywords: +patch
Added file: http://bugs.python.org/file37526/posix_dev_t_converter-3.5.patch

___
Python tracker 

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

[issue22939] integer overflow in iterator object

[Clement Rouault]

Clement Rouault added the comment:

> > The call to PySequence_GetItem() may be expensive, and we have to drop
> > the result if an OverflowError is raised after the call.

> You do realize that this error will be very rare and therefore 
> inconsequential.

The real question is: why would you call the iterator for a new value if it 
will be discarded anyway ? I think it could be very misleading to see  
_getitem__ being called and have an OverflowError being raised afterward.

--

___
Python tracker 

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

[issue19548] 'codecs' module docs improvements

[Nick Coghlan]

Nick Coghlan added the comment:

Thanks for those drafts, Martin - they look like a strong improvement to me. 
While I still had plenty of comments/questions on v2, I think that's more a 
reflection on how long it has been since we gave these docs a thorough overall 
review, moreso than a reflection on the proposed changes.

Victor - I added you to the nosy list for this one, as I'd specifically like 
your comments on the StreamReader/Writer docs updates. I'd like to make it 
clear that these are distinct from the "text encoding only" APIs in the io 
module, while still accurately describing the behaviour of the standard codecs.

--
nosy: +haypo
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

[issue23098] mknod devices can be >32 bits

[Jesús Cea Avión]

Jesús Cea Avión added the comment:

Serhiy, could you consider to create a patch for 2.7 and 3.4?. I am not 
familiar with the details of Argument Clinic.

--

___
Python tracker 

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

[issue23099] BytesIO and StringIO values unavailable when closed

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

getvalue() doesn't work after close() for purpose. close() frees memory used by 
BytesIO.

>>> import io, sys
>>> bio = io.BytesIO()
>>> sys.getsizeof(bio)
52
>>> bio.write(b'x'*1000)
1000
>>> sys.getsizeof(bio)
1053
>>> bio.close()
>>> sys.getsizeof(bio)
52

Changing the behavior will cause regression.

The behavior of memoryview looks as a bug.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue19548] 'codecs' module docs improvements

[Martin Panter]

Martin Panter added the comment:

Adding patch v2 after learning how to compile the docs and fixing my errors. I 
also simplified the descriptions of the CodecInfo attributes by defering the 
constructor signatures to where they are fully defined under “Codec base 
classes”, and merged the list of error handlers there as well.

A side effect of merging error handler lists is that “surrogatepass” is now 
defined for codecs in general, not just Codec.encode() and decode().

Also I noticed that “unicode_escape” actually does Latin-1 decoding.

--
Added file: http://bugs.python.org/file37525/codecs-doc.v2.patch

___
Python tracker 

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

[issue23099] BytesIO and StringIO values unavailable when closed

[Martin Panter]

New submission from Martin Panter:

IOBase.close() doc says file operations raise ValueError, but it is not obvious 
to me that reading back the “file” buffer is a file operation.

>>> with BytesIO() as b:
... b.write(b"123")
... 
3
>>> b.getvalue()
Traceback (most recent call last):
  File "", line 1, in 
ValueError: I/O operation on closed file.

Even worse, the memoryview gets corrupted on close():

>>> b = BytesIO(b"123")
>>> m = b.getbuffer()
>>> b.close()
>>> bytes(m)
b'\x98\x02>'

I also noticed that in the “io” implementation, writing to the file seems to be 
completely disallowed, even if it would not seem to change the size:

>>> b = BytesIO(b"123")
>>> m = b.getbuffer()
>>> b.write(b"x")
Traceback (most recent call last):
  File "", line 1, in 
BufferError: Existing exports of data: object cannot be re-sized

--
components: IO
messages: 233016
nosy: vadmium
priority: normal
severity: normal
status: open
title: BytesIO and StringIO values unavailable when closed
type: behavior
versions: Python 3.4

___
Python tracker 

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

[issue23098] mknod devices can be >32 bits

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

This is not so easy as look at first glance. PY_LONG_LONG should be used 
instead of long long. And as far as this type is optional, its use should be 
conditional if HAVE_LONG_LONG is defined.

May be needed complex converter like _Py_Uid_Converter because dev_t on Linux 
is 64-bit unsigned int and can not fit in the range of 64-bit signed int.

The code for 3.x should be even more complex due to using Argument Clinic.

--
components: +Extension Modules
nosy: +serhiy.storchaka
type:  -> behavior

___
Python tracker 

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

[issue21279] str.translate documentation incomplete

[Terry J. Reedy]

Terry J. Reedy added the comment:

I agree with Serhiy: no bullet points, links to glossary (at least in doc), 
without repeating.

--

___
Python tracker 

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