Re: Clean Singleton Docstrings

[Rustom Mody]

On Saturday, July 16, 2016 at 9:50:13 AM UTC+5:30, Ethan Furman wrote:
> On 07/15/2016 09:04 PM, Rustom Mody wrote:
> 
> > Just that suggesting that python's bool notion is straightforward is an
> > unnecessary lie – especially to newbies.
> 
> Python's boolean concept is as simple as it gets -- what is not 
> straightforward about it?

I thought the other thread "Operator precedence/boolean logic" demonstrated 
that.
Ive added a further continuation there – where this topic is more relevant
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Operator Precedence/Boolean Logic

[Rustom Mody]

On Thursday, June 30, 2016 at 10:52:50 PM UTC+5:30, Steven D'Aprano wrote:
> Okay, if you think that automata cannot be empty, I'll accept that. In that
> case, then I'll change my answer and say that __bool__ for automata should
> simply return True. All automata should be truthy.
> 

I am not sure with what tone of voice you are saying that

If ... “return True” is about as good -- ie useful -- as (say)

def __bool__(self):
  from random import random
  return int(2*random())

then I think we agree

But then there is a well-established behavior pattern in python
captured by the contexts that raise AttributeError/NameError/TypeError etc
viz For things that are undefined we are told politely they are undefined

IOW Why say something is useless and define it rather than just leave undefined
something that is ill-defined.

If on the other hand you are giving that “return True”as a serious useful 
definition?

If both you and Chris tripped up on a right definition of an “empty” automaton
and regex respectively, I believe it demonstrates that getting boolishness
for an arbitrary type right is at least non-trivial. [FWIW My belief: In
general its nonsensical]
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue27527] Make not yielding from or awaiting a coroutine a SyntaxError

[Decorater]

Changes by Decorater :


--
type:  -> enhancement

___
Python tracker 

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

[issue27527] Make not yielding from or awaiting a coroutine a SyntaxError

[Decorater]

Decorater added the comment:

I am thinking like this example:

import asyncio

@asyncio.coroutine
def SomeCoroutine():
print("test...")

@asyncio.coroutine
def SomeNormalFunction():
SomeCoroutine()

Will print a warning instead I would like it to be a SyntaxError when the 
function is called that tries to call a coroutine that has not been 
yielded/awaited at all.

--

___
Python tracker 

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

[issue27527] Make not yielding from or awaiting a coroutine a SyntaxError

[Decorater]

New submission from Decorater:

Currently there is a waring printed in python when you try to call a coroutine 
without yieling from or awaiting it but I would like it to be a SyntaxError 
when this happens instead.

--
components: Windows
messages: 270538
nosy: Decorater, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Make not yielding from or awaiting a coroutine a SyntaxError
versions: Python 3.4, Python 3.5, Python 3.6

___
Python tracker 

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

[issue27083] PYTHONCASEOK is ignored on Windows

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Yes, I think it will work.

--

___
Python tracker 

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

Re: Clean Singleton Docstrings

[Ethan Furman]

On 07/15/2016 09:04 PM, Rustom Mody wrote:


Just that suggesting that python's bool notion is straightforward is an
unnecessary lie – especially to newbies.


Python's boolean concept is as simple as it gets -- what is not straightforward 
about it?

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list

[issue27485] urllib.splitport -- is it official or not?

[Senthil Kumaran]

Senthil Kumaran added the comment:

I think that we use encourage everyone to use the higher level functions like 
urlparse() or urlsplit() and then get the .port from the named tuple result.

Two things to do.

1. Update that Note the documentation which states a false statement that those 
helper functions are not exposed in urllib.parse

2. Raise a DeprecationWarning and rename them to _splitport()

--
nosy: +orsenthil
versions:  -Python 3.2, 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

Re: Clean Singleton Docstrings

[Rustom Mody]

On Thursday, July 14, 2016 at 5:24:50 AM UTC+5:30, Peter Otten wrote:
> Lawrence D’Oliveiro wrote:
> > And there are still those who think that Python’s lax acceptance of
> > non-boolean values as booleans is a good idea...
> 
> I don't think this particular problem serves as an argument for stricter 
> handling of boolean expressions because the fix


I was going to apologise for the snark
Then I see thats not my words; I said something along similar lines
Doesn't mean python needs to change
Just that suggesting that python's bool notion is straightforward is an
unnecessary lie – especially to newbies.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue15443] datetime module has no support for nanoseconds

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

Note that the patches attached so far to this issue are nowhere close to a 
complete implementation.  I don't think a python-only prototype (a patch to 
datetime.py) would be hard to implement, but implementation would be easier if 
nanoseconds replaced microseconds in datetime and timedelta objects with new 
microsecond(s) becoming a computed property.

--
keywords:  -patch
versions: +Python 3.6 -Python 3.5

___
Python tracker 

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

[issue22246] add strptime(s, '%s')

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

With PEP 495, conversion from timestamp to naive datetime will no longer loose 
information.  In light of this, I would like to reconsider what strftime('%s') 
should return in the absence of %z.

--

___
Python tracker 

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

[issue22246] add strptime(s, '%s')

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
assignee:  -> belopolsky
versions: +Python 3.6 -Python 3.5

___
Python tracker 

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

[issue12750] add cross-platform support for %s strftime-format code

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

Given that we have the .timestamp() method, I am not sure this would be a very 
useful feature, but maybe it is a way to eliminate an attractive nuisance.

If anyone is still interested in getting this in - please check with 
python-ideas.

--
title: datetime.strftime('%s') should respect tzinfo -> add cross-platform 
support for %s strftime-format code

___
Python tracker 

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

[issue27526] test_venv.TestEnsurePip fails mysteriously when /tmp is too small

[R. David Murray]

New submission from R. David Murray:

I've been having a failure in test_venv when running the tests suite for some 
months now.  Since the buildbots aren't, I was guessing it was a local problem. 
 I finally got around to looking at it today, and I had no clue what was wrong 
here, after setting maxDiff to None:

==
FAIL: test_with_pip (test.test_venv.EnsurePipTest)
--
Traceback (most recent call last):
  File "/home/rdmurray/python/p35/Lib/test/test_venv.py", line 381, in 
test_with_pip
self.assertEqual(err, "")
AssertionError: 'Traceback (most recent call last):\n  Fil[741 chars]\'\n' != ''
- Traceback (most recent call last):
-   File "/home/rdmurray/python/p35/Lib/runpy.py", line 174, in 
_run_module_as_main
- mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
-   File "/home/rdmurray/python/p35/Lib/runpy.py", line 133, in 
_get_module_details
- return _get_module_details(pkg_main_name, error)
-   File "/home/rdmurray/python/p35/Lib/runpy.py", line 109, in 
_get_module_details
- __import__(pkg_name)
-   File "/tmp/tmpcpx0dj2o/lib/python3.5/site-packages/pip/__init__.py", line 
14, in 
- from pip.utils import get_installed_distributions, get_prog
-   File "/tmp/tmpcpx0dj2o/lib/python3.5/site-packages/pip/utils/__init__.py", 
line 27, in 
- from pip._vendor import pkg_resources
- ImportError: cannot import name 'pkg_resources'


It turns out that the problem was that the virtual machine I was running this 
in had a /tmp that was too small for pip to operate.  I've had this problem 
often with pip on my VMs.

I'm reporting this because it seems to me reasonably likely that ensurepip will 
fail mysteriously if /tmp is too small.  I'm OK with this issue getting closed 
as won't fix, since my setup is rather odd and it may be that no one else will 
run in to this.  But it may be that someone else will, and at least there will 
be a bug report to find.

--
messages: 270532
nosy: dstufft, r.david.murray
priority: normal
severity: normal
status: open
title: test_venv.TestEnsurePip fails mysteriously when /tmp is too small
type: behavior

___
Python tracker 

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

[issue12750] datetime.strftime('%s') should respect tzinfo

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
versions: +Python 3.6 -Python 3.5

___
Python tracker 

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

[issue12750] datetime.strftime('%s') should respect tzinfo

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
nosy: +shanmbic

___
Python tracker 

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

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

Sorry, the tracker messed up the URL: go to

https://github.com/abalkin/cpython.git

and select branch:issue24773-s3

--

___
Python tracker 

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

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

Since this is closely related to issue 15873, I am merging the nosy lists.

As far as I can tell, the patch just needs tests and a final decision on issue 
5288. I don't think it is at all controversial, but we need to relax the offset 
restrictions before ::z code can go in.

shanmbic, you can use my PEP 495 branch to test.  See 
.

--
nosy: +Anders.Hovmöller, Arfrever, Eric.Hanchrow, Roman.Evstifeev, SilentGhost, 
aymeric.augustin, barry, berker.peksag, cvrebert, davydov, deronnax, 
eric.araujo, flying sheep, haypo, jcea, jstasiak, jwilk, karlcow, kirpit, 
mcepl, mihaic, nagle, pbryan, perey, piotr.dobrogost, r.david.murray, roysmith
stage: patch review -> commit review

___
Python tracker 

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

[issue15873] datetime: add ability to parse RFC 3339 dates and times

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

I would very much like to see this ready before the feature cut-off for Python 
3.6.  Could someone post a summary on python-ideas to get a show of hands on 
some of the remaining wrinkles?

I would not worry about a C implementation at this point.  We can put python 
implementation in _strptime.py and call it from C as we do for the strptime 
method.

--

___
Python tracker 

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

[issue27522] Reference cycle in email.feedparser

[R. David Murray]

Changes by R. David Murray :


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

[issue27522] Reference cycle in email.feedparser

[R. David Murray]

R. David Murray added the comment:

Thanks, Costas.

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

[issue27522] Reference cycle in email.feedparser

[Roundup Robot]

Roundup Robot added the comment:

New changeset 6c7fd035bce3 by R David Murray in branch '3.5':
#27522: break unintended cycle in feedparser.
https://hg.python.org/cpython/rev/6c7fd035bce3

New changeset e1278508f3cb by R David Murray in branch 'default':
Merge: #27522: break unintended cycle in feedparser.
https://hg.python.org/cpython/rev/e1278508f3cb

--
nosy: +python-dev

___
Python tracker 

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

[issue15873] datetime: add ability to parse RFC 3339 dates and times

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
nosy:  -Alexander.Belopolsky

___
Python tracker 

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

[issue10225] Fix doctest runable examples in python manual

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
assignee: belopolsky -> 

___
Python tracker 

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

[issue25729] update pure python datetime.timedelta creation

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

For future reference, here is a link to PyPy history of datetime.py:

https://bitbucket.org/pypy/pypy/history-node/919e00b3e558/lib_pypy/datetime.py?at=default

--

___
Python tracker 

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

[issue25729] update pure python datetime.timedelta creation

[Alexander Belopolsky]

Alexander Belopolsky added the comment:

Brian, we had a similar discussion in issue 20858, but I am still unsure about 
the relationship between our datetime.py and that in PyPy.  Do you use CPython 
version in PyPy?  If not, have you applied this patch and if so, can you link 
to a PyPy issue or a commit?

--

___
Python tracker 

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

Re: Curious Omission In New-Style Formats

[Chris Angelico]

On Sat, Jul 16, 2016 at 9:35 AM, Lawrence D’Oliveiro
 wrote:
> On Thursday, July 14, 2016 at 12:46:26 PM UTC+12, Ian wrote:
>>
>> On Wed, Jul 13, 2016 at 4:24 PM, Lawrence D’Oliveiro wrote:
>>>
>>> How about “mantissa length”, then. That sufficiently neutral for you?
>>
>> That makes even less sense for integers.
>
> Perhaps you would prefer the more gender-neutral term “persontissa” ...

I would laugh, but gender issues are extremely significand to a lot of people...

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue26988] Add AutoNumberedEnum to stdlib

[Ethan Furman]

Ethan Furman added the comment:

Oh, and yes, I'll fix the whole 80-column thing.  ;)

--

___
Python tracker 

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

[issue26988] Add AutoNumberedEnum to stdlib

[Ethan Furman]

Ethan Furman added the comment:

Okay, here's an updated patch with the doc changes.

Once the main patch is committed I'm going to reorganize the docs a bit, but 
that's later.

--
assignee:  -> ethan.furman
Added file: http://bugs.python.org/file43743/issue26988.stoneleaf.02.patch

___
Python tracker 

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

[issue25507] IDLE: user code 'import tkinter; tkinter.font' should fail

[Terry J. Reedy]

Terry J. Reedy added the comment:

run_autocomplete.diff is a preliminary patch for moving the completion list 
function into run.py and reversing the imports.  However, the assert in 
test_autocomplete, line 103 newly fails because the call to open_completions in 
autocomplete_event (line 85) returns None.  The None comes from l. 155.
comp_lists = self.fetch_completions(comp_what, mode)
if not comp_lists[0]:
return None
I do not yet know why moving the one function causes the completion lists for 
re to be blank. I am going to shelve this approach and return to deletion.

--
keywords: +patch
Added file: http://bugs.python.org/file43742/run_autocomplete.diff

___
Python tracker 

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

Re: Curious Omission In New-Style Formats

[Lawrence D’Oliveiro]

On Thursday, July 14, 2016 at 12:46:26 PM UTC+12, Ian wrote:
>
> On Wed, Jul 13, 2016 at 4:24 PM, Lawrence D’Oliveiro wrote:
>>
>> How about “mantissa length”, then. That sufficiently neutral for you?
> 
> That makes even less sense for integers.

Perhaps you would prefer the more gender-neutral term “persontissa” ...
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue27213] Rework CALL_FUNCTION* opcodes

[Demur Rumed]

Demur Rumed added the comment:

Since the most common use of CALL_FUNCTION_EX is..

def f(*x,*kw):
other_func(*x, **kw)

I've added some code to BUILD_MAP_UNPACK_WITH_CALL & BUILD_TUPLE_UNPACK to not 
allocate a new object if called with oparg of 1 & TOP() is correct type

--
Added file: http://bugs.python.org/file43741/callfunc5.patch

___
Python tracker 

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

[issue27525] Wrong OS header on file created by gzip module

[Ned Deily]

Ned Deily added the comment:

It appears that not including the OS value in the header is probably more of a 
feature rather than a bug considering how long the gzip module has been around 
with this behavior.  Have you found any real-life cases where it makes a 
difference?

In any case, the os.platform value 'mac' referred to ancient Mac OS Classic 
(Mac OS 9 and earlier), platforms current Pythons do not support.  Current Mac 
OS X systems are platform 'darwin' and would use the same gzip value as 
platform 'posix'.

--
nosy: +ned.deily

___
Python tracker 

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

[issue27524] Update os.path for PEP 519/__fspath__()

[Brett Cannon]

Brett Cannon added the comment:

Here are tests for genericpath, posixpath, and ntpath (which should in the end 
cover all of os.path).

--
keywords: +patch
stage: test needed -> needs patch
Added file: http://bugs.python.org/file43740/fspath_tests.diff

___
Python tracker 

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

[issue27523] Silence Socket Depreciation Warnings.

[Decorater]

Decorater added the comment:

I just noticed it does not work the way I had hoped. Ignore this.

--
status: open -> closed

___
Python tracker 

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

[issue27524] Update os.path for PEP 519/__fspath__()

[Ethan Furman]

Changes by Ethan Furman :


--
nosy: +ethan.furman

___
Python tracker 

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

[issue24254] Make class definition namespace ordered by default

[Eric Snow]

Eric Snow added the comment:

post-review updates

--
Added file: http://bugs.python.org/file43739/deforder-with-tp-slot.diff

___
Python tracker 

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

[issue26800] Don't accept bytearray as filenames part 2

[Brett Cannon]

Brett Cannon added the comment:

Serhiy's patch LGTM.

--
nosy: +brett.cannon

___
Python tracker 

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

[issue27525] Wrong OS header on file created by gzip module

[Dor Dankner]

New submission from Dor Dankner:

The gzip module generates files with wrong OS header, by putting "Unknown" OS, 
instead of checking and filling the user's OS.
>From the gzip RFC (rfc1952): "This identifies the type of file system on which 
>compression took place. This may be useful in determining end-of-line 
>convention for text files."

The following patch contains a fix that fills the current OS flag (and testcase 
;) )

* The bug is relevant to python 2.x too, but I did not test the patch on it.
** also, I did not run the testcase on Win/Mac, however it should work.

--
components: Extension Modules
files: gzip_os_header_fix_and_tests.patch
keywords: patch
messages: 270515
nosy: ddorda
priority: normal
severity: normal
status: open
title: Wrong OS header on file created by gzip module
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file43738/gzip_os_header_fix_and_tests.patch

___
Python tracker 

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

[issue27523] Silence Socket Depreciation Warnings.

[Decorater]

Decorater added the comment:

Oh and ignore the exe on the patch if you see that 1 has changed.

--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
type:  -> enhancement

___
Python tracker 

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

[issue27524] Update os.path for PEP 519/__fspath__()

[Brett Cannon]

Changes by Brett Cannon :


--
dependencies: +Support Path objects in the posix module, Support path objects 
in the ntpath module

___
Python tracker 

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

[issue27524] Update os.path for PEP 519/__fspath__()

[Brett Cannon]

New submission from Brett Cannon:

As per PEP 519, os.path needs to be updated to support __fspath__().

--
assignee: brett.cannon
components: Library (Lib)
messages: 270513
nosy: brett.cannon
priority: release blocker
severity: normal
stage: test needed
status: open
title: Update os.path for PEP 519/__fspath__()
type: behavior
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

[issue27523] Silence Socket Depreciation Warnings.

[Decorater]

New submission from Decorater:

I have made a patch to some of the warnings to silence them hopefully this will 
help a lot.

--
files: socketmodule.c.patch
keywords: patch
messages: 270512
nosy: Decorater
priority: normal
severity: normal
status: open
title: Silence Socket Depreciation Warnings.
versions: Python 3.6
Added file: http://bugs.python.org/file43737/socketmodule.c.patch

___
Python tracker 

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

[issue25507] IDLE: user code 'import tkinter; tkinter.font' should fail

[Terry J. Reedy]

Terry J. Reedy added the comment:

In #27515, Nick Coughlin said that 'del a.b', would work if sys.modules('a.b') 
is also deleted -- unless a.b objects to being reloaded.  This seems not a 
problem for the current 8 tkinter submodules.  The attached tkimports.py runs 
without error.

I am not going to patch 2.7, which does not have the bug, just for the import 
reduction.  The last patch could be applied to 3.5 since it does not remove 
anything from PyShell.  Putting the three warning functions in a class and 
making the warning global a class attribute (a future issue) would be a 
different matter.

--
versions:  -Python 2.7
Added file: http://bugs.python.org/file43736/tkimports.py

___
Python tracker 

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

[issue27515] Dotted name re-import does not rebind after deletion

[Terry J. Reedy]

Terry J. Reedy added the comment:

Nick, do I understand correctly that if the reimport executes and I can access 
the module, everything should be okay?

--

___
Python tracker 

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

[issue27083] PYTHONCASEOK is ignored on Windows

[Brett Cannon]

Brett Cannon added the comment:

I think the best we can do is be platform-specific in what is checked for in 
the environ dict (e.g. b'PYTHONCASEOK' on darwin, 'PYTHONCASEOK' on win, and I 
don't know about cygwin), but otherwise one would have to iterate through the 
keys of the dict and do a type check before doing the comparison to fully avoid 
any potential warning being triggered.

Does the platform-specific decision of what to look for work for you, Serhiy?

--

___
Python tracker 

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

Re: math.frexp

[Paul Rubin]

Steven D'Aprano  writes:
> But this can give some protection against overflow of intermediate
> values. 

Might be simplest to just add the logarithms.  Look up Kahan summation
for how to do that while minimizing loss of precision.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue27083] PYTHONCASEOK is ignored on Windows

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Seeing if a key in a dict exists involves the key comparison if there is a key 
on the same position in the hash table.

--
nosy: +rhettinger

___
Python tracker 

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

[issue27083] PYTHONCASEOK is ignored on Windows

[Brett Cannon]

Brett Cannon added the comment:

There's no direct comparison to trigger a warning; it's just seeing if a key in 
a dict exists.

And b'PYTHONCASEOK' is not a bug as that's required for OS X (remember this is 
technically posix.environ, not os.environ).

--
status: open -> closed

___
Python tracker 

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

[issue27083] PYTHONCASEOK is ignored on Windows

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Comparing bytes with str can emit a warning or raise an exception. Checking for 
b'PYTHONCASEOK' in os.environ looks as a bug to me.

--
status: closed -> open

___
Python tracker 

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

[issue27078] Make f'' strings faster than .format: BUILD_STRING opcode?

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Nice idea, Antti. But I tried to implement it, and surprisingly found that this 
approach is slower than FORMAT_VALUE + BUILD_STRING. At least for this 
particular example. Perhaps because we can't use a stack and need to allocate a 
new tuple containing literal strings and formatted values for PyUnicode_Join(). 
Not mentioning that the code is much more complex.

Here is updated previous patch with fixed leak.

--
Added file: http://bugs.python.org/file43735/fstring_build_string_2.patch

___
Python tracker 

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

[issue27521] Misleading compress level header on files created with gzip

[Dor Dankner]

Dor Dankner added the comment:

Thank you for the fast reponse!
tests patch for the proposal fix is attached :)

--
Added file: http://bugs.python.org/file43734/compress_level_tests.patch

___
Python tracker 

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

[issue27522] Reference cycle in email.feedparser

[Costas]

New submission from Costas:

Background: We have two (clusters of) servers running a high-throughput 
websocket application. One runs under Python 2.7, the other has been migrated 
to 3.4. Very similar code runs on both servers, and both manually call the gc 
periodically to reduce latency. 

Problem: We noticed that under load the 3.4 server seems to slowly "leak" 
memory between gc collections, while the 2.7 server doesn't have this issue.

Investigation: I tracked down the source of all the garbage to 
email.feedparser, which is used by http.server to parse the headers of incoming 
requests. The initialiser of the FeedParser class creates a reference cycle by 
putting a lambda function into a member variable. The lambda contains a closure 
with its surrounding scope that points to the object, and the object points 
back to the lambda. 

Proposed fix: The lambda can be harmlessly replaced by a boolean value, which 
doesn't cause the problem, and it's much more readable too. I'm attaching a 
little patch.

--
components: email
files: emailfeedparsergc.patch
keywords: patch
messages: 270503
nosy: Costas, barry, r.david.murray
priority: normal
severity: normal
status: open
title: Reference cycle in email.feedparser
type: resource usage
versions: Python 3.5
Added file: http://bugs.python.org/file43733/emailfeedparsergc.patch

___
Python tracker 

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

[issue26696] Document collections.abc.ByteString

[Roundup Robot]

Roundup Robot added the comment:

New changeset 8be87fde577f by Brett Cannon in branch '3.5':
Issue #26696: Document collections.abc.ByteString.
https://hg.python.org/cpython/rev/8be87fde577f

New changeset 6ba86ca875a8 by Brett Cannon in branch 'default':
Merge for #26696
https://hg.python.org/cpython/rev/6ba86ca875a8

--
nosy: +python-dev

___
Python tracker 

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

[issue26696] Document collections.abc.ByteString

[Brett Cannon]

Brett Cannon added the comment:

Thanks for the patch, Xiang!

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

Re: Were is a great place to Share your finished projects?

[Marko Rauhamaa]

Marko Rauhamaa :
> Anyway, all of this has reminded me that bitkeeper is now free. I've
> never tried it so let's see if it is everything Sun's Teamware was.

Hm, ran into compilation trouble.

Maybe I should wait till bk is available for Fedora.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue27083] PYTHONCASEOK is ignored on Windows

[Brett Cannon]

Brett Cannon added the comment:

I fixed this by simply checking for both b'PYTHONCASEOK' and 'PYTHONCASEOK'. 
Thanks for the bug report, Eryk!

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

___
Python tracker 

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

[issue27083] PYTHONCASEOK is ignored on Windows

[Roundup Robot]

Roundup Robot added the comment:

New changeset bedcb9ec3f26 by Brett Cannon in branch '3.5':
Issue #27083: Respect the PYTHONCASEOK environment variable under
https://hg.python.org/cpython/rev/bedcb9ec3f26

New changeset 777da58794ca by Brett Cannon in branch 'default':
Merge for #27083
https://hg.python.org/cpython/rev/777da58794ca

--
nosy: +python-dev

___
Python tracker 

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

Re: Were is a great place to Share your finished projects?

[Marko Rauhamaa]

Chris Angelico :
> I've never managed to get Mercurial's branching system into my head
> (and then you have the people saying "don't use hg branches at all,
> just use named tags" or somesuch), but the git branching system is
> extremely simple. In fact, all of git is very simple. To anyone who is
> having trouble with comprehending git, I strongly recommend this
> video. It assumes you have a basic understanding of git commands (or
> can pause the video and look up a git-hg Rosetta Stone), but you don't
> need expert-level knowledge. In fact, it's aimed at people ages 4 and
> up...

I use git daily but don't really use branches, and need to ask a
coworker about the branching commands. Also, reverting changes in git
keeps baffling me (I need to check the source code of emacs' vc-mode to
figure out how it's done).

Anyway, all of this has reminded me that bitkeeper is now free. I've
never tried it so let's see if it is everything Sun's Teamware was.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: math.frexp

[Random832]

On Fri, Jul 15, 2016, at 12:32, Steven D'Aprano wrote:
> I can take the geometric mean of: 
> 
> [2.0**900, 2.0**920, 2.0**960, 2.0**980, 2.0**990]
> 
> and get to within a relative error of 1e-14 of the correct answer,
> 2**950:
> 
> py> geometric_mean([2.0**900, 2.0**920, 2.0**960, 2.0**980, 2.0**990])
> 9.516908214257811e+285
> py> 2.0**950
> 9.516908214257812e+285
>
> Here's one that's exact:
> 
> py> geometric_mean([2e300, 4e300, 8e300, 16e300, 32e300])
> 8e+300

My own attempt gave an exact result for both test cases.

from math import frexp as _frexp, ldexp

def frexp(x):
if type(x) is tuple:
m, e1 = x
m, e2 = _frexp(m)
return m, e1 + e2
else:
return _frexp(x)

def _mul(a, b):
ma, ea = frexp(a)
mb, eb = frexp(b)
return frexp((ma * mb, ea + eb))

def _product(values):
return reduce(_mul, values)

def geometric_mean(values):
n = len(values)
pm, pe = _product(values)
me, re = divmod(pe, n)
pm = ldexp(pm, re)
return ldexp(pm**(1./n), me)


-- 
https://mail.python.org/mailman/listinfo/python-list

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

[Brett Cannon]

Brett Cannon added the comment:

Thanks for catching that, David.

--
status: open -> closed

___
Python tracker 

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

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

[Roundup Robot]

Roundup Robot added the comment:

New changeset bb7686a555cc by Brett Cannon in branch 'default':
Fix a failing test introduced as part of issue #27512
https://hg.python.org/cpython/rev/bb7686a555cc

--

___
Python tracker 

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

[issue27521] Misleading compress level header on files created with gzip

[R. David Murray]

R. David Murray added the comment:

Thanks for the report and patch.  Now we need a test.

--
nosy: +r.david.murray
stage:  -> test needed
versions:  -Python 3.2, 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

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

[R. David Murray]

R. David Murray added the comment:

Looks like the buildbots aren't happy:

http://buildbot.python.org/all/builders/s390x%20SLES%203.x/builds/1396/steps/test/logs/stdio
http://buildbot.python.org/all/builders/s390x%20Debian%203.x/builds/1374

--
nosy: +r.david.murray
status: closed -> open

___
Python tracker 

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

[issue26844] Wrong error message during import

[Roundup Robot]

Roundup Robot added the comment:

New changeset 22eaf6158e7b by Brett Cannon in branch '3.5':
Issue #26844: Fix imp.find_module() to have the exception related to
https://hg.python.org/cpython/rev/22eaf6158e7b

New changeset 46da639f7114 by Brett Cannon in branch 'default':
Merge for #26844
https://hg.python.org/cpython/rev/46da639f7114

--
nosy: +python-dev

___
Python tracker 

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

[issue26844] Wrong error message during import

[Brett Cannon]

Brett Cannon added the comment:

Thanks for the patch, Lev!

--
resolution:  -> fixed
stage: commit review -> 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

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

[Brett Cannon]

Changes by Brett Cannon :


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

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

[Brett Cannon]

Brett Cannon added the comment:

Thanks for the patch, Xiang! Only thing I changed were braces around the `if` 
body in the C code and made the mock __fspath__() class raise an exception 
itself.

--

___
Python tracker 

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

[issue27512] os.fspath is certain to crash when exception raised in __fspath__

[Roundup Robot]

Roundup Robot added the comment:

New changeset 35bf83ff0828 by Brett Cannon in branch 'default':
Issue #27512: Don't segfault when os.fspath() calls an object whose
https://hg.python.org/cpython/rev/35bf83ff0828

--
nosy: +python-dev

___
Python tracker 

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

[issue27521] Misleading compress level header on files created with gzip

[Dor Dankner]

New submission from Dor Dankner:

When creating a gzip file using the gzip module,
the wrong header is set as the compress level when not using the default (9).
the reason is that the header is set blindly as \002, without really checking 
what compress level is.

Patch to fix that behaviour is provided :)
(Patch tested on python 3.5, but relevant to 2.x versions too)

--
components: Extension Modules
files: gzip_compressionlvl_header_fix.patch
keywords: patch
messages: 270490
nosy: ddorda
priority: normal
severity: normal
status: open
title: Misleading compress level header on files created with gzip
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: 
http://bugs.python.org/file43732/gzip_compressionlvl_header_fix.patch

___
Python tracker 

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

Re: math.frexp

[Chris Angelico]

On Sat, Jul 16, 2016 at 2:32 AM, Steven D'Aprano  wrote:
> If the result is too big to be represented as a float at the end of the
> product, then of course it will overflow. But this can give some protection
> against overflow of intermediate values. Consider multiplying:
>
> 2.0, 1e200, 1e200, 1e-200, 1e-200, 3.0
>
>
> Mathematically, the answer should be 6. In principle, by rescaling when
> needed to prevent overflow (or underflow), product() should be able to get
> something very close to 6, if not exactly 6.

I was under the impression that appropriate reordering of the elements
could prevent over/underflow and maximize accuracy, but that may be a
mistaken memory. However...

> But I'm not actually writing a general product() function. I'm doing this
> for geometric mean, so I return the scaling exponent and the mantissa[1]
> separately, and then take the nth-root of them individually, before
> combining them into the final result.

... this makes a lot of sense. In effect, I *think*, you're basically
doing the multiplication on something rather larger than a 64-bit IEEE
float, then taking the nth-root, and then combine them and convert
back to float. Is this about right?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: math.frexp

[Nobody]

On Fri, 15 Jul 2016 21:39:31 +1000, Steven D'Aprano wrote:

> prod *= (m1*m2)

Should be:

prod = m1*m2

or:
prod *= m1

(in the latter case, there's no point in decomposing prod).

Of course, if the result overflows, it's going to overflow whether you use
the naive approach or frexp(); in the latter case, it's the 2.0**scale
which will overflow.

One advantage of processing the scale separately is that you can use e.g.

return ((int(prod * 2**53) * (2**(scale-53))) if scale >= 53
else prod * 2**scale)

which will return a (long) integer if the exponent is such that the
fractional bits are lost.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: math.frexp

[Steven D'Aprano]

On Fri, 15 Jul 2016 09:48 pm, Chris Angelico wrote:

>> py> product_scaled([2.5, 3.5])  # expected 8.75
>> 2.734375
>>
> 
> You're chaining your product twice. (Also your scale, although that
> appears to be correct.) Changing it to "prod = m1 * m2" gives 8.75.

D'oh!

Thanks! I needed some fresh eyes on that, because I have been staring at it
for two days.


> But what do you gain by this? You're still stuffing the result back
> into a float at the end, so all you do is change from getting
> float("inf") to getting OverflowError. How can you make it not
> overflow?

If the result is too big to be represented as a float at the end of the
product, then of course it will overflow. But this can give some protection
against overflow of intermediate values. Consider multiplying:

2.0, 1e200, 1e200, 1e-200, 1e-200, 3.0


Mathematically, the answer should be 6. In principle, by rescaling when
needed to prevent overflow (or underflow), product() should be able to get
something very close to 6, if not exactly 6.

But I'm not actually writing a general product() function. I'm doing this
for geometric mean, so I return the scaling exponent and the mantissa[1]
separately, and then take the nth-root of them individually, before
combining them into the final result. Here's an example from my test suite.
I can take the geometric mean of: 

[2.0**900, 2.0**920, 2.0**960, 2.0**980, 2.0**990]

and get to within a relative error of 1e-14 of the correct answer, 2**950:

py> geometric_mean([2.0**900, 2.0**920, 2.0**960, 2.0**980, 2.0**990])
9.516908214257811e+285
py> 2.0**950
9.516908214257812e+285


Here's one that's exact:

py> geometric_mean([2e300, 4e300, 8e300, 16e300, 32e300])
8e+300






[1] I don't care what it's actually called :-)


-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Were is a great place to Share your finished projects?

[Chris Angelico]

On Sat, Jul 16, 2016 at 1:39 AM, Brandon McCaig  wrote:
> [regarding Mercurial]
> Combined with their failure to accomodate the distributed
> development model properly you now have a bunch of incompatible
> ideas for managing branches and history editing and they still
> haven't gotten it all right yet (but they're getting closer the
> more and more they model the design after Git).

I've never managed to get Mercurial's branching system into my head
(and then you have the people saying "don't use hg branches at all,
just use named tags" or somesuch), but the git branching system is
extremely simple. In fact, all of git is very simple. To anyone who is
having trouble with comprehending git, I strongly recommend this
video. It assumes you have a basic understanding of git commands (or
can pause the video and look up a git-hg Rosetta Stone), but you don't
need expert-level knowledge. In fact, it's aimed at people ages 4 and
up...

https://www.youtube.com/watch?v=1ffBJ4sVUb4

>> To give you an idea of how screwed up things are, even though I'm not one of
>> the developer team, and have never pushed a thing into the code
>> repositories (I have pushed into documentation repos), somehow according
>> to "git blame" I'm responsible for a bunch of code.
>
> The user name and email fields are not controlled in either Git
> or Mercurial so anybody can commit code under your name without
> you being involved. That would be pretty unprofessional though...

If you're paranoid, you can have git sign your commits, in which case
anyone could commit code under your name, but not using your private
key. You can then tell people to be suspicious of any commits they
can't cryptographically verify.

> I can't imagine Git magically pulling your name out of nowhere
> when it looks up the author of commits that are responsible for
> lines of code... Maybe you should report that to the mailing list
> and get to the bottom of it... I suspect that the explanation has
> nothing to do with any bugs in Git.

There are a few possibilities. If someone copied a slab of code from
the documentation repo straight into the code repo (maybe you provided
examples or something), git might detect that and recognize the
copying. In that case, you'd be (correctly) responsible for that code,
and the author would be a two-part "originally authored" pointing to
your docs commit and "moved or copied here by" pointing to the commit
that actually incorporated it. But if the repositories are completely
separate, this is unlikely. More likely, someone might be able to
cherry-pick the commit itself, if there is a corresponding file in
code; again, this would have a two-part authorship marker "author" and
"committer", because every git commit has this. (This is something
Mercurial lacks. Every commit is blamed to the person with the
commit-bit who pushed it, rather than the person who actually wrote
the code. Obviously the committer is important, but so is the author.)

If you want to get to the bottom of it, I would advise exploring the
commits that are tagged with your name. Do they look like changes you
made? Did you provide a patch file that someone else committed? And,
who committed the changes - can you email that person to ask for
clarification?

The beauty of git is that all the information is right there, if you
just look at it - 'git show 142857' will answer most of the above
questions, and add "--format=full" or "--format=fuller" [1] to get the
committer's info. Dig around... have fun!

[1] I mean, not "fuller", just... more formatful. Wait, what?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Were is a great place to Share your finished projects?

[Brandon McCaig]

On Fri, Jul 15, 2016 at 10:39:05AM +1000, Steven D'Aprano wrote:
> About seven years ago, the senior technical manager at my work chose hg over
> git. When he left to go to greener pastures, the dev team took about 30
> seconds to to reverse his decision and migrate to git, after which the
> level of VCS-related screw-ups and queries went through the roof.

Git used to have much sharper edges than Mercurial, but that is
pretty much a thing of the past. With Git you pretty much can't
permanently lose history unless you try really, really hard.
It'll always be there in the reflog for a period of several days
minimum (I think 2 weeks by default?) and if you're worried about
it you can configure it to put that off for months or years...

On the other hand, I have had Mercurial bugs repeatedly lose work
of mine. The kind of bugs that aren't easy to reproduce so nearly
impossible to report and nearly impossible to fix. The ecosystem
of "extensions" makes this problem inevitable. You depend on
extensions, typically third-party extensions for the first few
years of their life, for all of the power-user stuff, and the
extensions have as much power to corrupt or lose history as the
main library does. And of course, they have the potential to
alter the behavior of the core library making reporting bugs that
much more difficult ("ok, but which extensions, official or
unofficial, do you have installed?"). Now instead of one team
writing bugs you have N teams writing them in isolation.

Combined with their failure to accomodate the distributed
development model properly you now have a bunch of incompatible
ideas for managing branches and history editing and they still
haven't gotten it all right yet (but they're getting closer the
more and more they model the design after Git).

> To give you an idea of how screwed up things are, even though I'm not one of
> the developer team, and have never pushed a thing into the code
> repositories (I have pushed into documentation repos), somehow according
> to "git blame" I'm responsible for a bunch of code.

The user name and email fields are not controlled in either Git
or Mercurial so anybody can commit code under your name without
you being involved. That would be pretty unprofessional though...
I can't imagine Git magically pulling your name out of nowhere
when it looks up the author of commits that are responsible for
lines of code... Maybe you should report that to the mailing list
and get to the bottom of it... I suspect that the explanation has
nothing to do with any bugs in Git.

Regards,


-- 
Brandon McCaig  
Castopulence Software 
Blog 
perl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }.
q{Vg qbrfa'\''g nyjnlf fbhaq gung jnl.};
tr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say'



signature.asc
Description: Digital signature
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue27519] update the references to http://mercurial.selenic.com

[Stéphane Wirtel]

Stéphane Wirtel added the comment:

because we don't want to change a tool but just an URL. you can create an other 
issue if you prefer to use TortoiseHg.

--

___
Python tracker 

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

Re: Curious Omission In New-Style Formats

[Jussi Piitulainen]

Steven D'Aprano writes:

> On Fri, 15 Jul 2016 11:28 pm, Jussi Piitulainen wrote:
>
>> There's an old story they tell in my family about a child who begs for
>> bread from a house. The lady of the house asks if they want a one-hand
>> slice (yhe käe leipä) or a two-hand slice (kahe käe leipä), and when the
>> poor hungry child asks for the two-hand slice, they get a slice so thin
>> that it needs to be held with both hands. That's mean.
>
>
> Ha, that's exactly the same story my grandmother (who was
> Estonian-Russian) used to tell me. If you don't mind me asking, what
> nationality are you?

Finnish. Karelian enough that it probably is the exact same story.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue27519] update the references to http://mercurial.selenic.com

[Decorater]

Decorater added the comment:

TortoiseHg

--

___
Python tracker 

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

[issue27520] Issue when building PGO

[Decorater]

New submission from Decorater:

I get this issue when trying a PGO build it seems that some projects do not 
create a pgd.

(the link to simplify the size on here)
https://bpaste.net/show/c704ee912c53

--
components: Build, Tests, Windows
messages: 270487
nosy: Decorater, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Issue when building PGO
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

[issue27519] update the references to http://mercurial.selenic.com

[Stéphane Wirtel]

Stéphane Wirtel added the comment:

which GUI version ? it's in the documentation. please could you be more 
explicit ? thanks

--

___
Python tracker 

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

[issue27519] update the references to http://mercurial.selenic.com

[Decorater]

Decorater added the comment:

Why not add url to the GUI version too that actually adds hg to the path?

--
nosy: +Decorater

___
Python tracker 

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

Re: Curious Omission In New-Style Formats

[Steven D'Aprano]

On Fri, 15 Jul 2016 11:28 pm, Jussi Piitulainen wrote:

> There's an old story they tell in my family about a child who begs for
> bread from a house. The lady of the house asks if they want a one-hand
> slice (yhe käe leipä) or a two-hand slice (kahe käe leipä), and when the
> poor hungry child asks for the two-hand slice, they get a slice so thin
> that it needs to be held with both hands. That's mean.


Ha, that's exactly the same story my grandmother (who was Estonian-Russian)
used to tell me. If you don't mind me asking, what nationality are you?




-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Steven D'Aprano]

On Fri, 15 Jul 2016 11:13 pm, Jussi Piitulainen wrote:

> Steven D'Aprano writes:
> 
> [in response to my attempt to understand "steep learning curve"]
> 
>> "Learning curve" or "experience curve" is not just an metaphor, it is
>> an actual technical term. See the Wikipedia article:
>>
>> https://en.wikipedia.org/wiki/Learning_curve
>>
>>
>> Now, there are a couple of ways that we can interpret the idiom of
>> "steep learning curve". One is the way Wikipedia interprets it: as a
>> mistake.
> 
> [- -]
> 
> Ouch. Next time I hear anyone use the phrase, if I need to know whether
> they mean "easy to learn" or "hard to learn" or something else, I think
> I'll ask them...

You really don't need to. "Steep learning curve" in ordinary English ALWAYS
means that it is hard to make progress and then gets easier once you have
mastered it. Its a common idiom.

If you're talking to an actual expert in the field about an actual graph,
then it might be worth asking them what they mean. And the chances are they
will mean exactly the same thing as ordinary people, and they'll just
say "turn your head to the side, see how steep the graph is at the start".

That's my prediction.



-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Antoon Pardon]

Op 15-07-16 om 15:38 schreef Jussi Piitulainen:
> Antoon Pardon writes:
>
>> No, that is what people come up with afterwards. If you just start a
>> conversation about how people learn and how long it would take to get
>> some mastery and how we could present progress in a graph, virtually
>> everyone uses the conventional axes layout. This talk about swapped
>> axes only come from people who used the steep learning curve metaphor,
>> when you then try to show them what an actual steep learning curve
>> implies.
> Or from people who try to be charitable when other people use it. At
> least I like to think that that's what I did.

Sure, you can be charitable when other people use it. IME that doesn't
contradict that when you somehow find yourself in need of actually
graphing these kind of numbers you are likely to follow the conventional
layout.

-- 
Antoon Pardon.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Antoon Pardon]

Op 15-07-16 om 15:39 schreef Random832:
>
> On Fri, Jul 15, 2016, at 07:44, Antoon Pardon wrote:
>
>> No, that is what people come up with afterwards. If you just start a
>> conversation about how people learn and how long it would take to get
>> some mastery and how we could present progress in a graph, virtually
>> everyone uses the conventional axes layout.
> _Why_ do you think this? The natural way to graph progress vs effort is
> to have progress on the horizontal access and effort on the vertical
> axis, because that's what you get when you're climbing a literal hill,
> the only context in the universe where "vertical" and "horizontal"
> aren't arbitrarily assigned but are real spatial dimensions.

No that is not the natural way. That is the way you pick afterwards if
you want your graph to resemble the metaphor. But it is not the way
people "naturally" graph these numbers, if the metafor was not put
into their head in first place. Certainly not people who actually study
these kind of things.

> The only reason to do it the other way is an association with time and
> the convention of using time for the horizontal axis.

No the reason is, we prefer the graph to be a function. That is for every x
at most one y. Using the axes the other way around would mean that set backs
would result in multiple y values for the same x.

-- 
Antoon Pardon.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Jussi Piitulainen]

Antoon Pardon writes:

> No, that is what people come up with afterwards. If you just start a
> conversation about how people learn and how long it would take to get
> some mastery and how we could present progress in a graph, virtually
> everyone uses the conventional axes layout. This talk about swapped
> axes only come from people who used the steep learning curve metaphor,
> when you then try to show them what an actual steep learning curve
> implies.

Or from people who try to be charitable when other people use it. At
least I like to think that that's what I did.

(I'm not at all inclined to do that about certain other terms, but those
discussions are also not inclined to go anywhere.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Random832]

On Fri, Jul 15, 2016, at 07:44, Antoon Pardon wrote:

> No, that is what people come up with afterwards. If you just start a
> conversation about how people learn and how long it would take to get
> some mastery and how we could present progress in a graph, virtually
> everyone uses the conventional axes layout.

_Why_ do you think this? The natural way to graph progress vs effort is
to have progress on the horizontal access and effort on the vertical
axis, because that's what you get when you're climbing a literal hill,
the only context in the universe where "vertical" and "horizontal"
aren't arbitrarily assigned but are real spatial dimensions.

The only reason to do it the other way is an association with time and
the convention of using time for the horizontal axis.

> This talk about swapped axes only come from people who used the steep
> learning curve metaphor, when you then try to show them what an actual
> steep learning curve implies.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Jussi Piitulainen]

Antoon Pardon writes:

> Op 15-07-16 om 10:40 schreef Jussi Piitulainen:
>> Antoon Pardon writes:
>>
>>> Op 15-07-16 om 08:06 schreef Marko Rauhamaa:
 Common usage among educated speakers ordinarily is the yardstick for
 language questions.
>>> But educated about what exactly?
>>>
>>> Each time someone talks about "a steep learning curve" in order to
>>> indicate something is difficult to master, he is using it wrong,
>>> because actual steep learning curves indicate something can be
>>> mastered quickly.
>>>
>>> Now I suspect most people who talk about steep learning curves are
>>> educated, they just aren't educated about learning curves and so I
>>> think common usage among educated speakers is inadequate as a yard
>>> stick.
>> I think I see your point, but I think it's also easy to think the axes
>> of the metaphor so that it makes sense:
>>
>> c  ,
>> o ,
>> s,
>> t . .
>>  l e a r n i n g
>
> Only for someone who is not very familiar with how we graphically
> represent results. The cost/effort is always put on the X-ax because
> that is what we directly control and also because that is what always
> increases. You can't unspent time in trying to master something. We
> make this choice because we want a mathematical function.
>
> What if you have a set back? How do you show that on your graph?

Nice points, thank you. You may be simply right on this, and I may have
learnt something.

> Ask people if they prefer a steep or shallow pay check curve. Most
> seem very quick in choosing for the steep curve.

I'm not at all sure how I would answer. By asking what is meant?
Because to me it sounds like a trick question to begin with.

There's an old story they tell in my family about a child who begs for
bread from a house. The lady of the house asks if they want a one-hand
slice (yhe käe leipä) or a two-hand slice (kahe käe leipä), and when the
poor hungry child asks for the two-hand slice, they get a slice so thin
that it needs to be held with both hands. That's mean.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue27519] update the references to http://mercurial.selenic.com

[Berker Peksag]

Changes by Berker Peksag :


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

[issue27519] update the references to http://mercurial.selenic.com

[Berker Peksag]

Berker Peksag added the comment:

Thanks!

--
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior

___
Python tracker 

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

[issue27519] update the references to http://mercurial.selenic.com

[Roundup Robot]

Roundup Robot added the comment:

New changeset 2edae149e8c5 by Berker Peksag in branch 'default':
Issue #27519: Update Mercurial links to mercurial-scm.org
https://hg.python.org/devguide/rev/2edae149e8c5

--
nosy: +python-dev

___
Python tracker 

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

Re: Curious Omission In New-Style Formats

[Jussi Piitulainen]

Steven D'Aprano writes:

[in response to my attempt to understand "steep learning curve"]

> "Learning curve" or "experience curve" is not just an metaphor, it is
> an actual technical term. See the Wikipedia article:
>
> https://en.wikipedia.org/wiki/Learning_curve
>
>
> Now, there are a couple of ways that we can interpret the idiom of
> "steep learning curve". One is the way Wikipedia interprets it: as a
> mistake.

[- -]

Ouch. Next time I hear anyone use the phrase, if I need to know whether
they mean "easy to learn" or "hard to learn" or something else, I think
I'll ask them...

Thanks.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue27518] small typo error in Grammar/Grammar

[Roundup Robot]

Roundup Robot added the comment:

New changeset db5a5679a9de by Berker Peksag in branch '3.5':
Issue #27518: Fix typo in Grammar/Grammar
https://hg.python.org/cpython/rev/db5a5679a9de

New changeset bae0d7389e96 by Berker Peksag in branch 'default':
Issue #27518: Merge from 3.5
https://hg.python.org/cpython/rev/bae0d7389e96

--
nosy: +python-dev

___
Python tracker 

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

[issue27518] small typo error in Grammar/Grammar

[Berker Peksag]

Berker Peksag added the comment:

Thanks, Stéphane.

--
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
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

[issue27515] Dotted name re-import does not rebind after deletion

[Terry J. Reedy]

Terry J. Reedy added the comment:

I am pursuing 1. for 3.6.  The first patch, moving 4 objects from pyshell to 
run and an import from run to pyshell, reduced a bloated len(sys.modules) from 
193 to 156. I hope to get under 100.  I will test 2., separately for each 
affected tkinter module, for 2.7 and 3.5.

--

___
Python tracker 

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

Vulture 0.10 released

[Jendrik Seipp]

vulture - Find dead code


Vulture finds unused classes, functions and variables in your code.
This helps you cleanup and find errors in your programs. If you run it
on both your library and test suite you can find untested code.

Due to Python's dynamic nature, static code analyzers like vulture are
likely to miss some dead code. Also, code that is only called
implicitly may be reported as unused. Nonetheless, vulture can be a
very helpful tool for higher code quality.


Download

http://pypi.python.org/pypi/vulture


Features

* fast: uses static code analysis
* lightweight: only one module
* tested: tests itself and has 100% test coverage
* complements *pyflakes* and has the same output syntax
* supports Python 2.6, 2.7 and 3.x


News

* Detect unused function and method arguments (issue #15).
* Detect unused *args and **kwargs parameters.
* Change license from GPL to MIT.


Cheers,
Jendrik





--
https://mail.python.org/mailman/listinfo/python-announce-list

   Support the Python Software Foundation:
   http://www.python.org/psf/donations/

[issue15988] Inconsistency in overflow error messages of integer argument

[Terry J. Reedy]

Terry J. Reedy added the comment:

At this point in time, I have nothing further to add.  So follow Serhiy's 
advice.

--

___
Python tracker 

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

Re: math.frexp

[Chris Angelico]

On Fri, Jul 15, 2016 at 9:39 PM, Steven D'Aprano  wrote:
> py> from math import frexp
> py> x = 2.5
> py> y = 3.5
> py> x*y
> 8.75
> py> m1, e1 = math.frexp(x)
> py> m2, e2 = math.frexp(y)
> py> m1*m2 * 2.0**(e1 + e2)
> 8.75
>
>
> Looks good to me. So let's try a less naive version of product():
>
>
> def product_scaled(values):
> scale = 0
> prod = 1.0
> for a in values:
> m1, e1 = math.frexp(a)
> m2, e2 = math.frexp(prod)
> scale += (e1 + e2)
> prod *= (m1*m2)
> return (prod * 2.0**scale)
>
>
> py> product_scaled([2.5, 3.5])  # expected 8.75
> 2.734375
>

You're chaining your product twice. (Also your scale, although that
appears to be correct.) Changing it to "prod = m1 * m2" gives 8.75.

But what do you gain by this? You're still stuffing the result back
into a float at the end, so all you do is change from getting
float("inf") to getting OverflowError. How can you make it not
overflow?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Curious Omission In New-Style Formats

[Antoon Pardon]

Op 15-07-16 om 12:56 schreef Steven D'Aprano:
> On Fri, 15 Jul 2016 06:40 pm, Jussi Piitulainen wrote:
>
>> Antoon Pardon writes:
>>
>>> Op 15-07-16 om 08:06 schreef Marko Rauhamaa:
 Common usage among educated speakers ordinarily is the yardstick for
 language questions.
>>> But educated about what exactly?
>>>
>>> Each time someone talks about "a steep learning curve" in order to
>>> indicate something is difficult to master, he is using it wrong,
>>> because actual steep learning curves indicate something can be
>>> mastered quickly.
> That's not necessarily the case. See below.

I think it does.

>
> "Learning curve" or "experience curve" is not just an metaphor, it is an
> actual technical term. See the Wikipedia article:
>
> https://en.wikipedia.org/wiki/Learning_curve

I know and the technical term precedes the metaphor.

> Remember that the English idiom of a steep learning curve is not just hard
> to learn. It means that something takes a lot of effort to gain mastery
> over, after which things become easier.

Yes things/practicing become easier, mastering even further does not.

> Here is a curve that matches the common idiom. It is (1) steep, (2) requires
> a lot of effort for very little progress at the beginning, and (3) becomes
> easier with time:
>
>
> K   x
> n  x
> o x
> w   x
> l x 
> e  x
> d  x
> g x
> e
> + Effort or cost or time

I think you are making things up now. I have never seen an actual learning
curve with that shape. All learning curves I have seen show the law of
diminishing (marginal) returns.

> Another way to interpret it is to ask, what's the *cost* (in time, or
> effort) to gain a certain amount of knowledge? That's equivalent to
> swapping the X and Y axes:

Which you don't expect because if swapping axes was common, most people
would understand that talking about steep or shallow curves would be
meaningless since you wouldn't know whether is was steep with standaard
ax positions or steep with swapped ax posititions.

>
> Cx
> o   x
> sx
> t
> ·  x
> o
> r
> ·
> t x
> i
> m
> e
> + Knowledge gained
>
>
>
> That's not the conventional layout of the axis, but it does make sense, and
> it's more likely that people have this reversed layout in mind when
> thinking about "steepness of learning" than it is that they were thinking
> about the original curve and misinterpreting the meaning of the gradient.

No, that is what people come up with afterwards. If you just start a 
conversation
about how people learn and how long it would take to get some mastery and how we
could present progress in a graph, virtually everyone uses the conventional axes
layout. This talk about swapped axes only come from people who used the steep
learning curve metaphor, when you then try to show them what an actual steep
learning curve implies.

-- 
https://mail.python.org/mailman/listinfo/python-list

math.frexp

[Steven D'Aprano]

I'm experimenting with various implementations of product(values). Here's a
naive version that easily suffers from overflow:

from functools import reduce
from operator import mul

def product_naive(values):
return reduce(mul, values)


py> product_naive([2, 4, 5])
40
py> product_naive([1e200, 1e200, 1e200])
inf


So I started experimenting with math.frexp, but I'm having trouble
understanding what I'm doing wrong here.


Help on built-in function frexp in module math:

frexp(...)
frexp(x)

Return the mantissa and exponent of x, as pair (m, e).
m is a float and e is an int, such that x = m * 2.**e.
If x is 0, m and e are both 0.  Else 0.5 <= abs(m) < 1.0.



If x and y are both floats, then given:

m1, e1 = math.frexp(x)
m2, e2 = math.frexp(y)

Then x*y = m1*m2 * 2.0**(e1 + e2). We can test that:


py> from math import frexp
py> x = 2.5
py> y = 3.5
py> x*y
8.75
py> m1, e1 = math.frexp(x)
py> m2, e2 = math.frexp(y)
py> m1*m2 * 2.0**(e1 + e2)
8.75


Looks good to me. So let's try a less naive version of product():


def product_scaled(values):
scale = 0
prod = 1.0
for a in values:
m1, e1 = math.frexp(a)
m2, e2 = math.frexp(prod)
scale += (e1 + e2)
prod *= (m1*m2)
return (prod * 2.0**scale)


py> product_scaled([2.5, 3.5])  # expected 8.75
2.734375



What am I doing wrong?




-- 
Steven
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list