[issue25847] CPython not using Visual Studio code analysis!

[Alexander Riccio]

Alexander Riccio added the comment:

> That is, (as I undersatnd it) we've done a lot of work to not have compiler 
> warnings generated during compilation, and we don't want to backtrack on that.

Well, as-is, simply building as x64 generates a bunch of warnings, so it's not 
*quite* clean. I totally understand the need to keep warning-clean, but, well:

..\Modules\_pickle.c(5087): warning C4244: 'function': conversion from 
'Py_ssize_t' to 'int', possible loss of data 
[C:\PythonDev\repo\PCbuild\pythoncore.vcxproj]

..\Modules\posixmodule.c(3321): warning C4267: 'function': conversion from 
'size_t' to 'int', possible loss of data 
[C:\PythonDev\repo\PCbuild\pythoncore.vcxproj]

..\Modules\_tracemalloc.c(67): warning C4359: '': Alignment 
specifier is less than actual alignment (8), and will be ignored. 
[C:\PythonDev\repo\PCbuild\pythoncore.vcxproj]

..\Modules\zipimport.c(914): warning C4244: 'function': conversion from 
'Py_ssize_t' to 'long', possible loss of data 
[C:\PythonDev\repo\PCbuild\pythoncore.vcxproj]

..\Objects\codeobject.c(111): warning C4244: '=': conversion from 'Py_ssize_t' 
to 'unsigned char', possible loss of data 
[C:\PythonDev\repo\PCbuild\pythoncore.vcxproj]

..\Objects\funcobject.c(635): warning C4244: 'function': conversion from 
'Py_ssize_t' to 'int', possible loss of data 
[C:\PythonDev\repo\PCbuild\pythoncore.vcxproj]

..\Objects\funcobject.c(636): warning C4244: 'function': conversion from 
'Py_ssize_t' to 'int', possible loss of data 
[C:\PythonDev\repo\PCbuild\pythoncore.vcxproj]

..\PC\winreg.c(885): warning C4311: 'type cast': pointer truncation from 'void 
*' to 'DWORD' [C:\PythonDev\repo\PCbuild\pythoncore.vcxproj]

..\PC\getpathp.c(144): warning C4267: '=': conversion from 'size_t' to 'int', 
possible loss of data [C:\PythonDev\repo\PCbuild\pythoncore.vcxproj]

..\PC\msvcrtmodule.c(391): warning C4312: 'type cast': conversion from 'int' to 
'_HFILE' of greater size [C:\PythonDev\repo\PCbuild\pythoncore.vcxproj]

..\PC\msvcrtmodule.c(391): warning C4311: 'type cast': pointer truncation from 
'_HFILE' to 'long' [C:\PythonDev\repo\PCbuild\pythoncore.vcxproj]

..\PC\msvcrtmodule.c(538): warning C4311: 'type cast': pointer truncation from 
'_HFILE' to 'int' [C:\PythonDev\repo\PCbuild\pythoncore.vcxproj]

..\PC\msvcrtmodule.c(539): warning C4311: 'type cast': pointer truncation from 
'_HFILE' to 'int' [C:\PythonDev\repo\PCbuild\pythoncore.vcxproj]

..\PC\msvcrtmodule.c(540): warning C4311: 'type cast': pointer truncation from 
'_HFILE' to 'int' [C:\PythonDev\repo\PCbuild\pythoncore.vcxproj]

..\Python\ceval.c(4826): warning C4244: '=': conversion from 'Py_ssize_t' to 
'int', possible loss of data [C:\PythonDev\repo\PCbuild\pythoncore.vcxproj]

..\Python\ceval.c(5021): warning C4244: '=': conversion from 'Py_ssize_t' to 
'int', possible loss of data [C:\PythonDev\repo\PCbuild\pythoncore.vcxproj]

..\Python\compile.c(480): warning C4312: 'type cast': conversion from 'unsigned 
int' to 'void *' of greater size [C:\PythonDev\repo\PCbuild\pythoncore.vcxproj]

..\Python\compile.c(481): warning C4312: 'type cast': conversion from 'unsigned 
int' to 'void *' of greater size [C:\PythonDev\repo\PCbuild\pythoncore.vcxproj]

..\Python\compile.c(482): warning C4312: 'type cast': conversion from 'unsigned 
int' to 'void *' of greater size [C:\PythonDev\repo\PCbuild\pythoncore.vcxproj]

..\Python\compile.c(3155): warning C4244: 'initializing': conversion from 
'Py_ssize_t' to 'int', possible loss of data 
[C:\PythonDev\repo\PCbuild\pythoncore.vcxproj]

..\Python\compile.c(3385): warning C4244: 'initializing': conversion from 
'Py_ssize_t' to 'int', possible loss of data 
[C:\PythonDev\repo\PCbuild\pythoncore.vcxproj]


..\Python\peephole.c(482): warning C4244: '=': conversion from 'Py_ssize_t' to 
'int', possible loss of data [C:\PythonDev\repo\PCbuild\pythoncore.vcxproj]

..\Python\peephole.c(535): warning C4244: '=': conversion from 'Py_ssize_t' to 
'int', possible loss of data [C:\PythonDev\repo\PCbuild\pythoncore.vcxproj]

..\Python\peephole.c(553): warning C4244: '=': conversion from 'Py_ssize_t' to 
'int', possible loss of data [C:\PythonDev\repo\PCbuild\pythoncore.vcxproj]

..\Python\peephole.c(581): warning C4244: '=': conversion from 'Py_ssize_t' to 
'int', possible loss of data [C:\PythonDev\repo\PCbuild\pythoncore.vcxproj]

..\Python\peephole.c(592): warning C4244: '=': conversion from 'Py_ssize_t' to 
'unsigned char', possible loss of data 
[C:\PythonDev\repo\PCbuild\pythoncore.vcxproj]

..\Python\peephole.c(625): warning C4244: '=': conversion from 'Py_ssize_t' to 
'int', possible loss of data [C:\PythonDev\repo\PCbuild\pythoncore.vcxproj]

..\Python\peephole.c(639): warning C4244: '-=': conversion from 'Py_ssize_t' to 
'int', possible loss of data [C:\PythonDev\repo\PCbuild\pythoncore.vcxproj]

..\Modules\expat\xmlparse.c(1844): warning C4244: 'return': conversion from 
'__int64' to 'XML_Index', possible loss of data 
[C:\PythonDev\repo\PCbuild\_elementtree.vcxproj

[issue25847] CPython not using Visual Studio code analysis!

[Alexander Riccio]

Alexander Riccio added the comment:

> In which direction do you find us to be mad?

That's really quite a low warning level! For a large project, I can't imagine 
anything less than /W4!

--

___
Python tracker 

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

[issue25863] ISO-2022 seeking forgets state

[Martin Panter]

New submission from Martin Panter:

>>> from io import *
>>> text = TextIOWrapper(BytesIO(), "iso-2022-jp")
>>> text.write(u"P")
1
>>> text.tell()
1
>>> text.write(u"anter 正")
7
>>> text.tell()
12
>>> text.write(u"孝")
1
>>> text.seek(12)
12
>>> text.read()  # Should return 孝, not ASCII
"9'"
>>> text.buffer.getvalue()
b"Panter \x1b$B@59'"
>>> text.seek(1)
1
>>> text.read(7)
'anter 正'
>>> text.tell()  # Another bug?
Traceback (most recent call last):
  File "", line 1, in 
UnicodeDecodeError: 'iso2022_jp' codec can't decode bytes in position 2-3: 
illegal multibyte sequence

--
components: IO, Unicode
messages: 256431
nosy: ezio.melotti, haypo, martin.panter
priority: normal
severity: normal
status: open
title: ISO-2022 seeking forgets state
type: behavior
versions: Python 2.7, 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

[issue25847] CPython not using Visual Studio code analysis!

[Alexander Riccio]

Alexander Riccio added the comment:

Actually, hmm... the very naive version *DOES NOT* work. Grr.

--

___
Python tracker 

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

[issue20120] Percent-signs (%) in .pypirc should not be interpolated

[Thomas Levine]

Thomas Levine added the comment:

The error message could just say. something to the effect of ".pypyrc works 
differently in Python 2 and Python 3. If you want a percent sign in Python 3, 
you have to escape it with another percent sign".

Suppose someone is already using a configuration file that specifies a value as 
having two literal percent signs in a row, like a password that actually 
contains two percent signs. I see no way of fixing the present bug without 
breaking this situation, and I presume that this is why Antoine suggested that 
this is a wont fix.

--

___
Python tracker 

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

[issue25847] CPython not using Visual Studio code analysis!

[Zachary Ware]

Zachary Ware added the comment:

In which direction do you find us to be mad?

--

___
Python tracker 

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

[issue20120] Percent-signs (%) in .pypirc should not be interpolated

[Jason R. Coombs]

Jason R. Coombs added the comment:

It doesn't make sense to give guidance to use one percent sign on one Python 
and two on another because .pypirc applies to all Python versions. I'm sure 
it's not uncommon for one to use different versions of Python for various 
package releases.

I'm planning to use RawConfigParser in Setuptools. If there's no fallout from 
this change, I suggest that Python 3 should do the same for distutils in bugfix 
releases, as this behavior is a regression over Python 2.

--

___
Python tracker 

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

[issue25847] CPython not using Visual Studio code analysis!

[Alexander Riccio]

Alexander Riccio added the comment:

Hold on... CPython builds at /W3???!? What is this madness??!?

--
Added file: http://bugs.python.org/file41312/CPythonW3.PNG

___
Python tracker 

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

[issue25847] CPython not using Visual Studio code analysis!

[Steve Dower]

Steve Dower added the comment:

Doing the work to clean up the warnings really has to come second, ultimately.

The buildbot script also should be updated to pass that option.

--

___
Python tracker 

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

[issue25862] TextIOWrapper assertion failure after read() and SEEK_CUR

[Martin Panter]

New submission from Martin Panter:

Python 3.5.1+ (3.5:014e6f7d7c1a, Dec 14 2015, 11:20:58) 
[GCC 5.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from io import *
>>> text = TextIOWrapper(BytesIO(b"x"), "ascii")
>>> text.read(1)
'x'
>>> text.read()
''
>>> text.seek(0, SEEK_CUR)
python: ./Modules/_io/textio.c:2293: _io_TextIOWrapper_tell_impl: Assertion 
`self->decoded_chars == ((void *)0) || PyUnicode_GetLength(self->decoded_chars) 
== 0' failed.
Aborted (core dumped)
[Exit 134]

May affect other versions; I haven’t looked.

--
components: IO
messages: 256430
nosy: martin.panter
priority: normal
severity: normal
status: open
title: TextIOWrapper assertion failure after read() and SEEK_CUR
type: crash
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

[issue20120] Percent-signs (%) in .pypirc should not be interpolated

[Jason R. Coombs]

Jason R. Coombs added the comment:

This same issue applies to setuptools 
(https://bitbucket.org/pypa/setuptools/issues/442/setuptools-1832-cannot-access-pypi-if-pypi).

I've created a test that captures the failure, but I struggled to find a 
solution that doesn't break across Python versions.

Thomas suggested guiding the user to provide two percent signs instead of one, 
but that breaks on Python 2, which will interpret the value as two percent 
signs.

As suggested, using RawConfigParser does address the issue on both Python 2 and 
3, but that of course could break compatibility if interpolation was expected.

I have found that if one uses SafeConfigParser on Python 2 and 3, and requires 
the user to use two percent signs to represent one, it does seem to work on 
both Python 2 and 3.

--
nosy: +jason.coombs

___
Python tracker 

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

[issue25860] os.fwalk() silently skips remaining directories when error occurs

[Samson Lee]

Changes by Samson Lee :


--
nosy: +hynek, neologix

___
Python tracker 

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

[issue25860] os.fwalk() silently skips remaining directories when error occurs

[Samson Lee]

Changes by Samson Lee :


--
nosy: +benhoyt, haypo

___
Python tracker 

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

[issue25860] os.fwalk() silently skips remaining directories when error occurs

[Samson Lee]

New submission from Samson Lee:

I noticed os.fwalk() produced different results as os.walk(). It turned out
that os.fwalk() skips all remaining directories when OSError occurs (e.g. due
to PermissionError).

To reproduce the bug, first create a test directory structure:

$ mkdir 1; touch 1/a
$ mkdir 2; touch 2/b
$ mkdir 3; touch 3/c
$ mkdir 4; touch 4/c

At this stage, everything is okay, both os.fwalk() os.walk() produce the same
results:

>>> import os
>>> for root, dirs, files in os.walk('.'):
... dirs.sort()
... print(root, dirs, files)
. ['1', '2', '3', '4'] []
./1 [] ['a']
./2 [] ['b']
./3 [] ['c']
./4 [] ['d']
>>> for root, dirs, files, fd in os.fwalk('.'):
... dirs.sort()
... print(root, dirs, files)
. ['1', '2', '3', '4'] []
./1 [] ['a']
./2 [] ['b']
./3 [] ['c']
./4 [] ['d']

To introduce an error, force a PermissionError on one of the directories:

$ sudo chown root:root 2
$ sudo chmod 700 2

Now, the os.fwalk() results are different (trust me, os.walk() is still okay):

>>> for root, dirs, files, fd in os.fwalk('.'):
... dirs.sort()
... print(root, dirs, files)
. ['1', '2', '3', '4'] []
./1 [] ['a']

So it seems that os.fwalk skips remaining directories after an error occurs.

The cause of the problem is in this part of os.py:

for name in dirs:
try:
orig_st = stat(name, dir_fd=topfd, follow_symlinks=follow_symlinks)
dirfd = open(name, O_RDONLY, dir_fd=topfd)
except OSError as err:
if onerror is not None:
onerror(err)
break

To fix it, simply replace break with continue. Patch attached.

Cheers

--
components: Library (Lib)
files: fwalk-silently-skips-dirs-when-error-occurs.patch
keywords: patch
messages: 256377
nosy: Samson Lee
priority: normal
severity: normal
status: open
title: os.fwalk() silently skips remaining directories when error occurs
type: behavior
versions: Python 3.4, Python 3.5
Added file: 
http://bugs.python.org/file41304/fwalk-silently-skips-dirs-when-error-occurs.patch

___
Python tracker 

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

[issue25849] files, opened in unicode (text): write() returns symbols count, but seek() expect offset in bytes

[Martin Panter]

Martin Panter added the comment:

You might be right about the “reconstruction algorithm”. This text was added in 
revision 0bba533c0959; maybe Antoine can comment whether we should clarify or 
remove it.

I think the text added for TextIOBase.seek() in revision 03e61104f7a2 (Issue 
12922) is closer to the truth. Though I would probably drop the bit about 
tell() not usually returning a byte position; for many codecs it does seem to.

This illustrates the only four cases of seeking I understand are allowed for 
text streams:

>>> text = TextIOWrapper(BytesIO(), "utf-7")
>>> text.write("привет")
6
>>> text.seek(0)  # 1: Rewind to start
0
>>> text.read(1)
'п'
>>> saved = text.tell()
>>> text.read()
'ривет'
>>> text.seek(saved)  # 2: Seek to saved offset
340282368347045388720132684115559317504
>>> text.read(1)
'р'
>>> text.seek(0, SEEK_CUR)  # 3: No movement
680564735267983852183507291547327528960
>>> text.read(1)
'и'
>>> text.seek(0, SEEK_END)  # 4: Seek to end
18
>>> text.read()  # EOF
''

If the “slow reconstruction algorithm” was clarified or removed, and the 
documentation explained that you cannot seek to arbitrary characters without 
having previously called tell(), would that work?

--
nosy: +martin.panter, pitrou

___
Python tracker 

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

[issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError

[Andrew Barnert]

New submission from Andrew Barnert:

Example:

class MyDict(collections.abc.Mapping):
def __init__(self, d): self.d = d
def __len__(self): return len(self.d)
def __getitem__(self, key): return self.d[key]
def __iter__(self): return iter(self.d)

d = {1:2, 3:4}
m = MyDict({1: 2, 3: 4})

If you do `reversed(d)`, you get a nice `TypeError: argument to reversed() must 
be a sequence`. But if you do `reversed(m)`, you get a `reversed` iterator. And 
when you iterate it, presumably expecting to get 0 and 1 in some arbitrary 
order, you instead get 3, and then a `KeyError: 0`.

Of course it's obvious why this happens once you think about it: in order to 
handle types that implement the old-style sequence protocol (just respond to 
`__getitem__` for all integers from 0 to `len(self)`), `reversed` has to fall 
back to trying `__getitem__` for all integers from `len(d)-1` to 0.

If you provide a `__reversed__` method, it just calls that. Or, if you're a 
C-API mapping like `dict`, `PySequence_Check` will return false and it'll raise 
a `TypeError`. But for a Python mapping, there's no way `PySequence_Check` or 
anything else can know that you're not actually a sequence (after all, you 
implement `__getitem__` and `__len__`), so it tries to use you as one, and 
confusion results.

I think trying to fix this for _all_ possible mappings is a non-starter.

But fixing it for mappings that use `collections.abc.Mapping` is easy: just 
provide a default implementation of `collections.abc.Mapping.__reversed__` that 
just raises a `TypeError`.

I can't imagine this would break any working code. If it did, the workaround 
would be simple: just implement `def __reversed__(self): return (self[k] for k 
in reversed(range(len(self`.

--
components: Library (Lib)
messages: 256434
nosy: abarnert
priority: normal
severity: normal
status: open
title: collections.abc.Mapping should include a __reversed__ that raises 
TypeError
type: behavior

___
Python tracker 

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

[issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError

[Swati Jaiswal]

Swati Jaiswal added the comment:

> If you do `reversed(d)`, you get a nice `TypeError: argument to reversed() 
> must be a sequence`. But if you do `reversed(m)`, you get a reversed` 
> iterator. And when you iterate it, presumably expecting to get 0 and 1 in 
> some arbitrary order, you instead get 3, and then a KeyError:0`.

I got 2 instead of 3.

What are we exactly expecting here? How can a dictionary be reversed?

> I can't imagine this would break any working code. If it did, the workaround 
> would be simple: just implement `def __reversed__(self): return (self[k] for 
> k in reversed(range(len(self`.

This seems to make no difference. I still got the KeyError.

--

___
Python tracker 

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

[issue25190] Define StringIO seek offset as code point offset

[Martin Panter]

Martin Panter added the comment:

There were a few tricky bits doing this with _pyio.StringIO, but I think I was 
successful. Here is a patch with both implementations and some tests. If people 
think this should go ahead, I can add documentation.

In the process I may have discovered a bug with the TextIOWrapper 
implementations. Is calling truncate() meant to truncate the internal read 
buffer? At the moment you can read back truncated data, although the underlying 
byte stream is actually truncated.

--
keywords: +patch
Added file: http://bugs.python.org/file41313/stringio-seek.patch

___
Python tracker 

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

[issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError

[Andrew Barnert]

Andrew Barnert added the comment:

> It seems no more interesting or problematic than sequence argument unpacking 
> working with dictionaries, "a, b = {'one': 1, 'two': 2}".

Dictionaries (including dicts, dict subclasses, and custom Mappings) are 
iterables. People use that fact every time they write `for key in d`. So it's 
not at all problematic that they work with iterable unpacking. Especially since 
here, custom Mappings work exactly the same way as dicts, dict subclasses, 
custom Sets, iterators, and every other kind of iterable.

Dictionaries are not sequences. People never write code expecting them to be. 
So it is problematic that they work with sequence reversing. Especially since 
here, custom Mappings do _not_ work the same way as dicts, dict subclasses, 
custom Sets, iterators, and other non-sequences, all of which raise a TypeError.

--

___
Python tracker 

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

[issue25843] lambdas on the same line may incorrectly share code objects

[Mark Lawrence]

Mark Lawrence added the comment:

http://code.activestate.com/recipes/578353-code-to-source-and-back/ compares 
code objects as part of round trip testing.

--
nosy: +BreamoreBoy

___
Python tracker 

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

[issue25843] lambdas on the same line may incorrectly share code objects

[Emanuel Barry]

Emanuel Barry added the comment:

I see. Is there any to special-case those so that only closures use that? Maybe 
by checking on the function object itself - the function itself would be quite 
similar, as well.

@Mark - I think you've misunderstood me (others did too, so I'm going to assume 
I just explained poorly) - I'm not debating the use of comparing code objects, 
I'm talking about the implicit replacement of code objects in functions. 
However, it seems to be of use, so outright removing the behaviour isn't an 
option.

--

___
Python tracker 

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

[issue25857] csv: unexpected result

[R. David Murray]

R. David Murray added the comment:

Well, since there's no real standard for csv, it might have been.  Since it is 
iherently ambiguous according to "normal" csv rules, though, I'd say that if 
that is the case the originating spreadsheet is the one with the bug.  If you 
can prove there is a spreadsheet that uses this format, perhaps an enhancement 
request for csv would be in order.  I don't *think* there's any way to parse 
that with the existing dialect support, though I could be wrong.

--

___
Python tracker 

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

[issue25843] lambdas on the same line may incorrectly share code objects

[Raymond Hettinger]

Raymond Hettinger added the comment:

[Emanuel Barry]
> In which circumstances does comparing two code objects
> (at function creation time, what's more) make any sense?

It makes closures efficient:

>>> def f(x):
def g(y):
return x + y
return g

>>> h = f(1)
>>> i = f(2)
>>> h.__code__ is i.__code__
True

--

___
Python tracker 

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

[issue25861] Can't use Pickle. AttributeError: 'module' object has no attribute '_new_Index'

[SilentGhost]

Changes by SilentGhost :


--
nosy: +alexandre.vassalotti, pitrou
type: crash -> behavior

___
Python tracker 

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

[issue25861] Can't use Pickle. AttributeError: 'module' object has no attribute '_new_Index'

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

_new_Index is a function used in pandas to unpickle its Index objects. Added 29 
Jul 2014 
(https://github.com/pydata/pandas/commit/8d3cb3f36e2f7b415531e3b910f490c01657ecca).
 May be your current pandas is older than that used for pickling.

In any case this is not a Python bug.

--
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> 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

[issue25843] lambdas on the same line may incorrectly share code objects

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> It makes closures efficient:

No, code objects are not compared here. The code object is constant, and f() 
returns different closure objects using the same code object.

AFAIK the comparison of different code objects is used exclusively in testing.

--

___
Python tracker 

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

[issue1753718] base64 "legacy" functions violate RFC 3548

[R. David Murray]

R. David Murray added the comment:

How about we just make the docs more correct and say that input is read until 
readline() returns an empty bytes object?  That should make it clear that a 
line-oriented file is expected.

--

___
Python tracker 

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

[issue20782] base64 module docs do not use the terms 'bytes' and 'string' consistently.

[R. David Murray]

R. David Murray added the comment:

Darn.  I *thought* I remembered there being an existing patch for this when I 
was working on that other issue, but I couldn't find it.

--

___
Python tracker 

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

[issue25847] CPython not using Visual Studio code analysis!

[R. David Murray]

R. David Murray added the comment:

OK, let's move this to patch needed, then, and see if anyone is ambitious 
enough to do the work needed to make it useful to us :)

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

[issue25857] csv: unexpected result

[Ioan Fintescu]

Ioan Fintescu added the comment:

There seems to be a CSV specification, namely IETF RFC 4180, and, as far as
I can tell, it indicates you are correct, and I am wrong.  Especially
points 5., 6., and 7 on page 3.  Here is a quote from 5 (RFC 4180, page 2
).

If fields are not enclosed with double quotes, then double quotes may not
> appear inside the fields.

It gets more specific in 6., and 7.

So the csv module is doing the right thing.  An error message may help,
though.

...muss

On Mon, Dec 14, 2015 at 9:05 AM, R. David Murray 
wrote:

>
> R. David Murray added the comment:
>
> Well, since there's no real standard for csv, it might have been.  Since
> it is iherently ambiguous according to "normal" csv rules, though, I'd say
> that if that is the case the originating spreadsheet is the one with the
> bug.  If you can prove there is a spreadsheet that uses this format,
> perhaps an enhancement request for csv would be in order.  I don't *think*
> there's any way to parse that with the existing dialect support, though I
> could be wrong.
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError

[Swati Jaiswal]

Swati Jaiswal added the comment:

Can it be reproduced in default branch? I tried but got:
AttributeError: module 'collections' has no attribute 'abc'

--
nosy: +curioswati

___
Python tracker 

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

[issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError

[Raymond Hettinger]

Raymond Hettinger added the comment:

I've seen no evidence that this a problem in practice.  It seems no more 
interesting or problematic than sequence argument unpacking working with 
dictionaries, "a, b = {'one': 1, 'two': 2}".

--
nosy: +rhettinger

___
Python tracker 

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

[issue25849] files, opened in unicode (text): write() returns symbols count, but seek() expect offset in bytes

[Martin Panter]

Martin Panter added the comment:

I’m starting to understand that there might be a “reconstruction algorithm” 
needed. When reading, TextIOWrapper buffers decoded characters. If you call 
tell() and there is unread but decoded data, it is not enough to return the 
incremental decoder state. You have to handle the unread buffered data as well. 
Looking at the _pyio tell() implementation, it tries to wind the decoder 
backwards to minimize the state.

--

___
Python tracker 

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

[issue25865] 7.2 Assignment statements documentation is vague and slightly misleading

[Andrew Barnert]

New submission from Andrew Barnert:

>From 
>https://docs.python.org/3/reference/simple_stmts.html#assignment-statements

> If the target list contains one target prefixed with an asterisk, called a 
> “starred” target: The object must be a sequence with at least as many items 
> as there are targets in the target list, minus one. The first items of the 
> sequence are assigned, from left to right, to the targets before the starred 
> target. The final items of the sequence are assigned to the targets after the 
> starred target. A list of the remaining items in the sequence is then 
> assigned to the starred target (the list can be empty).
> Else: The object must be a sequence with the same number of items as there 
> are targets in the target list, and the items are assigned, from left to 
> right, to the corresponding targets.

The word "sequence" is used here multiple times. But the object being assigned 
to the target list can be any iterable (including an iterator, a set, some 
weird custom iterable you invent, ...).

> If the target is a target list enclosed in parentheses or in square brackets: 
> The object must be an iterable with the same number of items as there are 
> targets in the target list, and its items are assigned, from left to right, 
> to the corresponding targets.

This doesn't mention that you can have a starred target inside the 
parenthesized or bracketed target list. More importantly, it covers the exact 
same case already covered above. There's semantics for "assignment of an object 
to a target list, optionally enclosed in parentheses or square brackets", and 
then semantics for "Assignment of an object to a single target... If the target 
is a target list enclosed in parentheses or in square brackets".

According to the grammar, a single target (no commas, parens, or brackets) is a 
target list, but according to the previous paragraphs it seems like it isn't.

Finally, there's nothing that explains what distinguishes between target list 
assignment and single target assignment. As far as I can tell, it's treated as 
a target list iff there's a comma, or there's square brackets around it 
(similar to the fact that tuples are defined by commas, but lists by square 
brackets--but without the exception for `()`); that should probably be 
documented.

There's also some needless repetition there.

I think better wording might be something like this:

> Assignment is recursively defined as follows.

> * If the target list is a comma-separated list of two or more targets, 
> optionally enclosed in parentheses, or a comma-separated list of zero or more 
> targets enclosed in square brackets:

(It might be worth having a note here pointing out that these are almost the 
same rules for non-comprehension tuple and list displays, except that () is a 
tuple but not a target list. Or would that just be confusing?)

(It might also be worth mentioning that this is the same feature referred to as 
"iterable unpacking", "sequence unpacking", and/or "tuple unpacking" in PEP 
3132, the official tutorial, and lots of non-official materials?)

> ** If the target list contains one target prefixed with an asterisk, called a 
> “starred” target: The object must be an iterable with at least as many items 
> as there are targets in the target list, minus one. The first items of the 
> iterable are assigned, from left to right, to the targets before the starred 
> target. The final items of the iterable are assigned to the targets after the 
> starred target. A list of the remaining items in the iterable is then 
> assigned to the starred target (the list can be empty).

> ** Else: The object must be an iterable with the same number of items as 
> there are targets in the target list, and the items are assigned, from left 
> to right, to the corresponding targets.

> * Otherwise, the target list is treated as a single target. 

> ** If the target is an identifier (name): ...

(No section on bracketed target list here; that's already covered above.)

> ** If the target is an attribute reference: ...

> ** ...

--
assignee: docs@python
components: Documentation
messages: 256443
nosy: abarnert, docs@python
priority: normal
severity: normal
status: open
title: 7.2 Assignment statements documentation is vague and slightly misleading

___
Python tracker 

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

[issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError

[Emanuel Barry]

Emanuel Barry added the comment:

You need to do 'import collections.abc' as abc is a submodule of collections, 
and is not imported from a bare 'import collections'.

--
nosy: +ebarry

___
Python tracker 

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

[issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
priority: normal -> low
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

[issue25865] 7.2 Assignment statements documentation is vague and slightly misleading

[Andrew Barnert]

Andrew Barnert added the comment:

As a side note, why isn't () allowed as an empty target list, like []? Then the 
rules for target lists vs. single targets would be exactly parallel to the 
rules for tuple and list displays. And the error message `can't assign to ()` 
seems a bit weird--you can't really assign to the tuple `a, b, c` or `(a, b, 
c)`, but that's not what you're doing; you're just specifying a target list.

--

___
Python tracker 

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

[issue25864] collections.abc.Mapping should include a __reversed__ that raises TypeError

[Andrew Barnert]

Andrew Barnert added the comment:

> What are we exactly expecting here?

Well, naively, I was expecting a TypeError, just as you get for dict, or a 
subclass of dict, or a custom extension type that implements the C-API mapping 
protocol.

Once you understand how reversed works, you can understand why it gives you a 
nonsensical and useless iterator instead. But nobody would actually _want_ that.

So, as I proposed in the initial description, and the title, what we should be 
doing is raising a TypeError.

> How can a dictionary be reversed?

Assuming this is a pointless rhetorical question: That's exactly the point. 
There's no sensible meaning to reversing a dictionary, so it should raise a 
TypeError. Exactly as it already does for dict, subclasses of dict, and C-API 
mappings.

If this wasn't rhetorical: I guess you could argue that any arbitrary order in 
reverse is any arbitrary order, so even returning iter(m) would be acceptable. 
Or maybe reversed(list(m)) would be even better, if it didn't require O(N) 
space. But in practice, nobody will ever expect that--again, they don't get it 
from dict, subclasses, C-API mappings--so why go out of our way to implement 
it? So, again, it should raise a TypeError.

> This seems to make no difference. I still got the KeyError.

Of course. Again, the current behavior is nonsensical, will almost always raise 
a KeyError at some point, and will never be anything a reasonable person wants. 
So a workaround that restores the current behavior will also be nonsensical, 
almost always raise a KeyError at some point, and never be anything a 
reasonable person wants.

But, if you happen to be unreasonably unreasonable--say, you created a mapping 
with {2:40, 0:10, 1:20} and actually wanted reversed(m) to confusingly give you 
40, 20, 10--and this change did break your code, the workaround would restore 
it.

--

___
Python tracker 

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

[issue25861] Can't use Pickle. AttributeError: 'module' object has no attribute '_new_Index'

[Geoffrey Mégardon]

New submission from Geoffrey Mégardon:

Hello,

I am trying to run a piece of code that I programmed some time ago.
Back then, it was working fine and it was plotting some data.
But today, while I am trying to improve the plots, I ran the code and did not 
work!

Here the message:

D:\Users\Geoffrey\Anaconda\python.exe "D:/Google 
Drive/Work/Experiences/experiment-deviation-initial/analysis/FigureTrajAndDeviation.py"
Traceback (most recent call last):
  File "D:/Google 
Drive/Work/Experiences/experiment-deviation-initial/analysis/FigureTrajAndDeviation.py",
 line 36, in 
m = pickle.load( open(output_path+"/traj_and_RT_second_only.p", "rb" ) )
  File "D:\Users\Geoffrey\Anaconda\lib\pickle.py", line 1378, in load
return Unpickler(file).load()
  File "D:\Users\Geoffrey\Anaconda\lib\pickle.py", line 858, in load
dispatch[key](self)
  File "D:\Users\Geoffrey\Anaconda\lib\pickle.py", line 1090, in load_global
klass = self.find_class(module, name)
  File "D:\Users\Geoffrey\Anaconda\lib\pickle.py", line 1126, in find_class
klass = getattr(mod, name)
AttributeError: 'module' object has no attribute '_new_Index'

Process finished with exit code 1

I hope that you may now what it is about!!
I attached the code file.

--
components: Library (Lib)
files: FigureTrajAndDeviation.py
messages: 256379
nosy: Geoffrey Mégardon
priority: normal
severity: normal
status: open
title: Can't use Pickle. AttributeError: 'module' object has no attribute 
'_new_Index'
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file41305/FigureTrajAndDeviation.py

___
Python tracker 

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

[issue22137] Test imaplib API on all methods specified in RFC 3501

[Maciej Szulik]

Maciej Szulik added the comment:

Per the discussion we've had with David on IRC here's what happening. The last 
patch I've submitted is meant to clean up the tests by:
1. having single _setup method 
2. the _setup method should addClenup to clean the environment
3. have stubs with implemented mostly used methods, all others should be 
implemented ad-hoc in test methods
4. use unittest.main() for running tests

The current idea is to create tests along the current one, to show how the new 
improve the readability. For this work I'm reopening previously submitted issue 
http://bugs.python.org/issue25591 

The current issue will be on dependent on it and no further work should be done 
unless we have the tests cleared.

--
keywords:  -patch

___
Python tracker 

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

[issue25857] csv: unexpected result

[R. David Murray]

R. David Murray added the comment:

There's no place to generate an error message, the csv module parsed the line 
according to the rules.

I'm glad that there's an RFC now.  There wasn't when the module was written 
(which was well before my time on this project...)

--

___
Python tracker 

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

[issue25857] csv: unexpected result

[R. David Murray]

R. David Murray added the comment:

Oh, maybe there is.  We could add an RFC-strict dialect that would raise an 
error, if I'm understanding your quotes from it correctly.  That would be a new 
feature, though.

--

___
Python tracker 

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

[issue25843] lambdas on the same line may incorrectly share code objects

[R. David Murray]

R. David Murray added the comment:

Ah, haypo explained the code to me, and now I understand your comment Serhiy.

So, the replacement happens because of (a) an optimizer general rule and (b) 
the fact that code object *can* be compared.

So it sounds like Armin's suggestion of making an exception for code objects in 
the optimizer is the correct solution.

The issue with code objects that aren't really equal comparing equal would then 
be a separate bug that affects, as Serhiy said, only testing (that we know 
of...who knows what people like PJE might be doing with comparing code objects 
:)

--

___
Python tracker 

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

[issue25843] lambdas on the same line may incorrectly share code objects

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Indeed. My answer actually is an answer to implicit question: could we make 
different code objects be always non-equal? Answer: no, because we use the 
comparison of different code objects to test compiler and marshaller.

May be we can get rid of code objects comparability and provide separate 
function specially for testing. Of course this likely will break tests in 
third-party packages that do low-level hacking on code objects.

--

___
Python tracker 

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

[issue25843] lambdas on the same line may incorrectly share code objects

[STINNER Victor]

STINNER Victor added the comment:

compiler_add_o() uses an heuristic to compare and merge duplicated constants. 
It has special cases for float and complex numbers, but it's not designed to 
handle more types.

Funny, I had the same isue last week why I added support for tuple and 
frozenset "constants" in AST. I had to explicitly support these types in 
compiler_add_o().

I see two options:

(1) share code between compiler_add_o() and code_richcompare() to ensure that 1 
and 1.0 constants are not seen as equal
(2) modify compiler_add_o() to never merge code objects, always considere them 
as unequal

For (2), there is a minor technical issue: you have to generate an unique key 
for the dictionary.

I prefer option (1) for consistency.

--

___
Python tracker 

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

[issue25843] lambdas on the same line may incorrectly share code objects

[STINNER Victor]

STINNER Victor added the comment:

code_richcompare.patch: fix code_richcompare() to not consider that constants 
(1,) and (1.0,) are equal.

The patch lacks an unit test.

We may use the new _PyCode_ConstantKey() function to compare other code 
attributes?

--
keywords: +patch
Added file: http://bugs.python.org/file41307/code_richcompare.patch

___
Python tracker 

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

[issue1753718] base64 "legacy" functions violate RFC 3548

[R. David Murray]

R. David Murray added the comment:

Updated patch.

--
Added file: http://bugs.python.org/file41306/issue-01753718.patch

___
Python tracker 

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

[issue25843] lambdas on the same line may incorrectly share code objects

[STINNER Victor]

STINNER Victor added the comment:

> Would option (1) work if wrap 1 and 1.0 in a tuple? In a list? In a custom 
> collection?

Right now, the Python compiler is quite limited. It only produces constants for 
integers and strings, not complex types. The peephole optimizers is responsible 
to produce tuple and frozenset constants, and the optimizer is more naive. It 
doesn't try to merge constants, nor remove items from co_consts to only keep 
the new container. Example:

>>> def f():
...  return (1,2,3)
... 
>>> f.__code__.co_consts
(None, 1, 2, 3, (1, 2, 3))

1, 2, 3 constants are kept, whereas only (1, 2, 3) constant is used.

Test with my patch:

>>> f1, f2 = lambda x: x in {1,}, lambda x: x in {1.0,}
>>> 
>>> f1.__code__ is f2.__code__
False
>>> f1.__code__.co_consts
(None, 1, frozenset({1}))
>>> f2.__code__.co_consts
(None, 1.0, frozenset({1.0}))

The frozenset are different are expected.

--

___
Python tracker 

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

[issue25857] csv: unexpected result

[Ioan Fintescu]

Ioan Fintescu added the comment:

If you consider that, you should take a look at the RFC; it also contains a
BNF like grammar plus some pointers to another RFC (2234).  It may require
more effort that it is worth, absent some demand for it.

...muss

On Mon, Dec 14, 2015 at 9:34 AM, R. David Murray 
wrote:

>
> R. David Murray added the comment:
>
> Oh, maybe there is.  We could add an RFC-strict dialect that would raise
> an error, if I'm understanding your quotes from it correctly.  That would
> be a new feature, though.
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue25857] csv: unexpected result

[R. David Murray]

R. David Murray added the comment:

Yeah, we'll leave it alone until someone actually submits an enhancment 
request...and the only way it'll get done is if they do it, I suspect :)

--

___
Python tracker 

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

[issue25843] lambdas on the same line may incorrectly share code objects

[STINNER Victor]

STINNER Victor added the comment:

> The frozenset are different are expected.

Oh wait, in this example, it works, but not because of the expected reason. 
frozenset({1}) is equal to frozenset({1.0}) and code_richcompare() doesn't 
create a special key to make them different.

The example only works because the peephole optimizer is lazy and leave 1 and 
1.0 in co_consts which are seen as different by the patched code_richcompare().

--

___
Python tracker 

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

[issue25843] lambdas on the same line may incorrectly share code objects

[STINNER Victor]

STINNER Victor added the comment:

code_eq.py: code to test that frozenset() are inequal. The code hacks 
constants, don't run the code with new constants or it will crash!

--
Added file: http://bugs.python.org/file41309/code_eq.py

___
Python tracker 

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

[issue25861] Can't use Pickle. AttributeError: 'module' object has no attribute '_new_Index'

[R. David Murray]

Changes by R. David Murray :


--
resolution: not a bug -> third party

___
Python tracker 

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

[issue25843] lambdas on the same line may incorrectly share code objects

[R. David Murray]

R. David Murray added the comment:

Serhiy: that can't be entirely true, since we have here a bug where two lambdas 
on the same line are getting the same code object incorrectly, and that is not 
a testing context.

--

___
Python tracker 

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

[issue25591] refactor imaplib tests

[Maciej Szulik]

Maciej Szulik added the comment:

I'm reopening this issue per discussion with David we've had on IRC. The scope 
of this issue to refactor current tests to make them more readable and clean. 
The most important work is:
1. having single _setup method 
2. the _setup method should addClenup to clean the environment
3. have stubs with implemented mostly used methods, all others should be 
implemented ad-hoc in test methods
4. use unittest.main() for running tests

We'll do it along current tests to show the improvement. Once we reach 
satisfactory level we will remove the old tests. This issue is to show this 
progress.

--
assignee:  -> maciej.szulik
keywords:  -patch
resolution: duplicate -> 
status: closed -> open
superseder: Test imaplib API on all methods specified in RFC 3501 -> 
title: improve test coverage for the imaplib -> refactor imaplib tests

___
Python tracker 

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

[issue25843] lambdas on the same line may incorrectly share code objects

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Would option (1) work if wrap 1 and 1.0 in a tuple? In a list? In a custom 
collection?

--

___
Python tracker 

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

[issue25843] lambdas on the same line may incorrectly share code objects

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

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

[issue21258] Add __iter__ support for mock_open

[José Luis Lafuente]

Changes by José Luis Lafuente :


--
nosy: +José.Luis.Lafuente

___
Python tracker 

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

[issue25843] lambdas on the same line may incorrectly share code objects

[STINNER Victor]

STINNER Victor added the comment:

code_richcompare-2.patch: Updated patch to handle also frozenset, the other 
constant type generated by the peephole optimizer.

--
Added file: http://bugs.python.org/file41308/code_richcompare-2.patch

___
Python tracker 

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

[issue1753718] base64 "legacy" functions violate RFC 3548

[Martin Panter]

Martin Panter added the comment:

The change to readline() works well.

Any thoughts regarding my other comments? In particular, altchars and 
ignorechars cannot be arbitrary bytes-like objects.

--

___
Python tracker 

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

[issue25567] shlex.quote doesn't work on bytestrings

[Martin Panter]

Martin Panter added the comment:

I think the documentation needs a “Changed in version 3.6” notice

--
nosy: +martin.panter

___
Python tracker 

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

[issue12484] The Py_InitModule functions no longer exist, but remain in the docs

[Terry J. Reedy]

Terry J. Reedy added the comment:

Sorry, another week for 3.4

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

[issue25853] Compile error with pytime.h - struct timespec declared inside parameter list

[Martin Panter]

Martin Panter added the comment:

What platform, C library, etc do you have? According to Posix, struct timespec 
is normally defined in , but can also be gotten via various other 
include files, many of which are included before "pytime.h".

In particular,  includes "pyport.h", which has conditional code for 
including ,  and . All of these should define 
timespec. It might be useful to check your pyconfig.h file to see if stuff like 
the following is defined:

/* Define to 1 if you can safely include both  and . */
#define TIME_WITH_SYS_TIME 1

--
components: +Build -Library (Lib)
nosy: +martin.panter

___
Python tracker 

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

[issue12484] The Py_InitModule functions no longer exist, but remain in the docs

[Anish Shah]

Anish Shah added the comment:

will try to create a patch for this issue in a day. Thanks!

--
nosy: +Anish.Shah

___
Python tracker 

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

[issue12484] The Py_InitModule functions no longer exist, but remain in the docs

[Anish Shah]

Changes by Anish Shah :


--
keywords: +patch
Added file: 
http://bugs.python.org/file41310/remove_Py_InitModule_from_docs.patch

___
Python tracker 

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

[issue25843] lambdas on the same line may incorrectly share code objects

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

If go this way, I would add explicit support of all types supported in marshal, 
and include id(obj) into the key of all other types.

--

___
Python tracker 

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

[issue12484] The Py_InitModule functions no longer exist, but remain in the docs

[Zachary Ware]

Changes by Zachary Ware :


--
versions: +Python 3.4, Python 3.5, Python 3.6 -Python 3.1, Python 3.2, Python 
3.3

___
Python tracker 

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

[issue12484] The Py_InitModule functions no longer exist, but remain in the docs

[Terry J. Reedy]

Terry J. Reedy added the comment:

3.4 is also on security fix only status.

--
nosy: +terry.reedy
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

[issue12484] The Py_InitModule functions no longer exist, but remain in the docs

[Terry J. Reedy]

Changes by Terry J. Reedy :


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

[issue25567] shlex.quote doesn't work on bytestrings

[Carol Willing]

Changes by Carol Willing :


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

[issue12174] Multiprocessing logging levels unclear

[Camilla Montonen]

Camilla Montonen added the comment:

This issue raises the fact that the 2.X documentation 
lists two logging levels (SUBDEBUG and SUBWARNING) 
without explaining how these two fit into the logging 
hierarchy of the logging levels provided by the standard library logging module
(ie, is SUBDEBUG between INFO and DEBUG). 

The patch (provided by JJeffries and modified by Petri Lehtinen) 
adds an explanatory note stating the hierarchy as follows


These are  :const:`SUBWARNING`,
+which fits between :const:`INFO` and :const:`WARNING` in the normal logging
+hierarchy, and :const:`SUBDEBUG`, which fits below :const:`DEBUG`


Review (this applies to the 2.X version of the documentation)

1. It would be nice to clarify that SUBDEBUG is between DEBUG and NOTSET
instead of saying that it is 'below' as this maybe misunderstood (at least it's 
not very clear to me). 

2. Slightly unrelated to the main issue of this patch

2a) "In addition to having these two logging functions, the multiprocessing 
also"

Should be 

"In addition to having these two logging functions, the multiprocessing module 
also"


3. The documentation for the multiprocessing module in Python 3.X has removed 
any mention
of SUBWARNING and SUBDEBUG, so I'm not sure if this patch is even relevant 
anymore?

4. Also, slightly tangent to this patch, but might be nice to pick up is the 
fact that
documentation for the 2.X version mentions that the logging level table can be 
viewed in 
the logging module documentation

"For a full table of logging levels, see the logging module."

which is not the case anymore. As Vinay Sajip mentions, in 2.X the logging 
level table
has moved to the how-to 
https://docs.python.org/2/howto/logging.html#logging-levels 
and so this link should be updated as well


TODO:
1. Check if SUBWARNING and SUBDEBUG are still part of the public API in 3.X and 
then 
suggest alterations to documentation based on that.

--
nosy: +Winterflower

___
Python tracker 

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

[issue25849] files, opened in unicode (text): write() returns symbols count, but seek() expect offset in bytes

[Марк Коренберг]

Марк Коренберг added the comment:

First, it seems that there are no real "reconstruction algorithm" at all. Seek 
is allowed to point to any byte position, even to place "inside" characters for 
multibyte encodings, such as UTF-8.

Second, about performance:  I talk about implementation mentioned in first 
message. If it is not used (and will not be used), we may forget about that 
sentence.

Next, once again:

I consider it is a bug in allowing to seek to invalid byte offsets for text 
files. Since we cannot easily calculate what offset will be valid (for example, 
seek past the end of file, or places inside character), just disallow seek. In 
real applications, no one will seek/peek to places other than

* beginning of the file
* current byte offset
* seeking to the end of file.

so this seeks/peeks must be allowed.

This is applicable only to variable multibyte encodings (such as UTF-8).

--

___
Python tracker 

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

[issue25849] files, opened in unicode (text): write() returns symbols count, but seek() expect offset in bytes

[Марк Коренберг]

Марк Коренберг added the comment:

s/peek/tell/

--
status: closed -> open

___
Python tracker 

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

[issue25849] files, opened in unicode (text): write() returns symbols count, but seek() expect offset in bytes

[Марк Коренберг]

Марк Коренберг added the comment:

Also, can you provide the case, where such random seeks can be used on text 
files? It would be programmer error to seek to places other I mention. Does not 
it ?

--

___
Python tracker 

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

[issue25849] files, opened in unicode (text): write() returns symbols count, but seek() expect offset in bytes

[R. David Murray]

R. David Murray added the comment:

I think you haven't quite gotten what "opaque token" means in this context.  
The way you use tell/seek with text files is: you have read to some certain 
point in the file.  You call 'tell' and get back an opqaue token.  Later you 
can call seek with that token to get back to the place in the file that you 
"bookmarked".  It will never be between characters, because tell won't return 
such a poitner.  If you decide to call seek with something (other than 0) that 
you didn't get from tell, then you are on your own.

--

___
Python tracker 

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

[issue1753718] base64 "legacy" functions violate RFC 3548

[R. David Murray]

R. David Murray added the comment:

I missed the other comments somehow.  Will take a look soon.

--

___
Python tracker 

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

[issue24505] shutil.which wrong result on Windows

[Toby Tobkin]

Toby Tobkin added the comment:

Hopefully this isn't too much of an amateur question, but I ran into a 
semantics issue: should which be imitating the semantics of the Windows shell 
or of CreateProcess[3]? The current implementation of shutil.which implies 
Windows shell, but Python uses CreateProcess in subprocess for executing 
commands, not cmd.exe.

In order to correctly emulate the behavior of the Windows command search 
sequence[1] (e.g. for cmd.exe or Powershell), one needs to check whether or not 
a given command matches one of the internal Windows shell commands. For 
instance, if we have an executable at C:\xyz\chdir.exe, the following outputs 
should be observed from which if our current directory is C:\xyz:

>>> which('chdir')
(none)

>>> which('.\\chdir')
'C:\\xyz\\chdir.exe'

On the other hand, CreateProcess[3] would work this way:

CreateProcess(NULL, "chdir", ...) --> executes C:\xyz\chdir.exe
CreateProcess(NULL, "chdir.exe", ...) --> executes C:\xyz\chdir.exe

There are other semantic differences as well. For example, CreateProcess will 
not do path extension of e.g. "abc" to "abc.bat", but Powershell and cmd will.

Which semantics do I follow? Powershell/cmd or CreateProcess?

[1] Subsection "Command Search Sequence" of 
https://technet.microsoft.com/en-us/library/cc723564.aspx#XSLTsection127121120120
[2] Subsection "Internal and External Commands" of 
https://technet.microsoft.com/en-us/library/cc723564.aspx#XSLTsection127121120120
[3] 
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx

--

___
Python tracker 

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

[issue25859] EOFError in test_nntplib.NetworkedNNTPTests.test_starttls()

[Martin Panter]

New submission from Martin Panter:

The AMD64 Debian root buildbot and the x86 Gentoo Installed with X buildbot 
have been persistently failing test_nntplib for a while, and I can also 
reproduce it locally when “test -unetwork” is enabled. Six test cases fail. 
There is a pause before test_starttls() fails, then all the others fail 
immediately:

test_newgroups (test.test_nntplib.NetworkedNNTPTests) ... ok
test_over (test.test_nntplib.NetworkedNNTPTests) ... ok
test_starttls (test.test_nntplib.NetworkedNNTPTests) ... ERROR
test_unknown_command (test.test_nntplib.NetworkedNNTPTests) ... ERROR
test_welcome (test.test_nntplib.NetworkedNNTPTests) ... ok
test_with_statement (test.test_nntplib.NetworkedNNTPTests) ... ok
test_xhdr (test.test_nntplib.NetworkedNNTPTests) ... ERROR
test_xover (test.test_nntplib.NetworkedNNTPTests) ... ERROR
test_zlogin (test.test_nntplib.NetworkedNNTPTests) ... ERROR
test_zzquit (test.test_nntplib.NetworkedNNTPTests) ... ERROR
test_article_head_body (test.test_nntplib.NetworkedNNTP_SSLTests) ... ok
test_capabilities (test.test_nntplib.NetworkedNNTP_SSLTests) ... ok

Traceback from first failure:

==
ERROR: test_starttls (test.test_nntplib.NetworkedNNTPTests)
--
Traceback (most recent call last):
  File "/media/disk/home/proj/python/cpython/Lib/test/test_nntplib.py", line 
252, in wrapped
meth(self)
  File "/media/disk/home/proj/python/cpython/Lib/test/test_nntplib.py", line 
210, in test_starttls
self.server.starttls()
  File "/media/disk/home/proj/python/cpython/Lib/nntplib.py", line 1014, in 
starttls
self.getcapabilities()
  File "/media/disk/home/proj/python/cpython/Lib/nntplib.py", line 390, in 
getcapabilities
resp, caps = self.capabilities()
  File "/media/disk/home/proj/python/cpython/Lib/nntplib.py", line 558, in 
capabilities
resp, lines = self._longcmdstring("CAPABILITIES")
  File "/media/disk/home/proj/python/cpython/Lib/nntplib.py", line 525, in 
_longcmdstring
resp, list = self._getlongresp(file)
  File "/media/disk/home/proj/python/cpython/Lib/nntplib.py", line 476, in 
_getlongresp
resp = self._getresp()
  File "/media/disk/home/proj/python/cpython/Lib/nntplib.py", line 449, in 
_getresp
resp = self._getline()
  File "/media/disk/home/proj/python/cpython/Lib/nntplib.py", line 437, in 
_getline
if not line: raise EOFError
EOFError

It seems like as soon as the TLS connection is successfully set up, the server 
(news.trigofacile.com) shuts down the connection.

Would it be appropriate to change this test so that instead of connecting to a 
remote server, we connect to a local server running in a background thread? I 
attach a Python script that runs a minimal server with hardcoded responses 
allowing test_starttls() to pass. Perhaps we could use this for 
test_starttls(). Maybe even extend it to other remote server tests as well.

--
components: Tests
files: starttls_server.py
keywords: buildbot
messages: 256374
nosy: martin.panter
priority: normal
severity: normal
status: open
title: EOFError in test_nntplib.NetworkedNNTPTests.test_starttls()
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file41303/starttls_server.py

___
Python tracker 

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

[issue25766] __bytes__ doesn't work for str subclasses

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Other conversion special methods work in str subclass.

>>> class I(str):
... def __int__(self):
... return 42
... 
>>> int(I('35'))
42
>>> int(I('35'), 8)
29

--
nosy: +mark.dickinson, skrah

___
Python tracker 

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

[issue25847] CPython not using Visual Studio code analysis!

[Alexander Riccio]

Alexander Riccio added the comment:

> OK, let's move this to patch needed, then, and see if anyone is ambitious 
> enough to do the work needed to make it useful to us :)


I can try and hack it in, just as proof of concept. I think I should just be 
able to add something like:

/p:EnablePREfast=%EnablePREfast%^

...along with something like:

if "%~1"=="--enable-code-analysis" (set EnablePREfast=true) & shift & goto 
CheckOpts




God I hate batch scripting.

--

___
Python tracker 

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

[issue25847] CPython not using Visual Studio code analysis!

[R. David Murray]

R. David Murray added the comment:

It seems to me that adding the CLI flag is the least of the work.  You then 
have to make it compile cleanly :)  (That's why I said 'ambitious enough').  
That is, (as I undersatnd it) we've done a lot of work to not have compiler 
warnings generated during compilation, and we don't want to backtrack on that.  
Over time we've cleaned up the code so that we could make stricter compile 
flags the default, so this would be in that tradition.

--

___
Python tracker 

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

[issue25847] CPython not using Visual Studio code analysis!

[Alexander Riccio]

Alexander Riccio added the comment:

Yup, the very naive version works.

--
keywords: +patch
Added file: http://bugs.python.org/file41311/EnableCodeAnalysis.patch

___
Python tracker 

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

[issue25847] CPython not using Visual Studio code analysis!

[Mark Lawrence]

Mark Lawrence added the comment:

There are all ready numerous compiler warnings in the Windows builds, see 
#9566, #18295 and #18407.

--
components: +Windows
nosy: +BreamoreBoy

___
Python tracker 

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