Mailman 3 April 2018 - Python-ideas

Add more information in the header of pyc files
by Serhiy Storchaka April 11, 2018

April 11, 2018

The format of the header of pyc files was stable for long time and changed only few times. First time it was changed in 3.3: added the size of the corresponding source mod 2**32. [1] Second time it was changed in 3.7: added the 32-bit flags field and support of hash-based pyc files (PEP 552). [2] [3] I think that it is worth to make more changed. 1. More stable file signature. Currently the magic number is changed in every feature release. Only the third and the forth bytes are stable (b'\r\n'), the first bytes are changed non-predicable. The 'py' launcher and third-party software like the 'file' command should support the list of magic numbers for all existing Python releases, and they can't detect pyc file for future versions. There is also a chance the pyc file signature will match the signature of other file type by accident. It would be better if the first 4 bytes of pyc files be same for all Python versions (or at least for all Python versions with the same major number). 2. Include the Python version. Currently the 'py' launcher needs to support the table that maps magic numbers to Python version. It can recognize only Python versions released before building the launcher. If the two major numbers of Python version be included in the version, it would not need such table. 3. The number of compatible subversion. Currently the interpreter supports only a single magic number. If the updated version of the compiler produces more optimal or more correct but compatible bytecode (like ), there is no way to say that the new bytecode is preferable, but the old bytecode can be used too. Changing the magic number causes invalidating all pyc files compiled by the old compiler (see [4] for the example of problems caused by this). The header could contain two magic numbers: the major magic number should be bumped for incompatible changes, the minor magic number should be reset to 0 when the major magic number is bumped, and should be bumped when the compiler become producing different but compatible bytecode. If the import system reads the pyc file with the minor magic number equal or greater than current, it just uses the pyc file. If it reads the pyc file with the minor magic number lesser than current, it can regenerate the pyc file if it is writeable. And the compileall module should regenerate all pyc files with minor magic numbers lesser than current. [1] https://bugs.python.org/issue13645 [2] https://bugs.python.org/issue31650 [3] http://www.python.org/dev/peps/pep-0552/ [4] https://bugs.python.org/issue27286

3 4

Re: [Python-ideas] Python-ideas Digest, Vol 137, Issue 40
by Thautwarm Zhao April 11, 2018

April 11, 2018

I think Guido has given a direct answer why dict unpacking is not supported in syntax level, I can take it and I think it's better to implement a function for dict unpacking in standard library, just like from dict_unpack import dict_unpack, pattern as pat some_dict = {'a': {'b': {'c': 1}, 'd':2}, 'e': 3} extracted = dict_unpack(some_dict, schema = {'a': {'b': {'c': pat('V1')}, 'd': pat('V2')}, 'e': pat('V3')}) # extract to a flatten dictionary v1, v2, v3 = (extracted[k] for k in ('V1', 'V2', 'V3')) assert (v1, v2, v3) == (1, 2, 3) As for Steve's confusion, > > {key: value_pattern, **_} = {key: value, **_} > If I saw that, I would have no idea what it could even possibly do. > Let's pick the simplest concrete example I can think of: > > {'A': 1, **{}} = {'A': 0, **{}} > > I cannot interpret what that should do. Is it some sort of > pattern-matching? An update? What is the result? It is obviously some > sort of binding operation, an assignment, but an assignment to what? {'A': 1, **{}} = {'A': 0, **{}} should be just wrong because for any k-v pair at LHS, the key should be a expression and the value is for unpacking. {'A': [*a, b]} = {'A': [1, 2, 3]} is welcome, but {'A': 1} = {'A': '1'} is also something like pattern matching which is out of our topic. Anyway, this feature will not come true, let's forget it... I think Jacco is totally correct in following words. > I think most of these problems could be solved with pop and the > occasional list comprehension like this: > > a, b, c = [{'a':1,'b':2,'c':3}.pop(key) for key in ('a', 'b', 'c')] > > or for your example: > > c = {'a': 1, **{'b': 2}} # I suppose this one would generally > # be dynamic, but I need a name here. > a, b = [c.pop(key) for key in ('a', 'b')] > > would extract all the keys you need, and has the advantage that > you don't need hardcoded dict structure if you expand it to nested > dicts. It's even less writing, and just as extensible to nested dicts. > And if you dont actually want to destruct (tuples and lists aren't > destroyed either), just use __getitem__ access instead of pop. But pop cannot work for a nested case. Feel free to end this topic. thautwarm 2018-04-10 23:20 GMT+08:00 <python-ideas-request(a)python.org>: > Send Python-ideas mailing list submissions to > python-ideas(a)python.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.python.org/mailman/listinfo/python-ideas > or, via email, send a message with subject or body 'help' to > python-ideas-request(a)python.org > > You can reach the person managing the list at > python-ideas-owner(a)python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Python-ideas digest..." > > Today's Topics: > > 1. Re: Is there any idea about dictionary destructing? > (Steven D'Aprano) > 2. Re: Is there any idea about dictionary destructing? > (Jacco van Dorp) > 3. Re: Start argument for itertools.accumulate() [Was: Proposal: > A Reduce-Map Comprehension and a "last" builtin] (Guido van Rossum) > 4. Re: Is there any idea about dictionary destructing? > (Guido van Rossum) > > > ---------- 已转发邮件 ---------- > From: "Steven D'Aprano" <steve(a)pearwood.info> > To: python-ideas(a)python.org > Cc: > Bcc: > Date: Tue, 10 Apr 2018 19:21:35 +1000 > Subject: Re: [Python-ideas] Is there any idea about dictionary destructing? > On Tue, Apr 10, 2018 at 03:29:08PM +0800, Thautwarm Zhao wrote: > > > I'm focused on the consistency of the language itself. > > Consistency is good, but it is not the only factor to consider. We must > guard against *foolish* consistency: adding features just for the sake > of matching some other, often barely related, feature. Each feature must > justify itself, and consistency with something else is merely one > possible attempt at justification. > > > > {key: value_pattern, **_} = {key: value, **_} > > If I saw that, I would have no idea what it could even possibly do. > Let's pick the simplest concrete example I can think of: > > {'A': 1, **{}} = {'A': 0, **{}} > > I cannot interpret what that should do. Is it some sort of > pattern-matching? An update? What is the result? It is obviously some > sort of binding operation, an assignment, but an assignment to what? > > Sequence binding and unpacking was obvious the first time I saw it. I > had no problem guessing what: > > a, b, c = 1, 2, 3 > > meant, and once I had seen that, it wasn't hard to guess what > > a, b, c = *sequence > > meant. From there it is easy to predict extended unpacking. But I can't > say the same for this. > > I can almost see the point of: > > a, b, c, = **{'a': 1, 'b': 2, 'c': 3} > > but I'm having trouble thinking of a situation where I would actually > use it. But your syntax above just confuses me. > > > > The reason why it's important is that, when destructing/constructing for > > built-in data structures are not supported completely, > > people might ask why "[a, *b] = c" is ok but "{"a": a, **b} = c" not. > > People can ask all sorts of questions. I've seen people ask why Python > doesn't support line numbers and GOTO. We're allowed to answer "Because > it is a bad idea", or even "Because we don't think it is good enough to > justify the cost". > > > > If only multiple assignment is supported, why "(a, (b, c)) = d" could be > > ok? It's exactly destructing! > > That syntax is supported. I don't understand your point here. > > > > >> {'a': a, 'b': b, **c} = {'a': 1, **{'b': 2}} > > SyntaxError: can't assign to literal > > > > Above example could be confusing in some degree, I think. > > I have no idea what you expect it to do. Even something simpler: > > {'a': a} = {'a': 2} > > leaves me in the dark. > > > > > -- > Steve > > > > ---------- 已转发邮件 ---------- > From: Jacco van Dorp <j.van.dorp(a)deonet.nl> > To: python-ideas(a)python.org > Cc: > Bcc: > Date: Tue, 10 Apr 2018 11:52:40 +0200 > Subject: Re: [Python-ideas] Is there any idea about dictionary destructing? > I must say I can't really see the point either. If you say like: > > > {'a': a, 'b': b, **c} = {'a': 1, **{'b': 2}} > > Do you basically mean: > > c = {'a': 1, **{'b': 2}} > a = c.pop("a") > b = c.pop("b") # ? > > That's the only thing I could think of. > > I think most of these problems could be solved with pop and the > occasional list comprehension like this: > > a, b, c = [{'a':1,'b':2,'c':3}.pop(key) for key in ('a', 'b', 'c')] > > or for your example: > > c = {'a': 1, **{'b': 2}} # I suppose this one would generally > # be dynamic, but I need a name here. > a, b = [c.pop(key) for key in ('a', 'b')] > > would extract all the keys you need, and has the advantage that > you don't need hardcoded dict structure if you expand it to nested > dicts. It's even less writing, and just as extensible to nested dicts. > And if you dont actually want to destruct (tuples and lists aren't > destroyed either), just use __getitem__ access instead of pop. > > 2018-04-10 11:21 GMT+02:00 Steven D'Aprano <steve(a)pearwood.info>: > > On Tue, Apr 10, 2018 at 03:29:08PM +0800, Thautwarm Zhao wrote: > > > >> I'm focused on the consistency of the language itself. > > > > Consistency is good, but it is not the only factor to consider. We must > > guard against *foolish* consistency: adding features just for the sake > > of matching some other, often barely related, feature. Each feature must > > justify itself, and consistency with something else is merely one > > possible attempt at justification. > > > > > >> {key: value_pattern, **_} = {key: value, **_} > > > > If I saw that, I would have no idea what it could even possibly do. > > Let's pick the simplest concrete example I can think of: > > > > {'A': 1, **{}} = {'A': 0, **{}} > > > > I cannot interpret what that should do. Is it some sort of > > pattern-matching? An update? What is the result? It is obviously some > > sort of binding operation, an assignment, but an assignment to what? > > > > Sequence binding and unpacking was obvious the first time I saw it. I > > had no problem guessing what: > > > > a, b, c = 1, 2, 3 > > > > meant, and once I had seen that, it wasn't hard to guess what > > > > a, b, c = *sequence > > > > meant. From there it is easy to predict extended unpacking. But I can't > > say the same for this. > > > > I can almost see the point of: > > > > a, b, c, = **{'a': 1, 'b': 2, 'c': 3} > > > > but I'm having trouble thinking of a situation where I would actually > > use it. But your syntax above just confuses me. > > > > > >> The reason why it's important is that, when destructing/constructing for > >> built-in data structures are not supported completely, > >> people might ask why "[a, *b] = c" is ok but "{"a": a, **b} = c" not. > > > > People can ask all sorts of questions. I've seen people ask why Python > > doesn't support line numbers and GOTO. We're allowed to answer "Because > > it is a bad idea", or even "Because we don't think it is good enough to > > justify the cost". > > > > > >> If only multiple assignment is supported, why "(a, (b, c)) = d" could be > >> ok? It's exactly destructing! > > > > That syntax is supported. I don't understand your point here. > > > > > >> >> {'a': a, 'b': b, **c} = {'a': 1, **{'b': 2}} > >> SyntaxError: can't assign to literal > >> > >> Above example could be confusing in some degree, I think. > > > > I have no idea what you expect it to do. Even something simpler: > > > > {'a': a} = {'a': 2} > > > > leaves me in the dark. > > > > > > > > > > -- > > Steve > > _______________________________________________ > > Python-ideas mailing list > > Python-ideas(a)python.org > > https://mail.python.org/mailman/listinfo/python-ideas > > Code of Conduct: http://python.org/psf/codeofconduct/ > > > > ---------- 已转发邮件 ---------- > From: Guido van Rossum <guido(a)python.org> > To: "Stephen J. Turnbull" <turnbull.stephen.fw(a)u.tsukuba.ac.jp> > Cc: Tim Peters <tim.peters(a)gmail.com>, Python-Ideas < > python-ideas(a)python.org> > Bcc: > Date: Tue, 10 Apr 2018 08:05:18 -0700 > Subject: Re: [Python-ideas] Start argument for itertools.accumulate() > [Was: Proposal: A Reduce-Map Comprehension and a "last" builtin] > On Mon, Apr 9, 2018 at 11:35 PM, Stephen J. Turnbull < > turnbull.stephen.fw(a)u.tsukuba.ac.jp> wrote: > >> Tim Peters writes: >> >> > "Sum reduction" and "running-sum accumulation" are primitives in >> > many peoples' brains. >> >> I wonder what Kahneman would say about that. He goes to some length >> to explain that people are quite good (as human abilities go) at >> perceiving averages over sets but terrible at summing the same. Maybe >> they substitute the abstraction of summation for the ability to >> perform the operation? >> > > [OT] How is that human ability tested? I am a visual learner and I would > propose that if you have a set of numbers, you can graph it in different > ways to make it easier to perceive one or the other (or maybe both): > > - to emphasize the average, draw a line graph -- in my mind I draw a line > through the average (getting the trend for free) > - to emphasize the sum, draw a histogram -- in my mind I add up the sizes > of the bars > > -- > --Guido van Rossum (python.org/~guido) > > > ---------- 已转发邮件 ---------- > From: Guido van Rossum <guido(a)python.org> > To: Python-Ideas <python-ideas(a)python.org> > Cc: > Bcc: > Date: Tue, 10 Apr 2018 08:20:11 -0700 > Subject: Re: [Python-ideas] Is there any idea about dictionary destructing? > Here's one argument why sequence unpacking is more important than dict > unpacking. > > Without sequence unpacking, you have a long sequence, to get at a specific > item you'd need to use indexing, where you often end up having to remember > the indices for each type of information. Say you have points of the form > (x, y, z, t), to get at the t coordinate you'd have to write p[3]. With > sequence unpacking you can write > > x, y, z, t = p > > and then you can use the individual variables in the subsequent code. > > However if your point had the form {'x': x, 'y': y, 'z': z, 't': t}, you > could just write p['t']. This is much more mnemonic than p[3]. > > All the rest follows -- after a while extended forms of iterable unpacking > start making sense. But for dicts the use case is just much less common. > > (If you're doing a lot of JSON you might have a different view on that. > You should probably use some kind of schema-guided parser though.) > > -- > --Guido van Rossum (python.org/~guido) > > _______________________________________________ > Python-ideas mailing list > Python-ideas(a)python.org > https://mail.python.org/mailman/listinfo/python-ideas > >

1 0

Is there any idea about dictionary destructing?
by thautwarm April 10, 2018

April 10, 2018

We know that Python support the destructing of iterable objects. m_iter = (_ for _ in range(10)) a, *b, c = m_iter That's pretty cool! It's really convenient when there're many corner cases to handle with iterable collections. However destructing in Python could be more convenient if we support dictionary destructing. In my opinion, dictionary destructing is not difficult to implement and makes the syntax more expressive. A typical example is data access on nested data structures(just like JSON), destructing a dictionary makes the logic quite clear: data = { "direct": "some data", "nested": { "lst_data": [1, 2, 3], "int_data": 1 } } { "direct": direct, "nested": { "lst_data": [a, b, c], } } = data Dictionary destructing might not be very well-known but it really helps. The operations on nested key-value collections are very frequent, and the codes for business logic are not readable enough until now. Moreover Python is now popular in data processing which must be enhanced by the entire support of data destructing. Here are some implementations of other languages: Elixir, which is also a popular dynamic language nowadays. iex> %{} = %{:a => 1, 2 => :b} %{2 => :b, :a => 1} iex> %{:a => a} = %{:a => 1, 2 => :b} %{2 => :b, :a => 1} iex> a 1 iex> %{:c => c} = %{:a => 1, 2 => :b} ** (MatchError) no match of right hand side value: %{2 => :b, :a => 1} And in F#, there is something similar to dictionary destructing(actually, this destructs `struct` instead) type MyRecord = { Name: string; ID: int } let IsMatchByName record1 (name: string) = match record1 with | { MyRecord.Name = nameFound; MyRecord.ID = _; } when nameFound = name -> true | _ -> false let recordX = { Name = "Parker"; ID = 10 } let isMatched1 = IsMatchByName recordX "Parker" let isMatched2 = IsMatchByName recordX "Hartono" All of them partially destructs(or matches) a dictionary. thautwarm

9 11

Fwd: Is there any idea about dictionary destructing?
by Thautwarm Zhao April 9, 2018

April 9, 2018

I'm sorry that I didn't send a copy of the discussions here. ---------- Forwarded message ---------- From: Thautwarm Zhao <yaoxiansamma(a)gmail.com> Date: 2018-04-09 1:24 GMT+08:00 Subject: Re: [Python-ideas] Is there any idea about dictionary destructing? To: "Eric V. Smith" <eric(a)trueblade.com> Thank you, Eric. Your links really help me and I've investigated it carefully. After reading them, I found the discussion almost focused on a non-nested data structure. The flatten key-value pairs might be easily replaced by something like x, y, z = [some_dict[k] for k in ('a', 'b', 'c')] I couldn't agree more but, when it comes to nested, some_dict = { 'a': { 'b': { 'c': V1}, 'e': V2 }, 'f': V3 } I agree that there could be other ways as intuitive as the dict destructing to get `V1, V2, V3` instead, however dict destructing refers to the consistency of Python language behaviours. When I'm writing these codes: [a, *b] = [1, 2, 3] The LHS is actually equals to RHS, and if we implement a way to apply this on dictionary {'a': a, 'b': b, '@': c, **other} = {'a': 1, 'b': 2, '@': 3, '*': 4} It also presents that LHS equals to RHS. Dict destructing/constructing is totally compatible to Python unpack/pack, just as what iterable destructing/constructing does. It's neat when we talk about Python's data structures we can talk about the consistency, readability and the expression of intuition. In the real world, the following one could really help when it comes to the field of data storage. some_dict = {'a': [1, 2, 3, {"d": 4, "f": 5}]} {'a': [b, *c, {"d": e, **_}]} = some_dict The LHS doesn't only show the structure of some variable intuitively(this makes review easier, too), but also supplies a way to access data in fewer codes. In the previous talk people have shown multiple usages of dict destructing in real world: - Django Rest Framework validate - Load config files and use them, specifically Yaml/JSON data access. In fact, any other operation on dictionary than simply getting a value from a key might needs dict destructing, just when the task is complicated enough. I do think the usages are general enough now to make us allow similar syntax to do above tasks. P.S: Some other advices in the previous talk like the following: 'a' as x, 'b' as y, 'c' as z = some_dict 'a': x, 'b': y, 'c': z = some_dict mode, height, width = **prefs Either of them conflicts against the current syntax, or does mismatch the consistency of Python language(LHS != RHS). thautwarm 2018-04-08 5:39 GMT+08:00 Eric V. Smith <eric(a)trueblade.com>: > There was a long thread last year on a subject, titled "Dictionary > destructing and unpacking.": > https://mail.python.org/pipermail/python-ideas/2017-June/045963.html > > You might want to read through it and see what ideas and problems were > raised then. > > In that discussion, there's also a link to an older pattern matching > thread: > https://mail.python.org/pipermail/python-ideas/2015-April/032907.html > > Eric > > On 4/7/2018 1:26 PM, thautwarm wrote: > >> We know that Python support the destructing of iterable objects. >> >> m_iter= (_for _in range(10)) >> a,*b, c= m_iter >> >> That's pretty cool! It's really convenient when there're many corner >> cases to handle with iterable collections. >> However destructing in Python could be more convenient if we support >> dictionary destructing. >> >> In my opinion, dictionary destructing is not difficult to implement and >> makes the syntax more expressive. A typical example is data access on >> nested data structures(just like JSON), destructing a dictionary makes the >> logic quite clear: >> >> data= { >> "direct": "some data", >> "nested": { >> "lst_data": [1,2,3], >> "int_data": 1 >> } >> } >> { >> "direct": direct, >> "nested": { >> "lst_data": [a, b, c], >> } >> }= data >> >> >> Dictionary destructing might not be very well-known but it really helps. >> The operations on nested key-value collections are very frequent, and the >> codes for business logic are not readable enough until now. Moreover Python >> is now popular in data processing which must be enhanced by the entire >> support of data destructing. >> >> Here are some implementations of other languages: >> Elixir, which is also a popular dynamic language nowadays. >> >> |iex> %{} = %{:a => 1, 2 => :b} %{2 => :b, :a => 1} iex> %{:a => a} = >> %{:a => 1, 2 => :b} %{2 => :b, :a => 1} iex> a 1 iex> %{:c => c} = %{:a => >> 1, 2 => :b} ** (MatchError) no match of right hand side value: %{2 => :b, >> :a => 1}| >> >> And in F#, there is something similar to dictionary destructing(actually, >> this destructs `struct` instead) >> type MyRecord = { Name: string; ID: int } letIsMatchByName record1 (name: >> string) = matchrecord1 with| { MyRecord.Name = nameFound; MyRecord.ID = _; >> } whennameFound = name -> true| _ -> falseletrecordX = { Name = "Parker"; >> ID = 10} letisMatched1 = IsMatchByName recordX "Parker"letisMatched2 = >> IsMatchByName recordX "Hartono" >> >> All of them partially destructs(or matches) a dictionary. >> >> thautwarm >> >> >> >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas(a)python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ >> >>

1 0

PEP draft: Unifying function/method classes
by Jeroen Demeyer April 3, 2018

April 3, 2018

I have prepared a PEP draft for unifying function/method classes. You can find it at https://github.com/jdemeyer/PEP-functions This has not officially been submitted as PEP yet, I want to hear your comments first. Thanks, Jeroen.

7 6

Re: [Python-ideas] PEP draft: Unifying function/method classes
by Jeroen Demeyer April 2, 2018

April 2, 2018

On 2018-04-02 12:39, INADA Naoki wrote: > Thanks for writing such hard PEP. > > At first glance, it new type hierarchy seems OK. > But I can't understand rational for new flags. Which flags in particular do you mean? I just pushed an update explaining the rationale of METH_ARG0_FUNCTION: https://github.com/jdemeyer/PEP-functions#replacing-tp_call-meth_arg0_funct… > And it's very difficult to estimate runtime and maintenance cost of > the PEP, without draft implementation. Runtime cost: the goal is no slowdowns at all. Maintenance cost: IMHO, this PEP simplifies functions in CPython by removing special classes like method_descriptor so the effect should only be in the good sense. > FASTCALL is introduced in recently version, and it make implementation > complicated. > I'm afraid that this PEP make it worse. What do you mean? I am not making any changes to METH_FASTCALL. I only mention it in my PEP to document it. Jeroen.

2 1

Generalized version of contextlib.close
by Roberto Martínez April 2, 2018

April 2, 2018

Hi, sometimes I need to use contextlib.close but over methods with a different name, for example stop(), halt(), etc. For those cases I have to write my own contextlib.close specialized version with a hard-coded method name. I think adding a "method" argument to contextlib.close can be very useful: @contextmanager def closing(thing, method="close"): try: yield thing finally: getattr(thing, method)() Or maybe something even more generic: @contextmanager def calling(fn, *args, **kwargs): try: yield finally: fn(*args, **kwargs) Best regards, Roberto

4 3

Re: [Python-ideas] PEP draft: Unifying function/method classes
by Jeroen Demeyer April 1, 2018

April 1, 2018

On 2018-03-31 18:09, Steven D'Aprano wrote: > It seems like a huge amount of work What is a huge amount of work? Writing the PEP? Implementing the PEP? Using the PEP? Adapting existing Python code to the PEP? > Why isn't the answer to provide a hook to support introspection? That is a lot easier said than done. How would you do that? The problem is that multiple classes are involved, at least "builtin_function_or_method" and "method_descriptor". So you'll end up with at least 3 classes (those 2 plus the existing "function") supporting introspection. With my proposal, this is implemented only once. And do you expect users to implement those hooks or do you expect Python to do it? If you want to do it in Python, you'll need to add a new class anyway. That doesn't look simpler than my PEP. That being said, if there is a general consensus that this is the right thing to do, I'll go for it. However, I'm afraid that people will complain that I'm complicating functions in Python even more. Second: while introspection was the initial motivation, it does make sense to unify built-in functions and Python functions. For example: why are unbound methods just functions in Python classes but not in extension types? If you are going to do some reorganization of function classes anyway, you might as well do it properly. I claim that functions will be *easier* to work with in Python when my PEP is accepted, both for the end user as well as for the implementor of custom function classes. > Seems to me that if you want a fast, exact (no subclasses) check, you > should use "type(obj) is Class" rather than isinstance. If the *only* > reason to prohibit subclassing is to make isinstance a bit faster, > I don't think that's a good enough reason. I didn't really mean "isinstance" literally, I was mostly thinking of the C API. I agree that it's not clear. Do you happen to know why the existing function classes in Python disallow subclassing? I assumed that it was for exactly this reason. Jeroen.

3 2