[issue28581] Allow running code without explicitly saving the file.

[Terry J. Reedy]

Terry J. Reedy added the comment:

In my additional comment, I explored the idea of running without saving, not 
even to a temp file.

--

___
Python tracker 

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

[issue19042] Idle: add option to autosave 'Untitled' edit window

[Terry J. Reedy]

Terry J. Reedy added the comment:

Duplicate #28581 has a autosave patch in the initial post, which points out 
that "We are often required to copy code from various sites say some tutorial 
or code samples which are good for one time usage."

It prompted me to think more about the idea to 'add a mechanism to truly run 
without saving [to disk]', which I mentioned in my first post above.  To run 
editor code, IDLE retrieves the code from the Text widget as a single strings; 
runs compile(code, 'filename', 'exec'), ships the code object to the user 
process, and runs exec(code, fakemain).  (I understand this much better now 
than 3 years ago.)  The only use of the disk copy is for tracebacks.  But is it 
*needed*?  I believe not.  Here is standard interactive Python (3.5.2):

>>> def f():
1/0

>>> f()
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 2, in f
ZeroDivisionError: division by zero
>>>

Here is the same traceback in IDLE's Shell:

Traceback (most recent call last):
  File "", line 1, in 
f()
  File "", line 2, in f
1/0
ZeroDivisionError: division by zero

IDLE has filled in the missing lines from Shell's text.  I have not yet tracked 
where this is done (in pyshell.py, I believe), but I presume it could do the 
same for Untitled editor windows.  For this to work, the window titles should 
be Untitled-0, Untitled-1, ... .  The specific name used in the compile call 
would appear in the traceback, to be used to lookup the window the code came 
from.

With the ability to run the whole buffer without saving, it would be easy to 
run a selection.  (There have been multiple requests for this.)

IDLE already asks about saving when one tried to close a window with unsaved 
text, so there is no need to force saving when running for this purpose.

--
versions: +Python 3.6, Python 3.7 -Python 2.7, Python 3.3, Python 3.4

___
Python tracker 

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

[issue28581] Allow running code without explicitly saving the file.

[perilbrain]

perilbrain added the comment:

Thanks Terry, I tried searching for a similar issue but failed.

Feels like signing contributor form will take a while.
Meantime please feel free to tweak/improve and implement code in your way (Mine 
is a bit rough solution not even abiding by naming convention), if this is some 
licensing issue.

--

___
Python tracker 

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

[issue28581] Allow running code without explicitly saving the file.

[Terry J. Reedy]

Terry J. Reedy added the comment:

I agree that this is a problem that needs a solution. Your post gives the 
justification very well.  I already opened #19042 for this issue, so as is our 
usual policy, I am merging this duplicate into that one. 

Thank you for submitting a patch.  To apply it, we need a Contributor 
Agreement.  One can be signed electronically.  See 
https://www.python.org/psf/contrib/.  An '*' will appear after your name once a 
CA has been received and registered.  I will take a good look once this happens.

I the meanwhile, I will add a reference to this issue and patch, as well as 
additional comments, to #19042.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Idle: add option to autosave 'Untitled' edit window
versions: +Python 3.6, Python 3.7 -Python 3.4

___
Python tracker 

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

[issue27779] Sync-up docstrings in C version of the the decimal module

[Lisa Roach]

Lisa Roach added the comment:

Thanks for taking a look Stefan! I agree, it is definitely not as easy as it 
sounds.

Your review and comments are helpful, I will make adjustments to the 
docstrings. 

If you want, I can continue to try to sync-up the docstrings and submit them 
for you and Raymond to review? I've been checking the docstrings against the 
general decimal specification: http://speleotrove.com/decimal/decarith.html, 
and with additional eyes on readability and best practices hopefully we can 
write updated, synchronized docstrings.

--

___
Python tracker 

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

[issue28584] ICC compiler check is too permissive

[Zachary Ware]

Changes by Zachary Ware :


--
nosy: +zach.ware
stage:  -> patch review
versions:  -Python 3.3, Python 3.4

___
Python tracker 

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

[issue28582] Invalid backslash syntax errors are not always accurate as to the location on the line where the error occurs

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

This is known issue. See issue25677.

--
nosy: +serhiy.storchaka
resolution:  -> duplicate
superseder:  -> Syntax error caret confused by indentation

___
Python tracker 

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

[issue25677] Syntax error caret confused by indentation

[Chi Hsuan Yen]

Changes by Chi Hsuan Yen :


--
nosy: +Chi Hsuan Yen

___
Python tracker 

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

[issue28584] ICC compiler check is too permissive

[Carmelo Piccione]

Changes by Carmelo Piccione :


--
versions: +Python 2.7, Python 3.3, Python 3.4

___
Python tracker 

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

[issue28584] ICC compiler check is too permissive

[Carmelo Piccione]

New submission from Carmelo Piccione:

if the ${CC} variable has an encoded path which contains "icc" anywhere in the 
string, it will be interpreted by the configure script as an icc compiler 
rather than gcc. This is due to matching on *icc* in various places.

Example: "/home/cpiccion/.linuxbrew/bin/gcc" will match because of the 
"cpiccion".

This is also true for the other patterns, including "gcc".

Proposed fix is to take the basename of the ${CC} variable first.

--
components: Installation
files: icc-pattern-check-fix.patch
keywords: patch
messages: 279893
nosy: struktured
priority: normal
severity: normal
status: open
title: ICC compiler check is too permissive
type: compile error
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45307/icc-pattern-check-fix.patch

___
Python tracker 

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

[issue28499] Logging module documentation needs a rework.

[Vinay Sajip]

Vinay Sajip added the comment:

I'm not sure this issue tracker is the best place to have an extended 
discussion about documentation - perhaps we should move this to a mailing list 
such as python-list.

I'm not sure what you read first, but the logging documentation main page has a 
box marked "Important" right at the top, which says: "This page contains the 
API reference information. For tutorial information and discussion of more 
advanced topics, see ..." and then links to the basic and advanced tutorials 
and cookbook.

The basic tutorial starts with information on when to use logging (including 
links to the convenient-for-beginners logging.XXX() functions), discusses the 
different logging levels, and then gives a simple example:

import logging
logging.warning('Watch out!')  # will print a message to the console
logging.info('I told you so')  # will not print anything

So I don't see where your statement "No example of quick usage (the first one 
is for `Logger.debug`, and that's not a generic one)" comes from, nor "The 
top-level function are documented at the end of the document, albeit they are 
the quickest way to use and understand `logging`". Although they are *listed* 
low down, there are *links* to them very early in the basic tutorial - in the 
very first paragraph of "When to use logging".

With reference to your rough proposed structure,

"Introduction to logging (with short example)" - the beginning of the basic 
tutorial does this.

"Configuration (a separated chapter to describe file format, dict schema, and 
stuff)" - outline is described in the advanced tutorial, details are found in 
the specific page on the API reference for the logging.config module.

"Module references (logging, logging.config, logging.handler, etc.)" - this is 
as it is now.

"Cookbook & Tutorials" - these are separated from the reference documentation 
but otherwise seem to broadly follow what you're referring to here.

Bear in mind that opinions on (and reactions to) documentation are fairly 
subjective. For example, you seem to find the Django documentation problematic, 
but I don't, and it's widely regarded as one of the best documentation sets for 
any Python project, and has contributed a lot to Django's success.

If you really want to take this on, I don't think a patch is the best way to 
proceed, because there will be a *lot* of changes due to things moving around, 
etc. and one would need to build the documentation from the changed sources to 
get the full effect of the changes, unlike when reviewing source code. Instead, 
you could create a project on ReadTheDocs which takes copies of the logging 
documentation source pages and changes them to provide your alternative vision 
of how the documentation should look. This will allow easier side-by-side 
comparison for anyone who wants to review and compare the alternatives. If it's 
generally felt (e.g. by people on python-dev) that the new version is better 
than the current, then bringing the changes back shouldn't be too hard. What do 
you think?

--

___
Python tracker 

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

[issue28578] '\n' escape character print before the Py_GetCompiler version

[Amit Ghadge]

Amit Ghadge added the comment:

SilentGhost, Thanks for your response.

--

___
Python tracker 

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

[issue28199] Compact dict resizing is doing too much work

[Xiang Zhang]

Xiang Zhang added the comment:

Open #28583 and #28580 to tackle this.

--
dependencies: +Optimize _PyDict_Next for split table, PyDict_SetDefault doesn't 
combine split table when needed

___
Python tracker 

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

[issue28583] PyDict_SetDefault doesn't combine split table when needed

[Xiang Zhang]

New submission from Xiang Zhang:

PyDict_SetDefault doesn't combine split table when needed. This could lead to 
loss of order or crash. This is a follow up of #28199.

--
components: Interpreter Core
messages: 279889
nosy: inada.naoki, serhiy.storchaka, xiang.zhang
priority: normal
severity: normal
status: open
title: PyDict_SetDefault doesn't combine split table when needed
type: behavior
versions: Python 3.6, Python 3.7

___
Python tracker 

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

[issue28582] Invalid backslash syntax errors are not always accurate as to the location on the line where the error occurs

[Eric V. Smith]

New submission from Eric V. Smith:

See msg279799 from issue28128, repeated here:


Seems the ^ pointer is not always correct. For example, in the function scope 
it's correct:

$ cat test.py 
def foo():
s = 'C:\Program Files\Microsoft'

$ python3.7 -W error test.py
  File "test.py", line 2
s = 'C:\Program Files\Microsoft'
   ^
SyntaxError: invalid escape sequence \P

On the other hand, top-level literals confuses the pointer:

$ cat test.py   
s = 'C:\Program Files\Microsoft'

$ python3.7 -W error test.py
  File "test.py", line 1
s = 'C:\Program Files\Microsoft'
   ^
SyntaxError: invalid escape sequence \P

Is that expected?

--
components: Interpreter Core
messages: 279888
nosy: Chi Hsuan Yen, eric.smith
priority: normal
severity: normal
status: open
title: Invalid backslash syntax errors are not always accurate as to the 
location on the line where the error occurs
type: behavior
versions: Python 3.6, Python 3.7

___
Python tracker 

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

[issue26163] FAIL: test_hash_effectiveness (test.test_set.TestFrozenSet)

[Eric Appelt]

Eric Appelt added the comment:

Here are my test results - I'll re-describe the issue and test so people don't 
have to read through all the previous text and for completeness.

-

The basic test case ("letter test"):

Consider the set of the first seven letters - {'a', 'b', 'c', 'd', 'e', 'f', 
'g'}. If one constructs frozensets of all 128 possible subsets of this set, and 
computes their hashes, in principle they should have good collision statistics.

To check, the hashes of all 128 frozensets are computed and the last 7 bits of 
each hash are compared. The quality of the hashing algorithm is indicated by 
how many unique values of the last 7 bits are present in the set of 128 hashes. 
Too few unique values and the collision statistics are poor.

In the python testing suite, this particular test is run and if the number of 
unique values is 32 or less the test fails. Since the hash of a string depends 
on the value of the PYTHONHASHSEED which is random by default, and the hashes 
of frozensets are dependent on their entries, this test is not deterministic. 
My earlier tests show that this will fail for one out of every few thousand 
seeds.

--

The implementation issue and proposed fix:

The hash of a frozen set is computed by taking the hash of each element, 
shuffling the bits in a deterministic way, and then XORing it into a hash for 
the frozenset (starting with zero). The size of the frozenset is then also 
shuffled and XORed into that result.

Finally, in order to try to remove patterns incurred by XORing similar 
combinations of elements as with nested sets, the resulting hash is sent 
through a simple LCG to arrive at a final value:

hash = hash * 69069U + 907133923UL;

The hypothesis is that this LCG is not effective in improving collision rates 
for this particular test case. As an alternative, the proposal is to take the 
result of the XORs, and run that through the hashing algorithm set in the 
compiled python executable for hashing bytes (i.e. FNV or SipHash24). This 
rehashing may do a better job of removing patterns set up by combinations of 
common elements.

-

The experiment:

To more robustly check the properties of the frozenset hashing algorithm, the 
letter test is run many times setting different PYTHONHASHSEED values from 0 to 
1. This produces a distribution of unique sequences (u) of the last 7 hash 
bits in the set of 128 frozensets. 

To compare against the optimal case, the same distribution (u) is produced from 
a set of pseudorandom integers generated with "random.randint(0, 2**64)". Which 
is found to have be a normal distribution with a mean of ~81 and standard 
deviation of ~3.5.

Six different test cases are considered and the results are shown in the 
attached figure (figure1.png)

- Compile using the FNV algorithm. For control, do not shuffle the XORed result 
to compute the frozenset hash. (Fig 1-a)
- Compile using the FNV algorithm. For the current implementation, shuffle the 
XORed result using the LCG to compute the frozenset hash. (Fig 1-b)
- Compile using the FNV algorithm. For the current implementation, shuffle the 
XORed result using the FNV algorithm to compute the frozenset hash. (Fig 1-c)
- Compile using the SipHash24 algorithm. For control, do not shuffle the XORed 
result to compute the frozenset hash. (Fig 1-d)
- Compile using the SipHash24 algorithm. For the current implementation, 
shuffle the XORed result using the LCG to compute the frozenset hash. (Fig 1-e)
- Compile using the SipHash24 algorithm. For the current implementation, 
shuffle the XORed result using the SipHash24 algorithm to compute the frozenset 
hash. (Fig 1-f)



Results:

Using the LCG to shuffle the XORed result of the entry and size hashes to 
finish computing the frozenset hash did not improve the results of the letter 
test, and appeared to have no effect on the distribution at all.

Rehashing with the configured algorithm to shuffle the XORed result of the 
entry and size hashes to finish computing the frozenset hash did not improve 
the results of the letter test, and appeared to have no effect on the 
distribution at all.

The FNV results were odd in that specific outlying values of u were often 
repeated for different seeds, such as 45 and 104. There was no apparent 
periodic behavior in these repeated outlying results.

--
Added file: http://bugs.python.org/file45306/fig1.png

___
Python tracker 

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

[issue26163] FAIL: test_hash_effectiveness (test.test_set.TestFrozenSet)

[Eric Appelt]

Eric Appelt added the comment:

I made a copy/paste error on the second to last paragraph of the previous 
comment, it should be:

Rehashing with the configured algorithm to shuffle the XORed result of the 
entry and size hashes to finish computing the frozenset hash resulted in an 
ideal distribution matching that of the pseudorandom numbers.

--

___
Python tracker 

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

[issue28581] Allow running code without explicitly saving the file.

[perilbrain]

New submission from perilbrain:

Current Flow:-
- If you create a new file in idle and try to run it, the editor asks to save 
the file. However if user presses cancel button the code is not executed.

Problem:-
I have been using idle for over 5 years and this behavior is quite 
annoying(along with paste :) !!). We are often required to copy code from 
various sites say some tutorial or code samples which are good for one time 
usage.

Solution:-
If a user presses cancel button then set a flag in IOBinding say "optedTemp", 
save it to a named temporary file, execute the code and close the file. If user 
again runs the code, check for this flag. If it is true then there is no need 
to ask for saving the code and again create the temporary file, execute, close. 
If some one needs to save this code they can use the "save as" menu which sets 
off the optedTemp flag.

Here is the code I propose (check for "#+")

==idlelib/ScriptBinding.py===
# At top
import tempfile  #+

# New definition of functions:-


def _run_module_event(self, event):
filename = self.getfilename()
tempCode = None #+
if not filename:
tempCode = tempfile.NamedTemporaryFile(suffix = ".py") 
#+
filename = tempCode.name #Added***
self.editwin.io.writefile( filename ) #+
self.editwin.io.optedTemp = True #+
#return 'break'
code = self.checksyntax(filename)
..
interp.runcode(code)
if tempCode is not None: #+
tempCode.close() #+
return 'break'

def getfilename(self):
filename = self.editwin.io.filename
if not self.editwin.get_saved():
autosave = idleConf.GetOption('main', 'General',
  'autosave', type='bool')
if autosave and filename:
self.editwin.io.save(None)
elif self.editwin.io.optedTemp: #+
filename = None #+
else:
confirm = self.ask_save_dialog()
self.editwin.text.focus_set()
if confirm:
self.editwin.io.save(None)
filename = self.editwin.io.filename
else:
filename = None
return filename

idlelib/IOBinding.py==

def __init__(self, editwin):
#
self.__id_print = self.text.bind("<>", self.print_window)
self.optedTemp = False #+

def save_as(self, event):
filename = self.asksavefile()
if filename:
if self.writefile(filename):
self.set_filename(filename)
self.set_saved(1)
self.optedTemp = False #+
try:
self.editwin.store_file_breaks()
except AttributeError:


--
assignee: terry.reedy
components: IDLE
messages: 279885
nosy: perilbrain, terry.reedy
priority: normal
severity: normal
status: open
title: Allow running code without explicitly saving the file.
type: enhancement
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

[issue28580] Optimize _PyDict_Next for split table

[Xiang Zhang]

Changes by Xiang Zhang :


--
components: +Interpreter Core
title: Optimise _PyDict_Next for split table -> Optimize _PyDict_Next for split 
table
versions: +Python 3.6, Python 3.7

___
Python tracker 

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

[issue28580] Optimise _PyDict_Next for split table

[Xiang Zhang]

New submission from Xiang Zhang:

Since values of split table is always dense, we can optimise the current 
implementation of _PyDict_Next. I think this could hardly bring much 
performance enhancement. More importantly, this emphasizes the invariant and 
make bugs easy to find and test.

--
files: _PyDict_Next.patch
keywords: patch
messages: 279884
nosy: inada.naoki, serhiy.storchaka, xiang.zhang
priority: normal
severity: normal
stage: patch review
status: open
title: Optimise _PyDict_Next for split table
type: behavior
Added file: http://bugs.python.org/file45305/_PyDict_Next.patch

___
Python tracker 

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

[issue28499] Logging module documentation needs a rework.

[Florian Strzelecki]

Florian Strzelecki added the comment:

Hi! Sorry for the delay.

I published my slides on speaker deck: 
https://speakerdeck.com/exirel/read-and-write-the-doc
It contains only my main ideas and key concepts, since I prefer to talk more 
than just read slides to the public. I hope Pycon FR's organizers will be able 
to upload videos soon - it'll need translation for non-French speaker, too.

Thanks for creating this issue and for all your comments. I'll try to talk more 
here, but I'm not sure how we should proceed - so let's start a conversation?

In my talk, I rant a bit about two documentations: Django's documentation, and 
Python Logging's documentation. Both have, in my opinion, an issue with their 
organization: the Django one tend to scatter information around multiple 
chapters, and the Logging one, albeit properly compacted, fail to quickly 
answer beginner's questions and advanced user's needs.

Don't get me wrong: there is a lot of content here. Most of the question one 
may ask have an answer, lying here or there. After all, I was able to use the 
Configure File Format, once I had read the reference documentation for 
`logging`, `logging.config`, both tutorials, and the cookbook. My point is: I 
value a lot this documentation, but my experience as a beginner wasn't that 
good, and my current experience as an advanced user could be improved.

I remember the first time I read the documentation. I was reading an 
application's source code that used a `logging.config.dictConfig`, and I 
couldn't understand how it worked. How does each level in loggers and handlers 
work? How to change the format of each log? Does it work in multiple threads? 
In multiple process? Why is there a `logging.getLogger('something')`? How does 
it know my configuration? How can I output logs in my console and still write 
them? Can I call `getLogger` before I configure anything?

Take the main page (https://docs.python.org/3.7/library/logging.html):

* Hard to find a "How to configure logging" link,
* No description of the logging flow (it can be found in the advanced tutorial),
* No example of quick usage (the first one is for `Logger.debug`, and that's 
not a generic one),
* The top-level function are documented at the end of the document, albeit they 
are the quickest way to use and understand `logging`
* The "See also" part (which provide easy access to more content) is far far 
away at the bottom of the document.

And I think there are many other small issues regarding content organization.

I think there are (at least) 2 ways to look at these:

* Rework the overall structure,
* Focus on example.

I didn't think a lot about a better structure, so something like that is just a 
quick draft:

* Introduction to logging (with short example)
* Logging usage (how logging works - the Advanced Tutorial talk a lot about 
that)
* Configuration (a separated chapter to describe file format, dict schema, and 
stuff)
* Module references (logging, logging.config, logging.handler, etc.)
* Cookbook & Tutorials

(Each part in a separated chapter/sub-chapter)

I also think that the documentation should be able to answer these questions:

* As a beginner, how do I start? How should I learn logging?
* As experienced, how do I jump directly to what I want to know? (config, 
format, etc.)
* As advanced, how do I extend logging in my application?

I don't think a beginner needs to know what a LogRecord is, but they'll need to 
know what keys to use in their formatter in their basicConfig/dictConfig. And 
an advanced dev shouldn't spend minutes to fetch the documentation to finally 
found how to use their own LogRecord object in their logger.

---

Welp. That's a lot of text for now. I'm still not sure how to help nor how to 
begin with that. I never tried to make a push request to Python, and I don't 
know if I should try to submit a diff or not. Also, there is so much more than 
just that (I didn't talk about the "focus on example" part).

Last but not least, thanks for your attention!

--
nosy: +Florian Strzelecki

___
Python tracker 

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

[issue28199] Compact dict resizing is doing too much work

[Xiang Zhang]

Xiang Zhang added the comment:

I use gdb to run setuptools test suite and find the assumption, split tables 
are always dense is broken for both dictresize3 and dictresize4.

#0  0x771171c7 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:55
#1  0x77118e2a in __GI_abort () at abort.c:89
#2  0x771100bd in __assert_fail_base (fmt=0x77271f78 "%s%s%s:%u: 
%s%sAssertion `%s' failed.\n%n", 
assertion=assertion@entry=0x5e4b90 "oldvalues[i] != ((void *)0)", 
file=file@entry=0x5e4aa0 "Objects/dictobject.c", line=line@entry=1270, 
function=function@entry=0x5e59f0 <__PRETTY_FUNCTION__.12083> "dictresize") 
at assert.c:92
#3  0x77110172 in __GI___assert_fail 
(assertion=assertion@entry=0x5e4b90 "oldvalues[i] != ((void *)0)", 
file=file@entry=0x5e4aa0 "Objects/dictobject.c", line=line@entry=1270, 
function=function@entry=0x5e59f0 <__PRETTY_FUNCTION__.12083> "dictresize")
at assert.c:101
#4  0x0048bddc in dictresize (mp=mp@entry=0x7219d2b0, 
minused=) at Objects/dictobject.c:1270
#5  0x0048bf93 in insertion_resize (mp=mp@entry=0x7219d2b0) at 
Objects/dictobject.c:1100
#6  0x0048c5fd in insertdict (mp=mp@entry=0x7219d2b0, 
key=key@entry=0x7579c3c0, hash=-3681610201421769281, 
value=value@entry=0x707f56e8) at Objects/dictobject.c:1136
#7  0x0048fdfd in PyDict_SetItem (op=op@entry=0x7219d2b0, 
key=key@entry=0x7579c3c0, value=value@entry=0x707f56e8)
at Objects/dictobject.c:1572
#8  0x00492cb5 in _PyObjectDict_SetItem (tp=tp@entry=0xd52548, 
dictptr=0x7080cbd8, key=key@entry=0x7579c3c0, 
value=value@entry=0x707f56e8) at Objects/dictobject.c:4274
#9  0x0049df8a in _PyObject_GenericSetAttrWithDict (obj=0x7080cbb8, 
name=0x7579c3c0, value=0x707f56e8, dict=dict@entry=0x0)
at Objects/object.c:1172
#10 0x0049e0cf in PyObject_GenericSetAttr (obj=, 
name=, value=) at Objects/object.c:1194
#11 0x0049d80e in PyObject_SetAttr (v=v@entry=0x7080cbb8, 
name=name@entry=0x7579c3c0, value=value@entry=0x707f56e8)
at Objects/object.c:932

Thanks to Victor's _PyDict_CheckConsistency, it's easy then to find even 
without dictresize3 and dictresize4 (the current version), the test suite still 
fails (#define DEBUG_PYDICT).

#0  0x771171c7 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:55
#1  0x77118e2a in __GI_abort () at abort.c:89
#2  0x771100bd in __assert_fail_base (fmt=0x77271f78 "%s%s%s:%u: 
%s%sAssertion `%s' failed.\n%n", 
assertion=assertion@entry=0x5e53a0 "mp->ma_values[i] != ((void *)0)", 
file=file@entry=0x5e4d00 "Objects/dictobject.c", line=line@entry=498, 
function=function@entry=0x5e5dd0 <__PRETTY_FUNCTION__.11869> 
"_PyDict_CheckConsistency") at assert.c:92
#3  0x77110172 in __GI___assert_fail 
(assertion=assertion@entry=0x5e53a0 "mp->ma_values[i] != ((void *)0)", 
file=file@entry=0x5e4d00 "Objects/dictobject.c", line=line@entry=498, 
function=function@entry=0x5e5dd0 <__PRETTY_FUNCTION__.11869> 
"_PyDict_CheckConsistency") at assert.c:101
#4  0x0048ba17 in _PyDict_CheckConsistency (mp=mp@entry=0x70806e68) 
at Objects/dictobject.c:498
#5  0x004927a3 in PyDict_SetDefault (d=d@entry=0x70806e68, 
key=0x72ffcdd8, defaultobj=0x8abf20 <_Py_NoneStruct>)
at Objects/dictobject.c:2807
#6  0x00492854 in dict_setdefault (mp=0x70806e68, args=) at Objects/dictobject.c:2824
#7  0x00499469 in _PyCFunction_FastCallDict 
(func_obj=func_obj@entry=0x70f2f8c8, args=args@entry=0x105afe8, 
nargs=nargs@entry=2, 
kwargs=kwargs@entry=0x0) at Objects/methodobject.c:234
#8  0x00499815 in _PyCFunction_FastCallKeywords 
(func=func@entry=0x70f2f8c8, stack=stack@entry=0x105afe8, 
nargs=nargs@entry=2, 
kwnames=kwnames@entry=0x0) at Objects/methodobject.c:295
#9  0x00537b6f in call_function 
(pp_stack=pp_stack@entry=0x7fff5cd0, oparg=oparg@entry=2, 
kwnames=kwnames@entry=0x0)
at Python/ceval.c:4793

>From the backtrace we can see PyDict_SetDefault breaks the invariant. And 
>reading the code, yes, it doesn't handle split table separately.

I simply replace the logic in PyDict_SetDefault with insertdict to make a test. 
It doesn't fail, even with dictresize4.

An easy example to reproduce:

>>> class C:
... pass
... 
>>> c1, c2 = C(), C()
>>> c1.a, c1.b = 1, 2
>>> c2.__dict__.setdefault('b', None)
python: Objects/dictobject.c:498: _PyDict_CheckConsistency: Assertion 
`mp->ma_values[i] != ((void *)0)' failed.
Aborted (core dumped)

--

___
Python tracker 

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

[issue28576] Uninstalling Py352 x86 with /uninstall option does not remove prepended paths

[jcrmatos]

jcrmatos added the comment:

Hello,

The GUI uninstall removes the prepended paths w/o requiring a reboot, so I see 
no reason why the /uninstall method shouldn't do it too.

I did try to reboot afterwards, but the paths remain.

I also tested on another PC, with Windows 8.1 x64, with the same results.

What is strange is that the /uninstall method removes the .PY and .PYW from the 
PATHEXT env var, but keeps the prepended paths.
I attached the logs as requested.

All tries were made using using

python-3.5.2.exe InstallAllUsers=1 CompileAll=1 InstallLauncherAllUsers=0 
PrependPath=1 /passive

for installation and

python-3.5.2.exe /uninstall

for uninstallation.

Best regards,

JM

--
Added file: http://bugs.python.org/file45304/Temp.zip

___
Python tracker 

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

[issue28579] nan != nan

[Tim Peters]

Tim Peters added the comment:

Yes, it's both intended and annoying ;-)  The standard specifies that, by 
default, comparisons involving NANs are "unordered":  a NAN is _none_ of "less 
than", "equal to", or "greater than" any other float, including any other NaN, 
and including itself.

--
nosy: +tim.peters

___
Python tracker 

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

[issue28579] nan != nan

[SilentGhost]

SilentGhost added the comment:

That's how IEEE 754's NaN is defined. Seem to be behaving according to the 
standard.

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

[issue28579] nan != nan

[Liam Marsh]

New submission from Liam Marsh:

I found a really weird comportment with NANs:

>>> from math import nan, isnan, inf
>>> nan==nan
False
>>> nan!=nan
True
>>> a=nan  # maybe get another instance would fix it (or so I thought)
>>> a==nan
False
>>> a==a
False
>>> a is a  
True
>>> # because `is` works, it could be a
>>> # deliberate comportment. is it?
>>> a is nan
True
>>> isnan(a) and isnan(nan)
True
>>> nan == -nan
False
>>> nan is -nan
False
>>> a < 1
False
>>> a > 0
False
>>> a < inf
False
>>> b=external_pyd_call_that_returns_nan()
>>> isnan(b)
True
>>> b == nan
False

that sums what I tried up.

thanks for reading this.

--
messages: 279878
nosy: niacdoial
priority: normal
severity: normal
status: open
title: nan != nan
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

[issue28576] Uninstalling Py352 x86 with /uninstall option does not remove prepended paths

[Steve Dower]

Changes by Steve Dower :


--
assignee:  -> steve.dower

___
Python tracker 

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

[issue28576] Uninstalling Py352 x86 with /uninstall option does not remove prepended paths

[Steve Dower]

Steve Dower added the comment:

Does it go away after restarting? It's not easy to remove a setting like that 
from programs that are already running.

Also, can you post your log files? They'll be in %TEMP% and you can zip them up 
first to make it easier.

--

___
Python tracker 

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

[issue28575] Error 0x80070643 While installing in Win 10 32 Bit

[Steve Dower]

Changes by Steve Dower :


--
assignee:  -> steve.dower

___
Python tracker 

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

[issue28575] Error 0x80070643 While installing in Win 10 32 Bit

[Steve Dower]

Steve Dower added the comment:

If you look in your TEMP directory there should be a few more log files 
alongside the one you attached. Could you post those too? You can put them in a 
zip file to make it easier if you like.

--

___
Python tracker 

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

[issue28573] Python 3.6.0b3 64-bit has no sys._mercurial info

[Steve Dower]

Steve Dower added the comment:

We're not responsible for the builds released by Linux distros. There's a good 
chance they didn't build from mercurial, but used the source release plus 
patches.

--

___
Python tracker 

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

[issue28573] Python 3.6.0b3 64-bit has no sys._mercurial info

[SilentGhost]

SilentGhost added the comment:

The same is on 3.5.2 on ubuntu 16.10

--
nosy: +SilentGhost, larry
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

[issue28513] Document zipfile CLI

[SilentGhost]

Changes by SilentGhost :


--
components:  -XML

___
Python tracker 

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

[issue28522] can't make IDLEX work with python._pth and python-3.6.0b2

[Big Stone]

Big Stone added the comment:

it looks ok with 3.6.0b3 ... sorry for the false alarm

--

___
Python tracker 

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

[issue28522] can't make IDLEX work with python._pth and python-3.6.0b2

[Big Stone]

Big Stone added the comment:

oups! I may have test the old one...

--

___
Python tracker 

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

[issue28522] can't make IDLEX work with python._pth and python-3.6.0b2

[Big Stone]

Big Stone added the comment:

the suggested python._pth change makes python unhappy:

python36.zip
DLLs
Lib
.
import site

Récipient d’erreurs 116251549737, type 5
Nom d’événement : BEX64
Réponse : Non disponible
ID de CAB : 0

Signature du problème : 
P1 : python.exe
P2 : 3.6.112.1013
P3 : 57fc0593
P4 : ucrtbase.dll
P5 : 10.0.14393.0
P6 : 578997b5
P7 : 0006d5b8
P8 : c409
P9 : 0005
P10 : 

Fichiers joints :
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WERF455.tmp.WERInternalMetadata.xml
\\?\C:\Users\famille\AppData\Local\Temp\WERFF72.tmp.appcompat.txt

Ces fichiers sont peut-être disponibles ici :
C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_python.exe_ec9ba1cd21c08ca3de75f183bf945ce737867af_b3b3e14f_1575008a

Symbole d’analyse : 
Nouvelle recherche de la solution : 0
ID de rapport : 66625eb0-e311-4368-be37-4b600bcb8978
Statut du rapport : 1
Récipient avec hachage : 57d09a5cb4a63ab86af1e62bd270b573

--
Added file: http://bugs.python.org/file45303/Report.wer

___
Python tracker 

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

[issue28513] Document zipfile CLI

[armando mendoza]

Changes by armando mendoza :


--
components: +XML

___
Python tracker 

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

[issue28574] Update bundled pip

[Donald Stufft]

Donald Stufft added the comment:

Yea. I worked on trying to get this done over the weekend and I was l left with 
one issue left. Hoping to get that done in the next day or two.

Sent from my iPhone

> On Nov 1, 2016, at 1:08 AM, Steve Dower  wrote:
> 
> 
> Steve Dower added the comment:
> 
> Also, it can go into whatever versions you'd normally insert into. I just 
> tagged 3.6 and 3.7 because they're the ones currently broken.
> 
> --
> 
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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

[issue28578] '\n' escape character print before the Py_GetCompiler version

[SilentGhost]

SilentGhost added the comment:

sys.version is a string, it's intended to be printed and it needs \n to be able 
to output two lines. I'm not sure what exactly problem you're having, but if 
you want special characters like \n not to show in output, you should use

>>> print(sys.version)

I'm going to close this issue.

--
resolution:  -> rejected
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

[issue28578] '\n' escape character print before the Py_GetCompiler version

[Amit Ghadge]

Amit Ghadge added the comment:

Actually, I run this in Python terminal,

>>> import sys
>>> import sys.version

I also have attached patch, Please let me that is correct or not?

--
keywords: +patch
Added file: http://bugs.python.org/file45302/getcompiler.c.patch

___
Python tracker 

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

[issue28577] ipaddress.ip_network(...).hosts() returns nothing for an IPv4 /32

[Nick Coghlan]

Nick Coghlan added the comment:

I think this is an area where ipaddress just inherited ipaddr's behaviour 
without challenging it.

As Peter isn't currently particularly active, and I stepped back from ipaddress 
maintenance some time ago (since I don't work heavily enough with raw IP 
addresses to have the right design instincts to arbitrate edge cases like 
this), I'd suggest raising both this and #27683 on python-dev, pointing out 
that we used to have the "/31" special case (treating it the same as "/30") and 
inadvertently lost it in some other refactoring, but have never special cased 
"/32".

--
nosy: +pmoody

___
Python tracker 

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

[issue27683] ipaddress subnet slicing iterator malfunction

[era]

era added the comment:

#28577 requests a similar special case for /32

--
nosy: +era

___
Python tracker 

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

[issue28577] ipaddress.ip_network(...).hosts() returns nothing for an IPv4 /32

[Xiang Zhang]

Xiang Zhang added the comment:

Sorry, it's #27683.

--

___
Python tracker 

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

[issue28578] '\n' escape character print before the Py_GetCompiler version

[SilentGhost]

SilentGhost added the comment:

And how exactly are you "hitting sys.version command"?

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

[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine

[Sam Ferencik]

Sam Ferencik added the comment:

Michael,

Thanks for reopening this. You say you're using "64-bit hardware", but what 
bitness is your OS and the Python interpreter?

If you read my original issue description, I only had this issue with 32-bit 
Python on a 64-bit Linux system (on 64-bit hardware).

You say you have 64-bit hardware but are both your AIX and Linux 64-bit? And 
what about your Python? (Can you try invoking python2.7-32 and python2.7-64 
explicitly?) Please add this detail.

Thanks,
Sam

--

___
Python tracker 

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

[issue28577] ipaddress.ip_network(...).hosts() returns nothing for an IPv4 /32

[era]

era added the comment:

Quick googling did not turn up anything like a credible authoritative reference 
for this, but in actual practice, I have seen /32 used to designate a single 
individual IP address in CIDR notation quite a lot.

I can see roughly three options:

  1. Status quo.  Silently surprise users who expect this to work.
  2. Silently fix.  Hard-code /32 to return a range of one IP address.
  3. Let users choose.  Similarly to the "strict=True" keyword argument in the 
constructor method, the code could allow for either lenient or strict semantics.

By the by, I don't see how the bug you linked to is relevant here, did you 
mistype the bug number?  #27863 is about _elementtree

--

___
Python tracker 

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

[issue28578] '\n' escape character print before the Py_GetCompiler version

[Amit Ghadge]

New submission from Amit Ghadge:

When I hit sys.version command on Linux shell the Py_GetCompiler version print 
'\n' character like;

'3.7.0a0 (default:7aa001a48120, Nov  1 2016, 13:53:25) \n[GCC 5.3.1 20160406 
(Red Hat 5.3.1-6)]'

And When I launch python, Py_GetCompiler line print to the next line,

[aghadge@localhost build]$ ./python 
Python 3.7.0a0 (default:7aa001a48120+, Nov  1 2016, 14:05:04)
[GCC 5.3.1 20160406 (Red Hat 5.3.1-6)] on linux

--
nosy: +eric.snow, steve.dower
versions: +Python 2.7, Python 3.4

___
Python tracker 

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

[issue28577] ipaddress.ip_network(...).hosts() returns nothing for an IPv4 /32

[Xiang Zhang]

Xiang Zhang added the comment:

I am not sure. Actually there is a special case for mask 31, you can see 
#27863. Its result includes both the network and broadcast address. Add Nick to 
see his opinion.

FYI, ipaddress （ipaddr in Py2) always return empty for 32. But there is other 
library returning network address for 32, for example netaddr.

--
nosy: +ncoghlan
status: closed -> open
type:  -> behavior
versions: +Python 3.7 -Python 3.4, Python 3.5

___
Python tracker 

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

[issue28578] '\n' escape character print before the Py_GetCompiler version

[Amit Ghadge]

Changes by Amit Ghadge :


--
nosy: amitgb14
priority: normal
severity: normal
status: open
title: '\n' escape character print before the Py_GetCompiler version
type: enhancement
versions: Python 3.7

___
Python tracker 

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

[issue28577] ipaddress.ip_network(...).hosts() returns nothing for an IPv4 /32

[era]

era added the comment:

@xiang.zhang thanks for the quick reply.

I find this behavior surprising.  If I process a list of addresses, like

ips = (
 '10.9.8.7/32'
 '10.11.12.8/28'
)

for test in ['10.9.8.7', '10.11.12.10']:
  if test in [str(y) for x in ips for y in ipaddress.ip_network(x).hosts()]:
print('{0} found'.format(test))
  else:
print('{0} not found'.format(test))

I would expect both addresses to print "found", but that's not how the current 
implementation works.

I agree that the /28 should not include the gateway and broadcast addresses, 
but I would not expect the explicitly listed /32 address to completely 
disappear from the output.

Are my expectations incorrect?  For code like this, what should I use instead, 
if not hosts()?

--

___
Python tracker 

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

[issue28577] ipaddress.ip_network(...).hosts() returns nothing for an IPv4 /32

[Xiang Zhang]

Xiang Zhang added the comment:

hosts() won't return the network address itself and the network broadcast 
address. So for 10.9.8.7/32, it should return [].

--
nosy: +xiang.zhang
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

[issue28513] Document zipfile CLI

[SilentGhost]

SilentGhost added the comment:

> Apparently (haven’t tried myself) if you put “.. program:: zipfile” before 
> the :option: invocations, it changes the default context and you don’t need 
> the  bit.

Yes, moving program directive just after "Command Line Interface" heading works 
fine.

--

___
Python tracker 

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

[issue28577] ipaddress.ip_network(...).hosts() returns nothing for an IPv4 /32

[era]

era added the comment:

(Meh, silly typo, of course the expected output is ['10.9.8.7'], sorry about 
that!)

--

___
Python tracker 

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

[issue28577] ipaddress.ip_network(...).hosts() returns nothing for an IPv4 /32

[era]

New submission from era:

I would expect the following code to return ['10.9.8.8'] but it returns an 
empty list.

yosemite-osx$ python3
Python 3.5.1 (default, Dec 26 2015, 18:08:53) 
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ipaddress
>>> list(ipaddress.ip_network('10.9.8.7/32').hosts())
[]

This seems to happen for every /32 address.  I'm guessing the logic which wants 
to exclude the gateway and broadcast addresses from a block should treat a /32 
as a special case.

I tried to look for a previous bug submission but I could not find one.  As 
such, it seems peculiar if this has not been reported before.  Is this actually 
expected behavior by some rule I am overlooking?

I tested on Linux 3.4 and OSX Yosemite Homebrew / Python 3.5.1.

--
components: Library (Lib)
messages: 279855
nosy: era
priority: normal
severity: normal
status: open
title: ipaddress.ip_network(...).hosts() returns nothing for an IPv4 /32
versions: Python 3.4, Python 3.5

___
Python tracker 

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

[issue28568] Build files in PC/VS9.0 contain an outdated sqlite version number

[Roundup Robot]

Roundup Robot added the comment:

New changeset 8f9c54a75c3d by Zachary Ware in branch '2.7':
Closes #28568: Fix VS9.0 build files to use sqlite 3.8.11.0
https://hg.python.org/cpython/rev/8f9c54a75c3d

--
nosy: +python-dev
resolution:  -> fixed
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

[issue28568] Build files in PC/VS9.0 contain an outdated sqlite version number

[Zachary Ware]

Zachary Ware added the comment:

Thanks for the report and patch!

--

___
Python tracker 

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

[issue28576] Uninstalling Py352 x86 with /uninstall option does not remove prepended paths

[jcrmatos]

New submission from jcrmatos:

Hello,

When uninstalling Py352 x86 with the /uninstall option, it doesn't remove the 
prepended paths that were added on installation (unlike the GUI uninstall which 
removes them).

My system is a Win7ProSP1 x64.

Best regards,

JM

--
components: Installation, Windows
messages: 279852
nosy: jcrmatos, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Uninstalling Py352 x86 with /uninstall option does not remove prepended 
paths
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

[issue28575] Error 0x80070643 While installing in Win 10 32 Bit

[Nixon]

New submission from Nixon:

While trying to install Python Error 0x80070643 is showing.

--
components: Windows
files: Python 3.6.0b3 (32-bit)_20161101112524.log
messages: 279851
nosy: nixonvarghese, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Error 0x80070643 While installing in Win 10 32 Bit
type: crash
versions: Python 3.6
Added file: http://bugs.python.org/file45301/Python 3.6.0b3 
(32-bit)_20161101112524.log

___
Python tracker 

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