Re: [Python-Dev] (no subject)

[Ian Lee]

+1 for adding "+" or "|" operator for merging dicts. To me this operation:

>>> {'x': 1, 'y': 2} + {'z': 3}
{'x': 1, 'y': 2, 'z': 3}

Is very clear.  The only potentially non obvious case I can see then is
when there are duplicate keys, in which case the syntax could just be
defined that last setter wins, e.g.:

>>> {'x': 1, 'y': 2} + {'x': 3}
{'x': 3, 'y': 2}

Which is analogous to the example:

new_dict = dict1.copy()
new_dict.update(dict2)


~ Ian Lee

On Tue, Feb 10, 2015 at 12:11 AM, Serhiy Storchaka 
wrote:

> On 10.02.15 04:06, Ethan Furman wrote:
>
>>  return func(*(args + fargs), **{**keywords, **fkeywords})
>>
>
> We don't use [*args, *fargs] for concatenating lists, but args + fargs.
> Why not use "+" or "|" operators for merging dicts?
>
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> ianlee1521%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] (no subject)

[Ian Lee]

I split off a separate thread on python-ideas [1] specific to the idea of
introducing "+" and "+=" operators on a dict.

[1] https://mail.python.org/pipermail/python-ideas/2015-February/031748.html


~ Ian Lee

On Tue, Feb 10, 2015 at 10:35 PM, John Wong  wrote:

>
>
> On Wed, Feb 11, 2015 at 12:35 AM, Ian Lee  wrote:
>
>> +1 for adding "+" or "|" operator for merging dicts. To me this operation:
>>
>> >>> {'x': 1, 'y': 2} + {'z': 3}
>> {'x': 1, 'y': 2, 'z': 3}
>>
>> Is very clear.  The only potentially non obvious case I can see then is
>> when there are duplicate keys, in which case the syntax could just be
>> defined that last setter wins, e.g.:
>>
>> >>> {'x': 1, 'y': 2} + {'x': 3}
>> {'x': 3, 'y': 2}
>>
>> Which is analogous to the example:
>>
>> new_dict = dict1.copy()
>> new_dict.update(dict2)
>>
>>
>> Well looking at just list
> a + b yields new list
> a += b yields modified a
> then there is also .extend in list. etc.
>
> so do we want to follow list's footstep? I like + because + is more
> natural to read. Maybe this needs to be a separate thread. I am actually
> amazed to remember dict + dict is not possible... there must be a reason
> (performance??) for this...
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] some minor questions about pep8

[Ian Lee]

Guido,

In that case would you be open to a patch to update the PEP accordingly?

Additionally, does that official statement cover other dunder assignments
(e.g. "__author__"?). If so I'll update the PEP8 tool accordingly.

Thanks,

~ Ian Lee
On Mar 20, 2015 8:55 PM, "Guido van Rossum"  wrote:

> FWIW, I think __version__, __author__ etc. were bad ideas. Almost nobody
> manages these correctly. Note that the PEP 8 section starts with less than
> an endorsement: "If you *have* to have Subversion, CVS, or RCS crud in
> your source file, do it as follows."
>
> That said, if an official answer is required, common sense would suggest
> that __version__ should go before the imports. (I would put it before the
> docstring too, except then the docstring wouldn't be a docstring any more.
> Go figure.)
>
> On Fri, Mar 20, 2015 at 6:38 PM, Ben Finney 
> wrote:
>
>> Lewis Coates  writes:
>>
>> > In pep8 there are two conflicting statements, both
>> >
>> > https://www.python.org/dev/peps/pep-0008/#version-bookkeeping
>> > https://www.python.org/dev/peps/pep-0008/#imports
>> >
>> > Stipulate that they should be "at the top of the file after any module
>> > comments and docstrings." Which of these takes precedence?
>>
>> I don't know an official answer. The convention I've observed is
>> overwhelmingly in one direction: import statements come before any
>> assignment statements.
>>
>> > Secondly, we also have an "__author__", and "__project__" variables, I
>> > assume these would be put with the version information as well?
>>
>> Yes.
>>
>> --
>>  \ “Welchen Teil von ‘Gestalt’ verstehen Sie nicht?  [What part of |
>>   `\‘gestalt’ don't you understand?]” —Karsten M. Self |
>> _o__)  |
>> Ben Finney
>>
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/ianlee1521%40gmail.com
>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] some minor questions about pep8

[Ian Lee]

FWIW, I would vote for the "__version__", "__author__", etc assignments
being after the imports. Reason being cases where the "__version__" is not
from VCS, but is calculated from pkg_resources:

from pkg_resources import get_distribution
__version__ = get_distribution('mypackage').version

Also, then more useful things like "__all__" (which can very reasonably
rely on imports), can be together with "__version__" and "__author__"
assignments.

I would vote:

shebang
docstring
imports
dunder assignments
other code...





~ Ian Lee

On Fri, Mar 20, 2015 at 9:24 PM, Ian Lee  wrote:

> Guido,
>
> In that case would you be open to a patch to update the PEP accordingly?
>
> Additionally, does that official statement cover other dunder assignments
> (e.g. "__author__"?). If so I'll update the PEP8 tool accordingly.
>
> Thanks,
>
> ~ Ian Lee
> On Mar 20, 2015 8:55 PM, "Guido van Rossum"  wrote:
>
>> FWIW, I think __version__, __author__ etc. were bad ideas. Almost nobody
>> manages these correctly. Note that the PEP 8 section starts with less than
>> an endorsement: "If you *have* to have Subversion, CVS, or RCS crud in
>> your source file, do it as follows."
>>
>> That said, if an official answer is required, common sense would suggest
>> that __version__ should go before the imports. (I would put it before the
>> docstring too, except then the docstring wouldn't be a docstring any more.
>> Go figure.)
>>
>> On Fri, Mar 20, 2015 at 6:38 PM, Ben Finney 
>> wrote:
>>
>>> Lewis Coates  writes:
>>>
>>> > In pep8 there are two conflicting statements, both
>>> >
>>> > https://www.python.org/dev/peps/pep-0008/#version-bookkeeping
>>> > https://www.python.org/dev/peps/pep-0008/#imports
>>> >
>>> > Stipulate that they should be "at the top of the file after any module
>>> > comments and docstrings." Which of these takes precedence?
>>>
>>> I don't know an official answer. The convention I've observed is
>>> overwhelmingly in one direction: import statements come before any
>>> assignment statements.
>>>
>>> > Secondly, we also have an "__author__", and "__project__" variables, I
>>> > assume these would be put with the version information as well?
>>>
>>> Yes.
>>>
>>> --
>>>  \ “Welchen Teil von ‘Gestalt’ verstehen Sie nicht?  [What part of |
>>>   `\‘gestalt’ don't you understand?]” —Karsten M. Self |
>>> _o__)  |
>>> Ben Finney
>>>
>>> ___
>>> Python-Dev mailing list
>>> Python-Dev@python.org
>>> https://mail.python.org/mailman/listinfo/python-dev
>>> Unsubscribe:
>>> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>>>
>>
>>
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>>
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/ianlee1521%40gmail.com
>>
>>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Very old git mirror under github user "python-git"

[Ian Lee]

> On Feb 27, 2016, at 14:21, Alexander Walters  wrote:
> 
> Can we even ask github to pull it down and reasonably expect them to comply?  
> Their entire model is built on everyone forking everyone else.

As a data point — I had a pretty good experience with GitHub helping me out 
when I was trying to reclaim an organization using my company name. In that 
case it turned out that they just gave me the contact for the person and I 
worked it out from there, but it’d seemed like they were willing to take a 
more… forceful approach if it was needed.

Perhaps the better / easier solution is to promote the *real* “Sem-official 
read-only mirror of the Python Mercurial repository” [1] ? And perhaps this 
goes away entirely (in time) with PEP-512 [2]?

[1] https://github.com/python/cpython 
[2] https://www.python.org/dev/peps/pep-0512/ 
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 updated on whether to break before or after a binary update

[Ian Lee]

Cross posting the comment I’d left on the issue [1].

> My preference is to actually break that logic up and avoid the wrapping in 
> the first place, as in [2]. Which in this particular class has the side 
> benefit of that value being used again in the same function anyways.

> I'm starting to realize that Brandon Rhodes really had a big impact on my 
> ideas of styling as I've been learning Python these past few years, as this 
> was another one style I'm stealing from that same talk [3].

[1] http://bugs.python.org/msg263509 <http://bugs.python.org/msg263509>
[2] 
https://github.com/python/peps/commit/0c790e7b721bd13ad12ab9e6f6206836f398f9c4

~ Ian Lee | ianlee1...@gmail.com <mailto:ianlee1...@gmail.com>
> On Apr 15, 2016, at 10:49, MRAB  wrote:
> 
> On 2016-04-15 18:03, Victor Stinner wrote:
> > Hum.
> >
> >  if (width == 0
> >  and height == 0
> >  and color == 'red'
> >  and emphasis == 'strong'
> >  or highlight > 100):
> >  raise ValueError("sorry, you lose")
> >
> > Please remove one space to vertically align "and" operators with the
> > opening parenthesis:
> >
> >  if (width == 0
> > and height == 0
> > and color == 'red'
> > and emphasis == 'strong'
> > or highlight > 100):
> >  raise ValueError("sorry, you lose")
> >
> > (I'm not sure that the difference is obvious in a mail client, you
> > need a fixed width font which is not the case in my Gmail editor.)
> >
> > It helps to visually see that the multiline test and the raise
> > instruction are in two different blocks.
> >
> > (Moreover, the pep8 checks of OpenStack simply reject such syntax, but
> > I cannot use this syntax anymore :-))
> >
> I always half-indent continuation lines:
> 
>if (width == 0
>  and height == 0
>  and color == 'red'
>  and emphasis == 'strong'
>  or highlight > 100):
>raise ValueError("sorry, you lose")
> ___
> Python-Dev mailing list
> Python-Dev@python.org <mailto:Python-Dev@python.org>
> https://mail.python.org/mailman/listinfo/python-dev 
> <https://mail.python.org/mailman/listinfo/python-dev>
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/ianlee1521%40gmail.com 
> <https://mail.python.org/mailman/options/python-dev/ianlee1521%40gmail.com>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com