[Python-ideas] Re: Equality between some of the indexed collections
On Wed, May 06, 2020 at 12:39:30PM +1200, Greg Ewing wrote: > On 6/05/20 2:22 am, jdve...@gmail.com wrote: > >However, if sets and frozensets are "are considered to be > >fundamentally the same kind of thing differentiated by mutability", > >as you said, why not tuples and lists? > > I think that can be answered by looking at the mathematical > heritage of the types involved: [...] > To a mathematician, however, tuples and sequences are very > different things. Python treating tuples as sequences is a > "practicality beats purity" kind of thing, not to be expected > from a mathematical point of view. Thanks Greg, that's a really insightful observation. -- Steven ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4HN4E233O66ZA3QWZFHX7QDJVHPRAXKG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Equality between some of the indexed collections
On Wed, 6 May 2020 at 01:41, Greg Ewing wrote:
> On 6/05/20 2:22 am, jdve...@gmail.com wrote:
> > However, if sets and frozensets are "are considered to be
> > fundamentally the same kind of thing differentiated by mutability",
> > as you said, why not tuples and lists?
>
> I think that can be answered by looking at the mathematical
> heritage of the types involved:
>
> Python Mathematics
> -- ---
> setset
> frozenset set
> tuple tuple
> list sequence
>
> To a mathematician, however, tuples and sequences are very
> different things. Python treating tuples as sequences is a
> "practicality beats purity" kind of thing, not to be expected
> from a mathematical point of view.
>
>
I don't think that is accurate to represent as a representation of "a
mathematician". The top voted answer here disagrees:
https://math.stackexchange.com/questions/122595/whats-the-difference-between-tuples-and-sequences
"A sequence requires each element to be of the same type.
A tuple can have elements with different types."
The common usage for both is: you have a tuple of (Z, +) representing the
Abelian group of addition (+) on the integers (Z), whereas you have the
sequence {1/n}_{n \in N} converging to 0 in the space Q^N (rational
infinite sequences) for example.
I'd say the difference is just one of semantics and as a mathematician I
would consider tuples and sequences as "isomorphic", in fact, the
set-theoretical construction of tuples as functions is *identical* to the
usual definition of sequences: i.e. they are just two interpretations of
the the same object depending on your point of view.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/A7JO3MWPYGU2OJHVMC2B55CT6UTKLQBJ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
Christopher's quoting is kinda messed up and I can't be bothered fixing
it, sorry, so you'll just have to guess who said what :-)
On Tue, May 05, 2020 at 01:03:30PM -0700, Christopher Barker wrote:
> "If its builtin people will be more likely to use it, so we need to make
> > it builtin."
> >
> > This argument will apply to **literally** every function and class in
> > the standard library.
>
>
> But we are not talking adding a new builtin.
I didn't say a *new* builtin. You are talking about having this
related but distinct functionality piggy-back on top of the
existing tolerant zip function, distinguishing them by a flag.
I trust you wouldn't try to argue that `int(string, base)` is not
a builtin function? :-)
> > Firstly, we would have to agree that "maximizing the number of people
> > using the strict version of zip" is our goal. I don't think it is.
>
>
> Neither do I. But I am suggesting that "maximizing the number of people
> that need a strict version of zip will use it" Rather than, say, checking
> the length of the inputs before calling zip. Or writing their own version.
Okay, but a function in the std lib is sufficient for that. If you want
to argue against the alternatives:
- use more-itertools
- make it a recipe in the docs
then "more people will use it" is a good argument for putting it into
the stdlib. But why should we fear that there will be people doing
without, or rolling their own, because it's not builtin?
`zip_longest` has been in the stdlib for at least a decade. We know it
has use-cases, and unlike this strict version of zip the need for this
was established and proven long ago. If there are people doing without,
or rolling their own, zip_longest because they either don't know about,
or cannot be bothered, importing from itertools, should it be in
builtins too?
> > Why is zip_longest different? What if we want to add a fourth or fifth
> > flavour of zip? Do we then have three flags on zip and have to deal with
> > eight combinations of them?
> >
>
> no -- but we could (and I think should) have a ternary flag, so that
> zip_longest becomes unnecessary. And we'd never get to eight combinations:
> you can't have longest and shortest behavior at the same time!
A ternary flag of strict = True, False or what?
This demonstrates why the "constant flag" is so often an antipattern. It
doesn't scale past two behaviours. Or you end up with a series of flags:
zip(*iterators, strict=False, longest=False, fillvalue=None)
and then you have to check for incompatible combinations:
if longest and strict:
raise TypeError('cannot combine these two options')
and it becomes worse the more flags you have.
Or you end up with deprecated parameters:
def zip(*iterators, strict=_sentinel, mode=ZIP_MODES.SHORTEST):
if strict is not _sentinel:
raise DeprecationWarning
> But if we did, then would it be better to have eight separate functions in
> itertools?
You wouldn't have eight separate functions. You would have four. But to
distinguish four independent modes in a single function, you need three
flags, and that gives you 2**3 = 8 combinations to deal with, all of
which have to be checked, and exceptions raised if the combination is
invalid.
--
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/UANJQXQNWQY2C6ADLJO3P2PJ44Q37RGD/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Equality between some of the indexed collections
On 6/05/20 2:22 am, jdve...@gmail.com wrote: However, if sets and frozensets are "are considered to be fundamentally the same kind of thing differentiated by mutability", as you said, why not tuples and lists? I think that can be answered by looking at the mathematical heritage of the types involved: Python Mathematics -- --- setset frozenset set tuple tuple list sequence Sets and frozensets are both modelled after mathematical sets, so to me at least it's not surprising that they behave very similarly, and are interchangeable for many purposes. To a mathematician, however, tuples and sequences are very different things. Python treating tuples as sequences is a "practicality beats purity" kind of thing, not to be expected from a mathematical point of view. -- Greg ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/NZS54CXQ4NMJLNZJZDUERSM2W5XVK3N7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Passing Arguments Through Thin Wrappers (was : Auto-assign attributes from __init__ arguments)
>from inspect import stack, Signature > >def parameters(): >caller = stack()[2][0].f_globals[stack()[1][3]] >sig = Signature.from_callable(caller) >vars = stack()[1][0].f_locals >return sig.bind(**vars).arguments This also doesn't work for me if a variable is assigned inside the function before parameters() is called. Although I know you weren't suggesting this was a final working version, it does at least illustrate that this isn't a trivial problem to solve. Whilst this is slightly different from my idea of having a function to set the class attributes based on the parameters to init, having something like parameters() would reduce this to a one-liner, and I'd definitely find it useful for passing to super, which has been mentioned already. Lewis On Tue, 5 May 2020, 16:18 Barry Scott, wrote: > > > > On 5 May 2020, at 15:38, Steven D'Aprano wrote: > > > > Here is a quick and dirty proof of concept: > > > > > >from inspect import stack, Signature > > > >def parameters(): > >caller = stack()[2][0].f_globals[stack()[1][3]] > >sig = Signature.from_callable(caller) > >vars = stack()[1][0].f_locals > >return sig.bind(**vars).arguments > > > > > >def func(spam, eggs): > >params = parameters() > >for name, value in params.items(): > >print(name, '=', value) > > > > > > Calling `func(2, 3)` prints: > > > >spam = 2 > >eggs = 3 > > Is this to avoid locals()? > > Do you have a version that works inside a func of a class? > > I tried the obvious and it TB'ed: > > > from inspect import stack, Signature > > def parameters(): > caller = stack()[2][0].f_globals[stack()[1][3]] > sig = Signature.from_callable(caller) > vars = stack()[1][0].f_locals > return sig.bind(**vars).arguments > > > class X: > > def func(self, spam, eggs): > params = parameters() > for name, value in params.items(): > print(name, '=', value) > > x = X() > x.func( 1, 2 ) > > Traceback (most recent call last): > File "args.py", line 25, in > x.func( 1, 2 ) > File "args.py", line 20, in func > params = parameters() > File "args.py", line 11, in parameters > caller = stack()[2][0].f_globals[stack()[1][3]] > KeyError: 'func' > > > Barry > > > > > > > -- > > Steven > > ___ > > Python-ideas mailing list -- python-ideas@python.org > > To unsubscribe send an email to python-ideas-le...@python.org > > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/62ZDUVMEKQEMBRTVHM2GYXZVJLPPHYBQ/ > > Code of Conduct: http://python.org/psf/codeofconduct/ > > > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/7BVSYMV4Q7SOOEGC5UDLMWVZ6XT5RVUY/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/J6BMZISIMHTUFD47S7XFCTEXLALF7AOM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
On 05/05/2020 21:03, Christopher Barker wrote: "If its builtin people will be more likely to use it, so we need to make it builtin." This argument will apply to **literally** every function and class in the standard library. But we are not talking adding a new builtin. Well, actually we are. As Steven pointed out further down the post, adding a flag to a function that is pretty much always going to be set at compile time is equivalent to (and IMHO would be better expressed as) a new function. -- Rhodri James *-* Kynesim Ltd ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/YU3TQ7XP5YM2NSUDWV2MUPJY7VLA3OVM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
"If its builtin people will be more likely to use it, so we need to make > it builtin." > > This argument will apply to **literally** every function and class in > the standard library. But we are not talking adding a new builtin. > Firstly, we would have to agree that "maximizing the number of people > using the strict version of zip" is our goal. I don't think it is. Neither do I. But I am suggesting that "maximizing the number of people that need a strict version of zip will use it" Rather than, say, checking the length of the inputs before calling zip. Or writing their own version. Think about the strange discrepency between the three (so far...) kinds > of zip: > > - zip (shortest) is builtin, controlled by a flag; > - zip strict is builtin, controlled by a flag; > - zip longest is in a module, with a distinct name. > > Why is zip_longest different? What if we want to add a fourth or fifth > flavour of zip? Do we then have three flags on zip and have to deal with > eight combinations of them? > no -- but we could (and I think should) have a ternary flag, so that zip_longest becomes unnecessary. And we'd never get to eight combinations: you can't have longest and shortest behavior at the same time! But if we did, then would it be better to have eight separate functions in itertools? -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/FWZU546YMOYHGCXFYESZZCITV5LURR6R/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
On Tue, May 5, 2020 at 9:20 AM David Mertz wrote: > I have no idea whether a flag on zip() or a function in itertools would > get MORE USE. I *ABSOLUTELY* think it is an anti-goal to get more use for > its own sake though. > I'm not sure anyone was suggesting that -- *maybe* Alex, but I think his statement was over-interpreted. I only want APPROPRIATE USE in any case. > I can't imagine we all don't agree with that. > The real point, to me, is that users who use itertools.zip_strict() will > use it for exactly the reason that they want that semantics. In contrast, a > flag for `strict` or `truncate` or `equal` or whatever is a LOT more likely > to be used in the "just in case" code where the programmer has not thought > carefully about the semantics they want. > There's no way to really know, but I think this is being overblown -- folks generally don't go use extra flags just for the heck of it -- particularly one that won't be documented in anything but the latest documents for years :-) > The sky isn't falling, I certainly don't think everyone, nor even most > developers, would use the flag wrong. But a separate function just > provides a better, more consistent, API. > Well, THAT IS the point of discussion, yes. I disagree, but can see both points. But I do want folks to consider that having zip() as a builtin, and zip_strict() and zip_longest() would be in itertools. Which is different than if they were all in the same namespace (like the various string methods, for example). Another key point is that if you want zip_longest() functionality, you simply can not get it with the builtin zip() -- you are forced to look elsewhere. Whereas most code that might want "strict" behavior will still work, albeit less safely, with the builtin. These considerations should be considered in evaluating the API options. And this is why I personalty think if we add a flag to zip, we should add one for longest functionality as well, unifying the API. I don't think anyone in the huge discussion of the walrus operator, for > example, tried to make the case that the goal should be encouraging it to > be used AS MUCH AS POSSIBLE. > Indeed, the opposite was true: there was a lot of concern that it would be overused. though I think think that's a much bigger concern than in this case. A feature should be used *where appropriate*, and the design should not > vacantly simply try to make it more common. > Agreed, but discoverability is still something to be considered in the API. ANd it seems that there are folks arguing that we specifically want this to be less discoveble due to concerns of overuse. Which does not seem like good API design approach to me. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/NTA24XVRJ7CD4B2BAEEIDVPBRFZY6NEQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Equality between some of the indexed collections
On 05/05/2020 03:05 AM, Alex Hall wrote: On Tue, May 5, 2020 at 7:36 AM Raymond Hettinger mailto:raymond.hettin...@gmail.com>> wrote: >> Isn't a tuple essentially just a frozenlist? I know the intended >> semantics of tuples and lists tend to be different, but I'm not sure that's >> relevant. Alex, please be careful of your quoting -- Raymond did not say the above paragraph. -- ~Ethan~ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/AIXEG5T42P6WIW3UMLYSCQUZ4ETY4ZWG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
On Wed, May 6, 2020 at 3:25 AM Steven D'Aprano wrote:
> Personally, I don't think Chris' backwards-compatibility argument is
> strong. Technically adding a new keyword argument to a function is
> backwards-incompatible, but we normally exclude that sort of change. Who
> writes this?
>
> # This behaviour will be changed by the proposed new parameter.
> zip('', strict=1) # Raise a type error.
>
> So I think the *backwards incompatibility* argument is weak in that
> regard. But maybe Chris has got a different perspective on this that I
> haven't thought of.
Adding the flag isn't a problem, but merely adding the flag is
useless. (Ditto if a new function is created.) The assumption is that
the flag will be used, changing existing code from zip(x, y) to
zip_strict(x, y) or zip(x, y, strict=True). Either way, it's not the
creation of zip_strict or the addition of the kwonly arg that breaks
backward compat, but the change to (say) the ast module, making use of
this, that will cause problems.
> [Chris]
> > > Should they? I'm not sure how well-supported this actually is. If you
> > > hand-craft an AST and then compile it, is it supposed to catch every
> > > possible malformation?
>
> I would expect that the ast library should accept anything which could
> come from legal Python, and nothing that doesn't.
>
It absolutely should accept anything which could come from legal
Python. The question is, to what extent should it attempt to flag
invalid forms? For example, if you mess up the lineno fields,
attempting to compile that to a code object won't give you a nice
exception. It'll most likely just work, and give weird results in
tracebacks - but there is no legal code that could have produced that.
And what code could produce this?
>>> from ast import *
>>> eval(compile(fix_missing_locations(Expression(body=Set(elts=[]))), "-",
>>> "eval"))
set()
There is no valid code that can create a Set node with an empty
element list, yet it's perfectly sensible, and when executed, it
produces... an empty set. Exactly like you'd expect. Should it be an
error just because there's no Python code that can create it?
I'm of the opinion that it's okay for it to accept things that
technically can't result from any parse, just as long as there's a
reasonable interpretation of them. Which means that both raising and
compiling silently are valid results here; it's just a question of
whether you consider "ignore the spares" to be a reasonable
interpretation of an odd AST, or if you consider "mismatched lengths"
to be a fundamental error.
ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/FOCSHKCYPEQPVBY2WIE4MHW7QNM5JFEZ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
On Tue, 5 May 2020, 18:24 Steven D'Aprano, wrote:
> On Tue, May 05, 2020 at 05:26:02PM +0100, Henk-Jaap Wagenaar wrote:
>
> > This is a straw man in regards to backwards compatibility. This
> particular
> > (sub)thread is about whether if this zip-is-strict either as a separate
> > name or a Boolean flag or some other flag of zip should be a built-in or
> be
> > in e.g. itertools.
>
> Please don't misuse "strawman" in that fashion. A strawman argument is a
> logical fallacy where you attack a weaker position your opponent didn't
> make in order to make your own position stronger. That's not what Chris
> did, and frankly accusing him of strawmanning is a form of "poisoning
> the well".
> What Chris did was to propose a counterfactual to express his opinion on
> this proposal. To paraphrase:
>
> "If this were true (we were designing zip from scratch for the first
> time) then I would agree with the proposal, but since we aren't, I
> disagree because of these reasons."
>
> That is a perfectly legitimate position to take.
>
I agree on the face of it (in regards to strawmanning and your
paraphrasing), except I wasn't disagreeing with anything you've gone into
the detail above, but I disagreed with one of the reasons listed and
thought it was strawmanning, namely the "the backward compatibility break
large" (see further down, why).
>
> "If we weren't in lockdown, I would take you out for dinner at a
> restaurant, but since we are in quarantine, I don't think we
> should go out."
>
> Personally, I don't think Chris' backwards-compatibility argument is
> strong. Technically adding a new keyword argument to a function is
> backwards-incompatible, but we normally exclude that sort of change. Who
> writes this?
>
> # This behaviour will be changed by the proposed new parameter.
> zip('', strict=1) # Raise a type error.
>
> So I think the *backwards incompatibility* argument is weak in that
> regard. But maybe Chris has got a different perspective on this that I
> haven't thought of.
>
>
I cannot interpret that as a "large" break as Chris says, so I must assume
he meant something else (changing the default is my assumption) unless
somebody (Chris or otherwise) can tell me why adding a keyword argument
would be a large incompatible change?
>
> [Chris]
> > > Should they? I'm not sure how well-supported this actually is. If you
> > > hand-craft an AST and then compile it, is it supposed to catch every
> > > possible malformation?
>
> I would expect that the ast library should accept anything which could
> come from legal Python, and nothing that doesn't.
>
>
> --
> Steven
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/GQZLWLOHFPBQLADHYLHW6JYY2X4S4ABA/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/R4EV4JWACQDCSGBMBXWQSNYTNAJWU6LH/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
On Tue, May 05, 2020 at 05:28:08PM +0100, Henk-Jaap Wagenaar wrote: > But you care about your input, you can do so by setting strict=True (if > that's the road we go down), and unlike what others have said, the IDE I > use (pycharm) would tell me that flag exists as I type "zip" and so I'd be > more likely to use it than if it was in itertools/... We keep coming to this same old argument over and over. "If its builtin people will be more likely to use it, so we need to make it builtin." This argument will apply to **literally** every function and class in the standard library. Pick any arbitrary module, any function from that module: `imghdr.what`. I literally didn't even know that function existed until 30 seconds ago. If it had been a builtin, I would have known about it years ago, and would have been more likely to use it. All this is true. But it's not an argument in favour of making it a builtin. (Or at least not a *good* argument.) Firstly, we would have to agree that "maximizing the number of people using the strict version of zip" is our goal. I don't think it is. We don't try to maximize the number of people using `imghdr.what` -- it is there for those who need it, but we're not trying to push people to use it whether they need it or not. And secondly, that assumes that the benefit gained is greater than the cost in making the builtins more complicated. It now has two functions with the same name, `zip`, distinguished by a runtime flag, even though that flag will nearly always be given as a compile-time constant: # Almost always specified as a compile-time constant: zip(..., strict=True) # Almost never as a runtime variable: flag = settings['zip'].tolerant zip(..., strict=not flag) That "compile-time constant" suggests that, absent some compelling reason, the two functions ought to be split into separate named functions. "But my IDE..." is not a compelling reason. This is not a hard law, but it is a strong principle. Compile-time constants to swap from two distinct modes often make for poor APIs, and we should be reluctant to design our functions that way if we can avoid it. (Sometimes we can't -- but this is not one of those times.) Think about the strange discrepency between the three (so far...) kinds of zip: - zip (shortest) is builtin, controlled by a flag; - zip strict is builtin, controlled by a flag; - zip longest is in a module, with a distinct name. Why is zip_longest different? What if we want to add a fourth or fifth flavour of zip? Do we then have three flags on zip and have to deal with eight combinations of them? -- Steven ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2W5GF37T3T6XABYU6G5LOHUEJFLIGIBT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
On Tue, May 05, 2020 at 05:26:02PM +0100, Henk-Jaap Wagenaar wrote:
> This is a straw man in regards to backwards compatibility. This particular
> (sub)thread is about whether if this zip-is-strict either as a separate
> name or a Boolean flag or some other flag of zip should be a built-in or be
> in e.g. itertools.
Please don't misuse "strawman" in that fashion. A strawman argument is a
logical fallacy where you attack a weaker position your opponent didn't
make in order to make your own position stronger. That's not what Chris
did, and frankly accusing him of strawmanning is a form of "poisoning
the well".
What Chris did was to propose a counterfactual to express his opinion on
this proposal. To paraphrase:
"If this were true (we were designing zip from scratch for the first
time) then I would agree with the proposal, but since we aren't, I
disagree because of these reasons."
That is a perfectly legitimate position to take.
"If we weren't in lockdown, I would take you out for dinner at a
restaurant, but since we are in quarantine, I don't think we
should go out."
Personally, I don't think Chris' backwards-compatibility argument is
strong. Technically adding a new keyword argument to a function is
backwards-incompatible, but we normally exclude that sort of change. Who
writes this?
# This behaviour will be changed by the proposed new parameter.
zip('', strict=1) # Raise a type error.
So I think the *backwards incompatibility* argument is weak in that
regard. But maybe Chris has got a different perspective on this that I
haven't thought of.
[Chris]
> > Should they? I'm not sure how well-supported this actually is. If you
> > hand-craft an AST and then compile it, is it supposed to catch every
> > possible malformation?
I would expect that the ast library should accept anything which could
come from legal Python, and nothing that doesn't.
--
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/GQZLWLOHFPBQLADHYLHW6JYY2X4S4ABA/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
On 05/05/2020 17:26, Henk-Jaap Wagenaar wrote: This is a straw man in regards to backwards compatibility. This particular (sub)thread is about whether if this zip-is-strict either as a separate name or a Boolean flag or some other flag of zip should be a built-in or be in e.g. itertools. It is not about breaking backwards compatibility (presumably by making it the default behaviour of zip). Except that that's part of the thinking involved in choosing a flag instead of the usual new function. No one (I think) is claiming that we should break backwards compatibility and default to strict=True, but having the flag is a strong statement that length-checking is an intrinsic part of zipping. I don't believe that's true, and in consequence I think adding a flag is a mistake. -- Rhodri James *-* Kynesim Ltd ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/5GURR7YTHRY43KSM5LW7U665KGR24MUA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
But you care about your input, you can do so by setting strict=True (if that's the road we go down), and unlike what others have said, the IDE I use (pycharm) would tell me that flag exists as I type "zip" and so I'd be more likely to use it than if it was in itertools/... On Tue, 5 May 2020, 16:41 Rhodri James, wrote: > On 05/05/2020 13:53, Henk-Jaap Wagenaar wrote: > > Brandt's example with ast in the stdlib I think is a pretty good example > of > > this. > > > > On Tue, 5 May 2020 at 13:27, Rhodri James wrote: > > > >> On 05/05/2020 13:12, Henk-Jaap Wagenaar wrote: > >>> A function that is a "safer" version in some "edge case" (not extra > >>> functionality but better error handling basically) but that does > >> otherwise > >>> work as expected is not something one will search for automatically. > This > >>> is zip versus zip-with-strict-true. > >> > >> I'm sorry, I don't buy it. This isn't an edge case, it's all about > >> whether you care about what your input is. In that sense, it's exactly > >> like the relationship between zip and zip_longest. > > Interesting, because I'd call it a counterexample to your point. The > bug's authors should have cared about their input, but didn't. > > -- > Rhodri James *-* Kynesim Ltd > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/IBSSGPEVGBDAQFKDEIDSAEPT26YBYMRP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
This is a straw man in regards to backwards compatibility. This particular (sub)thread is about whether if this zip-is-strict either as a separate name or a Boolean flag or some other flag of zip should be a built-in or be in e.g. itertools. It is not about breaking backwards compatibility (presumably by making it the default behaviour of zip). On Tue, 5 May 2020, 17:17 Chris Angelico, wrote: > On Wed, May 6, 2020 at 1:44 AM Rhodri James wrote: > > > > On 05/05/2020 13:53, Henk-Jaap Wagenaar wrote: > > > Brandt's example with ast in the stdlib I think is a pretty good > example of > > > this. > > > > > > On Tue, 5 May 2020 at 13:27, Rhodri James > wrote: > > > > > >> On 05/05/2020 13:12, Henk-Jaap Wagenaar wrote: > > >>> A function that is a "safer" version in some "edge case" (not extra > > >>> functionality but better error handling basically) but that does > > >> otherwise > > >>> work as expected is not something one will search for automatically. > This > > >>> is zip versus zip-with-strict-true. > > >> > > >> I'm sorry, I don't buy it. This isn't an edge case, it's all about > > >> whether you care about what your input is. In that sense, it's > exactly > > >> like the relationship between zip and zip_longest. > > > > Interesting, because I'd call it a counterexample to your point. The > > bug's authors should have cared about their input, but didn't. > > > > Should they? I'm not sure how well-supported this actually is. If you > hand-craft an AST and then compile it, is it supposed to catch every > possible malformation? Has Python ever made any promises about > *anything* regarding manual creation of AST nodes? Maybe it would be > *nice* if it noticed the bug for you, but if you're messing around > with this sort of thing, it's not that unreasonable to expect you to > get your inputs right. > > If you're creating a language from scratch and want to have separate > "strict" and "truncating" forms of zip, then by all means, go ahead. > But I think the advantage here is marginal and the backward > compatibility break large. > > ChrisA > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/3JKQREPI4CE2ZEB75URDQMGKEWHJEJVO/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/CZX6FMFGUAPXZYKJL3C6L2P3YOSGBAAA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
I have no idea whether a flag on zip() or a function in itertools would get MORE USE. I *ABSOLUTELY* think it is an anti-goal to get more use for its own sake though. I'm +1 on a new function in itertools, maybe +0 or maybe -0 on a flag. But I only want APPROPRIATE USE in any case. The API conventions of Python in general very strongly favor a new function. Yes, not everything in Python naming is consistent, and counter examples for any idea can surely be found. But it just is a lot less surprising to users to follow the predominant pattern that zip_longest(), for example, follows. The real point, to me, is that users who use itertools.zip_strict() will use it for exactly the reason that they want that semantics. In contrast, a flag for `strict` or `truncate` or `equal` or whatever is a LOT more likely to be used in the "just in case" code where the programmer has not thought carefully about the semantics they want. The sky isn't falling, I certainly don't think everyone, nor even most developers, would use the flag wrong. But a separate function just provides a better, more consistent, API. I don't think anyone in the huge discussion of the walrus operator, for example, tried to make the case that the goal should be encouraging it to be used AS MUCH AS POSSIBLE. Nor likewise for any other new feature. A feature should be used *where appropriate*, and the design should not vacantly simply try to make it more common. -- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VZ6HBRWZ4ZFBRYTSVEKRG4PMFNFUEGM6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
On Wed, May 6, 2020 at 1:44 AM Rhodri James wrote: > > On 05/05/2020 13:53, Henk-Jaap Wagenaar wrote: > > Brandt's example with ast in the stdlib I think is a pretty good example of > > this. > > > > On Tue, 5 May 2020 at 13:27, Rhodri James wrote: > > > >> On 05/05/2020 13:12, Henk-Jaap Wagenaar wrote: > >>> A function that is a "safer" version in some "edge case" (not extra > >>> functionality but better error handling basically) but that does > >> otherwise > >>> work as expected is not something one will search for automatically. This > >>> is zip versus zip-with-strict-true. > >> > >> I'm sorry, I don't buy it. This isn't an edge case, it's all about > >> whether you care about what your input is. In that sense, it's exactly > >> like the relationship between zip and zip_longest. > > Interesting, because I'd call it a counterexample to your point. The > bug's authors should have cared about their input, but didn't. > Should they? I'm not sure how well-supported this actually is. If you hand-craft an AST and then compile it, is it supposed to catch every possible malformation? Has Python ever made any promises about *anything* regarding manual creation of AST nodes? Maybe it would be *nice* if it noticed the bug for you, but if you're messing around with this sort of thing, it's not that unreasonable to expect you to get your inputs right. If you're creating a language from scratch and want to have separate "strict" and "truncating" forms of zip, then by all means, go ahead. But I think the advantage here is marginal and the backward compatibility break large. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3JKQREPI4CE2ZEB75URDQMGKEWHJEJVO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
On 05/05/2020 13:53, Henk-Jaap Wagenaar wrote: Brandt's example with ast in the stdlib I think is a pretty good example of this. On Tue, 5 May 2020 at 13:27, Rhodri James wrote: On 05/05/2020 13:12, Henk-Jaap Wagenaar wrote: A function that is a "safer" version in some "edge case" (not extra functionality but better error handling basically) but that does otherwise work as expected is not something one will search for automatically. This is zip versus zip-with-strict-true. I'm sorry, I don't buy it. This isn't an edge case, it's all about whether you care about what your input is. In that sense, it's exactly like the relationship between zip and zip_longest. Interesting, because I'd call it a counterexample to your point. The bug's authors should have cared about their input, but didn't. -- Rhodri James *-* Kynesim Ltd ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/OBJAU2776PJ5MAYUPNNHP6ZAVV53BC7E/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Passing Arguments Through Thin Wrappers (was : Auto-assign attributes from __init__ arguments)
> On 5 May 2020, at 15:38, Steven D'Aprano wrote: > > Here is a quick and dirty proof of concept: > > >from inspect import stack, Signature > >def parameters(): >caller = stack()[2][0].f_globals[stack()[1][3]] >sig = Signature.from_callable(caller) >vars = stack()[1][0].f_locals >return sig.bind(**vars).arguments > > >def func(spam, eggs): >params = parameters() >for name, value in params.items(): >print(name, '=', value) > > > Calling `func(2, 3)` prints: > >spam = 2 >eggs = 3 Is this to avoid locals()? Do you have a version that works inside a func of a class? I tried the obvious and it TB'ed: from inspect import stack, Signature def parameters(): caller = stack()[2][0].f_globals[stack()[1][3]] sig = Signature.from_callable(caller) vars = stack()[1][0].f_locals return sig.bind(**vars).arguments class X: def func(self, spam, eggs): params = parameters() for name, value in params.items(): print(name, '=', value) x = X() x.func( 1, 2 ) Traceback (most recent call last): File "args.py", line 25, in x.func( 1, 2 ) File "args.py", line 20, in func params = parameters() File "args.py", line 11, in parameters caller = stack()[2][0].f_globals[stack()[1][3]] KeyError: 'func' Barry > > > -- > Steven > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/62ZDUVMEKQEMBRTVHM2GYXZVJLPPHYBQ/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7BVSYMV4Q7SOOEGC5UDLMWVZ6XT5RVUY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Passing Arguments Through Thin Wrappers (was : Auto-assign attributes from __init__ arguments)
On 05.05.20 15:35, Dan Sommers wrote: On Tue, 5 May 2020 23:06:39 +1000 Steven D'Aprano wrote: ... help me solve the DRY problem for module-level functions: def function(spam, eggs, cheese, aardvark): do stuff call _private_function(spam, eggs, cheese, aardvark) since this bites me about twice as often as the `self.spam = spam` issue. (That's not me being snarky by the way, it's a genuine question: dataclasses are a mystery to me, so I don't know what they can and can't do.) Lisp macros have a "" feature that captures the entire collection of arguments to the macro: http://clhs.lisp.se/Body/03_dd.htm Perhaps Python could adopt something similar? Unlike *args and **kwargs, captures all of the parameters, not just the non-positional, non-named ones. The idea would be something like this: def function(spam, eggs, cheese, aardvark, ): do_stuff _private_function() which would call _private_function as function was called. What about a way for overloading function signatures? The arguments are then bound to both signatures and the function has access to all the parameters. For example: def function(spam, eggs, cheese, aardvark) with (*args): ... # do stuff _private_function(*args) Calling `function(1, 2, 3, 4)` results in `spam, eggs, cheese, aardvark = 1, 2, 3, 4` and `args = (1, 2, 3, 4)`. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/OHGIK5YHET6YUANFDT7RRXRT47AIAYM5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Passing Arguments Through Thin Wrappers (was : Auto-assign attributes from __init__ arguments)
Here is a quick and dirty proof of concept: from inspect import stack, Signature def parameters(): caller = stack()[2][0].f_globals[stack()[1][3]] sig = Signature.from_callable(caller) vars = stack()[1][0].f_locals return sig.bind(**vars).arguments def func(spam, eggs): params = parameters() for name, value in params.items(): print(name, '=', value) Calling `func(2, 3)` prints: spam = 2 eggs = 3 -- Steven ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/62ZDUVMEKQEMBRTVHM2GYXZVJLPPHYBQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Equality between some of the indexed collections
Steven D'Aprano wrote: > On Tue, May 05, 2020 at 09:34:28AM -, jdve...@gmail.com wrote: > > (frozenset() == set()) is True shocked > > me. > > According to wikipedia https://en.wikipedia.org/wiki/Equality_(mathematics): > > "equality is a relationship between two quantities or, more generally two > > mathematical > > expressions, asserting that the quantities have the same value, or that the > > expressions > > represent the same mathematical object." > > If lists and tuples are considered different "mathematical objects" > > (different types), they cannot be considered equal --tough they can be > > equivalent, for instance ([1, 2, 3] == list((1, 2, 3)) and tuple([1, > > 2, 3]) == (1, 2, 3)) is True. > > There is no good correspondence between "mathematical objects" and > types. Even in mathematics, it is not clear whether the integer 1 as the > same mathematical object as the real number 1, or the complex number 1, > or the quaternion 1. > In Python, we usually say that if a type is part of the numeric tower > ABC, then instances with the same numeric value should be considered > equal even if they have different types. But that's not a hard rule, > just a guideline. > And it certainly shouldn't be used as a precedent implying that > non-numeric values should behave the same way. > If you are looking for a single overriding consistant principle for > equality in Python, I think you are going to be disappointed. Python > does not pretend to be a formal mathematically consistent language > and the only principle for equality in Python is that equality means > whatever the object's __eq__ method wants it to mean. > > I can only explain (frozenset() == set()) is > > True vs (list() == tuple()) is False if: > > a) frozensets and sets are considered the same "mathematical > > > > objects". So immutability vs mutability is not a relevant feature in > > Python equality context. Then, list() == tuple() should be True > > if > > no other feature distinguishes lists from tuples, I suppose... > > List and tuple are distinguished by the most important feature of all: > the designer's intent. Tuples are records or structs, not frozen lists, > which is why they are called tuple not frozen list :-) even if people > use them as a defacto frozen list. > On the other hand, frozensets are frozen sets, which is why they compare > equal. > Does this make 100% perfectly logical sense? Probably not. But it > doesn't have to. Lists and tuples are considered to be independent kinds > of thing, while sets and frozensets are considered to be fundamentally > the same kind of thing differentiated by mutability. > (In hindsight, it might have been more logically clear if mutable sets > inherited from immutable frozensets, but we missed the chance to do > that.) Thanks for your reply. I do not expect any kind of full correspondence between mathematical objects and programming objects. Just reasoning by analogy and trying to understand how lists and tuples cannot be equal and frozensets and sets can be on similar grounds. Mostly asking than answering. Designers' intent is an admissible answer, of course. A cat and a dog can be equal if equality is defined as "having the same name". However, designers' intent is one thing, and users' understating is another one. >From your words, I have learnt that --from designers' point of view-- tuples >are different from lists in their nature while sets and frozensets are mostly >the same kind of thing --roughly speaking of course... I wonder if users share that view. I feel that it is not unreasonable to expect that frozenset and set cannot be equal on the grounds that they are different types (as tuples and lists are different types too). From that perspective, equality on tuples / lists and frozensets / sets should follow similar rules. Not being that way is surprising. That is all. However, if sets and frozensets are "are considered to be fundamentally the same kind of thing differentiated by mutability", as you said, why not tuples and lists? And that is, I guess, the reasoning behind proponent's claim. What if the difference between tuples and lists is not so deep or relevant and they just differ on mutability? Asking again... ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4AKVBC3GLGJLAQXB55NQA55KKELC6Y23/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
On Mon, Apr 27, 2020 at 01:39:19PM -0700, Christopher Barker wrote: > Can you think of a single case where a zip_equal() (either pre-exisiting or > roll your own) would not work, but the concretizing version would? That's easy: if the body of your zip-handling function has side-effects which must be atomic (or at least as atomic as Python code will allow). An atomic function has to either LBYL (e.g. check the lengths of the iterables before starting to zip them), or needs to be able to roll-back if a mismatch is found at the end. In the most general case, we can't roll-back easily, or at all, so if your requirements are to avoid partial operations, then you must concretize the input streams and check their lengths. But I don't think that's a problem for this proposal. Nobody is saying that zip_strict can solve all problems, and we shouldn't hold it against it that it doesn't solve the atomicity problem (which is very hard to solve in Python). -- Steven ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/DZ3WZGWIXS4XJ563BTOW6GMXSVKSETYZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Passing Arguments Through Thin Wrappers (was : Auto-assign attributes from __init__ arguments)
On Tue, 5 May 2020 23:06:39 +1000 Steven D'Aprano wrote: > ... help me solve the DRY problem for module-level functions: > > def function(spam, eggs, cheese, aardvark): > do stuff > call _private_function(spam, eggs, cheese, aardvark) > > since this bites me about twice as often as the `self.spam = spam` > issue. > > (That's not me being snarky by the way, it's a genuine question: > dataclasses are a mystery to me, so I don't know what they can and can't > do.) Lisp macros have a "" feature that captures the entire collection of arguments to the macro: http://clhs.lisp.se/Body/03_dd.htm Perhaps Python could adopt something similar? Unlike *args and **kwargs, captures all of the parameters, not just the non-positional, non-named ones. The idea would be something like this: def function(spam, eggs, cheese, aardvark, ): do_stuff _private_function() which would call _private_function as function was called. No, Lisp macros are not Python function calls. No, I'm not proposing that exact syntax. No, I haven't thought it through. Yes, it borders on magic, and may impinge on implicit vs. explicit. But evidently, Steven and I share this particular pattern, although I never considered it enough of a problem to "solve." Dan -- “Atoms are not things.” – Werner Heisenberg Dan Sommers, http://www.tombstonezero.net/dan ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/Y3X2FMS33BJ3F7CVNNOKX6LBJZ6XQXOL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Auto-assign attributes from __init__ arguments
On Tue, May 5, 2020 at 3:14 PM Steven D'Aprano wrote: > On Tue, May 05, 2020 at 02:55:24PM +0200, Alex Hall wrote: > > > Perhaps we should take the energy that is going into this thread and > direct > > it towards supporting keyword-only arguments in dataclasses, a discussion > > which is apparently struggling: > > Why? How are dataclasses relevant (don't assume it is as obvious to > everyone as it may be to you)? I'm especially interested in how > dataclasses may help me solve the DRY problem for module-level > functions: > > def function(spam, eggs, cheese, aardvark): > do stuff > call _private_function(spam, eggs, cheese, aardvark) > > since this bites me about twice as often as the `self.spam = spam` > issue. > Well this thread is meant to be about assigning attributes in `__init__`, which dataclasses do quite well, and OP specifically said (which I quoted) "Maybe a data class which supported kW-only args and pos-only args would suit my use case." Solving that problem seems quite attainable. Your idea for parameters() seems pretty good, but it's an ambitious proposal which sounds like it belongs in a new thread. That's just my opinion though, I'm pretty new here and don't know how this stuff works. I think attempting to solve the larger problem of repeating names (both in your example and the self.spam=spam problem) is best done with a shortcut for same-named parameters as we've been discussing recently, as it's more general and flexible. dataclasses are a mystery to me, so I don't know what they can and can't > do.) > This is interesting to me. When I first came across attrs I thought it was awesome, but I've never used it. When I heard about dataclasses I was excited and read all about them, but didn't use them for a long time. I've still barely used them. I know others have similar experiences. I wonder why they look so good on paper but just aren't used that much? ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/SXY6QC5TMZEJ77CR3APW5AYB2GR4LB34/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Auto-assign attributes from __init__ arguments
On Tue, May 05, 2020 at 02:55:24PM +0200, Alex Hall wrote: > Perhaps we should take the energy that is going into this thread and direct > it towards supporting keyword-only arguments in dataclasses, a discussion > which is apparently struggling: Why? How are dataclasses relevant (don't assume it is as obvious to everyone as it may be to you)? I'm especially interested in how dataclasses may help me solve the DRY problem for module-level functions: def function(spam, eggs, cheese, aardvark): do stuff call _private_function(spam, eggs, cheese, aardvark) since this bites me about twice as often as the `self.spam = spam` issue. (That's not me being snarky by the way, it's a genuine question: dataclasses are a mystery to me, so I don't know what they can and can't do.) -- Steven ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ECA4EHXIPF2SIY4V667BQ3VFMT4HUAEN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Auto-assign attributes from __init__ arguments
Perhaps we should take the energy that is going into this thread and direct it towards supporting keyword-only arguments in dataclasses, a discussion which is apparently struggling: https://github.com/python/cpython/pull/6238#issuecomment-584579729 On Mon, May 4, 2020 at 10:49 PM Lewis Ball wrote: > I did think about data classes and although I haven't really used them > much they do seem to be for a different use case, for example they don't > support keyword-only args or positional-only args. I'm not sure if there > are any other differences. Maybe a data class which supported kW-only args > and pos-only args would suit my use case. > > On Mon, 4 May 2020, 21:19 Henk-Jaap Wagenaar, > wrote: > >> You are not the first to have this idea. Unless I am mistaken you might >> find what you are looking for in dataclasses which were added in Python 3.7: >> >> https://docs.python.org/3/library/dataclasses.html >> > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/5Y3QLLTVT6VXGGUPTLM3SH5PKL5R36AD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
Brandt's example with ast in the stdlib I think is a pretty good example of this. On Tue, 5 May 2020 at 13:27, Rhodri James wrote: > On 05/05/2020 13:12, Henk-Jaap Wagenaar wrote: > > A function that is a "safer" version in some "edge case" (not extra > > functionality but better error handling basically) but that does > otherwise > > work as expected is not something one will search for automatically. This > > is zip versus zip-with-strict-true. > > I'm sorry, I don't buy it. This isn't an edge case, it's all about > whether you care about what your input is. In that sense, it's exactly > like the relationship between zip and zip_longest. > > -- > Rhodri James *-* Kynesim Ltd > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/U47NZNW5DIZLW34UTNEFYQ3ZCRW57EMU/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/TVK7DRO4LNEAH3PAB5IJB5DI6TOBJ3TJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Auto-assign attributes from __init__ arguments
On Tue, May 5, 2020 at 10:08 PM Steven D'Aprano wrote: > > On Tue, May 05, 2020 at 04:05:20AM -, Brandt Bucher wrote: > > It's a fairly common idiom to just collect `locals()` on the first > > line of a function or method with lots of arguments > > Indeed, but it's that requirement that it must be precisely on the first > executable statement of the function that makes it fragile. > Particularly sneaky is this problem: def __init__(self, x, y, z, a, b, c): stuff = locals() spam = "ham" # what's in stuff now? Does stuff["stuff"] have a value? What about stuff["spam"] ? You can't be sure. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ZROJCADGLY4HOARP4K7OH3JJEORWNZC4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
On 05/05/2020 13:12, Henk-Jaap Wagenaar wrote: A function that is a "safer" version in some "edge case" (not extra functionality but better error handling basically) but that does otherwise work as expected is not something one will search for automatically. This is zip versus zip-with-strict-true. I'm sorry, I don't buy it. This isn't an edge case, it's all about whether you care about what your input is. In that sense, it's exactly like the relationship between zip and zip_longest. -- Rhodri James *-* Kynesim Ltd ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/U47NZNW5DIZLW34UTNEFYQ3ZCRW57EMU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
I feel like that argument is flawed. I cannot think of another good example (I am sure there are plenty!) but there is a big difference for discoverability between: A function that does something *different* and functionality does not exist in a built-in (or whatever namespace you are considering). For example, zip_longest v.s. zip: if you have know/expect one of your iterators to run out early, but do not wish the zipping to end, normal zip won't do and so you will end up searching for an alternative. A function that is a "safer" version in some "edge case" (not extra functionality but better error handling basically) but that does otherwise work as expected is not something one will search for automatically. This is zip versus zip-with-strict-true. I did not phrase that particularly well, but I am hoping people get the gist/can rephrase it better. On Tue, 5 May 2020 at 11:34, Paul Moore wrote: > On Tue, 5 May 2020 at 07:22, Christopher Barker > wrote: > > > In any case, you seem to making the argument that a few of us are > putting forward: yes, a flag on zip() is likely to get more use than a > function in itertools. Thanks for the support :-) > > I'd like to add my voice to the people saying that if someone isn't > willing to go and find the correct function, and import it from the > correct module, to implement the behaviour that they want, then I have > no interest in making it easier for them to write their code > correctly, because they seem to have very little interest in > correctness. Can someone come up with any sort of credible argument > that someone who's trying to write their code correctly would be in > any way inconvenienced by having to get the functionality from > itertools? > > It seems like we're trying to design a way for people to > "accidentally" write correct code without trying to, and without > understanding what could go wrong if they use the current zip > function. I'm OK with "make it easy to do the right thing", but "make > it easy to do the right thing by accident" is a step too far IMO. > > Paul > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/E3C4GFR6XVFJFOPTKQX4VI647HHBJVYC/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ZFEBTPTOX4TMI42OGBSVQ37AMP3ZFFJQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Auto-assign attributes from __init__ arguments
On Tue, May 05, 2020 at 04:05:20AM -, Brandt Bucher wrote: > > We should have a mechanism that collects the current function or method's > > parameters into a dict, similar to the way locals() returns all local > > variables. > > Maybe I'm missing something here, but how about... `locals`? It works exactly > as you hope: Using locals() is fragile. Consider: # Works fine. def method(self, args, spam, eggs, cheese): var(self).update(locals()) for x in args: print(x) # Suprise! This is broken! def method(self, args, spam, eggs, cheese): for x in args: print(x) var(self).update(locals()) (For brevity, I have ignored the "filter out self" issue.) One might not even notice that you have exposed the local x. Most people write unit tests to check for the presence of expected attributes; I don't know anyone who writes unit tests for the *absense* of unexpected attributes. The problem with locals() is that as soon as you move the call to locals out of the very first executable statement in the method, you risk contaminating it with unwanted local variables that aren't parameters. The most insidious problem will be cases that *nearly always* work: if very_rare_condition: x = something ... vars(self).update(**locals()) > It's a fairly common idiom to just collect `locals()` on the first > line of a function or method with lots of arguments Indeed, but it's that requirement that it must be precisely on the first executable statement of the function that makes it fragile. -- Steven ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/LG72WHK3GAKM6HZ3LGSLFXAGZRPWMPTG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Equality between some of the indexed collections
On Tue, May 05, 2020 at 09:34:28AM -, jdve...@gmail.com wrote: > `(frozenset() == set()) is True` shocked me. > > According to wikipedia https://en.wikipedia.org/wiki/Equality_(mathematics): > "equality is a relationship between two quantities or, more generally two > mathematical expressions, asserting that the quantities have the same value, > or that the expressions represent the same mathematical object." > > If lists and tuples are considered different "mathematical objects" > (different types), they cannot be considered equal --tough they can be > equivalent, for instance `([1, 2, 3] == list((1, 2, 3)) and tuple([1, > 2, 3]) == (1, 2, 3)) is True`. There is no good correspondence between "mathematical objects" and types. Even in mathematics, it is not clear whether the integer 1 as the same mathematical object as the real number 1, or the complex number 1, or the quaternion 1. In Python, we usually say that if a type is part of the numeric tower ABC, then instances with the same numeric value should be considered equal even if they have different types. But that's not a hard rule, just a guideline. And it certainly shouldn't be used as a precedent implying that non-numeric values should behave the same way. If you are looking for a single overriding consistant principle for equality in Python, I think you are going to be disappointed. Python does not pretend to be a formal mathematically consistent language and the only principle for equality in Python is that equality means whatever the object's `__eq__` method wants it to mean. > I can only explain `(frozenset() == set()) is True` vs `(list() == tuple()) > is False` if: > > a) `frozenset`s and `set`s are considered the same "mathematical > objects". So immutability vs mutability is not a relevant feature in > Python equality context. Then, `list() == tuple()` should be `True` if > no other feature distinguishes lists from tuples, I suppose... List and tuple are distinguished by the most important feature of all: the designer's intent. Tuples are records or structs, not frozen lists, which is why they are called tuple not frozen list :-) even if people use them as a defacto frozen list. On the other hand, frozensets are frozen sets, which is why they compare equal. Does this make 100% perfectly logical sense? Probably not. But it doesn't have to. Lists and tuples are considered to be independent kinds of thing, while sets and frozensets are considered to be fundamentally the same kind of thing differentiated by mutability. (In hindsight, it might have been more logically clear if mutable sets inherited from immutable frozensets, but we missed the chance to do that.) -- Steven ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/LF6OX37N47GMEQQMCSKQ2UJQY2RP7WYM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
On Tue, 5 May 2020 at 07:22, Christopher Barker wrote: > In any case, you seem to making the argument that a few of us are putting > forward: yes, a flag on zip() is likely to get more use than a function in > itertools. Thanks for the support :-) I'd like to add my voice to the people saying that if someone isn't willing to go and find the correct function, and import it from the correct module, to implement the behaviour that they want, then I have no interest in making it easier for them to write their code correctly, because they seem to have very little interest in correctness. Can someone come up with any sort of credible argument that someone who's trying to write their code correctly would be in any way inconvenienced by having to get the functionality from itertools? It seems like we're trying to design a way for people to "accidentally" write correct code without trying to, and without understanding what could go wrong if they use the current zip function. I'm OK with "make it easy to do the right thing", but "make it easy to do the right thing by accident" is a step too far IMO. Paul ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/E3C4GFR6XVFJFOPTKQX4VI647HHBJVYC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Equality between some of the indexed collections
On Tue, May 5, 2020 at 7:36 AM Raymond Hettinger < raymond.hettin...@gmail.com> wrote: > >> Isn't a tuple essentially just a frozenlist? I know the intended > >> semantics of tuples and lists tend to be different, but I'm not sure > that's > >> relevant. > > > In terms of API, it might look that way. But in terms of use cases, they > are less alike: lists-are-looping, tuples-are-for-nonhomongenous-fields. > List are like database tables; tuples are like records in the database. > Lists are like C arrays; tuples are like structs. > Right, that's what I'm referring to. If you're comparing two things which are meant to represent completely different entities (say, comparing a record to a table) then your code is probably completely broken (why would you be doing that?) and having equality return False isn't going to fix that. Conversely I can't see how returning True could break a program that would work correctly otherwise. If you're comparing a list and a tuple, and you haven't completely screwed up, you probably mean to compare the elements and you made a small mistake, e.g. you used the wrong brackets, or you forgot that *args produces a tuple. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3NYG6HCBEHWT44HBLWYVF5W3FKN3L27Y/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Equality between some of the indexed collections
Raymond Hettinger wrote:
> > On May 3, 2020, at 6:19 PM, Steven D'Aprano st...@pearwood.info wrote:
> > frozenset and set make a counterexample:
> > frozenset({1}) == {1}
> > True
> > Nice catch! That's really interesting. Is there reasoning
> > behind
> > frozenset({1}) == {1} but [1] != (1,), or is it just an accident
> > of
> > history?
> > Conceptually, sets are sets, whether they are mutable or frozen.
> > Right. This isn't an accident. It is by design.
> Also, some numeric types are specifically designed for cross-type comparison:
> >>> int(3) == float(3) == complex(3, 0)
> True
>
> And in Python 2, by design, str and unicode were comparable:
> >>> u'abc' == 'abc'
> True
>
> But the general rule is that objects aren't cross-type comparable by default.
> We have
> to specifically enable that behavior when we think it universally makes
> sense. The modern
> trend is to avoid cross-type comparability, enumerates and data classes for
> example:
> >>> Furniture = Enum('Furniture', ('table', 'chair', 'couch'))
> >>> HTML = Enum('HTML', ('dl', 'ol', 'ul', 'table'))
> >>> Furniture.table == HTML.table
> False
>
> >>> A = make_dataclass('A', 'x')
> >>> B = make_dataclass('B', 'x')
> >>> A(10) == B(10)
> False
>
> Bytes and str are not comparable in Python 3:
> >>> b'abc' == 'abc'
> False
>
> > Isn't a tuple
> > essentially just a frozenlist? I know the intended
> > semantics of tuples and lists tend to be different, but I'm not sure that's
> > relevant.
> > In terms of API, it might look that way. But in terms of use cases, they
> are less alike: lists-are-looping, tuples-are-for-nonhomongenous-fields.
> List are like
> database tables; tuples are like records in the database. Lists are like C
> arrays;
> tuples are like structs.
> On the balance, I think more harm than good would result from making sequence
> equality
> not depend on type. Also when needed, it isn't difficult to be explicit that
> you're
> converting to a common type to focus on contents:
> >>> s = bytes([10, 20, 30])
> >>> t = (10, 20, 30)
> >>> list(s) == list(t)
>
> When you think about it, it makes sense that a user gets to choose whether
> equality is
> determined by contents or by contents and type. For some drinkers, a can of
> beer is equal
> to a bottle of bear; for some drinkers, they aren't equal at all ;-)
> Lastly, when it comes to containers. They each get to make their own rules
> about what
> is equal. Dicts compare on contents regardless of order, but OrderedDict
> requires that
> the order matches.
> Raymond
`(frozenset() == set()) is True` shocked me.
According to wikipedia https://en.wikipedia.org/wiki/Equality_(mathematics):
"equality is a relationship between two quantities or, more generally two
mathematical expressions, asserting that the quantities have the same value, or
that the expressions represent the same mathematical object."
If lists and tuples are considered different "mathematical objects" (different
types), they cannot be considered equal --tough they can be equivalent, for
instance `([1, 2, 3] == list((1, 2, 3)) and tuple([1, 2, 3]) == (1, 2, 3)) is
True`.
I can only explain `(frozenset() == set()) is True` vs `(list() == tuple()) is
False` if:
a) `frozenset`s and `set`s are considered the same "mathematical objects". So
immutability vs mutability is not a relevant feature in Python equality
context. Then, `list() == tuple()` should be `True` if no other feature
distinguishes lists from tuples, I suppose...
b) language designers found `(frozenset() == set()) is True` convenient (why?).
Then, why is not `(list() == tuple()) is True` so convenient?
c) it is a bug and `frozenset() == set()` should be `True`.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/KWMD2ILZ4YN3V2A75HCDFX7YIL7S5FWL/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
Steven: I understand that Alex said he thought that putting "strict" in as a flag would make it a bit more likely that people would use, and that he thinks that's a good thing, and you think that's a bad thing, but... Unless we were to make it the default behavior, very few people are going to be adding this flag "just in case". And the fact that you think that making it a flag will make it more likely that folks will use it is an argument for making it a flag. Unless you don't like the idea at all, and want it to be more obscure and hard to find. In any case, you seem to making the argument that a few of us are putting forward: yes, a flag on zip() is likely to get more use than a function in itertools. Thanks for the support :-) However, you also seem to be making the argument that this feature would do more harm than good. I disagree, but if that's what you think, then it shouldn't be added at all, so please make that case, rather than arguing for adding it, but making it harder to find. -CHB On Mon, May 4, 2020 at 6:54 PM Steven D'Aprano wrote: > On Mon, May 04, 2020 at 09:20:28PM +0200, Alex Hall wrote: > > > > Seriously, if some object defines a weird `__eq__` then half the > > > standard library, including builtins, stops working "correctly". See > for > > > example the behaviour of float NANs in lists. > > > > > > My care factor for this is negligible, until such time that it is > proven > > > to be an issue for real objects in real code. Until then, YAGNI. > > > > Here is an example: > > Alex, I understand the point you are trying to make, and I got the > reference to numpy the first time you referenced it. I just don't care > about it. As far as I am concerned, numpy array's equality behaviour is > even more broken than float NANs, and it's not the stdlib's > responsibility to guarantee "correctness" (for some definition thereof) > if you use broken classes in your data -- especially not for something > of marginal value as "zip_strict", as you admitted yourself: > > "The problem is that no one really *needs* this check. You *can* do > without it." > > Right. So it's a "nice-to-have", not an essential function, and it can > go into intertools. The itertools implementer can decide for themselves > whether they care to provide a C accelerated version as well as a > Python version from Day 1, or even whether a recipe is enough. > > My point here is entirely that we shouldn't feel ourselves forced into > *premptively* providing a C version, let alone making this a builtin, > just because `x in y` breaks if one of the elements of y is a numpy > array. numpy itself doesn't need this function, they do their own length > checks. > > > -- > Steven > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/ZIQZLTKRMGSCELSWZ2EQCW24CZ44B4MG/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3EHXR3JUAKXYQEQZ2WRYHZBXKQD25SGZ/ Code of Conduct: http://python.org/psf/codeofconduct/
