Re: Is it possible to call a class but without a new instance created?

[Jim Lee]

On 06/18/2018 09:22 PM, Jach Fong wrote:

Ben Finney at 2018/6/19 PM 10:20 wrote:

Jach Fong  writes:


Although it passed the first examination, I have no idea if it can
work correctly in the real application:-)


Neither do I. What is the real-world problem you are trying to solve?
Why do you think this (and not some more idiomatic Python feature) is
needed for solving that problem?


No, I don't have any specific application in mind. This idea was just
triggered by a sentence in a Docstring in file font.py.

class Font:
    """Represents a named font.
    Constructor options are:
    ...
    exists -- does a named font by this name already exist?
   Creates a new named font if False, points to the existing font 
if True.

    ...
    """

But honestly I still don't know how it "points to the existing font":-(



If the font exists, the Font object calls this:
    tk.call("font", "configure", self.name, *font)
Otherwise, it calls this:
    tk.call("font", "create", self.name, *font)

The font caching is all handled by Tk, not Python.  The Font object is 
just a wrapper around calls to Tk.


-Jim

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

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

[Etienne Robillard]

Le 2018-06-18 à 22:47, William ML Leslie a écrit :

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().


Good to know man! I didn't knew that.

Thanks for sharing.

Etienne

--
Etienne Robillard
tkad...@yandex.com
https://www.isotopesoftware.ca/

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

Speed of animation with matplotlib.animation

[ast]

Hello

I noticed that the speed of animations made
with module matplotlib.animation always seems
wrong.

Here is a small example for demonstration purpose:


import numpy as np
import matplotlib.pyplot as plt
import matplotlib.animation as animation

fig = plt.figure()
ax = fig.add_subplot(111)
txt = ax.text(0.5, 0.5, "", transform=ax.transAxes)

dt = 0.1  # 100 ms

def animate(i):
txt.set_text("time= %.1f" % (i*dt))
return txt,


ani = animation.FuncAnimation(fig=fig,
  func=animate,
  frames = 200,
  interval = dt,
  blit = True,
  repeat=False)

plt.show()

--
so function animate is ran every interval=dt=100ms
with i=0, 1, 2, ..., 200 and it simply prints time
(i*dt) on the figure.

The animation should last 20s, but on my computer
it is twice faster

A link to FuncAnimation doc: https://bit.ly/2t5UKjA

interval : number, optional

Delay between frames in milliseconds. Defaults to 200.


What's wrong ?
--
https://mail.python.org/mailman/listinfo/python-list

Re: Speed of animation with matplotlib.animation

[Steven D'Aprano]

On Tue, 19 Jun 2018 10:34:55 +0200, ast wrote:

> The animation should last 20s, but on my computer it is twice faster
[...]
> What's wrong ?

Try replacing your CPU with one half as fast.

*wink*


(Sorry for the bad advice, I couldn't resist.)

-- 
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 Mon, 18 Jun 2018 09:39:21 -0700, Rick Johnson wrote:

> On Monday, June 18, 2018 at 6:57:27 AM UTC-5, Steven D'Aprano wrote:
>> I still think that Python has been going nowhere but downhill ever
>> since extended slicing was added in version 1.4.
> 
> Apples to oranges!


That whooshing noise you heard was the point going over your head.



-- 
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: Speed of animation with matplotlib.animation

[Peter Otten]

ast wrote:

> I noticed that the speed of animations made
> with module matplotlib.animation always seems
> wrong.

> dt = 0.1  # 100 ms
 
> interval : number, optional
> 
>  Delay between frames in milliseconds. Defaults to 200.
> 
> 
> What's wrong ?

>From the above I would conclude that you get a 100 ms delay with

dt = 100


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

Re: syntax difference

[Steven D'Aprano]

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.

People have been requesting static typing in Python virtually since Day 
1, and certainly since Python 1.5. Guido has been talking about it 
publicly since at least 2004:

https://www.artima.com/weblogs/viewpost.jsp?thread=85551

a few years before DropBox was even a startup.


-- 
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: Speed of animation with matplotlib.animation

[ast]

Le 19/06/2018 à 10:57, Peter Otten a écrit :

ast wrote:


I noticed that the speed of animations made
with module matplotlib.animation always seems
wrong.



dt = 0.1  # 100 ms
  

interval : number, optional

  Delay between frames in milliseconds. Defaults to 200.


What's wrong ?



From the above I would conclude that you get a 100 ms delay with


dt = 100




So the animation should last 200*0.1 = 20s
but it is twice faster
--
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Bart]

On 19/06/2018 06:08, Chris Angelico wrote:

On Tue, Jun 19, 2018 at 1:46 PM, Dan Stromberg  wrote:

Great languages are small but extensible, easy to read, and don't require
learning a lot before you can get started writing code or reading someone
else's code.

Great languages: C and Scheme.  And Python.

But isn't Lua smaller than Python?  That thought worries me a little.


It's a lot smaller. And that worries me ONLY to the extent that I
might, at some point, have to write something in Lua. I would much
rather use a richer language than a poorer one, any day.

A well-designed language has linear complexity, quadratic power. You
learn new language constructs and they are completely orthogonal; you
use those constructs and they interact infinitely. Python isn't quite
100% there (there are some odd edge cases), but it's close.



My own dynamic language is much smaller than Python, much less dynamic, 
much less extendable, and lower level.


Yet it might have a dozen highly useful features, ones I consider basic, 
that are already built-in and Just Work without having to grapple with 
innumerable, incompatible add-ons.


(What, I have to list them? Let's see:

* Goto (yes this /can/ be very useful)

* Pointers (this allows some of the features below)

* Swap(x,y) (evaluate each once unlike a,y=y,x)

* Reference parameters

* Mutable records

* Mutable and in-place modifiable strings

* Named constants

* Simple enums

* 'Tabledata' (too hard to explain; mix of enums and linked tables)

* Integer sets (Pascal-like sets)

* Bit indexing (eg. a.[i] to get the i'th bit, or a.[0..7])

* Switch statement (like C)

* Case statement (switch but for any types and for runtime expressions)

* N-way select (n|a,b,c,...|z); only one expr evaluated, z is default)

* Increment/decrement ops

* C-style packed struct types

* Direct access to native-code functions in external DLL/.so files

* Type punning

* Byte-code compiler will always compile all modules of app to single-
  byte-code file (very fast too)

* The interpreter is a single executable file. (Distribute any app as 
one exe plus one byte-code program file; or they can be trivially 
combined into one file)


* Built-in read statement: readln a,b,c

* Bit arrays (including 1, 2 and 4-bit elements)

* Packed arrays of C-style types

* View-slices

* Stop or 'stop x' (not a big feature, but it's there).

* 'main' function replaces all the '__main__ business; it will be called 
first if present.


* Dedicated loop statements for endless loop and repeat N times

Is that a dozen yet? Sorry it's about two dozen, of things which I don't 
think are in Python, or which may require add-ons.)


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

Re: Speed of animation with matplotlib.animation

[Gregory Ewing]

Steven D'Aprano wrote:


The animation should last 20s, but on my computer it is twice faster


Try replacing your CPU with one half as fast.


Or push the Turbo button to slow it down to 4.77MHz.

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

Re: Is it possible to call a class but without a new instance created?

[Jach Fong]

Jim Lee at 2018/6/19 PM 03:44 wrote:



On 06/18/2018 09:22 PM, Jach Fong wrote:

Ben Finney at 2018/6/19 PM 10:20 wrote:

Jach Fong  writes:


Although it passed the first examination, I have no idea if it can
work correctly in the real application:-)


Neither do I. What is the real-world problem you are trying to solve?
Why do you think this (and not some more idiomatic Python feature) is
needed for solving that problem?


No, I don't have any specific application in mind. This idea was just
triggered by a sentence in a Docstring in file font.py.

class Font:
    """Represents a named font.
    Constructor options are:
    ...
    exists -- does a named font by this name already exist?
   Creates a new named font if False, points to the existing font 
if True.

    ...
    """

But honestly I still don't know how it "points to the existing font":-(



If the font exists, the Font object calls this:
     tk.call("font", "configure", self.name, *font)
Otherwise, it calls this:
     tk.call("font", "create", self.name, *font)


If the Font was called through nametofont, then the font is None
and neither will be called:-)

--Jach

The font caching is all handled by Tk, not Python.  The Font object is 
just a wrapper around calls to Tk.


-Jim



---
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 Mon, 18 Jun 2018 13:52:24 -0700, Rick Johnson wrote:

> 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 say that as if the core developers were obligated to cater to your 
every idle whim or passing fancy.

Let me answer your question directly: they haven't written this tool for 
you because they don't have to pander to your idiosyncrasies.



-- 
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: Speed of animation with matplotlib.animation

[Peter Otten]

ast wrote:

> Le 19/06/2018 à 10:57, Peter Otten a écrit :
>> ast wrote:
>> 
>>> I noticed that the speed of animations made
>>> with module matplotlib.animation always seems
>>> wrong.
>> 
>>> dt = 0.1  # 100 ms
>>   
>>> interval : number, optional
>>>
>>>   Delay between frames in milliseconds. Defaults to 200.
>>>
>>>
>>> What's wrong ?
>> 
>>>From the above I would conclude that you get a 100 ms delay with
>> 
>> dt = 100
>> 
>> 
> 
> So the animation should last 200*0.1 = 20s
> but it is twice faster

No, with dt = 100 it should last

200 * 100ms = 20.000ms = 20s

with dt = 0.1 it should last

200 * 0.1ms = 20ms = 0.02s

but your computer is probably not fast enough for that.


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

Re: syntax difference

[Chris Angelico]

On Tue, Jun 19, 2018 at 7:19 PM, Bart  wrote:
> My own dynamic language is much smaller than Python, much less dynamic, much
> less extendable, and lower level.
>
> Yet it might have a dozen highly useful features, ones I consider basic,
> that are already built-in and Just Work without having to grapple with
> innumerable, incompatible add-ons.
>
> (What, I have to list them? Let's see:
>
> * Goto (yes this /can/ be very useful)
>
> * Pointers (this allows some of the features below)
>
> * Swap(x,y) (evaluate each once unlike a,y=y,x)
>
> * Reference parameters
>
> * Mutable records
>
> * Mutable and in-place modifiable strings
>
> * Named constants
>
> * Simple enums
>
> * 'Tabledata' (too hard to explain; mix of enums and linked tables)
>
> * Integer sets (Pascal-like sets)
>
> * Bit indexing (eg. a.[i] to get the i'th bit, or a.[0..7])
>
> * Switch statement (like C)
>
> * Case statement (switch but for any types and for runtime expressions)
>
> * N-way select (n|a,b,c,...|z); only one expr evaluated, z is default)
>
> * Increment/decrement ops
>
> * C-style packed struct types
>
> * Direct access to native-code functions in external DLL/.so files
>
> * Type punning
>
> * Byte-code compiler will always compile all modules of app to single-
>   byte-code file (very fast too)
>
> * The interpreter is a single executable file. (Distribute any app as one
> exe plus one byte-code program file; or they can be trivially combined into
> one file)
>
> * Built-in read statement: readln a,b,c
>
> * Bit arrays (including 1, 2 and 4-bit elements)
>
> * Packed arrays of C-style types
>
> * View-slices
>
> * Stop or 'stop x' (not a big feature, but it's there).
>
> * 'main' function replaces all the '__main__ business; it will be called
> first if present.
>
> * Dedicated loop statements for endless loop and repeat N times
>
> Is that a dozen yet? Sorry it's about two dozen, of things which I don't
> think are in Python, or which may require add-ons.)

Great! Now, for this next test, you are also allowed to count any
standard library that is included as part of your single-file
distribution (and thus isn't an "add-on"). Do you have:

* Arbitrary-precision integers?
* Unicode strings?
* The ability to create TCP sockets, and bind, listen, and connect them?
* Ditto for UDP and Unix sockets?
* Easy ways to create servers and clients for common internet
protocols eg HTTP, SMTP, IMAP?
* Out-of-the-box handling for SSL certificates?
* An efficient way to multiplex many concurrent connections eg select()?
* Reading and writing files relative to a previously-opened directory
(openat etc)?
* Parsers for common transport formats and encodings eg JSON, MIME, etc?
* A unit test framework?
* A GUI framework?
* An interactive interpreter, with GNU readline (on supported platforms)?
* An argument parser?
* A secure and reliable way to generate random numbers?
* Any form of compression library (eg zlib, lzma)?
* Parsers for any form of compressed file (eg zip, gz)?
* Inbuilt access to at least one database (SQLite3, PostgreSQL, etc)?
* Trigonometric functions (sin/cos/tan)?
* High-resolution timers?
* Cryptographic hashing functions (eg sha256)?
* A regex engine? (Bonus points for having two or more. Maybe negative points.)
* Date/time calculations using the Gregorian calendar? (Bonus points
for supporting other calendars.)
* Dare I ask: Multiple inheritance?

ALL of these are fully supported, out-of-the-box, by both Python and
Pike, the two languages I happen to have full source and docs for at
my fingertips. I would expect that most or all of these are also
supported by most other modern languages; some won't include a GUI
framework, others don't have arbitrary-precision integers, etc, but
I'd predict scores of 75% or better across the board. What's your
language's score?

And no, these are not cherry-picked from the most obscure features I
could find. Every single one of these is of immense value to
real-world code. Even multiple inheritance, which I listed last
because it's a bit of a hairy one, and is part of the reason that very
few languages will score 100%. But can you at least score *some*?

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

Re: syntax difference

[Steven D'Aprano]

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.




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

[Chris Angelico]

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.

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

Re: Speed of animation with matplotlib.animation

[ast]

Le 19/06/2018 à 11:47, Peter Otten a écrit :

ast wrote:


Le 19/06/2018 à 10:57, Peter Otten a écrit :

ast wrote:






No, with dt = 100 it should last

200 * 100ms = 20.000ms = 20s

with dt = 0.1 it should last

200 * 0.1ms = 20ms = 0.02s

but your computer is probably not fast enough for that.




You are right. I didn't noticed that interval was in ms
Ty
--
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Steven D'Aprano]

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?


The rest of your list seemed like a very nice list of low-level 
operations, if you want a low-level language with lots of redundancy and 
functional duplication. Like:

* Integer sets (Pascal-like sets)

Why do you need them if you have real sets?

* Increment/decrement ops

Why do you need them if you have + and - operators?

* Stop or 'stop x'

Why do you need a syntactic feature if a simple exit() function could do 
the job?

* Dedicated loop statements for endless loop and repeat N times

Why do you need them when regular while and for loops will work?

(Mind you, I do like the N-way select.)


But Python isn't a low-level language. You make a big deal of having 
named constants. Okay, great. Do you support Unicode strings and 
Decimals? Does your language come with a functioning web server? Can it 
send email straight out of the box?

Yeah, I get it, you like your language to have lots and lots and lots of 
syntax to do *slightly* different things. But it doesn't seem to be so 
good at doing application level functionality. Its basically just a less 
efficient, slightly prettier C.

Assuming that people who aren't you can even get it to compile. When I 
tried, it wouldn't compile on my computer.


Oh, with your pointer syntax -- how do you guarantee that your language 
is safe?



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

[Chris Angelico]

On Tue, Jun 19, 2018 at 8:33 PM, Steven D'Aprano
 wrote:
> Yeah, I get it, you like your language to have lots and lots and lots of
> syntax to do *slightly* different things. But it doesn't seem to be so
> good at doing application level functionality. Its basically just a less
> efficient, slightly prettier C.

With the word "dynamic" in its description, of course. That's VERY
important. C is not a dynamic language. Bart's language is dynamic.
That makes it unimaginably better.

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

Python Training in Bangalore

[sandy star]

 Python Training in Bangalore Best Python Training Courses in Bangalore –  
Marathahalli, BTM Layout, Rajajinagar & Jaya Nagar. We train the students from 
basic level to advanced concepts with a real-time environment. We are the Best 
Python Training Institute in bangalore.


URL : 
https://www.besanttechnologies.com/training-courses/python-training-institute-in-bangalore
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Bart]

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. Try:

count=0

def fn():
global count
count=count+1
return 1

a=[10,20,30,40]
b=[1,2,3,4]

a[1],b[fn()] = b[fn()],a[1]

print (a)
print (b)
print ("Count",count)

b[fn()] is evaluated twice.


(May reply to other points of yours and Chris' in a few days.)

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

Re: syntax difference

[Chris Angelico]

On Tue, Jun 19, 2018 at 8:52 PM, 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. Try:
>
> count=0
>
> def fn():
> global count
> count=count+1
> return 1
>
> a=[10,20,30,40]
> b=[1,2,3,4]
>
> a[1],b[fn()] = b[fn()],a[1]
>
> print (a)
> print (b)
> print ("Count",count)
>
> b[fn()] is evaluated twice.

Ahh right. You never mentioned that your swap targets had complex
expressions in them. What a horrible pity that Python requires you to
be explicit that fn should be called only once:

idx = fn()
a[1], b[idx] = b[idx], a[1]

It's the price you pay for orthogonality, I guess.

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

Re: syntax difference

[Bart]

On 19/06/2018 11:45, Chris Angelico wrote:

On Tue, Jun 19, 2018 at 8:33 PM, Steven D'Aprano
 wrote:

Yeah, I get it, you like your language to have lots and lots and lots of
syntax to do *slightly* different things. But it doesn't seem to be so
good at doing application level functionality. Its basically just a less
efficient, slightly prettier C.


With the word "dynamic" in its description, of course. That's VERY
important. C is not a dynamic language. Bart's language is dynamic.
That makes it unimaginably better.

ChrisA




What does 'dynamic' mean?

For many it just means that variables have dynamic type. Which is 
exactly what mine has (and with automatic memory management which goes 
along with that).


Some people may not even be aware of just how dynamic Python is.

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

Re: syntax difference

[Ed Kellett]

On 2018-06-19 11:21, Chris Angelico wrote:
> 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.

Hardly subtle.

It does also make them considerably easier to remove from code. 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. What would Python look like if every new feature had
to be possible to grep out?



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

Re: syntax difference

[Chris Angelico]

On Tue, Jun 19, 2018 at 9:07 PM, Bart  wrote:
> On 19/06/2018 11:45, Chris Angelico wrote:
>>
>> On Tue, Jun 19, 2018 at 8:33 PM, Steven D'Aprano
>>  wrote:
>>>
>>> Yeah, I get it, you like your language to have lots and lots and lots of
>>> syntax to do *slightly* different things. But it doesn't seem to be so
>>> good at doing application level functionality. Its basically just a less
>>> efficient, slightly prettier C.
>>
>>
>> With the word "dynamic" in its description, of course. That's VERY
>> important. C is not a dynamic language. Bart's language is dynamic.
>> That makes it unimaginably better.
>>
>> ChrisA
>>
>
>
> What does 'dynamic' mean?

Good question. You're the one who called your language "dynamic".

> For many it just means that variables have dynamic type. Which is exactly
> what mine has (and with automatic memory management which goes along with
> that).

So what does it mean for a variable to have dynamic type, then?

Automatic memory management is different again. You can have typed
variables (often called static typing), typed data (often called
dynamic typing), and automatic garbage collection. They're all
completely orthogonal. And they're not absolutes, although I don't
often see partially-typed-data in a language. (Partially-typed
variables are common.) If you're not using "dynamic typing" to mean
"values have types", you're going to have to define it.

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

Re: syntax difference

[Rhodri James]

On 18/06/18 21:39, Chris Angelico wrote:

On Tue, Jun 19, 2018 at 6:25 AM, Rick Johnson
 wrote:

Chris Angelico wrote:
[...]

assert """
, ", ";print('Will I print?');\
"';print("Or will I?");\
';print("What about me?");'''\
print("And me? Where endeth");"""\
print('the assertion?');\


Chris, that's not code...

That's a syntactical representation of some random flea circus.


Fortunately, my Python interpreter is able to execute flea circuses.


It has little flea executioners running around with little flea axes 
chopping off little flea heads?


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Chris Angelico]

On Tue, Jun 19, 2018 at 9:33 PM, Rhodri James  wrote:
> On 18/06/18 21:39, Chris Angelico wrote:
>>
>> On Tue, Jun 19, 2018 at 6:25 AM, Rick Johnson
>>  wrote:
>>>
>>> Chris Angelico wrote:
>>> [...]

 assert """
 , ", ";print('Will I print?');\
 "';print("Or will I?");\
 ';print("What about me?");'''\
 print("And me? Where endeth");"""\
 print('the assertion?');\
>>>
>>>
>>> Chris, that's not code...
>>>
>>> That's a syntactical representation of some random flea circus.
>>
>>
>> Fortunately, my Python interpreter is able to execute flea circuses.
>
>
> It has little flea executioners running around with little flea axes
> chopping off little flea heads?
>

Nah, it doesn't decapitate. It hangs them. It's a Python, after all.
But yeah, you have the right idea.

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

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

[Terry Reedy]

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:

C:\Python34\Doc>py
Python 3.4.4 (v3.4.4:737efcadf5a6, Dec 20 2015, 19:28:18) [MSC v.1600 32
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.

import tkinter as tk
root = tk.Tk()
tk.Label(root, text='label one', font='TkDefaultFont').pack()
from tkinter import font
font.nametofont('TkDefaultFont')



font.nametofont('TkDefaultFont')






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.


--
Terry Jan Reedy

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

Re: syntax difference

[Steven D'Aprano]

On Tue, 19 Jun 2018 12:13:30 +0100, 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.

+1


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

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

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

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

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

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

[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

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 hav

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

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

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

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 empl

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

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

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

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]

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

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]

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

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

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

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

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

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

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

[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

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

Re: syntax difference

[Gregory Ewing]

Bart wrote:

a[1],b[fn()] = b[fn()],a[1]


I suppose if you find yourself doing heaps of swaps with
complicated indexes it could be useful to have a swap
primitive. In my experience it's a pretty rare thing to
want to do, though.

Also it only covers one special case of all possible
permutations. It won't help you with a, b, c = b, c, a
for example.

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