[Python-ideas] Python-ideas Digest, Vol 117, Issue 13
Arek Bulski
arek.bulski at gmail.com
Tue Aug 2 11:11:58 EDT 2016
I am moving the discussion on file-like methods to GitHub. Mailing list is
not very usable IMHO. Please switch to that.
https://github.com/python/peps/issues/66
pozdrawiam,
Arkadiusz Bulski
2016-08-02 7:02 GMT+02:00 <python-ideas-request at python.org>:
> Send Python-ideas mailing list submissions to
> python-ideas at python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.python.org/mailman/listinfo/python-ideas
> or, via email, send a message with subject or body 'help' to
> python-ideas-request at python.org
>
> You can reach the person managing the list at
> python-ideas-owner at python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Python-ideas digest..."
>
>
> Today's Topics:
>
> 1. Re: Trial balloon: adding variable type declarations in
> support of PEP 484 (Steven D'Aprano)
> 2. Re: Trial balloon: adding variable type declarations in
> support of PEP 484 (Steven D'Aprano)
> 3. Re: Proposing new file-like object methods (eryk sun)
> 4. Re: Trial balloon: adding variable type declarations in
> support of PEP 484 (Guido van Rossum)
> 5. Re: Trial balloon: adding variable type declarations in
> support of PEP 484 (Guido van Rossum)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 2 Aug 2016 12:55:09 +1000
> From: Steven D'Aprano <steve at pearwood.info>
> To: python-ideas at python.org
> Subject: Re: [Python-ideas] Trial balloon: adding variable type
> declarations in support of PEP 484
> Message-ID: <20160802025509.GD6608 at ando.pearwood.info>
> Content-Type: text/plain; charset=us-ascii
>
> On Mon, Aug 01, 2016 at 02:31:16PM -0700, Guido van Rossum wrote:
> > PEP 484 doesn't change Python's syntax. Therefore it has no good
> > syntax to offer for declaring the type of variables, and instead you
> > have to write e.g.
> >
> > a = 0 # type: float
> > b = [] # type: List[int]
> > c = None # type: Optional[str]
> >
> > I'd like to address this in the future, and I think the most elegant
> > syntax would be to let you write these as follows:
> >
> > a: float = 0
> > b: List[int] = []
> > c: Optional[str] = None
>
>
> Those examples look reasonable to me.
>
>
> [...]
> > Second, when these occur in a class body, they can define either class
> > variables or instance variables. Do we need to be able to specify
> > which?
>
> I would think so. Consider the case that you have Class.spam and
> Class().spam which may not be the same type. E.g. the class attribute
> (representing the default value used by all instances) might be a
> mandatory int, while the instance attribute might be Optional[int].
>
>
> > Third, there's an annoying thing with tuples/commas here. On the one
> > hand, in a function declaration, we may see (a: int = 0, b: str = '').
> > On the other hand, in an assignment, we may see
> >
> > a, b = 0, ''
> >
> > Suppose we wanted to add types to the latter. Would we write this as
> >
> > a, b: int, str = 0, ''
> >
> > or as
> >
> > a: int, b: str = 0, ''
>
> Require parens around the name:hint.
>
> (a:int), (b:str) = 0, ''
>
> Or just stick to a type hinting comment :-)
>
>
> What about this case?
>
> spam, eggs = [1, 2.0, 'foo'], (1, '')
> [a, b, c], [d, e] = spam, eggs
>
> That becomes:
>
> [(a:int), (b:float), (c:str)], [(x:int), (y:str)] = spam, eggs
>
> which is bearable, but just unpleasant enough to discourage people from
> doing it unless they really need to.
>
>
> --
> Steve
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 2 Aug 2016 12:57:12 +1000
> From: Steven D'Aprano <steve at pearwood.info>
> To: python-ideas at python.org
> Subject: Re: [Python-ideas] Trial balloon: adding variable type
> declarations in support of PEP 484
> Message-ID: <20160802025711.GE6608 at ando.pearwood.info>
> Content-Type: text/plain; charset=us-ascii
>
> On Tue, Aug 02, 2016 at 07:40:39AM +1000, Chris Angelico wrote:
>
> > Additional case, unless it's patently obvious to someone with more 484
> > experience than I: what happens with chained assignment?
> >
> > a = b = c = 0
> >
> > Does each variable get separately tagged, or does one tag apply to all?
>
> (a:int) = (b:Optional[int]) = c = 0
>
> `a` is declared to always be an int, `b` declared to be an int or None,
> and `c` is not declared.
>
>
>
> --
> Steve
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 2 Aug 2016 04:33:53 +0000
> From: eryk sun <eryksun at gmail.com>
> To: python-ideas at python.org
> Subject: Re: [Python-ideas] Proposing new file-like object methods
> Message-ID:
> <
> CACL+1au+bX_tKQvxDJC1SBLSObKbqAUPjj9dpmcr9s1izq0Cng at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Tue, Aug 2, 2016 at 2:00 AM, Random832 <random832 at fastmail.com> wrote:
> > On Mon, Aug 1, 2016, at 20:27, Wes Turner wrote:
> >> file.pread?
> >
> > Wouldn't that be rather like having os.fstatat?
> >
> > For the concept in general, I'm concerned that the equivalent
> > functionality on windows may require that the I/O be done
> > asynchronously, or that the file have been opened in a special
> > way.
>
> Updating the file position is all or nothing. In synchronous mode,
> which is what the CRT's low I/O implementation uses, the file position
> is always updated. However, one can atomically set the file position
> before a read by passing an overlapped with an offset to ReadFile,
> which in turn sets the ByteOffset argument of the underlying
> NtReadFile [1] system call.
>
> [1]: https://msdn.microsoft.com/en-us/library/ff567072
>
> For example:
>
> import _winapi
> import ctypes
> from ctypes import wintypes
>
> kernel32 = ctypes.WinDLL('kernel32', use_last_error=True)
>
> ULONG_PTR = wintypes.WPARAM
>
> class OVERLAPPED(ctypes.Structure):
> class _OFF_PTR(ctypes.Union):
> class _OFFSET(ctypes.Structure):
> _fields_ = (('Offset', wintypes.DWORD),
> ('OffsetHigh', wintypes.DWORD))
> _fields_ = (('_offset', _OFFSET),
> ('Pointer', wintypes.LPVOID))
> _anonymous_ = ('_offset',)
> _fields_ = (('Internal', ULONG_PTR),
> ('InternalHigh', ULONG_PTR),
> ('_off_ptr', _OFF_PTR),
> ('hEvent', wintypes.HANDLE))
> _anonymous_ = ('_off_ptr',)
>
> with open('test.txt', 'wb') as f:
> f.write(b'0123456789')
>
> h = _winapi.CreateFile('test.txt', 0x80000000, 3, 0, 3, 0, 0)
> buf = (ctypes.c_char * 5)()
> n = (wintypes.DWORD * 1)()
> fp = (wintypes.LARGE_INTEGER * 1)()
>
> ov = (OVERLAPPED * 1)()
> ov[0].Offset = 5
>
>
> >>> kernel32.ReadFile(h, buf, 5, n, ov)
> 1
> >>> buf[:]
> b'56789'
> >>> kernel32.SetFilePointerEx(h, 0, fp, 1)
> 1
> >>> fp[0]
> 10
>
> Note that after reading 5 bytes at an offset of 5, the current file
> position is 10. With pread() it would still be at 0. The file position
> can be tracked and set atomically before each read or write, but I
> don't think this is practical unless it's part of a larger project to
> use the Windows API directly.
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 1 Aug 2016 21:57:12 -0700
> From: Guido van Rossum <guido at python.org>
> To: "Steven D'Aprano" <steve at pearwood.info>
> Cc: Python-Ideas <python-ideas at python.org>
> Subject: Re: [Python-ideas] Trial balloon: adding variable type
> declarations in support of PEP 484
> Message-ID:
> <
> CAP7+vJJLz2wRPpkrtb8j8v7vTRFqjbw_b4a5pwAv0-5HyKNf4w at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> The parentheses really strike me as too much complexity. You should
> just split it up into multiple lines, or use a semicolon.
>
> On Mon, Aug 1, 2016 at 7:57 PM, Steven D'Aprano <steve at pearwood.info>
> wrote:
> > On Tue, Aug 02, 2016 at 07:40:39AM +1000, Chris Angelico wrote:
> >
> >> Additional case, unless it's patently obvious to someone with more 484
> >> experience than I: what happens with chained assignment?
> >>
> >> a = b = c = 0
> >>
> >> Does each variable get separately tagged, or does one tag apply to all?
> >
> > (a:int) = (b:Optional[int]) = c = 0
> >
> > `a` is declared to always be an int, `b` declared to be an int or None,
> > and `c` is not declared.
> >
> >
> >
> > --
> > Steve
> > _______________________________________________
> > Python-ideas mailing list
> > Python-ideas at python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 1 Aug 2016 22:02:33 -0700
> From: Guido van Rossum <guido at python.org>
> To: "Steven D'Aprano" <steve at pearwood.info>
> Cc: Python-Ideas <python-ideas at python.org>
> Subject: Re: [Python-ideas] Trial balloon: adding variable type
> declarations in support of PEP 484
> Message-ID:
> <
> CAP7+vJJHYLwzbnOqrbqD3vboktXG-Rp+8n-MYxm8uf_Ge2m_yQ at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Regarding class variables: in my experience instance variables way
> outnumber class variables, except when the latter are used as defaults
> for instance variables.
>
> See e.g. this bit of code from mypy (and many others, actually):
> https://github.com/python/mypy/blob/master/mypy/nodes.py#L154. All of
> these declare instance variables. Many of them have no need for a
> default in the class, but must give one anyway or else there's nothing
> to put the type comment on -- you can't write
>
> defs # type: List[Statement]
>
> (it would be a NameError) and you certainly don't want to write
>
> defs = [] # type: List[Statement]
>
> (else the gods of shared mutable state will curse you) so you have to
> make do with
>
> defs = None # type: List[Statement]
>
> But this would be totally reasonable as
>
> defs: List[Statement]
>
> under my proposal.
>
> On Mon, Aug 1, 2016 at 7:55 PM, Steven D'Aprano <steve at pearwood.info>
> wrote:
> > On Mon, Aug 01, 2016 at 02:31:16PM -0700, Guido van Rossum wrote:
> >> PEP 484 doesn't change Python's syntax. Therefore it has no good
> >> syntax to offer for declaring the type of variables, and instead you
> >> have to write e.g.
> >>
> >> a = 0 # type: float
> >> b = [] # type: List[int]
> >> c = None # type: Optional[str]
> >>
> >> I'd like to address this in the future, and I think the most elegant
> >> syntax would be to let you write these as follows:
> >>
> >> a: float = 0
> >> b: List[int] = []
> >> c: Optional[str] = None
> >
> >
> > Those examples look reasonable to me.
> >
> >
> > [...]
> >> Second, when these occur in a class body, they can define either class
> >> variables or instance variables. Do we need to be able to specify
> >> which?
> >
> > I would think so. Consider the case that you have Class.spam and
> > Class().spam which may not be the same type. E.g. the class attribute
> > (representing the default value used by all instances) might be a
> > mandatory int, while the instance attribute might be Optional[int].
> >
> >
> >> Third, there's an annoying thing with tuples/commas here. On the one
> >> hand, in a function declaration, we may see (a: int = 0, b: str = '').
> >> On the other hand, in an assignment, we may see
> >>
> >> a, b = 0, ''
> >>
> >> Suppose we wanted to add types to the latter. Would we write this as
> >>
> >> a, b: int, str = 0, ''
> >>
> >> or as
> >>
> >> a: int, b: str = 0, ''
> >
> > Require parens around the name:hint.
> >
> > (a:int), (b:str) = 0, ''
> >
> > Or just stick to a type hinting comment :-)
> >
> >
> > What about this case?
> >
> > spam, eggs = [1, 2.0, 'foo'], (1, '')
> > [a, b, c], [d, e] = spam, eggs
> >
> > That becomes:
> >
> > [(a:int), (b:float), (c:str)], [(x:int), (y:str)] = spam, eggs
> >
> > which is bearable, but just unpleasant enough to discourage people from
> > doing it unless they really need to.
> >
> >
> > --
> > Steve
> > _______________________________________________
> > Python-ideas mailing list
> > Python-ideas at python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
>
>
> ------------------------------
>
> End of Python-ideas Digest, Vol 117, Issue 13
> *********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160802/af0f178e/attachment-0001.html>
More information about the Python-ideas
mailing list