Re: [Python-Dev] Investigating time for `import requests`

[Ronald Oussoren]

Op 10 okt. 2017 om 01:48 heeft Brett Cannon mailto:br...@python.org>> het volgende geschreven:

> 
> 
> On Mon, Oct 2, 2017, 17:49 Ronald Oussoren,  > wrote:
> Op 3 okt. 2017 om 04:29 heeft Barry Warsaw  > het volgende geschreven:
> 
> > On Oct 2, 2017, at 14:56, Brett Cannon  > > wrote:
> >
> >> So Mercurial specifically is an odd duck because they already do lazy 
> >> importing (in fact they are using the lazy loading support from 
> >> importlib). In terms of all of this discussion of tweaking import to be 
> >> lazy, I think the best approach would be providing an opt-in solution that 
> >> CLI tools can turn on ASAP while the default stays eager. That way 
> >> everyone gets what they want while the stdlib provides a shared solution 
> >> that's maintained alongside import itself to make sure it functions 
> >> appropriately.
> >
> > The problem I think is that to get full benefit of lazy loading, it has to 
> > be turned on globally for bare ‘import’ statements.  A typical application 
> > has tons of dependencies and all those libraries are also doing module 
> > global imports, so unless lazy loading somehow covers them, it’ll be an 
> > incomplete gain.  But of course it’ll take forever for all your 
> > dependencies to use whatever new API we come up with, and if it’s not as 
> > convenient to write as ‘import foo’ then I suspect it won’t much catch on 
> > anyway.
> >
> 
> One thing to keep in mind is that imports can have important side-effects. 
> Turning every import statement into a lazy import will not be backward 
> compatible.
> 
> Yep, and that's a lesson Mercurial shared with me at PyCon US this year. My 
> planned approach has a blacklist for modules to only load eagerly.

I’m not sure if i understand. Do you want to turn on lazy loading for the 
stdlib only (with a blacklist for modules that won’t work that way), or 
generally? In the latter case this would still not be backward compatible. 

Ronald___
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] What is the design purpose of metaclasses vs code generating decorators? (was Re: PEP 557: Data Classes)

[Ronald Oussoren]

> On 14 Oct 2017, at 16:37, Martin Teichmann  wrote:
> 
>> Things that will not work if Enum does not have a metaclass:
>> 
>> list(EnumClass) -> list of enum members
>> dir(EnumClass)  -> custom list of "interesting" items
>> len(EnumClass)  -> number of members
>> member in EnumClass -> True or False
>> 
>> - protection from adding, deleting, and changing members
>> - guards against reusing the same name twice
>> - possible to have properties and members with the same name (i.e. "value"
>> and "name")
> 
> In current Python this is true. But if we would go down the route of
> PEP 560 (which I just found, I wasn't involved in its discussion),
> then we could just add all the needed functionality to classes.
> 
> I would do it slightly different than proposed in PEP 560:
> classmethods are very similar to methods on a metaclass. They are just
> not called by the special method machinery. I propose that the
> following is possible:
> 
 class Spam:
> ...   @classmethod
> ...   def __getitem__(self, item):
> ...   return "Ham"
> 
 Spam[3]
>Ham
> 
> this should solve most of your usecases.

Except when you want to implement __getitem__ for instances as well :-). An 
important difference between @classmethod and methods on the metaclass is that 
@classmethod methods live in the same namespace as instance methods, while 
methods on the metaclass don’t.

I ran into similar problems in PyObjC: Apple’s Cocoa libraries use instance and 
class methods with the same name. That when using methods on a metaclass, but 
not when using something similar to @classmethod.  Because of this PyObjC is a 
heavy user of metaclasses (generated from C for additional fun). A major 
disadvantage of this is that tends to confuse smart editors. 

Ronald
___
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] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2017-10-13 - 2017-10-20)
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:
  open6260 ( +9)
  closed 37318 (+38)
  total  43578 (+47)

Open issues with patches: 2415 


Issues opened (36)
==

#31761: Failures and crashes when running tests by import in IDLE
https://bugs.python.org/issue31761  reopened by terry.reedy

#31772: SourceLoader uses stale bytecode in case of equal mtime second
https://bugs.python.org/issue31772  reopened by brett.cannon

#31781: crashes when calling methods of an uninitialized zipimport.zip
https://bugs.python.org/issue31781  opened by Oren Milman

#31782: Add a timeout to multiprocessing's Pool.join
https://bugs.python.org/issue31782  opened by Will Starms

#31783: Race condition in ThreadPoolExecutor when scheduling new jobs 
https://bugs.python.org/issue31783  opened by Steven.Barker

#31784: Implementation of the PEP 564: Add time.time_ns()
https://bugs.python.org/issue31784  opened by haypo

#31787: various refleaks when calling the __init__() method of an obje
https://bugs.python.org/issue31787  opened by Oren Milman

#31789: Better error message when failing to overload metaclass.mro
https://bugs.python.org/issue31789  opened by bup

#31790: double free or corruption (while using smem)
https://bugs.python.org/issue31790  opened by zulthan

#31791: Ensure that all PyTypeObject fields are set to non-NULL defaul
https://bugs.python.org/issue31791  opened by pdox

#31793: Allow to specialize smart quotes in documentation translations
https://bugs.python.org/issue31793  opened by mdk

#31794: Issues with test.autotest
https://bugs.python.org/issue31794  opened by serhiy.storchaka

#31798: `site.abs__file__` fails for modules where `__file__` cannot b
https://bugs.python.org/issue31798  opened by Alexander McFarlane

#31800: datetime.strptime: Support for parsing offsets with a colon
https://bugs.python.org/issue31800  opened by mariocj89

#31801: vars() manipulation encounters problems with Enum
https://bugs.python.org/issue31801  opened by ethan.furman

#31802: 'import posixpath' fails if 'os.path' has not be imported alre
https://bugs.python.org/issue31802  opened by Mark.Shannon

#31803: time.clock() should emit a DeprecationWarning
https://bugs.python.org/issue31803  opened by haypo

#31804: multiprocessing calls flush on sys.stdout at exit even if it i
https://bugs.python.org/issue31804  opened by Pox TheGreat

#31805: support._is_gui_available() hangs on x86-64 Sierra 3.6/3.x bui
https://bugs.python.org/issue31805  opened by haypo

#31807: unitest.mock: Using autospec=True conflicts with 'wraps'
https://bugs.python.org/issue31807  opened by John Villalovos

#31808: tarfile.extractall fails to overwrite symlinks
https://bugs.python.org/issue31808  opened by Frederic Beister

#31809: ssl module unnecessarily pins the client curve when using ECDH
https://bugs.python.org/issue31809  opened by gr

#31810: Travis CI, buildbots: run "make smelly" to check if CPython le
https://bugs.python.org/issue31810  opened by haypo

#31811: async and await missing from keyword list in lexical analysis 
https://bugs.python.org/issue31811  opened by Colin Dunklau

#31812: Document PEP 545 (documentation translation) in What's New in 
https://bugs.python.org/issue31812  opened by haypo

#31813: python -m enshure pip stucks
https://bugs.python.org/issue31813  opened by Serhy Pyton

#31814: subprocess_fork_exec more stable with vfork
https://bugs.python.org/issue31814  opened by Albert.Zeyer

#31815: Make itertools iterators interruptible
https://bugs.python.org/issue31815  opened by serhiy.storchaka

#31817: Compilation Error with Python 3.6.1/3.6.3 with Tkinter
https://bugs.python.org/issue31817  opened by jpc2350

#31818: [macOS] _scproxy.get_proxies() crash -- get_proxies() is not f
https://bugs.python.org/issue31818  opened by Mirko Friedenhagen

#31821: pause_reading() doesn't work from connection_made()
https://bugs.python.org/issue31821  opened by pitrou

#31822: Document that urllib.parse.{Defrag,Split,Parse}Result are name
https://bugs.python.org/issue31822  opened by Allen Li

#31823: Opaque default value for close_fds argument in Popen.__init__
https://bugs.python.org/issue31823  opened by Алексей Аверченко

#31824: Missing default argument detail in documentation of StreamRead
https://bugs.python.org/issue31824  opened by PeterLovett

#31826: Misleading __version__ attribute of modules in standard librar
https://bugs.python.org/issue31826  opened by abukaj

#31827: Remove os.stat_float_times()
https://bugs.python.org/issue31827  opened by haypo



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

#31826: Misleading __version__ attribute of modules in standard librar
https://bugs.python.org/issue31826

#31824: Missing default argument detail in documentation of

Re: [Python-Dev] Investigating time for `import requests`

[Brett Cannon]

On Fri, 20 Oct 2017 at 06:42 Ronald Oussoren  wrote:

> Op 10 okt. 2017 om 01:48 heeft Brett Cannon  het
> volgende geschreven:
>
>
>
> On Mon, Oct 2, 2017, 17:49 Ronald Oussoren, 
> wrote:
>
>> Op 3 okt. 2017 om 04:29 heeft Barry Warsaw  het
>> volgende geschreven:
>>
>> > On Oct 2, 2017, at 14:56, Brett Cannon  wrote:
>> >
>> >> So Mercurial specifically is an odd duck because they already do lazy
>> importing (in fact they are using the lazy loading support from importlib).
>> In terms of all of this discussion of tweaking import to be lazy, I think
>> the best approach would be providing an opt-in solution that CLI tools can
>> turn on ASAP while the default stays eager. That way everyone gets what
>> they want while the stdlib provides a shared solution that's maintained
>> alongside import itself to make sure it functions appropriately.
>> >
>> > The problem I think is that to get full benefit of lazy loading, it has
>> to be turned on globally for bare ‘import’ statements.  A typical
>> application has tons of dependencies and all those libraries are also doing
>> module global imports, so unless lazy loading somehow covers them, it’ll be
>> an incomplete gain.  But of course it’ll take forever for all your
>> dependencies to use whatever new API we come up with, and if it’s not as
>> convenient to write as ‘import foo’ then I suspect it won’t much catch on
>> anyway.
>> >
>>
>> One thing to keep in mind is that imports can have important
>> side-effects. Turning every import statement into a lazy import will not be
>> backward compatible.
>>
>
> Yep, and that's a lesson Mercurial shared with me at PyCon US this year.
> My planned approach has a blacklist for modules to only load eagerly.
>
>
> I’m not sure if i understand. Do you want to turn on lazy loading for the
> stdlib only (with a blacklist for modules that won’t work that way), or
> generally?
>

Generally, but provide out of the box a blacklist that already contains
troublesome modules in the stdlib.


> In the latter case this would still not be backward compatible.
>

Correct, which is why it would be opt-in and projects would need to be
diligent in keeping up their blacklist.
___
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