[issue31506] Improve the error message logic for object_new & object_init

[Nick Coghlan]

Nick Coghlan added the comment:

Those would both report "C() takes no parameters" without further enhancements 
(which would be out of scope for this issue).

The proposed improvement here isn't "Let's make the error message exactly 
correct in all cases" (that's probably impossible, since we've lost relevant 
information by the time the argument processing happens).

Instead, it's "let's make the error message more helpful in the most common 
case for beginners, and let the folks performing the more advanced operation of 
calling __new__ directly do the translation if they need to"

--

___
Python tracker 

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

[issue13224] Change str(x) to return only the qualname for some types

[Nick Coghlan]

Nick Coghlan added the comment:

Specifically this message, where the unwritten rationale is to offer 
behavioural consistency across the builtin types that know their own name and 
include it in their current repr() output: 
https://mail.python.org/pipermail/python-ideas/2011-October/012464.html

As per Guido's comment and the discussion of PEP 3155 above, the idea now is 
that for classes/functions/methods, we make it so that:

repr(x) -> gives both the type and the qualified name (as now)
str(x) -> gives just the qualified name

Importantly, this *won't* change the result of printing full namespaces, since 
the dict repr calls repr() on values, not str().

--
nosy: +ncoghlan

___
Python tracker 

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

[issue21937] IDLE interactive window doesn't display unsaved-indicator

[Terry J. Reedy]

Terry J. Reedy added the comment:

The 'follow-on' issue is #23666.

--

___
Python tracker 

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

[issue31498] Default values for zero in time.strftime()

[Denis Osipov]

Denis Osipov added the comment:

It seems strange to me that time.strftime() returns formatted date with wrong 
day of week and day of year values. So, I think it's probably a bug.
But I'm just learning Python and programming and I think that it can be 
intentional behavior.
If it's a bug I'd like to try to fix it. Otherwise could someone tell me why 
this behavior is OK?

--

___
Python tracker 

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

[issue13224] Change str(x) to return only the qualname for some types

[Guido van Rossum]

Guido van Rossum added the comment:

For modules, __name__ is the fully-qualified name, and that's fine.

But for classes and functions __name__ is just the "given name" from the syntax 
(whatever came after 'def' or 'class') and that's not fine -- for anything 
except builtins where we do this I would like the str() to produce the 
fully-qualified name.

I presume by "functions" you mean only things defined with 'def' and excluding 
bound methods?

--

___
Python tracker 

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

[issue23666] Add shell session logging option to IDLE

[Grant Jenks]

Grant Jenks added the comment:

+1 from me. I'd like to see it ask me to save when I close the window if I've 
already saved once.

--
nosy: +grantjenks

___
Python tracker 

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

[issue31514] There is a problem with the setdefault type conversion in the tuple

[sk xing]

New submission from sk xing:

The setdefault method of the tuple allows the introduction of custom data 
types.At this point, the __repr__ method is implemented so that the returned 
data type has an error.The type of str is returned, but the int type is written 
to the tuple.Also, write str without quotation marks.
Look at the demo.py in the attachment

--
components: Windows
files: demo.py
messages: 302497
nosy: paul.moore, sk xing, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: There is a problem with the setdefault type conversion in the tuple
versions: Python 3.6
Added file: https://bugs.python.org/file47151/demo.py

___
Python tracker 

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

[issue13224] Change str(x) to return only the qualname for some types

[Éric Araujo]

Éric Araujo added the comment:

(Nick and Guido! «My proposal is to make str(x) return x.__name__ for exactly 
these three types of objects: modules, classes, and functions.»)

--

___
Python tracker 

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

[issue13224] Change str(x) to return only the qualname for some types

[Éric Araujo]

Éric Araujo added the comment:

Martin Panter

> I’m a bit confused. In the current patch, the new type_str() function
> appears to use the “qualname” (which I support), but some of the test
> changes seem to contradict this, e.g.:

>  >>> C.foo(1)
> -classmethod  1
> +classmethod C 1

C is a qualname, as would be C.NestedD or something..NestedD
The qualname PEP explains why the module is not part of the qualname.


Me
> Finally, I don’t remember why I changed functions and modules when the two
> original use cases were only for classes.

The reason is a message by Nick on python-ideas.

--

___
Python tracker 

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

[issue31512] Add non-elevated symlink support for dev mode Windows 10

[Eryk Sun]

Eryk Sun added the comment:

Py_CreateSymbolicLinkW can be removed in 3.5+ because Windows XP is no longer 
supported and calling enable_symlink() is pointless. 

The Windows API uses some privileges simply to determine which security 
principals can access a capability. Whether the privilege is currently enabled 
or disabled in the current access token doesn't matter because functions 
automatically enable it for the current thread (in an impersonation token). 

In this case, CreateSymbolicLink calls RtlAcquirePrivilege to enable 
SeCreateSymbolicLinkPrivilege for the current thread; sets the symlink reparse 
point; and then reverts the current thread via RtlReleasePrivilege. It goes 
through these same steps whether or not the privilege is already enabled in the 
process, so there's no chance of a race condition between competing threads.

Also, as a side note, the linked blog makes the following claim, which paints 
an incomplete picture:

> However, for Windows users, due to Windows Vista’s security 
> requirements, users needed local admin rights and, importantly, 
> had to run mklink in a command-line console elevated as 
> administrator to create/modify symlinks. 

SeCreateSymbolicLinkPrivilege can be added to a standard user account, and it 
doesn't get filtered out from the user's token. So in general you do not need 
administrator access. However, the above is describing the case for most 
developers, who use a administrator account that's subject to UAC restrictions.

--
nosy: +eryksun

___
Python tracker 

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

[issue31447] proc communicate not exiting on python subprocess timeout using PIPES

[Eryk Sun]

Eryk Sun added the comment:

> when I said "also with close_fds=True", I meant that I tried 
> WITHOUT overriding stdin, stdout, and stderr AND setting 
> close_fds=True, but it didn't work. 

Console applications (e.g. python.exe) duplicate their standard handles into a 
child console process when the bInheritHandles argument of CreateProcess is 
false, i.e. when subprocess.Popen is called with the default close_fds=True. We 
know it's duplication instead of inheritance because the actual handle values 
change and also because it doesn't matter whether or not the standard handles 
are flagged as inheritable in the creating process. In the typical case this 
ensures that console processes have valid standard handles. 

However, if you make the standard handles non-inheritable in the parent and 
also inherit handles when creating the child, then the parent's standard 
handles will be neither inherited nor duplicated. The child will still inherit 
the standard handle *values* from the parent (i.e. copied from the parent's PEB 
ProcessParameters). These handle values will be invalid. Either the handle 
won't be defined, or it will reference an arbitrary, unrelated kernel object.

> What worked was not overriding stdin/out/err and adding
>
> os.set_inheritable(0, False)
> os.set_inheritable(1, False)
> os.set_inheritable(2, False)
>
> before the call (no need to set close_fds)

In this case cmd.exe gets duplicated standard handles, but you've flagged these 
handles as non-inheritable. When cmd.exe calls CreateProcess to execute 
waitfor.exe, it uses bInheritHandles=TRUE. Consequently, its non-inheritable 
standard handles are neither inherited by nor duplicated to waitfor.exe. Let's 
attach a debugger to the waitfor.exe process and examine the standard handle 
values in its PEB ProcessParameters:

0:003> ?? @$peb->ProcessParameters->StandardInput
void * 0x`0008
0:003> !handle 8
Handle 8
  Type  Event

0:003> ?? @$peb->ProcessParameters->StandardOutput
void * 0x`000c
0:003> !handle c
Handle c
  Type  WaitCompletionPacket

0:003> ?? @$peb->ProcessParameters->StandardError
void * 0x`0010
0:003> !handle 10
Handle 10
  Type  IoCompletion

waitfor.exe doesn't care that its standard handle values reference non-File 
objects, i.e. an Event, a WaitCompletionPacket, and an IoCompletion port. 
However, what if by coincidence one of its standard handle values is actually a 
valid File handle that's inherited for some other reason? That would be a right 
mess. That's why I suggested overriding the standard handles to the NUL device. 
For example:

import subprocess

script = r'''
import os
import subprocess

os.set_inheritable(0, False)
os.set_inheritable(1, False)
os.set_inheritable(2, False)

cmdline = 'cmd.exe /s /c waitfor.exe signal /t 200'
subprocess.run(cmdline, timeout=4, stdin=subprocess.DEVNULL,
stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
'''

args = ['python.exe', '-c', script]
proc = subprocess.Popen(args, encoding='ansi', stdin=subprocess.PIPE,
stdout=subprocess.PIPE, stderr=subprocess.PIPE)

proc_out, proc_err = proc.communicate(timeout=20)
print('proc_out:', proc_out)
print('proc_err:', proc_err)

--

___
Python tracker 

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

[issue31370] Remove support for threads-less builds

[Antoine Pitrou]

Antoine Pitrou added the comment:


New changeset 88c60c9668f0aa732693517a60b851cc1dfce0cb by Antoine Pitrou in 
branch 'master':
Trivial cleanups following bpo-31370 (#3649)
https://github.com/python/cpython/commit/88c60c9668f0aa732693517a60b851cc1dfce0cb


--

___
Python tracker 

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

[issue24243] behavior for finding an empty string is inconsistent with documentation

[R. David Murray]

R. David Murray added the comment:

I'm not Raymond, but he is correct.  This is an example of "taking advantage of 
the corner cases", and is something Python does a lot of, especially around 
strings and slices.  The current behavior was carefully considered and has 
useful properties.

--

___
Python tracker 

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

[issue31370] Remove support for threads-less builds

[Steve Gomez]

Steve Gomez added the comment:

Oracle Binary Code License Agreement for the Java SE Platform Products and 
JavaFX  ORACLE AMERICA, INC. ("ORACLE"), FOR AND ON BEHALF OF ITSELF AND ITS 
SUBSIDIARIES AND AFFILIATES UNDER COMMON CONTROL, IS WILLING TO LICENSE THE 
SOFTWARE TO YOU ONLY UPON THE CONDITION THAT YOU ACCEPT ALL OF THE TERMS  
CONTAINED IN THIS BINARY CODE LICENSE AGREEMENT AND SUPPLEMENTAL LICENSE TERMS 
(COLLECTIVELY "AGREEMENT").  PLEASE READ THE AGREEMENT CAREFULLY.  BY SELECTING 
THE "ACCEPT LICENSE AGREEMENT" (OR THE EQUIVALENT) BUTTON AND/OR BY USING THE 
SOFTWARE YOU ACKNOWLEDGE THAT YOU HAVE READ THE TERMS AND AGREE TO THEM.  IF 
YOU ARE AGREEING TO THESE TERMS ON BEHALF OF A COMPANY OR OTHER LEGAL ENTITY, 
YOU REPRESENT THAT YOU HAVE THE LEGAL AUTHORITY TO BIND THE LEGAL ENTITY TO 
THESE TERMS.  IF YOU DO NOT HAVE SUCH AUTHORITY, OR IF YOU DO NOT WISH TO BE 
BOUND BY THE TERMS, THEN SELECT THE "DECLINE LICENSE AGREEMENT" (OR THE 
EQUIVALENT) BUTTON AND YOU MUST NOT USE THE SOFTWARE ON THIS SITE OR ANY OTHER 
MEDIA ON WHICH THE SOFTWARE IS CONTAINED.  1.  DEFINITIONS.  "Software" means 
the software identified above in binary form that you selected for download, 
install or use (in the version You selected for download, install or use) from 
Oracle or its authorized licensees, any other machine readable materials 
(including, but not limited to, libraries, source files, header files, and data 
files), any updates or error corrections provided by Oracle, and any user 
manuals, programming guides and other documentation provided to you by Oracle 
under this Agreement.  "General Purpose Desktop Computers and Servers" means 
computers,  including desktop and laptop computers, or servers, used for 
general  computing functions under end user control (such as but not 
specifically  limited to email, general purpose Internet browsing, and office 
suite  productivity tools).  The use of Software in systems and solutions that 
provide dedicated functionality (other than as mentioned above) or designed  
for use in embedded or function-specific software applications, for example but 
not limited to: Software embedded in or bundled with industrial control 
systems, wireless mobile telephones, wireless handheld devices, kiosks, TV/STB, 
Blu-ray Disc devices, telematics and network control switching equipment, 
printers and storage management systems, and other related systems are excluded 
from this definition and not licensed under this  Agreement.  "Programs" means 
(a) Java technology applets and applications  intended to run on the Java 
Platform, Standard Edition platform on Java-enabled General Purpose Desktop 
Computers and Servers; and (b) JavaFX technology applications intended to run 
on the JavaFX Runtime on JavaFX-enabled General Purpose Desktop Computers and 
Servers.  “Commercial Features” means those features identified in Table 1-1 
(Commercial Features In Java SE Product Editions) of the Java SE documentation 
accessible at  
http://www.oracle.com/technetwork/java/javase/documentation/index.html.  
“README File” means the README file for the Software accessible at 
http://www.oracle.com/technetwork/java/javase/documentation/index.html.  2.  
LICENSE TO USE.  Subject to the terms and conditions of this Agreement   
including, but not limited to, the Java Technology Restrictions of the  
Supplemental License Terms, Oracle grants you a non-exclusive, 
non-transferable, limited license without license fees to reproduce and use 
internally the Software complete and unmodified for the sole purpose of  
running Programs.  THE LICENSE SET FORTH IN THIS SECTION 2 DOES NOT EXTEND TO 
THE COMMERCIAL FEATURES.  YOUR RIGHTS AND OBLIGATIONS RELATED TO THE COMMERCIAL 
FEATURES ARE AS SET FORTH IN THE SUPPLEMENTAL TERMS ALONG WITH ADDITIONAL 
LICENSES FOR DEVELOPERS AND PUBLISHERS.

--
nosy: +Steve Gomez

___
Python tracker 

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

[issue24243] behavior for finding an empty string is inconsistent with documentation

[Antoine Pitrou]

Antoine Pitrou added the comment:

I'm not sure why we're arguing over this.  Is this actually something that 
matters in the real world?

--

___
Python tracker 

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

[issue24243] behavior for finding an empty string is inconsistent with documentation

[Vedran Čačić]

Vedran Čačić added the comment:

Raymond, with respect, I think you're either wrong here, or misleading with a 
purpose.

There is a big difference between any(()) returning False, all(()) returning 
True, '' in '' returning True, math.factorial(0) returning 1,  and set() <= 
set() returning True, on one hand, and ''.rindex('') returning 5, on the other. 
You might argue the latter is convenient (though I haven't seen any argument in 
favor of that), but it's simply not in the same category as other phenomena 
you're equating it with.

Those in the first group are mathematical definitions. They cannot be different 
without breaking various mathematical properties. 0! is 1 in the same way, and 
with the same reason, that 3! is 6. If 0! were 5, then 3! would _have_ to be 
30. Both the specification (as the order of the symmetry group), and various 
algorithms for calculating factorial, simply give 1 when given 0 as an input. 
You can't really get 5 unless you explicitly treat 0 as a special case.

In the second group, there is an answer that might be convenient, and it 
probably has some obvious algorithm that produces it (I haven't read the code, 
but I doubt that someone treated '' as a special case there), but it doesn't 
fit the specification (maximal index doesn't exist), and you can easily write 
another algorithm that doesn't obviously treat '' as a special case, gives the 
same answers for all the other "sensible" cases, and gives something completely 
different for this case. The proof is that in many very similar cases, those 
different algorithms _have_ (inadvertently) been written.

One question is _whether_ '' is in some other string. Quite another is _where_ 
it is. First one is (greatly simplified, since it doesn't require 
contiguousness) all(c in other_string for c in ''), and that's obviously True 
for the same reason that set() <= any_set is True. But all(1/0 for c in '') is 
_also_ True, which shows that it really doesn't matter _what_ we test, as long 
as we test it on an empty collection. It shouldn't give us (by design) _any_ 
information that we can extract about "that particular occurence of ''" because 
there is in fact _no_ particular occurence to talk about.

In the face of ambiguity, refuse the temptation to guess. Yes, I see the 
convenience of not rasing ValueErrors for various string operations so some 
algorithms can say "ok, give me any value in case of '', I don't really care 
what it is", but we already do raise it for some operations - e.g. when 
splitting on an empty separator. We should do the same here. Either change the 
specification, or if the specification tells you to calculate something that 
doesn't exist, raise an exception.

--
nosy: +veky

___
Python tracker 

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

[issue31485] Tkinter widget.unbind(sequence, funcid) unbind all bindings

[Juliette Monsel]

Juliette Monsel added the comment:

I don't mind writing a patch and opening a pull request, however I don't know 
which corner cases I need to take into account.

--

___
Python tracker 

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

[issue21622] ctypes.util incorrectly fails for libraries without DT_SONAME

[Richard Eames]

Changes by Richard Eames :


--
nosy: +Richard Eames

___
Python tracker 

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

[issue31513] Document structure of memo dictionary to enable more advanced __deepcopy__ uses

[R. David Murray]

R. David Murray added the comment:

Unless I'm mistaken (and someone will correct me and reopen the issue if I am 
:) it is intentionally undocumented.  A proposal for a documented protocol of 
some sort is certainly a possibility, but is something that should start with a 
discussion on the python-ideas mailing list.

--
nosy: +r.david.murray
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

[issue31513] Document structure of memo dictionary to enable more advanced __deepcopy__ uses

[Josh Rosenberg]

New submission from Josh Rosenberg:

At present, the documentation for the copy module doesn't document anything 
about the memo dictionary for deepcopy except to say that it must be received 
by custom __deepcopy__ methods and passed along when calling copy.deepcopy, and 
that it is a "dictionary of objects already copied during the current copying 
pass", without specifying what the keys or values are.

Without providing a documented meaning for the keys and values in the memo 
dict, it's impossible to use it in a supported way for more complex cases (e.g. 
a case where the object must be created partially and memoized prior to 
deepcopying attributes that can self-reference). For an example, see this 
StackOverflow answer's approach to using __deepcopy__: 
https://stackoverflow.com/a/46284091/364696

Officially, the line where it does:

memo[id(self)] = newself = self.__class__(copy.deepcopy(self.id, memo))

is not using documented behavior AFAICT; the fact that the memo dict maps 
id()'s of the original objects to the new instance is undocumented. This 
wouldn't be so bad if there were a documented way to achieve the desired 
result, but in recursive cases like these it's the only way to add deepcopy 
support without also adding pickle support.

I'd suggest documenting the current behavior, assuming the current behavior is 
consistent on all alternate Python implementations; I know id() is a little 
funky elsewhere, but I'm not sure there is any other sane implementation.

--
assignee: docs@python
components: Documentation
messages: 302485
nosy: docs@python, josh.r
priority: normal
severity: normal
status: open
title: Document structure of memo dictionary to enable more advanced 
__deepcopy__ uses

___
Python tracker 

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

[issue31370] Remove support for threads-less builds

[Antoine Pitrou]

Antoine Pitrou added the comment:


New changeset b43c4caf81b10e5c7ebaeb3a712c6db584f60bbd by Antoine Pitrou in 
branch 'master':
Restore dummy_threading and _dummy_thread, but deprecate them (bpo-31370) 
(#3648)
https://github.com/python/cpython/commit/b43c4caf81b10e5c7ebaeb3a712c6db584f60bbd


--

___
Python tracker 

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

[issue31170] Update to expat 2.2.4 (expat: utf8_toUtf8 cannot properly handle exhausting buffer)

[Ned Deily]

Ned Deily added the comment:

I believe all the branches except 3.5 and 3.4 have been updated so adjusting 
the Versions field accordingly.  All yours, Larry!

--
stage: patch review -> commit review
versions:  -Python 3.3, 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

[issue31151] socketserver.ForkingMixIn.server_close() leaks zombie processes

[Ned Deily]

Changes by Ned Deily :


--
priority: release blocker -> deferred blocker

___
Python tracker 

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

[issue31233] socketserver.ThreadingMixIn leaks running threads after server_close()

[Ned Deily]

Changes by Ned Deily :


--
priority: release blocker -> deferred blocker

___
Python tracker 

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

[issue31512] Add non-elevated symlink support for dev mode Windows 10

[Vidar Fauske]

New submission from Vidar Fauske:

As explained in this Microsoft blogpost 
(https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/), it is 
possible on newer versions of Windows 10 for non-privileged users to create 
symlinks when the machine is in developer mode. However, to ensure backwards 
compatibility, this behavior requires a flag to be passed to the 
CreateSymbolicLink function.

I think this is something that Python can benefit from having. It would go from 
"symlinks on Windows rarely work" to "symlinks on Windows work in developer 
mode (and rarely otherwise)".

I've attached a proof of concept patch to enable this behavior (a Windows 10 
machine with the 'Creators Update' is required to test it). In summary, it 
enables the flag by default, and updates enable_symlink to prevent lacking 
privilege from disabling symlinks on machines in developer mode.

--
components: Library (Lib), Windows
files: devsymlink.patch
keywords: patch
messages: 302482
nosy: paul.moore, steve.dower, tim.golden, vidartf, zach.ware
priority: normal
severity: normal
status: open
title: Add non-elevated symlink support for dev mode Windows 10
type: enhancement
versions: Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47150/devsymlink.patch

___
Python tracker 

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

[issue31484] Cache single-character strings outside of the Latin1 range

[Antoine Pitrou]

Antoine Pitrou added the comment:

Judging by the numbers, this optimization does not sound worth the hassle.  It 
is quite rare to iterate over all characters in a long text while doing so 
little work with them that the cost of iteration is significant.

By the way:

> Sorry for using the word hieroglyphs for Chinese characters. I didn't know 
> how they are named in English.

I think the word you were looking for is "ideogram".

--
nosy: +pitrou

___
Python tracker 

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

[issue31440] wrong default module search path in help message

[Steve Dower]

Steve Dower added the comment:

I don't have time right this second to write it all up, but I did so in the 
past at https://docs.python.org/3/using/windows.html#finding-modules

Hopefully the answer you need is somewhere in that. Module search paths are 
complicated (but eric.snow is going to make it possible to use Python code to 
derive the search path at startup... right Eric? Right? :) )

--
nosy: +eric.snow

___
Python tracker 

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

[issue31036] building the python docs requires the blurb module

[Ned Deily]

Ned Deily added the comment:

P.S. I just noticed that I forgot to credit Brett here as the source (from 
superseded PR 2953) of a good portion of the last round of PRs.  Thanks!

--

___
Python tracker 

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

[issue31496] IDLE: test_configdialog failed

[Terry J. Reedy]

Terry J. Reedy added the comment:

If the test only fails with a HiDPI screen, then it must somehow be related.  
But if the highlight sample is normal size, like the font sample in
https://bugs.python.org/file47141/Screenshot_20170917_213616.png
then the relationship must not be as simple as I was thinking.

--

___
Python tracker 

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

[issue31500] IDLE: Tiny font on HiDPI display

[Terry J. Reedy]

Terry J. Reedy added the comment:

Thank you Cheryl.  That is enough to reject the patch is it is now.

The negative sizes are pixels.  I think it might be better to multiply them by 
a systems specific factor, but only when needed.

One might wish that the scaling should be handled automatically, in tkinter if 
not in tk itself.  But it was mentioned in one of the links that displays do 
not always report their dpi correctly.

One possibility is a tkinter calibration app that displays a 500 or 1000 pixel 
line (user selects) and asks the user to input the physical length (centimeters 
or inches).  (Some games do something similar with brightness.)

To check whether a tkinter scaling app could be used, I sized Serhiy's image so 
that the sample font in the Settings Font tab matched the sample font in a real 
box.  The system font around it is tiny but readable, especially with a 
magnifier.

This is a tkinter issue, not only an IDLE issue, but IDLE is a good test app, 
with realistically complex dialogs. Lacking a Python-wide fix, something could 
be added to the Font tab -- for instance a dpi multiplier that defaults to one. 
 It would only be used if not 1.0.

I reread config.IdleConf.GetFont.  Rather than manipulate one of tk's default 
fonts ('TkFixedFont'), it creates a normal font sized in points.  It uses 
'TkFixedFont' as a handy key for finding a system-specific sure-to-exist fixed 
pitch font: "actualFont = Font.actual(f)", where f is a TkFixedFont instance.  
Thus it does not affect the dialogs.

It would be helpful to know if HiDPI screens on Windows have a problem.

#31496 is about test_configdialog failing on the same HiDPI screen.

--

___
Python tracker 

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

[issue31370] Remove support for threads-less builds

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
pull_requests: +3642
stage: resolved -> patch review

___
Python tracker 

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

[issue31370] Remove support for threads-less builds

[Antoine Pitrou]

Antoine Pitrou added the comment:

https://github.com/python/cpython/pull/3648 restores dummy_threading and 
_dummy_thread, but deprecates them.

--
stage: patch review -> resolved

___
Python tracker 

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

[issue31370] Remove support for threads-less builds

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
keywords: +patch
pull_requests: +3641
stage: resolved -> patch review

___
Python tracker 

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

[issue30744] Local variable assignment is broken when combined with threads + tracing + closures

[Nathaniel Smith]

Nathaniel Smith added the comment:

Doesn't this proposal break every debugger, including pdb?

--

___
Python tracker 

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

[issue31370] Remove support for threads-less builds

[Antoine Pitrou]

Antoine Pitrou added the comment:

> eventlet also uses dummy_threading

Not sure what you mean by that.  eventlet uses the regular try/except import 
dance around "import threading":

https://github.com/eventlet/eventlet/blob/master/eventlet/support/dns/entropy.py#L20-L23
https://github.com/eventlet/eventlet/blob/master/eventlet/support/dns/resolver.py#L23-L26

As for portage, Arfrever fixed it :-)

https://gitweb.gentoo.org/proj/portage.git/commit/?id=504f66b0e25281e4465ebeceb799c3e54ff2b884

That said, I am not against bringing dummy_threading back, though it would 
sound rather weird to use it unconditionally...

--

___
Python tracker 

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

[issue31511] test_normalization: test.support.open_urlresource() doesn't handle urllib.error.URLError timeout

[STINNER Victor]

New submission from STINNER Victor:

http://buildbot.python.org/all/builders/AMD64%20Debian%20PGO%203.x/builds/1316/steps/test/logs/stdio

==
FAIL: test_main (test.test_normalization.NormalizationTest)
--
Traceback (most recent call last):
  File 
"/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.nondebug/build/Lib/urllib/request.py",
 line 1316, in do_open
encode_chunked=req.has_header('Transfer-encoding'))
socket.timeout: timed out

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File 
"/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.nondebug/build/Lib/test/test_normalization.py",
 line 42, in test_main
check=check_version)
urllib.error.URLError: 

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File 
"/var/lib/buildbot/slaves/enable-optimizations-bot/3.x.gps-debian-profile-opt.nondebug/build/Lib/test/test_normalization.py",
 line 47, in test_main
self.fail(f"Could not retrieve {TESTDATAURL}")
AssertionError: Could not retrieve 
http://www.pythontest.net/unicode/10.0.0/NormalizationTest.txt

--
components: Tests
messages: 302473
nosy: haypo
priority: normal
severity: normal
status: open
title: test_normalization: test.support.open_urlresource() doesn't handle 
urllib.error.URLError timeout
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

[issue31498] Default values for zero in time.strftime()

[R. David Murray]

R. David Murray added the comment:

Generally we're just reporting whatever the platform strftime does.  Is that 
what happens in this case?

--
nosy: +belopolsky, r.david.murray

___
Python tracker 

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

[issue31500] IDLE: Tiny font on HiDPI display

[Cheryl Sabella]

Changes by Cheryl Sabella :


Added file: https://bugs.python.org/file47149/configdialogkeys_new.png

___
Python tracker 

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

[issue31500] IDLE: Tiny font on HiDPI display

[Cheryl Sabella]

Changes by Cheryl Sabella :


Removed file: https://bugs.python.org/file47147/configdialog_new.png

___
Python tracker 

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

[issue31500] IDLE: Tiny font on HiDPI display

[Cheryl Sabella]

Changes by Cheryl Sabella :


Added file: https://bugs.python.org/file47148/configdialogkeys_old.png

___
Python tracker 

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

[issue31500] IDLE: Tiny font on HiDPI display

[Cheryl Sabella]

Cheryl Sabella added the comment:

Attached screen prints of configdialog.  It's messed up.

--
Added file: https://bugs.python.org/file47147/configdialog_new.png

___
Python tracker 

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

[issue30356] test_mymanager_context() of test_multiprocessing_spawn: manager._process.exitcode=-15 on x86 Windows7 3.x

[STINNER Victor]

STINNER Victor added the comment:

Similar issue: bpo-31510.

--

___
Python tracker 

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

[issue31510] test_many_processes() of test_multiprocessing_spawn failed on x86-64 Sierra 3.x

[STINNER Victor]

New submission from STINNER Victor:

The process was killed (SIGKILL).

See also bpo-30356.

http://buildbot.python.org/all/builders/x86-64%20Sierra%203.x/builds/765/steps/test/logs/stdio

==
FAIL: test_many_processes 
(test.test_multiprocessing_spawn.WithProcessesTestProcess)
--
Traceback (most recent call last):
  File 
"/Users/buildbot/buildarea/3.x.billenstein-sierra/build/Lib/test/_test_multiprocessing.py",
 line 505, in test_many_processes
self.assertEqual(p.exitcode, -signal.SIGTERM)
AssertionError: -9 != -15

--
components: Tests
messages: 302469
nosy: haypo
priority: normal
severity: normal
status: open
title: test_many_processes() of test_multiprocessing_spawn failed on x86-64 
Sierra 3.x
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

[issue31507] email.utils.parseaddr has no docstring

[R. David Murray]

R. David Murray added the comment:

Mark: re your training course...if you aren't trying to stay compatible with 
python2, note that python3 has a much more sophisticated address parser now, 
that gets called automatically if you use the new policies.

--
components: +email
nosy: +barry, r.david.murray

___
Python tracker 

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

[issue31509] test_subprocess hangs randomly on AMD64 Windows10 3.x

[STINNER Victor]

New submission from STINNER Victor:

http://buildbot.python.org/all/builders/AMD64%20Windows10%203.x/builds/1242/steps/test/logs/stdio

0:49:36 [401/405] test_osx_env passed
0:49:38 [402/405] test_fractions passed -- running: test_subprocess (31 sec)
0:49:51 [403/405] test_importlib passed -- running: test_subprocess (44 sec)
0:49:53 [404/405] test_pwd skipped -- running: test_subprocess (46 sec)
test_pwd skipped -- No module named 'pwd'

command timed out: 1200 seconds without output running 
['Tools\\buildbot\\test.bat', '-x64', '-j2', '--timeout', '900'], attempting to 
kill
program finished with exit code 1
elapsedTime=4198.024000

See also bpo-30885.

--
messages: 302467
nosy: haypo
priority: normal
severity: normal
status: open
title: test_subprocess hangs randomly on AMD64 Windows10 3.x
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

[issue31504] Documentation for return value for string.rindex is missing when search string is empty

[R. David Murray]

R. David Murray added the comment:

You have to remember that the most useful way to think about python slice 
indexes is that they point between characters. Consider, for example, that you 
have a starting index of something, and you are looking backward in the string 
for a trailing delimiter:

  >>> x = 'this is  of something'
  >>> x.rfind('>', 9)
  22
  >>> x[9:22]
  'weird example'

So the above is why 5 is different from 7: 5 is the index that you would use in 
a slice if you wanted the string that ended before the match...and the match in 
the null string case is the end of the string.  That is, Python is being 
consistent in this degenerate case.

--

___
Python tracker 

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

[issue31508] Running test_ttk_guionly logs "test_widgets.py:1562: UserWarning: Deprecated API of Treeview.selection() should be removed" warnings

[STINNER Victor]

STINNER Victor added the comment:

> This is a reminder to me to remove a deprecated API (see issue27319).

Running tests should not log deprecation warnings.

Either remove the code, or make the warning quiet, no? :-)

--

___
Python tracker 

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

[issue31500] IDLE: Tiny font on HiDPI display

[Cheryl Sabella]

Cheryl Sabella added the comment:

Tests run on Ubuntu.  The menubar is bigger now though, so it's default is
different than before.  Maybe that was the only way to fix it, but it's now
about twice as big as the shell font.

--

___
Python tracker 

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

[issue31500] IDLE: Tiny font on HiDPI display

[Terry J. Reedy]

Terry J. Reedy added the comment:

The TkFixedFont initially used in Shell and editor has its size set to 10 if 
initially negative. Users can only replace this with a real font, not another 
of tk's abstract fonts.

On windows, the sizes of the nearly 20 fonts touched by the patch range from 8 
to 12.  So no possible regression there.  If the sizes on Linux were in the 
range -8 to -12, then the effect is to replace the size with numbers around 10 
instead of exactly 10 (as IDLE currently does).  But from what you said on the 
patch, the negative numbers are not exactly the negative of their real size, 
but are tuned for positioning.

Cheryy, Louie, and Ned: the patch needs to be test on multiple *nix machines, 
especially on OSX, to make sure it does not mess up on standard monitors.  A 
quick 'git pr 3639' and 'python -m test.test_idle' would be helpful.

--
nosy: +csabella, louielu, ned.deily

___
Python tracker 

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

[issue31506] Improve the error message logic for object_new & object_init

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

What do you expect for:

class C: pass

object.__new__(C, 1)
C.__new__(C, 1)

--

___
Python tracker 

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

[issue31507] email.utils.parseaddr has no docstring

[Rohit Balasubramanian]

Rohit Balasubramanian added the comment:

I have submitted a pull request for the changes to email.utils.parseaddr.

--
keywords: +patch
nosy: +rohitb
pull_requests: +3640
stage:  -> patch review

___
Python tracker 

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

Re: Old Man Yells At Cloud

[bartc]

On 18/09/2017 15:04, Gregory Ewing wrote:

Dennis Lee Bieber wrote:

Pascal
provides print()/println() [okay, not /statements/ but /procedures/]


Actually write/writeln, and although they used parens like
procedures, they had special syntax for output formatting
that wasn't available to user-defined procedures, so they
were at least as special as the py2 print, maybe more so.


They HAD to be special, because that language was statically typed. You 
couldn't define a user-code procedure or function that took all possible 
types.


That doesn't apply in Python, but it is still useful for print to be a 
little special.


--
bartc

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

[issue31443] Possibly out of date C extension documentation

[Christian Heimes]

Christian Heimes added the comment:

I think it's svnmerge of this commit, which talks about VS 2005. It might have 
been required to support VS 2003 and 2005.

```
 r59290 | christian.heimes | 2007-12-03 14:47:29 +0100 (Mon, 03 Dec 2007) | 3 
lines

  Applied my patch #1455 with some extra fixes for VS 2005
  The new msvc9compiler module supports VS 2005 and VS 2008. I've also fixed 
build_ext to support PCbuild8 and PCbuild9 and backported my fix for xxmodule.c 
from py3k. The old code msvccompiler is still in place in case somebody likes 
to build an extension with VS 2003 or earlier.
  I've also updated the cygwin compiler module for VS 2005 and VS 2008. It 
works with VS 2005 but I'm unable to test it with VS 2008. We have to wait for 
a new version of cygwin.
```

--

___
Python tracker 

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

Re: Old Man Yells At Cloud

[Ben Bacarisse]

Steve D'Aprano  writes:

> [...] try something more common:
>
> 1/2
>
> Most people aren't expecting integer division, but true division, and silently
> returning the wrong result (0 instead of 0.5) is a silent source of
> bugs.

I'm the sure that expectation depends on their background and previous
programming experience, and since I don't know much about most people
when they first write 1/2 in Python, I must conceded that you may be
right.  But is that really the point?  Was the result of 1/2 determined
by a poll to find out what most people expected?  If so, who were these
people -- the result would depend very largely on the selection?

But there is a stronger claim (which I think you also made) that a
floating point result is the correct one.  However, some people with
little experience of floating point arithmetic (I certainly can't say
most but it must be quite few) will expect

  1/10

to return a tenth.  For /them/, the floating point result is silently
wrong and a source of bugs.  If I were aiming a language at beginners,
I'd make 1/10 be a rational or a type error.

However, I don't think that is Python's main demographic, so 1/10 giving
something not quite one tenth may well be the correct design choice.


> And 1/2 doesn't have to return an int. Why is this such a big deal?

I'm sure it's not deliberate, but 1/2 is a bad example because it can be
exactly represented in the most common implementations.  To get a more
fruitful exchange of views, a division like 1/3 or 1/10 might be a
better example.


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

[issue31507] email.utils.parseaddr has no docstring

[Krzysztof Warunek]

Krzysztof Warunek added the comment:

As well as `parsedate_to_datetime`... I'll work on that

--
nosy: +kwarunek

___
Python tracker 

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

[issue10496] Python startup should not require passwd entry

[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

[issue31508] Running test_ttk_guionly logs "test_widgets.py:1562: UserWarning: Deprecated API of Treeview.selection() should be removed" warnings

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

This is a reminder to me to remove a deprecated API (see issue27319).

--

___
Python tracker 

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

[issue31021] Clarify programming faq.

[R. David Murray]

R. David Murray added the comment:

I think there is nothing to do here unless Mark likes my suggestion and/or 
someone comes up with an even better improvement.

--

___
Python tracker 

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

[issue31508] Running test_ttk_guionly logs "test_widgets.py:1562: UserWarning: Deprecated API of Treeview.selection() should be removed" warnings

[STINNER Victor]

STINNER Victor added the comment:

I saw these warnings on:
http://buildbot.python.org/all/builders/x86%20Gentoo%20Refleaks%203.x/builds/96/steps/test/logs/stdio

Extract of the pythoninfo:

tkinter.TCL_VERSION: 8.6
tkinter.TK_VERSION: 8.6
tkinter.info_patchlevel: 8.6.6

--

I can reproduce the warning locally:

test_selection (tkinter.test.test_ttk.test_widgets.TreeviewTest) ... 
/home/haypo/prog/python/master/Lib/tkinter/test/test_ttk/test_widgets.py:1562: 
UserWarning: Deprecated API of Treeview.selection() should be removed
  'Deprecated API of Treeview.selection() should be removed')
ok

--

___
Python tracker 

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

[issue31504] Documentation for return value for string.rindex is missing when search string is empty

[Vedran Čačić]

Vedran Čačić added the comment:

This is nonsense. 'abcde'[7:7] is also ''. So the maximal index in fact doesn't 
exist. What do you think exactly is the property that differentiates 5 from 7 
here?

--
nosy: +veky

___
Python tracker 

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

[issue31508] Running test_ttk_guionly logs "test_widgets.py:1562: UserWarning: Deprecated API of Treeview.selection() should be removed" warnings

[STINNER Victor]

New submission from STINNER Victor:

0:33:11 load avg: 4.82 [ 44/405/1] test_ttk_guionly passed -- running: 
test_subprocess (504 sec)
/buildbot/buildarea/3.x.ware-gentoo-x86.refleak/build/Lib/tkinter/test/test_ttk/test_widgets.py:1562:
 UserWarning: Deprecated API of Treeview.selection() should be removed
  'Deprecated API of Treeview.selection() should be removed')
beginning 6 repetitions
123456
/buildbot/buildarea/3.x.ware-gentoo-x86.refleak/build/Lib/tkinter/test/test_ttk/test_widgets.py:1562:
 UserWarning: Deprecated API of Treeview.selection() should be removed
  'Deprecated API of Treeview.selection() should be removed')
./buildbot/buildarea/3.x.ware-gentoo-x86.refleak/build/Lib/tkinter/test/test_ttk/test_widgets.py:1562:
 UserWarning: Deprecated API of Treeview.selection() should be removed
  'Deprecated API of Treeview.selection() should be removed')
./buildbot/buildarea/3.x.ware-gentoo-x86.refleak/build/Lib/tkinter/test/test_ttk/test_widgets.py:1562:
 UserWarning: Deprecated API of Treeview.selection() should be removed
  'Deprecated API of Treeview.selection() should be removed')
./buildbot/buildarea/3.x.ware-gentoo-x86.refleak/build/Lib/tkinter/test/test_ttk/test_widgets.py:1562:
 UserWarning: Deprecated API of Treeview.selection() should be removed
  'Deprecated API of Treeview.selection() should be removed')
./buildbot/buildarea/3.x.ware-gentoo-x86.refleak/build/Lib/tkinter/test/test_ttk/test_widgets.py:1562:
 UserWarning: Deprecated API of Treeview.selection() should be removed
  'Deprecated API of Treeview.selection() should be removed')
./buildbot/buildarea/3.x.ware-gentoo-x86.refleak/build/Lib/tkinter/test/test_ttk/test_widgets.py:1562:
 UserWarning: Deprecated API of Treeview.selection() should be removed
  'Deprecated API of Treeview.selection() should be removed')
.

--
components: Tkinter
messages: 302454
nosy: gpolo, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Running test_ttk_guionly logs "test_widgets.py:1562: UserWarning: 
Deprecated API of Treeview.selection() should be removed" warnings
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

Re: [Tutor] beginning to code

[Chris Angelico]

On Mon, Sep 18, 2017 at 11:30 PM, Antoon Pardon  wrote:
> Op 18-09-17 om 14:58 schreef Chris Angelico:
>> On Mon, Sep 18, 2017 at 10:42 PM, Rick Johnson
>>  wrote:
>>> (2) Python is, in essence, converting the source code
>>> syntax of:
>>>
>>> if someObject:
>>>
>>> to:
>>>
>>> if BOOLEAN_VALUE_OF_SOMEOBJECT:
>>>
>>> Which, although the result of such a conversion (a
>>> Boolean) will be perfectly symmetrical with formal logic
>>> statements, the conversion is not obvious, because it
>>> happens behind the curtains.
>> What a surprise. In the context of a statement that has exactly two
>> possible courses of action (either you go into the 'if' block, or you
>> go into the 'else' block (if any)), you use the boolean value of an
>> object. What part of this is not obvious?
>
> Well that you reduce an object to a boolean value is not obvious to
> begin with. A TypeError because you are treating a non-boolean as
> a boolean would have been more obvious to me.

Sure, but those are basically your only two options. Either you have a
way of interpreting some/all objects as booleans, or you require an
explicit conversion. In Python syntax:

# Interpret all objects as boolean:
if x: pass

# Require explicit conversion or comparison:
if bool(x): pass
if x == True: pass

But not BOTH of the above:

if bool(x) == True: pass

That's pointless. It's not "more explicit". It's just more redundant.

> A second thought is that it isn't obvious that empty strings, lists ...
> should be thought of as falsy. Sometimes I am treating a stream of
> values/objects and when I ask for the next available items, i get
> a string/list. An empty string/list in that context would mean that
> nothing was available, but it is possible that more will be available
> later and so could be treated just like a non-empty list/string.

Yep. That's a philosophical choice; Python has decided that a
container with nothing in it is falsy, on the assumption that you're
more likely to be contrasting [1,2,3] against [] than either of the
above against None. Other languages have made other choices. Python is
100% consistent within its native data types - including that, unless
otherwise specified, an object is truthy and the absence of an object
(eg None) is falsy. One notable violation of that rule was that a
datetime.time() representing midnight used to be considered false, but
that was treated as a bug and corrected, since a time of midnight is
not equivalent to a number of zero, but to a point on a clock.

> Once you understand how python does things, you can work with it, but
> IMO the way python does things is IMO not at all that obvious as people
> would like us to think.

Understood - but it's not arbitrary, and you *can* get to know the rules.

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

[issue31503] Enhance dir(module) to be informed by __all__ by updating module.__dir__

[R. David Murray]

Changes by R. David Murray :


--
nosy: +r.david.murray

___
Python tracker 

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

Re: [Tutor] beginning to code

[Paul Moore]

On 18 September 2017 at 14:30, Antoon Pardon  wrote:
> Well that you reduce an object to a boolean value is not obvious to
> begin with. A TypeError because you are treating a non-boolean as
> a boolean would have been more obvious to me.

More obvious, possibly - that's essentially a matter of what people
are used to, and a measure of personal opinion.

More useful? Unlikely. The practical examples I've seen of languages
like Python that implicitly convert non-boolean values to boolean, and
languages that don't (and raise an error if a non-boolean is supplied
to an if statement) suggest to me that implicit conversion is highly
useful. I certainly use it in my code (although in my view it's
perfectly "obvious", so I may use constructs that you would find
non-obvious).

> A second thought is that it isn't obvious that empty strings, lists ...
> should be thought of as falsy. Sometimes I am treating a stream of
> values/objects and when I ask for the next available items, i get
> a string/list. An empty string/list in that context would mean that
> nothing was available, but it is possible that more will be available
> later and so could be treated just like a non-empty list/string.

We can argue over the precise rules as to *what* boolean values Python
chooses to take particular non-boolean values as meaning. I'm not
going to have a blazing row over whether an empty string should be
true or false. But equally, I'm not going to mount a campaign to
change it. It's just not that important to me. If you want an argument
worth having, go argue with the Perl people about the fact that "0"
(the 1-character string containing a zero) is false in Perl:

> perl -e "print qq'a non-empty string that is false\n' if not '0';"
a non-empty string that is false

Given this sort of silliness, I'm perfectly OK with the choices Python made :-)

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

[issue31506] Improve the error message logic for object_new & object_init

[Nick Coghlan]

Nick Coghlan added the comment:

For this issue, I'm not proposing to make any change other than to solve the 
specific problem reported in the blog post: when the method itself isn't 
overridden, then the error message should report the name of the most derived 
class, not "object", to help users more readily find the likely source of their 
problem (a missing "__init__" method definition).

Making these custom errors consistent with Python 3's otherwise improved 
argument unpacking errors would be a separate issue (and I agree *that* change 
wouldn't qualify as being easy).

--

___
Python tracker 

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

[issue31498] Default values for zero in time.strftime()

[Denis Osipov]

Denis Osipov added the comment:

If it's really a bug I could make PR with changes in timemodule.c (in 
gettmarg() and checktm() functions). But I'm not sure that it's not intended 
behavior.

--

___
Python tracker 

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

Re: [Tutor] beginning to code

[Antoon Pardon]

Op 18-09-17 om 14:58 schreef Chris Angelico:
> On Mon, Sep 18, 2017 at 10:42 PM, Rick Johnson
>  wrote:
>> (2) Python is, in essence, converting the source code
>> syntax of:
>>
>> if someObject:
>>
>> to:
>>
>> if BOOLEAN_VALUE_OF_SOMEOBJECT:
>>
>> Which, although the result of such a conversion (a
>> Boolean) will be perfectly symmetrical with formal logic
>> statements, the conversion is not obvious, because it
>> happens behind the curtains.
> What a surprise. In the context of a statement that has exactly two
> possible courses of action (either you go into the 'if' block, or you
> go into the 'else' block (if any)), you use the boolean value of an
> object. What part of this is not obvious?

Well that you reduce an object to a boolean value is not obvious to
begin with. A TypeError because you are treating a non-boolean as
a boolean would have been more obvious to me.

A second thought is that it isn't obvious that empty strings, lists ...
should be thought of as falsy. Sometimes I am treating a stream of
values/objects and when I ask for the next available items, i get
a string/list. An empty string/list in that context would mean that
nothing was available, but it is possible that more will be available
later and so could be treated just like a non-empty list/string.

But then, I can't mix this kind of interface with the io module because
a read from classes in that module will produce an empty (byte)string
to indicate the end of the stream.

Once you understand how python does things, you can work with it, but
IMO the way python does things is IMO not at all that obvious as people
would like us to think.

-- 
Antoon Pardon.

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

[issue31499] ElementTree crash while cleaning up ParseError

[STINNER Victor]

STINNER Victor added the comment:

The bug is now fixed in Python 3.6 and master. Thanks for the bug report and 
analysis, Stefan Behnel!

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

[issue31447] proc communicate not exiting on python subprocess timeout using PIPES

[Leonardo Francalanci]

Leonardo Francalanci added the comment:

That works!
But when I said "also with close_fds=True", I meant that I tried WITHOUT 
overriding stdin, stdout, and stderr AND setting close_fds=True, but it didn't 
work. What worked was not overriding stdin/out/err and adding

os.set_inheritable(0, False)
os.set_inheritable(1, False)
os.set_inheritable(2, False)

before the call (no need to set close_fds)

--

___
Python tracker 

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

Re: [Tutor] beginning to code

[Rustom Mody]

On Monday, September 18, 2017 at 6:25:09 PM UTC+5:30, Rustom Mody wrote:
> On Monday, September 18, 2017 at 5:23:49 PM UTC+5:30, Rick Johnson wrote:
> > On Sunday, September 17, 2017 at 8:51:38 PM UTC-5, INADA Naoki wrote:
> > > >
> > > > >
> > > > > I would agree that testing any of those for '== True' or
> > > > > the like is pointless redundancy,
> > > >
> > > > But what's wrong with syntactical redundancy when it brings
> > > > _clarity_ to the source code? And why can't Python be smart?
> > > > Consider the collowing code:
> > > >
> > > > if bool(someObject) == True:
> > > > # Do something
> > > >
> > > > Yes, from a "byte-code perspective", this source code is
> > > > superfluous, but, from a source code perspective, this code
> > > > is perfectly balanced between explicit and implicit.
> > > 
> > > I can't agree with you.  It's too redundant.  It doesn't
> > > provide any information about what coder think. 
> > 
> > It's not about what the "coder thinks", many times what the
> > coder thinks is wrong, it's about writing code that is
> > intuitive to as wide an audience as possible.
> > 
> > > While PEP 8 recommends `if x:`, I accept `if x > 0` or `if
> > > len(x) > 0` when I review code in my company.
> > 
> > So when `x` is an iterable, as in:
> > 
> > if len(x) > 0:
> > # blah
> > 
> > You're okay with the explicit test. Or when `x` is a
> > numeric, as in:
> > 
> > if x > 0:
> > # blah
> > 
> > You're okay with the explicit test. So, from a standpoint of
> > consistency, you /should/ be okay with this:
> > 
> > if bool(x) == True:
> > # blah
> > 
> > But you're not! :-). 
> 
> I have a feeling Rick that you are mixing up two unrelated things:
> - the bool(x) part
> - the ... == True part
> 
> The operation 
> x == True
> for true(!)/proper booleans x is a no-op
> because True == True is True
> and False == True is False
> And there are no other (proper) booleans
> 
> However because anything else can be bool-ish even though not boolean
> you need the bool(x) to effect the mapping:
> 
> {None, 0, "" {}, []} → False
> Everything_else → True
> 
> This mapping is neither obvious nor trivial

Sufficiently non-obvious that I missed the key element:
{None, 0, "" {}, [], False} → False
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [Tutor] beginning to code

[Steve D'Aprano]

On Mon, 18 Sep 2017 09:53 pm, Rick Johnson wrote:

> Tell you what: test your hypothesis on non-programmers and
> report back here.

Why would someone do that?

The purpose of source code is not to communicate with non-programmers. It is to
communicate with other programmers. (If the code is executable by a computer as
well, that's even better.)

I wouldn't ask a non-programmer to critique my source code any more than I would
ask a non-English reader to critique my English prose, or a non-musician to
read my musical score[1]. It would annoy the non-programmer and provide no
useful results.



> all i'm
> suggesting is an extrapolation of that philosophy into the
> realms of conditional logic.

By writing True == True when you actually mean just True.


> I'm thinking of writing a linter (or pre-parser, call it
> what you like) that will enforce the explicit forms that i
> have outlined above.

That's an excellent idea. And just like I promised all those many, many years
ago when you announced you were re-writing Python to implement all your other
brilliant ideas, I'll beta test it for you. If and when you actually write some
code and make it publicly available.







[1] Always supposing I could write a musical score. 


-- 
Steve
“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: [Tutor] beginning to code

[Chris Angelico]

On Mon, Sep 18, 2017 at 10:42 PM, Rick Johnson
 wrote:
> (2) Python is, in essence, converting the source code
> syntax of:
>
> if someObject:
>
> to:
>
> if BOOLEAN_VALUE_OF_SOMEOBJECT:
>
> Which, although the result of such a conversion (a
> Boolean) will be perfectly symmetrical with formal logic
> statements, the conversion is not obvious, because it
> happens behind the curtains.

What a surprise. In the context of a statement that has exactly two
possible courses of action (either you go into the 'if' block, or you
go into the 'else' block (if any)), you use the boolean value of an
object. What part of this is not obvious?

Do you prefer languages that:

1) Require the use of an actual Boolean type? You still don't have to
compare the bool against True - "if bool(some_object)" would work.
2) Have no data types, but require that you use "1" or "0" (the
strings) to represent true and false?
3) Treat any nonzero value as false, and zero as true?

All of those exist. Are they somehow intrinsically better than the
Python model? Are they "more explicit"?

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

Re: [Tutor] beginning to code

[Rustom Mody]

On Monday, September 18, 2017 at 5:23:49 PM UTC+5:30, Rick Johnson wrote:
> On Sunday, September 17, 2017 at 8:51:38 PM UTC-5, INADA Naoki wrote:
> > >
> > > >
> > > > I would agree that testing any of those for '== True' or
> > > > the like is pointless redundancy,
> > >
> > > But what's wrong with syntactical redundancy when it brings
> > > _clarity_ to the source code? And why can't Python be smart?
> > > Consider the collowing code:
> > >
> > > if bool(someObject) == True:
> > > # Do something
> > >
> > > Yes, from a "byte-code perspective", this source code is
> > > superfluous, but, from a source code perspective, this code
> > > is perfectly balanced between explicit and implicit.
> > 
> > I can't agree with you.  It's too redundant.  It doesn't
> > provide any information about what coder think. 
> 
> It's not about what the "coder thinks", many times what the
> coder thinks is wrong, it's about writing code that is
> intuitive to as wide an audience as possible.
> 
> > While PEP 8 recommends `if x:`, I accept `if x > 0` or `if
> > len(x) > 0` when I review code in my company.
> 
> So when `x` is an iterable, as in:
> 
> if len(x) > 0:
> # blah
> 
> You're okay with the explicit test. Or when `x` is a
> numeric, as in:
> 
> if x > 0:
> # blah
> 
> You're okay with the explicit test. So, from a standpoint of
> consistency, you /should/ be okay with this:
> 
> if bool(x) == True:
> # blah
> 
> But you're not! :-). 

I have a feeling Rick that you are mixing up two unrelated things:
- the bool(x) part
- the ... == True part

The operation 
x == True
for true(!)/proper booleans x is a no-op
because True == True is True
and False == True is False
And there are no other (proper) booleans

However because anything else can be bool-ish even though not boolean
you need the bool(x) to effect the mapping:

{None, 0, "" {}, []} → False
Everything_else → True

This mapping is neither obvious nor trivial

And one could argue that leaving python to implicitly make [] (say) into False
should be documented

So if you drop the hangup with the red-herring ...==True 
you have a point in asking for the bool(...)
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue31499] ElementTree crash while cleaning up ParseError

[STINNER Victor]

STINNER Victor added the comment:


New changeset 8afd7ab12d7f8915b549cf04af384b495ec73d22 by Victor Stinner (Miss 
Islington (bot)) in branch '3.6':
[3.6] bpo-31499, xml.etree: Fix xmlparser_gc_clear() crash (GH-3641) (#3645)
https://github.com/python/cpython/commit/8afd7ab12d7f8915b549cf04af384b495ec73d22


--

___
Python tracker 

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

Re: [Tutor] beginning to code

[Rick Johnson]

Steve D'Aprano wrote:

> [snip: offensive statements]
>
> Your insistence on adding the entirely superfluous, unnecessary

Please acquaint yourself with the definition of superfluous,
as in most i have seen, the actual word "unnecessary" is
part of the definition.

> and distracting "== True" at the end of something which is
> already True or False demonstrates a lack of fluency in the
> language and difficulty in reasoning about boolean logic.

Steve, it one thing for you to disagree with me (even to the
point of passionate appeals), but it is quite another to
suggest that my "fluency of the Python language" or my
"reasoning about boolean logic" is flawed.

Python is a programming language, not a formal logic, and i
can assure you, i understand Python semantics and formal
logic just fine.

My complaint that Python's conditional logic forms: (1)
implicitly cast objects to boolean, and (2) and rely on an
underlying and unintuitive design which has arbitrarily
assigned boolean values to objects -- is not a result of a
misunderstanding on my part, no, it a result of my utter
distaste for implicit conditional logic forms. 

Consider the currently accepted form of conditional logic:

if someObject:
# do something

In this implicit code example, Python is doing two "magical"
things:

(1) Python3 is implicitly casting `someObject` to a
boolean value by silently calling
`someObject.__bool__()`. 

Of course, in Python<3 there was no __bool__ dunder
method, so you'd have to define __nonzero__ or __len__
to achieve the same thing. And for those who don't know
about this difference, consider the following Python 2.x
code:

>>> class FalseFoo(object):
... def __len__(self):
... return 0
>>> falseFoo = FalseFoo()
>>> bool(falseFoo)
False
>>> class TrueFoo(object):
... def __len__(self):
... return 1
>>> trueFoo = TrueFoo()
>>> bool(trueFoo)
True

Hmm, in light of this revelation, one could argue that
__bool__ was only introduced to correct a semantical
inconsistency that existed between the bool() function
and the dunder method it called, namely: __nonzero__ or
__len__ (depending on which was defined). All other
builtin functions (i can think of) map perfectly to
intuitively named dunder methods (len -> __len__, dir ->
__dir__, etc...). So, obviously, the devs are concerned
about "source code semantics", or they would have not
have introduced __bool__.

(2) Python is, in essence, converting the source code
syntax of:

if someObject:

to:

if BOOLEAN_VALUE_OF_SOMEOBJECT:

Which, although the result of such a conversion (a
Boolean) will be perfectly symmetrical with formal logic
statements, the conversion is not obvious, because it
happens behind the curtains.

So with that simple statement, two magical and unobvious
actions are occuring behind the curtain. IMO, such non-
obvious conversions are a violation of the "human readable"
goal of Python source code. Magic is not obvious. And
implicit conditional logic is not "human readable".
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue31504] Documentation for return value for string.rindex is missing when search string is empty

[Ashok Bakthavathsalam]

Changes by Ashok Bakthavathsalam :


--
type: behavior -> enhancement

___
Python tracker 

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

[issue31506] Improve the error message logic for object_new & object_init

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

It is not so easy to make an error message conforming with error messages for 
similar types. This may require changing error messages in other code.

First, "takes no arguments" instead of "takes no parameters".

For normal __new__ and __init__ you never got "takes no arguments". They  take 
at least one argument -- a class or an instance.

>>> tuple.__new__(tuple, 1, 2, 3, 4)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: tuple expected at most 1 arguments, got 4
>>> list.__init__([], 1, 2, 3, 4)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: list expected at most 1 arguments, got 4
>>> class C:
... def __new__(cls): return object.__new__(cls)
... def __init__(self): pass
... 
>>> C.__new__(C, 1, 2, 3, 4)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: __new__() takes 1 positional argument but 5 were given
>>> C.__init__(C(), 1, 2, 3, 4)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: __init__() takes 1 positional argument but 5 were given

--

___
Python tracker 

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

[issue31499] ElementTree crash while cleaning up ParseError

[Roundup Robot]

Changes by Roundup Robot :


--
pull_requests: +3639

___
Python tracker 

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

[issue31499] ElementTree crash while cleaning up ParseError

[STINNER Victor]

STINNER Victor added the comment:


New changeset e727d41ffcd91b21ce82026ec8c8381d34a16209 by Victor Stinner in 
branch 'master':
bpo-31499, xml.etree: Fix xmlparser_gc_clear() crash (#3641)
https://github.com/python/cpython/commit/e727d41ffcd91b21ce82026ec8c8381d34a16209


--

___
Python tracker 

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

[issue31506] Improve the error message logic for object_new & object_init

[Nick Coghlan]

Nick Coghlan added the comment:

Fortunately, the logic is already well encapsulated: there's a "if (excess_args 
&& (case A || case B)) {... report error ...}" check at the start of each of 
object_new and object_init, where "case A" = "the other function in the 
object_new/object_init pair has *not* been overriden" and "case B" is "this 
function *has* been overridden".

That means the only change needed is to include the type name in an updated 
error message in case A, while retaining the current error messages for case B.

--

___
Python tracker 

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

lxml 4.0.0 released

[Stefan Behnel]

Hi all,

lxml 4.0.0 was released yesterday with several new features and
enhancements. Thanks to everyone who contributed.

lxml is the fastest, most versatile and most widely used tool for
processing XML and HTML in Python, supporting XPath, XSLT and many pythonic
ways to deal with markup documents.

The documentation is here: http://lxml.de/

Download:
https://pypi.python.org/pypi/lxml

Binary wheels are available for Linux, Mac-OS and Windows.

Changelog: http://lxml.de/4.0/changes-4.0.0.html

Github:
https://github.com/lxml/lxml/releases/tag/lxml-4.0.0

This release was built using Cython 0.26.1.

If you are interested in commercial support or customisations for the lxml
package, please contact me directly.

Have fun,

Stefan



4.0.0 (2017-09-17)
==

Features added
--

* The ElementPath implementation is now compiled using Cython,
  which speeds up the ``.find*()`` methods quite significantly.

* The modules ``lxml.builder``, ``lxml.html.diff`` and ``lxml.html.clean``
  are also compiled using Cython in order to speed them up.

* ``xmlfile()`` supports async coroutines using ``async with`` and
  ``await``. See http://lxml.de/api.html#incremental-xml-generation

* ``iterwalk()`` has a new method ``skip_subtree()`` that prevents walking
  into the descendants of the current element.

* ``RelaxNG.from_rnc_string()`` accepts a ``base_url`` argument to
  allow relative resource lookups.

* The XSLT result object has a new method ``.write_output(file)`` that
  serialises output data into a file according to the 
  configuration.

Bugs fixed
--

* GH#251: HTML comments were handled incorrectly by the soupparser.
  Patch by mozbugbox.

* LP#1654544: The html5parser no longer passes the ``useChardet`` option
  if the input is a Unicode string, unless explicitly requested.  When
  parsing files, the default is to enable it when a URL or file path is
  passed (because the file is then opened in binary mode), and to disable
  it when reading from a file(-like) object.

  Note: This is a backwards incompatible change of the default
  configuration. If your code parses byte strings/streams and depends on
  character detection, please pass the option ``guess_charset=True``
  explicitly, which already worked in older lxml versions.

* LP#1703810: ``etree.fromstring()`` failed to parse UTF-32 data with BOM.

* LP#1526522: Some RelaxNG errors were not reported in the error log.

* LP#1567526: Empty and plain text input raised a TypeError in soupparser.

* LP#1710429: Uninitialised variable usage in HTML diff.

* LP#1415643: The closing tags context manager in ``xmlfile()`` could
  continue to output end tags even after writing failed with an exception.

* LP#1465357: ``xmlfile.write()`` now accepts and ignores None as input
  argument.

* Compilation under Py3.7-pre failed due to a modified function signature.

Other changes
-

* The main module source files were renamed from ``lxml.*.pyx`` to plain
  ``*.pyx`` (e.g. ``etree.pyx``) to simplify their handling in the build
  process.  Care was taken to keep the old header files as fallbacks for
  code that compiles against the public C-API of lxml, but it might still
  be worth validating that third-party code does not notice this change.
-- 
https://mail.python.org/mailman/listinfo/python-announce-list

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

NumExpr patched from 2.6.3 to 2.6.4

[Robert McLeod]

This is a quick note to update from the release two days ago that we've
pushed NumExpr 2.6.4. The release of 2.6.3 two days ago omitted
implementations for the new `ceil` and `floor` functions for the Intel VML
when compiled with the Intel MKL.  Thanks to Christoph Gohlke for noticing
the error and patching it.

Also thanks to Matthew Brett for helping me to get the manywheels procedure
going for NumExpr. There was a minor delay yesterday in uploading due to
the Amazon/Travis outage.

Github:

https://github.com/pydata/numexpr

PyPI:

https://pypi.python.org/pypi/numexpr

Docs:

http://numexpr.readthedocs.io/en/latest/

-- 
Robert McLeod, Ph.D.
robbmcl...@gmail.com
robbmcl...@protonmail.com
-- 
https://mail.python.org/mailman/listinfo/python-announce-list

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

six 1.11.0

[Benjamin Peterson]

It's been a while, but six 1.11.0 is now live on PyPI! six is a Python
2&3 compatibility library.

Many thanks to the various contributors who did most the work.

Here is the changelog for 1.11.0:

- Pull request #178: `with_metaclass` now properly proxies `__prepare__`
to the
  underlying metaclass.

- Pull request #191: Allow `with_metaclass` to work with metaclasses
implemented
  in C.

- Pull request #203: Add parse_http_list and parse_keqv_list to moved
  urllib.request.

- Pull request #172 and issue #171: Add unquote_to_bytes to moved
urllib.parse.

- Pull request #167: Add `six.moves.getoutput`.

- Pull request #80: Add `six.moves.urllib_parse.splitvalue`.

- Pull request #75: Add `six.moves.email_mime_image`.

- Pull request #72: Avoid creating reference cycles through tracebacks
in
  `reraise`.
-- 
https://mail.python.org/mailman/listinfo/python-announce-list

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

ANN: yacron 0.5.0 released

[Gustavo Carneiro]

yacron is a modern Cron replacement that is Docker-friendly

- "Crontab" is in YAML format;
- Builtin sending of Sentry and Mail outputs when cron jobs fail;
- Flexible configuration: you decide how to determine if a cron job fails
or not;
- Designed for running in Docker, Kubernetes, or 12 factor environments:
- Runs in the foreground;
- Logs everything to stdout/stderr [1];
- Option to automatically retry failing cron jobs, with exponential backoff.

[1] Whereas vixie cron only logs to syslog, requiring a syslog daemon to be
running in the background or else you don't get logs!

Home page: https://github.com/gjcarneiro/yacron
PyPI: https://pypi.python.org/pypi/yacron

Note: I am not planning any more features until the 1.0 release, but I
appreciate help finding and fixing bugs.

-- 
Gustavo J. A. M. Carneiro
Gambit Research
"The universe is always one step beyond logic." -- Frank Herbert
-- 
https://mail.python.org/mailman/listinfo/python-announce-list

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

[RELEASE] Python 2.7.14

[Benjamin Peterson]

I'm happy to announce to the immediate availability of Python 2.7.14,
yet another bug fix release in the Python 2.7 series. 2.7.14 includes 9
months of conservative bug fixes from the 3.x branch.

Downloads of source code and binaries are at:
https://www.python.org/downloads/release/python-2714/

Bugs may be reported at
https://bugs.python.org/

Warmly,
Benjamin
2.7 release manager
(on behalf of all of 2.7's contributors)
-- 
https://mail.python.org/mailman/listinfo/python-announce-list

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

Re: [Tutor] beginning to code

[Rick Johnson]

On Sunday, September 17, 2017 at 8:51:38 PM UTC-5, INADA Naoki wrote:
> >
> > >
> > > I would agree that testing any of those for '== True' or
> > > the like is pointless redundancy,
> >
> > But what's wrong with syntactical redundancy when it brings
> > _clarity_ to the source code? And why can't Python be smart?
> > Consider the collowing code:
> >
> > if bool(someObject) == True:
> > # Do something
> >
> > Yes, from a "byte-code perspective", this source code is
> > superfluous, but, from a source code perspective, this code
> > is perfectly balanced between explicit and implicit.
> 
> I can't agree with you.  It's too redundant.  It doesn't
> provide any information about what coder think. 

It's not about what the "coder thinks", many times what the
coder thinks is wrong, it's about writing code that is
intuitive to as wide an audience as possible.

> While PEP 8 recommends `if x:`, I accept `if x > 0` or `if
> len(x) > 0` when I review code in my company.

So when `x` is an iterable, as in:

if len(x) > 0:
# blah

You're okay with the explicit test. Or when `x` is a
numeric, as in:

if x > 0:
# blah

You're okay with the explicit test. So, from a standpoint of
consistency, you /should/ be okay with this:

if bool(x) == True:
# blah

But you're not! :-). 

Even though "== True" is just as much a part of the explicit
test as "> 0" is, and likewise, "bool(x)" is just as important
as "len(x)" to call the proper dunder method. So what is
your justification for making a special case out of the last
example, but having no problem with the first two forms?

Because, as we know: "SPECIAL CASES ARE NOT SPECIAL ENOUGH
TO BREAK THE RULES". *wink*

IMO, you're ignoring the importance of consistency. If you
want to be consistent, either you must accept _all_ forms,
or _none_ of them.

> While it is redundant in most case, it express what writer
> thinking. But I never permit `if bool(x) == True`.  It only
> express `if x is truthy value` in complicated way. `if x`
> is best way to express `if x is truthy value`.

Tell you what: test your hypothesis on non-programmers and
report back here. 

> > So what
> > should Python do when such intuitive, but not so much
> > efficient, code is encountered? Easy! Python should optimize
> > it! Observe:
> >
> > FROM: "if bool(someObject) == True:"
> >   TO: "if someObject:"
> >
> > FROM: "if bool(someObject) == False:"
> >   TO: "if not someObject:"
> >
> > Why is "source code optimization" such a difficult concept
> > for some people in this community to grasp? In this case,
> > Python doesn't even need to know anything about these
> > objects, no, the solution is just a simple matter of string
> > substitution.
> >
> >
> While such type of optimization is possible, it's not easy
> as you think. You can overwrite `bool`.
> 
> def bool(x):
> return !x

Oops. That looks like a syntax error. Ruby uses the "!" as a
logical not operator, _not_ Python.

> if 0:
> print("not shown")
> 
> if bool(0) == True:
> print("shown")
> 

But i get your point. 

Although, your point -- "that a programmer can shoot
[him/her]self in the foot" -- is really moot, since there are
literally countless ways in which code can be broken by
doing dumb things. For example, i can hit my computer with a
big hammer and cause all sorts of bad things to happen, but
using the: "coder might strike the computer with big hammer
so we should prepare for that by doing X, Y and Z..." excuse
as a design philosophy is just not practical. In the end,
we can't stop a coder from smashing the computer with a big
hammer, but we can demand that the code is written in an
explicit (enough) manner.

Forcing whitespace usage to denote Python blocks is one way
that Python forces us to write clean code, and all i'm
suggesting is an extrapolation of that philosophy into the
realms of conditional logic.

> But my point is only readability.  I don't agree `if
> bool(x) == True:` is clear than `if x:`.

You certainly have a right to your opinion. And i do
appreciate you presenting this argument in a respectful
manner.

I'm thinking of writing a linter (or pre-parser, call it
what you like) that will enforce the explicit forms that i
have outlined above. Possibly with the ability to fine tune
it in a way that best suits the programmer. For instance, if
you wanted "if NUMERIC > 0" and "if len(ITERABLE) > 0", but
you didn't want "if bool(x) == BOOLEAN_LITERAL", then it
would ignore the last form.

What do you think of this?
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue31506] Improve the error message logic for object_new & object_init

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Not sure this is easy issue. It requires taking to account many different cases 
and analyzing many arguments checking code scattered around many files.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

Re: [Tutor] beginning to code

[Rick Johnson]

On Sunday, September 17, 2017 at 7:12:46 PM UTC-5, Terry Reedy wrote:
> The coinage 'Executable pseudocode' was my description of Python on 
> comp.lang.python, mirrored to this list, in April 1997, long before
> I became a Python (core) dev.  Guido did say things like 'human 
> readable' before that.  To the extent that my description implies a 
> higher standard, you cannot imput it to Guido ;-).

I can neither confirm or deny that claim, so until i can, i
will accept your claim as valid. Although, i seem to
remember GvR using "executable pseudocode" in one of his
early interviews.

In any event, there is no doubt that GvR's original intent
was to create a language with a clear syntax (something that
ABC tried to do, but failed miserably), so whether he used
the exact words 'executable pseudocode' or 'human readable',
the meaning is the same. 

"A horse of a different color is still a horse; of course, of course." :-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Old Man Yells At Cloud

[bartc]

On 18/09/2017 04:23, Steve D'Aprano wrote:

On Mon, 18 Sep 2017 11:11 am, Rick Johnson wrote:


Speaking in _keystrokes_, and that's what really matters
here, a print function is always three more keystrokes than
a print statement.


Keystrokes only matter if you are hunt'n'peck typing and need to pause between
holding down the shift key and pressing the 9 key. Otherwise typing ( is little
different than typing 9, its pretty much all the same regardless of what
character you type. For an even half-arsed typist like myself, hitting the
shift and 9 keys happens almost simultaneously. Technically it might involve
two fingers but its effectively a single movement.

If you micro-analyse this, not all keystrokes are equivalent. They use different
fingers, different hands, the movements are different. The fact that some
characters need two simultaneous keypresses is not so important.


I don't hunt but my typing accuracy is very poor.

Shifted keys are harder (in having poorer success outcomes) because two 
keys are involved, the keys are somewhat outside the Qwerty zone so need 
a longer reach, and some synchronisation is needed (the shift must be 
pressed before the '(').


It's not as bad as it sounds but just means that unnecessary shifted 
punctuation is more of a PITA than if it wasn't necessary.


It's a lot worse doing this in C however; compare:

   print a

with:

   printf ("%d\n",a);

8 extra punctuation characters, of which half are shifted (on my 
keyboard). /And/ you have to select a suitable format code. Suddenly, 
having to type:


   print (a)

doesn't seem so bad.


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

The Python-List community

[Leam Hall]

A few days ago I pointed out that this list's community had 
"opportunities to improve". While we still have lots of those 
opportunities, it is good to see several community members raise the bar 
in welcoming new folks into the community.


Thank you for your help and positive attitude!

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

[issue31504] Documentation for return value for string.rindex is missing when search string is empty

[Ashok Bakthavathsalam]

Ashok Bakthavathsalam added the comment:

@Storchaka, 

You say `5` is related to the substring. Pray, explain how 5 is related to a 
null substring? Also, from https://bugs.python.org/msg243710, as per the great 
Hettinger:

   Though this is closed as not a bug, feel free to add an example or a 
   mention in the documentation.  Keep it short though.  

That's all I am asking to be included.

--

___
Python tracker 

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

[issue31504] Documentation for return value for string.rindex is missing when search string is empty

[Ashok Bakthavathsalam]

Ashok Bakthavathsalam added the comment:

Look at my suggested changes. It doesn't add noise, IMHO.

All I am saying is that the explicit behaviour needs to be documented. 
I unnecessarily wasted at least 3-4 hours on this "undocumented" behavior.

--

___
Python tracker 

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

[issue31507] email.utils.parseaddr has no docstring

[Mark Dickinson]

New submission from Mark Dickinson:

While demonstrating email.utils.parseaddr in a recent training course, I 
discovered it had no docstring (see below). This looks as though it should be 
an easy fix for a first-time contributor.

taniyama:Desktop mdickinson$ ipython
Python 3.6.2 (default, Jul 24 2017, 13:17:39) 
Type 'copyright', 'credits' or 'license' for more information
IPython 6.2.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: from email.utils import parseaddr

In [2]: parseaddr?
Signature: parseaddr(addr)
Docstring: 
File:  
/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/email/utils.py
Type:  function

--
components: Library (Lib)
keywords: easy
messages: 302442
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: email.utils.parseaddr has no docstring
type: behavior
versions: Python 2.7, 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

[issue31505] assertion failure in json, in case _json.make_encoder() received a bad encoder() argument

[Oren Milman]

Changes by Oren Milman :


--
keywords: +patch
pull_requests: +3638
stage:  -> patch review

___
Python tracker 

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

[issue31499] ElementTree crash while cleaning up ParseError

[STINNER Victor]

STINNER Victor added the comment:

test_issue31499.diff: Oh great, it works (to reproduce the crash). I modified 
your test and included it in my PR, I added you as a co-author of my PR ;-)

--

___
Python tracker 

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

[issue31506] Improve the error message logic for object_new & object_init

[Nick Coghlan]

Changes by Nick Coghlan :


--
keywords: +easy (C)

___
Python tracker 

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

[issue31496] IDLE: test_configdialog failed

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

No, the fix for issue31500 doesn't affect this issue.

--

___
Python tracker 

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

[issue31506] Improve the error message logic for object_new & object_init

[Nick Coghlan]

Changes by Nick Coghlan :


--
components: +Interpreter Core
stage:  -> needs patch
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

[issue31506] Improve the error message logic for object_new & object_init

[Nick Coghlan]

New submission from Nick Coghlan:

As described in 
https://blog.lerner.co.il/favorite-terrible-python-error-message/, object_new 
and object_init currently have "object" hardcoded in the error messages they 
raise for excess parameters:


>>> class C: pass
... 
>>> C(10)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: object() takes no parameters
>>> c = C()
>>> c.__init__(10)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: object.__init__() takes no parameters

This hardcoding makes sense for the case where that particular method has been 
overridden, and the interpreter is reporting an error in the subclass's call up 
to the base class, rather than in the call to create an instance of the 
subclass:

>>> class D:
... def __init__(self, *args):
... return super().__init__(*args)
... 
>>> D(10)
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 3, in __init__
TypeError: object.__init__() takes no parameters


However, it's misleading in the case where object_new is reporting an error 
because it knows object_init hasn't been overridden (or vice-versa), and hence 
won't correctly accept any additional arguments: in those cases, it would be 
far more useful to report "type->tp_name" in the error message, rather than 
hardcoding "object".

If we split the error message logic that way, then the first two examples above 
would become:

>>> class C: pass
... 
>>> C(10)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: C() takes no parameters
>>> c = C()
>>> c.__init__(10)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: C.__init__() takes no parameters

while the subclassing cases would be left unchanged.

--
messages: 302439
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Improve the error message logic for object_new & object_init

___
Python tracker 

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

[issue31504] Documentation for return value for string.rindex is missing when search string is empty

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

5 is not valid index of character, but it is valid index of substring.

IMHO documenting explicitly miscellaneous particular cases which are not 
exceptions of general rules just adds a noise. This makes the documentation 
larger and decrease the chance that it will be read.

--
nosy: +r.david.murray, rhettinger

___
Python tracker 

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