[issue40278] pathlib Path.replace raises OSError when target exists

2020-04-13 Thread Michael Selik


Michael Selik  added the comment:

The docs for ``os.replace`` says "If dst is a directory, OSError will be 
raised."  That's helpful, but the docs for ``pathlib.Path.replace`` make it 
seem like the target will be unconditionally replaced regardless of whether 
it's a file or directory.  Sure, there's the association of the two functions 
in the correspondence table in the pathlib docs, but that's easy to overlook 
when looking up ``pathlib.Path.replace``.

If nothing else, I guess this is a request to alter the docstring.

--

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



[issue40278] pathlib Path.replace raises OSError when target exists

2020-04-13 Thread Michael Selik


New submission from Michael Selik :

The pathlib module ``Path.replace(target)`` states that "If target points to an 
existing file or directory, it will be unconditionally replaced."  However, 
this does not appear to be true.  I experience an OSError ``[Errno 66] 
Directory not empty`` when attempting to ``replace`` to an existant target.

https://docs.python.org/3/library/pathlib.html#pathlib.Path.replace


I see that others on StackOverflow encounter the same issue.  The top answer 
ignores the Python documentation and recommends removing the target directory 
before replacing.

https://stackoverflow.com/questions/50355180/use-pathlib-to-destructively-rename-one-directory-to-another-existing-directory

--
messages: 366363
nosy: selik
priority: normal
severity: normal
status: open
title: pathlib Path.replace raises OSError when target exists
type: behavior
versions: Python 3.8

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



[issue34498] Python 3.7 breaks on singledispatch_function.register(pseudo_type), which Python 3.6 accepted

2019-03-28 Thread Michael Selik


Michael Selik  added the comment:

+1 for this use case. Until it's resolved, perhaps there should be a note in 
the singledispatch docs that types from the ``typing`` module should not be 
used?

--
nosy: +selik

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



[issue36018] Add a Normal Distribution class to the statistics module

2019-02-19 Thread Michael Selik


Michael Selik  added the comment:

+1, This would be useful for quick analyses, avoiding the overhead of 
installing scipy and looking through its documentation.

Given that it's in the statistics namespace, I think the name can be simply 
``Normal`` rather than ``NormalDist``.  Also, instead of ``.from_examples`` 
consider naming the classmethod ``.fit``.

--
nosy: +selik

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



[issue34003] csv.DictReader can return basic dict instead of OrderedDict

2018-06-29 Thread Michael Selik


Michael Selik  added the comment:

I searched for previously submitted issues, but somehow didn't spot #32339.

I'll do some searching for whether anyone uses ``move_to_end`` on DictReader 
rows and respond to the mailing list with a report.

--

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



[issue34003] csv.DictReader can return basic dict instead of OrderedDict

2018-06-29 Thread Michael Selik


Change by Michael Selik :


--
components: +Library (Lib)

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



[issue34003] csv.DictReader can return basic dict instead of OrderedDict

2018-06-29 Thread Michael Selik


Change by Michael Selik :


--
type:  -> performance

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



[issue34003] csv.DictReader can return basic dict instead of OrderedDict

2018-06-29 Thread Michael Selik


Michael Selik  added the comment:

Pull request.

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

--

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



[issue34003] csv.DictReader can return basic dict instead of OrderedDict

2018-06-29 Thread Michael Selik


Change by Michael Selik :


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

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



[issue34003] csv.DictReader can return basic dict instead of OrderedDict

2018-06-29 Thread Michael Selik


New submission from Michael Selik :

Since dicts are now keeping insertion order as of 3.7, we can switch to the 
more efficient construction of dict rather than OrderedDict for each row in the 
CSV file.

--
messages: 320734
nosy: selik
priority: normal
severity: normal
status: open
title: csv.DictReader can return basic dict instead of OrderedDict
versions: Python 3.8

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



[issue34002] minor efficiency and clarity improvements in email package

2018-06-29 Thread Michael Selik


Change by Michael Selik :


--
components: +email
nosy: +barry, r.david.murray
versions: +Python 3.8

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



[issue34002] minor efficiency and clarity improvements in email package

2018-06-29 Thread Michael Selik


Change by Michael Selik :


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

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



[issue34002] minor efficiency and clarity improvements in email package

2018-06-29 Thread Michael Selik


New submission from Michael Selik :

The primary motivation for these improvements was avoiding a while/pop pattern 
for looping. A for-loop is a big improvement over copying a list, then 
repeatedly popping the 0th element.

A lesser improvement is the use of ``a.intersection(b)`` instead of ``c = 
set(b); len(c) > len(c - a)``. The check for intersection is more clear, and it 
avoids an unnecessary set construction.

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

--
messages: 320730
nosy: selik
priority: normal
severity: normal
status: open
title: minor efficiency and clarity improvements in email package

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



[issue33462] reversible dict

2018-06-08 Thread Michael Selik


Michael Selik  added the comment:

It looks like there's general agreement on python-dev that this is appropriate 
for v3.8 (not v3.7).

Guido van Rossum and Ramsey D'silva gave a +1. Raymond Hettinger noted some use 
cases. INADA Naoki raised a point about waiting for other implementations, 
which Guido agreed with, but after some research came around to OK'ing this for 
v3.8.

Responding to Serhiy Storchaka's worry about adding new code possibly upsetting 
the compiler optimizations: The implementation seems straightforward and 
unlikely to confuse the compiler. Is there evidence that similar code has 
previously made CPython slower? If the compiler's black magic is too difficult 
to understand, it may be equally plausible that this code causes an improvement 
to the optimization of unrelated code.

--

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



[issue33463] Can namedtuple._asdict return a regular dict instead of OrderedDict?

2018-05-23 Thread Michael Selik

Michael Selik <m...@selik.org> added the comment:

I changed the PR to simply replace OrderedDict with dict. For the docs 
warnings, if I'm understanding correctly, those should be separate pulls for 
older branches?

--

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



[issue33462] reversible dict

2018-05-12 Thread Michael Selik

Michael Selik <m...@selik.org> added the comment:

Right, a blend of the code from dictiterobject 
(https://github.com/python/cpython/blob/master/Objects/dictobject.c#L3309) and 
listreviterobject 
(https://github.com/python/cpython/blob/master/Objects/listobject.c#L3128).

--

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



[issue33463] Can namedtuple._asdict return a regular dict instead of OrderedDict?

2018-05-12 Thread Michael Selik

Change by Michael Selik <m...@selik.org>:


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

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



[issue33463] Can namedtuple._asdict return a regular dict instead of OrderedDict?

2018-05-12 Thread Michael Selik

Michael Selik <m...@selik.org> added the comment:

Is this warning what you had in mind?
https://github.com/python/cpython/pull/6772

--

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



[issue33463] Can namedtuple._asdict return a regular dict instead of OrderedDict?

2018-05-10 Thread Michael Selik

New submission from Michael Selik <m...@selik.org>:

Since the basic dict is now keeping insertion order, can we switch 
namedtuple._asdict to return a basic dict? Other than OrderedDict.move_to_end 
and the repr, I believe there is no compatibility issue.

--
messages: 316387
nosy: selik
priority: normal
severity: normal
status: open
title: Can namedtuple._asdict return a regular dict instead of OrderedDict?
type: enhancement
versions: Python 3.7, Python 3.8

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



[issue33462] reversible dict

2018-05-10 Thread Michael Selik

New submission from Michael Selik <m...@selik.org>:

Now that dicts are tracking insertion order, they can be made reversible via 
the built-in reversed, just like OrderedDict.

--
messages: 316386
nosy: selik
priority: normal
severity: normal
status: open
title: reversible dict
type: enhancement

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



[issue33203] random.choice: raise IndexError on empty sequence even when not using getrandbits internally

2018-04-02 Thread Michael Selik

Michael Selik <m...@selik.org> added the comment:

If you're going to tackle this problem, this should probably be solved for the 
general case of n <= 0 rather than just n == 0.

In [1]: import random

In [2]: class Random(random.Random):
   ...: def random(self):
   ...: return  super().random()
   ...:

In [3]: r = Random()

In [4]: r._randbelow(-1) # Should raise a ValueError
Out[4]: 0

But honestly, if someone is going to override ``random`` I think we can expect 
them to realize they're stepping into the deep end.

--
nosy: +selik

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



[issue31908] trace module cli does not write cover files

2017-11-13 Thread Michael Selik

Michael Selik <m...@selik.org> added the comment:

You're referring to something like this:

+def test_count_and_summary(self):
+name = TESTFN + '.py'
+with open(name, 'w') as fd:
+self.addCleanup(unlink, name)
+fd.write("""\
+x = 1
+y = 2
+
+def f():
+return x + y
+
+for i in range(10):
+f()
+""")
+status, stdout, stderr = assert_python_ok('-m', 'trace', '-cs', name)
+self.assertEqual(status, 0)
+self.assertIn(b'lines   cov%   module   (path)', stdout)
+self.assertIn(('6   100%%   %s   (%s)' % (TESTFN, name)).encode(), 
stdout)
+

?

--

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



[issue31908] trace module cli does not write cover files

2017-11-13 Thread Michael Selik

Change by Michael Selik <m...@selik.org>:


--
nosy: +selik

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



[issue31915] (list).insert() not working

2017-10-31 Thread Michael Selik

New submission from Michael Selik <michael.se...@gmail.com>:

What behavior did you expect from your code?
What behavior did you get instead?

It looks like you're not calling the list copy method correctly. Try writing 
"tables2.copy()" instead of "tables2.copy". It also looks like you have other 
bugs in your code.

This forum is for reporting bugs in the Python language. If you'd like help 
with bugs in your own code, try asking on StackOverflow 
(https://stackoverflow.com/) or on the Python Help mailing list 
(https://mail.python.org/mailman/listinfo/python-help).

--
nosy: +Michael Selik

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



[issue31908] trace module cli does not write cover files

2017-10-31 Thread Michael Selik

Michael Selik <michael.se...@gmail.com> added the comment:

Ok, pull request submitted:
https://github.com/python/cpython/pull/4205

--

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



[issue31908] trace module cli does not write cover files

2017-10-31 Thread Michael Selik

Change by Michael Selik <m...@selik.org>:


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

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



[issue31908] trace module cli does not write cover files

2017-10-31 Thread Michael Selik

Michael Selik <michael.se...@gmail.com> added the comment:

While writing a patch for this, I noticed the ``lnotab`` parameter seems nearly 
unused. It's a dict, but is only used for its keys.

https://github.com/python/cpython/blob/master/Lib/trace.py#L333

Further, the choice to count unreached lines only when ``show_missing`` was set 
seems inconsistent.

https://github.com/python/cpython/blob/master/Lib/trace.py#L335

https://github.com/python/cpython/blob/master/Lib/trace.py#L280

--

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



[issue31908] trace module cli does not write cover files

2017-10-31 Thread Michael Selik

Michael Selik <michael.se...@gmail.com> added the comment:

The problem appears to be a mistake in commit 
f026dae130bf6f9015c4b212f16852ba4a3f3dec

https://github.com/python/cpython/commit/f026dae130bf6f9015c4b212f16852ba4a3f3dec

This made the writing of cover files conditional on ``show_missing`` which is 
the option to mark lines which weren't executed with several angle brackets 
">>>>>".

https://github.com/python/cpython/blob/3.5/Lib/trace.py#L326

mike on mac in ~/
$ python -m trace --count foo.py
hello

mike on mac in ~/
$ ls *.cover
ls: *.cover: No such file or directory

mike on mac in ~/
$ python -m trace --count -m foo.py
hello

mike on mac in ~/
$ ls *.cover
-rw-r--r--  1 mike  staff22B Oct 31 15:40 foo.cover

--

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



[issue31908] trace module cli does not write cover files

2017-10-30 Thread Michael Selik

New submission from Michael Selik <michael.se...@gmail.com>:

The trace module command-line utility doesn't write cover files. I've noticed 
this issue for some years now. It works fine in Python 2. When using Python 3, 
no ".cover" files are written, regardless of how "--coverdir" is specified.

mike on macbook in ~/
$ echo 'print("hello")' > foo.py

mike on macbook in ~/
$ python -m trace --count foo.py
hello

mike on macbook in ~/
$ ls *.cover
ls: *.cover: No such file or directory


My apologies if this is a duplicate bug. I searched the tracker and Google for 
a while, but couldn't find a relevant issue.

------
messages: 305268
nosy: Michael Selik
priority: normal
severity: normal
status: open
title: trace module cli does not write cover files
type: behavior
versions: Python 3.6

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



[issue29965] MatchObject __getitem__() should support slicing and len

2017-04-03 Thread Michael Selik

Michael Selik added the comment:

Sorry, it looks like I got the issue number wrong. My comparison should not 
have been with #24454, but instead with an issue I can't locate at the moment. 
Reproducing the example:

for g0, g1, g2 in re.finditer(r'(\d+)/(\d+)', 'Is 1/3 the same as 2/6?'):
ratio = Fraction(int(g1), int(g2))

Better:

for mo in re.finditer(r'(\d+)/(\d+)', 'Is 1/3 the same as 2/6?'):
ratio = Fraction(*map(int, mo[1:3]))

The map in the last one isn't very pretty, but I hope it illustrates the gist 
of what I'd like to do for a much larger pattern with many capture groups.

--

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



[issue29965] MatchObject __getitem__() should support slicing and len

2017-04-03 Thread Michael Selik

Michael Selik added the comment:

Yesterday I wanted to do a destructuring bind on a slice of groups in a 
finditer. Similar situation to the use case of Issue #24454. It might not be 
"normal code" but I end up in that situation every month or so when parsing 
semi-structured documents. I found myself wishing for a mapping-destructuring 
bind, but that's another story.

I haven't read the full discussion of ``len`` on MatchObject yet, but I 
tentatively agree with Brandon Rhodes' comment in Issue #19536:

"My retort is that concentric groups can happen anyway:
that Group Zero, holding the entire match, is not really
as special as the newcomer might suspect, because you can
always wind up with groups inside of other groups; it is
simply part of the semantics of regular expressions that
groups might overlap or might contain one another ..."

@Serhiy, I was unaware of the feature of passing several arguments to groups. 
Unfortunately, the regex pattern I was using had a very large set of groups. A 
slice would have been particularly elegant. Passing several arguments to 
mo.groups() will be helpful, but still more awkward than a slice.

Perhaps it is a can of worms, but I was pleased to see indexing available and 
was disappointed not to find the typically supported corresponding features.

--

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



[issue29965] MatchObject __getitem__() should support slicing and len

2017-04-02 Thread Michael Selik

Michael Selik added the comment:

This would also enable negative indexing, which currently raises "IndexError: 
no such group".

Edit: I meant whole numbers, not natural numbers.

--
versions: +Python 3.7

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



[issue29965] MatchObject __getitem__() should support slicing and len

2017-04-02 Thread Michael Selik

Changes by Michael Selik <m...@selik.org>:


--
components: +Regular Expressions
nosy: +ezio.melotti, mrabarnett
type:  -> enhancement

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



[issue29965] MatchObject __getitem__() should support slicing and len

2017-04-02 Thread Michael Selik

New submission from Michael Selik:

Currently, slicing a MatchObject causes an IndexError and len() a TypeError. 
It's natural to expect slicing and len to work on objects of a finite length 
that index by natural numbers.

--
messages: 291050
nosy: selik
priority: normal
severity: normal
status: open
title: MatchObject __getitem__() should support slicing and len

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



[issue29957] unnecessary LBYL for key contained in defaultdict, lib2to3/btm_matcher

2017-04-01 Thread Michael Selik

Michael Selik added the comment:

Ok, I'll change the PR.

--

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



[issue29957] unnecessary LBYL for key contained in defaultdict, lib2to3/btm_matcher

2017-03-31 Thread Michael Selik

Michael Selik added the comment:

PR submitted. I also signed the contributor agreement, but the bot doesn't seem 
to have noticed.

--

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



[issue29957] unnecessary LBYL for key contained in defaultdict, lib2to3/btm_matcher

2017-03-31 Thread Michael Selik

Michael Selik added the comment:

I'll submit a pull request momentarily.

--

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



[issue29957] unnecessary LBYL for key contained in defaultdict, lib2to3/btm_matcher

2017-03-31 Thread Michael Selik

New submission from Michael Selik:

Minor, but it looks like someone decided to use a defaultdict but forgot to 
remove the checks for whether a key exists.

Creating a defaultdict(list):
https://github.com/python/cpython/blob/6f0eb93183519024cb360162bdd81b9faec97ba6/Lib/lib2to3/btm_matcher.py#L100

Checking for the key, then initializing an empty list:
https://github.com/python/cpython/blob/6f0eb93183519024cb360162bdd81b9faec97ba6/Lib/lib2to3/btm_matcher.py#L120

Again:
https://github.com/python/cpython/blob/6f0eb93183519024cb360162bdd81b9faec97ba6/Lib/lib2to3/btm_matcher.py#L137

Because the ``results`` is getting returned, perhaps it'd be better to use a 
regular dict and dict.setdefault instead of a defaultdict.

--
components: 2to3 (2.x to 3.x conversion tool)
messages: 290955
nosy: selik
priority: normal
severity: normal
status: open
title: unnecessary LBYL for key contained in defaultdict, lib2to3/btm_matcher

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



Re: Two-Dimensional Expression Layout

2016-08-21 Thread Michael Selik
On Sun, Aug 21, 2016, 3:06 AM Lawrence D’Oliveiro <lawrenced...@gmail.com>
wrote:

> On Sunday, August 21, 2016 at 6:49:19 PM UTC+12, Michael Selik wrote:
>
> > Indeed it is, not sure why.
>
> Moral: It helps to understand the code you’re criticizing, before you
> start criticizing, not after.
>

A true statement, but not my takeaway from this discussion.

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


Re: Two-Dimensional Expression Layout

2016-08-21 Thread Michael Selik
On Sun, Aug 21, 2016 at 12:31 AM Lawrence D’Oliveiro <lawrenced...@gmail.com>
wrote:

> On Sunday, August 21, 2016 at 12:44:21 PM UTC+12, Michael Selik wrote:
> >
> > On Sat, Aug 20, 2016 at 6:21 PM Lawrence D’Oliveiro wrote:
> >
> >>> if any(not isinstance(obj, Image) for obj in [src, mask, dest]):
> >>> ...
> >>
> >> Spot the bug in your version...
> >
> > - ``mask != None`` is unnecessary, unless somehow None has been
> registered
> > as an instance of Image.
>
> That’s the bug: it’s not unnecessary.
>
> Maybe a quick application of one of De Morgan’s theorems might help:
>
> if (
> isinstance(src, Image)
> and
> (mask == None or isinstance(mask, Image))
> and
> isinstance(dest, Image)
> ) :
> don’t raise TypeError("image args must be Image objects")
> #end if
>
> Is that better for you?
>

Indeed it is, not sure why. I think Steven's right in this case. Since the
condition isn't identical for all objects, and it's only three variables,
I'd rather break it apart.

if not isinstance(src, Image):
raise TypeError('src must be an Image')
if mask and not isinstance(mask, Image):
raise TypeError('mask must be an Image or None')
if not isinstance(dest, Image):
raise TypeError('dest must be an Image')

As he said as well, this has the added benefit of encouraging more explicit
error messages.

In programming and in prose, sometimes repetition feels ugly and redundant,
but sometimes repetition feels like a beautiful harmony.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Two-Dimensional Expression Layout

2016-08-20 Thread Michael Selik
On Sat, Aug 20, 2016 at 8:43 PM Michael Selik <michael.se...@gmail.com>
wrote:

> On Sat, Aug 20, 2016 at 6:21 PM Lawrence D’Oliveiro <
> lawrenced...@gmail.com> wrote:
>
>> > p0 = (0, 0)
>> > p1 = (major_dim, 0)
>> > colour_stops = (0, rect_1_colour), (1, complement(rect_1_colour))
>> > rect_1_pattern = qah.Pattern.create_linear(p0, p1, colour_stops)
>>
>> That’s an example of what I mean about obscure structure.
>>
>
> To each his own. I was assuming all those variable names meant something
> to you. If not, then I expect it'd read well with good names. In this
> example, I think the abbreviations and numbers in the names could be
> changed to something more meaningful.
>

I think that came out wrong. Let me try again...

origin = 0, 0
destination = width, 0
start_color = 0, selected_color
stop_color = 1, complement(selected_color)
pattern = qah.Pattern.from_line(origin, destination, (start_color,
stop_color))

Better?
I wasn't sure what the numbers 0 and 1 are doing for the colour_stops.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Two-Dimensional Expression Layout

2016-08-20 Thread Michael Selik
On Sat, Aug 20, 2016 at 6:21 PM Lawrence D’Oliveiro 
wrote:

> > p0 = (0, 0)
> > p1 = (major_dim, 0)
> > colour_stops = (0, rect_1_colour), (1, complement(rect_1_colour))
> > rect_1_pattern = qah.Pattern.create_linear(p0, p1, colour_stops)
>
> That’s an example of what I mean about obscure structure.
>

To each his own. I was assuming all those variable names meant something to
you. If not, then I expect it'd read well with good names. In this example,
I think the abbreviations and numbers in the names could be changed to
something more meaningful.


> >> From , a
> >> complex condition (with redundant parentheses again):
> >>
> >> if (
> >> not isinstance(src, Image)
> >> or
> >> mask != None and not isinstance(mask, Image)
> >> or
> >> not isinstance(dest, Image)
> >> ) :
> >> raise TypeError("image args must be Image objects")
> >> #end if
> >>
> >
> > No need for the separate calls to isinstance, nor the check for None.
> >
> > if any(not isinstance(obj, Image) for obj in [src, mask, dest]):
> > ...
>
> Spot the bug in your version...
>

It'd be easier if I ran the code :-)
Let's see...
- the ``or`` translates to an ``any(...)``
- ``not isinstance(obj, Image)`` is repeated 3 times
- ``[src, mask, dest]`` corresponds to the 3 objects
- ``mask != None`` is unnecessary, unless somehow None has been registered
as an instance of Image.

... can't spot it. Give me a hint?
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Two-Dimensional Expression Layout

2016-08-20 Thread Michael Selik
On Fri, Aug 19, 2016 at 5:01 AM Lawrence D’Oliveiro 
wrote:

> It is handy to be able to keep complex expressions together sometimes,
> when breaking them up would simply obscure their structure. To avoid lines
> getting long, why not take advantage of the two available screen/page
> dimensions to make their structure clearer? As a bonus, spacing out
> parentheses makes them look less of a clutter.
>
>

> Examples from <
> https://github.com/ldo/qahirah_examples/blob/master/operators>:
>
> A function call with complex arguments (specifying arguments by keywords
> is highly recommended here):
>
> rect_1_pattern = \
> qah.Pattern.create_linear \
>   (
> p0 = (0, 0),
> p1 = (major_dim, 0),
> colour_stops =
> (
> (0, rect_1_colour),
> (1, complement(rect_1_colour)),
> )
>   )
>

I'd rather have intermediate variables and avoid the non-semantic
indentation.

p0 = (0, 0)
p1 = (major_dim, 0)
colour_stops = (0, rect_1_colour), (1, complement(rect_1_colour))
rect_1_pattern = qah.Pattern.create_linear(p0, p1, colour_stops)



Computing a variable value (using redundant parentheses to avoid
> backslash-continuations):
>
> dest_rect = \
> (
> draw_bounds
> +
> Vector(col, row) * draw_bounds.dimensions
> +
> Vector(0, top_extra)
> )
>

I'd rather have one long line for this case, even if it's "too long" by PEP
8 standards. If it's too long to think about, I'd break the task into
parts, each with a well-considered variable name.

substep = a + b
final = substep + c



From , a
> complex condition (with redundant parentheses again):
>
> if (
> not isinstance(src, Image)
> or
> mask != None and not isinstance(mask, Image)
> or
> not isinstance(dest, Image)
> ) :
> raise TypeError("image args must be Image objects")
> #end if
>

No need for the separate calls to isinstance, nor the check for None.

if any(not isinstance(obj, Image) for obj in [src, mask, dest]):
...


If you prefer maps to comprehensions:

is_image = lambda obj: isinstance(obj, Image)
if any(map(is_image, [src, mask, dest])):
...
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: What's the best way to minimize the need of run time checks?

2016-08-17 Thread Michael Selik
On Sun, Aug 14, 2016 at 11:01 AM  wrote:

> On Sunday, August 14, 2016 at 7:09:47 AM UTC+1, Paul Rubin wrote:
> > Steven D'Aprano writes:
> > > If the Python community rallies around this "record" functionality and
> > > takes to it like they took too namedtuple
> >
> > I like namedtuple and I think that it's a feature that they're modified
> > by making a new copy.  I know that has overhead but it's palpably
> > bug-avoidant.  I've used them extensively in some programs and they took
> > a considerable burden off my mind compared to using something like
> > structs or records.
>
> You might find this https://glyph.twistedmatrix.com/2016/08/attrs.html an
> interesting read.
>

I disagree with a few points from that blog post.

1. I don't mind typing so much. I like to be explicit. The attrs library
uses some overly-concise abbreviations. For example, what's the meaning of
``@attrs.s`` or ``attrs.ib``?
2. When inheriting from a namedtuple, I use the same class name for the
base and the child, so my reprs look good.
3. I don't bother to fieldnames.split() when passing fieldnames as a
space-separated string, because the split is unnecessary.
4. I *like* that namedtuple is backwards-compatible with tuples, so that
refactoring from tuples to namedtuples is easy.
5. Inheritance is useful. Sure, there are times it fails, but that's true
for any technique.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Finding the first index in a list greater than a particular value

2016-08-15 Thread Michael Selik
On Mon, Aug 15, 2016 at 2:01 AM Jussi Piitulainen <
jussi.piitulai...@helsinki.fi> wrote:

> There is a tradition of returning -1 when no valid index is found.
>

Sometimes it's better to break with tradition. Raise a ValueError. No
silent errors, and all that Zen.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Finding the first index in a list greater than a particular value

2016-08-14 Thread Michael Selik
On Sun, Aug 14, 2016 at 2:21 PM Atri Mahapatra 
wrote:

> I have a list of dictionaries which look like this:
> [{'Width': 100, 'Length': 20.0, 'Object': 'Object1'}, {'Width': 12.0,
> 'Length': 40.0, 'Object': 'Object2'}.. so on till 10]
>
> I would like to find the first index in the list of dictionaries whose
> length is greater than a particular value
>
> f=lambda seq, m: [ii for ii in range(0, len(seq)) if seq[ii]['Length'] >
> m][0] and it throws an error
>
> can  anyone suggest a way  to do it?
>

There's no need to play code golf (squishing your thoughts into one line).

def index_of_first_record_of_minimum_size(records, m):
'records is an iterable of dictionaries'

for i, dictionary in enumerate(list_of_dicts):
if dictionary['Length'] > m:
return i
raise ValueError('no record found with "Length" greater than %r' %
(m,))


If you have trouble coming up with a good name for a function, that
suggests you are either doing too much or too little with that function. If
you want the same task outside of a function, change the return to a break.

if not records:
raise ValueError('no records found')
for index, d in enumerate(records):
if d['Length'] > m:
break # `index` is now the index of the first record of minimum
length
else:
raise ValueError('no record found with "Length" greater than %r' %
(m,))
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Creating dictionary of items from Excel with mutliple keys

2016-08-13 Thread Michael Selik
On Sat, Aug 13, 2016 at 12:46 PM Atri Mahapatra 
wrote:

> I am trying to create a following dictionary. I am reading data from excel
>

Rather than using xlrd or other tools to read from excel, can you save the
file as CSV (comma-separated values)? I think you'll find Python's csv
module is very pleasant to use.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: What's the best way to minimize the need of run time checks?

2016-08-12 Thread Michael Selik
On Fri, Aug 12, 2016, 7:11 AM Steven D'Aprano 
wrote:

>
> [1] Are there programming language aware spell checkers? If not, there
> should be.
>

A good autocomplete is much like a spell-checker. I have far fewer spelling
errors when using an editor with autocomplete.

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


Re: Print function not working

2016-08-11 Thread Michael Selik
On Thu, Aug 11, 2016 at 1:38 PM MRAB  wrote:

> On 2016-08-11 18:18, Chris Angelico wrote:
> > On Fri, Aug 12, 2016 at 3:03 AM, Atri Mahapatra
> >  wrote:
> >> I have installed IDLE 3.5.1 and wrote the following  to check if print
> is working. When it runs, I do not see anything is printed:
> >>
> >> class Base: #{
> >> def __init__( self ): #{
> >> print("Hello, world: \n\n");
> >>
> >> #}
> >>
> >> #}
> >>
> >>
> >> if ( __name__ == " __main__"): #{
> >> root = Base();
> >> #}
> >>
> >> Can anyone please point out the reason?
> >>
> >> Thanks,
> >> Atri
> >
> > Is name equal to main? That is, are you running this code as a top-level
> script?
> >
> It's not checking whether the name is "__main__", but whether it's "
> __main__" (note the space after the first quote).
>
> > Also: You do not need to write Python code as if it were C or Java.
> > All that extra punctuation is just putting unnecessary stress on the
> > world's punctuation mines, which are already overworked. :)
> >
> +1
>

When debugging something like this, one technique is to remove bits of code
to reduce the complexity. Remove something, run the code, check the
results, then repeat if it's still failing.

If you're not sure how class initializers work, maybe convert to a regular
function and try again.

def foo():
print('hello')
if __name__ == '__main__':
foo()

If that still doesn't work, maybe get rid of the function.

if __name__ == '__main__':
print('hello')

And if that still doesn't work, maybe get rid of the if-statement.

print('hello')

I think you'll find that the single line program "print('hello')" works
just fine.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Asynchronous programming

2016-08-11 Thread Michael Selik
On Thu, Aug 11, 2016 at 11:46 AM Michael Selik <michael.se...@gmail.com>
wrote:

> On Thu, Aug 11, 2016 at 11:01 AM Steven D'Aprano <
> steve+pyt...@pearwood.info> wrote:
>
>> That ... looks wrong. You're taking something which looks like a procedure
>> in the first case (trn.execute), so it probably returns None, and yielding
>> over it. Even it that's not wrong, and it actually returned something
>> which
>> you ignored in the first case
>>
>
> It's a standard, perhaps a mistaken standard, but nonetheless database
> cursors tend to have that feature: execute returns the mutated self. I
> agree that execute looks like it should return None instead. The return
> self pattern feels Rubyish to me (or Rubic?).
>

Contradicting myself:
yield from c.execute(query).fetchall()# looks good
yield from c.execute(query)   # looks bad
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Asynchronous programming

2016-08-11 Thread Michael Selik
On Thu, Aug 11, 2016 at 11:01 AM Steven D'Aprano 
wrote:

> That ... looks wrong. You're taking something which looks like a procedure
> in the first case (trn.execute), so it probably returns None, and yielding
> over it. Even it that's not wrong, and it actually returned something which
> you ignored in the first case
>

It's a standard, perhaps a mistaken standard, but nonetheless database
cursors tend to have that feature: execute returns the mutated self. I
agree that execute looks like it should return None instead. The return
self pattern feels Rubyish to me (or Rubic?).
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Advice on optimizing a Python data driven rules engine

2016-08-11 Thread Michael Selik
On Thu, Aug 11, 2016 at 10:57 AM Malcolm Greene  wrote:

> Background: I'm building a  rules engine for transforming rows of data
> being returned by csv DictReader, eg. each row of data is a dict of column
> name to value mappings. My rules are a list of rule objects whose
> attributes get referenced by rule specific methods. Each rule has an
> associated method which gets called based on rule name.
>

Could you share the API you've designed for this tool? An example of usage
will clarify what you intend.

One technique for applying a transformation function to each record
returned by a csv DictReader:

import csv
import math
from io import StringIO

f = StringIO('''\
a,b,c
1,2,3
4,5,6
''')

def pass_(value):
return value

transforms = {
'a': lambda v: math.sin(int(v)),
'b': lambda v: math.cos(int(v)),
}

for row in csv.DictReader(f):
print({k: transforms.get(k, pass_)(v) for k, v in row.items()})



Using __missing__ for your transform dict might be more elegant than .get
with a pass_ as default.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: What's the best way to minimize the need of run time checks?

2016-08-10 Thread Michael Selik
On Wed, Aug 10, 2016, 6:44 PM Juan Pablo Romero Méndez <
jpablo.rom...@gmail.com> wrote:

> As to why I asked that, there are several reasons: I have a very concrete
> need right now to find pragmatic ways to increase code quality, reduce
> number of defects, etc. in a Python code base. But also I want to
> understand better the mind set and culture of Python's community.
>

That's a much better question. Arguing about type checking is somewhat of a
red herring. It's best not to fight the language, but to use its strengths.

I often find that trying to add type and value checks just makes my code
harder to read and harder to maintain, even if they solve a particular bug
in the moment. A better solution is to refactor in such a way that those
checks are unnecessary.

Are you familiar with context managers and the iterator protocol? If not, I
suggest you start by looking for setup/cleanup code or try/except/finally
blocks that you can refactor into a context manager and by looking for
awkward loops with explicit external state that you can refactor into an
iterator.

If you really must add type- and value-checks, I suggest trying to place
them in a property so that they don't clutter the more interesting code.

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


Re: What's the best way to minimize the need of run time checks?

2016-08-10 Thread Michael Selik
On Wed, Aug 10, 2016, 4:34 PM Juan Pablo Romero Méndez <
jpablo.rom...@gmail.com> wrote:

>
> I've been trying to find (without success so far) an example of a situation
> where the dynamic features of a language like Python provides a clear
> advantage over languages with more than one type.
>

Only one type? There are a great variety of types for Python objects. Even
Python classes have types. Further, you can modify types at runtime! It's a
typing bonanza!

I suppose you could argue we're conflating types and classes. If so, it
sounds like you started this conversation with an ulterior motive and not
to learn about best practices for runtime type checking in Python.

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


Re: Why can't I define a variable like "miles_driven" with an underscore in Python 3.4.3 ?

2016-08-10 Thread Michael Selik
On Wed, Aug 10, 2016 at 1:41 PM Cai Gengyang  wrote:

> I managed to get this piece of code to work :
>
> >>> print("This program calculates mpg.")
> This program calculates mpg.
> >>> milesdriven = input("Enter miles driven:")
> Enter miles driven: 50
> >>> milesdriven = float(milesdriven)
> >>> gallonsused = input("Enter gallons used:")
> Enter gallons used: 100
> >>> gallonsused = float(gallonsused)
> >>> gallonsused = float(gallonsused)
> >>> mpg = milesdriven / gallonsused
> >>> print("Miles per gallon:", mpg)
> Miles per gallon: 0.5
> >>> print("This program calculates mpg.")
> This program calculates mpg.
> >>> milesdriven = input("Enter miles driven:")
> Enter miles driven: 100
> >>> milesdriven = float(milesdriven)
> >>> gallonsused = input("Enter gallons used:")
> Enter gallons used: 500
> >>> gallonsused = float(gallonsused)
> >>> mpg = milesdriven / gallonsused
> >>> print("Miles per gallon:", mpg)
> Miles per gallon: 0.2
>
> But, why can't i define a variable like "miles_driven" with an underscore
> in my Python Shell ? When I try to define it , the underscore doesn't
> appear at all and instead I get this result :
> "miles driven" , with no underscore appearing even though I have already
> typed "_" between "miles" and "driven" ?
>

You'll have to give more information about the system you're using.
Underscores are allowed in Python variable names.

The first thought I have is that something outside of Python is changing
your underscore to a space. Perhaps your OS spelling autocorrect is overly
aggressive?
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: What's the best way to minimize the need of run time checks?

2016-08-10 Thread Michael Selik
On Tue, Aug 9, 2016 at 9:31 PM Steven D'Aprano 
wrote:

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


Great link. I enjoyed the video, too.
https://www.youtube.com/watch?v=tz-Bb-D6teE

Buried deep in the QA section, there's a comment from the audience (I'll
paraphrase), that compiler type-checking is wonderful. Yegge replies that, "I
realized early in my career that I would actually rather have a runtime
error than a compile error."
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: What's the best way to minimize the need of run time checks?

2016-08-09 Thread Michael Selik
On Wed, Aug 10, 2016 at 1:22 AM Juan Pablo Romero Méndez <
jpablo.rom...@gmail.com> wrote:

> 1) catching exceptions at the point where you care, 2)
> preemptively check for certain runtime conditions to avoid exceptions 3)
> write as many tests as possible  4) learn to live with runtime errors.
>

I suggest focusing on #4, learn to appreciate/enjoy runtime errors. When
you've come around to that way of thinking, you'll have better judgement on
when to care about catching exceptions vs letting them stop your program.

As for writing as many tests as possible... eh. Think about your code
scientifically. You can disprove a falsifiable hypothesis, but you can't
prove a hypothesis. Sometimes you can formally prove the correctness of
your code via logical deduction, but that's not testing. Sometimes you can
exhaustively test all expected inputs, but it's impossible to exhaustively
test the infinity of possible inputs. So write tests as if you're
presenting evidence for a theory.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: What's the best way to minimize the need of run time checks?

2016-08-09 Thread Michael Selik
On Tue, Aug 9, 2016 at 3:22 PM Juan Pablo Romero Méndez <
jpablo.rom...@gmail.com> wrote:

> I'm actually looking for ways to minimize run time errors, so that would
> include TypeError and AttributeError.
>
> In your "File-like" example having type information would prevent me from
> even passing the wrong object, so I don't need to test for that particular
> problem.
>

Let's clarify this discussion by using the word "check" for type-checks
that necessary for the application to behave as desired and using the word
"test" for checking application behavior under normal and edge cases, such
as unexpected types being passed.

Are you saying you want to minimize type-checks during the execution of
your application? Or do you want to minimize the amount of testing code you
write?

I don't check for file-likeness in the application code. If somehow a
non-file-like (file-unlike?) object makes its way into my function, I
expect (and hope) my program will immediately stop and print a nice
traceback for me. If I wanted some other behavior, I probably would already
have try/except surrounding the appropriate section to deal with not-found
or permissions errors. If I need to, I'll add TypeError and AttributeError
to that except statement.

I sometimes write tests for unexpected inputs, checking to ensure that
either a TypeError or AttributeError is raised. However, sometimes I'm not
worried about it. If the user gives me bizarre input, they should know to
expect (possibly) bizarre results. Who knows, maybe that's what they wanted.

I would add type-checking or value-checking to my application if the wrong
type or value does not raise an error but instead causes an infinite loop
or corrupts data. Those situations are fairly rare.



On Tue, Aug 9, 2016 at 4:52 PM Juan Pablo Romero Méndez <
jpablo.rom...@gmail.com> wrote:

> So as the writer of the function you expect the user to read the function
> body to determine what is safe to pass or not?


No. But I usually expect them to not freak out when they see a traceback.
Or if they do freak out, I want them to freak out and send a bug report.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: What's the best way to minimize the need of run time checks?

2016-08-09 Thread Michael Selik
On Tue, Aug 9, 2016 at 2:59 PM Chris Angelico <ros...@gmail.com> wrote:

> On Wed, Aug 10, 2016 at 4:51 AM, Michael Selik <michael.se...@gmail.com>
> wrote:
> > "File-like" is a good example. Rather than go through the frustration of
> a
> > formal definition for what is file-like, stay productive and flexible
> with
> > duck typing. Objects that don't have the appropriate methods or
> attributes
> > will cause a TypeError or AttributeError. If you're passing in the wrong
> > kind of object, you'll find out almost as soon as you write the code
> > (because you test early and often), just as you would with a statically
> > analyzed type system.
>
> It's slightly delayed; with Python, you have to actually execute the
> code path in question, whereas a static type system would detect it at
> the compilation stage. So it may depend on the quality of your
> testing. MyPy may be able to help there.
>

Depends on how long it takes to compile!
https://xkcd.com/303/
:-)
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: What's the best way to minimize the need of run time checks?

2016-08-09 Thread Michael Selik
On Tue, Aug 9, 2016 at 2:31 PM Juan Pablo Romero Méndez <
jpablo.rom...@gmail.com> wrote:

> Hello,
>
> In online forums sometimes people complain that they end up having to test
> constantly for None, or that a function's argument has a specific type /
> shape (which immediately brings the following aphorism to mind: "Any
> sufficiently large test suite contains an ad hoc, bug-ridden, slow
> implementation of half of Haskell's type system").
>
> Some responses I've seen to that particular complaint is that they are
> doing it wrong. That they are trying to force a type system into a dynamic
> language (Clojure, Ruby, Python, Javascript, etc).
>
> Do you guys have any resources you like that addresses the following issue:
> What is the best way to use the dynamic features of Python to avoid having
> to write a poor's man type system?
>

It'll be easiest to discuss a specific example. Can you share a chunk of
code which frustrates you?

In general, Python's TypeError and AttributeError serve much the same
purpose as other languages' type systems. Where other languages might force
you to create named, formally specified types, Python allows informally
specified interfaces.

"File-like" is a good example. Rather than go through the frustration of a
formal definition for what is file-like, stay productive and flexible with
duck typing. Objects that don't have the appropriate methods or attributes
will cause a TypeError or AttributeError. If you're passing in the wrong
kind of object, you'll find out almost as soon as you write the code
(because you test early and often), just as you would with a statically
analyzed type system.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Call for Assistance

2016-08-09 Thread Michael Selik
On Tue, Aug 9, 2016 at 3:23 AM Charles Ross  wrote:

> I’ve begun a new book called Meta Python that I’m looking for assistance
> with. The book is one I wish was out there, and so am writing. The book is
> targeted at experienced programmers who are novice Python users and want to
> move from that point to one where they have published to PyPI.
>

Maybe you should add a chapter discussing community, open-source,
volunteerism, and how difficult it is to get enthusiastic, productive
contributors, but how easy it is to get emailed criticism?
(no cynicism intended)
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Question regarding stdlib distutils strtobool behavior

2016-08-09 Thread Michael Selik
On Tue, Aug 9, 2016 at 9:50 AM Joseph Bane <havocjos...@gmail.com> wrote:

> Thank you for your note. I was thinking it might be just a historical
> artifact.
>

That was just my guess. You can search the mailing list archives and the
bug tracker to find out if there's been any past discussion.


> Do you think this is the type of thing we could propose be changed in the
> next version of Python? It seems it would be more consistent with
> the principle of least surprise from the perspective of outsider Python
> calling code. I would be happy to submit a small patch for this change.
>

Seems non-controversial enough that you could write a bug on
http://bugs.python.org/ and then submit a patch. The question is whether or
not you can convince someone with commit access to push your change.

Even if your patch improves the code, it might not improve it enough to
justify change. There are some disadvantages to code churn.

If I were revising it, it'd be something like this...

def strtobool(val):
"""Convert a string representation of truth to true (1) or false
(0).

True values are 'y', 'yes', 't', 'true', 'on', and '1'; false values
are 'n', 'no', 'f', 'false', 'off', and '0'.  Raises ValueError if
'val' is anything else.
"""
val = val.casefold()
if val in ('y', 'yes', 't', 'true', 'on', '1'):
return True
if val in ('n', 'no', 'f', 'false', 'off', '0'):
return False
raise ValueError(f'invalid truth value {val}')

For unicode, str.casefold is better than str.lower for caseless comparison. The
elif and else were unnecessary because of the returns. For fun, I thought
I'd use the new string formatting style (
https://www.python.org/dev/peps/pep-0498/).

Again, I'm not sure if those changes are worthwhile.


As a side note, we discovered this with some code that was checking `if var
> is True` instead of just `if var`.
>

The Pythonic style is to simply check ``if var`` rather than ``if var is
True``. This realizes the flexibility of duck typing -- it doesn't matter
whether the variable is True, so long as it is true (eg. has a non-false
truth value).

The core developers might thus say there's no bug here, because 1 is true.



My apologies for forgetting to use interleaved response style previously.
Google Inbox defaults to top-posting.


On Tue, Aug 9, 2016 at 9:34 AM, Michael Selik <michael.se...@gmail.com>
wrote:

> On Tue, Aug 9, 2016 at 9:26 AM Joseph Bane <havocjos...@gmail.com> wrote:
>>
>>> Hello.
>>>
>>> It recently came to my attention that the strtobool function in the
>>> standard library doesn't return Python native boolean values, but rather
>>> returns integer 0 or 1:
>>>
>>> https://hg.python.org/cpython/file/3.5/Lib/distutils/util.py#l304
>>>
>>> I am curious why this is the defined behavior and whether anyone can
>>> fill me in regarding this approach. For clarity, I would expect the code to
>>> `return True` and `return False` rather than `return 1` and `return 0`.
>>>
>>
>> I'll take a guess: it's probably a(n) historical artifact. Before there
>> were bools, returning 1 or 0 was the obvious technique. Even after bools
>> were added to Python 2, returning the literal 1 or 0 was faster than
>> looking up the names True or False. Now that True and False are keywords,
>> using the keyword is the obvious solution.
>>
>
>
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Question regarding stdlib distutils strtobool behavior

2016-08-09 Thread Michael Selik
On Tue, Aug 9, 2016 at 9:26 AM Joseph Bane  wrote:

> Hello.
>
> It recently came to my attention that the strtobool function in the
> standard library doesn't return Python native boolean values, but rather
> returns integer 0 or 1:
>
> https://hg.python.org/cpython/file/3.5/Lib/distutils/util.py#l304
>
> I am curious why this is the defined behavior and whether anyone can fill
> me in regarding this approach. For clarity, I would expect the code to
> `return True` and `return False` rather than `return 1` and `return 0`.
>

I'll take a guess: it's probably a(n) historical artifact. Before there
were bools, returning 1 or 0 was the obvious technique. Even after bools
were added to Python 2, returning the literal 1 or 0 was faster than
looking up the names True or False. Now that True and False are keywords,
using the keyword is the obvious solution.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Python slang

2016-08-06 Thread Michael Selik via Python-list
On Sat, Aug 6, 2016, 10:10 AM Marco Sulla via Python-list <
python-list@python.org> wrote:

> On 6 August 2016 at 00:31, Chris Angelico  wrote:
> > On Sat, Aug 6, 2016 at 8:00 AM, Marco Sulla via Python-list
> >  wrote:
> >> * `dict` instead of `map`
> >
> > "map" has many other meanings (most notably the action wherein you
> > call a function on every member of a collection to produce another
> > collection).
>
> Well, the word `map` of the `map` function is a verb. IMO there would
> be no ambiguity.
>

Are you thinking of Lisp-2 where functions have a separate namespace from
everything else?
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Python slang

2016-08-06 Thread Michael Selik
On Fri, Aug 5, 2016 at 10:12 PM Chris Angelico  wrote:

> That answers the question about True and False, but not about None,
> which started the question. Why are instances capitalized here? Is it
> simply a matter of grandfathering in, with no specific decision?
>

When people ask me why the core classes are lowercased, I joke that it's
following Hamming's thought that "true greatness" is when your name is
spelled all lower case [0]. Great things are capitalized, like Counter, but
truly great things are lowercased, like dict.

BTW, this leads me to the thought that someone should edit Wikipedia to
properly lowercase "hamming window".

[0] "You and Your Research" (http://www.paulgraham.com/hamming.html)
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Capturing the bad codes that raise UnicodeError exceptions during decoding

2016-08-04 Thread Michael Selik
On Thu, Aug 4, 2016 at 3:24 PM Malcolm Greene  wrote:

> Hi Chris,
>
> Thanks for your suggestions. I would like to capture the specific bad
> codes *before* they get replaced. So if a line of text has 10 bad codes
> (each one raising UnicodeError), I would like to track each exception's
> bad code but still return a valid decode line when finished.
>
> My goal is to count the total number of UnicodeExceptions within a file
> (as a data quality metric) and track the frequency of specific bad
> code's (via a collections.counter dict) to see if there's a pattern that
> can be traced to bad upstream process.
>

Give this a shot (below). It seems to do what you want.


import csv
from collections import Counter
from io import BytesIO

def _cleanline(line, counts=Counter()):
try:
return line.decode()
except UnicodeDecodeError as e:
counts[line[e.start:e.end]] += 1
return line[:e.start].decode() + _cleanline(line[e.end:], counts)

def cleanlines(fp):
'''
convert data to text; track decoding errors
``fp`` is an open file-like iterable of lines'
'''
cleanlines.errors = Counter()
for line in fp:
yield _cleanline(line, cleanlines.errors)

f = BytesIO(b'''\
this,is line,one
line two,has junk,\xffin it
so does,\xfa\xffline,three
''')

for row in csv.reader(cleanlines(f)):
print(row)

print(cleanlines.errors.most_common())
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: usage of functools.partial in in parallelism

2016-08-01 Thread Michael Selik
On Sun, Jul 31, 2016 at 5:47 AM Sivan Greenberg  wrote:

> That's exactly the answer I was looking for. Thanks.
>
> I got used too much I guess to solving problems the OOP way, e.g. my code
> wraps the session.get invocation with a class to pack together the
> arguments and data and also took care of parallelism using gevent, from
> within the class.
>
> While a bit more verbose (or god forbid..unpythonic?) I find it much nore
> readable in my taste and easier to pass on to the next code maintainer in
> the heritage.
>

You might benefit from watching the talk "Stop Writing Classes"
https://www.youtube.com/watch?v=o9pEzgHorH0
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Dynamically call methods where method is known by address vs name

2016-07-22 Thread Michael Selik
On Fri, Jul 22, 2016 at 4:05 PM Malcolm Greene  wrote:

> I know I can do the following:
>
> >>> s = 'lower'
> >>> getattr(s, 'upper')()
> 'LOWER'
>
> But how could I do the same if I had the method 'address' (better
> name???) vs. method name?
>
> >>> upper_method = s.upper
>
> How do I combine this upper_method with string s to execute the method
> and return 'LOWER'?
>

In [1]: s = 'hello'
In [2]: f = s.upper
In [3]: f()
Out[3]: 'HELLO'
In [4]: g = str.upper
In [5]: g(s)
Out[5]: 'HELLO'

Is that what you're looking for?
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Stupid question, just need a quick and dirty fix

2016-07-22 Thread Michael Selik
On Fri, Jul 22, 2016 at 2:11 AM Steven D'Aprano <st...@pearwood.info> wrote:

> On Fri, 22 Jul 2016 03:18 pm, Michael Selik wrote:
> >> On Jul 22, 2016, at 12:39 AM, Jordan Bayless <jmbayl...@gmail.com>
> wrote:
> >>
> >> Posting the entire code snippet is tough because it's thousands of lines
> >> of code.
> >
> > You could paste into a GitHub gist (https://gist.github.com/) and share
> > the link.
>
> Are you going to read "thousands of lines" of unfamiliar code trying to
> work
> out what changes need to be made to fix an underspecified problem?
>
> Yeah, sure you are. Have fun.
>

I suppose not :-)
But then I could follow up with a request for the traceback.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Stupid question, just need a quick and dirty fix

2016-07-21 Thread Michael Selik

> On Jul 22, 2016, at 12:39 AM, Jordan Bayless  wrote:
> 
> Posting the entire code snippet is tough because it's thousands of lines of 
> code.

You could paste into a GitHub gist (https://gist.github.com/) and share the 
link.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: reversed(enumerate(x))

2016-07-20 Thread Michael Selik

> On Jul 20, 2016, at 12:42 PM, Ian Kelly  wrote:
> 
>for i, n in reversed(enumerate(x)): pass
> 
> fails with "TypeError: argument to reversed() must be a sequence".

So make it a sequence:
for i, n in reversed(list(enumerate(x))): pass

If ``x`` is very large, you can use your zip/range technique to save memory.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Compression of random binary data

2016-07-11 Thread Michael Selik
On Mon, Jul 11, 2016, 10:56 AM  wrote:

> What kind of statistic law or mathematical conjecture  or is it even a
> physical law is violated by compression of random binary data?
>

If you get lucky, you might be able to achieve very good compression.

> http://dilbert.com/strip/2001-10-25

Or are you asking about an algorithm that reliably compresses random data
by a fairly constant percent?

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


Re: Quick poll: gmean or geometric_mean

2016-07-10 Thread Michael Selik
On Sun, Jul 10, 2016, 5:08 AM Chris Angelico  wrote:

> On Sun, Jul 10, 2016 at 8:08 PM, Steven D'Aprano 
> wrote:
> >> Now even the basic IPython shell has autocomplete :-)
> >
> > Not all shells or editors are IPython, and not all abbreviations are bad.
> > Would you rather print, or
> > write_values_as_strings_to_the_predefined_standard_output_file?
>
> Also: Interesting that the IPython shell is "basic". I thought the
> basic Python shell was the one you get when you type "python" with no
> args. Idle or IPython or anything else is a layer on top of that.
>

It is. I meant the basic terminal version of IPython, rather than the QT or
Jupyter version.

IPython 5 switched from readline to prompt_toolkit, so it gained a few nice
features.

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


Re: Quick poll: gmean or geometric_mean

2016-07-10 Thread Michael Selik
On Sun, Jul 10, 2016, 4:56 AM Steven D'Aprano  wrote:

> On Sun, 10 Jul 2016 05:28 pm, Rustom Mody wrote:
>
> > From fuzzy memory of sitting in statistics classes decades ago
> > filled with μ-σ etc I'd suggest μ gμ hμ
>
> In all the stats books and references I've seen, μ is always the population
> mean (implicitly the arithmetic mean). When discussing the different kinds
> of mean, A, G and H are used for arithmetic, geometric and harmonic means.
> (Other means are rarely discussed.)
>
> I don't think I've ever seen gµ or hµ. They're sort of backwards... I'd
> expect µ subscript-g or subscript-h, not the other way.
>

I'm glad you brought up textbooks as it reminded me to say that most
scientific software is still struggling to shake off the legacy of
abbreviation.

Now even the basic IPython shell has autocomplete :-)

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


Re: Quick poll: gmean or geometric_mean

2016-07-09 Thread Michael Selik
On Sat, Jul 9, 2016, 12:57 PM Robert Kern <robert.k...@gmail.com> wrote:

> On 2016-07-09 17:13, Michael Selik wrote:
> > On Sat, Jul 9, 2016 at 10:17 AM Jason Friedman <jsf80...@gmail.com>
> wrote:
> >
> >>> +1 for consistency
> >
> > What do other languages use?
>
> R, the most likely candidate, doesn't have them built-in.
>
> scipy.stats uses gmean() and hmean()
>

SciPy also uses other obscure abbreviations. My least favorite is "eye".

My first thought at reading "hmean" might be horizontal mean, especially if
there were a vmean.

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


Re: Quick poll: gmean or geometric_mean

2016-07-09 Thread Michael Selik
On Sat, Jul 9, 2016 at 10:17 AM Jason Friedman  wrote:

> > +1 for consistency
>

What do other languages use?

Even though I generally prefer complete words instead of abbreviations, if
an abbreviation is a strong standard across many statistics modules (like
"stdev" instead of "standard_deviation"), then it's better to stay
consistent with that standard.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Clean Singleton Docstrings

2016-07-07 Thread Michael Selik


> On Jul 7, 2016, at 7:46 PM, Rob Gaddi  
> wrote:
> 
> I've got a package that contains a global ensmartened dict that allows
> all the various parts of my program to share state.

The simplest solution would be to use a module as your singleton. For example, 
"registry.py" would work. Pydoc will show its docstring, and it will have all 
the features you had been using, with the added benefit of not needing to 
enforce its singletonness.
 
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Making Classes Subclassable

2016-07-04 Thread Michael Selik
On Mon, Jul 4, 2016, 4:36 AM Lawrence D’Oliveiro 
wrote:

> On Monday, July 4, 2016 at 7:58:07 PM UTC+12, dieter wrote:
> > --> "type(obj)" or "obj.__class__" (there are small differences)
> > give you the type/class of "obj".
>
> When would it not be the same?
>

Old-style classes.

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


Re: Language improvement: Get more from the `for .. else` clause

2016-06-29 Thread Michael Selik
On Wed, Jun 29, 2016 at 7:11 AM Victor Savu 
wrote:

> Please let me know if you are interested in a more concrete case such as a
> domain-specific application (I can think of progress bars, logging,
> transfer rate statistics ...).
>

Yes, please. I'd like to compare the proposed syntax against the solution
with the current syntax.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Sharing package data across files

2016-06-28 Thread Michael Selik
On Tue, Jun 28, 2016 at 3:21 PM  wrote:

> I'm trying to create a package in which the constituent files share some
> state.  Apparently, I don't understand scopes, namespaces, and package
> semantics as well as I thought I did.  Here's the directory structure for a
> simplified example:
>
>example/
>  __init__.py
>  vars.py
>  funcs.py
>
> How can I make the example package work like one integrated module even
> though in reality it's split across multiple files?
>

Why do you want to?
Isn't easier to have the ``funcs`` module import the ``vars`` module?
Even easier, paste all the code into a single file.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: fastest way to read a text file in to a numpy array

2016-06-28 Thread Michael Selik
On Tue, Jun 28, 2016 at 10:08 AM Hedieh Ebrahimi  wrote:

> File 1 has :
> x1,y1,z1
> x2,y2,z2
> 
>
> and file2 has :
> x1,y1,z1,value1
> x2,y2,z2,value2
> x3,y3,z3,value3
> ...
>
> I need to read the coordinates from file 1 and then interpolate a value
> for these coordinates on file 2 to the closest coordinate possible. The
> problem is file 2 is has around 5M lines. So I was wondering what would be
> the fastest approach?
>

Is this a one-time task, or something you'll need to repeat frequently?
How many points need to be interpolated?
How do you define distance? Euclidean 3d distance? K-nearest?

5 million can probably fit into memory, so it's not so bad.

NumPy is a good option for broadcasting the distance function across all 5
million labeled points for each unlabeled point. Given that file format,
NumPy can probably read from file directly into an array.

http://stackoverflow.com/questions/3518778/how-to-read-csv-into-record-array-in-numpy
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: fastest way to read a text file in to a numpy array

2016-06-28 Thread Michael Selik
On Tue, Jun 28, 2016 at 9:51 AM Heli  wrote:

> Is even reading the file in to numpy array the best method or there are
> better approaches?
>

What are you trying to accomplish?
Summary statistics, data transformation, analysis...?
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Iteration, while loop, and for loop

2016-06-28 Thread Michael Selik
On Tue, Jun 28, 2016 at 9:26 AM Joseph Lee <joseph.lee22...@gmail.com>
wrote:

>
> -Original Message-----
> From: Michael Selik
> Sent: Tuesday, June 28, 2016 6:16 AM
>
> MS: You should not. Use the first version, it's much better. Python
> for-loops are preferable to while-loops.
>
> JL: For the most part, for loops are better, but there are times when
> while loops are preferable such as when you don't know the size of the
> input beforehand.


Not knowing the number of elements is not a reason to prefer a while-loop.
A for-loop handles that quite well.

with open('example.txt') as f:
for line in f:
print(line)

We often loop over files without knowing how big a file is.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Iteration, while loop, and for loop

2016-06-28 Thread Michael Selik
On Tue, Jun 28, 2016 at 9:34 AM BartC <b...@freeuk.com> wrote:

> On 28/06/2016 14:15, Michael Selik wrote:
> > On Tue, Jun 28, 2016 at 8:41 AM Elizabeth Weiss <cake...@gmail.com>
> wrote:
> >
> >> I do not understand the second code. What is counter?
> >>
> >
> > It looks like someone wanted to make a loop induction variable.
> > https://en.wikipedia.org/wiki/Induction_variable
>
> I don't know if that helps; I've never heard of an induction variable.
>

But you've seen them often in other programming languages?


> And according to the first example in that link, then 'word' in the OP's
> second example might be classed as an induction variable too!


The variable ``word`` was not being incremented/decremented by a fixed
amount, nor was it a linear function of another induction variable.


> Confusing.


Indeed. That's why Python's for-loops are preferable.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Iteration, while loop, and for loop

2016-06-28 Thread Michael Selik
On Tue, Jun 28, 2016 at 8:41 AM Elizabeth Weiss  wrote:

> I do not understand the second code. What is counter?
>

It looks like someone wanted to make a loop induction variable.
https://en.wikipedia.org/wiki/Induction_variable


> Why do we use this code if we can use the simpler for loop?
>

You should not. Use the first version, it's much better. Python for-loops
are preferable to while-loops.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Language improvement: Get more from the `for .. else` clause

2016-06-27 Thread Michael Selik
On Mon, Jun 27, 2016 at 12:53 AM Victor Savu 
wrote:

> capture the [StopIteration] value in the `else` statement of the `for` loop
>

I'm having trouble thinking of a case when this new feature is necessary.
Can you show a more realistic example?
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Proposal: named return values through dict initialization and unpacking

2016-06-26 Thread Michael Selik
On Tue, Jun 21, 2016 at 9:41 PM Steven D'Aprano  wrote:

> On Tue, 21 Jun 2016 05:34 pm, Ari Freund wrote:
> >  var3, var1, var2 = **d
>
> But I don't want to use the key names your function uses. I want to
> use names which makes sense for my application
>

Note that my dict unpacking syntax proposal would solve this quite nicely.

{'var1': width, 'var2': counter, 'var3': aardvark} = d

But the current syntax ain't so bad either. Maybe it's even better, more
readable despite being less concise.

expected = {'var1', 'var2', 'var3'}
excess = d.keys() - expected
if excess:
raise ValueError('unexpected keys {!r}'.format(excess))
width = d['var1']
counter = d['var2']
aardvark = d['var3']
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Is signed zero always available?

2016-06-22 Thread Michael Selik
On Wed, Jun 22, 2016 at 4:53 PM Christopher Reimer <
christopher_rei...@icloud.com> wrote:

> > On Jun 22, 2016, at 7:59 AM, Grant Edwards 
> wrote:
> >
> >> On 2016-06-22, Random832  wrote:
> >>> On Wed, Jun 22, 2016, at 10:19, Grant Edwards wrote:
> >>>
> >>> Is that guaranteed by Python, or just a side-effect of the
> >>> implementation?  Back in the days when Python used native C
> >>> integers I think the latter.
> >>
> >> AIUI, native C integers have never reliably supported signed zero
> >> even with representations that naively seem to have it. There's no
> >> well-defined way to detect it - no int version of copysign, for
> >> instance - and implementations are free to erase the distinction on
> >> every load/store or define one of them to be a trap representation.
> >
> > It's been almost 25 years since I used hardware that supported signed
> > zero integers (CDC 6600).  I don't recall there being a C compiler
> > available.  We used Pascal and assembly, though I think FORTRAN was
> > what most people used.  I don't recall whether the Pascal
> > implementation exposed the existence of -0 to the user or not.
>
> When I took mathematics in college, the following was true:
>
> -1 * 0 = 0
>
> I would probably have gotten rapped on the knuckles by my instructors if I
> answered -0. Zero was zero. No plus or minus about that. No discussion of
> signed integers ever mentioned signed zero.
>
> Did I miss something in college?
>

I can't remember where I came across the concept. It might have been in
calculus. Zero can be thought of as the asymptotic value of 1/n as n
approaches infinity. If so, then negative zero would be the asymptote of
-1/n as n approaches infinity.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Proposal: named return values through dict initialization and unpacking

2016-06-21 Thread Michael Selik
On Tue, Jun 21, 2016, 10:14 AM Terry Reedy  wrote:

> On 6/21/2016 3:34 AM, Ari Freund via Python-list wrote:
> > I'd like to run this idea by the community to see if it's PEP worthy and
> > hasn't been already rejected.
> >
> There was a recent (last couple of months?) discussion on python-ideas
> about dictionary unpacking.  It does not seem too practical.  But maybe
> you can find the thread
>

There were a few related threads. I wrote a module to handle what I thought
was the most important use case.

https://github.com/selik/destructure

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


Re: Method Chaining

2016-06-17 Thread Michael Selik
On Fri, Jun 17, 2016, 6:44 PM Michael Selik <michael.se...@gmail.com> wrote:

>
>
> On Fri, Jun 17, 2016, 6:42 PM Lawrence D’Oliveiro <lawrenced...@gmail.com>
> wrote:
>
>> On Saturday, June 18, 2016 at 1:35:06 AM UTC+12, Michael Selik wrote:
>>
>> > The chained version looks like each method is returning a modified
>> > copy.
>>
>> As opposed to a modified original?
>>
>
> Correct. Read the rationale for list.sort returning None. It's in the
> Python design FAQ.
>

Sorry, I should have included the link.

https://docs.python.org/2/faq/design.html#why-doesn-t-list-sort-return-the-sorted-list

Even if we're talking about a non-mutation side-effect, I think the same
rationale applies.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Method Chaining

2016-06-17 Thread Michael Selik
On Fri, Jun 17, 2016, 6:42 PM Lawrence D’Oliveiro <lawrenced...@gmail.com>
wrote:

> On Saturday, June 18, 2016 at 1:35:06 AM UTC+12, Michael Selik wrote:
>
> > The chained version looks like each method is returning a modified
> > copy.
>
> As opposed to a modified original?
>

Correct. Read the rationale for list.sort returning None. It's in the
Python design FAQ.

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


Re: Method Chaining

2016-06-17 Thread Michael Selik
On Fri, Jun 17, 2016 at 5:31 AM Steven D'Aprano  wrote:

> (g.move_to((p1 + p2a) / 2)
>   .line_to(p1 + (p2 - p1) * frac)
>   .line_to((p1 + p1a) / 2)
>   .stroke()
>   )
>
> the parens and indentation more clearly mark this chunk of code as a
> unit.


I prefer reserving indentation for where they're required ("for", "while",
"if", etc.). In this case, I'd use an extra blank line before and after.
Or, better, I'd move the chunk of code into a function by itself.

On the other hand, I like the fact that methods which are
> conceptually procedures that operate by side-effect return None.
>

Exactly. The chained version looks like each method is returning a modified
copy. The Pandas library isn't perfect, but it has a good consistency for
methods returning copies unless explicitly "inplace=True", in which case
the method returns None.

Paraphrasing Jakob's law of user experience [0], it doesn't matter if your
design is better. People are more familiar with the design of other
libraries and will expect yours to behave the same way: impure methods
return None, unless named "pop" or a similar standard.

[0] https://www.nngroup.com/articles/end-of-web-design/
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Method Chaining

2016-06-16 Thread Michael Selik
On Thu, Jun 16, 2016 at 10:53 PM Lawrence D’Oliveiro 
wrote:

> Example from ,
> concisely expressing a complex drawing sequence:
>
> (g
> .move_to((p1 + p2a) / 2)
> .line_to(p1 + (p2 - p1) * frac)
> .line_to((p1 + p1a) / 2)
> .stroke()
> .move_to((p2 + p2a) / 2)
> .line_to(p2 + (p1 - p2) * frac)
> .line_to((p2 + p1a) / 2)
> .stroke()
> )
>

Wouldn't that look nicer with the ``g`` repeated on every line, no extra
indentation, and no extraneous parentheses?

g.move_to((p1 + p2a) / 2)
g.line_to(p1 + (p2 - p1) * frac)
g.line_to((p1 + p1a) / 2)
g.stroke()
g.move_to((p2 + p2a) / 2)
g.line_to(p2 + (p1 - p2) * frac)
g.line_to((p2 + p1a) / 2)
g.stroke()

Sometimes it's hard to know when a function has a side-effect. I appreciate
that these impure functions tend to return None.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: for / while else doesn't make sense

2016-06-15 Thread Michael Selik
On Wed, Jun 15, 2016, 10:28 AM Rustom Mody  wrote:

> Where did the question of "break can be written as goto" come from?
>

Stephen said the "else" in for-else was "unconditional". He argued that
neither the presence nor absence of a break should be considered a
condition, because we don't consider the occurrence or non-occurrence of an
exception (goto) as a condition of whether to run the else-clause.

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


Re: for / while else doesn't make sense

2016-06-13 Thread Michael Selik
On Mon, Jun 13, 2016 at 10:46 PM Steven D'Aprano <st...@pearwood.info>
wrote:

> On Tue, 14 Jun 2016 09:45 am, Michael Selik wrote:
> > On Sun, Jun 12, 2016 at 10:16 PM Steven D'Aprano <st...@pearwood.info>
> > wrote:
> >> On Mon, 13 Jun 2016 04:44 am, Michael Selik wrote:
> >> > On Sun, Jun 12, 2016 at 6:11 AM Steven D'Aprano <
> >> > steve+comp.lang.pyt...@pearwood.info> wrote:
> >> >
> >> >> - run the for block
> >> >> - THEN unconditionally run the "else" block
> >> >>
> >> > Saying "unconditionally" is a bit misleading here. As you say, it's
> >> > conditioned on completing the loop without break/return/raise.
> >>
> >> It's also conditional on the OS not killing the Python process,
> >> conditional on the CPU not catching fire, conditional on the user not
> >> turning the power of, and conditional on the sun not exploding and
> >> disintegrating the entire earth.
> >>
> >> In the absence of any event which interferes with the normal execution
> of
> >> code by the Python VM, and in the absence of one of a very few
> >> explicit "JUMP" statements which explicitly jump out of the compound
> >> for...else statement, the else clause is unconditionally executed after
> >> the for clause.
>
> > Saying that ``raise``, ``break``, and ``return`` are "one of a very few
> > explicit JUMP statements" implies that they are obscure.
>
> What? No. How do you get that?
>

The context. That was right after a list of several (mostly) oddball
situations. In my experience, that pattern of speech is usually used to
imply that everything listed is also exceptionally strange.

There's a simple mental model, one which has the advantage of actually
> matching the implementation: for...else executes else unconditionally, ...
> If Python 3.6 introduces a GOTO command, then my mental model of
> for...else doesn't need to change.
>

That's a good explanation. The documentation says, "A break statement
executed in the first suite terminates the loop without executing the else
clause’s suite." Do you think that qualification of "without executing the
else clause" is unnecessary/redundant?

Regardless of the implementation, I think that explanation -- if break,
then skip the else-clause -- helps clarify the purpose.

https://docs.python.org/3/reference/compound_stmts.html#the-for-statement

else: # only if no break occurs
> and then I would feel guilty for lying, because that comment is not, in
> fact, correct. Returning out of the function from inside the loop will also
> avoid running the else part, as will an exception.
>

I absolve you of guilt! :-) If you had written, "guaranteed to run if no
break," then lawyers will come after you. If you had written "if and only
if" some mathematicians might complain. As you wrote it, it's actually true.

An "if and only if" logical statement has two parts: "if no break, run
else-clause" and "if break, do not run else-clause". As you say, the first
part is false. But you only made the latter claim.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Overriding methods inherited from a superclass with methods from a mixin

2016-06-13 Thread Michael Selik
On Mon, Jun 13, 2016 at 7:46 PM  wrote:

> I ... am making an effort to get used to the rtl order as quickly as
> possible.
>

Funny, you keep saying right-to-left. I think the issue is you think the
parent class is more important. Fight the power! Youth revolt! In Python,
the children are in control. Now you can read it left-to-right, as is
natural.

I feel somewhat bad about posting these links
>

The StackOverflow answer had an upvoted comment that the BaseRequest should
be written after the Mixins. The two blog posts read like conversation
starters. I don't think the authors intended to write model code.

A famous textbook getting it wrong would be more interesting. But even
Knuth makes mistakes (https://en.wikipedia.org/wiki/Knuth_reward_check).
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: for / while else doesn't make sense

2016-06-13 Thread Michael Selik
On Sun, Jun 12, 2016 at 10:16 PM Steven D'Aprano <st...@pearwood.info>
wrote:

> On Mon, 13 Jun 2016 04:44 am, Michael Selik wrote:
>
> > On Sun, Jun 12, 2016 at 6:11 AM Steven D'Aprano <
> > steve+comp.lang.pyt...@pearwood.info> wrote:
> >
> >> - run the for block
> >> - THEN unconditionally run the "else" block
> >>
> >
> > Saying "unconditionally" is a bit misleading here. As you say, it's
> > conditioned on completing the loop without break/return/raise.
>
> It's also conditional on the OS not killing the Python process, conditional
> on the CPU not catching fire, conditional on the user not turning the power
> of, and conditional on the sun not exploding and disintegrating the entire
> earth.
>
> In the absence of any event which interferes with the normal execution of
> code by the Python VM, and in the absence of one of a very few
> explicit "JUMP" statements which explicitly jump out of the compound
> for...else statement, the else clause is unconditionally executed after the
> for clause.
>
> Happy now?
>

I think most folks assume that their program will not run as expected if
the sun explodes.

Saying that ``raise``, ``break``, and ``return`` are "one of a very few
explicit JUMP statements" implies that they are obscure. Listing them in
addition to the sun exploding suggests that you think they are similarly
unlikely and should be ignored as too bizarre to consider.

In contrast, I think raise, break, and return are quite common. Further, I
think you do too, despite what you are trying to imply. Maybe I read the
tone wrong. It's tough sometimes to hear someone's tone of voice in email.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Overriding methods inherited from a superclass with methods from a mixin

2016-06-13 Thread Michael Selik
On Mon, Jun 13, 2016 at 2:46 PM  wrote:

> Thank you for your replies. I don't know if I'm quoting you correctly, I'm
> quite confused with Google Groups... not sure if it's a "forum", something
> like a mailing list, or both... or neither.
>

Mailing list. A "forum" in the metaphorical sense, not the sense of phpBB.
You're doing fine with quoting, though it would help to add who said what
when quoting multiple people.

since the correct order is from right to left,


Did you mean left-to-right?
Are you thinking of Java where there's only one parent class allowed and
you specify any extra interfaces you're implementing afterwards? Because
that's not what your code is doing.

Still, pretty much *no one* uses that order [mixin1, mixin2, base]. A quick
> Google search returns (at least in my "bubble") many blog articles from
> "notable" Python users with that order wrong.
>

Do you mind providing links? I haven't seen anyone "notable" make this
mistake.


> > To me it makes sense. English reads left-to-right, so method
>
> lookups go left-to-right (and children before parents) in the inheritance
> > list.
>
> Basically I wasn't very confident the code was OK because my intuition
> said the right way to order the classes I was inheriting from was from left
> to right.


That is correct! Write them in the order you are prioritizing the
definitions. Overrides before bases, left to right.


> I don't see any sense in that analogy you made... sure English and most
> occidental languages read ltr, but I fail to see how it makes more sense to
> have the base class on the right and the mixins on the left. Basically, I
> think of the mixins like plugins of kinds, I'm "adding" functionality to
> that "base" class I'm inheriting from.


That's not a good metaphor for what's actually happening. For more detail,
check out Raymond's "super considered super" video (
https://www.youtube.com/watch?v=EiOglTERPEo).


> Don't take my word for it, Google multi inheritance or mixin in Python and
> let me know if you find someone who thinks it's "natural" to do it that way.


This might be a bit of selection bias. People who think it makes sense
might not have an incentive to write a blog post about it. People who don't
like it will thus be more vocal.

Ian Lewis seems to be ranked highly by Google (
https://www.ianlewis.org/en/mixins-and-python).
I disagree with his assertion that "most people" read an inheritance
hierarchy top-down with the bases at the left. I think of inheritance as a
tree. Even if it is a diamond at some point, a depth-first-search of a tree
isn't far off from the truth. The root (base) is at the bottom, in my mind,
and the leaves are at the top.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Conversion: execfile --> exec

2016-06-13 Thread Michael Selik
On Mon, Jun 13, 2016 at 1:51 PM Rustom Mody  wrote:

> looks (to me) like an intent to import the package chaco with no locals
> and globals -- Just guessing of course
>

And without creating a module object. I suppose that means it doesn't get
cached in sys.modules either. Not sure if that's a feature or a bug.
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Overriding methods inherited from a superclass with methods from a mixin

2016-06-13 Thread Michael Selik
On Mon, Jun 13, 2016 at 12:01 AM  wrote:

> I haven't used Python for some time so I don't feel confident to judge
>

Yet, you are clearly judging the code you pasted as not OK.

Perhaps you guys could help me either convincing me that the bpaste code is
> OK
>

It would be helpful for you to explain why you think the code you pasted is
not OK. To me it makes sense. English reads left-to-right, so method
lookups go left-to-right (and children before parents) in the inheritance
list.
-- 
https://mail.python.org/mailman/listinfo/python-list


  1   2   >