Re: [Python-Dev] Reminder: 12 weeks to 3.7 feature code cutoff

2017-11-03 Thread Lele Gaifax 
Terry Reedy  writes:

> On 11/2/2017 4:54 AM, Lele Gaifax wrote:
>
>> I'm not sure if the rebase should have been done on the original branch
>> instead of creating a new one, or instead if I should open a new PR (and
>> close the original one?).
>
> It is normal to 'git merge upstream/master' after updating the master branch
> and checking out the pr branch, and then push the updated branch. I
> sometimes have to do that when reviewing a pr.  Often, for me, the problem
> is not merge conflicts, but re version conflicts.  However, if there are
> merge conflicts that make it easier to reproduce the patch from the current
> master, closing and opening a new PR is ok too.

There was one major conflict, due to the NEWS->blurb transition, and to fix
that I rebased the patchset onto the (at the time) current master removing one
commit and recording a new one with a proper NEWS.d entry. It seemed correct
to me pushing the result into a different branch of my own GH fork, and to
stick a note about the fact in the PR, asking about the preferred workflow:
since a few people already reviewed the code, I didn't feel right in
overwriting that history (I still don't know how GH behave when one
force-pushes a different history in a branch already tracked by a PR).

In the end, I closed the original PR#377 and opened a new
https://github.com/python/cpython/pull/4238.

I need some hint on how to solve a compilation issue on Windows, as I didn't
find a portable wrapper interface to the unlink(2) system call: when the
backup fails the code wants to remove the possibly corrupted/incomplete
external file, but apparently the  header is not present on that
system so I explicitly declared the unlink() function as done for example by
Modules/posixmodule.c, but does not seem the right solution.

Thanks in advance,
ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
[email protected]  | -- Fortunato Depero, 1929.

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Reorganizing re and curses related code

2017-11-03 Thread Serhiy Storchaka 
Currently the implementation of re and curses related modules is sparsed 
over several files:


re:
Lib/re.py
Lib/sre_compile.py
Lib/sre_constants.py
Lib/sre_parse.py

_sre:

Modules/_sre.c
Modules/sre_constants.h
Modules/sre.h
Modules/sre_lib.h

_curses:
Include/py_curses.h
Modules/_cursesmodule.c
Modules/_curses_panel.c

I want to make the re module a package, and move sre_*.py files into it. 
Maybe later I'll add the sre_optimize.py file for separating 
optimization from parsing and compiling to an internal code. The 
original sre_*.py files will be left for compatibility for long time, 
but they will just import their content from the re package.


_sre implementation will be moved into the Modules/_sre/ directory. This 
will just make them to be in one place and will decrease the number of 
files in the Modules/ directory.


The implementations of the _curses and _curses_panel modules together 
with the common header file will be moved into the Modules/_curses/ 
directory. Excluding py_curses.h from the set of global headers will 
increase the speed of rebuilding when modify just the _curses 
implementation (I did this too much recent times). In future the 
implementation of menu and forms extensions will be added (the patch for 
menu has beed provided years ago). Since _cursesmodule.c is one of the 
largest file (it defines hundreds of functions), it may be worth to 
extract the implementation of the _curses.window class into a separate 
file. And I want to implement the support of "soft function-key labels". 
All this will increase the number of _curses related files to 7.


curses already is a package.

Since virtually all changes in these files at recent years have been 
made by me, I don't think this will harm other core developers. Are 
there any objections?


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Reorganizing re and curses related code

2017-11-03 Thread Antoine Pitrou 

Sounds good to me :-)

Regards

Antoine.


On Fri, 3 Nov 2017 12:01:28 +0200
Serhiy Storchaka  wrote:
> Currently the implementation of re and curses related modules is sparsed 
> over several files:
> 
> re:
>  Lib/re.py
>  Lib/sre_compile.py
>  Lib/sre_constants.py
>  Lib/sre_parse.py
> 
> _sre:
> 
>  Modules/_sre.c
>  Modules/sre_constants.h
>  Modules/sre.h
>  Modules/sre_lib.h
> 
> _curses:
>  Include/py_curses.h
>  Modules/_cursesmodule.c
>  Modules/_curses_panel.c
> 
> I want to make the re module a package, and move sre_*.py files into it. 
> Maybe later I'll add the sre_optimize.py file for separating 
> optimization from parsing and compiling to an internal code. The 
> original sre_*.py files will be left for compatibility for long time, 
> but they will just import their content from the re package.
> 
> _sre implementation will be moved into the Modules/_sre/ directory. This 
> will just make them to be in one place and will decrease the number of 
> files in the Modules/ directory.
> 
> The implementations of the _curses and _curses_panel modules together 
> with the common header file will be moved into the Modules/_curses/ 
> directory. Excluding py_curses.h from the set of global headers will 
> increase the speed of rebuilding when modify just the _curses 
> implementation (I did this too much recent times). In future the 
> implementation of menu and forms extensions will be added (the patch for 
> menu has beed provided years ago). Since _cursesmodule.c is one of the 
> largest file (it defines hundreds of functions), it may be worth to 
> extract the implementation of the _curses.window class into a separate 
> file. And I want to implement the support of "soft function-key labels". 
> All this will increase the number of _curses related files to 7.
> 
> curses already is a package.
> 
> Since virtually all changes in these files at recent years have been 
> made by me, I don't think this will harm other core developers. Are 
> there any objections?
> 



___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Reorganizing re and curses related code

2017-11-03 Thread Nick Coghlan 
On 3 November 2017 at 20:01, Serhiy Storchaka  wrote:
>
> Since virtually all changes in these files at recent years have been made by
> me, I don't think this will harm other core developers. Are there any
> objections?

Sound fine to me (and you may want to add an underscore prefix to the
sre_*.py files in their new home).

The one caveat I'll note is that this may limit automatic backporting
of fixes to this files (I'm not sure how good 'git cherry-pick' is at
handling file renames).

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Reorganizing re and curses related code

2017-11-03 Thread Serhiy Storchaka 

03.11.17 12:29, Nick Coghlan пише:

On 3 November 2017 at 20:01, Serhiy Storchaka  wrote:


Since virtually all changes in these files at recent years have been made by
me, I don't think this will harm other core developers. Are there any
objections?


Sound fine to me (and you may want to add an underscore prefix to the
sre_*.py files in their new home).

The one caveat I'll note is that this may limit automatic backporting
of fixes to this files (I'm not sure how good 'git cherry-pick' is at
handling file renames).


I'm aware of this and tried to fix all known bugs (which can't be 
classified as a lack of a feature) in these modules before doing this 
change. There are two old bugs left in _sre, but they don't have fixes yet.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Reminder: 12 weeks to 3.7 feature code cutoff

2017-11-03 Thread Guido van Rossum 
Maybe we should remove typing from the stdlib?
https://github.com/python/typing/issues/495

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
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 563: Postponed Evaluation of Annotations

2017-11-03 Thread Guido van Rossum 
IMO the inability of referencing class-level definitions from annotations
on methods pretty much kills this idea.

On Thu, Nov 2, 2017 at 11:27 PM, Nick Coghlan  wrote:

> On 3 November 2017 at 04:39, Jukka Lehtosalo  wrote:
> >> > * forward references: when a type hint contains names that have not
> been
> >> >   defined yet, that definition needs to be expressed as a string
> >> >   literal;
> >>
> >> After all the discussion, I still don't see why this is an issue.
> >> Strings makes perfectly fine forward references. What is the problem
> >> that needs solving? Is this about people not wanting to type the leading
> >> and trailing ' around forward references?
> >
> >
> > Let's make a thought experiment. What if every forward reference would
> > require special quoting? Would Python programmers be happy with this?
> Say,
> > let's use ! as a suffix to mark a forward reference. They make perfectly
> > fine forward references. They are visually pretty unobtrusive (I'm not
> > suggesting $ or other ugly perlisms):
> >
> > def main():
> > args = parse_args!()  # A forward reference
> > do_stuff!(args)  # Explicit is better than implicit
> >
> > def parse_args():
> > ...
> >
> > def do_stuff(args):
> > ...
> >
> > Of course, I'm not seriously proposing this, but this highlights the fact
> > that in normal code forward references "just work" (at least usually),
> and
> > if we'd require a special quoting mechanism to use them anywhere, Python
> > would look uglier and more inconsistent. Nobody would be happy with this
> > change, even though you'd only have to type a single ! character extra --
> > that's not a lot work, right?
> >
> > I think that the analogy is reasonable.
>
> I think it also makes a pretty decent argument that pushing function
> annotations into implicit lambda expressions will be easier to explain
> to people than converting them into strings, and then having to
> explain an entirely new complex set of name resolution rules.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   [email protected]   |   Brisbane, Australia
> ___
> Python-Dev mailing list
> [email protected]
> 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
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Remove typing from the stdlib (was: Reminder: 12 weeks to 3.7 feature code cutoff)

2017-11-03 Thread Serhiy Storchaka 

03.11.17 16:36, Guido van Rossum пише:
> Maybe we should remove typing from the stdlib?
> https://github.com/python/typing/issues/495

I didn't use typing, but AFAIK the most used feature from typing is 
NamedTuple. If move NamedTuple and maybe other convenient classes not 
directly related to typing into collections or types modules, I think 
removing typing from the stdlib will less stress people.

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [edk2] Official port of Python on EDK2

2017-11-03 Thread Michael Zimmermann 
> FYI, this library adds thread support to UEFI:
>
> https://github.com/Openwide-Ingenierie/GreenThreads-UEFI

IMO this library has some crucial problems like changing the TPL
during context switching.
For my project "EFIDroid" I've invested many months analyzing, testing
and implementing my own threading implementation based on
LK(LittleKernel, a MIT licensed project) threads and get/set -context.

The result is a pretty stable implementation which can even be used in
UEFI drivers:
https://github.com/efidroid/uefi_edk2packages_EFIDroidLKLPkg/tree/master/UEFIThreads
I'm currently using this lib for my LKL(LinuxKernelLibrary) port to be
able to use linux touchscreen drivers in UEFI - so you could say it
has been well tested.

The only "problem" is that it only supports ARM right now and that the
get/set context implementation was copied (and simplified) from glibc
which means that this part is GPL code.

Thanks
Michael Zimmermann

On Thu, Nov 2, 2017 at 8:37 PM, Blibbet  wrote:
> On 11/02/2017 09:41 AM, Jayaprakash, N wrote:
>> Would you consider adding thread support in this port of Python for
> EDK2 shell?
>
> FYI, this library adds thread support to UEFI:
>
> https://github.com/Openwide-Ingenierie/GreenThreads-UEFI
>
> Note that the library is GPLv2, ...but the author (a 1-person project)
> could be asked to relicense to BSD to fit into Tianocore.
>
> Note that library is currently Intel x64-centric, and contains a bit of
> assembly. Will need some ARM/RISC-V/x86 contributions.
>
> HTH,
> Lee Fisher
> ___
> edk2-devel mailing list
> [email protected]
> https://lists.01.org/mailman/listinfo/edk2-devel
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove typing from the stdlib (was: Reminder: 12 weeks to 3.7 feature code cutoff)

2017-11-03 Thread Paul Moore 
On 3 November 2017 at 14:50, Serhiy Storchaka  wrote:
> 03.11.17 16:36, Guido van Rossum пише:
>> Maybe we should remove typing from the stdlib?
>> https://github.com/python/typing/issues/495
>
> I didn't use typing, but AFAIK the most used feature from typing is
> NamedTuple. If move NamedTuple and maybe other convenient classes not
> directly related to typing into collections or types modules, I think
> removing typing from the stdlib will less stress people.

(Checks docs) Hmm, I'd missed that this was even in there.

Regardless of what happens with the typing module, I think this should
be moved. I expect there are many people who never looked at the docs
of the typing module because they don't use type annotations. I know
the class uses type annotations to define its attributes, but I don't
see that as an issue. Data classes do the same, and they won't be in
the typing module...

Paul
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Remove typing from the stdlib

2017-11-03 Thread Victor Stinner 
Hi,

2017-11-03 15:36 GMT+01:00 Guido van Rossum :
> Maybe we should remove typing from the stdlib?
> https://github.com/python/typing/issues/495

I'm strongly in favor on such move.

My experience with asyncio in the stdlib is that users expect changes
faster than the very slow release process of the stdlib (a release
every 18 months in average).

I saw many PEPs and discussion on the typing design (meta-classes vs
regular classes), as if the typing is not stable enough to be part of
the stdlib.

The typing module is not used yet in the stdlib, so there is no
technically reason to keep typing part of the stdlib. IMHO it's
perfectly fine to keep typing and annotations out of the stdlib, since
the venv & pip tooling is now rock solid ;-)

Victor
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove typing from the stdlib

2017-11-03 Thread Eric V. Smith 

On 11/3/2017 12:15 PM, Victor Stinner wrote:

Hi,

2017-11-03 15:36 GMT+01:00 Guido van Rossum :

Maybe we should remove typing from the stdlib?
https://github.com/python/typing/issues/495



The typing module is not used yet in the stdlib, so there is no
technically reason to keep typing part of the stdlib. IMHO it's
perfectly fine to keep typing and annotations out of the stdlib, since
the venv & pip tooling is now rock solid ;-)


I'm planning on using it for PEP 557:
https://www.python.org/dev/peps/pep-0557/#class-variables

The way the code currently checks for this should still work if typing 
is not in the stdlib, although of course it's assuming that the name 
"typing" really is the "official" typing library.


# If typing has not been imported, then it's impossible for
#  any annotation to be a ClassVar. So, only look for ClassVar
#  if typing has been imported.
typing = sys.modules.get('typing')
if typing is not None:
# This test uses a typing internal class, but it's the best
#  way to test if this is a ClassVar.
if type(a_type) is typing._ClassVar:
# This field is a ClassVar. Ignore it.
continue

See also https://github.com/ericvsmith/dataclasses/issues/14

Eric.

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Python tracker Issues

2017-11-03 Thread Python tracker 

ACTIVITY SUMMARY (2017-10-27 - 2017-11-03)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open6255 ( -5)
  closed 37431 (+54)
  total  43686 (+49)

Open issues with patches: 2416 


Issues opened (36)
==

#27456: asyncio: set TCP_NODELAY flag by default
https://bugs.python.org/issue27456  reopened by yselivanov

#31887: docs for email.generator are missing a comment on special mult
https://bugs.python.org/issue31887  opened by dhke

#31889: difflib SequenceMatcher ratio() still have unpredictable behav
https://bugs.python.org/issue31889  opened by Siltaar

#31892: ssl.get_server_certificate should allow specifying certificate
https://bugs.python.org/issue31892  opened by hanno

#31894: test_timestamp_naive failed on NetBSD
https://bugs.python.org/issue31894  opened by serhiy.storchaka

#31895: Native hijri calendar support
https://bugs.python.org/issue31895  opened by haneef95

#31896: In function define class inherit ctypes.structure, and using c
https://bugs.python.org/issue31896  opened by Yang Big

#31897: Unexpected exceptions in plistlib.loads
https://bugs.python.org/issue31897  opened by Ned Williamson

#31898: Add a `recommended-packages.txt` file
https://bugs.python.org/issue31898  opened by ncoghlan

#31899: Ensure backwards compatibility with recommended packages
https://bugs.python.org/issue31899  opened by ncoghlan

#31900: localeconv() should decode numeric fields from LC_NUMERIC enco
https://bugs.python.org/issue31900  opened by cstratak

#31901: atexit callbacks only called for current subinterpreter
https://bugs.python.org/issue31901  opened by Dormouse759

#31902: Fix col_offset for ast nodes: AsyncFor, AsyncFunctionDef, Asyn
https://bugs.python.org/issue31902  opened by guoci

#31903: `_scproxy` calls SystemConfiguration functions in a way that c
https://bugs.python.org/issue31903  opened by Maxime Belanger

#31904: Python should support VxWorks RTOS
https://bugs.python.org/issue31904  opened by Brian Kuhl

#31907: Clarify error message when attempting to call function via str
https://bugs.python.org/issue31907  opened by mickey695

#31908: trace module cli does not write cover files
https://bugs.python.org/issue31908  opened by Michael Selik

#31910: test_socket.test_create_connection() failed with EADDRNOTAVAIL
https://bugs.python.org/issue31910  opened by haypo

#31911: Use malloc_usable_size() in pymalloc for realloc
https://bugs.python.org/issue31911  opened by haypo

#31912: PyMem_Malloc() should guarantee alignof(max_align_t)
https://bugs.python.org/issue31912  opened by skrah

#31913: forkserver could warn if several threads are running
https://bugs.python.org/issue31913  opened by pitrou

#31914: Document Pool.(star)map return type
https://bugs.python.org/issue31914  opened by dilyan.palauzov

#31916: ensurepip not honoring value of $(DESTDIR) - pip not installed
https://bugs.python.org/issue31916  opened by multimiler

#31920: pygettext ignores directories as inputfile argument
https://bugs.python.org/issue31920  opened by Oleg Krasnikov

#31921: Bring together logic for entering/leaving a frame in frameobje
https://bugs.python.org/issue31921  opened by pdox

#31922: Can't receive replies from multicast UDP with asyncio
https://bugs.python.org/issue31922  opened by vxgmichel

#31923: Misspelled "loading" in Doc/includes/sqlite3/load_extension.py
https://bugs.python.org/issue31923  opened by davywtf

#31924: Fix test_curses on NetBSD 8
https://bugs.python.org/issue31924  opened by serhiy.storchaka

#31925: test_socket creates too many locks
https://bugs.python.org/issue31925  opened by serhiy.storchaka

#31927: Fix compiling the socket module on NetBSD 8 and other issues
https://bugs.python.org/issue31927  opened by serhiy.storchaka

#31930: IDLE: Pressing "Home" on Windows places cursor before ">>>"
https://bugs.python.org/issue31930  opened by terry.reedy

#31931: test_concurrent_futures: ProcessPoolSpawnExecutorTest.test_shu
https://bugs.python.org/issue31931  opened by haypo

#31932: setup.py cannot find vcversall.bat on MSWin 8.1 if installed i
https://bugs.python.org/issue31932  opened by laranzu

#31933: some Blake2 parameters are encoded backwards on big-endian pla
https://bugs.python.org/issue31933  opened by oconnor663

#31934: Failure to build out of source from a not clean source
https://bugs.python.org/issue31934  opened by xdegaye

#31935: subprocess.run() timeout not working with grandchildren and st
https://bugs.python.org/issue31935  opened by Martin Ritter



Most recent 15 issues with no replies (15)
==

#31935: subprocess.run() timeout not working with grandchildren and st
https://bugs.python.org/issue31935

#31934: Failure to build out of source from a not clean source
https://bugs.python.org/issue31934

#31932: setup.py cannot find vcversall.bat on MSWin 8.1 if instal

Re: [Python-Dev] Remove typing from the stdlib (was: Reminder: 12 weeks to 3.7 feature code cutoff)

2017-11-03 Thread Brett Cannon 
On Fri, 3 Nov 2017 at 08:09 Paul Moore  wrote:

> On 3 November 2017 at 14:50, Serhiy Storchaka  wrote:
> > 03.11.17 16:36, Guido van Rossum пише:
> >> Maybe we should remove typing from the stdlib?
> >> https://github.com/python/typing/issues/495
> >
> > I didn't use typing, but AFAIK the most used feature from typing is
> > NamedTuple. If move NamedTuple and maybe other convenient classes not
> > directly related to typing into collections or types modules, I think
> > removing typing from the stdlib will less stress people.
>
> (Checks docs) Hmm, I'd missed that this was even in there.
>
> Regardless of what happens with the typing module, I think this should
> be moved. I expect there are many people who never looked at the docs
> of the typing module because they don't use type annotations. I know
> the class uses type annotations to define its attributes, but I don't
> see that as an issue. Data classes do the same, and they won't be in
> the typing module...
>

There is another option and that's splitting up the typing module into
core, abstract things, and then the stuff that is about concrete types. For
instance, ClassVar, Union, and cast() are all abstract concepts that are
basic to type hints. But things like Mapping are more concrete and not a
fundamental concept to type hints. You could argue that the fundamentals
that won't change could stay in the stdlib while the concrete type classes
could get pulled out so they can be managed more easily/quickly.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove typing from the stdlib

2017-11-03 Thread Antoine Pitrou 
On Fri, 3 Nov 2017 12:46:33 -0400
"Eric V. Smith"  wrote:
> On 11/3/2017 12:15 PM, Victor Stinner wrote:
> > Hi,
> > 
> > 2017-11-03 15:36 GMT+01:00 Guido van Rossum :  
> >> Maybe we should remove typing from the stdlib?
> >> https://github.com/python/typing/issues/495  
> 
> > The typing module is not used yet in the stdlib, so there is no
> > technically reason to keep typing part of the stdlib. IMHO it's
> > perfectly fine to keep typing and annotations out of the stdlib, since
> > the venv & pip tooling is now rock solid ;-)  
> 
> I'm planning on using it for PEP 557:
> https://www.python.org/dev/peps/pep-0557/#class-variables
> 
> The way the code currently checks for this should still work if typing 
> is not in the stdlib, although of course it's assuming that the name 
> "typing" really is the "official" typing library.

I don't think other modules should start relying on the typing module at
runtime.
The dataclasses module can define its own "ClassVar" thing and then I
suspect it's easy to map it to typing._ClassVar.  It seems we should be
careful not to blur the distinction between declarations that have an
effect on actual code, and typing declarations which only affect
type-checking tools.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [edk2] Official port of Python on EDK2

2017-11-03 Thread Brett Cannon 
Since the initial email got cross-posted, would it be possible to drop
python-dev from any discussing that doesn't directly involve Python itself
(e.g. we don't need to be involved in a discussion about whether you all
have threading on UEFI)?

On Fri, 3 Nov 2017 at 07:57 Michael Zimmermann 
wrote:

> > FYI, this library adds thread support to UEFI:
> >
> > https://github.com/Openwide-Ingenierie/GreenThreads-UEFI
>
> IMO this library has some crucial problems like changing the TPL
> during context switching.
> For my project "EFIDroid" I've invested many months analyzing, testing
> and implementing my own threading implementation based on
> LK(LittleKernel, a MIT licensed project) threads and get/set -context.
>
> The result is a pretty stable implementation which can even be used in
> UEFI drivers:
>
> https://github.com/efidroid/uefi_edk2packages_EFIDroidLKLPkg/tree/master/UEFIThreads
> I'm currently using this lib for my LKL(LinuxKernelLibrary) port to be
> able to use linux touchscreen drivers in UEFI - so you could say it
> has been well tested.
>
> The only "problem" is that it only supports ARM right now and that the
> get/set context implementation was copied (and simplified) from glibc
> which means that this part is GPL code.
>
> Thanks
> Michael Zimmermann
>
> On Thu, Nov 2, 2017 at 8:37 PM, Blibbet  wrote:
> > On 11/02/2017 09:41 AM, Jayaprakash, N wrote:
> >> Would you consider adding thread support in this port of Python for
> > EDK2 shell?
> >
> > FYI, this library adds thread support to UEFI:
> >
> > https://github.com/Openwide-Ingenierie/GreenThreads-UEFI
> >
> > Note that the library is GPLv2, ...but the author (a 1-person project)
> > could be asked to relicense to BSD to fit into Tianocore.
> >
> > Note that library is currently Intel x64-centric, and contains a bit of
> > assembly. Will need some ARM/RISC-V/x86 contributions.
> >
> > HTH,
> > Lee Fisher
> > ___
> > edk2-devel mailing list
> > [email protected]
> > https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove typing from the stdlib

2017-11-03 Thread Paul Moore 
On 3 November 2017 at 17:47, Antoine Pitrou  wrote:
> On Fri, 3 Nov 2017 12:46:33 -0400
> "Eric V. Smith"  wrote:
>> On 11/3/2017 12:15 PM, Victor Stinner wrote:
>> > Hi,
>> >
>> > 2017-11-03 15:36 GMT+01:00 Guido van Rossum :
>> >> Maybe we should remove typing from the stdlib?
>> >> https://github.com/python/typing/issues/495
>>
>> > The typing module is not used yet in the stdlib, so there is no
>> > technically reason to keep typing part of the stdlib. IMHO it's
>> > perfectly fine to keep typing and annotations out of the stdlib, since
>> > the venv & pip tooling is now rock solid ;-)
>>
>> I'm planning on using it for PEP 557:
>> https://www.python.org/dev/peps/pep-0557/#class-variables
>>
>> The way the code currently checks for this should still work if typing
>> is not in the stdlib, although of course it's assuming that the name
>> "typing" really is the "official" typing library.
>
> I don't think other modules should start relying on the typing module at
> runtime.
> The dataclasses module can define its own "ClassVar" thing and then I
> suspect it's easy to map it to typing._ClassVar.  It seems we should be
> careful not to blur the distinction between declarations that have an
> effect on actual code, and typing declarations which only affect
> type-checking tools.

I'm looking forward to the dataclasses module, and I'm perfectly OK
with the way that it uses type annotations to declare attributes. I
also don't have a problem with it relying on the typing module - but
*only* if the typing module is in the stdlib. I don't think it's good
if a standard feature needs an external library for some of its
functionality.

So I guess the point is, if we're considering moving typing out of the
stdlib, then what's the impact on PEP 557?

Personally, I don't use type annotations myself yet, but I've used
code that does and I'm considering looking into them - for a variety
of reasons, documentation, IDE support, and the ability to type check
my code via mypy. If typing moves out of the stdlib, I'd be much less
inclined to do so - adding a runtime dependency is a non-trivial cost
in terms of admin for deployment, handling within my (peculiar, if you
want to debate workflow) development workflow, etc. Working out how to
add type annotations *without* them being a runtime dependency (just
at test-time) is too much work. So I am concerned that if we move
typing out of the stdlib, it'll reduce adoption rates.

Paul
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove typing from the stdlib (was: Reminder: 12 weeks to 3.7 feature code cutoff)

2017-11-03 Thread Jelle Zijlstra 
2017-11-03 10:46 GMT-07:00 Brett Cannon :

>
>
> On Fri, 3 Nov 2017 at 08:09 Paul Moore  wrote:
>
>> On 3 November 2017 at 14:50, Serhiy Storchaka 
>> wrote:
>> > 03.11.17 16:36, Guido van Rossum пише:
>> >> Maybe we should remove typing from the stdlib?
>> >> https://github.com/python/typing/issues/495
>> >
>> > I didn't use typing, but AFAIK the most used feature from typing is
>> > NamedTuple. If move NamedTuple and maybe other convenient classes not
>> > directly related to typing into collections or types modules, I think
>> > removing typing from the stdlib will less stress people.
>>
>> (Checks docs) Hmm, I'd missed that this was even in there.
>>
>> Regardless of what happens with the typing module, I think this should
>> be moved. I expect there are many people who never looked at the docs
>> of the typing module because they don't use type annotations. I know
>> the class uses type annotations to define its attributes, but I don't
>> see that as an issue. Data classes do the same, and they won't be in
>> the typing module...
>>
>
> There is another option and that's splitting up the typing module into
> core, abstract things, and then the stuff that is about concrete types. For
> instance, ClassVar, Union, and cast() are all abstract concepts that are
> basic to type hints. But things like Mapping are more concrete and not a
> fundamental concept to type hints. You could argue that the fundamentals
> that won't change could stay in the stdlib while the concrete type classes
> could get pulled out so they can be managed more easily/quickly.
>

I don't think the fundamentals are less likely to change—if anything, it
may be the opposite. Many of the potential innovations we'd want to add to
typing (Protocols, literal types, intersection types) are fundamental to
the type system, and things like Mapping actually don't change very often.


>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> jelle.zijlstra%40gmail.com
>
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove typing from the stdlib

2017-11-03 Thread Steve Dower 

On 03Nov2017 0915, Victor Stinner wrote:

Hi,

2017-11-03 15:36 GMT+01:00 Guido van Rossum :

Maybe we should remove typing from the stdlib?
https://github.com/python/typing/issues/495


I'm strongly in favor on such move.


I'm torn.

If not having typing installed means you can't use "Any" or "Optional" 
in an annotation, that basically kills the whole thing. Some primitives 
need to be there.


If annotations become glorified strings (which IMHO they should) and 
typing gains a function to parse those into type hints (which IMHO it 
should), then I'm in favour of splitting typing out. (Personally, if 
making every type hint a literal 'string' meant that I could avoid 
importing typing then I'd do it.)


However, if typing is split out then its API (specifically, the contents 
of typing.__all__ and their semantic meaning (e.g. "Iterable" means 
something with an "__iter__" method)) needs to stay in PEPs.


Static analysers using type hints encode much more information about 
these types than can be inferred statically from typing.py, which means 
the definitions should not change faster than Python x.*y*. Ideally, 
they would not change at all once released.


For example, my static analyser has an existing object representing 
iterables, since we've been inferring iterables for years. When I parse 
a type annotation and see "typing.Iterable", I'm going to just 
substitute my own implementation - the definition in typing.py isn't 
going to be used (or be useful). And because it has to map across 
languages, it has to be a hard-coded mapping that can't rely on 
typing.py at all.


Since the contents of typing.py will likely be completely ignored by my 
analyser, which means that I can't treat "whatever version of typing is 
installed" as ground truth. It needs to move slower or be purely 
additive. Being in the standard library is a nice easy way to ensure 
this - moving it out is a risk.


That said, because I don't care about the contents of the file, all the 
heavy execution stuff can totally be moved out. If typing in the stdlib 
became very trivial definitions or just a set of names to support 
searching/editors/forward-refs, and typing out of the stdlib had the 
ability to convert annotations into an object model that provides rich 
runtime introspection, I'd also be fine. At least then the interface is 
highly stable, even if the implementation (for those who use it) changes.


Cheers,
Steve
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove typing from the stdlib

2017-11-03 Thread Antoine Pitrou 

Also, as for dataclasses specifically, since it may become as pervasive
as namedtuples, we probably want it to be as light-weight as possible.
Which will be harder to achieve if its *API* depends on the typing
machinery.

Regards

Antoine.


Le 03/11/2017 à 19:04, Paul Moore a écrit :
> On 3 November 2017 at 17:47, Antoine Pitrou  wrote:
>> On Fri, 3 Nov 2017 12:46:33 -0400
>> "Eric V. Smith"  wrote:
>>> On 11/3/2017 12:15 PM, Victor Stinner wrote:
 Hi,

 2017-11-03 15:36 GMT+01:00 Guido van Rossum :
> Maybe we should remove typing from the stdlib?
> https://github.com/python/typing/issues/495
>>>
 The typing module is not used yet in the stdlib, so there is no
 technically reason to keep typing part of the stdlib. IMHO it's
 perfectly fine to keep typing and annotations out of the stdlib, since
 the venv & pip tooling is now rock solid ;-)
>>>
>>> I'm planning on using it for PEP 557:
>>> https://www.python.org/dev/peps/pep-0557/#class-variables
>>>
>>> The way the code currently checks for this should still work if typing
>>> is not in the stdlib, although of course it's assuming that the name
>>> "typing" really is the "official" typing library.
>>
>> I don't think other modules should start relying on the typing module at
>> runtime.
>> The dataclasses module can define its own "ClassVar" thing and then I
>> suspect it's easy to map it to typing._ClassVar.  It seems we should be
>> careful not to blur the distinction between declarations that have an
>> effect on actual code, and typing declarations which only affect
>> type-checking tools.
> 
> I'm looking forward to the dataclasses module, and I'm perfectly OK
> with the way that it uses type annotations to declare attributes. I
> also don't have a problem with it relying on the typing module - but
> *only* if the typing module is in the stdlib. I don't think it's good
> if a standard feature needs an external library for some of its
> functionality.
> 
> So I guess the point is, if we're considering moving typing out of the
> stdlib, then what's the impact on PEP 557?
> 
> Personally, I don't use type annotations myself yet, but I've used
> code that does and I'm considering looking into them - for a variety
> of reasons, documentation, IDE support, and the ability to type check
> my code via mypy. If typing moves out of the stdlib, I'd be much less
> inclined to do so - adding a runtime dependency is a non-trivial cost
> in terms of admin for deployment, handling within my (peculiar, if you
> want to debate workflow) development workflow, etc. Working out how to
> add type annotations *without* them being a runtime dependency (just
> at test-time) is too much work. So I am concerned that if we move
> typing out of the stdlib, it'll reduce adoption rates.
> 
> Paul
> 
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove typing from the stdlib

2017-11-03 Thread Guido van Rossum 
A side note (I'm reading all responses but staying out of the discussion):

No static checker should depend on the *contents* of typing.py, since it's
just a bunch of runtime gymnastics to allow types to be evaluated at
runtime without errors, with a secondary goal of making them introspectable
(some folks don't even agree with the latter, e.g. Mark Shannon).

Static analyzers should be able to make strong *assumptions* about what
things defined there mean -- in mypy such assumptions are all over the
place, based on the full name of things -- it never reads typing.py. (It
reads typing.pyi from typeshed, but what's there is ignored in many cases
too.)



On Fri, Nov 3, 2017 at 10:00 AM, Steve Dower  wrote:

> On 03Nov2017 0915, Victor Stinner wrote:
>
>> Hi,
>>
>> 2017-11-03 15:36 GMT+01:00 Guido van Rossum :
>>
>>> Maybe we should remove typing from the stdlib?
>>> https://github.com/python/typing/issues/495
>>>
>>
>> I'm strongly in favor on such move.
>>
>
> I'm torn.
>
> If not having typing installed means you can't use "Any" or "Optional" in
> an annotation, that basically kills the whole thing. Some primitives need
> to be there.
>
> If annotations become glorified strings (which IMHO they should) and
> typing gains a function to parse those into type hints (which IMHO it
> should), then I'm in favour of splitting typing out. (Personally, if making
> every type hint a literal 'string' meant that I could avoid importing
> typing then I'd do it.)
>
> However, if typing is split out then its API (specifically, the contents
> of typing.__all__ and their semantic meaning (e.g. "Iterable" means
> something with an "__iter__" method)) needs to stay in PEPs.
>
> Static analysers using type hints encode much more information about these
> types than can be inferred statically from typing.py, which means the
> definitions should not change faster than Python x.*y*. Ideally, they would
> not change at all once released.
>
> For example, my static analyser has an existing object representing
> iterables, since we've been inferring iterables for years. When I parse a
> type annotation and see "typing.Iterable", I'm going to just substitute my
> own implementation - the definition in typing.py isn't going to be used (or
> be useful). And because it has to map across languages, it has to be a
> hard-coded mapping that can't rely on typing.py at all.
>
> Since the contents of typing.py will likely be completely ignored by my
> analyser, which means that I can't treat "whatever version of typing is
> installed" as ground truth. It needs to move slower or be purely additive.
> Being in the standard library is a nice easy way to ensure this - moving it
> out is a risk.
>
> That said, because I don't care about the contents of the file, all the
> heavy execution stuff can totally be moved out. If typing in the stdlib
> became very trivial definitions or just a set of names to support
> searching/editors/forward-refs, and typing out of the stdlib had the
> ability to convert annotations into an object model that provides rich
> runtime introspection, I'd also be fine. At least then the interface is
> highly stable, even if the implementation (for those who use it) changes.
>
> Cheers,
> Steve
>
> ___
> Python-Dev mailing list
> [email protected]
> 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
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove typing from the stdlib

2017-11-03 Thread Antoine Pitrou 

Le 03/11/2017 à 19:34, Stéfane Fermigier a écrit :
> 
> On Fri, Nov 3, 2017 at 6:47 PM, Antoine Pitrou  > wrote:
> 
> I don't think other modules should start relying on the typing module at
> runtime.
> 
> They already do, as I've noted in my message about dependency injection,
> and I find this quite elegant.

Third-party libraries do what they want, but we are talking about the
stdlib here.

Regards

Antoine.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove typing from the stdlib

2017-11-03 Thread Steve Dower 

On 03Nov2017 1124, Guido van Rossum wrote:

A side note (I'm reading all responses but staying out of the discussion):

No static checker should depend on the *contents* of typing.py, since 
it's just a bunch of runtime gymnastics to allow types to be evaluated 
at runtime without errors, with a secondary goal of making them 
introspectable (some folks don't even agree with the latter, e.g. Mark 
Shannon).


Static analyzers should be able to make strong *assumptions* about what 
things defined there mean -- in mypy such assumptions are all over the 
place, based on the full name of things -- it never reads typing.py. (It 
reads typing.pyi from typeshed, but what's there is ignored in many 
cases too.)


Thank you. Very glad to hear I understood it correctly.

Cheers,
Steve


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove typing from the stdlib

2017-11-03 Thread Stéfane Fermigier 
On Fri, Nov 3, 2017 at 6:47 PM, Antoine Pitrou  wrote:

> On Fri, 3 Nov 2017 12:46:33 -0400
> "Eric V. Smith"  wrote:
> > On 11/3/2017 12:15 PM, Victor Stinner wrote:
> > > Hi,
> > >
> > > 2017-11-03 15:36 GMT+01:00 Guido van Rossum :
> > >> Maybe we should remove typing from the stdlib?
> > >> https://github.com/python/typing/issues/495
> >
> > > The typing module is not used yet in the stdlib, so there is no
> > > technically reason to keep typing part of the stdlib. IMHO it's
> > > perfectly fine to keep typing and annotations out of the stdlib, since
> > > the venv & pip tooling is now rock solid ;-)
> >
> > I'm planning on using it for PEP 557:
> > https://www.python.org/dev/peps/pep-0557/#class-variables
> >
> > The way the code currently checks for this should still work if typing
> > is not in the stdlib, although of course it's assuming that the name
> > "typing" really is the "official" typing library.
>
> I don't think other modules should start relying on the typing module at
> runtime.
>

They already do, as I've noted in my message about dependency injection,
and I find this quite elegant.

Previously, similar projects used decorators, or less elegant constructs.

  S.

-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Chairman, Free&OSS Group / Systematic Cluster -
http://www.gt-logiciel-libre.org/
Co-Chairman, National Council for Free & Open Source Software (CNLL) -
http://cnll.fr/
Founder & Organiser, PyData Paris - http://pydata.fr/
---
“You never change things by fighting the existing reality. To change
something, build a new model that makes the existing model obsolete.” — R.
Buckminster Fuller
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove typing from the stdlib

2017-11-03 Thread Barry Warsaw 
On Nov 3, 2017, at 10:00, Steve Dower  wrote:
> 
> On 03Nov2017 0915, Victor Stinner wrote:
>> Hi,
>> 2017-11-03 15:36 GMT+01:00 Guido van Rossum :
>>> Maybe we should remove typing from the stdlib?
>>> https://github.com/python/typing/issues/495
>> I'm strongly in favor on such move.
> 
> I'm torn.

Me too.  We’re seeing much greater adoption of type annotations, and it’s 
becoming one of the killer features for adopting Python 3.  I’d be hesitant to 
accept anything that slows that adoption down.  While it’s been technically 
provisional, a lot of code is beginning to depend on it and it would be a shame 
to break that code as we also start to adopt Python 3.7.  But I can appreciate 
the need to iterate on its API faster.

I don’t know if a middle ground is feasible.  What core functionality and 
stable-enough APIs can be kept in stdlib typing, and can we provide an 
extension or override mechanism if you want the latest and greatest?

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove typing from the stdlib

2017-11-03 Thread Paul Moore 
On 3 November 2017 at 17:00, Steve Dower  wrote:
>
> I'm torn.
>
> If not having typing installed means you can't use "Any" or "Optional" in an
> annotation, that basically kills the whole thing. Some primitives need to be
> there.

Thinking some more about this, I think that it's now established that
the annotation syntax is for types - any debate over other uses for
them is now past. As a result, though, I think it's important that the
language (and/or the standard library) should include support for
*expressing* those types. The typing module is what allows users to
express types like "list of integers", or "optional string", or
"iterable", and if we move typing out of the stdlib, we make it
impossible for people who want to use the language feature to do so
from within the core language.

Consider someone who's downloaded Python and PyCharm (or Visual
Studio). They want to get the benefit of the IDE code completion
facilities, so they declare their argument as List[int], following the
information they've found on how to declare lists of integers. And now
their code won't run, until they install typing from PyPI. And there's
no workaround, because you can't express List[int] in the core
language/stdlib. That's not a very good start for a newcomer to
Python.

I'm fine with the "advanced" bits of typing being removed from the
stdlib, but I think we need to include in the stdlib at least enough
to express the basic types of the language (including common
combinations such as Optional and Union).

Paul

PS Apologies if I've misunderstood any of the technical aspects of
typing - I'm happy to be corrected. As I said in another email, I've
not actually used type annotations in my own code yet, although I'm
thinking of starting to - precisely because I've been using PyCharm
recently and the IDE support when you declare types is quite nice.
___
Python-Dev mailing list
[email protected]
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 563: Postponed Evaluation of Annotations

2017-11-03 Thread Barry Warsaw 
On Nov 2, 2017, at 23:22, Nick Coghlan  wrote:
> Another point worth noting is that merely importing the typing module
> is expensive:
> 
> $ python -m perf timeit -s "from importlib import reload; import
> typing" "reload(typing)"
> .
> Mean +- std dev: 10.6 ms +- 0.6 ms
> 
> 10 ms is a *big* chunk out of a CLI application's startup time budget.

Far and away so, except for the re module.

% ./python.exe -X importtime -c "import typing"
import time: self [us] | cumulative | imported package
import time:72 | 72 | _codecs
import time:   625 |696 |   codecs
import time:   354 |354 |   encodings.aliases
import time:   713 |   1762 | encodings
import time:   198 |198 | encodings.utf_8
import time:98 | 98 | _signal
import time:   233 |233 | encodings.latin_1
import time:   353 |353 | _weakrefset
import time:   264 |617 |   abc
import time:   402 |   1018 | io
import time:   136 |136 |   _stat
import time:   197 |333 | stat
import time:   227 |227 |   genericpath
import time:   377 |604 | posixpath
import time:  2812 |   2812 | _collections_abc
import time:   787 |   4534 |   os
import time:   315 |315 |   _sitebuiltins
import time:   336 |336 |   sitecustomize
import time:   114 |114 |   usercustomize
import time:  1064 |   6361 | site
import time:   160 |160 |   _operator
import time:  1412 |   1571 | operator
import time:   371 |371 | keyword
import time:   817 |817 |   _heapq
import time:   762 |   1579 | heapq
import time:   272 |272 | itertools
import time:   635 |635 | reprlib
import time:99 | 99 | _collections
import time:  3580 |   8104 |   collections
import time:   112 |112 |   _functools
import time:   781 |892 | functools
import time:  1774 |   2666 |   contextlib
import time:   272 |272 |   types
import time:   861 |   1132 | enum
import time:76 | 76 |   _sre
import time:   426 |426 | sre_constants
import time:   446 |872 |   sre_parse
import time:   414 |   1361 | sre_compile
import time:79 | 79 | _locale
import time:   190 |190 | copyreg
import time: 17200 |  19961 |   re
import time:   374 |374 |   collections.abc
import time: 15124 |  46226 | typing

-Barry



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove typing from the stdlib

2017-11-03 Thread Sven R. Kunze 

On 03.11.2017 21:34, Paul Moore wrote:

Consider someone who's downloaded Python and PyCharm (or Visual
Studio). They want to get the benefit of the IDE code completion
facilities, so they declare their argument as List[int], following the
information they've found on how to declare lists of integers.


The PyCharm I know is capable of detecting such simple types on its own, 
without type hints.



I for one like the idea of a faster evolution of typing.py.

Cheers,
Sven


PS: pip is pretty standard these days, so I don't think it's much of an 
issue for guys who really needs it installed.

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove typing from the stdlib

2017-11-03 Thread Victor Stinner 
2017-11-03 18:00 GMT+01:00 Steve Dower :
> If not having typing installed means you can't use "Any" or "Optional" in an
> annotation, that basically kills the whole thing. Some primitives need to be
> there.

I'm not sure that I understand you.

The question is if you would only need  or .

If typing is removed from the stdlib, you can still use it in your
application. It's "just" another dependency no? Which major (non
trivial) application or Python module has zero external dependency
nowaday?

The only drawback is that we cannot use typing "anymore" in the stdlib
itself, since we don't allow external dependency in the stdlib for
practical reasons. But as I wrote, we don't use typing currently in
stdlib. I'm perfectly fine with the current status of having
annotations on the stdlib in a third party project.

Victor
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Reminder: 12 weeks to 3.7 feature code cutoff

2017-11-03 Thread Joao S. O. Bueno 
This just popped up in Brython's issue tracker discussion:

"""
Pierre Quentel 

04:57 (16 hours ago)
to brython-dev/br., Subscribed

I think it's better to rename all occurences of async now, although
it's strange that :

there is currently no deprecation warning in CPython with code that
uses it as a variable name, PEP492 said that "async and await names
will be softly deprecated in CPython 3.5 and 3.6"
there is no mention of async and await becoming keywords in What's new
in Python 3.7

Maybe the idea was finally given up, but I can't find a reference.

"""

So, what is the status of promoting async and await to full keyword for 3.7?


On 1 November 2017 at 19:47, Ned Deily  wrote:
> Happy belated Halloween to those who celebrate it; I hope it wasn't too 
> scary!  Also possibly scary: we have just a little over 12 weeks remaining 
> until Python 3.7's feature code cutoff, 2018-01-29.  Those 12 weeks include a 
> number of traditional holidays around the world so, if you are planning on 
> writing another PEP for 3.7 or working on getting an existing one approved or 
> getting feature code reviewed, please plan accordingly.If you have 
> something in the pipeline, please either let me know or, when implemented, 
> add the feature to PEP 537, the 3.7 Release Schedule PEP.  As you may recall, 
> the release schedule calls for 4 alpha preview releases prior to the feature 
> code cutoff with the first beta release.  We have already produced the first 
> two alphas.  Reviewing the schedule recently, I realized that I had 
> "front-loaded" the alphas, leaving a bigger gap between the final alphas and 
> the first beta.  So I have adjusted the schedule a bit, pushing alpha 3 and 4 
> out.  The new
  d
>  ates are:
>
> - 3.7.0 alpha 3: 2017-11-27 (was 2017-11-13)
> - 3.7.0 alpha 4: 2018-01-08 (was 2017-12-18)
> - 3.7.0 beta 1:  2018-01-29 (feature freeze - unchanged)
>
> I hope the new dates give you a little bit more time to get your bits 
> finished and get a little bit of exposure prior to the feature freeze.
>
> Considering how quickly and positively it has been adopted, 3.6 is going to 
> be a tough act to follow.  But we can do it again.  Thank you all for your 
> ongoing efforts!
>
> --Ned
>
> --
>   Ned Deily
>   [email protected] -- []
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Reminder: 12 weeks to 3.7 feature code cutoff

2017-11-03 Thread Jelle Zijlstra 
2017-11-03 16:44 GMT-07:00 Joao S. O. Bueno :

> This just popped up in Brython's issue tracker discussion:
>
> """
> Pierre Quentel 
>
> 04:57 (16 hours ago)
> to brython-dev/br., Subscribed
>
> I think it's better to rename all occurences of async now, although
> it's strange that :
>
> there is currently no deprecation warning in CPython with code that
> uses it as a variable name, PEP492 said that "async and await names
> will be softly deprecated in CPython 3.5 and 3.6"
> there is no mention of async and await becoming keywords in What's new
> in Python 3.7
>
> Maybe the idea was finally given up, but I can't find a reference.
>
> """
>
> So, what is the status of promoting async and await to full keyword for
> 3.7?
>
> This was implemented, and it's in NEWS:
https://github.com/python/cpython/pull/1669.

>
> On 1 November 2017 at 19:47, Ned Deily  wrote:
> > Happy belated Halloween to those who celebrate it; I hope it wasn't too
> scary!  Also possibly scary: we have just a little over 12 weeks remaining
> until Python 3.7's feature code cutoff, 2018-01-29.  Those 12 weeks include
> a number of traditional holidays around the world so, if you are planning
> on writing another PEP for 3.7 or working on getting an existing one
> approved or getting feature code reviewed, please plan accordingly.
> If you have something in the pipeline, please either let me know or, when
> implemented, add the feature to PEP 537, the 3.7 Release Schedule PEP.  As
> you may recall, the release schedule calls for 4 alpha preview releases
> prior to the feature code cutoff with the first beta release.  We have
> already produced the first two alphas.  Reviewing the schedule recently, I
> realized that I had "front-loaded" the alphas, leaving a bigger gap between
> the final alphas and the first beta.  So I have adjusted the schedule a
> bit, pushing alpha 3 and 4 out.  The new
>   d
> >  ates are:
> >
> > - 3.7.0 alpha 3: 2017-11-27 (was 2017-11-13)
> > - 3.7.0 alpha 4: 2018-01-08 (was 2017-12-18)
> > - 3.7.0 beta 1:  2018-01-29 (feature freeze - unchanged)
> >
> > I hope the new dates give you a little bit more time to get your bits
> finished and get a little bit of exposure prior to the feature freeze.
> >
> > Considering how quickly and positively it has been adopted, 3.6 is going
> to be a tough act to follow.  But we can do it again.  Thank you all for
> your ongoing efforts!
> >
> > --Ned
> >
> > --
> >   Ned Deily
> >   [email protected] -- []
> >
> > ___
> > Python-Dev mailing list
> > [email protected]
> > https://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> jsbueno%40python.org.br
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> jelle.zijlstra%40gmail.com
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Reminder: 12 weeks to 3.7 feature code cutoff

2017-11-03 Thread Victor Stinner 
2017-11-04 0:44 GMT+01:00 Joao S. O. Bueno :
> This just popped up in Brython's issue tracker discussion:
>
> """
> Pierre Quentel 
>
> 04:57 (16 hours ago)
> to brython-dev/br., Subscribed
>
> I think it's better to rename all occurences of async now, although
> it's strange that :
>
> there is currently no deprecation warning in CPython with code that
> uses it as a variable name, PEP492 said that "async and await names
> will be softly deprecated in CPython 3.5 and 3.6"
> there is no mention of async and await becoming keywords in What's new
> in Python 3.7
>
> Maybe the idea was finally given up, but I can't find a reference.

async & await already became concrete keywords in Python 3.7:

$ ./python
Python 3.7.0a2+ (heads/master-dirty:cbe1756e3e, Nov  4 2017, 00:24:07)
>>> async=1
  File "", line 1
async=1
 ^
SyntaxError: invalid syntax

Please request an entry in the "What's New in Pyhon 3.7" at
https://bugs.python.org/issue30406

Victor
___
Python-Dev mailing list
[email protected]
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 563: Postponed Evaluation of Annotations

2017-11-03 Thread Luca Sbardella 
Impressive stats! I didn’t know this command, thanks!

On Fri, 3 Nov 2017 at 20:47, Barry Warsaw  wrote:

> On Nov 2, 2017, at 23:22, Nick Coghlan  wrote:
> > Another point worth noting is that merely importing the typing module
> > is expensive:
> >
> > $ python -m perf timeit -s "from importlib import reload; import
> > typing" "reload(typing)"
> > .
> > Mean +- std dev: 10.6 ms +- 0.6 ms
> >
> > 10 ms is a *big* chunk out of a CLI application's startup time budget.
>
> Far and away so, except for the re module.
>
> % ./python.exe -X importtime -c "import typing"
> import time: self [us] | cumulative | imported package
> import time:72 | 72 | _codecs
> import time:   625 |696 |   codecs
> import time:   354 |354 |   encodings.aliases
> import time:   713 |   1762 | encodings
> import time:   198 |198 | encodings.utf_8
> import time:98 | 98 | _signal
> import time:   233 |233 | encodings.latin_1
> import time:   353 |353 | _weakrefset
> import time:   264 |617 |   abc
> import time:   402 |   1018 | io
> import time:   136 |136 |   _stat
> import time:   197 |333 | stat
> import time:   227 |227 |   genericpath
> import time:   377 |604 | posixpath
> import time:  2812 |   2812 | _collections_abc
> import time:   787 |   4534 |   os
> import time:   315 |315 |   _sitebuiltins
> import time:   336 |336 |   sitecustomize
> import time:   114 |114 |   usercustomize
> import time:  1064 |   6361 | site
> import time:   160 |160 |   _operator
> import time:  1412 |   1571 | operator
> import time:   371 |371 | keyword
> import time:   817 |817 |   _heapq
> import time:   762 |   1579 | heapq
> import time:   272 |272 | itertools
> import time:   635 |635 | reprlib
> import time:99 | 99 | _collections
> import time:  3580 |   8104 |   collections
> import time:   112 |112 |   _functools
> import time:   781 |892 | functools
> import time:  1774 |   2666 |   contextlib
> import time:   272 |272 |   types
> import time:   861 |   1132 | enum
> import time:76 | 76 |   _sre
> import time:   426 |426 | sre_constants
> import time:   446 |872 |   sre_parse
> import time:   414 |   1361 | sre_compile
> import time:79 | 79 | _locale
> import time:   190 |190 | copyreg
> import time: 17200 |  19961 |   re
> import time:   374 |374 |   collections.abc
> import time: 15124 |  46226 | typing
>
> -Barry
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/luca.sbardella%40gmail.com
>
-- 
http://lucasbardella.com
___
Python-Dev mailing list
[email protected]
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 563: Postponed Evaluation of Annotations

2017-11-03 Thread Barry Warsaw 
On Nov 3, 2017, at 17:09, Luca Sbardella  wrote:
> 
> Impressive stats! I didn’t know this command, thanks!

Neither did I until a day or so ago.  I already only want to use Python 3.7.  :)

-Barry



signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove typing from the stdlib

2017-11-03 Thread Lukasz Langa 

> On 3 Nov, 2017, at 4:01 PM, Victor Stinner  wrote:
> 
> The question is if you would only need  or  pip install typing>.
> 
> If typing is removed from the stdlib, you can still use it in your
> application. It's "just" another dependency no?


The ideal situation is that something is built-in and just works, examples: 
dicts, lists, sorted().

So, if you have to import it to use it, it's still great but less seamless, 
current example: regular expressions. Let's say Guido suggests we should import 
sorted, dict, and list before use. Not a big deal, right? I mean, how many 
applications do you know that don't use any other imports?

Finally, if you have to find a third-party package, add it to requirements.txt 
and manage the dependency forward, that's even less seamless. The standard 
library has a pretty conservative approach to backwards compatibility. On the 
other hand, third-party libraries often don't. Sure, there's noble exceptions 
but the general feel is that you need to be more careful with dependencies from 
PyPI. If somebody suggested that regular expressions or dictionaries should be 
moved to PyPI, in my book that would suggest strange things will start 
happening in the future.

So, the difference is in perceived usability. It's psychological.

- Ł


signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Reminder: 12 weeks to 3.7 feature code cutoff

2017-11-03 Thread Nick Coghlan 
On 4 November 2017 at 09:52, Jelle Zijlstra  wrote:
>
> 2017-11-03 16:44 GMT-07:00 Joao S. O. Bueno :
>>
>> This just popped up in Brython's issue tracker discussion:
>>
>> """
>> Pierre Quentel 
>>
>> 04:57 (16 hours ago)
>> to brython-dev/br., Subscribed
>>
>> I think it's better to rename all occurences of async now, although
>> it's strange that :
>>
>> there is currently no deprecation warning in CPython with code that
>> uses it as a variable name, PEP492 said that "async and await names
>> will be softly deprecated in CPython 3.5 and 3.6"
>> there is no mention of async and await becoming keywords in What's new
>> in Python 3.7
>>
>> Maybe the idea was finally given up, but I can't find a reference.
>>
>> """
>>
>> So, what is the status of promoting async and await to full keyword for
>> 3.7?
>>
> This was implemented, and it's in NEWS:
> https://github.com/python/cpython/pull/1669.

That's a big enough change that it should be in What's New as well (at
least in the porting section, and probably more prominent than that).

The current lack of DeprecationWarnings in 3.6 is a fairly major
oversight/bug, though:

Python 3.6.2 (default, Oct  2 2017, 16:51:32)
[GCC 7.2.1 20170915 (Red Hat 7.2.1-2)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> await = 1
>>> async = 1
>>> print(async, await)
1 1

So if we're going to go ahead with making them real keywords in 3.7
(as specified in PEP 492), then the missing DeprecationWarning problem
in 3.6 needs to be fixed.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove typing from the stdlib

2017-11-03 Thread Nick Coghlan 
On 4 November 2017 at 04:24, Guido van Rossum  wrote:
> A side note (I'm reading all responses but staying out of the discussion):
>
> No static checker should depend on the *contents* of typing.py, since it's
> just a bunch of runtime gymnastics to allow types to be evaluated at runtime
> without errors, with a secondary goal of making them introspectable (some
> folks don't even agree with the latter, e.g. Mark Shannon).
>
> Static analyzers should be able to make strong *assumptions* about what
> things defined there mean -- in mypy such assumptions are all over the
> place, based on the full name of things -- it never reads typing.py. (It
> reads typing.pyi from typeshed, but what's there is ignored in many cases
> too.)

If I understand correctly, a lot of the complexity in the current
typing.py implementation is there to make isinstance and issubclass do
something "useful" at runtime, and to allow generics to be used as
base classes.

If it wasn't for those design goals, then "typing.List[int]" could
just return a lightweight instance of a regular class rather than a
usable Python class definition.

If I'm right about that, then PEP 560's proposal to allow types to
implement a hook that says "Replace me with this other object for
runtime subclassing purposes" may be enough to let you delete most of
the current code in the typing module - you'd just need to have
isinstance and issubclass respect that new hook as well, and define
the hooks as returning the relevant ABCs.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com