Re: syntax difference (type hints)

[Gregory Ewing]

Steven D'Aprano wrote:
Sometimes the type system cannot infer the type of a variable 
or name, and needs a hint from the author.


Or it can infer it, but is unable to produce intelligible
error messages without some intermediate signposts to
follow.

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

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

[Tal Einat]

Tal Einat  added the comment:

> What do you think of changing 'ToolTip' to 'Tooltip'?

+1, I'll change it.

> TclError from widget.destroy suggests that we *might* be able to cleanup 
> better.

The try/except clauses which are hard to test are used since the order in which 
widgets are destroyed can vary, and I don't know how to properly check whether 
a widget still exists (so that e.g. unbinding events won't throw an exception).

For the on-hover tooltip, events are registered on the "anchor" widget.  ISTM 
these events should be unregistered when the tooltip is destroyed, hence I 
added that to __del__.  Any suggestions for a better cleanup mechanism?

>> The TclError exceptions are reproduced by the htest in tooltip.py.
> With the code as is?  Or if the try-except is removed?
Without the try/except.

> I [...] would like the popups to respond keyboard (Tab) focus changes as well 
> as mouse movement focus changes.

Looking at the Tk docs, it seems this will require binding properly to the 
FocusIn and oFocusOut events.  This is indeed a separate mechanism.  It should 
be straightforward when bound to a simple widget such as a button.  The Calltip 
class will need to override this since it already implements an appropriate 
alternative.

--

___
Python tracker 

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

Re: syntax difference

[Dan Stromberg]

On Mon, Jun 18, 2018 at 10:08 PM, Chris Angelico  wrote:

> On Tue, Jun 19, 2018 at 1:46 PM, Dan Stromberg 
> wrote:
> > Great languages are small but extensible, easy to read, and don't require
> > learning a lot before you can get started writing code or reading someone
> > else's code.
> >
> > Great languages: C and Scheme.  And Python.
> >
> > But isn't Lua smaller than Python?  That thought worries me a little.
>
> It's a lot smaller. And that worries me ONLY to the extent that I
> might, at some point, have to write something in Lua. I would much
> rather use a richer language than a poorer one, any day.
>
Some size is useful.  A lot of "richness" leads you to Perl.

You
> learn new language constructs and they are completely orthogonal; you
> use those constructs and they interact infinitely.
>
Agreed.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Chris Angelico]

On Tue, Jun 19, 2018 at 1:46 PM, Dan Stromberg  wrote:
> Great languages are small but extensible, easy to read, and don't require
> learning a lot before you can get started writing code or reading someone
> else's code.
>
> Great languages: C and Scheme.  And Python.
>
> But isn't Lua smaller than Python?  That thought worries me a little.

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

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

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

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

[Karthikeyan Singaravelan]

Karthikeyan Singaravelan  added the comment:

Thanks @prawin for the confirmation. There is a mailing list discussion at 
https://groups.google.com/forum/#!topic/python-ideas/Ny1RN9wY0cI and it seems 
this is related to Thai language locale. Feel free to add in if you have any 
more input on if it's reproducible in maybe other machines of Thai locale or so 
on. There is a PR that adds alias along with other missing items but I will 
wait for others to chime in to see if there is a better solution to fix this.

Thanks.

--

___
Python tracker 

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

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

[Terry J. Reedy]

Change by Terry J. Reedy :


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

___
Python tracker 

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

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

[Prawin Phichitnitikorn]

Prawin Phichitnitikorn  added the comment:

Sorry for late Reply,

But for me I'm resolve by adding 

# cp874 codec
'874': 'cp874',

to alias.py file

--

___
Python tracker 

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

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

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Spinoffs:
 change rstrip.RstripExtension to Rstrip
 change stackviewer.StackBrowser to accept exception

--
stage: patch review -> test needed

___
Python tracker 

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

Re: syntax difference

[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

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

[issue33872] doc Add list access time to list definition

[Xiang Zhang]

Xiang Zhang  added the comment:

I concur with INADA. I don't prefer to add such implementation choice in 
definition. As for glossary, it may be unnecessary either but since it's 
already there, I don't think it needs to be removed.

--
nosy: +xiang.zhang

___
Python tracker 

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

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

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

[issue33894] tempfile.tempdir cannot be unset

[Eric V. Smith]

Eric V. Smith  added the comment:

I like philiprowlands' version:

- If tempdir is unset or None at any call to
+ If tempdir is None (the default) at any call to

Care to produce a PR?

--
versions: +Python 2.7, Python 3.6, Python 3.7

___
Python tracker 

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

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

[issue33894] tempfile.tempdir cannot be unset

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

What about:

"If tempdir is unset or None (the default value has not been modified) ..." 

?

--
nosy: +pablogsal

___
Python tracker 

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

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

[issue33898] pathlib issues with Windows device paths

[Eryk Sun]

New submission from Eryk Sun :

For \\?\ extended device paths, pathlib removes the trailing slash for the root 
directory if the device isn't UNC or a logical (A-Z) drive.

Correct:

>>> str(Path('//?/UNC/'))
'?\\UNC\\'

>>> str(Path('//?/Z:/'))
'?\\Z:\\'

Incorrect:

>>> str(Path('//?/BootPartition/'))
'?\\BootPartition'

>>> str(Path('//?/Volume{}/'))
'?\\Volume{}'

>>> str(Path('//?/Global/Z:/'))
'?\\Global\\Z:'

It keeps the trailing slash for some \\.\ paths, but not all.

Correct:

>>> str(Path('//./BootPartition/'))
'.\\BootPartition\\'

Incorrect:

>>> str(Path('//./Global/Z:/'))
'.\\Global\\Z:'

It adds a root directory to \\.\ device paths where none was specified. 

Incorrect:

>>> str(Path('//./nul'))
'.\\nul\\'

>>> str(Path('//./PhysicalDrive0'))
'.\\PhysicalDrive0\\'

>>> str(Path('//./C:'))
'.\\C:\\'

".\\C:" refers to the volume device, whereas ".\\C:\\" is the root 
directory in the file system.

pathlib should parse \\?\ and \\.\ device paths the same way with respect to 
the drive and root. The difference in practice is only how Windows does (\\.\) 
or does not (\\?\) canonicalize the path. 

Additionally, pathlib fails to identify the drive correctly in these cases.

Incorrect:

>>> Path('//?/Global/Z:/').drive
'?\\'

>>> Path('//?/BootPartition/Temp').drive
'?\\'

Except for "UNC" and "Global" paths, the drive should be the first component 
after the local-device prefix. The "UNC" device also includes subsequent server 
and share components, if any. For the reserved "Global" symlink, it should look 
to the next component. For example, r'\\?\Global\UNC\server\share' is a drive. 

There's also the "GlobalRoot" symlink (or "Global\\GlobalRoot" to be pedantic), 
but that can't be handled generically.

--
components: Library (Lib), Windows
messages: 319921
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: test needed
status: open
title: pathlib issues with Windows device paths
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

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

[issue32962] test_gdb fails in debug build with `-mcet -fcf-protection -O0`

[STINNER Victor]

STINNER Victor  added the comment:

Related issue: bpo-31237.

--

___
Python tracker 

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

Re: syntax difference

[Jim Lee]

On 06/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

[issue33896] filecmp.cmp returns True on files that differ

[Dean Morin]

Dean Morin  added the comment:

Fair enough, how about just making it clearer in the documentation? Currently 
you need to look at the source code to see what would be required for a 
signature clash to occur. Maybe something like:

Note that the [os.stat()](https://docs.python.org/3/library/os.html#os.stat) 
signatures only consider 
[st_mode](https://docs.python.org/3/library/os.html#os.stat_result.st_mode), 
[st_size](https://docs.python.org/3/library/os.html#os.stat_result.st_size), 
and 
[st_mtime](https://docs.python.org/3/library/os.html#os.stat_result.st_mtime). 
In some circumstances it's possible for differing files to be considered equal 
when _shallow_ is `True`.

--

___
Python tracker 

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

[issue32962] test_gdb fails in debug build with `-mcet -fcf-protection -O0`

[STINNER Victor]

STINNER Victor  added the comment:

> 1) Skip whole test_gdb when optimizations are used (who debugs with them 
> anyway?)

It's already done, no? But the title issue is "-mcet -fcf-protection
-O0" and -O0 disables optimizations.

--

___
Python tracker 

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

[issue33663] Web.py wsgiserver3.py raises TypeError when CSS file is not found

[miss-islington]

miss-islington  added the comment:


New changeset 8c19a44b63033e9c70e9b552476baecb6e3e9451 by Miss Islington (bot) 
in branch '3.6':
bpo-33663: Convert content length to string before putting to header (GH-7754)
https://github.com/python/cpython/commit/8c19a44b63033e9c70e9b552476baecb6e3e9451


--

___
Python tracker 

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

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

[issue33663] Web.py wsgiserver3.py raises TypeError when CSS file is not found

[miss-islington]

miss-islington  added the comment:


New changeset 53d1e9fad316e1404535157fe21cab8919f707c9 by Miss Islington (bot) 
in branch '3.7':
bpo-33663: Convert content length to string before putting to header (GH-7754)
https://github.com/python/cpython/commit/53d1e9fad316e1404535157fe21cab8919f707c9


--
nosy: +miss-islington

___
Python tracker 

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

[issue33663] Web.py wsgiserver3.py raises TypeError when CSS file is not found

[miss-islington]

Change by miss-islington :


--
pull_requests: +7388

___
Python tracker 

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

[issue33663] Web.py wsgiserver3.py raises TypeError when CSS file is not found

[miss-islington]

Change by miss-islington :


--
pull_requests: +7387

___
Python tracker 

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

[issue33663] Web.py wsgiserver3.py raises TypeError when CSS file is not found

[Steve Dower]

Steve Dower  added the comment:


New changeset b36b0a3765bcacb4dcdbf12060e9e99711855da8 by Steve Dower 
(ValeriyaSinevich) in branch 'master':
bpo-33663: Convert content length to string before putting to header (GH-7754)
https://github.com/python/cpython/commit/b36b0a3765bcacb4dcdbf12060e9e99711855da8


--

___
Python tracker 

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

[issue28710] Sphinx incompatible markup in the standard library docstrings

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I agree with David.  I would like the ugly markup changed independent of how 
Sphinx treats it.  I was thinking of changing the title to "Change obsolete tex 
markup in stdlib docstrings".  The intent of `word' was for people to see 
balanced quotes, which in ascii text means 'word'.

--

___
Python tracker 

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

Re: syntax difference

[Chris Angelico]

On 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

[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

[issue33896] filecmp.cmp returns True on files that differ

[R. David Murray]

R. David Murray  added the comment:

For your problem, just don't use the default shallow setting :)

--

___
Python tracker 

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

[issue33896] filecmp.cmp returns True on files that differ

[R. David Murray]

R. David Murray  added the comment:

I understand your concern, but this is working as designed and documented.  
Using st_ino would mean you would return true if and only if it was the *same* 
file.  That is not the intent.  See issue 27396 for some background discussion.

--
nosy: +r.david.murray
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

Re: syntax difference

[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

[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

[issue33897] Add a restart option to logging.basicConfig()

[Raymond Hettinger]

New submission from Raymond Hettinger :

Once a logger or basicConfig() has been called, later calls to basicConfig() 
are silent ignored.  The makes it very difficult to experiment with or teach 
the various options at the interactive prompt or in a Jupyter notebook.

What we have:

>>> import logging
>>> logging.warning('Too much data')
WARNING:root:Too much data
>>> logging.info('Volume is at 80%')
>>> logging.basicConfig(level=logging.INFO)
>>> logging.info('Volume is at 80%')
>>> # Note, no output was created

What we need:

>>> import logging
>>> logging.warning('Too much data')
WARNING:root:Too much data
>>> logging.info('Volume is at 80%')
>>> logging.basicConfig(level=logging.INFO, restart=True)
>>> logging.info('Volume is at 80%')
INFO:rootVolume is at 80%

--
assignee: vinay.sajip
components: Library (Lib)
messages: 319911
nosy: rhettinger, vinay.sajip
priority: normal
severity: normal
status: open
title: Add a restart option to logging.basicConfig()
type: enhancement
versions: Python 3.8

___
Python tracker 

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

[issue28710] Sphinx incompatible markup in the standard library docstrings

[R. David Murray]

R. David Murray  added the comment:

I would still like to see the legacy tex markup removed from the docstrings, so 
I think closing this issue is not appropriate, but it's not a big enough deal 
that I'll push for it if Raymond wants to keep it closed.

--

___
Python tracker 

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

[issue32962] test_gdb fails in debug build with `-mcet -fcf-protection -O0`

[Charalampos Stratakis]

Charalampos Stratakis  added the comment:

I'd say there are use cases where gdb will be used with optimizations 
especially in downstream distribution.

--

___
Python tracker 

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

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

[issue28710] Sphinx incompatible markup in the standard library docstrings

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Marking this as closed.  Though well-intentioned, the suggestion is predicated 
on a misperception of the role of Sphinx for CPython and existing PEP 
recommendations on docstring practices.

--
nosy: +rhettinger
resolution:  -> not a bug
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

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

[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

[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

[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

[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

[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

[issue28710] Sphinx incompatible markup in the standard library docstrings

[Terry J. Reedy]

Terry J. Reedy  added the comment:

RestructuredText, DocUtils, and Sphinx were developed independently, by people 
other than the pydev/cpython group.  (The proposal to include DocUtils in the 
stdlib was rejected.)  We converted to .rst for the Python documentation 
sources files about a decade ago.  Sphinx turns them into the .html files you 
can see online.  RestructuredText markup can now also be used in PEP, 
news/changelog, and What's New sources.  These are things that most people only 
view online or in other processed forms, not in source form.

On the other hand, stdlib docstrings are mostly viewed unprocessed in .py 
sources or as output from help() in text consoles or text widgets.  So markup 
in stdlib docstrings would impact everyone, not just core developers.

--

___
Python tracker 

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

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

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

[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

[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

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

[issue33895] LoadLibraryExW called with GIL held can cause deadlock

[Tony Roberts]

Tony Roberts  added the comment:

Sure, I'll get that done in the next couple of days.

--

___
Python tracker 

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

[issue33895] LoadLibraryExW called with GIL held can cause deadlock

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Do you want to submit a PR for this?  You can take a look at our developer's 
guide if you're new to contributing to Python:
https://devguide.python.org/

--
nosy: +pitrou
stage:  -> needs patch
type:  -> behavior
versions:  -Python 2.7, Python 3.4, Python 3.5

___
Python tracker 

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

Re: syntax difference

[Jim Lee]

On 06/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

[issue28710] Sphinx incompatible markup in the standard library docstrings

[Patrick Lehmann]

Patrick Lehmann  added the comment:

Having single quotes in docstrings is also ok for Sphinx documentation.

Btw. ReStructured text (docutils) was invented to document Python sources, why 
is it not used by Python?

--

___
Python tracker 

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

Re: syntax difference

[Chris Angelico]

On 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

[issue33896] filecmp.cmp returns True on files that differ

[Dean Morin]

New submission from Dean Morin :

By default `filecmp.cmp()` has `shallow=True` which can produce some surprising 
behavior.

In the docs it states:

> If shallow is true, files with identical os.stat() signatures are taken to be 
> equal.

However the "signature" only considers the file mode, file size, and file 
modification time, which is not sufficient. `cmp()` will return `True` (files 
are equal) in some circumstances for files that actually differ. Depending on 
the underlying file system, the same python script will return `True` or 
`False` when `cmp()` is called on the exact same files. I'll add the 
long-winded details at the bottom.

To fix, I believe `st.st_ino` should be included in `_sig` 
(https://github.com/python/cpython/blob/3.7/Lib/filecmp.py#L68).

I'm in the middle of a move, but I can make a PR in the next couple weeks if 
this seems like a reasonable fix and no one else gets around to it.

The long version is that we're migrating some existing reports to a new data 
source. The goal is to produce identical csv files from both data sources. I 
have a python script that pulls down both csv files and uses `cmp()` to compare 
them. 

On my machine, the script correctly discovers the differences between the two. 
One of the date columns has incorrect dates in the new version.

However on my colleagues machine, the script fails to discover the differences 
and shows that the csv files are identical.

The difference is that on my machine, `os.stat(f).st_mtime` is a timestamp 
which includes fractional seconds (1529108360.1955538), but only includes the 
seconds (1529108360.0) on my colleagues machine. Since only the dates differed 
within the csvs, both files had the same file mode, file size, and both were 
downloaded within the same second.

We got a few more people to see what they got for `st_mtime`. The link could be 
the file system used. We're all using macs, but for those of us using an APFS 
Volume disk, `st_mtime` returns a timestamp which includes fractional seconds, 
and for those of us using a Logical Volume Mac OS Extended disk, it returns a 
timestamp which only includes the seconds (1529108360.0).

When comparing os.stat() between the two differing csv files, the only 
difference (other than fractional seconds for various timestamps) was `st_ino` 
which is why I believe it should be included in `_sig()`.

--
components: Library (Lib)
messages: 319904
nosy: Dean Morin
priority: normal
severity: normal
status: open
title: filecmp.cmp returns True on files that differ
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7

___
Python tracker 

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

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

[issue33301] Add __contains__ to pathlib

[Andrew Berger]

Andrew Berger  added the comment:

I can make these changes. Would probably add a .exists method to PurePath, 
using the _normal_accessor.stats staticmethod, then call that in __contains__

--
nosy: +aberger5b

___
Python tracker 

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

[issue28710] Sphinx incompatible markup in the standard library docstrings

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Oh, you are right. I didn't write much English TeX, and used other types 
of quotes.

I'm sure that I seen `such quotation' in non-TeX files, but maybe my 
memory fools me. In any case using this writing here is likely an 
artifact of copying from a TeX documentation.

--

___
Python tracker 

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

Re: syntax difference

[Ian Kelly]

On Mon, Jun 18, 2018 at 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

[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

[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

[issue28710] Sphinx incompatible markup in the standard library docstrings

[Terry J. Reedy]

Terry J. Reedy  added the comment:

> AFAIK `name' is common writing of quotes in English texts

I don't remember ever seeing it before.  It looks like a typo to me, and I am 
sure it will to most readers.  I think it should be corrected as if it were a 
typo.

--

___
Python tracker 

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

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

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

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

[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

[issue33893] Linux terminal shortcuts support in python shell

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Thanks. I have presumed that Linux consoles are also line oriented, but 
hesitated to say so without really knowing so.

--

___
Python tracker 

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

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

[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

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]

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

[issue28710] Sphinx incompatible markup in the standard library docstrings

[R. David Murray]

R. David Murray  added the comment:

No, it is (somewhat) unique to tex.  If you write `word' tex would turn that 
into a pair of opposing quotes in the typeset document, as opposed to 'word' 
(the convention in regular text/emails/posts/etc) where you'd just see ascii 
quotes.  tex would render 'word' as a closing quote both before and after word, 
which looks weird in typeset text.

There's no bug here; as you say we aren't interested in making the docstrings 
parseable as restructured text (at least, I'm not).  For me, this is about 
getting rid of the now-odd-looking tex leftovers and making the ascii styling 
consistent with the bulk of our docstrings.

It's not a big deal, though.

--

___
Python tracker 

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

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

[issue28710] Sphinx incompatible markup in the standard library docstrings

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

What is the problem? Docstrings are not written in the reStructuredText format 
in general. If Sphinx complains about docstrings in the stlib, don't run Sphinx 
for the stdlib files or report a Sphinx bug. Even if remove all `x', docstrings 
still will not be valid reStructuredText. For example the last three lines will 
be joined in a single paragraph for the docstring in msg319848.

`name' does not have special meaning in (La)TeX. AFAIK `name' is common writing 
of quotes in English texts. It predates reStructuredText and was widely used in 
Usenet and mailing lists (as two spaces after sentence-ending punctuation, 
double hyphen for a dash, _n_a_m_e_ to simulate underscoring, etc). It is just 
a part of old computer-typing culture (or may be even pre-computer).

--
nosy: +serhiy.storchaka

___
Python tracker 

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

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

[issue33866] Stop using OrderedDict in enum

[INADA Naoki]

New submission from INADA Naoki :


New changeset e57f91a0f0d5700ec466c9dd0fd2d2b5323a5e76 by INADA Naoki in branch 
'master':
bpo-33866: enum: Stop using OrderedDict (GH-7698)
https://github.com/python/cpython/commit/e57f91a0f0d5700ec466c9dd0fd2d2b5323a5e76


--

___
Python tracker 

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

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

[issue33894] tempfile.tempdir cannot be unset

[Philip Rowlands]

Philip Rowlands  added the comment:

How about

- If tempdir is unset or None at any call to
+ If tempdir is None (the default) at any call to

This avoids headaches over the meaning of "unset", and accurately reflects the 
code at:
https://github.com/python/cpython/blob/3.6/Lib/tempfile.py#L289

--

___
Python tracker 

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

[issue23660] Turtle left/right inverted when using different coordinates orientation

[Carol Willing]

Carol Willing  added the comment:

Reopened at the request of the original submitter.

--
resolution: remind -> 
stage: resolved -> patch review
status: closed -> open

___
Python tracker 

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

[issue28710] Sphinx incompatible markup in the standard library docstrings

[R. David Murray]

R. David Murray  added the comment:

By the way, in case anyone is curious, I'm pretty sure that markup is left over 
from the days when tex/latex was what docs were *written* in.

--

___
Python tracker 

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

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

[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

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

[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

[issue28710] Sphinx incompatible markup in the standard library docstrings

[R. David Murray]

R. David Murray  added the comment:

Right, my opinion is that we shouldn't be putting markup in docstrings.  They 
are (from our point of view) pure text.

I don't know if discussion on python-dev is warranted, it seems like a fairly 
uncontroversial change, since it brings the docstrings in question into 
compliance with our general practice in the majority of the stdlib.  Unless my 
impression about that is wrong :)

I don't have an opinion on multiple versus single PR for this.

--

___
Python tracker 

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