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

[Chris Angelico]

On Mon, Jun 18, 2018 at 2:48 PM, Jach Fong  wrote:
> After looking into the \tkiniter\font.py source file, triggered by Jim's
> hint on my previous subject "Why an object changes its "address" between
> adjacent calls?", I get more confused.
>
> Below was quoted from the font.py:
> 
> def nametofont(name):
> """Given the name of a tk named font, returns a Font representation.
> """
> return Font(name=name, exists=True)
>
> 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.
> ...
> """
>
> def __init__(self, root=None, font=None, name=None, exists=False,
>  **options):
> ...
> --
> From my understanding, the __init__ method was called after the instance
> was created, that's why the __init__ has a self parameter, right? Then,
> how is it possible "...points to the existing font if True"? I didn't
> see any clue in __init__ doing this.
>
> I also make a test of my own and it fails too.
>
 class A:
> ... objs = []
> ... def __init__(self, exists=False):
> ... if exists:  self = self.objs[0]
> ... else:  self.objs.append(self)
> ...
 a0 = A()
 id(a0)
> 35569968
 a1 = A(exists=True)
 id(a1)
> 35572336
>
> What I expect is that id(a0) and id(a1) has the same value. They should
> points to the same object.

Yes, what you want is possible; but you need a slightly different
method. Assigning to 'self' doesn't do anything - it's not magical,
it's just a parameter. Instead, look into overriding __new__; that's
how, for instance, the int() constructor can return cached objects.

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

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

[Ben Finney]

Jach Fong  writes:

> I also make a test of my own and it fails too.
>
> >>> class A:
> ... objs = []
> ... def __init__(self, exists=False):
> ... if exists:  self = self.objs[0]

The function parameters (bound here to the names ‘self’, ‘exists’) are
in the local function scope. After the function ends, the scope of those
names ends; those name bindings no longer affect anything. So, changing
what ‘self’ refers to has no effect on the A instance that exists.

In other words: Creating the instance is the responsibility of the
constructor method (a class method named ‘__new__’), and that instance
is what gets passed to the instance initialiser (an instance method
named ‘__init__’).

The initialiser has no control over what instance gets passed in, and no
control over that same instance being returned from the constructor.

> What I expect is that id(a0) and id(a1) has the same value. They
> should points to the same object.

You can't get that effect from within the instance initialiser. What you
need to do is change the class constructor (named ‘__new__’), and that's
a more advanced topic I leave you to research on your own.

-- 
 \  “Now Maggie, I’ll be watching you too, in case God is busy |
  `\   creating tornadoes or not existing.” —Homer, _The Simpsons_ |
_o__)  |
Ben Finney

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

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

[Peter Otten]

Jach Fong wrote:

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

Yes, this is possible in Python, by writing a custom __new__ method. An 
extreme example:

>>> class Three:
... def __new__(*args): return 3
... 
>>> a = Three()
>>> b = Three()
>>> a
3
>>> b
3
>>> a is b
True

But this is not what is done with the tkinter Font class. Most tkinter 
classes refer to a tcl/tk object and so does Font.

import tkinter as tk
from tkinter.font import Font

root = tk.Tk()

a = Font(root, name="foo", size=10, exists=False)

label = tk.Label(root, text="hello", font=a)
label.pack()

def update_foo():
b = Font(root, name="foo", size=20, exists=True)
# two distinct Font objects referring to the same underlying tcl font.
assert a is not b


button = tk.Button(root, text="update foo font to 20pt", command=update_foo)
button.pack()

root.mainloop()

Here the b = Font(...) creates another wrapper for the "foo" font and 
updates its size in the process so that the label's appearance is updated, 
too.


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

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

[Terry Reedy]

On 6/18/2018 12:48 AM, Jach Fong wrote:

After looking into the \tkiniter\font.py source file, triggered by Jim's
hint on my previous subject "Why an object changes its "address" between
adjacent calls?", I get more confused.

Below was quoted from the font.py:

def nametofont(name):
     """Given the name of a tk named font, returns a Font representation.
     """
     return Font(name=name, exists=True)

class Font:
     """Represents a named font.


tkinter abbreviates tk interface.  A Python tkinter Font instance 
represents a tk named font structure. It has a hidden pointer to the tk 
structure.  The same is true of all instances of tkinter widgets 
classes.  Each has a hidden pointer to a tk widget



     Constructor options are:
     ...
     exists -- does a named font by this name already exist?


Does a *tk* named font exist?

    Creates a new named font if False, points to the existing font 
if True.


Again, 'font' here means a tk structure, not a python instance.  Each 
call to Font returns a new python instance.  But for Fonts, it may or 
may not point to a new tk structure.



     ...
     """

     def __init__(self, root=None, font=None, name=None, exists=False,
  **options):
     ...


One can mostly ignore the parallel existence of python instances and tk 
structures.  But they can get out of sync during shutdown.  If t is an 
instance of Text, t.destroy() causes tkinter to tell tk to destroy the 
tk widget, leaving t useless.  Similarly, if 'del t' deletes the last 
reference to the Python instance, it may disappear, leaving the tk 
widget possibly unaccessible.


--
Terry Jan Reedy


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

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

[Terry Reedy]

To answer the question of the title, which is a bit different from the 
question in the text, yes.  type(None)() always returns the singleton 
None object.  (And one can write a singleton class in Python also.) 
bool() always returns one of False or True.  int() and str() may return 
either a new or old object.  For such immutables, it does not matter as 
long at the object has the correct value.  As others said, this is all 
handled in a __new__ method.  But none of this has much to do with 
tkinter instances.


On 6/18/2018 5:09 AM, Terry Reedy wrote:

On 6/18/2018 12:48 AM, Jach Fong wrote:

After looking into the \tkiniter\font.py source file, triggered by Jim's
hint on my previous subject "Why an object changes its "address" between
adjacent calls?", I get more confused.

Below was quoted from the font.py:

def nametofont(name):
 """Given the name of a tk named font, returns a Font representation.
 """
 return Font(name=name, exists=True)

class Font:
 """Represents a named font.


tkinter abbreviates tk interface.  A Python tkinter Font instance 
represents a tk named font structure. It has a hidden pointer to the tk 
structure.  The same is true of all instances of tkinter widgets 
classes.  Each has a hidden pointer to a tk widget



 Constructor options are:
 ...
 exists -- does a named font by this name already exist?


Does a *tk* named font exist?

    Creates a new named font if False, points to the existing font 
if True.


Again, 'font' here means a tk structure, not a python instance.  Each 
call to Font returns a new python instance.  But for Fonts, it may or 
may not point to a new tk structure.



 ...
 """

 def __init__(self, root=None, font=None, name=None, exists=False,
  **options):
 ...


One can mostly ignore the parallel existence of python instances and tk 
structures.  But they can get out of sync during shutdown.  If t is an 
instance of Text, t.destroy() causes tkinter to tell tk to destroy the 
tk widget, leaving t useless.  Similarly, if 'del t' deletes the last 
reference to the Python instance, it may disappear, leaving the tk 
widget possibly unaccessible.





--
Terry Jan Reedy


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

Re: syntax difference

[Bart]

On 18/06/2018 01:10, Chris Angelico wrote:

On Mon, Jun 18, 2018 at 9:30 AM, Rick Johnson
 wrote:

On Sunday, June 17, 2018 at 2:07:40 PM UTC-5, Jim Lee wrote:


IMHO, trying to shoehorn static type checking on top of a dynamically
typed language shows that the wrong language was chosen for the job.


Exactly.

I'm not against the idea of Python growing a new feature.
Features are great. My objection is concerned merely with
the "how" it is implemented, not the "why" it was
implemented.

"Type-hint comments" would allow:

  (1) those who need them, to use them.

  (2) those who don't care about them, to totally ignore
  them.

  (3) and those who utterly *HATE* them, to write a simply
  little function which will strip them from any and all
  source code they might be forced to maintain.


A. Isn't it cute, how he thinks that comments are easier to remove
than other elements equally well defined in the grammar?


You're right in that neither task is that trivial.

I can remove comments by writing a tokeniser which scans Python source 
and re-outputs tokens one at a time. Such a tokeniser normally ignores 
comments.


But to remove type hints, a deeper understanding of the input is needed. 
I would need a parser rather than a tokeniser. So it is harder.


Both methods would fail with source code that exists as a string 
constant (for exec() for example), or source code that is synthesised at 
runtime.


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

Re: syntax difference

[Chris Angelico]

On Mon, Jun 18, 2018 at 8:33 PM, Bart  wrote:
> On 18/06/2018 01:10, Chris Angelico wrote:
>>
>> On Mon, Jun 18, 2018 at 9:30 AM, Rick Johnson
>>  wrote:
>>>
>>> On Sunday, June 17, 2018 at 2:07:40 PM UTC-5, Jim Lee wrote:
>>>
 IMHO, trying to shoehorn static type checking on top of a dynamically
 typed language shows that the wrong language was chosen for the job.
>>>
>>>
>>> Exactly.
>>>
>>> I'm not against the idea of Python growing a new feature.
>>> Features are great. My objection is concerned merely with
>>> the "how" it is implemented, not the "why" it was
>>> implemented.
>>>
>>> "Type-hint comments" would allow:
>>>
>>>   (1) those who need them, to use them.
>>>
>>>   (2) those who don't care about them, to totally ignore
>>>   them.
>>>
>>>   (3) and those who utterly *HATE* them, to write a simply
>>>   little function which will strip them from any and all
>>>   source code they might be forced to maintain.
>>
>>
>> A. Isn't it cute, how he thinks that comments are easier to remove
>> than other elements equally well defined in the grammar?
>
>
> You're right in that neither task is that trivial.
>
> I can remove comments by writing a tokeniser which scans Python source and
> re-outputs tokens one at a time. Such a tokeniser normally ignores comments.
>
> But to remove type hints, a deeper understanding of the input is needed. I
> would need a parser rather than a tokeniser. So it is harder.

They would actually both end up the same. To properly recognize
comments, you need to understand enough syntax to recognize them. To
properly recognize type hints, you need to understand enough syntax to
recognize them. And in both cases, you need to NOT discard important
information like consecutive whitespace.

So in both cases, you would probably end up with something like 2to3.
The effective work is going to be virtually identical. And there's
another complication, if you want any form of generic tool. You have
to ONLY remove certain comments, not others. For instance, you
probably should NOT remove copyright/license comments.

> Both methods would fail with source code that exists as a string constant
> (for exec() for example), or source code that is synthesised at runtime.
>

Sure, but I would just consider that to be outside the scope.

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

Re: Metasyntactic thingies

[Rhodri James]

On 17/06/18 10:09, Steven D'Aprano wrote:

But what placeholder names do you use for functions, methods or other
actions? As in, placeholder verbs rather than nouns?

Aside from such boring ones as "do_work" and similar, the only
placeholder verb I can think of is frobnicate.

Does anyone else have any?


Sometimes I "mangle()" things, but I'm usually boring. 
"do_something()", "do_something_else()" or (if I'm feeling particularly 
nostalgic and helpless) "do_something_muttley()".


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

ANN: Version 0.1.5 of sarge (a subprocess wrapper library) has been released.

[Vinay Sajip via Python-list]

Version 0.1.5 of Sarge, a cross-platform library which wraps the 
subprocessmodule in the standard library, has been released.
What changed?-
- Fixed #37: Instead of an OSError with a "no such file or directory" message,  
a ValueError is raised with a more informative "Command not found" message.
- Fixed #38: Replaced ``async`` keyword argument with ``async_``, as ``async``  
has become a keyword in Python 3.7.
- Fixed #39: Updated tutorial example on progress monitoring.
What does Sarge do?---
Sarge tries to make interfacing with external programs from yourPython 
applications easier than just using subprocess alone.
Sarge offers the following features:
* A simple way to run command lines which allows a rich subset of Bash-style 
shell command syntax, but parsed and run by sarge so that youcan run on Windows 
without cygwin (subject to having those commandsavailable):
>>> from sarge import capture_stdout>>> p = capture_stdout('echo foo | cat; 
>>> echo bar')>>> for line in p.stdout: print(repr(line))...'foo\n''bar\n'
* The ability to format shell commands with placeholders, such thatvariables 
are quoted to prevent shell injection attacks.
* The ability to capture output streams without requiring you toprogram your 
own threads. You just use a Capture object and then youcan read from it as and 
when you want.
* The ability to look for patterns in captured output and to 
interactaccordingly with the child process.
Advantages over subprocess---
Sarge offers the following benefits compared to using subprocess:
* The API is very simple.
* It's easier to use command pipelines - using subprocess out of thebox often 
leads to deadlocks because pipe buffers get filled up.
* It would be nice to use Bash-style pipe syntax on Windows, butWindows shells 
don't support some of the syntax which is useful, like&&, ||, |& and so on. 
Sarge gives you that functionality on Windows,without cygwin.
* Sometimes, subprocess.Popen.communicate() is not flexible enough forone's 
needs - for example, when one needs to process output a line ata time without 
buffering the entire output in memory.
* It's desirable to avoid shell injection problems by having theability to 
quote command arguments safely.
* subprocess allows you to let stderr be the same as stdout, but notthe other 
way around - and sometimes, you need to do that.
Python version and platform 
compatibility-
Sarge is intended to be used on any Python version >= 2.6 and istested on 
Python versions 2.6, 2.7, 3.3, 3.4, 3.5, 3.6 and 3.7 on Linux,Windows, and Mac 
OS X (not all versions are tested on all platforms,but sarge is expected to 
work correctly on all these versions on allthese platforms).
Finding out more
You can read the documentation at
http://sarge.readthedocs.org/
There's a lot more information, with examples, than I can put intothis post.
You can install Sarge using "pip install sarge" to try it out. Theproject is 
hosted on BitBucket at
https://bitbucket.org/vinay.sajip/sarge/
And you can leave feedback on the issue tracker there.
I hope you find Sarge useful!
Regards,
Vinay Sajip
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Bart]

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

On Mon, Jun 18, 2018 at 8:33 PM, Bart  wrote:




You're right in that neither task is that trivial.

I can remove comments by writing a tokeniser which scans Python source and
re-outputs tokens one at a time. Such a tokeniser normally ignores comments.

But to remove type hints, a deeper understanding of the input is needed. I
would need a parser rather than a tokeniser. So it is harder.


They would actually both end up the same. To properly recognize
comments, you need to understand enough syntax to recognize them. To
properly recognize type hints, you need to understand enough syntax to
recognize them. And in both cases, you need to NOT discard important
information like consecutive whitespace.


No. If syntax is defined on top of tokens, then at the token level, you 
don't need to know any syntax. The process that scans characters looking 
for the next token, will usually discard comments. Job done.


It is very different for type-hints as you will need to properly parse 
the source code.


As a simpler example, if the task was the eliminate the "+" symbol, that 
would be one kind of token; it would just be skipped when encountered. 
But if the requirement to eliminate only unary "+", and leave binary 
"+", then that can't be done at tokeniser level; it will not know the 
context.


(The matter of leading white space sometimes being important, is a minor 
detail. It just becomes a token of its own.)



So in both cases, you would probably end up with something like 2to3.
The effective work is going to be virtually identical. And there's
another complication, if you want any form of generic tool. You have
to ONLY remove certain comments, not others. For instance, you
probably should NOT remove copyright/license comments.


What will those look like? If copyright/licence comments have their own 
specific syntax, then they just become another token which has to be 
recognised.


The main complication I can see is that, if this is really a one-time 
source-to-source translator so that you will be working with the result, 
then usually you will want to keep the comments.


Then it is a question of more precisely defining the task that such a 
translator is to perform.


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

Re: syntax difference

[Chris Angelico]

On Mon, Jun 18, 2018 at 9:16 PM, Bart  wrote:
> On 18/06/2018 11:45, Chris Angelico wrote:
>>
>> On Mon, Jun 18, 2018 at 8:33 PM, Bart  wrote:
>
>
>
>>> You're right in that neither task is that trivial.
>>>
>>> I can remove comments by writing a tokeniser which scans Python source
>>> and
>>> re-outputs tokens one at a time. Such a tokeniser normally ignores
>>> comments.
>>>
>>> But to remove type hints, a deeper understanding of the input is needed.
>>> I
>>> would need a parser rather than a tokeniser. So it is harder.
>>
>>
>> They would actually both end up the same. To properly recognize
>> comments, you need to understand enough syntax to recognize them. To
>> properly recognize type hints, you need to understand enough syntax to
>> recognize them. And in both cases, you need to NOT discard important
>> information like consecutive whitespace.
>
>
> No. If syntax is defined on top of tokens, then at the token level, you
> don't need to know any syntax. The process that scans characters looking for
> the next token, will usually discard comments. Job done.

And it also will usually discard formatting (consecutive whitespace,
etc). So unless you're okay with reconstructing
functionally-equivalent code, rather than actually preserving the
original code, you cannot merely tokenize. You have to use a special
form of tokenization that actually keeps all that.

> It is very different for type-hints as you will need to properly parse the
> source code.
>
> As a simpler example, if the task was the eliminate the "+" symbol, that
> would be one kind of token; it would just be skipped when encountered. But
> if the requirement to eliminate only unary "+", and leave binary "+", then
> that can't be done at tokeniser level; it will not know the context.

Right. You can fairly easily reconstruct code that uses a single
newline for any NEWLINE token, and a single space in any location
where whitespace makes sense. It's not so easy to correctly
reconstruct "x*y + a*b" with the original spacing.

> What will those look like? If copyright/licence comments have their own
> specific syntax, then they just become another token which has to be
> recognised.

If they have specific syntax, they're not comments, are they?

> The main complication I can see is that, if this is really a one-time
> source-to-source translator so that you will be working with the result,
> then usually you will want to keep the comments.
>
> Then it is a question of more precisely defining the task that such a
> translator is to perform.

Right, exactly. So you need to do an actual smart parse, which - as
mentioned - is functionally equivalent whether you're stripping
comments or some lexical token.

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

Re: syntax difference

[Steven D'Aprano]

On Sun, 17 Jun 2018 11:10:55 -0700, Rick Johnson wrote:

> Steven D'Aprano wrote:
>> Bart Wrote:
>> > So what's a Type Hint associated with in Python?
>> Since it is a type *hint*, not a type *declaration*, the interpreter
>> can and does ignore it.
> 
> But yet, the _programmer_ cannot ignore it.

The programmer can ignore it, just as they can ignore any other form of 
documentation. Nobody is stopping you from writing:

result = function(the_string=42.5)

if you wish. Adding a type hint doesn't change that.



>> It makes no change at all to the execution model of the language.
> 
> Then why the *HELL* are type-hints an official part of the Python
> language syntax?

Just to annoy you.



-- 
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 06:35:40 +1000, Chris Angelico wrote:

> On Mon, Jun 18, 2018 at 6:23 AM, Marko Rauhamaa 
> wrote:
>> Jim Lee :
>>> IMHO, trying to shoehorn static type checking on top of a dynamically
>>> typed language shows that the wrong language was chosen for the job.
>>
>> I'm also saddened by the type hinting initiative. When you try to be
>> best for everybody, you end up being best for nobody. The niche Python
>> has successfully occupied is huge. Why risk it all by trying to take
>> the whole cake?
> 
> Did you complain when function annotations were introduced back in 2006?
> 
> https://www.python.org/dev/peps/pep-3107/
> 
> That's TWELVE YEARS ago. Over in the Node.js world, that's ... uhh,
> actually that's longer ago than Node.js has even been around. Another
> trendy language is Go... oh wait, that wasn't around in 2006 either.

Yes, but in fairness, people have abandoned Python by the handful for Go 
and Javascript. At the rate people are abandoning Python, in another 10 
or 20 years Python will have dropped to the second most popular language:

http://pypl.github.io/PYPL.html



-- 
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 06:56:56 +1000, Chris Angelico wrote:

> You talk about "risk it all by trying to take the whole cake" as if
> annotations are a change. But if they were already around before you
> first met the language, then they're just part of the language. You
> might as well argue against the += operator or list comprehensions.

I still think that Python has been going nowhere but downhill ever since 
extended slicing was added in version 1.4.



-- 
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 Mon, Jun 18, 2018 at 9:50 PM, Steven D'Aprano
 wrote:
> On Mon, 18 Jun 2018 06:35:40 +1000, Chris Angelico wrote:
>
>> On Mon, Jun 18, 2018 at 6:23 AM, Marko Rauhamaa 
>> wrote:
>>> Jim Lee :
 IMHO, trying to shoehorn static type checking on top of a dynamically
 typed language shows that the wrong language was chosen for the job.
>>>
>>> I'm also saddened by the type hinting initiative. When you try to be
>>> best for everybody, you end up being best for nobody. The niche Python
>>> has successfully occupied is huge. Why risk it all by trying to take
>>> the whole cake?
>>
>> Did you complain when function annotations were introduced back in 2006?
>>
>> https://www.python.org/dev/peps/pep-3107/
>>
>> That's TWELVE YEARS ago. Over in the Node.js world, that's ... uhh,
>> actually that's longer ago than Node.js has even been around. Another
>> trendy language is Go... oh wait, that wasn't around in 2006 either.
>
> Yes, but in fairness, people have abandoned Python by the handful for Go
> and Javascript. At the rate people are abandoning Python, in another 10
> or 20 years Python will have dropped to the second most popular language:
>
> http://pypl.github.io/PYPL.html
>

Oh, I forgot about that. That's why Guido is busily stuffing it with
every feature he possibly can, in the hope that - once Python runs out
of popularity - it'll at least... actually, you know what, I got
nothing.

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

Re: syntax difference

[Steven D'Aprano]

On Sun, 17 Jun 2018 16:46:05 -0700, Rick Johnson wrote:

> People like myself will outright refuse to maintain your code.

Whew Dan, you dodged a bullet there.



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

[Bart]

On 18/06/2018 12:33, Chris Angelico wrote:

On Mon, Jun 18, 2018 at 9:16 PM, Bart  wrote:



What will those look like? If copyright/licence comments have their own
specific syntax, then they just become another token which has to be
recognised.


If they have specific syntax, they're not comments, are they?


So how is it possible for ANY program to determine what kind of comments 
they are?


I've used 'smart' comments myself, which contain special information, 
but are also designed to be very easily detected by the simplest of 
programs which scan the source code. For that purpose, they might start 
with a special prefix so that it is not necessary to parse the special 
information, but just to detect the prefix.


For example, comments that start with #T# (and in my case, that begin at 
the start of a line). Funnily enough, this also provided type 
information (although for different purposes than what is discussed here).




The main complication I can see is that, if this is really a one-time
source-to-source translator so that you will be working with the result,
then usually you will want to keep the comments.

Then it is a question of more precisely defining the task that such a
translator is to perform.


Right, exactly. So you need to do an actual smart parse, which - as
mentioned - is functionally equivalent whether you're stripping
comments or some lexical token.


The subject is type annotation. Presumably there is some way to 
distinguish such a type annotation within a comment from a regular 
comment? Such as the marker I suggested above.


Then the tokeniser just needs to detect that kind of comment rather than 
need to understand the contents.


Although the tokeniser will need to work a little differently by 
maintaining the positions of all tokens within the line, information 
that is usually discarded.


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

Re: syntax difference

[Marko Rauhamaa]

Chris Angelico :

> On Mon, Jun 18, 2018 at 9:50 PM, Steven D'Aprano
>  wrote:
>> On Mon, 18 Jun 2018 06:35:40 +1000, Chris Angelico wrote:
>>
>>> On Mon, Jun 18, 2018 at 6:23 AM, Marko Rauhamaa 
>>> wrote:
 I'm also saddened by the type hinting initiative. When you try to
 be best for everybody, you end up being best for nobody. The niche
 Python has successfully occupied is huge. Why risk it all by trying
 to take the whole cake?
>>>
>>> Did you complain when function annotations were introduced back in
>>> 2006?
>>> [...]
>>
>> Yes, but in fairness, people have abandoned Python by the handful for
>> Go and Javascript. At the rate people are abandoning Python, in
>> another 10 or 20 years Python will have dropped to the second most
>> popular language:
>>
>> http://pypl.github.io/PYPL.html
>>
>
> Oh, I forgot about that. That's why Guido is busily stuffing it with
> every feature he possibly can, in the hope that - once Python runs out
> of popularity - it'll at least... actually, you know what, I got
> nothing.

So the point *was* popularity!? I suspected as much.


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

Re: Python list vs google group

[Gene Heskett]

On Friday 15 June 2018 23:52:12 Gregory Ewing wrote:

> Jim Lee wrote:
> > It was so long ago that I forgot some of the
> > details, but it boiled down to the TWAIN driver pushing the SCSI bus
> > out of spec.
>
> Clearly you didn't sacrifice enough goats!
>
> https://odetocode.com/blogs/scott/archive/2004/09/22/scsi-is-not-magic
>.aspx
>
> --
> Greg

This biggest single thing wrong with any of those old scsi interfaces is 
the bus's 5 volt isolation diode, the designer speced a shotkey(sp) 
diode, and some damned bean counter saw the price diff and changed it to 
a std si power diode in the BOM on the way to the production line, 
thereby destroying the headroom of the logic 1 signal level by lowering 
the supply voltage to the resistive terms used by nominally .6 volts, 
the diff in the forward drop. Back when you could run over to the shack 
and get a shotkey diode, you could make any of them work like a charm.

The other choice was to find a higher voltage to run the terms on, 5.75 
volts would have been lovely but made of pure unobtainium. But combine 
the si diode, and a psu fading with age and down to 4.85 volts on the 5 
volt line and you were doomed.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Flask failure

[T Berger]

On Friday, June 15, 2018 at 1:48:16 PM UTC-4, Elismar Luz wrote:
> Address already in use!

Hi Elismar,

I'm new to Python and didn't understand your post when I first read it. 

Thanks, 

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

Re: syntax difference

[Marko Rauhamaa]

Jim Lee :
> Really?  Wow.  I'd hate to live in your world!  Just because something
> exists, it can't be challenged or questioned.  Got it!

No need to get overly agitated just because someone says something
preposterous.


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

Re: Understanding memory location of Python variables

[Daniel Montecillo]

I am also wondering about this behavior. Thank you Chris A for providing the 
explanation.

On Jun 16, 2018, at 5:45 PM, Chris Angelico 
mailto:ros...@gmail.com>> wrote:

On Sun, Jun 17, 2018 at 2:38 AM,  mailto:ip.b...@gmail.com>> 
wrote:
Hi everyone,

I'm intrigued by the output of the following code, which was totally contrary 
to my expectations. Can someone tell me what is happening?

myName = "Kevin"
id(myName)
47406848
id(myName[0])
36308576
id(myName[1])
2476000

I expected myName[0] to be located at the same memory location as the myName 
variable itself. I also expected myName[1] to be located immediately after 
myName[0].


A string or array in C is allocated in contiguous memory. Python,
however, is not C. What you're looking at is the identities of
objects, not the memory locations of bytes. Everything you're assuming
about C should be discarded.

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


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

Re: Python list vs google group

[Alister via Python-list]

On Fri, 15 Jun 2018 09:32:05 -0700, T Berger wrote:

> On Friday, June 15, 2018 at 11:55:59 AM UTC-4, Chris Angelico wrote:
>> Perhaps quantity is not the important thing here.
> 
> It is the important thing. I'm stuck with a problem and still waiting
> for replies to my email. I've decided to repost my problem here, so
> we'll see whether my hypothesis holds water.
> 
> Tamara

i still beg to differ & agree with Chris. quality is what counts
which would you prefer 100 wrong/contradictory answers or one correct one*


* i accept that even here for any moderately complex question you are 
still likely to get contradictory answers



-- 
Iron Law of Distribution:
Them that has, gets.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Ed Kellett]

On 2018-06-18 13:18, Chris Angelico wrote:
> 1) Parse the code, keeping all the non-essential parts as well as the
> essential parts.
> 2) Find the comments, or find the annotations
> 3) If comments, figure out if they're the ones you want to remove.
> 4) Reconstruct the file without the bits you want to remember.
> 
> Step 3 is removed if you're using syntactic annotations. Otherwise,
> they're identical.

It's likely that Python comments are much easier to remove than
arbitrary bits of Python syntax--you need to know the answer to "am I in
a string literal?", which is a lexical analysis problem you could hack
together a solution for over the course of about one coffee, as opposed
to "where exactly am I in the Python parse tree?", which is... harder.
The information you need to keep track of and later reconstruct is
substantially simpler, too.

I don't think "they're hard to mechanically remove" is a particularly
good argument against type hints, but considered on its own it probably
is true.



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

Re: Understanding memory location of Python variables

[Jeremy Black]

Also, I don't think you can rely on memory being allocated sequentially any
more now that everyone has implemented some level of ASLR.

https://en.wikipedia.org/wiki/Address_space_layout_randomization

On Sat, Jun 16, 2018 at 12:22 PM Alister via Python-list <
python-list@python.org> wrote:

> On Sat, 16 Jun 2018 13:19:04 -0400, Joel Goldstick wrote:
>
> > On Sat, Jun 16, 2018 at 12:38 PM,   wrote:
> >> Hi everyone,
> >>
> >> I'm intrigued by the output of the following code, which was totally
> >> contrary to my expectations. Can someone tell me what is happening?
> >>
> > myName = "Kevin"
> > id(myName)
> >> 47406848
> > id(myName[0])
> >> 36308576
> > id(myName[1])
> >> 2476000
> >>
> >> I expected myName[0] to be located at the same memory location as the
> >> myName variable itself. I also expected myName[1] to be located
> >> immediately after myName[0].
> >> --
> >> https://mail.python.org/mailman/listinfo/python-list
> >
> > Others can probably give a more complete explanation, but small numbers,
> > and apparently letters are cached since they are so common.
>
> also ID is not necessarily a memory location (at least not according to
> the language specification)
> the standard cpython implementation does user the memory location for an
> object's ID but this is an implementation detail
>
> if you are tying to make use of ID in any way to manipulate computer
> memory your program is fundamentaly broken
>
>
>
> --
> Can you MAIL a BEAN CAKE?
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Vincent Vande Vyvre]

Le 18/06/18 à 06:48, Jach Fong a écrit :

After looking into the \tkiniter\font.py source file, triggered by Jim's
hint on my previous subject "Why an object changes its "address" between
adjacent calls?", I get more confused.

Below was quoted from the font.py:

def nametofont(name):
    """Given the name of a tk named font, returns a Font representation.
    """
    return Font(name=name, exists=True)

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.

    ...
    """

    def __init__(self, root=None, font=None, name=None, exists=False,
 **options):
    ...
--
From my understanding, the __init__ method was called after the instance
was created, that's why the __init__ has a self parameter, right? Then,
how is it possible "...points to the existing font if True"? I didn't
see any clue in __init__ doing this.

I also make a test of my own and it fails too.

>>> class A:
... objs = []
... def __init__(self, exists=False):
... if exists:  self = self.objs[0]
... else:  self.objs.append(self)
...
>>> a0 = A()
>>> id(a0)
35569968
>>> a1 = A(exists=True)
>>> id(a1)
35572336

What I expect is that id(a0) and id(a1) has the same value. They 
should points to the same object.



Best Regards,
Jach Fong




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


Hi,


What you try to do is called a /singleton./

A classic example :

class Foo:
    _instance = None
    def __new__(cls, *args, **kwargs):
    if cls._instance is None:
    cls._instance = super(Foo, cls).__new__(cls, *args, **kwargs)
    return cls._instance

    def __init__(self, ...):

        ...


Vincent

Send at Mon, 18 Jun 2018 09:17:21 +0200

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

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

[Chris Angelico]

On Mon, Jun 18, 2018 at 5:17 PM, Vincent Vande Vyvre
 wrote:
> What you try to do is called a /singleton./

In this case, not necessarily a singleton, but returning a cached
object that's the same for any given argument. Basically, interned
objects. But yes, the same idea.

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

Re: Python list vs google group

[Peter Otten]

Gene Heskett wrote:

> This biggest single thing wrong with any of those old scsi interfaces is
> the bus's 5 volt isolation diode, the designer speced a shotkey(sp)
> diode, and some damned bean counter saw the price diff and changed it to

Is this a case of  ?

https://en.wikipedia.org/wiki/Walter_H._Schottky


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

Re: syntax difference

[Chris Angelico]

On Mon, Jun 18, 2018 at 10:07 PM, Bart  wrote:
> On 18/06/2018 12:33, Chris Angelico wrote:
>>
>> On Mon, Jun 18, 2018 at 9:16 PM, Bart  wrote:
>
>
>>> What will those look like? If copyright/licence comments have their own
>>> specific syntax, then they just become another token which has to be
>>> recognised.
>>
>>
>> If they have specific syntax, they're not comments, are they?
>
>
> So how is it possible for ANY program to determine what kind of comments
> they are?
>
> I've used 'smart' comments myself, which contain special information, but
> are also designed to be very easily detected by the simplest of programs
> which scan the source code. For that purpose, they might start with a
> special prefix so that it is not necessary to parse the special information,
> but just to detect the prefix.
>
> For example, comments that start with #T# (and in my case, that begin at the
> start of a line). Funnily enough, this also provided type information
> (although for different purposes than what is discussed here).

Oh, a specific format of comments? Sorry, I misunderstood.

Yes, it is certainly possible to start with a program that removes all
comments, and then refine it to one which only removes those which
(don't) match some pattern. That's definitely a possibility.

> The subject is type annotation. Presumably there is some way to distinguish
> such a type annotation within a comment from a regular comment? Such as the
> marker I suggested above.
>
> Then the tokeniser just needs to detect that kind of comment rather than
> need to understand the contents.
>
> Although the tokeniser will need to work a little differently by maintaining
> the positions of all tokens within the line, information that is usually
> discarded.

Pretty much, yes. It's going to end up basically in the same place, though:

1) Parse the code, keeping all the non-essential parts as well as the
essential parts.
2) Find the comments, or find the annotations
3) If comments, figure out if they're the ones you want to remove.
4) Reconstruct the file without the bits you want to remember.

Step 3 is removed if you're using syntactic annotations. Otherwise,
they're identical.

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

A quick question for you!

[Etienne Robillard]

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?


Thanks,

Etienne

--

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

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

Re: Python list vs google group

[Gene Heskett]

On Monday 18 June 2018 09:16:10 Peter Otten wrote:

> Gene Heskett wrote:
> > This biggest single thing wrong with any of those old scsi
> > interfaces is the bus's 5 volt isolation diode, the designer speced
> > a shotkey(sp) diode, and some damned bean counter saw the price diff
> > and changed it to
>
> Is this a case of  ?
>
> https://en.wikipedia.org/wiki/Walter_H._Schottky

So its spelled with two t's.

Concentrating on my spelling mistake, you probably missed my point 
entirely. But then you are not a CET either so the rest of my 
explanation may not have been in reach as it passed by at a pretty good 
technical altitude.  Sigh...

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

Technical altitude, was Re: Python list vs google group

[Peter Otten]

Gene Heskett wrote:

> On Monday 18 June 2018 09:16:10 Peter Otten wrote:
> 
>> Gene Heskett wrote:
>> > This biggest single thing wrong with any of those old scsi
>> > interfaces is the bus's 5 volt isolation diode, the designer speced
>> > a shotkey(sp) diode, and some damned bean counter saw the price diff
>> > and changed it to
>>
>> Is this a case of  ?
>>
>> https://en.wikipedia.org/wiki/Walter_H._Schottky
> 
> So its spelled with two t's.
> 
> Concentrating on my spelling mistake, you probably missed my point
> entirely. But then you are not a CET either so the rest of my
> explanation may not have been in reach as it passed by at a pretty good
> technical altitude.  Sigh...
> 

I'm doomed. Right?

:)

Other than that I find it hard to believe that a "bean counter" can change a 
technical spec. He may put pressure on the designer, but when the designer 
gives in he's still responsible for the resulting technical problems.

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

Re: syntax difference

[Steven D'Aprano]

On Sun, 17 Jun 2018 12:07:14 -0700, Jim Lee wrote:

> IMHO, trying to shoehorn static type checking on top of a dynamically
> typed language shows that the wrong language was chosen for the job.


The experience of computer languages like Lisp, Smalltalk/StrongTalk, 
Erlang, Racket, Javascript variant Typescript, and PHP variant Hack (to 
mention only a few) shows that type hinting on top of dynamic languages 
can and does work very well.

As a human programmer, you surely perform your own ad hoc type checking 
when you write and debug code. When reading a function like this:

# from the calender.py module in the standard library
def isleap(year):
"""Return True for leap years, False for non-leap years."""
return year % 4 == 0 and (year % 100 != 0 or year % 400 == 0)

naturally you reason that year is probably an integer, not a list of 
strings, and if you see code call:

isleap("hello")

you almost certainly realise it will fail without needing to run the 
code. Having an automated checker or linter do something similar is 
neither rocket science, nor against the spirit of dynamic typing.

Linters have done some type-checking for many years. One popular 
convention was Sphinx-based type annotations in docstrings:

http://www.pydev.org/manual_adv_type_hints.html


Across the programming language landscape, dynamic languages are adding 
static features, and static languages are adding dynamic features:

http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html

Since Steve Yegge gave that talk, the process has only accelerated, 
driven by both practical experience with gradual typing and a lot of 
academic research.

PySonar has been successfully used by Google for close on a decade:

https://yinwang0.wordpress.com/2010/09/12/pysonar/

and MyPy has also been very successful:

http://mypy-lang.org/

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

It is 2018. People who say that static typing cannot be integrated with 
dynamic languages are nearly half a century behind the state of the art 
in computer programming.

(As an industry, the programming community is *painfully* conservative. 
Things which Lisp was doing in the 1950s are *still* not mainstream, and 
most programmers do not even imagine they are possible.)


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

[Gregory Ewing]

Bart wrote:
I can remove comments by writing a tokeniser which scans Python source 
and re-outputs tokens one at a time. Such a tokeniser normally ignores 
comments.


What was being talked about wasn't removing *all* comments,
but removing just the ones that contain type hints.

But to remove type hints, a deeper understanding of the input is needed. 
I would need a parser rather than a tokeniser.


Fortunately, Python comes with a parser for Python built
in (the ast module). So you get quite a good head start.

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

Re: syntax difference

[Steven D'Aprano]

On Mon, 18 Jun 2018 15:11:05 +0300, Marko Rauhamaa wrote:

[...]
> So the point *was* popularity!? I suspected as much.

Presumably you missed the invisible sarcasm tags.

As well as the point that despite all the "type annotation is killing 
Python" FUD from certain corners of the Python community, Python is not 
only alive and well, but actually growing in popularity according to (as 
far as I can see) all the well-known measures of language popularity.

Personally I don't think that type annotations are specifically driving 
that increase in popularity, but there is no evidence that they are 
harming it.


-- 
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: Technical altitude, was Re: Python list vs google group

[Steven D'Aprano]

On Mon, 18 Jun 2018 15:59:58 +0200, Peter Otten wrote:

> Other than that I find it hard to believe that a "bean counter" can
> change a technical spec. He may put pressure on the designer, but when
> the designer gives in he's still responsible for the resulting technical
> problems.

Surely it depends on how dysfunctional the organisation is, and whether 
or not they are answerable to independent standards. Ultimately, the 
engineers answer to management, and if management treat them as drones 
that have to do what they're told instead of experts that can make 
decisions for themselves, anything is possible.

When you hear of technical disasters like tens of thousands of cars 
having to be recalled, or laptop batteries catching fire, or similar 
problems, we almost never find out whether this was an unavoidable 
failure, a technical mistake by the designers, or a case of managerial 
interference.

Fortunately I've avoided having to work in that sort of environment, but 
my wife used to work in the entertainment industry where that sort of 
managerial interference is the rule, not the exception.


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

Further to my earlier comments...

On Sun, 17 Jun 2018 12:07:14 -0700, Jim Lee wrote:
> IMHO, trying to shoehorn static type checking on top of a dynamically
> typed language shows that the wrong language was chosen for the job.


Relevant:

http://lambda-the-ultimate.org/node/1519

and this quote is extremely pertinent:

Giving people a dynamically-typed language does not mean 
that they write dynamically-typed programs.
-- John Aycock


Lots of people have observed that *nearly all* real Python code is much 
less dynamic than the language allows. When you call "len(x)", the 
compiler has to resolve the name "len" at runtime in case it has been 
monkey-patched or shadowed, but in practice that hardly ever happens.

Moving the type-checking out of the core language into the IDE or linter 
which can be used or not used according to the desire of the programmer 
is an elegant (partial) solution to the problem that testing can never 
demonstrate the absence of bugs, only their presence, without 
compromising on the full range of dynamic programming available to those 
who want it.




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

[Grant Edwards]

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?

-- 
Grant Edwards   grant.b.edwardsYow! Make me look like
  at   LINDA RONSTADT again!!
  gmail.com

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

RE: syntax difference

[Schachner, Joseph]

As soon as I sent the previous message I realized it's "doc string" not def 
string.  Pardon me. 
--- Joe S.

-Original Message-
From: Ed Kellett  
Sent: Monday, June 18, 2018 8:47 AM
To: python-list@python.org
Subject: Re: syntax difference

On 2018-06-18 13:18, Chris Angelico wrote:
> 1) Parse the code, keeping all the non-essential parts as well as the 
> essential parts.
> 2) Find the comments, or find the annotations
> 3) If comments, figure out if they're the ones you want to remove.
> 4) Reconstruct the file without the bits you want to remember.
> 
> Step 3 is removed if you're using syntactic annotations. Otherwise, 
> they're identical.

It's likely that Python comments are much easier to remove than arbitrary bits 
of Python syntax--you need to know the answer to "am I in a string literal?", 
which is a lexical analysis problem you could hack together a solution for over 
the course of about one coffee, as opposed to "where exactly am I in the Python 
parse tree?", which is... harder.
The information you need to keep track of and later reconstruct is 
substantially simpler, too.

I don't think "they're hard to mechanically remove" is a particularly good 
argument against type hints, but considered on its own it probably is true.

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

RE: syntax difference (type hints)

[Schachner, Joseph]

Assuming that we want Python to remain a dynamically typed (but strongly typed) 
language, I believe the proposed type hints are only necessary for function 
definitions, where the caller really needs to know the types of arguments to 
pass in.   At the moment that purpose is (I think adequately) served by def 
strings, triple quoted strings immediately following the function declaration.  
When I do code reviews for Python developed here, if the argument names of a 
function do not hint at the type they should be and there is no def string then 
I insist that something be added.  Often what gets added is a def string that 
says something about what the function does and explains what argument types 
are expected.

-- Joseph S.

-Original Message-
From: Ed Kellett  
Sent: Monday, June 18, 2018 8:47 AM
To: python-list@python.org
Subject: Re: syntax difference

On 2018-06-18 13:18, Chris Angelico wrote:
> 1) Parse the code, keeping all the non-essential parts as well as the 
> essential parts.
> 2) Find the comments, or find the annotations
> 3) If comments, figure out if they're the ones you want to remove.
> 4) Reconstruct the file without the bits you want to remember.
> 
> Step 3 is removed if you're using syntactic annotations. Otherwise, 
> they're identical.

It's likely that Python comments are much easier to remove than arbitrary bits 
of Python syntax--you need to know the answer to "am I in a string literal?", 
which is a lexical analysis problem you could hack together a solution for over 
the course of about one coffee, as opposed to "where exactly am I in the Python 
parse tree?", which is... harder.
The information you need to keep track of and later reconstruct is 
substantially simpler, too.

I don't think "they're hard to mechanically remove" is a particularly good 
argument against type hints, but considered on its own it probably is true.

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

Re: syntax difference

[Rick Johnson]

Chris Angelico wrote:
[...]
> What was the quote before that?
> 
> > "Type-hint comments" would allow:
> > (3) and those who utterly *HATE* them, to write a simpl[e]
> > little function which will strip them from any and all
> > source code they might be forced to maintain.
> 
> Put up or shut up. Write something that strips all type
> hint comments.

"Type-hint comments" don't exist yet. They are only
theoretical at this point. Now stop distracting, and let's
see your code!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Rick Johnson]

Jim Lee wrote:
> Chris wrote:
> > 
> > I said that you can't decry changes that were before
> > your time (they're simply the way things are).
> 
> Really?  Wow.  I'd hate to live in your world!  Just
> because something exists, it can't be challenged or
> questioned.  Got it!

Chris is a good choir boy. He consistently ranks a perfect
10 out 10 on parochial surveys.
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: syntax difference (type hints)

[Dan Strohl via Python-list]

> -Original Message-
> From: Python-list  On
> Behalf Of Schachner, Joseph
> Sent: Monday, June 18, 2018 7:58 AM
> To: Ed Kellett ; python-list@python.org
> Subject: RE: syntax difference (type hints)
> 
> EXTERNAL MAIL: python-list-bounces+d.strohl=f5@python.org
> 
> Assuming that we want Python to remain a dynamically typed (but strongly
> typed) language, I believe the proposed type hints are only necessary for
> function definitions, where the caller really needs to know the types of
> arguments to pass in.   At the moment that purpose is (I think adequately)
> served by def strings, triple quoted strings immediately following the 
> function
> declaration.  When I do code reviews for Python developed here, if the
> argument names of a function do not hint at the type they should be and there
> is no def string then I insist that something be added.  Often what gets added
> is a def string that says something about what the function does and explains
> what argument types are expected.
> 
> -- Joseph S.
> 

I like having the option to add type hints to various things, including 
functions, but also classes, and the methods, and attributes of a class.   
While I don't add them to every one of these every time, if I write a function 
that I expect to be used by someone else, I will annotate it.  Similarly, if I 
write a class that I expect to be instantiated or sub-classed as part of a 
library, I will annotate that as well, including any attributes that I expect 
to be used or changed.  

I haven't totally utilized the new type hinting yet, I am still often still 
documenting in the triple quoted strings using epytext type hinting, but that 
doesn't really handle things like "a list of strings", or even worse, " a 
dictionary that looks like dict("key1":1, "key2":"foobar") in a "standard" way 
(that I have found at least), or cases where an argument can be a string OR an 
int, or a list.  (I use the string/list option pretty regularly when I have 
functions that can handle one object, or multiple ones, and I've already used 
the * to break out something else).  I'm looking forward to finding the time to 
figure out how to best annotate those types of things.

And I have found that having these things well annotated does help my IDE 
(PyCharm) to keep me from making simple mistakes.

In the end, I figure that I don't see any real downside to the new type 
hinting, if I use it, great, if not, that's fine as well.  I would certainly 
not be supportive of making it required in order to compile though.


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

Re: syntax difference

[Ian Kelly]

On Mon, Jun 18, 2018 at 9:17 AM Rick Johnson
 wrote:
>
> Chris Angelico wrote:
> [...]
> > What was the quote before that?
> >
> > > "Type-hint comments" would allow:
> > > (3) and those who utterly *HATE* them, to write a simpl[e]
> > > little function which will strip them from any and all
> > > source code they might be forced to maintain.
> >
> > Put up or shut up. Write something that strips all type
> > hint comments.
>
> "Type-hint comments" don't exist yet. They are only
> theoretical at this point. Now stop distracting, and let's
> see your code!

Uh, yes, they do. They're defined in PEP 484, and Mypy uses them for
type-checking Python 2 code, where the annotations don't exist.

https://mypy.readthedocs.io/en/stable/python2.html?highlight=comment#type-checking-python-2-code
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference (type hints)

[Ian Kelly]

FYI, Python type hints aren't "proposed"; they're already here. The
function annotation syntax was added in 3.0, without any imposition of
semantic meaning or requirements on it, and allowed to simmer for
several years for third-party frameworks to find uses for. Python 3.5
added the typing module to support type hinting in the style of Mypy
without any further language changes. Most recently, Python 3.6 added
syntax for annotating variables in addition to functions. All of these
things are already fully available in modern Python.
On Mon, Jun 18, 2018 at 9:05 AM Schachner, Joseph
 wrote:
>
> Assuming that we want Python to remain a dynamically typed (but strongly 
> typed) language, I believe the proposed type hints are only necessary for 
> function definitions, where the caller really needs to know the types of 
> arguments to pass in.   At the moment that purpose is (I think adequately) 
> served by def strings, triple quoted strings immediately following the 
> function declaration.  When I do code reviews for Python developed here, if 
> the argument names of a function do not hint at the type they should be and 
> there is no def string then I insist that something be added.  Often what 
> gets added is a def string that says something about what the function does 
> and explains what argument types are expected.
>
> -- Joseph S.
>
> -Original Message-
> From: Ed Kellett 
> Sent: Monday, June 18, 2018 8:47 AM
> To: python-list@python.org
> Subject: Re: syntax difference
>
> On 2018-06-18 13:18, Chris Angelico wrote:
> > 1) Parse the code, keeping all the non-essential parts as well as the
> > essential parts.
> > 2) Find the comments, or find the annotations
> > 3) If comments, figure out if they're the ones you want to remove.
> > 4) Reconstruct the file without the bits you want to remember.
> >
> > Step 3 is removed if you're using syntactic annotations. Otherwise,
> > they're identical.
>
> It's likely that Python comments are much easier to remove than arbitrary 
> bits of Python syntax--you need to know the answer to "am I in a string 
> literal?", which is a lexical analysis problem you could hack together a 
> solution for over the course of about one coffee, as opposed to "where 
> exactly am I in the Python parse tree?", which is... harder.
> The information you need to keep track of and later reconstruct is 
> substantially simpler, too.
>
> I don't think "they're hard to mechanically remove" is a particularly good 
> argument against type hints, but considered on its own it probably is true.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Rick Johnson]

On Monday, June 18, 2018 at 5:45:28 AM UTC-5, Chris Angelico wrote:

> So in both cases, you would probably end up with something
> like 2to3.

And there you have it! 

Just Like Python3000, the python devs have caused a major
disruption by saddling us with the syntactic noise of type-
hints. Therefore, _they_ are responsible for producing a
tool which will remove these type-hints from scripts and do
it error _free_.

So petition your friends over at py-dev and get the ball
rolling, would ya pal?

And the great news is, after they release this tool, myself,
and all the other folks who have been blindsided by a
special purpose feature can no longer complain. Nope. And
you will _finally_ have the moral high ground when you brow
beat others for daring to protest.

That's right Chris!

We will quietly run the tool on all the type-hint scripts we
encounter and then we will be as content as you.

Why can't we _all_ be happy little clams just like you?

Hmm?

Is that really too much to ask?

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

Re: Python list vs google group

[Joe Pfeiffer]

Peter Otten <__pete...@web.de> writes:

> Gene Heskett wrote:
>
>> This biggest single thing wrong with any of those old scsi interfaces is
>> the bus's 5 volt isolation diode, the designer speced a shotkey(sp)
>> diode, and some damned bean counter saw the price diff and changed it to
>
> Is this a case of  ?
>
> https://en.wikipedia.org/wiki/Walter_H._Schottky

I'm missing why the claim that management changed the spec on a diode
from Schottky to conventional would be folk etymology?  Or why Gene
being unsure of his spelling would?  What does any of this have to do
with etymology, folk or genuine?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference (type hints)

[Chris Angelico]

On Tue, Jun 19, 2018 at 12:57 AM, Schachner, Joseph
 wrote:
> Assuming that we want Python to remain a dynamically typed (but strongly 
> typed) language, I believe the proposed type hints are only necessary for 
> function definitions, where the caller really needs to know the types of 
> arguments to pass in.   At the moment that purpose is (I think adequately) 
> served by def strings, triple quoted strings immediately following the 
> function declaration.  When I do code reviews for Python developed here, if 
> the argument names of a function do not hint at the type they should be and 
> there is no def string then I insist that something be added.  Often what 
> gets added is a def string that says something about what the function does 
> and explains what argument types are expected.
>

(The official term is "docstring", and you can find some specifics on
them in PEP 257.)

What you're doing is all very well, but it isn't very
machine-readable. Type hints as defined in PEP 3107 and 484 are
designed to be understood by linters and autocompletion tools and the
like. And once you have the machine-readable, you should be able to
leave off any type information in the purely-human-readable parts of
documentation.

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

Re: Python list vs google group

[Grant Edwards]

On 2018-06-18, Joe Pfeiffer  wrote:
> Peter Otten <__pete...@web.de> writes:
>
>> Gene Heskett wrote:
>>
>>> This biggest single thing wrong with any of those old scsi interfaces is
>>> the bus's 5 volt isolation diode, the designer speced a shotkey(sp)
>>> diode, and some damned bean counter saw the price diff and changed it to
>>
>> Is this a case of  ?
>>
>> https://en.wikipedia.org/wiki/Walter_H._Schottky
>
> I'm missing why the claim that management changed the spec on a diode
> from Schottky to conventional would be folk etymology?  Or why Gene
> being unsure of his spelling would?  What does any of this have to do
> with etymology, folk or genuine?

I was wondering the same thing...

-- 
Grant Edwards   grant.b.edwardsYow! Half a mind is a
  at   terrible thing to waste!
  gmail.com

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

Re: syntax difference

[Rick Johnson]

Chris Angelico wrote:
> Bart wrote:
[...]
> > What will those look like? If copyright/license comments
> > have their own specific syntax, then they just become
> > another token which has to be recognized.
>
> If they have specific syntax, they're not comments, are they?

Yes, they are.

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

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

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

After all, it's the Python way.

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.

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

Re: syntax difference

[Ben Bacarisse]

Bart  writes:

> On 18/06/2018 11:45, Chris Angelico wrote:
>> On Mon, Jun 18, 2018 at 8:33 PM, Bart  wrote:
>
>
>>> You're right in that neither task is that trivial.
>>>
>>> I can remove comments by writing a tokeniser which scans Python source and
>>> re-outputs tokens one at a time. Such a tokeniser normally ignores comments.
>>>
>>> But to remove type hints, a deeper understanding of the input is needed. I
>>> would need a parser rather than a tokeniser. So it is harder.
>>
>> They would actually both end up the same. To properly recognize
>> comments, you need to understand enough syntax to recognize them. To
>> properly recognize type hints, you need to understand enough syntax to
>> recognize them. And in both cases, you need to NOT discard important
>> information like consecutive whitespace.
>
> No. If syntax is defined on top of tokens, then at the token level,
> you don't need to know any syntax. The process that scans characters
> looking for the next token, will usually discard comments. Job done.

You don't even need to scan for tokens other than strings.  From what I
read in the documentation a simple scanner like this would do the trick:

  %option noyywrap
  %x sqstr dqstr sqtstr dqtstr
  %%
   
  \'  ECHO; BEGIN(sqstr);
  \"  ECHO; BEGIN(dqstr);
  \'\'\'  ECHO; BEGIN(dqtstr);
  \"\"\"  ECHO; BEGIN(dqtstr);
   
  \"   |
  \'   |
  \'\'\'  |
  \"\"\"  ECHO; BEGIN(INITIAL);
   
  \\\'   |
  \\\"   |
  .  ECHO;
   
  #.*
   
  %%
  int main(void) { yylex(); }

and it's only this long because there are four kinds of string.  Not
being a Python expert, there may be some corner case errors.  And really
there are comments that should not be removed such as #! on line 1 and
encoding declarations, but they would just need another line or two.

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

Re: syntax difference

[Rick Johnson]

On Monday, June 18, 2018 at 6:43:36 AM UTC-5, Steven D'Aprano wrote:
> The programmer can ignore [type-hints], just as they can
> ignore any other form of documentation.

Type-hints, as implemented, break all the rules of
conventional documentation. In any programming language i
have ever seen, formal documentation elements such as
documentation strings and comments do not _interleave_
themselves with executable code, no, they are forced to
isolate themselves on entire lines, or, the tail ends of
lines. For instance, i have never seem a dynamic programming
language that did anything like the following:

def foo():
for k,v in d:
print(k, v)

Have you??? Maybe i'm crazy, but i would prefer to have my
_documentation_ and executable-code separated from one
another.

def foo():
# Iterate over the keys of d
# k: string
# v: integer
# d: dict (duh!)
for k,v in d:
print(k, v) # That was builtin!

> Nobody is stopping you from writing:
> 
> result = function(the_string=42.5)

Steven, that's an example of "self-documenting names" not
"documentation". I'm sorry, but you are terribly confused if
you cannot understand the non-subtle difference between
these two concepts.

> [we do it] Just to annoy you.

You're also terribly confused if you believe i'm the only
person in this community who is opposed to the current
implementation of type-hints. Remember, i'm not advocating
that type-hints be removed completely (the train has left
the station). I'm only requesting that one of the following
be done to _alleviate_ the burden of their poorly executed
implementation:

(1) Re-implement type-hints as a comment. 
 
(2) Provide a tool that will remove type-hints from scripts
error free.

Is that _really_ too much to ask?

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

Re: syntax difference

[Rick Johnson]

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!

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

Folk etymology, was Re: Python list vs google group

[Peter Otten]

Grant Edwards wrote:

> On 2018-06-18, Joe Pfeiffer  wrote:
>> Peter Otten <__pete...@web.de> writes:
>>
>>> Gene Heskett wrote:
>>>
 This biggest single thing wrong with any of those old scsi interfaces
 is the bus's 5 volt isolation diode, the designer speced a shotkey(sp)
 diode, and some damned bean counter saw the price diff and changed it
 to
>>>
>>> Is this a case of  ?
>>>
>>> https://en.wikipedia.org/wiki/Walter_H._Schottky
>>
>> I'm missing why the claim that management changed the spec on a diode
>> from Schottky to conventional would be folk etymology?  Or why Gene
>> being unsure of his spelling would?  What does any of this have to do
>> with etymology, folk or genuine?
> 
> I was wondering the same thing...

"folk etymology" would be the retrofitting of the exotic "Schottky" into two 
familiar words "shot" and "key". Sometimes the writer assumes that these 
words are somehow related to the labeled object.

The best known example in German is

Maulwurf ("mouth throw" for mole)

leading to the (false) idea that moles use their mouth to build mole hills.




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

Re: syntax difference

[Rick Johnson]

Bart wrote:
[...]
> For example, comments that start with #T# (and in my case,
> that begin at the start of a line).

Such would be a _breeze_ to parse out. And i would argue
(given a sufficiently unique tag) that arbitrary white space
would not be any more error prone, either. Thus, your
"tagged comments" would be much more readable as they will
match the current block indentation and not be smashed
against the left most column. 

"Readability counts!".

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

Re: syntax difference

[Rick Johnson]

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!

And we thoughts _google_ was evil. o_O
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Ed Kellett]

are you someone's ironic 3rd-year art project



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

Re: syntax difference

[Rick Johnson]

Steven D'Aprano said:
> Python is not only alive and well, but actually growing in
> popularity according to (as far as I can see) all the well-
> known measures of language popularity.

Steven *ALSO* said:
> "Ever since I learned about confirmation bias, I've been
> seeing it everywhere."

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

Re: syntax difference

[Rick Johnson]

Steven D'Aprano wrote:
> Moving the type-checking out of the core language into the
> IDE or linter which can be used or not used according to
> the desire of the programmer

Except, what your poppycock commentary seems to glaze over is
the fact that whilst a programmer can certainly decided to
"use or not use" the type-hints feature in his or her own
code, he or she certainly cannot "see or _unsee_" type-hints
that are written by other programmers.

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

Re: syntax difference

[Rick Johnson]

Ian wrote:

> Uh, yes, they do. They're defined in PEP 484, and Mypy uses them for
> type-checking Python 2 code, where the annotations don't exist.

So when will the interleaved type-hints be removed from the language 
specification?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Jim Lee]

On 06/18/2018 07:03 AM, Steven D'Aprano wrote:

As a human programmer, you surely perform your own ad hoc type checking
when you write and debug code.
Of course.  And, I use linting tools and other forms of static type 
checking.  What I don't like is adding the *syntax* for static type 
checking to the (dynamically typed) language proper, particularly when 
the implementations of said language do nothing but ignore it.


The syntax should be defined inside comments, 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.


If static type checking were a high priority, I would not choose a 
language like Python for the task - 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.


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


-Jim

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

Re: syntax difference

[Chris Angelico]

On Tue, Jun 19, 2018 at 3:34 AM, Jim Lee  wrote:
>
>
> On 06/18/2018 07:03 AM, Steven D'Aprano wrote:
>>
>> As a human programmer, you surely perform your own ad hoc type checking
>> when you write and debug code.
>
> Of course.  And, I use linting tools and other forms of static type
> checking.  What I don't like is adding the *syntax* for static type checking
> to the (dynamically typed) language proper, particularly when the
> implementations of said language do nothing but ignore it.

So you have annotations for type information. Tell me: why should
these annotations be introduced with a hash and ended with a newline?
What is it about type annotations that requires that they be delimited
in this way?

What about assertions? Are they comments too? Should we have, for instance:

if x > 0:
...
elif x < 0:
...
else:
#assert: x == 0
...

or is it better to use an 'assert' statement? After all, they can
legitimately be ignored by the interpreter.

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

Re: syntax difference

[Ian Kelly]

On Mon, Jun 18, 2018 at 11:39 AM Jim Lee  wrote:
> On 06/18/2018 07:03 AM, Steven D'Aprano wrote:
> > As a human programmer, you surely perform your own ad hoc type checking
> > when you write and debug code.
> Of course.  And, I use linting tools and other forms of static type
> checking.  What I don't like is adding the *syntax* for static type
> checking to the (dynamically typed) language proper, particularly when
> the implementations of said language do nothing but ignore it.
>
> The syntax should be defined inside comments, 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.

If you want to use a type checking tool that uses type comments, then
by all means do so. The existence of annotation syntax in no way
prevents that.

When PEP 3107 was written, it was anticipated that annotations would
find more uses than just type hinting. Some of those proposed ideas
(e.g. database query mapping) depend on the annotation being readable
at run-time, for which a comment would be wholly inadequate. In
practice, I don't think that has really been borne out. Still, the
intention was to make the language more flexible, not just to cram in
type hinting, and I don't think that was necessarily a bad idea.

PEP 484 was created out of the observation that the community of
static type analysis tools that has grown out of PEP 3107 would
benefit from a common dialect of types. All it does is provide that.

Neither of these are forcing you to use a type checker that requires
annotations for type hints rather than comments, if that's what you
prefer. The annotation-based checker is probably a fair bit easier to
build from the maintainer's standpoint, though, since it can rely on
existing parsing tools and the typing module.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Jim Lee]

On 06/18/2018 10:46 AM, Chris Angelico wrote:

On Tue, Jun 19, 2018 at 3:34 AM, Jim Lee  wrote:


On 06/18/2018 07:03 AM, Steven D'Aprano wrote:

As a human programmer, you surely perform your own ad hoc type checking
when you write and debug code.

Of course.  And, I use linting tools and other forms of static type
checking.  What I don't like is adding the *syntax* for static type checking
to the (dynamically typed) language proper, particularly when the
implementations of said language do nothing but ignore it.

So you have annotations for type information. Tell me: why should
these annotations be introduced with a hash and ended with a newline?
What is it about type annotations that requires that they be delimited
in this way?

Uhhhbecause that's mostly the definition of a comment?  Duh!

What about assertions? Are they comments too? Should we have, for instance:

if x > 0:
 ...
elif x < 0:
 ...
else:
 #assert: x == 0
 ...

or is it better to use an 'assert' statement? After all, they can
legitimately be ignored by the interpreter.

ChrisA


I'm noticing a pattern here.  Can we stick to the subject at hand?

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

Re: syntax difference

[Chris Angelico]

On Tue, Jun 19, 2018 at 4:09 AM, Jim Lee  wrote:
>
>
> On 06/18/2018 10:46 AM, Chris Angelico wrote:
>>
>> On Tue, Jun 19, 2018 at 3:34 AM, Jim Lee  wrote:
>>>
>>>
>>> On 06/18/2018 07:03 AM, Steven D'Aprano wrote:

 As a human programmer, you surely perform your own ad hoc type checking
 when you write and debug code.
>>>
>>> Of course.  And, I use linting tools and other forms of static type
>>> checking.  What I don't like is adding the *syntax* for static type
>>> checking
>>> to the (dynamically typed) language proper, particularly when the
>>> implementations of said language do nothing but ignore it.
>>
>> So you have annotations for type information. Tell me: why should
>> these annotations be introduced with a hash and ended with a newline?
>> What is it about type annotations that requires that they be delimited
>> in this way?
>
> Uhhhbecause that's mostly the definition of a comment?  Duh!

Yes, that's the definition of a comment. What is it about type
annotations that requires them to be comments? Please explain.

>> What about assertions? Are they comments too? Should we have, for
>> instance:
>>
>> if x > 0:
>>  ...
>> elif x < 0:
>>  ...
>> else:
>>  #assert: x == 0
>>  ...
>>
>> or is it better to use an 'assert' statement? After all, they can
>> legitimately be ignored by the interpreter.
>>
>> ChrisA
>
>
> I'm noticing a pattern here.  Can we stick to the subject at hand?

Yes, but probably not the same pattern you are. What, fundamentally,
is the difference between type hints and assertions, such that - in
your view - one gets syntax and the other is just comments?

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

Re: syntax difference

[Jim Lee]

On 06/18/2018 11:01 AM, Ian Kelly wrote:

On Mon, Jun 18, 2018 at 11:39 AM Jim Lee  wrote:

On 06/18/2018 07:03 AM, Steven D'Aprano wrote:

As a human programmer, you surely perform your own ad hoc type checking
when you write and debug code.

Of course.  And, I use linting tools and other forms of static type
checking.  What I don't like is adding the *syntax* for static type
checking to the (dynamically typed) language proper, particularly when
the implementations of said language do nothing but ignore it.

The syntax should be defined inside comments, 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.

If you want to use a type checking tool that uses type comments, then
by all means do so. The existence of annotation syntax in no way
prevents that.

No, but it adds an awful lot of functionally inert noise to live code.

When PEP 3107 was written, it was anticipated that annotations would
find more uses than just type hinting. Some of those proposed ideas
(e.g. database query mapping) depend on the annotation being readable
at run-time, for which a comment would be wholly inadequate. In
practice, I don't think that has really been borne out. Still, the
intention was to make the language more flexible, not just to cram in
type hinting, and I don't think that was necessarily a bad idea.

PEP 484 was created out of the observation that the community of
static type analysis tools that has grown out of PEP 3107 would
benefit from a common dialect of types. All it does is provide that.

Neither of these are forcing you to use a type checker that requires
annotations for type hints rather than comments, if that's what you
prefer. The annotation-based checker is probably a fair bit easier to
build from the maintainer's standpoint, though, since it can rely on
existing parsing tools and the typing module.
Thanks for the explanation, but it only reinforces my view.  The more 
entrenched this feature becomes, the more we will see annotation-based 
tools and, at some point, we will all be forced to used annotations in 
order to take advantage of the tools.


-Jim

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

Re: syntax difference

[Jim Lee]

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.


-Jim

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

Re: syntax difference

[Chris Angelico]

On Tue, Jun 19, 2018 at 4:34 AM, 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.
>

I don't know what you mean by "syntactic meaning". Do you mean that
they create no executable bytecode, that they have no run-time
influence? Because that's not entirely true; they are stored, and can
be viewed at run-time. In fact, in optimized mode, assertions produce
no bytecode whatsoever; so by that definition, they are more comment-y
than annotations are. Do you have some other definition?

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

Re: syntax difference

[Jim Lee]

On 06/18/2018 11:49 AM, Chris Angelico wrote:

On Tue, Jun 19, 2018 at 4:34 AM, 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.


I don't know what you mean by "syntactic meaning". Do you mean that
they create no executable bytecode, that they have no run-time
influence? Because that's not entirely true; they are stored, and can
be viewed at run-time. In fact, in optimized mode, assertions produce
no bytecode whatsoever; so by that definition, they are more comment-y
than annotations are. Do you have some other definition?

ChrisA
I'm tired of running around in circles with you, so I will respectfully 
decline to comment further.


-Jim

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

Re: syntax difference

[Ian Kelly]

On Mon, Jun 18, 2018 at 11:27 AM Rick Johnson
 wrote:
>
> Ian wrote:
>
> > Uh, yes, they do. They're defined in PEP 484, and Mypy uses them for
> > type-checking Python 2 code, where the annotations don't exist.
>
> So when will the interleaved type-hints be removed from the language 
> specification?

These things are unrelated. The comment specification was added to
supplement type hints, not replace them.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Rick Johnson]

On Monday, June 18, 2018 at 12:46:36 PM UTC-5, Chris Angelico wrote:

> What about assertions? Are they comments too? Should we
> have, for instance:
> 
> if x > 0:
> ...
> elif x < 0:
> ...
> else:
> #assert: x == 0
> ...
> 
> or is it better to use an 'assert' statement? After all,
> they can legitimately be ignored by the interpreter.

(oh my!)

Of course they can "easily be ignored", 

for cryin' out loud, 

assert statements all begin with the same "syntactical
tag"!

okay, wait for it... 

--> assert <--
^^

Yep!

Which BTW is a _keyword_. 

(if you didn't know that already) *wink*

But please Chris, feel free to bring us your next logical
dead end. 

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

Re: syntax difference

[Rick Johnson]

On Monday, June 18, 2018 at 1:02:18 PM UTC-5, Ian wrote:
[...]
> When PEP 3107 was written, it was anticipated that
> annotations would find more uses than just type hinting.
> Some of those proposed ideas (e.g. database query mapping)
> depend on the annotation being readable at run-time, for
> which a comment would be wholly inadequate.

That's a BS excuse! Any tool can pre-process a python script
simply by reading the source from disc before passing it
off to the Python interpreter. It's a simple matter of
_delegation_.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Rick Johnson]

On Monday, June 18, 2018 at 1:50:09 PM UTC-5, Chris Angelico wrote:
[...]
> I don't know what you mean by "syntactic meaning". Do you mean that
> they create no executable bytecode, that they have no run-time
> influence? Because that's not entirely true; they are stored, and can
> be viewed at run-time.

So can doc-strings! Ever used the help(...) function? 


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

Re: syntax difference

[Chris Angelico]

On Tue, Jun 19, 2018 at 5:26 AM, Rick Johnson
 wrote:
> On Monday, June 18, 2018 at 12:46:36 PM UTC-5, Chris Angelico wrote:
>
>> What about assertions? Are they comments too? Should we
>> have, for instance:
>>
>> if x > 0:
>> ...
>> elif x < 0:
>> ...
>> else:
>> #assert: x == 0
>> ...
>>
>> or is it better to use an 'assert' statement? After all,
>> they can legitimately be ignored by the interpreter.
>
> (oh my!)
>
> Of course they can "easily be ignored",
>
> for cryin' out loud,
>
> assert statements all begin with the same "syntactical
> tag"!
>
> okay, wait for it...
>
> --> assert <--
> ^^
>
> Yep!
>
> Which BTW is a _keyword_.
>
> (if you didn't know that already) *wink*
>
> But please Chris, feel free to bring us your next logical
> dead end.

Ahh, yes, it's easy to find the end of an assert statement, too, isn't
it? Or are you talking about properly parsing, which - as you
might recall - was my original point?

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

So easy to take shortcuts. So easy to get bitten. Isn't it nice how
Python provides proper parsing as a module, though? Except that, oh
how terrible, that makes it just as easy to find ALL syntactic
elements.

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

Re: syntax difference

[Ian Kelly]

On Mon, Jun 18, 2018 at 10:19 AM Rick Johnson
 wrote:
> 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_.

If this is really your attitude, then I pity anybody who has the
misfortune to work with you. If a comment is wrong, the best course of
action is to fix it. Not to come to the conclusion that all comments
are useless or worse than useless and to therefore swear off reading
all comments forever more.

As most seasoned programmers would say, the most useful comments are
those that explain why, not what or how. What the code does or how it
does it can generally be understood just by reading the code. *Why*
the code does what it does often cannot. Here's an example of a bad
comment:

def num_threads():
# Use 10 threads.
return 20

We easily see the value is 20, but *should* it be 10 or 20? We don't
know. Now here's an example of a useful comment:

def num_threads():
# Use 10 threads because the system randomly
# locks up at 15 or more. (bug: 12345)
return 20

This one makes it clear that whoever increased the value from 10 to 20
wasn't paying attention. The change should likely be reverted.

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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Rhodri James]

On 18/06/18 19:21, Jim Lee wrote:
Thanks for the explanation, but it only reinforces my view.  The more 
entrenched this feature becomes, the more we will see annotation-based 
tools and, at some point, we will all be forced to used annotations in 
order to take advantage of the tools.


So don't take advantage of the tools.  They're just tools, and they may 
be a help for programmers who can't be bothered to figure things out for 
themselves, but they aren't required by any means.


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

Re: syntax difference

[Rhodri James]

On 18/06/18 19:34, Jim Lee wrote:
Type hints are just that - hints.  They have no syntactic meaning to the 
parser,


This is plainly not true, otherwise the parser would be throwing syntax 
errors at you all the time.  Whether they have semantic meaning to the 
parser is more debatable.


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

Re: syntax difference

[Bart]

On 18/06/2018 15:03, Steven D'Aprano wrote:


It is 2018. People who say that static typing cannot be integrated with
dynamic languages are nearly half a century behind the state of the art
in computer programming.


It can be, but it spoils the language. In the case of Python, it is 
already so big and has so many features crammed in that adding type 
hints probably makes little difference.


I spent a bit of time a decade ago with adding type hints to my own 
dynamic language. It was done to improve performance, and yes some 
benchmarks could be double the speed.


In the end I got rid of them to keep the language purer, smaller and 
simpler. Other approaches which don't involve annotating source code 
(eg. type inference) are better IMO.


One problem with them was that, if you said X was an int, you were 
obliged to check it was int, otherwise bad things could happen if it 
assumed X was int because you said so, and in reality it wasn't. That 
checking doesn't help improve performance, which was one aim.


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

Re: syntax difference

[Chris Angelico]

On Tue, Jun 19, 2018 at 6:03 AM, Bart  wrote:
> In the end I got rid of them to keep the language purer, smaller and
> simpler. Other approaches which don't involve annotating source code (eg.
> type inference) are better IMO.

Inference is great when it works. How do you assist a type inference
engine, when it's unable to get all the information it needs? A type
system has to either be imperfect, or be an entire executable
programming language, or have additional information given to it.

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

Re: syntax difference

[Rick Johnson]

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.

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

Re: syntax difference

[Chris Angelico]

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.

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

Re: syntax difference

[Jim Lee]

On 06/18/2018 12:52 PM, Rhodri James wrote:

On 18/06/18 19:34, Jim Lee wrote:
Type hints are just that - hints.  They have no syntactic meaning to 
the parser,


This is plainly not true, otherwise the parser would be throwing 
syntax errors at you all the time.  Whether they have semantic meaning 
to the parser is more debatable.


That's funny - arguing semantics over the difference between syntactic 
and semantic.  If we're not careful, this conversation could become 
recursive and blow up the Internet! :)


-Jim

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

Re: syntax difference

[Rick Johnson]

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.

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.

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.

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

I have made my sacrifice, by agreeing that i will accept
the inclusion of type-hints even though i find the whole
concept the be a violation of Python's core principles. All
i ask in return is that the py-devs make a sacrifice of their
own, by releasing a tool to remove these type-hints error
free. 

And then those of us who are offended by type-hints will
have no reason to complain.

And wouldn't that be nice?

Wouldn't it be nice to actually have a sense of community
again.

Wouldn't it be nice to compromise instead of squabble?

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

Re: syntax difference

[Chris Angelico]

On Tue, Jun 19, 2018 at 6:52 AM, 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.
>
> 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.

For the same reason that the core devs won't offer a tool to remove
assertions, or docstrings. If you want it, write it yourself. Why
should busy volunteer core devs write the tool for you?

> 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.
>
> That is not behavior of a community. A community would care
> for the opinions of all members.

I believe you're confusing "community" with "democracy". This is not a
democracy. This is a place in which the overwhelming majority of the
work is done by volunteers. You cannot demand that they do work for
you unless you are paying for it.

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

RE: syntax difference

[Schachner, Joseph]

On YouTube you can watch videos of Guido van Rossum presenting at PyCon from a 
few years ago, in which he makes clear that he has been thinking about this 
since 2000, that he wants someone else to guide this PEP along its path because 
he is too close to it, and that NOTHING about having a typing module requires 
you to use it.  In fact, you can use it without affecting your source code and 
interleaving the (helpful) information into the source code.  They support 
"stub" files, with a ".pyi" extension, in which you can place the declarations 
with the typing information.   The type checker will read that an use it along 
with your unmodified source code to do its checking.  He also thanked multiple 
people for their contributions bringing this from an idea to a preliminary 
implementation in 3.5 and now possibly final form in 3.6.6rc1.  

Now that you know that 1) You are not required to modify your source code at 
all, even if you want to get full utility from typing, and 2) you really don't 
have use typing at all, nothing forces you to,  and 3) it's been developed by 
the Python community for years and was proposed by Guido years before he went 
to DropBox,  does that help?

-- Joe S.

-Original Message-
From: Rick Johnson  
Sent: Monday, June 18, 2018 1:16 PM
To: python-list@python.org
Subject: Re: syntax difference

Steven D'Aprano wrote:
> Moving the type-checking out of the core language into the IDE or 
> linter which can be used or not used according to the desire of the 
> programmer

Except, what your poppycock commentary seems to glaze over is the fact that 
whilst a programmer can certainly decided to "use or not use" the type-hints 
feature in his or her own code, he or she certainly cannot "see or _unsee_" 
type-hints that are written by other programmers.


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

Re: syntax difference

[Jim Lee]

On 06/18/2018 02:36 PM, Schachner, Joseph wrote:

Now that you know that 1) You are not required to modify your source code at 
all, even if you want to get full utility from typing, and 2) you really don't 
have use typing at all, nothing forces you to,  and 3) it's been developed by 
the Python community for years and was proposed by Guido years before he went 
to DropBox,  does that help?

-- Joe S.

Not at all.  As Rick said, you cannot *unsee* what other programmers 
have written.  Just because I don't personally use a feature, it doesn't 
follow that I can ignore it.  I still have to deal with other people's code.


-Jim

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

Re: Folk etymology, was Re: Python list vs google group

[Joe Pfeiffer]

Peter Otten <__pete...@web.de> writes:

> Grant Edwards wrote:
>
>> On 2018-06-18, Joe Pfeiffer  wrote:
>>> Peter Otten <__pete...@web.de> writes:
>>>
 Gene Heskett wrote:

> This biggest single thing wrong with any of those old scsi interfaces
> is the bus's 5 volt isolation diode, the designer speced a shotkey(sp)
> diode, and some damned bean counter saw the price diff and changed it
> to

 Is this a case of  ?

 https://en.wikipedia.org/wiki/Walter_H._Schottky
>>>
>>> I'm missing why the claim that management changed the spec on a diode
>>> from Schottky to conventional would be folk etymology?  Or why Gene
>>> being unsure of his spelling would?  What does any of this have to do
>>> with etymology, folk or genuine?
>> 
>> I was wondering the same thing...
>
> "folk etymology" would be the retrofitting of the exotic "Schottky" into two 
> familiar words "shot" and "key". Sometimes the writer assumes that these 
> words are somehow related to the labeled object.

This would only be a folk etymology if (1) the spelling were really
"shotkey", and (2) someone thought it was because of some tortured
derivation from "shot" and "key".

Most of the best-known examples in English are backronyms like Port
Outboard Starboard Home and For Unlawful Carnal Knowledge.

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

Re: Python list vs google group

[Gene Heskett]

On Monday 18 June 2018 11:45:45 Joe Pfeiffer wrote:

> Peter Otten <__pete...@web.de> writes:
> > Gene Heskett wrote:
> >> This biggest single thing wrong with any of those old scsi
> >> interfaces is the bus's 5 volt isolation diode, the designer speced
> >> a shotkey(sp) diode, and some damned bean counter saw the price
> >> diff and changed it to
> >
> > Is this a case of  ?
> >
> > https://en.wikipedia.org/wiki/Walter_H._Schottky
>
> I'm missing why the claim that management changed the spec on a diode
> from Schottky to conventional would be folk etymology?  Or why Gene
> being unsure of his spelling would?  What does any of this have to do
> with etymology, folk or genuine?

Its this list, Joe. Anything as long as there is a provable effect, is 
fair game here, and has been for a goodly number of years.



-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Folk etymology, was Re: Python list vs google group

[Gregory Ewing]

Peter Otten wrote:
"folk etymology" would be the retrofitting of the exotic "Schottky" into two 
familiar words "shot" and "key". Sometimes the writer assumes that these 
words are somehow related to the labeled object.


Well, there is a thing called "shot noise", and you can probaby
get it from a Shottky diode under some circumstances, but
Shottky is definitely someone's name. (Walter H. Shottky, to
be specific.)

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

Re: Folk etymology, was Re: Python list vs google group

[Jim Lee]

On 06/18/2018 04:09 PM, Gregory Ewing wrote:

Peter Otten wrote:
"folk etymology" would be the retrofitting of the exotic "Schottky" 
into two familiar words "shot" and "key". Sometimes the writer 
assumes that these words are somehow related to the labeled object.


Well, there is a thing called "shot noise", and you can probaby
get it from a Shottky diode under some circumstances, but
Shottky is definitely someone's name. (Walter H. Shottky, to
be specific.)

FWIW, we used to call them barrier diodes, or sometimes hot carrier 
diodes, until the name "Schottky" became commonplace in, what, the mid 
80s or so?


-Jim

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

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

[sa...@caprilion.com.tw]

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



---
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 (type hints)

[Steven D'Aprano]

On Mon, 18 Jun 2018 14:57:30 +, Schachner, Joseph wrote:

> Assuming that we want Python to remain a dynamically typed (but strongly
> typed) language, 

There is no question about that.


> I believe the proposed type hints are only necessary
> for function definitions,

What is the basis of this belief? How much experience do you have using 
type annotations and gradual typing?

On a scale of 0 to 10, where 0 is "never even used it", and 10 is "used 
it extensively on projects with tens or hundreds of thousands of lines of 
code", where do you fit?

Because type annotations and gradual typing *is* being used extensively 
on huge code bases at Dropbox, and they have been using it for years, and 
I can tell you that the type hinting features being added to Python, such 
as the ability to annotate names outside of function definitions, *are* 
necessary.

Which won't come as a surprise to anyone who has used languages with type 
inference. Sometimes the type system cannot infer the type of a variable 
or name, and needs a hint from the author. ML proved that nearly fifty 
years ago.

Honestly folks, you're talking as if what Python is doing is cutting edge 
experimental stuff. It isn't. It is *old and boring* and well-understood 
with nearly half a century of practical experience behind it.

You all sound like old BASIC programmers bitterly complaining about this 
new-fangled idea of "functions" when all anybody could possibly need is 
GOTO and a good memory for remembering line numbers.



-- 
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 08:10:12 -0700, Rick Johnson wrote:

> "Type-hint comments" don't exist yet.

Yes they do, and they have existed for years.


https://www.python.org/dev/peps/pep-0526/


But don't let a little thing like the fact you have no clue whatsoever 
about this stop you from pontificating about it.

Because the opinions of the ignorant are of course the most important 
thing of all, far more important than facts or experience.



-- 
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 21:03:14 +0100, Bart wrote:

> In the case of Python, it is
> already so big and has so many features crammed in that adding type
> hints probably makes little difference.

You've never used C++ have you?

Describing Python as a "big" language is ludicrous.



-- 
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: Is it possible to call a class but without a new instance created?

[Jach Fong]

It seems most of confusion comes from mixing up python object and tk
widgets, and ignored that the tkinter is really a python-tk-interface.
Thank you for pointing it out.


Terry Reedy at 2018/6/18 PM 05:19 wrote:
To answer the question of the title, which is a bit different from the 
question in the text, yes.  type(None)() always returns the singleton 
None object.  (And one can write a singleton class in Python also.) 
bool() always returns one of False or True.  int() and str() may return 
either a new or old object.  For such immutables, it does not matter as 
long at the object has the correct value.  As others said, this is all 
handled in a __new__ method.  But none of this has much to do with 
tkinter instances.


On 6/18/2018 5:09 AM, Terry Reedy wrote:

On 6/18/2018 12:48 AM, Jach Fong wrote:

After looking into the \tkiniter\font.py source file, triggered by Jim's
hint on my previous subject "Why an object changes its "address" between
adjacent calls?", I get more confused.

Below was quoted from the font.py:

def nametofont(name):
 """Given the name of a tk named font, returns a Font 
representation.

 """
 return Font(name=name, exists=True)

class Font:
 """Represents a named font.


tkinter abbreviates tk interface.  A Python tkinter Font instance 
represents a tk named font structure. It has a hidden pointer to the 
tk structure.  The same is true of all instances of tkinter widgets 
classes.  Each has a hidden pointer to a tk widget



 Constructor options are:
 ...
 exists -- does a named font by this name already exist?


Does a *tk* named font exist?

    Creates a new named font if False, points to the existing 
font if True.


Again, 'font' here means a tk structure, not a python instance.  Each 
call to Font returns a new python instance.  But for Fonts, it may or 
may not point to a new tk structure.



 ...
 """

 def __init__(self, root=None, font=None, name=None, exists=False,
  **options):
 ...


One can mostly ignore the parallel existence of python instances and 
tk structures.  But they can get out of sync during shutdown.  If t is 
an instance of Text, t.destroy() causes tkinter to tell tk to destroy 
the tk widget, leaving t useless.  Similarly, if 'del t' deletes the 
last reference to the Python instance, it may disappear, leaving the 
tk widget possibly unaccessible.







---
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: Folk etymology, was Re: Python list vs google group

[Gene Heskett]

On Monday 18 June 2018 19:24:14 Jim Lee wrote:

> On 06/18/2018 04:09 PM, Gregory Ewing wrote:
> > Peter Otten wrote:
> >> "folk etymology" would be the retrofitting of the exotic "Schottky"
> >> into two familiar words "shot" and "key". Sometimes the writer
> >> assumes that these words are somehow related to the labeled object.
> >
> > Well, there is a thing called "shot noise", and you can probaby
> > get it from a Shottky diode under some circumstances, but
> > Shottky is definitely someone's name. (Walter H. Shottky, to
> > be specific.)
>
> FWIW, we used to call them barrier diodes, or sometimes hot carrier
> diodes, until the name "Schottky" became commonplace in, what, the mid
> 80s or so?
>
> -Jim

More like the early 70's. I spent from 70, to late 77 keeping one of 
Nebraska ETV's 3rd of a megawatt transmitters on the air. One of the 
support engineers brought up a 10 pack of the first HP schottkey diodes 
up and made the claim that it was a 98% efficient rectifier at 500 mhz.  
So I removed the twin vacuum tube diode (a 6AL5) that wasn't capable of 
delivering a volt of video from a monitoring test point into astd 75 ohm 
load, and soldered one of this new HP diodes in its place.  I had to 
lift it back out of its mount nearly 3/4" just to get it down to one 
volt.  It didn't take me long to modify the other 5.
 
-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Jach Fong]

Ben Finney at 2018/6/18 PM 03:29 wrote:

Jach Fong  writes:


I also make a test of my own and it fails too.


class A:

... objs = []
... def __init__(self, exists=False):
... if exists:  self = self.objs[0]


The function parameters (bound here to the names ‘self’, ‘exists’) are
in the local function scope. After the function ends, the scope of those
names ends; those name bindings no longer affect anything. So, changing
what ‘self’ refers to has no effect on the A instance that exists.

In other words: Creating the instance is the responsibility of the
constructor method (a class method named ‘__new__’), and that instance
is what gets passed to the instance initialiser (an instance method
named ‘__init__’).

The initialiser has no control over what instance gets passed in, and no
control over that same instance being returned from the constructor.


What I expect is that id(a0) and id(a1) has the same value. They
should points to the same object.


You can't get that effect from within the instance initialiser. What you
need to do is change the class constructor (named ‘__new__’), and that's
a more advanced topic I leave you to research on your own.


class B:
_obj = None
def __new__(*args, **kwargs):
if not B._obj:
B._obj = object.__new__(*args, **kwargs)
return B._obj

b0 = B()
b1 = B()
assert b0 is b1

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

--Jach

---
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: Is it possible to call a class but without a new instance created?

[Ben Finney]

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?

-- 
 \ “The Vatican is not a state.… a state must have territory. This |
  `\ is a palace with gardens, about as big as an average golf |
_o__) course.” —Geoffrey Robertson, 2010-09-18 |
Ben Finney

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

Re: syntax difference (type hints)

[Dan Stromberg]

On Mon, Jun 18, 2018 at 5:45 PM, Steven D'Aprano <
steve+comp.lang.pyt...@pearwood.info> wrote:

> On Mon, 18 Jun 2018 14:57:30 +, Schachner, Joseph wrote:
> > I believe the proposed type hints are only necessary
> > for function definitions,
>
> What is the basis of this belief? How much experience do you have using
> type annotations and gradual typing?
>
> On a scale of 0 to 10, where 0 is "never even used it", and 10 is "used
> it extensively on projects with tens or hundreds of thousands of lines of
> code", where do you fit?
>
I've done 10 projects of varying sizes with Python 3 type hints now.  Some
I wrote from scratch with type hints from the beginning, others I
retrofitted type hints into existing code.

I've found that I mostly add type hints to function definitions, but
infrequently I have to add them to the creation of collection types, like
an empty list or empty dictionary.

I tend to call mypy like:
mypy --disallow-untyped-call foo.py bar.py

...or:
mypy --disallow-untyped-calls --ignore-missing-imports foo.py bar.py

...if there are dependency modules that don't (yet?) have type hints in
them.

I'm eager to try MonkeyType and/or pep484transform.py to automatically add
type hints, but so far I've only added them manually.  It remains to be
seen (by me, at least) how many nonessential names will be type hinted by
these tools.

Instagram says mypy is by far the most common python type checker, but they
like "pyre" for its speed, which is another type checker.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Dan Stromberg]

On Mon, Jun 18, 2018 at 5:52 PM, Steven D'Aprano <
steve+comp.lang.pyt...@pearwood.info> wrote:

> On Mon, 18 Jun 2018 21:03:14 +0100, Bart wrote:
>
> > In the case of Python, it is
> > already so big and has so many features crammed in that adding type
> > hints probably makes little difference.
>
> You've never used C++ have you?
>
> Describing Python as a "big" language is ludicrous.
>
Actually, I think Python is getting a bit big. I feel like there may be a
push to add "important" features to 3.x to make people want to move off of
2.x.  But that's making it hard for the many other implementations of
Python to catch up (and stay caught up).

What would I remove, if Python weren't used in production all over the
world?

map and filter.  metaclasses.  List comprehensions.  "feature strings" (AKA
"f strings").  And that new := assignment expression makes me shudder -
that's something I haven't missed at all since I switched from C to Python.

I'm pleased that machine int's and long's were unified.

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.
-- 
https://mail.python.org/mailman/listinfo/python-list