Re: [Python-Dev] cpython: Introduce importlib.util.ModuleManager which is a context manager to
On 29/05/13 01:14, Brett Cannon wrote: On Tue, May 28, 2013 at 5:40 PM, Antoine Pitrou wrote: On Tue, 28 May 2013 23:29:46 +0200 (CEST) brett.cannon wrote: +.. class:: ModuleManager(name) + +A :term:`context manager` which provides the module to load. The module will +either come from :attr:`sys.modules` in the case of reloading or a fresh +module if loading a new module. Proper cleanup of :attr:`sys.modules` occurs +if the module was new and an exception was raised. What use case does this API solve? See http://bugs.python.org/issue18088 for the other part of this story. I'm basically replacing what importlib.util.module_for_loader does after I realized there is no way in a subclass to override what/how attributes are set on a module before the code object is executed. Instead of using the decorator people will be able to use this context manager with a new method to get the same effect with the ability to better control attribute initialization. (FWIW, I think "ModuleManager" is a rather bad name :-) +1. XxxManager is what Java programmers call their classes when they are forced to have an unnecessary class because they don't have 1st class functions or modules. (I don't like 'Context Manager' either, but it's too late to change it :( ) I'm open to suggestions, but the thing does manage the module so it at least makes sense. But what do you mean by managing? 'Manage' has many meanings. Once you've answered that question you should have your name. Cheers, Mark. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Introduce importlib.util.ModuleManager which is a context manager to
Hi, What about ModuleProxy? From the dictionary: prox·y /ˈpräksē/ Noun The authority to represent someone else, esp. in voting. A person authorized to act on behalf of another. Synonyms deputy - representative - agent - substitute Alfredo On 05/30/2013 10:34 AM, Mark Shannon wrote: On 29/05/13 01:14, Brett Cannon wrote: On Tue, May 28, 2013 at 5:40 PM, Antoine Pitrou wrote: On Tue, 28 May 2013 23:29:46 +0200 (CEST) brett.cannon wrote: +.. class:: ModuleManager(name) + + A :term:`context manager` which provides the module to load. The module will + either come from :attr:`sys.modules` in the case of reloading or a fresh + module if loading a new module. Proper cleanup of :attr:`sys.modules` occurs + if the module was new and an exception was raised. What use case does this API solve? See http://bugs.python.org/issue18088 for the other part of this story. I'm basically replacing what importlib.util.module_for_loader does after I realized there is no way in a subclass to override what/how attributes are set on a module before the code object is executed. Instead of using the decorator people will be able to use this context manager with a new method to get the same effect with the ability to better control attribute initialization. (FWIW, I think "ModuleManager" is a rather bad name :-) +1. XxxManager is what Java programmers call their classes when they are forced to have an unnecessary class because they don't have 1st class functions or modules. (I don't like 'Context Manager' either, but it's too late to change it :( ) I'm open to suggestions, but the thing does manage the module so it at least makes sense. But what do you mean by managing? 'Manage' has many meanings. Once you've answered that question you should have your name. Cheers, Mark. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/asolano%40icai.es ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bilingual scripts
On 30 May 2013 04:40, "Barry Warsaw" wrote: > > On May 29, 2013, at 01:01 PM, Nick Coghlan wrote: > > >PEP 432 is also related, as it includes the "pysystem" proposal [1] > >(an alternate Python CLI that will default to -Es behaviour, but is > >otherwise similar to the standard "python" interpreter). > > I *knew* this was being specified somewhere, but I couldn't find it in either > the tracker or PEP summary. As an aside Nick, what do you think about > splitting the pysystem proposal out of PEP 432? I think they could certainly > live as independent PEPs albeit perhaps the pysystem one dependent on 432. Sure. You could probably even implement it without PEP 432, it would just be somewhat painful to replicate the current CLI behaviour. Cheers, Nick. > > > >The rest of the discussion though makes me think we may actually need > >a *nix equivalent of PEP 397 (which describes the "py" launcher we > >created to get around the limitations of Windows file associations). > > Perhaps! > > >Between that and the interpreter identification mechanism defined for > >the PEP 425 compatibility tags it should be possible to come up with > >an upstream solution for 3.4 that the distros can backport to work > >with earlier versions (similar to the way users can download the > >Windows launcher directly from > >https://bitbucket.org/pypa/pylauncher/downloads even though we only > >started shipping it upstream as part of the Python 3.3 installer) > > We're getting pretty close to a real idea here. :) > > -Barry > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Introduce importlib.util.ModuleManager which is a context manager to
On 30 May 2013 06:25, "Brett Cannon" wrote: > > On Wed, May 29, 2013 at 2:56 PM, R. David Murray wrote: > > On Wed, 29 May 2013 20:10:44 +0200, Antoine Pitrou wrote: > >> On Wed, 29 May 2013 12:55:01 -0400 > >> Brett Cannon wrote: > >> > > Perhaps 'managed_module'? > >> > > >> > managed_module is better than managed_initialization. > >> > >> I don't understand how it's "managed". "manage", "manager", etc. is the > >> kind of dumb words everybody uses when they don't manage (!) to explain > >> what they're talking about. > >> > >> My vote is for "module_to_init", "uninitialized_module", > >> "pristine_module", etc. > > I don't like unititionalized_module or pristine_module as that isn't > guaranteed thanks to reloading; seems misleading. > > > > > Actually, you are right, 'managed_module' isn't much if any better > > than those. > > > > Our problem is that there are two concepts we are trying to cram into > > one name: what the context manager is managing, and the object that the > > context manager gives you on entry to the with block. There probably > > isn't a good answer. > > > > I suppose that one approach would be to have a module_initializer context > > manager return self and then separately call a method on it it to actually > > load the module inside the with body. But adding more typing to solve > > a naming issue seems...odd. > > That would make me feel icky, so I won't do it. > > So module_to_init it is unless someone can convince me the bikeshed is > a different colour. +1 to that bikeshed colour. It covers what we're returning (a module) and what we plan to do with it that needs a with statement (initialising it). Cheers, Nick. > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Segmentation fault on 3.4 with --pydebug
This happens after Benjamin's changes in 83937. Anybody else seeing this? Intel i5 2.4 GHz, Mac OS X 10.8.3, clang $ hg up default $ make distclean $ MACOSX_DEPLOYMENT_TARGET=10.8 ./configure --with-pydebug $ make $ ./python.exe -Wd -m test.regrtest test_exceptions [1/1] test_exceptions Fatal Python error: Segmentation fault Current thread 0x7fff74254180: File "/Users/ambv/Documents/Projekty/Python/cpython/py34/Lib/test/test_exceptions.py", line 453 in f File "/Users/ambv/Documents/Projekty/Python/cpython/py34/Lib/test/test_exceptions.py", line 453 in f File "/Users/ambv/Documents/Projekty/Python/cpython/py34/Lib/test/test_exceptions.py", line 453 in f ... (repeated a 100 times) Command terminated abnormally. Everything runs fine without --with-pydebug (or before 83937 with --with-pydebug). -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Segmentation fault on 3.4 with --pydebug
No for me: $ ./python -Wd -m test.regrtest test_exceptions [1/1] test_exceptions 1 test OK. $ uname -a Linux 3.2.0-32-generic #51-Ubuntu SMP Wed Sep 26 21:32:50 UTC 2012 i686 i686 i386 GNU/Linux Please look at issue18075 2013/5/30 Łukasz Langa : > This happens after Benjamin's changes in 83937. Anybody else seeing this? > > Intel i5 2.4 GHz, Mac OS X 10.8.3, clang > > $ hg up default > $ make distclean > $ MACOSX_DEPLOYMENT_TARGET=10.8 ./configure --with-pydebug > $ make > $ ./python.exe -Wd -m test.regrtest test_exceptions > [1/1] test_exceptions > Fatal Python error: Segmentation fault > > Current thread 0x7fff74254180: > File > "/Users/ambv/Documents/Projekty/Python/cpython/py34/Lib/test/test_exceptions.py", > line 453 in f > File > "/Users/ambv/Documents/Projekty/Python/cpython/py34/Lib/test/test_exceptions.py", > line 453 in f > File > "/Users/ambv/Documents/Projekty/Python/cpython/py34/Lib/test/test_exceptions.py", > line 453 in f > ... (repeated a 100 times) > Command terminated abnormally. > > > > Everything runs fine without --with-pydebug (or before 83937 with > --with-pydebug). > > -- > Best regards, > Łukasz Langa > > WWW: http://lukasz.langa.pl/ > Twitter: @llanga > IRC: ambv on #python-dev > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/dmi.baranov%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Segmentation fault on 3.4 with --pydebug
What's the stack trace? $> gdb --args ./python.exe -Wd -m test.regrtest test_exceptions and once in gdb: gdb> bt That should point on where it happened. I hope this help On 2013-05-30 13:08, Łukasz Langa wrote: This happens after Benjamin's changes in 83937. Anybody else seeing this? Intel i5 2.4 GHz, Mac OS X 10.8.3, clang $ hg up default $ make distclean $ MACOSX_DEPLOYMENT_TARGET=10.8 ./configure --with-pydebug $ make $ ./python.exe -Wd -m test.regrtest test_exceptions [1/1] test_exceptions Fatal Python error: Segmentation fault Current thread 0x7fff74254180: File "/Users/ambv/Documents/Projekty/Python/cpython/py34/Lib/test/test_exceptions.py", line 453 in f File "/Users/ambv/Documents/Projekty/Python/cpython/py34/Lib/test/test_exceptions.py", line 453 in f File "/Users/ambv/Documents/Projekty/Python/cpython/py34/Lib/test/test_exceptions.py", line 453 in f ... (repeated a 100 times) Command terminated abnormally. Everything runs fine without --with-pydebug (or before 83937 with --with-pydebug). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Segmentation fault on 3.4 with --pydebug
On 30 May, 2013, at 13:08, Łukasz Langa wrote: > This happens after Benjamin's changes in 83937. Anybody else seeing this? > > Intel i5 2.4 GHz, Mac OS X 10.8.3, clang > > $ hg up default > $ make distclean > $ MACOSX_DEPLOYMENT_TARGET=10.8 ./configure --with-pydebug > $ make > $ ./python.exe -Wd -m test.regrtest test_exceptions > [1/1] test_exceptions > Fatal Python error: Segmentation fault > > Current thread 0x7fff74254180: > File > "/Users/ambv/Documents/Projekty/Python/cpython/py34/Lib/test/test_exceptions.py", > line 453 in f > File > "/Users/ambv/Documents/Projekty/Python/cpython/py34/Lib/test/test_exceptions.py", > line 453 in f > File > "/Users/ambv/Documents/Projekty/Python/cpython/py34/Lib/test/test_exceptions.py", > line 453 in f > ... (repeated a 100 times) > Command terminated abnormally. > > > > Everything runs fine without --with-pydebug (or before 83937 with > --with-pydebug). Issue #18075 contains a patch. I probably won't have time to commit until sunday, but feel free to apply the patch yourself :-) Ronald ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Introduce importlib.util.ModuleManager which is a context manager to
On 05/30/2013 03:34 AM, Mark Shannon wrote: On 29/05/13 01:14, Brett Cannon wrote: On Tue, May 28, 2013 at 5:40 PM, Antoine Pitrou wrote: On Tue, 28 May 2013 23:29:46 +0200 (CEST) brett.cannon wrote: +.. class:: ModuleManager(name) + +A :term:`context manager` which provides the module to load. The module will +either come from :attr:`sys.modules` in the case of reloading or a fresh +module if loading a new module. Proper cleanup of :attr:`sys.modules` occurs +if the module was new and an exception was raised. (FWIW, I think "ModuleManager" is a rather bad name :-) +1. XxxManager is what Java programmers call their classes when they are forced to have an unnecessary class because they don't have 1st class functions or modules. (I don't like 'Context Manager' either, but it's too late to change it :( ) I'm open to suggestions, but the thing does manage the module so it at least makes sense. But what do you mean by managing? 'Manage' has many meanings. Once you've answered that question you should have your name. It manages the context, as in the above reference to context manager. In this case the context is the loading and unloading of a module. Having context managers names end with manager helps indicate how it's used. But other verb+er combinations also work. Taking a hint from the first few words of the __doc__ string gives us an obvious alternative. ModuleProvider Cheers, Ron ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Segmentation fault on 3.4 with --pydebug
2013/5/30 Łukasz Langa : > This happens after Benjamin's changes in 83937. Anybody else seeing this? Remember you need the hash to fully identify hg changesets. :) > > Intel i5 2.4 GHz, Mac OS X 10.8.3, clang > > $ hg up default > $ make distclean > $ MACOSX_DEPLOYMENT_TARGET=10.8 ./configure --with-pydebug > $ make > $ ./python.exe -Wd -m test.regrtest test_exceptions > [1/1] test_exceptions > Fatal Python error: Segmentation fault As noted, it's infinite recursion. Without optimization I've noticed clang is very inefficient with respect to stack space, so for example, each PyEval_FrameEx frame is 1/2 KB. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Segmentation fault on 3.4 with --pydebug
On 30 maj 2013, at 14:45, Ronald Oussoren wrote: > Issue #18075 contains a patch. I probably won't have time to commit until > sunday, but feel free to apply the patch yourself :-) I did just that. Fixed, thanks! -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] performance testing recommendations in devguide
Hi, On Wed, May 29, 2013 at 9:00 PM, Eric Snow wrote: > ... > > What would be important to say in the devguide regarding Python > performance and testing it? In the devguide I would only add information that are specific to benchmarking the interpreter. A separate "Benchmarking HOWTO" that covers generic topics could/should be added to docs.python.org. Best Regards, Ezio Melotti > What would you add/subtract from the > above? How important is testing memory performance? How do we avoid > performance regressions? Thanks! > > -eric ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 443 - Single-dispatch generic functions (including ABC support)
On 29 maj 2013, at 04:40, Nick Coghlan wrote:
> I expect we will see improved tools for integrating class based
> dispatch and generic function dispatch in the future, but we should
> *not* try to engineer a solution up front. Doing so would involve too
> much guessing about possible use cases, rather than letting the design
> be informed by the *actual* use cases that emerge in practice.
I thought about this over the last two days and I've concluded Nick
is right here. I really don't want functools.singledispatch to be
undercooked when introduced. However, it seems we fleshed out the PEP
and the reference implementation to do one thing only, and do it well.
The rest is guesswork. It's better to build on a simple foundation than
to provide a solution waiting for the problem (see: annotations).
So, unless anyone strongly objects, I think we shouldn't bother to
special-case instance methods and class methods.
"Code wins arguments":
class State:
def __init__(self):
self.add.register(int, self.add_int)
self.add.register(float, self.add_float)
self.add.register(complex, self.add_complex)
self.sum = 0
@staticmethod
@singledispatch
def add(arg):
raise TypeError("This type is not supported.")
def add_int(self, arg):
self.sum += arg
def add_float(self, arg):
self.sum += int(round(arg))
def add_complex(self, arg):
self.sum += int(round(arg.real))
if __name__ == '__main__':
state = State()
state.add(1)
state.add(2.51)
state.add(3.7+4j)
assert state.sum == 8
state.add(2.50)
assert state.sum == 10
try:
state.add("string")
assert False, "TypeError not raised."
except TypeError:
pass # properly refused to add a string
--
Best regards,
Łukasz Langa
WWW: http://lukasz.langa.pl/
Twitter: @llanga
IRC: ambv on #python-dev
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 443 - Single-dispatch generic functions (including ABC support)
On 31 maj 2013, at 01:47, Łukasz Langa wrote: > class State: >def __init__(self): >self.add.register(int, self.add_int) Ouch, I realized this is wrong just after I hit "Send". self.add is a staticmethod so this registration will overload on every instance. Which is obviously bad. Lesson learned: don't post code at 2 AM. -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 443 - Single-dispatch generic functions (including ABC support)
On 31 maj 2013, at 01:51, Łukasz Langa wrote: > On 31 maj 2013, at 01:47, Łukasz Langa wrote: > >> class State: >>def __init__(self): >>self.add.register(int, self.add_int) > > Ouch, I realized this is wrong just after I hit "Send". > self.add is a staticmethod so this registration will overload > on every instance. Which is obviously bad. So, after some embarrassing head banging, here's the correct solution: https://gist.github.com/ambv/5682351 So, it *is* possible to make instance-level and class-level registration work with the existing @singledispatch code and a bit of plumbing. Obviously, all that is not necessary for actual static methods. Back to the point, though. I don't feel we should complicate the code, tests and documentation by introducing special handling for methods. In terms of pure type-driven single dispatch, we have a solution that was intentionally simple from the get-go. The next step will be predicate dispatch anyway ;)) What do you think? -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 443 - Single-dispatch generic functions (including ABC support)
On Fri, 2013-05-31 at 03:05 +0200, Łukasz Langa wrote: > On 31 maj 2013, at 01:51, Łukasz Langa wrote: > > Back to the point, though. I don't feel we should complicate the > code, tests and documentation by introducing special handling > for methods. In terms of pure type-driven single dispatch, we > have a solution that was intentionally simple from the get-go. > > The next step will be predicate dispatch anyway ;)) > > What do you think? +1. It's incredibly useful and easy to document as-is. - C ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
