[issue30462] urllib does not support NO_PROXY environment variable containing domain with asterisk

[Xiang Zhang]

Xiang Zhang  added the comment:

Hi, Jiri. Could you update your PR and let's continue with this issue?

--
versions: +Python 3.8 -Python 3.7

___
Python tracker 

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

[issue33904] IDLE: In rstrip, rename class RstripExtension as Rstrip

[Srinivas Reddy T]

Change by Srinivas  Reddy T :


--
keywords: +patch
pull_requests: +7418
stage: needs patch -> patch review

___
Python tracker 

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

Re: Writing an assembler in Python

[dieter]

iansuder...@gmail.com writes:

> What does the code look like to insert assembler into python and how does 
> that code send information back to python.

Python is a "high level" language: it tries hard to hide many
"low level" details such as addresses and memory management.
Thus, it is quite far away from low level assembler code.

You can use something like "cython" to compile something
similar to Python source code into C/C++ code - either
for direct optimizations or to interface with C/C++
libraries. In the second case, the C/C++ functions can include
assembly code (provided this is supported by the compiler).

"cython" handles most of the difficulties of Python's C API,
thus typically providing for (rather) safe Python-C/C++ interaction.
I suggest to read its documentation.

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

[issue33908] remove unecessary variable assignments

[Xiang Zhang]

Change by Xiang Zhang :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type: resource usage -> 
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

[issue33908] remove unecessary variable assignments

[Srinivas Reddy T]

New submission from Srinivas  Reddy T :

https://github.com/python/cpython/pull/7116

--
messages: 320018
nosy: thatiparthy
priority: normal
severity: normal
status: open
title: remove unecessary variable assignments
type: resource usage
versions: Python 3.7, Python 3.8

___
Python tracker 

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

[issue33908] remove unecessary variable assignments

[Srinivas Reddy T]

Change by Srinivas  Reddy T :


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

___
Python tracker 

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

[issue33907] IDLE: Rename calltips and CallTips as calltip and Calltip.

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests: +7416
stage: needs patch -> patch review

___
Python tracker 

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

[issue33907] IDLE: Rename calltips and CallTips as calltip and Calltip.

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset e97a685185b82ba6de6de576fc2a4cf3cd6192af by Terry Jan Reedy in 
branch '3.6':
 [3.6] bpo-33907: Rename an IDLE module and class. (GH-7807)  (GH-7809)
https://github.com/python/cpython/commit/e97a685185b82ba6de6de576fc2a4cf3cd6192af


--

___
Python tracker 

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

Re: syntax difference

[Chris Angelico]

On Wed, Jun 20, 2018 at 11:19 AM, Steven D'Aprano
 wrote:
> On Wed, 20 Jun 2018 07:52:31 +1000, Chris Angelico wrote:
>
>>> What do you do in python when a local function variable needs to retain
>>> its value? I'm sure it can do it, but I bet it's not as simple as how I
>>> do it.
>>>
>> What do you mean, "retain its value"? Do you mean the way closures work?
>
> I think that Bart means something like static variables in C. That's
> something I'd like to see Python get. The simplest work-around we have is
> to put the static variable in the function parameter list as if it were
> an argument of the function.

Ah. Yeah, that would be a plausible feature to add to Python. But in
C, a static variable is basically the same thing as a global variable,
except that its name is scoped to the function. There is only one of
it. What happens in Python? For instance:

def f():
def g():
static x = 0
x += 1
return x
return g

Does the static variable exist once for each instance of g()? If so,
it'll behave like a closure variable; if not, it'll behave like a
global. Either way, I'm pretty much certain that people will expect
the other.

>>> Multi-level loop break? Separators in numbers? I think that one is
>>> finally in.
>>
>> Multi-level loop break is most commonly spelled "return".
>
> Not in languages that have a multi-level break.

Sure, but across all languages, it's most commonly spelled "return",
and I don't see very many people screaming for multi-level break.

>> In over two
>> decades of programming, the number of times I've needed to break out of
>> multiple loops without breaking out of an entire function can be counted
>> on the fingers of one hand. Specifically, three times. In nearly three
>> decades.
>
> Okay. The number of times I've wanted an asynchronous function so far has
> been zero, therefore the feature must be useless, right?
>
> *wink*

Fair criticism. However, his original statement was that these were
inherently useful features. Some of them are definitely useful (static
variables, maybe reference arguments); others are useful in some
languages but a terrible fit for something like Python (pointers); and
some are just not all that commonly needed. Compare the number of
times you use a for...else, the number of times you use multi-level
break, and the number of times you use slices with negative steps. Now
add all of them up, and compare to the number of times you use
subprocesses, or network calls (either the direct socket layer, or one
of the higher level features that's built on it, like HTTP download).
Both of those are highly practical features. Neither can be
implemented purely in the stdlib (unless you just punt on it by making
a totally unchecked way to make system calls). Both are, therefore,
extremely useful language features, even though they don't actually
require dedicated syntax.

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

[issue33301] Add __contains__ to pathlib

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

There was a similar (closed) issue about making Path an iterable. The problem 
with both these related ideas is that they are ambiguous. Does it means that a 
directory contains a specified file, or that a path contains a specified path 
component, or that a specified path is a prefix of other path? There are 
third-party pathlib-like implementations that make Path a str subclass. They 
have both __iter__ and __contains__ inherited from str, but with different 
meaning.

I'm -1. It is better to write explicitly what you mean than allow the computer 
to guess.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue33907] IDLE: Rename calltips and CallTips as calltip and Calltip.

[Terry J. Reedy]

Terry J. Reedy  added the comment:

The calltip window class name is only used in 4 places, so I decided to expand 
to CalltipWindow.

--

___
Python tracker 

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

[issue33907] IDLE: Rename calltips and CallTips as calltip and Calltip.

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I also changed calltips.CallTips to calltip.Calltip, which is the same class 
name as for calltip_w.Calltip (formerly CallTip).  This is confusing now and 
would block merging the files.  Change the latter to calltip_w.CalltipW (for 
Window).

--
nosy:  -miss-islington
stage: patch review -> needs patch

___
Python tracker 

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

[issue33907] IDLE: Rename calltips and CallTips as calltip and Calltip.

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests: +7415

___
Python tracker 

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

[issue33907] IDLE: Rename calltips and CallTips as calltip and Calltip.

[miss-islington]

miss-islington  added the comment:


New changeset b89a376b3b9bdc3b6f1b7d05ff64babcbfd93cc2 by Miss Islington (bot) 
in branch '3.7':
bpo-33907: Rename an IDLE module and class. (GH-7807)
https://github.com/python/cpython/commit/b89a376b3b9bdc3b6f1b7d05ff64babcbfd93cc2


--
nosy: +miss-islington

___
Python tracker 

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

Re: syntax difference

[Steven D'Aprano]

On Tue, 19 Jun 2018 12:13:40 -0700, Jim Lee wrote:

> On 06/19/2018 04:13 AM, Ed Kellett wrote:
>> I think
>> we're all--still--missing the larger point that "easy to remove" is a
>> completely stupid metric for judging language features. Seriously. Not
>> a little bit stupid.
>
> Not if you think of the feature as analogous to cancer.

That would take it so far beyond the stupidity event horizon that no 
human language has an adjective for how stupid it is.

Besides, annotations aren't cancer. They're obviously terrorism. Any fool 
can see that.


-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: syntax difference

[Steven D'Aprano]

On Tue, 19 Jun 2018 12:38:24 -0700, Rick Johnson wrote:

> Why shouldn't i have the right to "brush type-hints under the rug" Ian?
> After all, if the code *I* write doesn't belong to *ME*, well then, who
> *HELL* does it belong to?

If you don't want to use type-hints in your own code, why did you put 
them in in the first place?

Don't expect somebody else to reverse your own foolishness. You put the 
annotations in, you can take them out.


> Is it not the right of the programmer to decide whether a named function
> is more appropriate than a list comprehension or an anonymous function?

It isn't the right of the programmer to have somebody else write a 
function to convert the one to another for them.



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: curve_fit in scipy

[Sharan Basappa]

> > Secondly, I don't understand how curve_fit knows the number of arguments 
> > that test_func takes.
> 
> Part of the dynamic nature of Python is that a function carries with it 
> the number of parameters (as just one among many such properties).  We 
> call it "introspection" when we examine such properties of objects.  The 
> curve_fit function usees such an introspection to find that 
> test_function has two parameters (a and b) defining the family of curves.

Thanks a lot. The above feature where a given function is able to inspect 
another function is really cool. This gives me an idea to go a read it further. 

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

[issue33907] IDLE: Rename calltips and CallTips as calltip and Calltip.

[miss-islington]

Change by miss-islington :


--
pull_requests: +7414

___
Python tracker 

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

[issue33907] IDLE: Rename calltips and CallTips as calltip and Calltip.

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 06e2029dfa500a42e3565ed7ba8573412f153d1c by Terry Jan Reedy in 
branch 'master':
bpo-33907: Rename an IDLE module and class. (GH-7807)
https://github.com/python/cpython/commit/06e2029dfa500a42e3565ed7ba8573412f153d1c


--

___
Python tracker 

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

Re: Writing an assembler in Python

[Dan Stromberg]

On Tue, Jun 19, 2018 at 7:33 PM, Steven D'Aprano <
steve+comp.lang.pyt...@pearwood.info> wrote:

> On Tue, 19 Jun 2018 17:41:11 -0700, iansuderman wrote:
>
> > What does the code look like to insert assembler into python and how
> > does that code send information back to python.
> >
> > It seems you wrote that python is a good compiler for assembly.  If
> > possible I want to add assembly to my python.
>
> Who are you talking too?
>

If Python does inline assembler, this is the first I've heard of it.

You can do something kind of like this (but nicer) using
https://pypi.org/project/numba/  Just make sure to use it in "no-python"
mode, not "object" mode.

HTH

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

Re: Writing an assembler in Python

[Steven D'Aprano]

On Tue, 19 Jun 2018 17:41:11 -0700, iansuderman wrote:

> What does the code look like to insert assembler into python and how
> does that code send information back to python.
> 
> It seems you wrote that python is a good compiler for assembly.  If
> possible I want to add assembly to my python.

Who are you talking too?




-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

[issue33855] IDLE: Minimally test every non-startup module.

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Still open for a patch explaining idle_test.template in README.

I opened #33904 for rstrip, #33905 for stackbrowser, #33906 for windows, and 
#33907 for calltips/CallTip renaming.

--
stage: patch review -> test needed

___
Python tracker 

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

[issue33907] IDLE: Rename calltips and CallTips as calltip and Calltip.

[Terry J. Reedy]

Change by Terry J. Reedy :


--
keywords: +patch
pull_requests: +7413
stage: needs patch -> patch review

___
Python tracker 

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

[issue23548] TypeError in event loop finalizer, new in Python 3.4.3

[William Woodall]

William Woodall  added the comment:

Just an update to my previous post. We ran into this issue again, but only 
noticed later because we do not see this problem on Ubuntu Bionic with Python 
3.6.5, but we did see it again when we tested later on Ubuntu Xenial with 
Python 3.5.1.

See: https://github.com/ros2/launch/issues/84

So this seems to be fixed in later versions, unless it's just hidden now within 
the asyncio debug log messages (though I didn't see anything there either, at a 
glance).

--

___
Python tracker 

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

Re: syntax difference

[Steven D'Aprano]

On Wed, 20 Jun 2018 07:52:31 +1000, Chris Angelico wrote:

>> What do you do in python when a local function variable needs to retain
>> its value? I'm sure it can do it, but I bet it's not as simple as how I
>> do it.
>>
> What do you mean, "retain its value"? Do you mean the way closures work?

I think that Bart means something like static variables in C. That's 
something I'd like to see Python get. The simplest work-around we have is 
to put the static variable in the function parameter list as if it were 
an argument of the function.


>> Multi-level loop break? Separators in numbers? I think that one is
>> finally in.
> 
> Multi-level loop break is most commonly spelled "return".

Not in languages that have a multi-level break.


> In over two
> decades of programming, the number of times I've needed to break out of
> multiple loops without breaking out of an entire function can be counted
> on the fingers of one hand. Specifically, three times. In nearly three
> decades.

Okay. The number of times I've wanted an asynchronous function so far has 
been zero, therefore the feature must be useless, right?

*wink*



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: Why an object changes its "address" between adjacent calls?

[Jach Fong]

Terry Reedy at 2018/6/19 PM 08:35 wrote:

On 6/18/2018 8:38 PM, sa...@caprilion.com.tw wrote:

Grant Edwards at 2018/6/18 PM 10:36 wrote:

On 2018-06-17, Jach Fong  wrote:

The "address" of the Font object 'TkDefaultFont' changes, why?


What makes you think it's the same object the second time and not a
new object?


Simply from what the method's name "name-to-font" implied. The font is 
already there, so naturally it should be the same one:-)


'nametofont' is a trivial function returning 'Font(name=name, 
exists=True)'.  As explained before, the address is the address of the 
Python Font interface object, not the tk font structure.  tk has a 
mapping of font names to font structures.  tkinter does not keep a dict 
mapping names or font structures to Font instances, so each call to Font 
returns a new Font instance.



Thank you, Terry. I understand the relationship between Python-
tkinter-tk after you had explained before. Even though, I had to push
myself back to the status when I started this thread, to reply
Grant's question:-)

After switching from comp.lang.python to python-list a while, I noticed
that a thread can become fragile caused by the delay of email. Sometimes
it makes discussion a little confusion:-)

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

Re: syntax difference

[Steven D'Aprano]

On Tue, 19 Jun 2018 14:07:32 -0700, bart4858 wrote:

> Do you think that a feature like swap(x,y) literally only works on two
> simple variables?

I think that if you write "x" and "y", you mean placeholder names that 
stand in for arbitrary variable names, not expressions. That's the common 
and usual meaning.

I *know* that when I write "x" and "y", I mean names. Not integer 
literals, not class definition statements, not while loops, not 
try...except blocks, not GOTO labels. If I intended something other than 
simple names, I would have said so.

So how about accepting that your communication was less than clear, 
instead of trying to deflect the blame for miscommunication on the reader?

As the writer, you are responsible for your own words, and if they are 
open to misinterpretation, the correct response is "Mea culpa", not "why 
didn't you read what I meant, instead of what I wrote, you idiot?"



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: Writing an assembler in Python

[iansuderman]

What does the code look like to insert assembler into python and how does that 
code send information back to python.

It seems you wrote that python is a good compiler for assembly.  If possible I 
want to add assembly to my python.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue33855] IDLE: Minimally test every non-startup module.

[miss-islington]

miss-islington  added the comment:


New changeset cbaee6fe02d22f357c2edf4e463c240d5df22f14 by Miss Islington (bot) 
in branch '3.7':
bpo-33855: Still more edits and minimal tests for IDLE  (GH-7784)
https://github.com/python/cpython/commit/cbaee6fe02d22f357c2edf4e463c240d5df22f14


--

___
Python tracker 

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

[issue33855] IDLE: Minimally test every non-startup module.

[miss-islington]

miss-islington  added the comment:


New changeset 90209a172c5b629f512cf292a22950285a2c3d81 by Miss Islington (bot) 
in branch '3.6':
bpo-33855: Still more edits and minimal tests for IDLE  (GH-7784)
https://github.com/python/cpython/commit/90209a172c5b629f512cf292a22950285a2c3d81


--

___
Python tracker 

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

Re: syntax difference

[bart4858]

Some of that can be done. It may not need specific support.

But my intention is to have an ordinary language for everyday coding not one 
that can only be understood by CS professors.

Mine is unusual in that I can drop features I rarely use, which means that 
everything in it gets good use. Including multi-level breaks.

And the core language can stay small (or smallish - it's not Forth). Which I 
think is where we came in.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue33301] Add __contains__ to pathlib

[Andrew Berger]

Andrew Berger  added the comment:

I think the idea is that either a subdir or file could be valid inputs. 

So `Path('/usr/bar') in Path('/etc/foo')` return True if 
`Path('/etc/foo/usr/bar')` is either a dir or file.

As for PurePath, I did overlook that accessing an inode via a call to stat 
would be considered filesystem IO. So putting that method in Path (if this 
turns out to be a good idea) is the better option. Thanks

--

___
Python tracker 

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

[issue33855] IDLE: Minimally test every non-startup module.

[miss-islington]

Change by miss-islington :


--
pull_requests: +7412

___
Python tracker 

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

[issue33855] IDLE: Minimally test every non-startup module.

[miss-islington]

Change by miss-islington :


--
pull_requests: +7411
stage: test needed -> patch review

___
Python tracker 

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

[issue33855] IDLE: Minimally test every non-startup module.

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 4d92158f4c3917fc4fbfebff15224e74782abf79 by Terry Jan Reedy in 
branch 'master':
bpo-33855: Still more edits and minimal tests for IDLE  (GH-7784)
https://github.com/python/cpython/commit/4d92158f4c3917fc4fbfebff15224e74782abf79


--

___
Python tracker 

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

[issue33839] IDLE tooltips.py: refactor and add docstrings and tests

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I am going to change calltips.py and CallTips to calltip.py and Calltip in 
#33907, but will not change tooltip.py there as I would expect a merge 
conflict.  Once the change is made elsewhere, change should be made to tooltip 
and test_tooltip directly.

--
dependencies: +IDLE: Rename calltips and CallTips as calltip and Calltip.

___
Python tracker 

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

[issue33907] IDLE: Rename calltips and CallTips as calltip and Calltip.

[Terry J. Reedy]

New submission from Terry J. Reedy :

Rename module 'calltips' as 'calltip'
1. 'calltips' and 'windows' are the only two plural module names.
2. 'calltip' fits better with 'calltip_w' (which may, however, be merged 
in 'calltip'.
Module rename can be checked as with 'window', #33906.

and class CallTips as Calltip.
3. This may be the only plural class name.
4. ToolTip is singular and will be changed to Tooltip in #33839.  See the 6/17 
and 6/19 messages.
Needed changes in other modules will not necessarily be caught by existing 
tests.  Use grep for 'CallTips'.

I will not change tooltip.py (currently not used or tested) as change here 
would conflict with current PR for #33839.

--
assignee: terry.reedy
components: IDLE
messages: 320004
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE: Rename calltips and CallTips as calltip and Calltip.
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue33904] IDLE: In rstrip, rename class RstripExtension as Rstrip

[Terry J. Reedy]

Change by Terry J. Reedy :


--
title: IDLE: In rstrip, change class RstripExtension to Rstrip -> IDLE: In 
rstrip, rename class RstripExtension as Rstrip

___
Python tracker 

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

[issue33906] IDLE: rename windows.py as window.py

[Terry J. Reedy]

Change by Terry J. Reedy :


--
title: IDLE: change windows.py to window.py -> IDLE: rename windows.py as 
window.py

___
Python tracker 

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

[issue33906] IDLE: change windows.py to window.py

[Terry J. Reedy]

New submission from Terry J. Reedy :

Change module 'windows' to 'window'::
1. 'calltips' and 'windows' are the only two plural module names.
2. The top menu entry was changed from 'Windows' to 'Window' some time ago.
3. 'windows' is also a OS.

With all modules at least imported in a test, all imports in modules should be 
checked, so running test_idle after changing the file name should reveal all 
imports that need to be changed.

What could have been the 'Window' class is called 'ListedTopLevel'.

--
assignee: terry.reedy
components: IDLE
messages: 320003
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE: change windows.py to window.py
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue30811] A venv created and activated from within a virtualenv uses the outer virtualenv's site-packages rather than its own.

[Josh Holland]

Change by Josh Holland :


--
nosy: +anowlcalledjosh

___
Python tracker 

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

Re: syntax difference

[Chris Angelico]

On Wed, Jun 20, 2018 at 8:14 AM,   wrote:
> Features? Important ones? Go back 40 years and see how important they were 
> then. Most of them,nobody had heard of, and would not be meaningful.
>

Let's see. Forty years ago was 1978. Databasing was a little bit
important. I mean, not much... just that it was the main reason a lot
of companies would buy computers. It was a simpler time; a time when
people didn't have to worry about silly things like "standards",
because you would just always buy from the same manufacturer. You
didn't have to worry about "security" because people didn't send
information out on the internet. Oh, and people like you weren't
writing programming languages, so nobody cared about checklists.

Fortunately, it's 2018, and we have this little thing called the
"internet" in every single person's home, more or less. Internet
protocols, consequently, are fairly important.

> Now do the same with my list - most are programming features that could be 
> understood and appreciated even then.
>
> Finally, imagine going forward 40 years; how many of those acronyms will 
> still be relevant?

Here are all of the acronyms I used:

* TCP, UDP: Definitely going to be relevant for the foreseeable future.
* HTTP, SMTP, IMAP: Probably going to be relevant.
* SSL: Definitely relevant, although you might prefer to use the
acronym "TLS" today, and maybe others in the future. But the concept
will still stand, and libraries will migrate.
* JSON, MIME: Likely to be relevant. Maybe others will be as well, but
without tipping these out.
* GUI: Definitely relevant. So long as we have humans, GUIs will be wanted.
* GNU: https://xkcd.com/1508/
* lzma: Maybe, maybe not.
* sha: Definitely.

I'd go with "most of them".

> But anyone still involved in coding algorithms will likely still find some of 
> my features useful. Although the language will long be gone.

Ahh, coding algorithms. Okay. Do you have:

1) A way to guarantee that a function is pure?

2) A simple means of constructing a list/array from another list/array
by performing a transformation on it? ("map" or a comprehension)

3) A simple means of filtering a list/array to only those which fit
some criterion? ("filter" or a comprehension)

4) First-class functions, and closures?

5) A way to easily see whether a function will mutate its arguments?

That's a basic start. If you can do all of those, you might possibly
have a language that is beautifully aimed at whiteboards and
blackboards across the world. Mathematicians will love you.

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

[issue33905] IDLE: stackbrowser.Stackbrowser should accept exception.

[Terry J. Reedy]

New submission from Terry J. Reedy :

Stackbrowser is currently initialized with a traceback and/or the sys.last_xyz 
attributes.  The latter are not set when unittesting;  the test framework 
somehow prevents this.  The tests needed are the ones that will be enabled by 
Stackbrower accepting an exception, which has everything needed.

--
assignee: terry.reedy
components: IDLE
messages: 320002
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE: stackbrowser.Stackbrowser should accept exception.
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

Re: syntax difference

[bart4858]

Features? Important ones? Go back 40 years and see how important they were 
then. Most of them,nobody had heard of, and would not be meaningful.

Now do the same with my list - most are programming features that could be 
understood and appreciated even then.

Finally, imagine going forward 40 years; how many of those acronyms will still 
be relevant?

But anyone still involved in coding algorithms will likely still find some of 
my features useful. Although the language will long be gone.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue33904] IDLE: In rstrip, change class RstripExtension to Rstrip

[Terry J. Reedy]

New submission from Terry J. Reedy :

Rstrip is no longer an extension.  Change all occurrences throughout idlelib, 
including tests.  Some may not be covered in tests.  Branch after #33855 is 
merged.

--
assignee: terry.reedy
components: IDLE
messages: 320001
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE: In rstrip, change class RstripExtension to Rstrip
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

Re: syntax difference

[Chris Angelico]

On Wed, Jun 20, 2018 at 7:41 AM,   wrote:
> I think you're getting a programming language mixed up with a bunch of random 
> libraries.
>
> If you want to do any actual coding rather than scripting, such as 
> implementing some of that stuff, then this is where those basic language 
> features that are missing from core Python become useful.
>

ALL of those features are part of the Python standard library. Every
one of them is something you can do with a plain vanilla Python
installation. They are useful for real-world coding, scripting, or
whatever you want to call it.

> What do you do in python when a local function variable needs to retain its 
> value? I'm sure it can do it, but I bet it's not as simple as how I do it.
>

What do you mean, "retain its value"? Do you mean the way closures work?

> Multi-level loop break? Separators in numbers? I think that one is finally in.

Multi-level loop break is most commonly spelled "return". In over two
decades of programming, the number of times I've needed to break out
of multiple loops without breaking out of an entire function can be
counted on the fingers of one hand. Specifically, three times. In
nearly three decades.

> You can have all your libraries /and/ have fundamental language features at 
> the same time. They are not mutually exclusive.

Of course! Funnily enough, that's what I have with Python. Do you have
both, or do you only have checkbox language features?

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

Re: syntax difference

[bart4858]

I think you're getting a programming language mixed up with a bunch of random 
libraries.

If you want to do any actual coding rather than scripting, such as implementing 
some of that stuff, then this is where those basic language features that are 
missing from core Python become useful.

What do you do in python when a local function variable needs to retain its 
value? I'm sure it can do it, but I bet it's not as simple as how I do it.

Multi-level loop break? Separators in numbers? I think that one is finally in.

You can have all your libraries /and/ have fundamental language features at the 
same time. They are not mutually exclusive.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue33901] test_dbm_gnu.test_reorganize() failed on x86-64 High Sierra 3.x

[STINNER Victor]

STINNER Victor  added the comment:

Thanks Serhiy and Xiang for the reviews and to help to debug this bug.

--

___
Python tracker 

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

[issue33901] test_dbm_gnu.test_reorganize() failed on x86-64 High Sierra 3.x

[STINNER Victor]

STINNER Victor  added the comment:

Ok, the test have been fixed in 3.6, 3.7 and master. I added a private version 
number in master.

If someone wants to add a public version number, please go ahead but open a new 
issue.

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

[issue33901] test_dbm_gnu.test_reorganize() failed on x86-64 High Sierra 3.x

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 00f9edb98dd64e14daf5c44f303deca5cbc3cdeb by Victor Stinner in 
branch 'master':
bpo-33901: Add _gdbm._GDBM_VERSION (GH-7794)
https://github.com/python/cpython/commit/00f9edb98dd64e14daf5c44f303deca5cbc3cdeb


--

___
Python tracker 

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

Re: syntax difference

[Chris Angelico]

On Wed, Jun 20, 2018 at 7:07 AM,   wrote:
> Do you think that a feature like swap(x,y) literally only works on two simple 
> variables? X and y represent any two lvalue expressions. For example, a[I] 
> and a[I+1]. Python will evaluate each twice.
>
> My version sets up two references then exchanges what they point to with one 
> bytecode.
>

Congratulations. You have something that you, personally, consider
important, and which has zero externally-visible impact. But what
about the couple dozen important features that I listed?

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

Re: syntax difference

[bart4858]

Do you think that a feature like swap(x,y) literally only works on two simple 
variables? X and y represent any two lvalue expressions. For example, a[I] and 
a[I+1]. Python will evaluate each twice.

My version sets up two references then exchanges what they point to with one 
bytecode. 

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

[issue33855] IDLE: Minimally test every non-startup module.

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Change windows.py to window.py, in line with change of menu.  Should be safer 
with everything imported.

--
stage: patch review -> test needed

___
Python tracker 

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

Re: syntax difference

[Ian Kelly]

On Tue, Jun 19, 2018 at 1:42 PM Rick Johnson
 wrote:
>
> On Tuesday, June 19, 2018 at 1:02:52 PM UTC-5, Ian wrote:
> > On Mon, Jun 18, 2018 at 2:57 PM Rick Johnson
> > It's a "burden" (actually, a helpful tool) to the
> > programmer either way: whether it's in a comment or an
> > annotation, it's the programmer's job to keep it correct.
> > Whether it's in a comment or an annotation, it's up to the
> > programmer to read it or not in order to better understand
> > the code. How it would be a burden on the machine either
> > way is beyond me.
>
> If you had read my argument from the beginning of the
> thread, you would have known that: whilst i never liked the
> idea of Python having any kind of type annotations, i made
> it very clear at multiple places in this debate, that i am
> willing to grit my teeth and accept them *IF* the python dev
> team would be kind enough to (1) force all type annotation
> to be declared as comments, or (2) release a tool that will
> remove type-hints (error free) from scripts.

No, that's been perfectly clear. What befuddles me is your continued
insistence that the devs must do this, rather than writing the tool
yourself.

And yes, it would have to be (2), because (1) is obviously out of the
question. The only way to "force" type annotations to be comments
would be to remove the function annotation feature altogether, which
would be hugely backward-incompatible.

> > > After all, it's the Python way.
> >
> > Whatever this platitude is supposed to mean. I don't see
> > "shift the work of programming onto the machine" anywhere
> > in the Zen of Python.
>
> Ian, you an i both know that at our current level of
> technological evolution, we do not yet have machines that
> program themselves. That would require artificial
> intelligence. However, while our machines cannot yet program
> themselves, we certainly can offload many of the _burdens_
> we programmers face onto these machines. And parsing, just
> like computation, is one of those repetitive burdens that
> machines perform far much better than any human ever could.

Type hints are no different in this regard than any other part of the
program. You seem to be under the impression that the less you have to
read, the easier it is. And while that's true to an extent, I'll
remind you that comments, type hints, readable code, all of it are
written primarily for consumption by *humans*, not the machine.

"Programs must be written for people to read, and only incidentally
for machines to execute." - Hal Abelson

> Moreover, Guido has written and has been documented in
> interviews detailing the core principles of Python's design,
> and i dare any of you to find me one quote from those early
> days that gushed about type annotations.

Sorry, I won't be baited by your rhetorical nonsense. Function
annotations are a feature, not a "core principle". You could equally
well ask to find quotes about decorators, or coroutines, or list
comprehensions, or metaclasses, etc. etc.

> > > The beauty of type-hint comments is that even without
> > > striping the type-hint comment from the source code, a
> > > programmer can more easily ignore a type-hint comment than
> > > the interleaved type-hint. This is especially true if the
> > > programmer uses an editor which has syntax hilighting. My
> > > syntax hilighter colors all comments a light gray. So
> > > therefore, i can skip block and blocks of comments in a
> > > fraction of second simply by quickly scanning down to the
> > > first line that is not grayed out.
> >
> > This paragraph was the reason for my statement about "if
> > you're trying to make the case for type hints being treated
> > like comments, this isn't it". If this is not trying to
> > justify why type hints should be in comments (so you can
> > brush them under the rug and pretend they don't exist),
> > then what is it?
>
> Why shouldn't i have the right to "brush type-hints under
> the rug" Ian? After all, if the code *I* write doesn't
> belong to *ME*, well then, who *HELL* does it belong to?

You're deflecting. This goes on for several more angry paragraphs, so
I'm just going to ignore it and skip ahead.

> So with that in mind, i cannot understand why Python wants
> to saddle me with type-hints?

You seem to keep forgetting that they're optional. Even if you inherit
a program that uses them, nobody is forcing you to read them, to run
any sort of type analysis over them, or even to retain them. But just
because you can delete them doesn't make anybody obligated to provide
you with a tool that you can't be bothered to write for yourself.

> But what is even more disturbing, is the hostility that is
> being displayed here when i request a simple tool that will
> remove these offensive type-hints.

WRITE IT YOURSELF.

That's not me being hostile, just direct.

> > And for all your desire to have your opinion heard, you
> > seem awfully eager to dismiss the opinions of those who
> > actually like and want type hints the way 

[issue33902] entry_points/console_scripts is too slow

[George King]

George King  added the comment:

OK, thanks. I agree that this is best pursued with the developers of the 
relevant modules. I appreciate your quick and detailed responses!

--

___
Python tracker 

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

[issue33902] entry_points/console_scripts is too slow

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

"It's complicated" :)  But technically speaking they are all separate projects, 
so while there is synergy, CPython itself *imports* some of those to provide 
various tasks, but it doesn't lead their development.  You'll find a lot of the 
same players in all those projects though.

This might be a good resource: https://www.pypa.io/en/latest/

I hope you don't mind, but I am going to close this issue since it's not 
directly related to Python itself.  If you feel otherwise and/or can provide a 
reproducible test case, please do reopen it.

Thanks for your contribution to Python!

--
resolution:  -> third party
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

Re: syntax difference

[Chris Angelico]

On Wed, Jun 20, 2018 at 5:38 AM, Rick Johnson
 wrote:
>> You've been answered time and time again -- the devs are
>> volunteers and are not beholden to do whatever you want
>> just because you don't like it -- yet for some reason you
>> keep asking.
>
> Are you a dev?
>
> Is Chris a Dev?
>
> Is Steven a Dev?
>
>> [...]
>
>> And for all your desire to have your opinion heard, you
>> seem awfully eager to dismiss the opinions of those who
>> actually like and want type hints the way they are.
>
> Did you miss the part where i came to the table and made a
> compromise? Yea -- that part -- the part where i compromised
> to accept these type-hints in exchange for a tool that will
> remove them. Hmm. Is that too much to ask? Surely you don't
> believe that diplomacy is a one-sided compromise, do you?

Well, it looks like that compromise isn't going to happen. Which
means, according to this statement, you are not going to accept type
hints. Congratulations. You have rejected type hints. Now what?

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

Re: syntax difference

[Rick Johnson]

On Tuesday, June 19, 2018 at 1:02:52 PM UTC-5, Ian wrote:
> On Mon, Jun 18, 2018 at 2:57 PM Rick Johnson
[...]
> > The point is, from the POV of the interpreter and the
> > programmer. comments are always going to be comments
> > regardless of whether special purpose tools parse them or
> > not. And given a choice between placing a new burden on a
> > programmer or placing that burden on the machine, we
> > should always choose to place that burden on the
> > _machine_.
> 
> As far as I can tell, you seem to be arguing that putting
> type hints in an annotation somehow puts a burden on the
> programmer, while putting type hints in a comment somehow
> puts a burden on the machine. This makes no sense to me.

And if it's any consolation for you, you'll be happy to know
that i'm not at all surprised to learn this, either.

> It's a "burden" (actually, a helpful tool) to the
> programmer either way: whether it's in a comment or an
> annotation, it's the programmer's job to keep it correct.
> Whether it's in a comment or an annotation, it's up to the
> programmer to read it or not in order to better understand
> the code. How it would be a burden on the machine either
> way is beyond me.

If you had read my argument from the beginning of the
thread, you would have known that: whilst i never liked the
idea of Python having any kind of type annotations, i made
it very clear at multiple places in this debate, that i am
willing to grit my teeth and accept them *IF* the python dev
team would be kind enough to (1) force all type annotation
to be declared as comments, or (2) release a tool that will
remove type-hints (error free) from scripts.  

And while i don't particularly enjoy repeating myself, i am
hoping that perhaps this time it might sink in...

> > After all, it's the Python way.
> 
> Whatever this platitude is supposed to mean. I don't see
> "shift the work of programming onto the machine" anywhere
> in the Zen of Python.

Ian, you an i both know that at our current level of
technological evolution, we do not yet have machines that
program themselves. That would require artificial
intelligence. However, while our machines cannot yet program
themselves, we certainly can offload many of the _burdens_
we programmers face onto these machines. And parsing, just
like computation, is one of those repetitive burdens that
machines perform far much better than any human ever could.

Furthermore, and contrary to popular belief, the full
philosophy of Python is not as neatly contained in the Zen
as some may think. No. The Python Zen is merely a list of
style prejudices which attempt to convey the "overall"
philosophy of the stereotypical python programmer. Not a
detailed style guide or an exhaustive rule book.

Moreover, Guido has written and has been documented in
interviews detailing the core principles of Python's design,
and i dare any of you to find me one quote from those early
days that gushed about type annotations.

Go ahead now

Give 'er a go!

> > The beauty of type-hint comments is that even without
> > striping the type-hint comment from the source code, a
> > programmer can more easily ignore a type-hint comment than
> > the interleaved type-hint. This is especially true if the
> > programmer uses an editor which has syntax hilighting. My
> > syntax hilighter colors all comments a light gray. So
> > therefore, i can skip block and blocks of comments in a
> > fraction of second simply by quickly scanning down to the
> > first line that is not grayed out.
> 
> This paragraph was the reason for my statement about "if
> you're trying to make the case for type hints being treated
> like comments, this isn't it". If this is not trying to
> justify why type hints should be in comments (so you can
> brush them under the rug and pretend they don't exist),
> then what is it?

Why shouldn't i have the right to "brush type-hints under
the rug" Ian? After all, if the code *I* write doesn't
belong to *ME*, well then, who *HELL* does it belong to?

Is it not the right of the programmer to decide whether a
named function is more appropriate than a list comprehension
or an anonymous function?

Huh???

Is is not the right of the programmer to decide that string
formatting is more appropriate than string concatenation, or
vice versa?

Hmm???

Correct me if i'm wrong here, but i seem to remember an oft-
sited statement around these parts which says roughly:
"Python is programming for adults" . Meaning, that unlike
more "formalized" languages (such as Java, for instance),
Python does not try to dictate how we must write our code.

Sure, there are certain exceptions to this rule, like forced
indentation, for instance, but, compared to other languages,
Python is perhaps one of the most tolerant when it comes to
freedom.

For instance, Python does not force us to declare private
attribute and public attributes. Nor does it require us to
write setters or getters. Each programmer can decide for
themselves if they want to 

[issue33902] entry_points/console_scripts is too slow

[George King]

George King  added the comment:

Thanks Barry. My question then is, what relationship does cpython have with 
pip, setuptools, distutils and pkg_resources? Since pip comes bundled with 
Python now it seems a little bit closer than "3rd party". Thanks!

--

___
Python tracker 

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

[issue17237] m68k aligns on 16bit boundaries.

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests:  -7408

___
Python tracker 

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

[issue31680] Expose curses library name and version on Python level

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +7410

___
Python tracker 

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

Re: syntax difference

[Jim Lee]

On 06/19/2018 04:13 AM, Ed Kellett wrote:

I think
we're all--still--missing the larger point that "easy to remove" is a
completely stupid metric for judging language features. Seriously. Not a
little bit stupid.

Not if you think of the feature as analogous to cancer.

-Jim

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

[issue27777] cgi.FieldStorage can't parse simple body with Content-Length and no Content-Disposition

[Chris Eykamp]

Chris Eykamp  added the comment:

Packaged patch offered below into PR 7804

https://github.com/python/cpython/pull/7804

--
versions: +Python 3.5

___
Python tracker 

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

[issue33301] Add __contains__ to pathlib

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Not a good idea IMHO.  Why would containment mean the existence of a file in a 
directory?  It could just as well mean that a certain path component is part of 
the path.

Also I don't understand what would e.g. `Path('/usr/bar') in Path('/etc/foo')` 
mean.

As for adding a .exists method to PurePath, I think you're missing the point of 
PurePath here (i.e. its operations *don't* do any IO whatsoever).

--
nosy: +pitrou

___
Python tracker 

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

[issue27777] cgi.FieldStorage can't parse simple body with Content-Length and no Content-Disposition

[Chris Eykamp]

Change by Chris Eykamp :


--
pull_requests: +7409

___
Python tracker 

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

Re: syntax difference

[Grant Edwards]

On 2018-06-19, Steven D'Aprano  wrote:

> I know that Rick's attitude towards reality is that facts are only for 
> other people, and that once he has made up his mind nothing will budge 
> it, *especially* not facts, but for anyone reading this who might be 
> fooled into imagining that Rick has a point, really, no.

Many of us plonked Rick ages ago.  Now we only see his posts when
people followup and quote him.

-- 
Grant Edwards   grant.b.edwardsYow! ... If I had heart
  at   failure right now,
  gmail.comI couldn't be a more
   fortunate man!!

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

[issue17237] m68k aligns on 16bit boundaries.

[INADA Naoki]

Change by INADA Naoki :


--
pull_requests: +7408

___
Python tracker 

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

Re: syntax difference

[Mark Lawrence]

On 19/06/18 18:10, Ian Kelly wrote:

On Tue, Jun 19, 2018 at 3:14 AM Steven D'Aprano
 wrote:


On Mon, 18 Jun 2018 10:01:58 -0700, Rick Johnson wrote:


Steven D'Aprano wrote:
[...]

particular at DropBox, which is (I believe) funding a lot of Guido's
time on this, because they need it.


And now we get to the truth!

Guido's new puppet master is the sole reason why this fine community --
of once free-roaming *STALLIONS*-- is now corralled and saddled with
type-hints!


I know that Rick's attitude towards reality is that facts are only for
other people, and that once he has made up his mind nothing will budge
it, *especially* not facts, but for anyone reading this who might be
fooled into imagining that Rick has a point, really, no.


Don't worry, I think that most people are capable of recognizing it as
an ad-hominem by a troll. Speaking of which, why hasn't Rick been
banned years ago for this kind of crap?



The moderators are mostly thick Yanks who think that rr, Trump and Putin 
are decent people?


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

[issue33717] Enhance test.pythoninfo: meta-ticket for multiple changes

[Xiang Zhang]

Xiang Zhang  added the comment:


New changeset 6aa283a6036f80e5820db2beae98c62745fae96f by Xiang Zhang (Miss 
Islington (bot)) in branch '3.6':
bpo-33717: set terse to True when calling platform.platform in test.pythoninfo 
(GH-7797) (GH-7802)
https://github.com/python/cpython/commit/6aa283a6036f80e5820db2beae98c62745fae96f


--

___
Python tracker 

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

Re: syntax difference

[Ian Kelly]

On Mon, Jun 18, 2018 at 2:57 PM Rick Johnson
 wrote:
>
> On Monday, June 18, 2018 at 2:48:58 PM UTC-5, Ian wrote:
> > I would also note that none of this applies to type hinting
> > in any case. Type hints don't require the programmer to be
> > able to explain anything in natural language, nor are they
> > prone to becoming out-of-sync.
> >
> > Because if they do, then then the type analyzer will
> > complain the very next time you run it. So if you're trying
> > to make the case for type hints being treated like
> > comments, this isn't it.
>
> My point is perfectly clear to anyone who bothers to read it
> in its entirety.

Actually, I responded to this paragraph because it was the only one
that made any sense at all. I didn't consider the rest to be worth of
the post to be worth the time. But if you want, I'll respond to the
rest.

> From the POV of the interpreter, comments are nothing but a
> human crutch that is to be ignored.

This is like saying that from the POV of the interpreter, the keyboard
and monitor are nothing but a human crutch to be ignored. Okay, fine,
but so what?

> And even from the POV of a programmer, comments can be more
> useful if they are ignored than if they are not. Some
> programmers lack the skill required to properly explain the
> workings of an algorithm in natural language, and thus, the
> reader of such a comment will only become confused.
> Likewise, comments are notorious for becoming out-of-sync
> with the code. And at such point, comments are not only
> _confusing_ or _misleading_, no, they have become _lies_.

Already responded to above.

> The point is, from the POV of the interpreter and the
> programmer. comments are always going to be comments
> regardless of whether special purpose tools parse them or
> not. And given a choice between placing a new burden on a
> programmer or placing that burden on the machine, we should
> always choose to place that burden on the _machine_.

As far as I can tell, you seem to be arguing that putting type hints
in an annotation somehow puts a burden on the programmer, while
putting type hints in a comment somehow puts a burden on the machine.
This makes no sense to me. It's a "burden" (actually, a helpful tool)
to the programmer either way: whether it's in a comment or an
annotation, it's the programmer's job to keep it correct. Whether it's
in a comment or an annotation, it's up to the programmer to read it or
not in order to better understand the code. How it would be a burden
on the machine either way is beyond me.

> After all, it's the Python way.

Whatever this platitude is supposed to mean. I don't see "shift the
work of programming onto the machine" anywhere in the Zen of Python.

> The beauty of type-hint comments is that even without
> striping the type-hint comment from the source code, a
> programmer can more easily ignore a type-hint comment than
> the interleaved type-hint. This is especially true if the
> programmer uses an editor which has syntax hilighting. My
> syntax hilighter colors all comments a light gray. So
> therefore, i can skip block and blocks of comments in a
> fraction of second simply by quickly scanning down to the
> first line that is not grayed out.

This paragraph was the reason for my statement about "if you're trying
to make the case for type hints being treated like comments, this
isn't it". If this is not trying to justify why type hints should be
in comments (so you can brush them under the rug and pretend they
don't exist), then what is it?

> I have asked time and time again for someone to directly
> justify why py-dev won't offer a tool to remove the
> interleaved type-hint syntax from scripts.

You've been answered time and time again -- the devs are volunteers
and are not beholden to do whatever you want just because you don't
like it -- yet for some reason you keep asking.

> And yet, this whole thread has been a giant cascade of
> distractions from that one, simple, question.
>
> It is obvious to the impartial reader what is going on here.
>
> There is a systematic campaign of brow beating underway to
> punish those who do not blindly accept the validity of type-
> hints. And any wavering from the the official party line
> will be subject to retributions.

Yeah, just as soon as we finish covering up the moon landing hoax and
chemtrails, we're all going to a secret Hillary Clinton deep state
Illuminati meeting where we'll plan out how to control Python users
forever.

> That is not behavior of a community. A community would care
> for the opinions of all members.

Somebody who actually values the community would not make rude posts
on the mailing list about other members of the community, accusing
them all of being part of some conspiracy and accusing GvR of being a
puppet. All I'm saying, you reap what you sow.

And for all your desire to have your opinion heard, you seem awfully
eager to dismiss the opinions of those who actually like and want type
hints the way they are.

> I 

Re: syntax difference

[Rick Johnson]

On Tuesday, June 19, 2018 at 4:12:10 AM UTC-5, Steven D'Aprano wrote:
[...]
> People have been requesting static typing in Python virtually since Day 
> 1, 

"Day one"??? 

Really? 

"People"???

How many people?

Contrary to to your fuzzy memories, Steven, we all know that Guido _purposely_ 
designed this language to be _dynamic_. Python was never intended to be a 
statically typed language. Not then, and not ever!

Hmm? 

Now you're confusing your own "straw man nostalgia" with actual history. But 
hey, don't allow the facts get in the way of a good lie!
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue33717] Enhance test.pythoninfo: meta-ticket for multiple changes

[Xiang Zhang]

Xiang Zhang  added the comment:


New changeset b2dd5f1b667b37b5d36b39adc3a3aa6ebf59ef0b by Xiang Zhang (Miss 
Islington (bot)) in branch '2.7':
bpo-33717: set terse to True when calling platform.platform in test.pythoninfo 
(GH-7797) (GH-7803)
https://github.com/python/cpython/commit/b2dd5f1b667b37b5d36b39adc3a3aa6ebf59ef0b


--
nosy: +xiang.zhang

___
Python tracker 

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

[issue33901] test_dbm_gnu.test_reorganize() failed on x86-64 High Sierra 3.x

[Barry A. Warsaw]

Change by Barry A. Warsaw :


--
nosy: +barry

___
Python tracker 

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

[issue33902] entry_points/console_scripts is too slow

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

This really isn't enough information to know exactly what's going on in your 
case, but there are things that are known to be slow for CLI startups.  
Probably the biggest contributor is pkg_resources.  Of course, that's a third 
party library that's popular for handling entry points, so it's not really a 
Python problem.  There are some other third party libraries on PyPI that may be 
more performant for you.  Entry point handling is something that I'd like to 
try to address in 3.8 in a manner similar to importlib.resources.

--
nosy: +barry

___
Python tracker 

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

[issue33717] Enhance test.pythoninfo: meta-ticket for multiple changes

[miss-islington]

Change by miss-islington :


--
pull_requests: +7407

___
Python tracker 

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

[issue33717] Enhance test.pythoninfo: meta-ticket for multiple changes

[miss-islington]

Change by miss-islington :


--
pull_requests: +7406

___
Python tracker 

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

[issue33901] test_dbm_gnu.test_reorganize() failed on x86-64 High Sierra 3.x

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

The buildbot is green again!

--

___
Python tracker 

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

Re: syntax difference

[Ian Kelly]

On Tue, Jun 19, 2018 at 3:14 AM Steven D'Aprano
 wrote:
>
> On Mon, 18 Jun 2018 10:01:58 -0700, Rick Johnson wrote:
>
> > Steven D'Aprano wrote:
> > [...]
> >> particular at DropBox, which is (I believe) funding a lot of Guido's
> >> time on this, because they need it.
> >
> > And now we get to the truth!
> >
> > Guido's new puppet master is the sole reason why this fine community --
> > of once free-roaming *STALLIONS*-- is now corralled and saddled with
> > type-hints!
>
> I know that Rick's attitude towards reality is that facts are only for
> other people, and that once he has made up his mind nothing will budge
> it, *especially* not facts, but for anyone reading this who might be
> fooled into imagining that Rick has a point, really, no.

Don't worry, I think that most people are capable of recognizing it as
an ad-hominem by a troll. Speaking of which, why hasn't Rick been
banned years ago for this kind of crap?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Steven D'Aprano]

On Mon, 18 Jun 2018 10:34:54 -0700, Jim Lee wrote:

> The syntax should be defined inside comments

Then you ought to be pleased that from Python 4.0 (or from Python 3.7 
with a ``__future__`` import) annotations will be treated as strings by 
the interpreter.

That makes them effectively special comments like docstrings: they aren't 
executed, only recorded in the object for introspection.

def func(x: int) -> str:

becomes precisely the same as:

def func(x): # type x:int, return:str

except that the comment is attached to the function as a string for 
runtime introspection.


> by the tools that actually
> need to use them.  Let the tools do what they were designed to do.  Let
> the language do what it was designed to do.

Then you should be glad, because the language is designed to do this. 
Annotations in Python are the end result of a long, carefully thought out 
design process.


> If static type checking were a high priority, I would not choose a
> language like Python for the task

You are talking as if "static type checking" were an end in itself. 
That's like saying "If unit tests were a high priority, I would not 
choose a language like C".

Static type-checking is a means to an end. The end is more reliable code 
and making it easier to find bugs. I trust you don't mean to imply that 
you don't need to find bugs in Python code.

If your linter or IDE can tell you that the function you intended to 
return a string can sometimes return None, why is this so horrible?


> - but some people seem to want to beat
> the language into submission as a do-everything-but-wash-my-car
> solution; and in so doing, the language becomes so fragile and bloated
> that people will walk away from it.

Ah, I wondered how long it would be before the "feature X is killing 
Python" FUD reared its ugly head.


> In reading through many of the PEPs, I'm reminded of the saying, "If all
> you have is a hammer, everything looks like a nail".

And when the most advanced tool you've used is a hammer, an electric 
drill looks like a very expensive, awkward to use hammer.



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

Re: [pypy-dev] A quick question for you!

[William ML Leslie]

On 18 June 2018 at 22:18, Etienne Robillard  wrote:
> Hi,
>
> Quick question: Does anyone of you know what is the effect of enabling
> gc.enable() in sitecustomize.py when using PyPy? Can it reduce latency for
> long-lived WSGI applications?
>

gc is enabled by default.  you only need to use gc.enable() if you
have earlier run gc.disable().

-- 
William Leslie

Notice:
Likely much of this email is, by the nature of copyright, covered
under copyright law.  You absolutely MAY reproduce any part of it in
accordance with the copyright law of the nation you are reading this
in.  Any attempt to DENY YOU THOSE RIGHTS would be illegal without
prior contractual agreement.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Rick Johnson]

Rhodri James wrote:
[...]
> It has little flea executioners running around with little flea axes 
> chopping off little flea heads?

Hmm. And who knew that Python-list was really just a homicidal flea circus. Go 
figure!

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

Re: syntax difference

[Rick Johnson]

On Tuesday, June 19, 2018 at 5:21:25 AM UTC-5, Chris Angelico wrote:
> On Tue, Jun 19, 2018 at 8:12 PM, Steven D'Aprano
>  wrote:
> > On Mon, 18 Jun 2018 11:34:40 -0700, Jim Lee wrote:
> >
> >> On 06/18/2018 11:18 AM, Chris Angelico wrote:
> >>> What, fundamentally, is the difference between type hints and
> >>> assertions, such that - in
> >>> your view - one gets syntax and the other is just comments?
> >> Type hints are just that - hints.  They have no syntactic meaning to the
> >> parser, and do not affect the execution path in any way. Therefore, they
> >> are effectively and actually comments.  The way they have been
> >> implemented, though, causes noise to be interspersed with live code and,
> >> as others have said, are difficult to remove or ignore.
> >
> > So let me get this straight...
> >
> > Using annotations is evil, because it intersperses noise with live code:
> >
> > def function(argument: int,
> >  flag: bool,
> >  sequence: list) -> str:
> > ...
> >
> >
> > But using comments is great, because it doesn't:
> >
> > def function(argument,  # type=int,
> >  flag,  # type=bool,
> >  sequence, # type=list):  # type=str
> > ...
> >
> >
> > Okay, I'm glad we cleared that up.
> >
> 
> Isn't it nice how comments, being terminated exclusively by
> end-of-line, allow the introduction of subtle bugs? Let's see how many
> people spot the (presumably deliberate) bug in Steve's code here.

It wasn't deliberate, Chris. But if Steven "presumably" wanted to show us why 
hanging comments are a code smell that most professional programmers will 
avoid, well, he certainly excelled at that, didn't he?

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

[issue33901] test_dbm_gnu.test_reorganize() failed on x86-64 High Sierra 3.x

[miss-islington]

miss-islington  added the comment:


New changeset fe8122d7b7c747fc344dde8467b09de6b5888d01 by Miss Islington (bot) 
in branch '3.6':
bpo-33901: Fix test_dbm_gnu for gdbm 1.15 (GH-7798)
https://github.com/python/cpython/commit/fe8122d7b7c747fc344dde8467b09de6b5888d01


--
nosy: +miss-islington

___
Python tracker 

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

[issue33895] LoadLibraryExW called with GIL held can cause deadlock

[Eryk Sun]

Eryk Sun  added the comment:

In some of these cases, it would be simpler to just remove the explicit dynamic 
linking. 3.6+ doesn't support XP, so CancelIoEx, CreateSymbolicLinkW, 
RegDeleteKeyExW, RegDisableReflectionKey, RegEnableReflectionKey, and 
RegQueryReflectionKey can be linked implicitly. 3.7+ doesn't support Vista, in 
which case GetMaximumProcessorCount can be linked implicitly. (It should be 
GetActiveProcessorCount. See issue 33166.) OTOH, ShellExecuteExW is loaded 
explicitly on purpose to avoid a static dependency on shell32.dll.

--
nosy: +eryksun

___
Python tracker 

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

[issue30345] test_gdb fails on Python 3.6 when built with LTO+PGO

[STINNER Victor]

STINNER Victor  added the comment:

Ok, I pushed a change to the master branch. Now the question is if Python 2.7, 
3.6 and 3.7 should be fixed as well?

I will wait at least one day to see if buildbots are happy.

--

___
Python tracker 

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

[issue30345] test_gdb fails on Python 3.6 when built with LTO+PGO

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 06fe77a84bd29d51506ab2ff703ae585a6121af2 by Victor Stinner in 
branch 'master':
bpo-30345: Add -g to LDFLAGS for LTO (GH-7709)
https://github.com/python/cpython/commit/06fe77a84bd29d51506ab2ff703ae585a6121af2


--

___
Python tracker 

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

Re: curve_fit in scipy

[Gary Herron]

This is a Python forum, but what you are asking is not a Python 
question.  You might find a better source of answers on a scipy specific 
forum.


But here's my attempt at answers:



On 06/19/2018 08:26 AM, sharan.basa...@gmail.com wrote:

Hi All,

I am working out an exercise on curve_fit function available scipy package.

While I understand in general about curve_fit, I am unable to understand the 
following:

params, params_covariance = optimize.curve_fit(test_func, x_data, y_data,
p0=[2, 2])

Firstly, I don't understand why test_func is passed as an argument to cur_fit


You are trying to fit a curve to some data, right.  The curve_fit 
procedure needs to know what curve you are trying to fit.  Is it a 
linear curve, exponential, polynomial or ...?  In this example it's a 
sine function with parameters for regulating amplitude and frequency.  
But it could be any function with any parameters.  To be more precise, 
test_function is not a single function y=f(x), but a whole family of 
functions y=f(x; a,b) where a and b define a particular function.



Secondly, I don't understand how curve_fit knows the number of arguments that 
test_func takes.


Part of the dynamic nature of Python is that a function carries with it 
the number of parameters (as just one among many such properties).  We 
call it "introspection" when we examine such properties of objects.  The 
curve_fit function usees such an introspection to find that 
test_function has two parameters (a and b) defining the family of curves.




Full code is available below for reference:

import numpy as np

# Seed the random number generator for reproducibility
np.random.seed(0)

x_data = np.linspace(-5, 5, num=50)
y_data = 2.9 * np.sin(1.5 * x_data) + np.random.normal(size=50)

# And plot it
import matplotlib.pyplot as plt
plt.figure(figsize=(6, 4))
plt.scatter(x_data, y_data)

from scipy import optimize

def test_func(x, a, b):
 return a * np.sin(b * x)

params, params_covariance = optimize.curve_fit(test_func, x_data, y_data,
p0=[2, 2])

print(params)

plt.figure(figsize=(6, 4))
plt.scatter(x_data, y_data, label='Data')
plt.plot(x_data, test_func(x_data, params[0], params[1]),
  label='Fitted function')

plt.legend(loc='best')

plt.show()


--
Dr. Gary Herron
Professor of Computer Science
DigiPen Institute of Technology
(425) 895-4418

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

[issue33717] Enhance test.pythoninfo: meta-ticket for multiple changes

[Xiang Zhang]

Change by Xiang Zhang :


--
pull_requests: +7405

___
Python tracker 

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

[issue33901] test_dbm_gnu.test_reorganize() failed on x86-64 High Sierra 3.x

[miss-islington]

Change by miss-islington :


--
pull_requests: +7404

___
Python tracker 

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

[issue33901] test_dbm_gnu.test_reorganize() failed on x86-64 High Sierra 3.x

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 13c79c677f9ec9437c82eda72fa1c2d288d8fceb by Victor Stinner in 
branch '3.7':
bpo-33901: Fix test_dbm_gnu for gdbm 1.15 (GH-7798)
https://github.com/python/cpython/commit/13c79c677f9ec9437c82eda72fa1c2d288d8fceb


--

___
Python tracker 

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

[issue33671] Efficient zero-copy for shutil.copy* functions (Linux, OSX and Win)

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +7403

___
Python tracker 

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

[issue33746] testRegisterResult in test_unittest fails in verbose mode

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +7402

___
Python tracker 

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

[issue33901] test_dbm_gnu.test_reorganize() failed on x86-64 High Sierra 3.x

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +7401

___
Python tracker 

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

[issue33901] test_dbm_gnu.test_reorganize() failed on x86-64 High Sierra 3.x

[STINNER Victor]

STINNER Victor  added the comment:


New changeset c44d8e5db6fb9d3847c49e9c9718f2b4cf71f506 by Victor Stinner in 
branch 'master':
bpo-33901: Better test_dbm_gnu.test_reorganize() fix (GH-7795)
https://github.com/python/cpython/commit/c44d8e5db6fb9d3847c49e9c9718f2b4cf71f506


--

___
Python tracker 

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

Re: syntax difference

[Steven D'Aprano]

On Tue, 19 Jun 2018 11:52:22 +0100, Bart wrote:

> On 19/06/2018 11:33, Steven D'Aprano wrote:
>> On Tue, 19 Jun 2018 10:19:15 +0100, Bart wrote:
>> 
>>> * Swap(x,y) (evaluate each once unlike a,y=y,x)
>> 
>> Sigh. Really? You think x,y = y,x evaluates x and y twice?
> 
> Yes.

Well, you would be wrong.

[steve@ando ~]$ python3.5 -c "import dis; dis.dis('x, y = y, x')"
  1   0 LOAD_NAME0 (y)
  3 LOAD_NAME1 (x)
  6 ROT_TWO
  7 STORE_NAME   1 (x)
 10 STORE_NAME   0 (y)
 13 LOAD_CONST   0 (None)
 16 RETURN_VALUE


> Try:
[snip complex example]

Why would I try that? You made a claim that x, y = y, x evaluates x and y 
twice. You didn't say anything about calling a function twice. Of course 
if you call a function twice, the function gets called twice. What does 
your language do?

Shifting the goals posts is not a nice thing to do Bart. You made a claim 
about swapping two named variables, not one about multiple function calls.




-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson

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

curve_fit in scipy

[Sharan Basappa]

Hi All,

I am working out an exercise on curve_fit function available scipy package.

While I understand in general about curve_fit, I am unable to understand the 
following:

params, params_covariance = optimize.curve_fit(test_func, x_data, y_data,
   p0=[2, 2])

Firstly, I don't understand why test_func is passed as an argument to cur_fit
Secondly, I don't understand how curve_fit knows the number of arguments that 
test_func takes.

Full code is available below for reference:

import numpy as np

# Seed the random number generator for reproducibility
np.random.seed(0)

x_data = np.linspace(-5, 5, num=50)
y_data = 2.9 * np.sin(1.5 * x_data) + np.random.normal(size=50)

# And plot it
import matplotlib.pyplot as plt
plt.figure(figsize=(6, 4))
plt.scatter(x_data, y_data)

from scipy import optimize

def test_func(x, a, b):
return a * np.sin(b * x)

params, params_covariance = optimize.curve_fit(test_func, x_data, y_data,
   p0=[2, 2])

print(params)

plt.figure(figsize=(6, 4))
plt.scatter(x_data, y_data, label='Data')
plt.plot(x_data, test_func(x_data, params[0], params[1]),
 label='Fitted function')

plt.legend(loc='best')

plt.show()
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue33895] LoadLibraryExW called with GIL held can cause deadlock

[Tony Roberts]

Tony Roberts  added the comment:

Sure, that's reasonable :)

For my case I have a usable workaround so not back porting it to < 3.8 is fine 
for me. My workaround will just leak the thread state if another thread is in 
__import__, which happens so rarely that it's not really a problem (but not 
rarely enough that blocking is acceptable!). The other cases changed in this PR 
would cause the same issue, but in practice for my application it's unlikely.

Thanks!

--

___
Python tracker 

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

[issue33671] Efficient zero-copy for shutil.copy* functions (Linux, OSX and Win)

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:


New changeset c7f02a965936f197354d7f4e6360f4cfc86817ed by Giampaolo Rodola in 
branch 'master':
bpo-33671 / shutil.copyfile: use memoryview() with dynamic size on Windows 
(#7681)
https://github.com/python/cpython/commit/c7f02a965936f197354d7f4e6360f4cfc86817ed


--

___
Python tracker 

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

[issue30345] test_gdb fails on Python 3.6 when built with LTO+PGO

[STINNER Victor]

STINNER Victor  added the comment:

Very interesting article about PGO and LTO changes in GCC:
https://hubicka.blogspot.com/2018/06/gcc-8-link-time-and-interprocedural.html

See "Early debug info" paragraph.

--

___
Python tracker 

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

[issue33865] [EASY] Missing code page aliases: "unknown encoding: 874"

[STINNER Victor]

STINNER Victor  added the comment:

Prawin Phichitnitikorn: "But for me I'm resolve by adding (...)"

Ok, so can you please give the value of:

* sys.stdin.encoding
* sys.stdout.encoding
* sys.stderr.encoding
* os.device_encoding(0)
* os.device_encoding(1)
* os.device_encoding(2)
* locale.getpreferredencoding(False)

Maybe also the .errors attribute of sys.stdin, sys.stdout and sys.stderr.

--

___
Python tracker 

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