Re: [Python-Dev] PEP 7 contradiction for comment style

[Benjamin Peterson]

Your assumption is correct. Perhaps the PEP 7 should be partitioned into
"< 3.6" and "3.6" sections where applicable.

On Mon, Jan 9, 2017, at 12:50, Brett Cannon wrote:
> https://bugs.python.org/issue29215 noticed that PEP 7 says "C++-style
> line
> comments" are allowed, but then later says "Never use C++ style //
> one-line
> comments." I'm assuming we are sticking with allowing C++-style comments
> and the "never" link just needs an addendum to say that only applies to
> code prior to Python 3.5, but I wanted to double-check before editing the
> PEP.
> ___
> 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/benjamin%40python.org
___
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

[Python-Dev] PEP 7 contradiction for comment style

[Brett Cannon]

https://bugs.python.org/issue29215 noticed that PEP 7 says "C++-style line
comments" are allowed, but then later says "Never use C++ style // one-line
comments." I'm assuming we are sticking with allowing C++-style comments
and the "never" link just needs an addendum to say that only applies to
code prior to Python 3.5, but I wanted to double-check before editing the
PEP.
___
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] enable-framework Vs. Naught

[Chris Barker - NOAA Federal]

> This list is for development of furture releases.  Questions about using 
> current releases should go to python-list, Stackoverflow, or other help 
> forums.

The python-Mac SIG would be a good one for this.

CHB

>
> --
> Terry Jan Reedy
>
>
> ___
> 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/chris.barker%40noaa.gov
___
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] Adding bytes.frombuffer() constructor to PEP 467

[Chris Barker - NOAA Federal]

>   This is what happens with numpy arrays:
>
> >>> bytes(numpy.array([2], 'i1'))
> b'\x00\x00'
>
> >>> bytes(numpy.array([2, 2], 'i1'))
> b'\x02\x02'
>
> For better or worse, single-element numpy arrays have a working __index__ 
> methods

Ouch -- that probably is for the worse..

There are Numpy scalars that should be used for that.


> 1. For 3.6, restore and document 3.5 behavior.  Recommend that 3rd party 
> types that are both integer-like and buffer-like implement their own 
> __bytes__ method to resolve the bytes(x) ambiguity.

+1 -- though the default should be clear if there isn't one.

> 2.1.  Accept only objects with a __bytes__ method or a sequence of ints in 
> range(256).

If frombuffer() is added, then yes.

> 2.2.  Expand __bytes__ definition to accept optional encoding and errors 
> parameters.  Implement str.__bytes__(self, [encoding[, errors]]).

Ouch! I understand the desire to keep a simple API -- but I think
encoding clearly belongs with the strong object. What's wrong with:

s.encode() ?

IIUC, the ONLY object one could possibly encode anyway is a string -
'cause you have to know the internal representation. So bytes() would
simply be passing the encoding info off to the string anyway ( or
other object with and encode method).

> 2.3.  Implement new specialized bytes.fromsize and bytes.frombuffer 
> constructors as per PEP 467 and Inada Naoki proposals.

Maybe not important -- but nice to have a obvious and perform any way
to do it. ( does this proposal allow an initializing value?).

For prior art, Numpy has:

zeros()
ones()
empty()

And I would like to see an explicit frombuffer() constructor. See
others' notes about how using an intermediary memoryview is not
obvious and straightforward.

-CHB
___
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] Imports with underscores

[Chris Barker]

On Mon, Jan 9, 2017 at 12:29 PM, Terry Reedy  wrote:

> The tkinter doc still has
>
> ...to use Tkinter all you need is a simple import statement:
>   import tkinter
> Or, more often:
>   from tkinter import *
>
> Should this be changed?
>

yes, it should.

I would suggest suggesting something like:

import tkinter as tk

following the similar convention of wxPython, numpy, matplotlib, (all
large widely used packages that started their lives with import *
recommendations...)

-CHB




-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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