Hi Dom
In your original post you used your proposed addition to write code that
provides a way of handling defaults different from the standard mechanism,
and perhaps in your opinion better.
The following example tells us something about defaults mechanism already
provided by Python:
>>> def f(a
Hi Dom
To support your proposal you provided an example. Well done for providing
evidence to support your idea. Doing that makes the discussion more
productive.
I'm going to use the words 'good' and 'bad', but with two provisos. The
first is that they are judgemental, and often judgement is littl
Hi Dom
In your original post you said you're writing some code to improve handling
of defaults (perhaps only in some situations). You also said that the
feature you're suggesting would make your improved default handler easier
to write.
Python already handles default values at least fairly well i
POSTSCRIPT
We can also use locals() to 'inverse search' to get the name, much as in
the original post.
>>> locals()['x']
(0, 1, 2, 3)
>>> id(x)
139910226553296
>>> id(locals()['x'])
139910226553296
--
Jonathan
___
Python-ideas mailing list -- python-id
Perhaps use the id of an object instead of its value. Here's how it might
work
>>> store = {}
>>> def wibble(fn):
... val = fn()
... name = fn.__name__
... store[id(val)] = name
... return val
>>> @wibble
... def ddd():
... return tuple(range(4))
>>> ddd
(0, 1, 2, 3)
The original example is:
numbers = (i for i in range(5))
assert 5 not in numbers
sorted(numbers)
I like this example. It provides an opportunity to improve the
documentation.
The problems goes away if we write any of the following
numbers = [i for i in range(5)]
numbers = tup
Hi
Here's a similar example
$ python3
> Python 3.10.6 (main, Nov 14 2022, 16:10:14) [GCC 11.3.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from collections import Counter
> >>> cnt = Counter # Oops!
> >>> cnt.update('abcde')
> >>> cnt
>
>
This is wh
Hi
Some of us might believe that a currently legal syntax should only
exceptionally be given a new meaning, even if there is no evidence
whatsoever that this legal syntax is actually in use. My own belief is more
pragmatic. If there's very strong evidence that the syntax is not in use,
I'm happy t
Hi
Some have liked adding a new syntax
a, b, ... = iterable
to mean consume two items from the iterable. However,
a, b, Ellipsis = iterable
has a different meaning (at least in Python 3.8). It redefines Ellipsis.
(As an explicit constant, '...' can be redefined.)
The syntax
a, b, ... = i
Hi
This is a nice problem, well presented. Here's four comments / questions.
1. How does the introduction of faster CPython in Python 3.11 affect the
benchmarks?
2. Is there an across-the-board change that would speedup this line-offsets
task?
3. To limit splitlines memory use (at small performan
Steve D'Aprano wrote of an incompleteness in this PEP
This is not just some minor, trivial implementation issue, it cuts right
> to the core of this feature's semantics [...]
For comparison, please look at the PEP for the statistics module. Steve
wrote both PEP and the standard library module. I
Hi
Consider
>>> a, b, *_ = iter('abdef')
>>> a, b, None = iter('abdef')
File "", line 1
SyntaxError: can't assign to keyword
If providing this feature is found to be a good idea, it might be better to
use 'None' or even a new keyword rather than '*'. Obvious benefits is it
avoid
Here is another problem in this general area. Multiplying an array by a
float already raises a type error.
>>> []*0.0
Traceback (most recent call last):
TypeError: can't multiply sequence by non-int of type 'float'
This problem can arrse 'by accident'. For example, consider
>>> x =
Hi Steve
Today's XKCD is on 'Selection Bias' and it is set in a statistics
conference: https://xkcd.com/2618/
According to its PEP the statistics module provides "common statistics
functions such as mean, median, variance and standard deviation".
You ask "if you are a user of statistics, how imp
Hi Paul
You wrote:
> You [the original poster] seem to want a function[to express the
> criteria], but it's not obvious to me why you need that.
A function has several advantages.
1. It can be reused.
2. It can be tested (a special case of 1).
3. It can be passed as a parameter (a special case
Hi Lucas.rs
You wrote:
> In its current implementation, the list type does not provide a simple and
> straightforward way to retrieve one of its elements that fits a certain
> criteria.
>
Thank you. You've asked a good question. I hope my answer will be helpful.
Here's my preferred solution, us
Hi
Thank you Inada for your prompt and helpful reply. Here's a link for cached
hash in bytes object: https://bugs.python.org/issue46864
What I have in mind is making selected objects smaller, for example by
using smaller pointers. But how to know the performance benefit this will
give?
I think i
Hi
As you may have seen, AMD has recently announced CPUs that have much larger
L3 caches. Does anyone know of any work that's been done to research or
make critical Python code and data smaller so that more of it fits in the
CPU cache? I'm particularly interested in measured benefits.
This search
Hi
Steve D'Aprano started this thread on 16 Jan, referencing
https://bugs.python.org/issue46393.
In the 95th message in this thread, on 27 Jan, Stephen J. Turnbull wrote:
I think for many of us (specifically me, but I don't think I'm alone) it's
> equally important that we aren't persuaded that
Joao's
{1, 2, 3}.frozen()
shows real originality, arising from deep creative thought about the roots
of the problem. I was both surprised and delighted when I saw it, and I
think some others were too. (I agree with others that here 'freeze' is
better than 'frozen'.)
Obviously, each of the two
Earlier today in https://bugs.python.org/issue46393, Serhiy Storchaka wrote:
As Steven have noted the compiler-time optimization is not applicable here
because name frozenset is resolved at run-time.
In these cases where a set of constants can be replaced with a frozenset of
constants (in "x in {
The compiler can figure out that the value of
{1, 2, 3}
is a set containing the elements 1, 2 and 3.
The problem with the value of
frozenset({1, 2, 3})
is that the value of frozenset depends on the context. This is because
frozenset = print
is allowed.
According to help(repr):
repr
Summary: Further information is provided, which suggests that it may be
best to amend Python so that "frozenset({1, 2, 3})" is the literal for
eval("frozenset({1, 2, 3})").
Steve D'Aprano correctly notes that the bytecode generated by the expression
x in {1, 2 ,3}
is apparently not optimal. He
Hi Ricard
Python to web assembly is a good idea that is already being developed.
The first result from this search
https://www.google.com/search?q=python+webassembly
is the project https://github.com/pyodide/pyodide.
Also relevant is https://www.theregister.com/2021/11/30/python_web_wasm/
You lo
Hi Chris
Again you ask good questions.
Q: How to find the bare string '#wibble'? It's optimised out during
compilation.
A: Very good. I didn't know that. For current Python we'll have to use a
different marker. For future Python we could change the compiler so that it
directly sets fn.__wibble__
Hi
I've just had a brainwave that may give an even less invasive
implementation of PEP 671. It relies on every function having a dict, as
provided by https://www.python.org/dev/peps/pep-0232/.
Consider:
def fn(a, b, c): pass
fn.__wibble__ = 123
fn.__wibble__ # Give 123, of course.
No
Hi Chris
I like your questions. You ask: How would fn.__wibble__ be different from
checks at the top of fn.__code__?
They'd be in two different code blocks. I see a function call going as
follows.
1. Process the supplied arguments in the usual way.
2. Create a new frame object and place it on the
Hi
One of the motives for PEP 671 is that the signature of a function fn, and
hence the associated help(fn) is sometimes opaque regarding default values.
I won't repeat the excellent examples already given.
In the current implementation default values are handled outside the
compiled code of the
Hi Chris
You wrote:
In fact, on subsequent consideration, I'm inclining more strongly
> towards SyntaxError, due to the difficulty of explaining the actual
> semantics. Changing the PEP accordingly.
Your PEP, so your choice. I now think that if implemented, your PEP adds to
the Python compiler
Hi
Please forgive me if it's not already been considered. Is the following
valid syntax, and if so what's the semantics? Here it is:
def puzzle(*, a=>b+1, b=>a+1):
return a, b
Aside: In a functional programming language
a = b + 1
b = a + 1
would be a syntax (or at least compi
Hi Serhiy
Thank you for so clearly explaining how names get passed to function and
class constructors.
You also wrote:
> We do not have generalized way to call arbitrary constructor with
> automatically passing __name__, __qualname__ and __module__. And it would
> be convenient.
>
> create n
>From my phone.
An important thing about def x and class A is that the strings x and A are
made available to the constructor for x and A respectively. The same is not
true for x=val.
Jonathan
___
Python-ideas mailing list -- python-ideas@python.org
To u
Hi Yahbai
You might wish to reconsider your proposal in light of existing behaviour
>>> 1+-1
0
Consider also your proposed
>>> a, b = 2 +- 1
We know that {a, b} = {1, 3}. But which is which?
In your use case you might be better off introducing a custom type
>>> lims = pm(2, 1)
>>> lims.lo, lims.
Jonathan Goble wrote:
> Is there a reason why we can't just link to the Wayback Machine copy like
> you did here?
>
I agree with that as immediate first aid. It seems that wikipedia practice
now is to link to both the original article and to a copy on the wayback
machine.
I've found some perhap
Thank you Paul. I used my default Python, which is Python 3.6. However,
with 3.7 and 3.8 I get the same as you. I've promoted you 'works for me' on
b.p.o to 'not a bug'. Thank you again.
--
Jonathan
___
Python-ideas mailing list -- python-ideas@python.o
The interactive help message for writelines gives no help. I've made an
enhancement request to b.p.o.
help(open('/dev/zero').writelines) gives no help
https://bugs.python.org/issue44623
Please take a look.
--
Jonathan
___
Python-ideas mailing list --
Hi Leon (and Bryan)
Here's some comments on your interesting suggestion.
Bryan Ford's CACHEDIR.TAG proposal is supported by gnu tar. See:
https://www.gnu.org/software/tar/manual/html_node/exclude.html
By the way, I've copied Bryan.
There's a cachedir_tag module on PyPi, by Alex Willmer:
https:/
Thomas Grainger wrote:
It looks like there's a consensus being reached, should I create a bpo?
>
Perhaps first state what seems to be the consensus and invite further
comments before going to bpo.
Disclaimer: I'd like to see both:
1. Something on PyPi to help persons who are using ssl on curren
It may help to think separately about existing code using ssl, and about
new code. However, I'm not a user of ssl, so please doubt my opinions below.
EXISTING CODE
Those maintaining existing code might welcome an easy way of checking that
the code doesn't have a misleading assignment. They might a
Thank you Thomas for concisely and fairly reporting your experience, and
based on that suggesting a way to improve Python. Thank you for taking the
time to do this.
Here's a typo that caused a bug (which inconvenienced the original poster):
context.miunimum_version = ssl.TLSVersion.TLSv1_3
> cont
Off-topic
Someone on this list wrote:
Mu.
>
> https://en.wikipedia.org/wiki/Mu_(negative)#%22Unasking%22_the_question
This is a koan, a device in Zen Buddhism used by a teacher to help the
student liberate themselves from being imprisoned by rational discursive
thought.
Here is another koan.
We have the following.
>>> 12 = True
SyntaxError: can't assign to literal
>>> True = False
SyntaxError: can't assign to keyword
>>> ... = False
SyntaxError: can't assign to Ellipsis
We also have (works better in monospaced font)
>>> d[] = True
d[] = True
On Sat, May 29, 2021 at 6:01 PM Chris Angelico
> But if you're okay with constructing a new dict, you can do this:
>
> d = dict(sorted(d.items(), key=lambda kv: ...))
>
Or to keep the same dict (not tested)
tmp = list(sorted(d.items()))
d.clear()
d.update(tmp)
--
Jonathan
_
There's been a discussion in this list on extending Python to provide
SYNTAX such as
@decorator
name = EXPRESSION
and also suitable semantics. (Here 'name' is an identifier, in the
discussion called a 'variable'.)
This post is about providing SEMANTICS for such decorator syntax. We can do
Martin wrote:
as you might have noticed, I am trying to improve the syntax and semantics
> for symbolic math in Python. Until now, I have to say, my ideas were not
> that well received, but I learned from the discussion and maybe this time I
> come up with something people like.
>
For about 10 ye
Martin wrote:
In general, doing symbolic math in Python is not very beautiful.
I think this is a problem worth investigating. (Disclaimer: I do research
in pure mathematics.)
> The number of hoops you have to jump through is large, mostly because
> syntax is abused for things it was not actual
Martin wrote
So, if you show them (the following is fake)
>
> >>> 1/2 + 1/3
> 5/6
> 1 / 2 + 1 / 3
> 0.83
>
> They will immediately spot what's going on.
>
I'm sighted. I can see the difference. I suspect a blind person using a
screen reader would struggle a lot to spot th
Hi Martin
I think it important to realise there are at least two issues. The first is
whether sometimes fraction is better than float, and vice versa. The second
is whether the default behaviour for int / int should be changed.
A third issue is whether some of the benefits you are seeking can be
Martin wrote:
when dividing two integers, the result is a float, which means we
> immediately lose precision. This is not good if you want to use code which
> supports higher precision.
I am of course in favour of keeping precision, if there is no cost. But
here there is a cost. Arbitrary precis
Perhaps Off Topic, but for a good cause.
This year I met Jana Scroeder, a blind person forced to change jobs as part
of the social cost of Covid. Her outsider experience of computer coding
training became a wish to make things better. She has applied for a Holman
Prize ($25,000 over a year) to fun
Summary: The argument in list(arg) must be iterable. The argument in
str(arg) can be anything. Further, in [ a, b, c, d ] the content of the
literal must be read by the Python parser as a Python expression. But in
"this and that" the content need not be a Python expression.
Hi David
I find your s
On Fri, Apr 30, 2021 at 6:00 PM Chris Angelico wrote:
For those cases where you're merging literal parts and generated
> parts, it may be of value to use an f-string:
>
> >>> f"[{','.join('0123')}]"
> '[0,1,2,3]'
>
> The part in the braces is evaluated as Python code, and the rest is
> simple lit
Hi David
I see where you are coming from. I find it helps to think of sep.join as a
special case. Here's a more general join, with sep.join equivalent to
genjoin(sep, '', '').
def genjoin(sep, left, right):
def fn(items):
return left + sep.join(items) + right
retur
In August 2020, in the context of PEP 472 I suggested
>>> {-}
for the empty set literal. At present the closest we can do for an empty
set literal is
>>> {0} - {0}
set()
The context for this is whether PEP 472 should make
>>> something[]
a syntax error. If we do then, what about th
Hi
I see two issues. The first is present behaviour. The second is alternative
ways of ordering the elements of a Cartesian product.
Here's an example of the present behaviour.
>>> iter_range = iter(range(100))
>>> prod = itertools.product(iter_range, "abcdef")
>>> next(iter_range)
Hi
There's interest here in arithmetic operations on NaN . I've just seen a
product listed as costing NaN pounds to buy a null amount. That was written
as £NaN/null.
The bargain item is Glade Shake & Vacuum Citrus, and you can see it at
https://www.tesco.com/groceries/en-GB/products/253732570
Se
Hi
Don Knuth, author of The Art Of Computer Programming and creator of the TeX
typesetting system is 83 today. Happy Birthday Don. Thank you for TeX and
everything else.
You're warmly invited to join me online to celebrate Don's life and work.
The virtual party is on Thursday 14 January, 6:30 to
Bravo, Jeff. I couldn't have chosen a better example.
However, I'd expect large ints to be stored in two parts. A (class,
pointer) pair which has fixed size. And memory referenced by the pointer,
large enough to store the value of the large int.
However, that's part of the language implementation
Hi Richard
You wrote
I believe that one solution to detecting the cycles is to create a set
> of the object IDs you have visited and started to print. If you come
> across an ID you have already seen, this point is in a cycle. Sets are
> fairly compact and intentionally fast to search for an item
Hi Jeff
> But you're right, that's a better word for discussing the problem.
> Steven's problem data structures are cyclic graphs. I don't agree that such
> structures are a sign one is doing something wrong (outside the naive
> approach to printing them out).
>
Thank you for agreeing with me, an
Hi Jeff
You wrote:
Detecting cycles will involve a lot of bikeshedding. (Sorry, couldn't
> resist.)
>
Indeed. That really brought a smile to my face. Thank you.
As I recall, bikeshedding is endless discussion (cycles again) of the
COLOUR to paint the bikeshed. And in mathematics there's the top
Hi Richard
You suggested
A very simple and in my mind reasonable use for this is to build a
> representation of a graph, where each node is represented by a list (or
> some other collection), and the connections are denoted by adding to
> that collection the nodes that are adjacent (or maybe a tu
Hi
I'd say the problem isn't recursion. Here I'm using the definitions given
in:
https://en.wikipedia.org/wiki/Recursion
https://www.cs.utah.edu/~germain/PPS/Topics/recursion.html
Rather, it's that the data has a loop (or cycle) in it. A simple example of
this is
>>> x = []
>>> x.append(x
Hi Alexey
You wrote that docstring-related software generally fails to handle
docstrings properly in stub files. I don't have experience of this,
probably because I don't use such software. Please would you provide some
examples. Ideal would be issued that have been raised (by you if need be)
for
Hi Christopher
I did notice the unusual command line, but didn't think any more of it. I
thought everything I needed to look at was already in the message.
A reference to https://pypi.org/project/importhook/ would have helped me. I
don't see importhook providing a practical implementation of the
Hi Paul
I get a syntax error. The code won't even compile. I don't see how your
code can avoid it. Are you sure your example works?
$ python3.8
Python 3.8.0 (default, Oct 28 2019, 16:14:01)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> @TimeIt
...
Hi
On Thu, Dec 3, 2020 at 2:02 PM Chris Angelico wrote:
> well... uhhh Technically you can do that already
>
> for a in aaa:
> for b in bbb:
> if condition(a, b):
> break
> else:
> continue # We didn't break from b, so continue a
> break # We did b
Hi Jonatan
Please consider
for a in aaa:
for b in bbb:
if condition(a, b):
break
KEYWORD:
break
where KEYWORD is like else, but with the opposite semantics. I think this
does exactly what you asked for, in your example.
In July this year
The module __main__ is somewhat special. It's there from the very beginning
(so far as I can tell).
$ python3 -c 'import __main__; print(__main__)'
And without importing __main__.
$ python3 -c 'import sys; print(sys.modules["__main__"])'
In light of this, it seems to me that the
Christopher Barker and Stephen J. Turnbull wrote:
> As a statement clause separator, which becomes ambiguous:
>
> if thing: x
>
Yes. Very good. Well done, both of you.
Now consider this. PEP 643 allows for things like
obj[a=x:y]
and "may open up the open the possibility" of allowing
SUMMARY:
I share with you extracts from a personal email Rick Teachey sent me, on my
involvement in PEP 637 (keyword arguments in item access), and my answers
to some important questions he asks.
BACKGROUND:
Last week, prior to my publicly stating my resignation as a co-author of
PEP 637, Ricky Te
Hi
The following is copied and pasted from
https://github.com/python/peps/pull/1650
Stefano Borini
===
Commit message:
PEP 637 I've asked Jonathan Fine to resign as PEP author, and he's agreed
to do so. Details in the pull request
Pull request comment:
Hi Jonathan
Tha
SUMMARY
This post asks for some examples that will improve PEP 637, by providing
examples where the existing language specification is not adequate (but PEP
637 is). The rest of this post should tell you why I want these examples,
and what they should look like.
DISCLAIMER
I'm an editor of PEP 637
I'm pleased to announce v0.0.2 of my kwkeys package.
https://pypi.org/project/kwkey/
The main new feature is items-key duality. Based on that, it emulates the
semantics proposed by D'Aprano and van Rossum. It also emulates the
semantics proposed by myself.
What does this mean? Here, by duality I
Oops. Should read
Subject: Package kwkey to support Guido's favoured semantics
Please accept my apologies.
--
Jonathan
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.py
The next release of kwkey will provide a class A with the following
property.
It is that
>>> A(1, 2, a=3, b=4)[d] = 'val'
will result in
>>> d.__setitem__((1, 2), 'val', a=3, b=4)
This is precisely the same call that would result from
>>> d[1, 2, a=3, b=4] = 'val'
using the semantics
Hi Steven
Thank you, for reviewing and combining your previous statements into a
single message. This is a great help, for the creation and editing of the
revised PEP.
I intend to do something similar myself. Perhaps others might also want to
do something similar.
--
Jonathan
__
Paul Moore wrote:
Again, obvious. But you still haven't given any reason why we would want to
> do that. No-one's arguing that these things aren't possible, or that the
> proposals can't be implemented. What I'm asking, and you aren't answering,
> is what is the use case? When, in real world code,
Thank you, Guido, for your interest in this discussion.
You wrote:
> So __keyfn__ has literally only two allowed values, None and True.
>
That's my proposal, for now. I'm happy for further allowed values to be
added via another PEP. In fact, that is my preference.
You also wrote:
> Could you j
Paul Moore wrote:
But you don't give any reason why you'd want to do that. Why are you
> using subscript notation rather than a simple function call?
Good point. Consider
>>> def f(*argv): pass
>>> d = dict()
Now compare
>>> f(1, 2) = 3
SyntaxError: can't assign to function call
I wrote:
Ricky has given some examples. Here are more, all assuming
> __keyfn__ = True
>
My mistake. It should be
__keyfn__ = None
I'm sure you've already figured that out. Still, please accept my apologies.
--
Jonathan
>
___
Python-ideas ma
For me, a satisfactory outcome from the current PEP process would be a new
dunder, which I am calling __keyfn__, that has two possible values,
namely None or True. (And of course, the associated syntax and semantics
changes. And documentation changes. These are not minor matters.)
As __keyfn__ has
This is a continuation of my previous post. I wrote:
Here's an example of how the new dunder might work in practice.
>
> class A:
> __keyfn__ = None
> def __setitem__(self, val, x=0, y=0, z=0):
> print((val, x, y, z))
>
> >>> a = A()
> >>> a[1, z=2] = 'hello
Here are two examples, which I hope help us understand our options.
Here's an example of how the new dunder might work in practice.
class A:
__keyfn__ = None
def __setitem__(self, val, x=0, y=0, z=0):
print((val, x, y, z))
>>> a = A()
>>> a[1, z=2] = 'hell
SUMMARY
Sequences and mappings are both similar and different. Let's introduce and
use a new dunder attribute, to give item access appropriate behaviour. This
proposal is based on an earlier thread - see Acknowledgments for URL.
INTRODUCTION
In Python, there are two sorts of builtin objects that h
Ben's right regarding the facts. Here's my examples.
Python 3.6.9 (default, Jul 17 2020, 12:50:27)
>>> def foo(*argv, **kwargs): return argv, kwargs
>>> foo(*'ab', x=1, y=2, *'cd', z=3)
(('a', 'b', 'c', 'd'), {'x': 1, 'y': 2, 'z': 3})
Python 2.7.17 (default, Jul 20 2020, 15:37:01)
Hi Todd
You wrote:
> Why would that be the case? d[1:3] is allowed but d(1:3) isn't. The
> interpreter replaces "1:3" with "slice(1, 3)" behind-the-scenes.
>
>>> s ='hello'
>>> s[1:3]
'el'
>>> s[(1:3)]
SyntaxError: invalid syntax
>>> f(x=1:3)
SyntaxError: invalid
Christopher wrote: Why not allow slice syntax as an expression everywhere?
In reply, Todd wrote: That is a very different discussion, and not directly
related to keyword indexes. Would it be possible to start a new email
thread to discuss it?
I think they are closely related matters, at least in
Hi Todd
You wrote:
I think this is a bad idea, since it would mean classes could seem to
> support keyword arguments but silently do the completely wrong thing,
> especially if someone accidentally uses an older version.
>
I don't see this happening, and certainly don't see it as a new problem.
Hi Todd
I still don't see how testing it will help anything at this point.
>
Well, you and I have a difference of opinion here. I don't think it's
worth discussing this further now. Perhaps next month it will be.
--
Jonathan
___
Python-ideas mailing
Todd wrote:
It has the same capabilities, the question is whether it has any additional
> abilities that would justify the added complexity.
>
The most obvious additional ability is that always
>>> d[SOME_EXPRESSION]
is equivalent to
>>> d[key]
for a suitable key.
This is a capability th
Todd wrote:
Only Jonathan seems to want to do it differently. We are trying to find
> out exactly why he prefers this approach. So far the only advantage I have
> seen is that it is easier to experiment with.
>
I think it's good to make experiments before making a decision. That's
where I'd lik
Here's a few words on whether we should allow and whether we can forbid:
>>> something[]
First, in
>>> something[x=1]
what I call the argv is empty, as it is with
>>> something[]
If we represent an empty argv by passing the empty tuple () to __getitem__,
then how are
>>> something
Hi Steven
You wrote:
why are we even considering a language change to force every single
> subscriptable object to accept arbitrary keyword-only arguments unless the
> maintainer changes their class to
> explicitly reject them?
I think there might be a misunderstanding here. I'd like to see an
Message below sent in error. Please ignore. I'll send a replacement in a
few minutes. Please accept my apologies.
On Sat, Aug 15, 2020 at 4:30 PM Jonathan Fine wrote:
> Hi Steven
>
>
> Recall that my proposal implies
> >>> d = dict()
> >>> d[a=1,
Hi Steven
Recall that my proposal implies
>>> d = dict()
>>> d[a=1, b=2] = 42
>>> d[a=1, b=2]
42
Recall that your proposal implies
>>> d = dict()
>>> d[a=1, b=2] = 42
TypeError: wrapper __setitem__ doesn't take keyword arguments
>
___
Ewing
wrote:
> On 14/08/20 10:03 pm, Jonathan Fine wrote:
> > NO POSITIONAL ARGUMENTS
> > I'd like
> > >>> d[x=1, y=2]
> > to be valid syntax. It's not clear to me that all agree with this.
>
> If keywords are to be allowed, it see
I'd like to sound out consensus regarding mapping access, where none of the
keys are positional. In particular, I suggest that PEP 472 allow syntax and
semantics such as
>>> d[x=1, y=2] = 42
>>> d[x=1, y=2]
42
and ask whether the class
>>> X = type(d)
should be part of standard Pyth
We are discussing a proposal to extend Python's syntax to allow
d[1, 2, a=3, b=4]
We are also discussing the associated semantics. At present
d[1, 2]
d[(1, 2)]
are semantically equivalent.
There is a proposal, that
d[1, 2, a=3, b=4]
d[(1, 2), a=3, b=4]
be semantically equivale
Hi Todd
You wrote:
I guess the thing I don't understand is why you favor that API. Could you
> please explain what you think are the advantages of your approach, ideally
> with some examples where you think your approach is clearer?
>
I've created a github issue for this, which I'll answer her
1 - 100 of 413 matches
Mail list logo
