[issue38263] [Windows] multiprocessing: DupHandle.detach() race condition on DuplicateHandle(DUPLICATE_CLOSE_SOURCE)

[Leonardo Rick]

Leonardo Rick  added the comment:

Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Program Files\Python39\lib\multiprocessing\spawn.py", line 116, in 
spawn_main
exitcode = _main(fd, parent_sentinel)
  File "C:\Program Files\Python39\lib\multiprocessing\spawn.py", line 126, in 
_main
self = reduction.pickle.load(from_parent)
  File "C:\Program Files\Python39\lib\multiprocessing\connection.py", line 967, 
in rebuild_pipe_connection
handle = dh.detach()
  File "C:\Program Files\Python39\lib\multiprocessing\reduction.py", line 131, 
in detach
return _winapi.DuplicateHandle(
PermissionError: [WinError 5] Acesso negado

--
nosy: +leonardo2
versions: +Python 3.9 -Python 3.8

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

[issue42620] documentation on `getsockname()` wrong for AF_INET6

[Rick van Rein]

Rick van Rein  added the comment:

Excellent, thanks.  I personally would appreciate if a remark about IPv6 would 
also be made.

--

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

[issue42620] documentation on `getsockname()` wrong for AF_INET6

[Rick van Rein]

New submission from Rick van Rein :

Shown in the session below is unexpected output of a 4-tuple from an AF_INET6 
socket along with documentation that *suggests* to expect a 2-tuple.  The 
phrasing "IP" might have to be toned down to "IPv4" or "AF_INET" to be accurate 
enough to avoid confusion.

Opinion: I think you should be explicit about the different behaviour for 
AF_INET6, so it is not reduced to a special/nut case for special interest 
groups.  IPv6 has a hard enough time getting in; different formats for AF_INET 
and AF_INET6 should ideally be shown to all programmers, to at least avoid 
*uninformed* decisions to be incompatible with IPv6 while they develop on an 
IPv4 system (and the same in the opposite direction).


Python 3.7.3 (default, Jul 25 2020, 13:03:44) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> sox6 = socket.socket (socket.AF_INET6)
>>> sox6.getsockname ()
('::', 0, 0, 0)
>>> sox6.getsockname.__doc__
'getsockname() -> address info\n\nReturn the address of the local endpoint.  
For IP sockets, the address\ninfo is a pair (hostaddr, port).'

--
components: Library (Lib)
messages: 382863
nosy: vanrein
priority: normal
severity: normal
status: open
title: documentation on `getsockname()` wrong for AF_INET6
type: behavior
versions: Python 3.7

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

[issue37296] pdb next vs __next__

[Rick]

Rick  added the comment:

I have no idea what program this was in, it's lost in the depths of time.
I can't retain these things for over a year, too old, maybe in my twenties I 
would have remembered what code this was in but no longer.
Can it.

--

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

[issue39580] Check for COMMAND_LINE_INSTALL variable in Python_Documentation.pkg

[Rick Heil]

Change by Rick Heil :


--
keywords: +patch
nosy: +rickheil
nosy_count: 3.0 -> 4.0
pull_requests: +19551
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/20271

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

[issue39580] Check for COMMAND_LINE_INSTALL variable in Python_Documentation.pkg

[Rick Heil]

Rick Heil  added the comment:

In case folks reading this are not aware, installer(8) sets an environmental 
variable COMMAND_LINE_INSTALL when an installation is triggered on the command 
line versus when a user double-clicks a package in the GUI to kick off the 
install.

I've filed the linked PR to add a test on the APPDIR open statement to avoid 
popping up the Finder when the package is installed on the command line. If 
there's a different method by which I should do this, please point me in the 
vague direction and I'm happy to update!

(note - I just signed the CLA today so it should be registered soonish)

--

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

[issue39637] Probably incorrect message after failed import

[Rick van Rein]

Change by Rick van Rein :


--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

[issue39637] Probably incorrect message after failed import

[Rick van Rein]

Rick van Rein  added the comment:

Thanks for explaining.  It is indeed confusing, even though I'm quite 
experienced with Python.

--

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

[issue39637] Probably incorrect message after failed import

[Rick van Rein]

New submission from Rick van Rein :

The following error message surprises me:

>>> import os.environ
Traceback (most recent call last):
  File "", line 1, in 
ModuleNotFoundError: No module named 'os.environ'; 'os' is not a package

Shouldn't that say that "'environ' is not a package" instead?

After all, 'os' will support

>>> import os.path
>>> 

This is confusing :)

--
components: Interpreter Core
messages: 362011
nosy: vanrein
priority: normal
severity: normal
status: open
title: Probably incorrect message after failed import
versions: Python 3.7

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

[issue37296] pdb next vs __next__

[Rick]

New submission from Rick :

Don't know how to get version from pdb, Makefile says 2.7

Code runs but when debugging I get an error that an iterator has no next() 
function.  It has got a __next__() function, and it runs, just not under pdb.

If I create a spurious next() function, pdb runs, and calls the __next__() 
function.

--
messages: 345712
nosy: tsingi
priority: normal
severity: normal
status: open
title: pdb next vs __next__
type: behavior

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

Re: Python for beginners or not? [was Re: syntax difference]

[Rick Johnson]

  To: Steven D'Aprano
From: Rick Johnson 

On Monday, June 25, 2018 at 5:56:04 AM UTC-5, Steven D'Aprano wrote:

> Nearly everybody misses the fact that the Zen is a joke,
> not to be taken *too* seriously. A particularly subtle
> joke, but still a joke.

The Python Zen is not merely a joke. But it does outline the philosophy of a
Python programmer in a humorous and self- contradicting manner. So while you
shouldn't read the Zen as some sort of religious law, you shouldn't dismiss it
as a joke either. Like a Monty Python skit, the Zen exposes the hypocrisy of
reality and does so in a humorous way.

> Not satisfied with those two ways, Tim invented his own.
>
> https://bugs.python.org/issue3364

BS! If there is one skill that we pythonista's all share, it is an uncanny
ability to glaze over our obvious mistakes with beautiful, sweet lies.

"A bug???"

"Whaddya mean a bug?"

"That's not a bug!"

"It's a feature!"

"Here, allow me to explain..."

[...snip two hours of monologue...]

Alas!

If only we had followed our _true_ calling and became lawyers.

(at least we would have been forced to dress respectively) ;-)

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Rick Johnson]

  To: Steven D'Aprano
From: "Rick Johnson" 

  To: Steven D'Aprano
From: Rick Johnson 

On Sunday, June 24, 2018 at 10:05:14 AM UTC-5, Steven D'Aprano wrote: [...]
> Be fair. It's more like 50% of the time. Let's not dogpile
> onto Bart. He asked a question, I answered it, we don't all
> need to sink the boot in as well.

And why am i _not_ surprised to learn that Steven defines "community" as
kicking and dogpiling others 50% of the time.

Well, at least it wasn't 100%...

Eh? o_O

-+- BBBS/Li6 v4.10 Toy-3
 + Origin: Prism bbs (1:261/38)

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Anyone here on Python-Dev mailing list?

[Rick Johnson]

  To: Steven D'Aprano
From: Rick Johnson 

Steven D'Aprano wrote:
[...]
> I get spam bots trying to flush out suckers. I don't get
> bots that send out random messages to random people. Why?

Steven, my son, i suppose some questions just answer themselves...

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Rick Johnson]

  To: Steven D'Aprano
From: Rick Johnson 

On Sunday, June 24, 2018 at 10:05:14 AM UTC-5, Steven D'Aprano wrote: [...]
> Be fair. It's more like 50% of the time. Let's not dogpile
> onto Bart. He asked a question, I answered it, we don't all
> need to sink the boot in as well.

And why am i _not_ surprised to learn that Steven defines "community" as
kicking and dogpiling others 50% of the time.

Well, at least it wasn't 100%...

Eh? o_O

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Rick Johnson]

From: Rick Johnson 

On Sunday, May 20, 2018 at 5:29:11 PM UTC-5, Mikhail V wrote:

> What against PDF?

I'm not a big fan of PDF either. Adobe Reader is one the most bloated POS
software i have ever had the misfortune of hosting on my computers, and i
absolutely refuse to host that crapware any longer. And while there are smaller
 more sane PDF viewers and editors, i find the whole experience of PDF to be
annoying.

I would suggest sticking with HTML or raw text. Every computer worth its salt
has a web browser, but not every computer needs (yet another) special purpose
document format (PUKE!). And I refuse to participate in the propagation of the
PDF file format.

> Anyway, I have reloaded files with most recent corrections in various
formats:
>
> PDF
> https://github.com/Mikhail22/Documents/blob/master/data-blocks-v01.pdf
>
> TXT
> https://github.com/Mikhail22/Documents/blob/master/data-blocks-v01.txt
>
> HTML(direct preview link)
> http://htmlpreview.github.io/?https://raw.githubusercontent.com/Mikhail22/Doc
uments/master/data-blocks-v01.html

Thanks for providing the last two "sane" formats.

--- BBBS/Li6 v4.10 Toy-3
 * Origin: Prism bbs (1:261/38)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Rick Johnson]

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

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

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

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

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

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

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

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

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

Go ahead now

Give 'er a go!

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

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

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

Huh???

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

Hmm???

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

Sure, there are certain exceptions to this rule, like forced
indentation, for instance, but, compared to other languages,
Python is perhaps one o

Re: syntax difference

[Rick Johnson]

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

"Day one"??? 

Really? 

"People"???

How many people?

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

Hmm? 

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

Re: syntax difference

[Rick Johnson]

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

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

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

Re: syntax difference

[Rick Johnson]

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

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

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

Re: syntax difference

[Rick Johnson]

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

My point is perfectly clear to anyone who bothers to read it
in its entirety.

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

And yet, this whole thread has been a giant cascade of
distractions from that one, simple, question.

It is obvious to the impartial reader what is going on here.

There is a systematic campaign of brow beating underway to
punish those who do not blindly accept the validity of type-
hints. And any wavering from the the official party line
will be subject to retributions.

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

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

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

And wouldn't that be nice?

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

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

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

Re: syntax difference

[Rick Johnson]

Chris Angelico wrote:
[...]
> assert """
> , ", ";print('Will I print?');\
> "';print("Or will I?");\
> ';print("What about me?");'''\
> print("And me? Where endeth");"""\
> print('the assertion?');\

Chris, that's not code...

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

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

Re: syntax difference

[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

[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

[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

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

Re: syntax difference

[Rick Johnson]

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

Yes, they are.

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

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

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

After all, it's the Python way.

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

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

Re: syntax difference

[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

[Rick Johnson]

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

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

Re: syntax difference

[Rick Johnson]

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

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

Re: syntax difference

[Rick Johnson]

On Sunday, June 17, 2018 at 9:22:57 PM UTC-5, Chris Angelico wrote:
> First, 

No. 

You're not squirming your way out this one Chris. 

_You_ leveled the assertion that removing interleaved type-
hints from the executable code would be easier than removing
my proposed "type-hint comments".

What was the quote??? 

Oh, i remember:

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

Now. Put up, or shut up.

> [...]

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

Re: syntax difference

[Rick Johnson]

 Chris Angelico wrote:
[...] 
> A. Isn't it cute, how he thinks that comments are easier to remove
> than other elements equally well defined in the grammar?

And may we see your code that will remove all instances of type-hints error 
free? 

Hmm?

I look forward to scraping the internet for source code i can try it on, and 
then posting the tracebacks here for all to see.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Rick Johnson]

On Sunday, June 17, 2018 at 3:58:26 PM UTC-5, Dan Stromberg wrote:
[...]
> I actually really like Python's type hinting, which I've recently started
> using.  I've now used it on 10 projects, and I imagine I'll be using it in
> many more.
> 
> Don't like them?  I guess you don't have to use them.

Go ahead an be cocky if you want to. 

But just remember this:

People like myself will outright refuse to maintain your
code. And do you know what that means Dan? It means your
code will _die_! And then we will get paid to rewrite your
code. 

Code that will be far more maintainable than the syntactical
mess you wrote. And if we want static typing -- no problem!
-- we'll convince out clients to switch to a language that
has *REAL* static typing. 

Okay? 

Howdya like that?

(shills gonna do what shills gonna do, i guess @_@)

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

Re: syntax difference

[Rick Johnson]

On Sunday, June 17, 2018 at 4:17:33 PM UTC-5, Chris Angelico wrote:
> On Mon, Jun 18, 2018 at 7:10 AM, Jim Lee  wrote:
> >
> >
> > On 06/17/2018 01:56 PM, Chris Angelico wrote:
> >>
> >> On Mon, Jun 18, 2018 at 6:50 AM, Jim Lee  wrote:
> >>>
> >>>
> >>> On 06/17/2018 01:35 PM, Chris Angelico wrote:
> 
>  On Mon, Jun 18, 2018 at 6:23 AM, Marko Rauhamaa 
>  wrote:
> >
> > Jim Lee :
> >>
> >> IMHO, trying to shoehorn static type checking on top of a dynamically
> >> typed language shows that the wrong language was chosen for the job.
> >
> > I'm also saddened by the type hinting initiative. When you try to be
> > best for everybody, you end up being best for nobody. The niche Python
> > has successfully occupied is huge. Why risk it all by trying to take
> > the
> > whole cake?
> 
>  Did you complain when function annotations were introduced back in 2006?
> 
>  https://www.python.org/dev/peps/pep-3107/
> 
>  That's TWELVE YEARS ago. Over in the Node.js world, that's ... uhh,
>  actually that's longer ago than Node.js has even been around. Another
>  trendy language is Go... oh wait, that wasn't around in 2006 either.
> 
>  Type annotations have been in Python for nearly twelve years; ten if
>  you count the actual release of Python 3.0. The thing that changed
>  more recently was that *non-type* annotations were deprecated, since
>  very few use-cases were found. When did the shoehorning happen,
>  exactly?
> 
>  ChrisA
> >>>
> >>> What does time have to do with anything?  I wasn't using Python in 2006.
> >>> A
> >>> bad idea is a bad idea, regardless of *when* it was conceived.
> >>>
> >> You talk about "risk it all by trying to take the whole cake" as if
> >> annotations are a change. But if they were already around before you
> >> first met the language, then they're just part of the language. You
> >> might as well argue against the += operator or list comprehensions.
> >>
> >> ChrisA
> >
> > You seem to have lost the attribution to those comments in your reply.  I
> > wasn't the one who talked about
> >
> > "risk it all by trying to take the whole cake".
> >
> 
> My apologies, stuff wrapped and I misread as I skimmed back. You were
> the one who used the word "shoehorned". In the same way, that sounds
> like you already knew the language, and then someone added extra
> features that don't fit. It's not shoehorning if the feature was
> already there before you met the language.


Red herring!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: syntax difference

[Rick Johnson]

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

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

Exactly.

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

"Type-hint comments" would allow:

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

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

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

Personally, i would never put type-hints in my Python code.
I write a large portion of my overall code in Python
specifically because i do not wish to be distracted by type
declarations.

Of course, regardless of how much i try to avoid type-hints,
the problem will come, when one day in the future, i am
forced to maintain another Python programmer's code that is
littered with these declarations. And removing them won't be
easy.

But that's the real danger of this feature. The Python
community will not see the real effect of type-hints (at
least, as they are currently implemented) for a long time.
But as more and more type-hints are spread in the wild, more
and more people, and more and more organizations, are going
to look for "cleaner language" to solve their R and
general purpose high-level problems.

What's the point of eye-ball-parsing through miles of type-
hints which demand all the burdens of static typing whilst
giving none of the real benefits. The Python interpreter
ignores these hints. But as programmers -- as, human beings,
and not machines! -- ignoring the syntactical noise of type-
hints will be impossible.

So either the Python devs need to release a
"3ToTypeHintFree.py", or they need to re-implement this so-
called feature as a special class of comment. And here is an
example of how that might be done, using Steven's example
from above:



## Steven's Example ##
#(Current implementation of type-hints)
py> def func(x: float) -> list:
"""Ello, ime-uh lit-al doc-string, yes i am."""
... pass




## Prposed solution v1 ##
py> def func(x):
"""Ello, ime-uh lit-al doc-string, yes i am."""
# x:float -> list
... pass

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

Re: syntax difference

[Rick Johnson]

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

But yet, the _programmer_ cannot ignore it. Does that make
any sense to you, or anyone else with half a brain?

> It makes no change at all to the execution model of the
> language.

Then why the *HELL* are type-hints an official part of the
Python language syntax? Had type hints been implemented as
comments (for instance: a special class of comment in the
same way that doc-strings are a special class of strings),
then a programmer could ignore them! Heck, i have even have
a feature in my editor that will hide all comments and doc-
strings! And the code to perform this task is fairly simple.

But it's gonna one hell of a _nightmare_ to remove type-
hints from source code when they are _interleaved_ with the
damn source code, and considered by the interpreter to be
syntax.

> But the human reader, linters, IDEs and editors can
> associate it with the name it annotates, and use it as a
> hint as to what is intended to happen, and flag any
> discrepancies.

And each of these could have done the same with a "type-hint
comment". But oh no, that would be too easy! And the whole
point here is to cause a big fat ruckus? Isn't it, Mr.
D'Aprano?




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

Re: syntax difference

[Rick Johnson]

Chris Angelico wrote:
[...]
> For the record, there's nothing at all wrong with printf-style
> formatting; its flexibility and brevity make it extremely useful in
> many situations.

Except that it's old, not elegant, error prone, feature poor, and not Pythonic!

But besides all _that_ (and possibly more) it's slightly amusing, i suppose.

Cling to the past much?

What's wrong Chris, is the syntax of the new format method too difficult for 
you? Or do you have a personal disliking for anything OOP?

Personally, i would suggest the OP should learn the new Python formatting 
methods and disregard the legacy printf style crap that has been copy/pasted 
from countless other languages. 

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

Re: Python list vs google group

[Rick Johnson]

On Friday, June 15, 2018 at 9:14:13 PM UTC-5, Richard Damon wrote:
> if the Windows driver broke some specification but still sort
> of worked [...]

...that's when the engineers in the Redmond, WA area know it's time to package 
and ship the product!
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue31725] Turtle/tkinter: NameError crashes ipython with "Tcl_AsyncDelete: async handler deleted by the wrong thread"

[Rick J. Pelleg]

Rick J. Pelleg  added the comment:

Thanks!

On Sat, Jun 16, 2018, 18:53 Carol Willing  wrote:

>
> Carol Willing  added the comment:
>
> Hi Rick,
>
> I'm closing this issue as not reproducible. Thanks for filing it and using
> Turtle.
>
> --
> nosy: +willingc
> resolution:  -> not a bug
> stage:  -> resolved
> status: open -> closed
>
> ___
> Python tracker 
> <https://bugs.python.org/issue31725>
> ___
>

--

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

Re: text mining

[Rick Johnson]

On Friday, June 15, 2018 at 8:00:36 AM UTC-5, Steven D'Aprano wrote:
> Seriously, you are asking strangers to help you out of the goodness of 
> their heart. 

Stop lying Steven. 

Nobody here has a heart.

This is Usenet, dammit.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEP8 compliance

[Rick Johnson]

On Wednesday, June 13, 2018 at 10:47:40 AM UTC-5, Steven D'Aprano wrote:
 
> I'm of two minds here... 

Obviously.

> [...] So use your own judgement: if following PEP 8 becomes
> a chore, or if you would rather follow your own style,
> don't feel guilty about ignoring the style guide.

IOWs: 

  "Be consistent!" 

  "Except, when you don't want to be."

  "Although, it might be a good idea to be."

  "Hmm. Well. Maybe not.

  "Who knows!"

Great advice Steven. 

Great advice.

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

I'm glad to see you've chosen a new foot quote, because as
opposed to the previous one, this is _actually_ funny.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Splitting up large python module impact on performance?

[Rick Johnson]

On Wednesday, June 13, 2018 at 4:27:35 AM UTC-5, Chris Angelico wrote:
> It's more his definition of "large" and "small" that I was
> disagreeing with. You're absolutely right that a dense
> global scope is a problem; but a "one class per file" rule
> is a terrible idea.

What if the "one class" spans thousands of lines? Surely you
don't believe that class definitions (outside of toy classes
and academic examples, that is) are limited to a couple
dozen lines, do you?

> A hundred tiny files is far harder to work with than ten
> medium-sized files,

I doubt anyone here is suggesting that modules should be
limited to 10 lines each, or something ridiculous like that.
Heck, the minimum class definition _alone_ (at least, if
you're going to properly utilize vertical whitespace)
requires around 2 dozen lines.

## BEGIN MODULE ##
01#
02# import something here
03#
04# define constants here
05#
06#
07# (WHITE SPACE BUFFER)
08#
09#
10class MyClass(object):
11def __init__(self):
12pass
13
14def method(self):
15pass
16#
17#
18# (WHITE SPACE BUFFER)
19#
20#
21# (INITIALIZATION/TESTING/LOGIC/ETC)
22#
23#
## END MODULE ##

That's 23 lines of code to define whitespace and boilerplate
_alone_.

> and IMO a single file with all the code in it is only
> slightly worse. That is to say, I would prefer to work with
> a single gigantic file than a directory with lots and lots
> of tiny interdependent files, each one importing six or
> seven others.

Blame the import mess on a missing feature, not on those of
us who prefer reasonably sized source files.

To alleviate a large portion of the circular import mess
(and depending on the coding style employed, possibly all of
it), python's packaging system could have leveraged the
power of "componentized modules" -- much the way that
classes share variables between them using class attributes
(no import required!) -- but unfortunately, this powerful
feature was overlooked. And packages are nothing more than
some kind of quasi directory tree which masquerades itself
as a namespace so that a programmer can replace a long
import path with a _dot_.

WELL, WHOOP-DEE-DO!

That's like a superhero without a superpower.

Hmm...

After considering the blinkered state of Python packages and
the resulting pitfalls of the python import mechanism, we
can only assume the Python gods found inspiration for this
"hot mess" in the title of GnR's fifth studio album.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Splitting up large python module impact on performance?

[Rick Johnson]

On Tuesday, June 12, 2018 at 10:35:47 PM UTC-5, Chris Angelico wrote:
[...]
> A few thousand lines in a file is only a problem if you're
> using an editor that lacks a Find feature. Or if you use
> bad function/class names that you can't search for.

I'm unaware of any text editor that doesn't have a find
feature. But, in a any event, the real problem is not a lack
of features, no, it's a matter of reducing the mental load.
The smaller the file, the less "off screen" data the
programmer must consider at any one time during the editing
process.

Say for instance, you want to add a new symbol, and the
symbol is going in the module namespace. Okay. Seems simple
enough, right? But if your file contains thousands of lines
of code, you can't determine with any degree of certainly
(unless you have a photographic memory!), if the name is
already assigned.

Sure, it only takes a few seconds to (1) bring up the find
feature, (2) type in the symbol, and (3) do the search. But
as programmers we are constantly inventing and assigning
names. And if your modules are so big that you have to bring
up a search tool everytime a new name needs to be assigned,
well, then, i cannot image that workflow being conducive to
any professional environment.

But knowing Chris, we can only assume that he has a custom
MUD solution. Who knows!

> > When in doubt, and when it comes to style issues, there is
> > one universal rule you should always strive to follow, and
> > that rule is to be _consistent_. PEP8 underscores the
> > importance of consistency, and you may want to read it.
> 
> Yep! It does. Let me see...
> 
> [snip link]
> 
> """However, know when to be inconsistent -- sometimes style
> guide recommendations just aren't applicable."""

Hey. Don't blame me. Blame Monty.

> > I may exaggerate on this a bit more if you're interested.
> 
> Isn't it normal for you to exaggerate everything?

Nothing about me is "normal", Chris. 

Haven't you noticed?

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

Re: Splitting up large python module impact on performance?

[Rick Johnson]

Bill Deegan wrote:
> I'm doing some refactoring on a fairly large python
> codebase. Some of the files are > 4000 lines long and
> contain many classes.

I would argue that files of such size are a total pain to
navigate and thus, edit. I prefer to place only one -- or
only a handful of classes -- in each file. One class per
file is _most_ preferred. But if you have a small group of
classes that are closely dependent on one another, and, the
source definitions can fit comfortably in a single file,
well then, i say do it. You just have to decide what is
comfortable for _you_; your coworkers; and anyone who may be
forced to maintain your code in the future.

When in doubt, and when it comes to style issues, there is
one universal rule you should always strive to follow, and
that rule is to be _consistent_. PEP8 underscores the
importance of consistency, and you may want to read it.

> Should I expect any performance hit from splitting some of
> the classes out to other files?

I think you should worry less about the startup performance
hit and more about the possibility of circular imports. I'm
not a big fan of Python's import or packaging systems, as
neither mesh nicely with my style of programming.

But i've found some ways to work around them...

So if you're using the OOP paradigm (like i am), and if you
write your OOP code in a strict formal style (hail java!),
then you can leverage some of the machinery of OOP to get
_around_ the limitations inherent in the aforementioned
components of the Python language. 

I may exaggerate on this a bit more if you're interested.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Stefan's headers [was:Names and identifiers]

[Rick Johnson]

Gregory Ewing wrote:

[...]

> * Charging money for copies of software is not the only way
> to make money from programming. You can charge for support
> services. You can charge for writing custom one-off
> software. There are people who make a good living from
> doing these things.

Microsoft not only demands to be paid for writing the
software *and* maintaining it, but they also demand that you
pay to have it upgraded every couple of years after it
"mysteriously" becomes exponentially more laggy and exploit
prone than usual.

 "Hmm, i wonder how that happened?"

 *SCRATCHES-HEAD*

 *LOOKS-AT-INSTRUMENT-PANEL*

 "Oh noes!" O_O

 "The software fuel tank is almost _empty_!"

How else will they convince you to buy the latest copy of
windoze 95?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Index of entity in List with a Condition

[Rick Johnson]

subhaba...@gmail.com wrote:
> I have the following sentence,
> 
> "Donald Trump is the president of United States of America". 
> 
> I am trying to extract the index 'of', not only for single but also
> for its multi-occurance (if they occur), from the list of words of the
> string, made by simply splitting the sentence.
>  index1=[index for index, value in enumerate(words) if value == "of"],
> where words=sentence.split()
> 
> I could do this part more or less nicely. 
> 
> But I am trying to say if the list of words has the words "United"
> and "States" and it has "of " in the sentence then the previous 
> word before of is, president. 
> 
> I am confused how may I write this, if any one may help it.
> 
> Thanking in advance.

Typically when you ask us to do your homework for you, it is
considered bad taste to present the teacher's assignment
verbatim and then expect that we will provide a turn-key
solution. And although you _did_ provide some sort of
"Pythony looking" code, unfortunately the code is poorly
formatted.

Next time, please try to present your question in a formal,
well-though-out manner. Source code should either be
executable, or conspicuously labeled as psuedo code. Not
because we don't _know_ what pseudo code looks like, but
because we can intuit your level of knowledge from the
presentation. And i gotta tell ya, this presentation is not
exactly screaming valedictorian -- but i digress.

Now, as to your problem...

Well, first, hold on a second, because, i want to correct your
sentence. You presented your target string as:

"Donald Trump is the president of United States of America"

No-no-no. This sentence seems to be missing a few things.
The first is a three letter word. And let's insert that word
now...

>>> s = "Donald Trump is the president of United States of America"
>>> s.index('U')
33
>>> s = s[:33] + 'the ' + s[33:]
>>> s
'Donald Trump is the president of the United States of America'

Ah yes. You see how much more smoothly that rolls off the
ol' tongue? Now, in the interest of public awareness, let's
add an addendum, shall we?

>>> s += ", who was duly elected to office by the great people of this fine 
country in a free and open election. And no amount of whining; pouting; 
sniveling; conspiratorial hoopla; flailing of the arms; the legs; or any 
combination thereof for that matter; will change the reality that Donald *BIG 
JOHN* Trump is now the president of this fine country. Seriously folks. It's 
been an interesting ride. But the circus is over now. Elvis left the building 
over a _year_ ago. Heck, Jimmy Hoffa has already rolled over in his grave 
*THREE* times! But most disturbing of all, is that the dozens of emaciated cats 
trapped in each of your apartments are on the verge of cannibalism (yesh, you 
forgot about them, didn't you?), and the toxic ammonia fumes are melting the 
paint off the walls! It's time to go home and lick your wounds folks. Better 
luck next time. Aloha."

Whew! (*wipes brow*) Now that we've gotten all of that out of
the way... what was your question again? o_O
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Stefan's headers [was:Names and identifiers]

[Rick Johnson]

On Monday, June 11, 2018 at 3:04:14 PM UTC-5, MRAB wrote:
> On 2018-06-11 20:17, Rick Johnson wrote:
[...]
> > A dashboard is a horrible analogy. Software and hardware
> > are connected at the _hip_.  A more correct analogy to
> > describe the relationship between computer hardware and
> > computer software would be a car and an engine. A car is
> > basically useless without an engine, and likewise for an
> > engine without a car.
> >
> I'm going to have to disagree with you there. The engine is
> also hardware.

My analogy was not intented to draw direct parallels between
car components and computer components. It was intented to
underscore the mutual dependancy between them. For example:
computers function by combining hardware and software.
Likewise, automobiles function by combining a power-plant
with a passenger compartment.

> The software is more like the fuel.

How so?

(01) Can energy be extracted from software?

(02) If so, at what rate is software depleted as the hardware
 transforms it into energy?

(03) What is the energy potential of... oh... say... a pint of
 software?

(04) Is software a solvent?

(05) Does software easily vaporize?

(06) What is the flash point of software?

(07) What sort of mining processes are required to extract
 software (or its precursors) from the environment.

(08) How much more software do you estimate we can extract?

(09) Does the concept of "peak software" have any potential
 of becoming a toxic political football?

(10) Who discovered software?

(11) And finally -- and in the interest of safety -- may we
 have a look at the MSDS sheet for software?

> > And yes, there are aftermarket engines sold by third
> > parties and people buy them all the time to replace OEM
> > engines.
> >
> It doesn't matter how good the engine is (or how much
> you've upgraded the processor), because without the fuel
> (or software) it's just a large paperweight (or room
> heater). :-)

Well, that was kinda my point.

No. Wait a sec. Allow me to rephrase.

That was _exactly_ my point.

:-)

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

Re: Stefan's headers [was:Names and identifiers]

[Rick Johnson]

On Monday, June 11, 2018 at 1:02:15 PM UTC-5, Chris Angelico wrote:

> You're trying to argue against my hypothetical statements
> about game publishing, and declaring that it's possible to
> use software to encourage hardware sales. But my point was
> that, absent copyright and the ability to make money from
> software, software probably *would not exist*. Tell me, do
> you go to a car manufacturer and buy the ability to use a
> third-party dashboard? If the dashboard itself is
> fundamentally unsaleable, and MUST be given away for free,
> who other than the original manufacturer will produce one?

A dashboard is a horrible analogy. 

Software and hardware are connected at the _hip_.

A more correct analogy to describe the relationship between
computer hardware and computer software would be a car and
an engine. A car is basically useless without an engine,
and likewise for an engine without a car.

And yes, there are aftermarket engines sold by third parties
and people buy them all the time to replace OEM engines. 

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

Re: user defined modules

[Rick Johnson]

Sharan Basappa wrote:
> Is there a specific location where user defined modules
> need to be kept?

My advice is that any location is a good location so long as
the location you chose is _not_ a part of the PythonXY
directory tree. 

For example, on a windoze machine (and in Python2.x at
least), the PythonXY directory is placed (by default) at the
root of the default drive (usually C drive). Your scripts
(on a windows machine) should be (idealy) somewhere in the
os.path.expanduser('~/Documents') tree. 

Personally i use a .pth file to point Python in the
direction of my library modules. Unlike the old time
masochist, i just hate having to repeat myself. Thus, like
most modern folk, i have learned that copy+paste and "set-
it-and-forget-it" text file are a computer users best
friend and loyal companions.

## MAP ##
C:/
   PythonXY/
   config.pth

The contents of my .pth file is simply an unquoted string
representing the path to my library folders. (something like
this)

## PTH FILE CONTENT ##
C:/.../Documents/path/to/my/lib/folder

That's it!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Stefan's headers [was:Names and identifiers]

[Rick Johnson]

Gene Heskett wrote:
> I rather like that idea. Unforch, who would be in charge of keeping the 
> books uptodate? The USTPO? Of course that would expand another guvmnt 
> agencies payroll x10, and its a waste of taxpayer dollars since Albert 
> retired anyway.

What century are you trapped in pal? Heck, all you need is a Godaddy(c) website
and a simple HTML form (Hell, they even gots templates for that!!!).

> Here in the hew hess aye, we originally had a copyright term of 7 years, 
> renewable just once for another 7. I will date myself by saying I can 
> actually remember those days.  But then Disney started buying senators 
> and congressmen, and we now have this asinine lifetime +70 years just to 
> keep Mickey Mouse and Company's (oh, and don't forget a widow named 
> Cher) income rolling in.

Yeah, and they've sucked up every independent animation house between here and
Kathmandu.

> Thats the sort of stuff usually found, warm and squishy, on the ground 
> behind the male of the bovine specie.

Huh? The female bovines don't defecate where you come from? Well then! i see!
Say hello to Qin-I, would ya?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Stefan's headers [was:Names and identifiers]

[Rick Johnson]

On Friday, June 8, 2018 at 12:34:58 PM UTC-5, Marko Rauhamaa wrote:

> PS IMO copyright laws should be abolished altogether. At
> the very least one should pay for copyright protection. One
> €1 for the first year, €2 for the second, €4 for the third
> and so on exponentially.

I like your idea of a exponential punitive annual increase
to "secure the right" of copyright protection. However, your
pricing scheme seems a bit outdated. Like, a century or
_two_ outdated. ;-)

Heck, in the spirit of the Python tutorial, i say we utilize
the Fibonacci sequence (slightly modified) and finally put
that atrocious code example to some good use.

Yep, and pass it an initial argument reflecting the current
"year of our lord", would ya?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why exception from os.path.exists()?

[Rick Johnson]

Marko Rauhamaa wrote:
> Chris Angelico :
> 
> > Marko Rauhamaa  wrote:
> >>
> >> This surprising exception can even be a security issue:
> >>
> >>>>> os.path.exists("\0")
> >>Traceback (most recent call last):
> >>  File "", line 1, in 
> >>  File "/usr/lib64/python3.6/genericpath.py", line 19, in exists
> >>os.stat(path)
> >>ValueError: embedded null byte
> >
> > [...]
> >
> > A Unix path name cannot contain a null byte, so what you
> > have is a fundamentally invalid name. ValueError is
> > perfectly acceptable.
> 
> At the very least, that should be emphasized in the
> documentation. The pathname may come from an external
> source. It is routine to check for "/", "." and ".." but
> most developers (!?) would not think of checking for "\0".
> That means few test suites would catch this issue and few
> developers would think of catching ValueError here. The end
> result is unpredictable.

I'd have to agree with this assessment. Either a filepath
exists, or it doesn't. Therefore, in the "worldview" of
os.path.exist, there should be no consideration of
conformity, as it is blatantly obvious that any malformed
path would _not_ and could _not_ possibly, exist. In fact,
the only case in which the method in question should raise
an Exception is when a non-stringy argument is passed. Which
-- at least in 2.x version -- i can confirm (with limited
testing) it does this correctly!

## PYTHON 2.X SESSION ##
py> os.path.exists('')
False
py> os.path.exists(None)
Traceback (most recent call last):
  File "", line 1, in 
os.path.exists(None)
  File "C:\Python27\lib\genericpath.py", line 26, in exists
os.stat(path)
TypeError: coercing to Unicode: need string or buffer, NoneType found
>>> os.path.exists(1)
Traceback (most recent call last):
  File "", line 1, in 
os.path.exists(1)
  File "C:\Python27\lib\genericpath.py", line 26, in exists
os.stat(path)
TypeError: coercing to Unicode: need string or buffer, int found

But if the argument is a string, either it exists as a
filepath or it doesn't. Case closed. Anything less would
constitute type discrimination. Which is not only
inconsistent, it's unethical.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: (no subject)

[Rick Johnson]

sagar daya wrote:
> Couldn't install any module from pip
> Plz help???

As with most actions, an algorithm is required. (shocking, i
know!)

What methodology have you implemented thus far to achieve
your goal of "installing modules from PIP"? Please enumerate
the steps you chose to take, and then we _might_ can offer
advice.

For instance, if someone is having trouble brushing their
teeth, the first question we might ask is: "Have you located
the toothbrush and toothpaste yet?". 

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

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

[Rick Teachey]

Rick Teachey <ri...@teachey.org> added the comment:

Lending my voice to the suggestion of limiting the class attribute check to 
`typing.ClassVar` and `ClassVar`. It can always be expanded later if it is 
needed.

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33453>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33453] from __future__ import annotations breaks dataclasses ClassVar and InitVar handling

[Rick Teachey]

Rick Teachey <ri...@teachey.org> added the comment:

> Is there any scenario where the following code would be useful...

Perhaps if someone, in search of a speedup, were sort of rolling their own 
lighter-weight equivalent to the typing module (in order to avoid importing the 
full typing module), but duck typed enough to fool the average type checker? Is 
that possible?

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33453>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33452] add user notification that parent init will not be called in dataclass init method

[Rick Teachey]

Rick Teachey <ri...@teachey.org> added the comment:

The init method that comes up for int, str, float, etc is just the object init:

assert int.__init__ is object.__init__

Probably the thing to do is grab any init methods that aren't the 
object.__init__ while stripping out the dataclass-created init methods? Maybe 
something like:

import warnings

if cls.__dataclass_params__.init:
for pcls in cls.mro():
if pcls.__init__ is not object.__init__:
try:
d_params = getattr(pcls, "__dataclass_params__")
except AttributeError:
warnings.warn('Found a not called init')
else:
if not d_params.init:
warnings.warn('Found a custom dataclass init')

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33452>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33453] from __future__ import annotations breaks dataclasses ClassVar handling

[Rick Teachey]

Rick Teachey <ri...@teachey.org> added the comment:

Sorry, mean to say it works just fine *without* the import.

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33453>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33453] from __future__ import annotations breaks dataclasses ClassVar handling

[Rick Teachey]

Rick Teachey <ri...@teachey.org> added the comment:

To be clear: it works just fine with the annotations import.

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33453>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33453] from __future__ import annotations breaks dataclasses ClassVar handling

[Rick Teachey]

New submission from Rick Teachey <ri...@teachey.org>:

This is broken in 3.7 (both beta 3 and 4):

from __future__ import annotations
from dataclasses import dataclass
from typing import ClassVar, Any

@dataclass
class C():
class_var: ClassVar[Any] = object()
data: str

Traceback:

Traceback (most recent call last):
  File "", line 1, in 
  File 
"C:\Users\ricky\AppData\Local\Programs\Python\Python37\lib\dataclasses.py", 
line 850, in dataclass
return wrap(_cls)
  File 
"C:\Users\ricky\AppData\Local\Programs\Python\Python37\lib\dataclasses.py", 
line 842, in wrap
return _process_class(cls, init, repr, eq, order, unsafe_hash, frozen)
  File 
"C:\Users\ricky\AppData\Local\Programs\Python\Python37\lib\dataclasses.py", 
line 763, in _process_class
else 'self',
  File 
"C:\Users\ricky\AppData\Local\Programs\Python\Python37\lib\dataclasses.py", 
line 442, in _init_fn
raise TypeError(f'non-default argument {f.name!r} '
TypeError: non-default argument 'data' follows default argument

--
components: Library (Lib)
messages: 316333
nosy: Ricyteach, eric.smith
priority: normal
severity: normal
status: open
title: from __future__ import annotations breaks dataclasses ClassVar handling
type: behavior
versions: Python 3.7

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33453>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33452] add user notification that parent init will not be called in dataclass init method

[Rick Teachey]

New submission from Rick Teachey <ri...@teachey.org>:

The dataclasses module is incredibly easy to use. This is a good thing. BUT one 
downside is it will definitely be utilized by people who don't have a thorough 
understanding of how it does what it does.

Even for me, despite having a very good understanding of how it works, after 
heavily using it on a project for about 3 weeks now I made a mistake like the 
one below:

class ImportantMixin:
def __init__(self):
super().__init__()
important_task()

@dataclass
class NaiveDClass(ImportantMixin):
  data1 = int
  data2 = int

I then went on along my merry way. Obviously, ImportantMixin.__init__ never 
gets called and I didn't realize this until it was a bigger problem than it 
should have been (should have written better tests! but I digress).

It would seem like a good idea for the dataclasses module to let the user know 
they did this, probably via the warning system. Seems like it would be 
relatively easy to do: if there is an init method being create, just inspect 
the MRO for any previously defined init methods that weren't created by 
dataclasses.

Thanks.

--
components: Library (Lib)
messages: 316331
nosy: Ricyteach, eric.smith
priority: normal
severity: normal
status: open
title: add user notification that parent init will not be called in dataclass 
init method
type: enhancement
versions: Python 3.8

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33452>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33328] pdb error when stepping through generator

[Rick Teachey]

Rick Teachey <ri...@teachey.org> added the comment:

Closed as duplicate of issue 13044.

--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33328>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33328] pdb error when stepping through generator

[Rick Teachey]

Rick Teachey <ri...@teachey.org> added the comment:

I am on Anaconda 4.5.1 on Windows 10 (Python 3.6.5). I have confirmed that I DO 
get the error on another machine with the same version installed, so the lack 
of an error seems specific to my current machine. I do not know what could be 
causing this; it is very odd.

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33328>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33328] pdb error when stepping through generator

[Rick Teachey]

Change by Rick Teachey <ri...@teachey.org>:


--
components: +Library (Lib)
type:  -> behavior

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33328>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33328] pdb error when stepping through generator

[Rick Teachey]

Rick Teachey <ri...@teachey.org> added the comment:

The interactive session result is below:

GeneratorExit

Exception ignored in: 
Traceback (most recent call last):
  File "C:\Users\ricky\AppData\Local\Programs\Python\Python37\lib\types.py", 
line 27, in _ag
  File "C:\Users\ricky\AppData\Local\Programs\Python\Python37\lib\bdb.py", line 
90, in trace_dispatch
  File "C:\Users\ricky\AppData\Local\Programs\Python\Python37\lib\bdb.py", line 
128, in dispatch_call
  File "C:\Users\ricky\AppData\Local\Programs\Python\Python37\lib\bdb.py", line 
250, in break_anywhere
  File "C:\Users\ricky\AppData\Local\Programs\Python\Python37\lib\bdb.py", line 
49, in canonic
AttributeError: 'NoneType' object has no attribute 'abspath'

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33328>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33328] pdb error when stepping through generator

[Rick Teachey]

New submission from Rick Teachey <ri...@teachey.org>:

Hello: 

The attached python file runs a pdb interactive session for a generator. It 
produces an error in Python 3.7 Beta 3, but no error in 3.6.

I searched for this issue and there do seem to be things that are related to it 
already, but I haven't investigated the cause of this issue and am not 
acquainted with the details of the pdb module, so I was unable to determine 
whether previous reports discuss this same problem.

--
files: demo.py
messages: 315586
nosy: Ricyteach
priority: normal
severity: normal
status: open
title: pdb error when stepping through generator
versions: Python 3.7
Added file: https://bugs.python.org/file47545/demo.py

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33328>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Rick Johnson]

Grant Edwards wrote:
> Etienne Robillard wrote:
> 
> > Do you understand that a modern mobile device typically
> > require a Internet subscription and an additional
> > subscription for the smart phone?
> 
> Huh?  What is "an internet subscription"?  Why would you
> need two of them if all you have is a smartphone?

Most american cell providers these days offer an unlimited
"0talk and text" plan and then add an additional fee for smart
phones (aka: "Data Plan").
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Rick Johnson]

On Friday, March 30, 2018 at 8:59:16 PM UTC-5, Chris Angelico wrote:
[...]
> You can pooh-pooh any statistic. 

Yeah, except the ones supported by actual _facts_.

> So far, though, you have provided NO statistics of your
> own, just your own gut feeling. 

Uh huh. And what do you call drawing naive conclusions from
statistical data? I'd call it confirmation bias!

> Wanna provide some competing information showing that other
> languages are more used?

Chris, here is how debate works:

PersonA asserts X.

PersonB demands evidence for X.

PersonA either provides evidence for X, or X is rejected as
hooey.

Under no circumstance is PersonB required to prove PersonA'a
assertions. The onerous is on PersonA.

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

[issue33190] problem with ABCMeta.__prepare__ when called after types.new_class

[Rick Teachey]

Rick Teachey <ri...@teachey.org> added the comment:

Thank you; I gave it a go. Hopefully didn't cause too much additional work for 
someone.

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33190>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33190] problem with ABCMeta.__prepare__ when called after types.new_class

[Rick Teachey]

Change by Rick Teachey <ri...@teachey.org>:


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

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33190>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Rick Johnson]

On Friday, March 30, 2018 at 7:44:40 PM UTC-5, Steven D'Aprano wrote:
[...]
> Reddit's /ruby subreddit: 40,571 subscribers.
>
> Reddit's /python subreddit: 230,858 subscribers.

Those numbers mean nothing unless you can prove all two-
hundred-thirty-odd thousand of them to be active, non-
tolling, non-socking, non-spaming accounts.

Sure, i can imagine Python-list has an impressively large
number of registered users, however, on a daily basis there
are only 3-5 on-topic threads. And of those, the majority of
the posts are send by a hanful of regulars.

IOWs: these "membership numbers" are not true metrics.

I'd wager to say that only a couple hundred accounts out of
that 230,000 are active and legit python programmers (if
that).

Be realistic dude.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue33188] dataclass MRO entry resolution for type variable metaclasses: TypeError

[Rick Teachey]

Rick Teachey <ri...@teachey.org> added the comment:

I'll also say: one of the biggest reasons I was excited to read the 
`dataclasses` PEP was because I thought "AWESOME! Now I can delete all of the 
stupid boilerplate __init__ and __repr__ methods for those `typing.Sequences`, 
`typing.Mapping`, etc etc subclasses!"

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33188>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33188] dataclass MRO entry resolution for type variable metaclasses: TypeError

[Rick Teachey]

Rick Teachey <ri...@teachey.org> added the comment:

> passing keyword arguments to metaclass will be much more rare for dataclasses 
> than passing a ready namespace

The impetus of my running into these issues was assuming that things like 
`Generic[MyTypeVar]` would "just work" with `make_dataclass`, which seemed like 
a valid assumption since the class creation approach made heavy use of by 
`dataclasses` implies this:

@dataclass
class MyDclass(Generic[MyTypeVar]):
var: MyTypeVar

The fact that I cannot do this, then, without error is surprising:

MyDclass = make_dataclass("MyDclass", (("var", MyTypeVar),), 
bases=(Generic[MyTypeVar],))

I'm not stating it HAS to be fixed. Maybe it doesn't have to. But to me, the 
above seems like the reason to do it if it's going to be done.

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33188>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Python Developer Survey: Python 3 usage overtakes Python 2 usage

[Rick Johnson]

On Friday, March 30, 2018 at 10:45:35 AM UTC-5, Terry Reedy wrote:
> https://www.jetbrains.com/research/python-developers-survey-2017/
> “Which version of Python do you use the most?”
> 2014 80% 2.x, 20% 3.x
> 2016 60% 2.x, 40% 3.x
> 2017 25% 2.x, 75% 3.x
> 
> This is a bigger jump than I anticipated.

If these stats are true, i would caution not to draw any
rash conclusions from them. Even *IF* there are more Python3
programmers today than Python2 (and personally, i'm not
buying it!), what *REALLY* matters is the following:

(1) Has the total number of Python programmers remained
steady? (or has it increased or decreased?)
 
(2) What percentage of the Python3 users are merely students
who use Python (probably against their will) as part of
university studies, and thus, will abandon the language when
(and *IF*) they move into the professional world.

(3) Of the aforementioned students, how many are training to
become actual programmers?

My suspicion is that not only are the overall numbers of
Python programmers on the decline (Thanks, Python3000!),
but the folks who are using Python are mostly students who
will abandon the language when they leave university.

In the end, the property which matters _most_ here is
quaLity not quaNtity. IOWs: a hundred professional grade
softwares in the wild are more important than a billion
hello world programs in the classroom. Which is another
reason why i pay absolutely zero attention to the TIOBI
index (nothin' but hype!).
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue33188] dataclass MRO entry resolution for type variable metaclasses: TypeError

[Rick Teachey]

Rick Teachey <ri...@teachey.org> added the comment:

Eric: see also Ivan's comment on Issue 33190, which will factor into the 
solution to this I think. It seems you can't just pass the `namespace` to the 
`kwds` argument (as I have done in my solution above).

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33188>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33190] problem with ABCMeta.__prepare__ when called after types.new_class

[Rick Teachey]

Rick Teachey <ri...@teachey.org> added the comment:

Excellent; thank you very much for the explanation.

I have never done a PR on a project this size but I'll give it a try.

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33190>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33190] problem with ABCMeta.__prepare__ when called after types.new_class

[Rick Teachey]

New submission from Rick Teachey <ri...@teachey.org>:

I am pretty sure this is a bug. If not I apologize.

Say I want to dynamically create a new `C` class, with base class `MyABC` (and 
dynamically assigned abstract method `m`). This works fine if I use `type`, but 
if I use `new_class`, the keyword argument to the `m` method implementation 
gets lost somewhere in the call to `ABCMeta.__prepare___`.

I've attached a file to demo. Thanks.

--
components: Library (Lib)
files: abcmeta_prepare.py
messages: 314714
nosy: Ricyteach, levkivskyi
priority: normal
severity: normal
status: open
title: problem with ABCMeta.__prepare__ when called after types.new_class
type: behavior
versions: Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47509/abcmeta_prepare.py

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33190>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33188] dataclass MRO entry resolution for type variable metaclasses: TypeError

[Rick Teachey]

Rick Teachey <ri...@teachey.org> added the comment:

Same error on 3.7.

Probably getting beyond my knowledge here but from the error message, it seems 
like the answer is simply that:

type('MyChild', (MyParent[int],), {})

...is just the wrong way to make a new `type` when utilizing type variables.

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33188>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33188] dataclass MRO entry resolution for type variable metaclasses: TypeError

[Rick Teachey]

Rick Teachey <ri...@teachey.org> added the comment:

Sorry: to be clear, the error only occurs when attempting to create the class 
using `make_dataclass`.

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33188>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33188] dataclass MRO entry resolution for type variable metaclasses: TypeError

[Rick Teachey]

New submission from Rick Teachey <ri...@teachey.org>:

I'm getting the following error at when attempting to create a new `dataclass` 
with any base class that is supplied a type variable:

TypeError: type() doesn't support MRO entry resolution; use 
types.new_class()

In principle, it seems like this shouldn't cause any problems, since this works 
as expected:

@dataclass
class MyClass(Generic[MyTypeVar]):
pass

The problem seems to be the call to `type` in `make_dataclass` for 
instantiating the class object, since `type` doesn't support type variables. If 
I replace the `dataclass` line that produces the error with the following code 
block, it seems to work:

try:
cls = type(cls_name, bases, namespace)
except TypeError:
cls = types.new_class(cls_name, bases, namespace)

I haven't tested, but it might be possible to just remove the call to `type` 
altogether.

I've attached a file demonstrating the issue.

--
components: Library (Lib)
files: dataclass_metaclass_issue.py
messages: 314703
nosy: Ricyteach, eric.smith
priority: normal
severity: normal
status: open
title: dataclass MRO entry resolution for type variable metaclasses: TypeError
type: behavior
versions: Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47508/dataclass_metaclass_issue.py

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33188>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Rick Johnson]

On Wednesday, March 28, 2018 at 2:25:42 AM UTC-5, Gregory Ewing wrote:
> Rick Johnson wrote:
> > The only difference is when you want to make a call from a
> > _reference_, which, as you and i well know, is not the
> > most common way func/meths are called (these are rare).
> 
> No, but it's the case we're talking about here. If
> functions don't behave the same way in all circumstances,
> you can't claim them to be first-class.

Just for the record: i never made any such claim. O:-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pep8 for long pattern

[Rick Johnson]

On Tuesday, March 27, 2018 at 9:37:14 PM UTC-5, Dan Stromberg wrote:
> I can easily get 132+ columns of a font large enough for my
> 52 year old eyes on a 15" laptop.

Well, if you're comfortable with the long lines, fine. But
be aware that long lines are poo-pooed in most professional
enviroments.

> 80 is actually a bit defeatist, because it discourages
> developers from using more descriptive identifiers.

I'm a big fan of self-documenting code. But sometimes i have
to remind myself that really long names make the code harder
to read. The wise find a nice balance between readability
and self-documenting. And unless you're a masochist, don't
look to Microsoft for inspiration!

Another reason for 80 char limit is to prevent deeply nested
blocks. At the PEP8 recommended four-space-indention, three
blocks is about all you can get. And that's good enough for
me.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Rick Johnson]

On Tuesday, March 27, 2018 at 6:55:23 PM UTC-5, Steven D'Aprano wrote:
> On Tue, 27 Mar 2018 09:28:34 -0700, Rick Johnson wrote:
[...]
> > Since when did utilizing a method to request a specific
> > value become some sort of magic?
>
> Since it requires a special method that has super powers no
> method you can write yourself can do.

That's hilarious. I guess you never called __init__? LOL!

> Can you write a pure-Ruby method that does the same thing
> as Object.method, using only standard, public parts of the
> Ruby API? No special debugger hooks or "subject to change
> without warning" internal APIs or other private
> implementation details.

I'm not your personal tutor, Steven. And i'm not about to
waste one second of my time writing a solution to a non-
problem. Ruby already provides a well-known mechanism to
retrieve the method object. If you seek assistance, why
don't you go over the Ruby-list and ask them for help. I'm
sure they'd be very eager to help after hearing all the nice
things you've said about Ruby.

> > Even though i prefer Python's way better, the implicit
> > return of Python function references is far more "magical"
> > than making an explicit call to a method will ever be.
>
> Let's say you have an object, lassie = Dog(). How do you
> get access to her tail? Do you use dot syntax:
>
> lassie.tail

I dunno, because you failed to provide a class definition
for `Dog`, so i have nothing to go on save this horrid
explanation of yours. It'd be like me asking you to list the
contents of my refrigerator. Listen, post a code sample and
then i'll comment on it. Until then, don't expect me to read
your mind.

> [snip: more questions about some mysterious Dog class
> (probably stored at Area 51!)]
>
> Ruby attributes are always private.

Indeed. Unlike Python, Ruby is a pure OO language, and thus,
demands that public attributes must be explicitly made
public. Think of Ruby as existing somewhere between Python
and Java. Ruby tries to be as pure about OOP as it can
without becoming as onerous as Java. So yeah, you can safely
assume that Python and Ruby are not the same language
(surprising, i know!)

> You must write accessor getter and setter methods if you
> want to access them from outside the instance or class.

Yes. Unlike Python, Ruby doesn't believe in the philosophy
of "consenting adults" (where privatization of attributes
and methods is done using something as ridiculously brittle
as leading underscores [insert laugh track here]). And Ruby
sure as heck does not promote the utterly annoying Python
misfeature otherwise known as "name mangling".

Which reminds me!!!

So you think Ruby is the _only_ language that has
misfeatures? Well, feast your eyes on this Python
perversion!

>>> class Fu(object):
def bar1(self):
pass
def _bar2(self):
pass
def __bar3(self):
pass
>>> fu = Fu()
>>> [name for name in dir(fu) if 'bar' in name]
['_Fu__bar3', '_bar2', 'bar1']

What happened to the method named "__bar3"?

Where did it go?

"Hey Python, I want my symbol back!"

Tip: Better go check Area 51, cause i assure you, Steven,
you won't find that symbol anywhere in Python. It's gone
dude! Off in another parallel universe. Probably hangin'
with the Squaches and eatin' beef jerky, for all we know.

And to think! During this entire thread you have gone out of
your way to call Ruby inconsistent and accuse her of
returning surprising results... well then... tell us Mr.
D'Aprano, how does the crow taste? Hmm?

> But once you have those accessors, you can use lassie.tail
> to access the member (attribute) tail, and lassie.bark to
> *call* the method. There is no member "bark" because
> methods aren't values.

Care to provide some code that will prove your point? Or are
we condemned to suffer more of these horrid explanations of
yours?

PS: If you need help writing the Dog class, send me a PM.
And if you're nice, maybe i'll help.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pep8 for long pattern

[Rick Johnson]

On Tuesday, March 27, 2018 at 4:02:37 PM UTC-5, Dan Stromberg wrote:
> On Tue, Mar 27, 2018 at 8:18 AM, Michael Torrie  wrote:
> > But when it's exactly what you need, why do you need to
> > shoehorn the expression into 79 characters?  Seems
> > pointless in a case like this. PEP8 is a guideline, not an
> > absolute rule.  It's okay to bend it a bit in cases like
> > this.
> 
> I think PEP8 specifying a max of 80 columns is very silly.
> Even an old VT220 terminal could do 132 columns.

And just think how many columns you could do with 1pt font!
And while i admit i enjoy coding with my nose pressed
against the monitor as much as the next "guyal"[1], just uh,
be sure to keep a good optometrist on retainer, eh pal?

> My understanding is that PEP8 requires 80 columns because a
> tiny, tiny, tiny minority of Python developers wanted to be
> able to put 3 editors next to each other horizontally,
> without wrapping.

Stacking horizontal windows three deep is all the rage, but
the reason has more to do with easy reading. Long lines are
difficult to read. And when your eyes do a linefeed at the
end of a 200 character long line, there's no guarantee
you'll end up starting on the next line. Sometimes you'll
find yourself three lines down, while others, back at the
start of the same line. And that's annoying.

> I like to check my code with pycodestyle, but I always
> override that dang 80 column requirement.

Certainly your decision. But please do try to maintain as
much of PEP8 as you can tolerate. Most of it (~75%) is
really good advice.

[1] "guy" and/or "gal" = "guyal"
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Rick Johnson]

On Tuesday, March 27, 2018 at 4:47:05 PM UTC-5, Gregory Ewing wrote:
> Rick Johnson wrote:
> > rb> Object.method("print_name").call("Meathead")
>
> Yes, but the point is that you have to have to use a different
> syntax to call it. This is like having to say
>
> f.__call__(arg)
>
> in Python instead of just
>
> f(arg)

You _can_ call a Ruby func/method directly by name, and i've
already demonstrated that fact. For example, the following is
perfectly legit (although untested):

def f(arg)
nil
end
f("arg")

And here is the equivalent code in Python (notice the
similarities):

def f(arg):
pass
f("arg")

The only difference is when you want to make a call from a
_reference_, which, as you and i well know, is not the most
common way func/meths are called (these are rare).

Here is Ruby 1.9:

ref = Object.method("f")
ref.call("arg")

And the Python equivalent:

ref = f
ref("arg")

NOTE: Of course, the "Python equivalent" assumes `f` is in
the current module space, whereas in Ruby, Object is
available _everywhere_.

As you can see, there is nothing "magical" about the Ruby
code. Sure, one could claim it is more onerous (and i would
agree). But to claim it is "magic" (as Chris did) is absurd.

PS: I must stress again that i am using Ruby version 1.9 and
have been for many years. I must also stress there have been
many changes in the Ruby language since 1.9 and i have not
kept up with them. So, it may be possible to do `ref("arg")`
in the newer versions. The point is, before anyone accuses
Ruby of not doing X, Y or Z -- they really should go read
the docs.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Rick Johnson]

On Tuesday, March 27, 2018 at 11:35:31 AM UTC-5, Chris Angelico wrote:
> Why are you suggesting that this is magic?

_You_ are the one who leveled the accusation that Ruby's
methodology for fetching a function reference (a la):

Object.method(meth-name-here)

is "magic". I'm merely requesting that you defend _your_
accusation. That's all.

> Yep, one of the most misunderstood lines in the zen.
> "Explicit" means "stuff I like", and "implicit" means
> "stuff I don't like". Or at least, that's how I see this
> used.

Perhaps (and unfortunately) some folks in this community
interpret the zen as you claim, however, the words explicit
and implicit have clear definitions, and thus, to ascribe
them to personal "likes" is a miscarriage of both
comprehension and objectivity.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Rick Johnson]

On Tuesday, March 27, 2018 at 8:46:54 AM UTC-5, Chris Angelico wrote:
[...]
> Cool, so Greg was right: you can't get a reference to a
> method or function. You need magic to simulate it.

Since when did utilizing a method to request a specific
value become some sort of magic?

Do you consider this to be magic?

os.lstdir('C:\\')

What about this?

''.join(map(chr, [109, 101, 97, 116, 32, 104, 101, 97, 100]))

Even though i prefer Python's way better, the implicit
return of Python function references is far more "magical"
than making an explicit call to a method will ever be.

Python Zen Says: "Explicit is better than implicit"

Hmm, i suppose Python's constancy is overrated[1]. 

[1] Which is merely a nice way of saying: "It's a lie!".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: (no subject)

[Rick Johnson]

On Tuesday, March 27, 2018 at 7:19:53 AM UTC-5, kevon harris wrote:
> Unable to pull up IDLE after downloading Python 3.6.4
> 
> Sent from Mail for Windows 10

What OS?

On Windows running Python2.X, IDLE is located @ '/Python2X/Lib/idlelib/idle.pyw'
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Rick Johnson]

On Tuesday, March 27, 2018 at 3:24:48 AM UTC-5, Steven D'Aprano wrote:
> On Mon, 26 Mar 2018 11:37:35 -0700, Rick Johnson wrote:

> Printing a string and calling a function is obfuscated code? Deary me.

When the programmer can't be bothered to invent names more
descriptive than `a` and `b`, why yes, yes it is.

> And besides, while I'm more than happy to take (undeserved)
> credit for all the things Ruby gets right, I draw the line
> at being blamed for Ruby misfeatures like parens-less
> function calls, and the inconsistent behaviour they lead
> to.

What version are you testing this "misfeature" on?
Personally, I'm using 1.9, so i have no idea if the
"misfeature" has been repaired or not. The latest stab;e
release is 2.5.0. There have been a ton of changes since
1.9!

> > > Because of this "fix", the printed strings no longer
> > > match the code being executed, but the strange,
> > > inconsistent behaviour still occurs.
> > 
> > The supposed "inconsistent behavior" here has absolutely
> > nothing to do with Ruby, no, it's all on _you_. _YOU_ are
> > the one who created a non-sensical function
> 
> I love watching you trying to squirm your way out of
> admitting that you screwed up. Returning the input plus two
> is nonsensical is it?

When the function is named `a`, why yes, yes it is!

> As I said, don't blame me for Ruby's poor design.  By the
> way, there are precisely the same number of clues that:  a
> is a function as there are for:  super  in Ruby. But you
> know that, because you were vehemently defending the use of
> super with no parens and why it isn't inconsistent for it
> to do something completely different from super() with
> parens.

Okay, Mr. "Language Designer"... how do _you_ propose to
implement Ruby's super in a way that provides these same
three distinct forms:

(1) implicit passing of args: `super`
(2) explicit passing if args: `super(arg1, arg2, ..., argN)`
(3) no arg passing: `super()`

Let's hear it! And don't forget to make your design
consistent with func/meth calls, even though super is not a
func at all -- but i digress!

> So now you're claiming I hacked the Ruby interpreter to
> support non- standard code? I can smell the desperation in
> you from the other side of the planet.  Rick, nothing I did
> was illegal Ruby code. Everything I did was 100% following
> the rules of the Ruby language.

The rules you violated were _style_ and _sanity_ rules.
Every wise programmer knows that readability dictates one
space on each side of an operator:

YES: a + b
NO: a+b
NO: a+ b
NO: a +b
HELL NO: a+   b

Ruby is punishing you for your petulant behavior. And if i
were you, i'd be kissing Matz's backside for only giving you
a "surprising result". Because if *I* were the creator of
Ruby, i'd have Ruby format your hard-drive for doing _less_.

But i look forward to your proposed solutions to Ruby's so-
called "broken expressions and inconsistent super". Oh guru,
please enlighten us with your language design wisdom.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Rick Johnson]

On Tuesday, March 27, 2018 at 1:55:01 AM UTC-5, Gregory Ewing wrote:
> Chris Angelico wrote:
> > Question: How do you get a reference to a Ruby function? Or are they
> > not first-class objects?
>
> They're not first-class. So, you can't.

If Chris means: "how do you get a reference to a Ruby
function object", then yes, it _is_ possible! Consider the
following:

## Ruby 1.9 ##
rb> def print_name(name); puts "Your name is #{name.inspect}"; end
rb> print_name("Chris")
"Chris"

In this case, since the function `print-name` was defined
outside of an class definition, Ruby will add the function
as a method of `Object` (Ruby is more purist about OOP than
Python). So, to get a reference to the function object
(which is now a method of `Object`!), all we need to do is
call a method named "method" ("gigity") and pass it the name
of the method as a string:

rb> Object.method("print_name")
#
rb> Object.method("print_name").call("Meathead")
Your name is "Meathead"

PS: Greg, please inform Chris that Google is his friend. ;-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Rick Johnson]

On Monday, March 26, 2018 at 6:11:31 PM UTC-5, Python wrote:
> On Mon, Mar 26, 2018 at 02:19:12PM -0700, Rick Johnson wrote:
[...]
> > Hmm. If "syntax parser rules" could prevent poorly
> > formatted code, then there'd be no need for style guides.
>
> It may be telling that my team has minimal style standards
> for C/C++, and none at all for Python... [We don't feel it
> requires any.]

Hmm, which would indicate to me you're part of a small,
tight-nit group of like-minded folks. However, what works
well for small groups begins to fall apart in larger
social environment.

> > > > No self-respecting professional programmer would ever
> > > > write in such a manner.
>
> I should also have said that I think this assumes a certain
> level of expertise with the language.  We all start out as
> novices with every new language, and may spend a very long
> time there, depending on how much we use it...

Hmm, very true. If only Steven had been more experienced with
Ruby, then he would have known to avoid that pitfall. O:-)

> > Perl is a special case (and thus not a good retort)
> > because the language itself was purposely intended to be
> > cryptic.
>
> I think Larry would disagree with that assessment...

And that's an opinion he gets to have ;-)

[...]

> > IOWs: It's not a bug, dude, it's a feature.
>
> I dunno, this smells a lot like BS.
>
> Ruby touts itself as being a simple language with elegant
> syntax. This thread is my only exposure to it to date, but
> what I've seen here is, frankly, the exact opposite of
> that.

And do you normally judge the worthiness of an entire
language based on one poorly styled non-idiomatic example
created by somone who is (admittingly) not intimately
familiar with the language?

> You should not need a map to distinguish function
> calls from variables,

I agree that the Python mandated empty parens is a nicely
intuitive indication of a func-call, and that's why i use
the empty parens in all my Ruby code (even though Ruby does
not force me to). Hmm, I'm not sure why Matz chose to make
the syntax optional. But whatever his reason may have benn,
i just hold down shift, and strike two keys, and -- whamo --
my coding style is consistent.

> or operands from function arguments,

Agreed. The syntax "foo(x, y, z)" nicely encapsulates
the arguments whereas "foo x, y, z" does not.

> let alone have the latter depend on the position of the
> operator token relative to any whitespace between it and
> the two tokens on either side of it.  That's hard to read,
> complicated, inelegant, and just poor syntax. [My opinion,
> obviously.] That's not enough exposure to decide that the
> language isn't simple and elegant overall, but it certainly
> does induce a strong negative prejudice.

You shouldn't dismiss Ruby over this one little issue. Need
i remind you that Python has its fair share of warts? In
fact, here is one involving Python's implicit self which
occasionally bites even the seasoned pythonista:

>>> class Foo(object):
... def bar(self, arg1, arg2, arg3):
... pass
>>> foo = Foo()
>>> foo.bar(1,2)
Traceback (most recent call last):
  File "<pyshell#7>", line 1, in 
foo.bar(1,2)
TypeError: bar() takes exactly 4 arguments (3 given)

(A reinactment of programmer mental state follows)

"Huh?" o_O

"I gave _three_ arguments, you say?" o.O

"Wuh-wuh-what?" O_O

"_THREE_?" #_O

"What the hell are your talking about Python?" ಠ_ಠ

"Are you blind?" (╯°□°）╯︵ ┻━┻

"Cause I'm _looking_ at the freaking code..."  ＼(°ロ＼)

"And i'm _looking_ at the freaking exception..." (／ロ°)／

"but what you're telling me just don't add up!" \(`Д´)

"YOU LIAR!!!"  ┻━┻︵ヽ(`Д´)ﾉ︵ ┻━┻

"Okay. Alright. Listen. I _swears_..."  щ(ﾟДﾟщ)

"I only gave you *TWO* arguments -- just two!" (屮ﾟДﾟ)屮

"WOE IS ME!" （´Д｀）

"I'm so terribly vexed!" (>_<)

"What have i done to deserve this?" （ ´,_ゝ`)

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Rick Johnson]

On Monday, March 26, 2018 at 3:09:38 PM UTC-5, Python wrote:
> On Mon, Mar 26, 2018 at 11:37:35AM -0700, Rick Johnson wrote:
[...]
> > Ruby followed the rules.
> > But you didn't.
>
> Nonsense... Your language's syntax parser is what defines
> the rules. All of the expressions Stephen wrote did not
> yeild a syntax error, therefore he "followed the rules."

Hmm. If "syntax parser rules" could prevent poorly formatted
code, then there'd be no need for style guides.

> > No self-respecting professional programmer would ever
> > write in such a manner.
>
> I think your expectation here is much too high.  I've seen
> A LOT of Perl written by, for example, professional
> testers, of this ilk, and I've seen it cause bugs when a)
> they got the syntax very slightly wrong, or b) they got the
> syntax right but someone else to whom the intention wasn't
> clear "fixed" it.

Perl is a special case (and thus not a good retort) because
the language itself was purposely intended to be cryptic.
Thus, what Perl programmers consider to be "normal and
perfectly acceptable code" would cause the rest of us to run
away in horror.

"Debug that mess?" o_O

"NO WAY!"

> Humans are already good enough at making mistakes that they
> require no additional encouragement, such as what is
> provided by allowing such syntactical horrors.

Agreed. And that's why we must respect and follow the code
styling wisdom which has been passed down by those who
struggled before us. Sure, the behavior that Steven
uncovered is odd, but it could be that Maz harbors a strong
disliking for undisciplined pupils, and thus, he designed
and placed this little trap in the hopes the pain it induced
might encourage the petulant little meat-heads to follow
some sensible styling rules.

IOWs: It's not a bug, dude, it's a feature.

PS: ("meat-head": it's what's for dinner)

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

Re: Ruby parens-free function calls [was Re: Accessing parent objects]

[Rick Johnson]

On Monday, March 26, 2018 at 5:46:03 AM UTC-5, Steven D'Aprano wrote:
> Rick, you're supposedly familiar with Ruby. And yet, you
> didn't notice that your supposed "fix" didn't touch any
> executable code, all it did was modify the strings being
> printed.

Because the goal was to *UN-OBFUSCATE* the code, not to
provide a solution for the problem _you_ created.

> Because of this "fix", the printed strings no longer match
> the code being executed, but the strange, inconsistent
> behaviour still occurs.

The supposed "inconsistent behavior" here has absolutely
nothing to do with Ruby, no, it's all on _you_. _YOU_ are
the one who created a non-sensical function with a single
char name; and _YOU_ are the one who placed a call to that
function in the middle of an expression, which, on first
glance, looks to be a common numeric addition or string
concatenation. There are no syntactical clues that `a` is a
function. Thus, it is _YOU_ who is to blame for the supposed
"unexpected output".

Ruby followed the rules.

But you didn't.

Like a mad scientist you injected obfuscation into your
source code and then blamed Ruby because your poor naming
conventions and your clumsily formed expressions did not
produce the "purdy little result" you expected.
Congratulations, you have forsaken the most vital principle
of good programming -> Readability Counts!.

"Code is read more often than it is written" (ring a bell?).

No self-respecting professional programmer would ever write
in such a manner. Its the kind of crapola that will get you
fired in 2 seconds. Yet, here you are -- THE GREAT AND
POWERFUL D'APRANO -- thumping your chest over this
horrendous code and acting as if we should be proud of you.

Yip of the day: No one is proud of you.

> Here's the code again:

No thanks. I've seen more than i care to see of your little
"examples".

> Of course we can solve the problem by always using
> parentheses when making function calls.

I'm sorry, but _we_ are not required to solve the problems
_you_ create. _You_ made that mess, and now _you_ can clean it
up.

> But that misses the point that Ruby allows this
> inconsistency in the first place.

Hmm, i see. And if the operator of an automobile purposesly
drives off a cliff, who do you blame: driver or
manufacturer?
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue33141] descriptor __set_name__ feature broken for dataclass descriptor fields

[Rick Teachey]

Rick Teachey <ri...@teachey.org> added the comment:

Looks great to me. Thanks!

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33141>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33141] descriptor __set_name__ feature broken for dataclass descriptor fields

[Rick Teachey]

Rick Teachey <ri...@teachey.org> added the comment:

Yeah and I think lines 2709-2712 of TestDescriptors also needs removed.

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33141>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33141] descriptor __set_name__ feature broken for dataclass descriptor fields

[Rick Teachey]

Rick Teachey <ri...@teachey.org> added the comment:

Eric, looking at the PR; note that if you do this for the __set_name__ check:

if inspect.ismethoddescriptor(self.default):

...an object like the one below will not get its __set_name__ called, even 
though PEP 487 says it should:

class D:
def __set_name__(self, o, n):
self.name = n

class C:
d: int = D()

if __name__ == "__main__":
print(f"C.d.name = {C.d.name}") # __set_name__ was called
assert inspect.ismethoddescriptor(C.d) # Error

--

___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33141>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com