As a point of interest, is get() considered an official part of the
mapping protocol, or just nice-to-have?
The docs don't seem to be very clear about that. There used to be
some tables listing the methods making up the core sequence and
mapping protocols, but I can't find them now. Have they
On 26/08/20 10:03 am, Stefano Borini wrote:
But you have a point that whatever the implementation might be, it has
to play nice with the current dict() behavior. Yet, if we were to add
an enhanced dunder, nothing for the current dict would change.
Despite arguing against it earlier, I think
On 24/08/20 3:24 am, Raihan Rasheed Apurbo wrote:
In CPython we have reference counting. My question is can we optimize
current RC using strategies like Deferred RC and Coalescing? If no
then where would I face problem if I try to implement these sorts of
strategies?
I gather there have been
On 22/08/20 6:43 am, Serhiy Storchaka wrote:
It would have non-zero cost. There is a common idiom:
try:
from foo import bar
except ImportError:
def bar(): ...
In this case you would need to try importing foo from other locations.
I wouldn't suggest going that far.
Maybe check whether the module being imported from is shadowing another
module further along the search path and warn about that?
--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to
On 18/08/20 5:39 pm, Marco Sulla wrote:
The new `@const` will be added as a hook to the PEG parser. if the PEG
parser finds a `@const`, it will invoke the miniparser of `mykeywords`
module inherent to `@const`.
I don't think this is likely to be accepted into the language. Guido has
always
On 18/08/20 7:58 am, Marco Sulla wrote:
My proposal is to add a way for third party modules to add custom
keywords. Example:
from mykeywords import @const
@const a = 1
What would that mean?
--
Greg
___
Python-ideas mailing list --
On 18/08/20 6:37 am, Jonathan Fine wrote:
if
>>> something[*argv]
is allowed, then what was a syntax error becomes a run-time error.
I don't think so. If argv is empty, this is more akin to
x = ()
something(x)
which we presumably still want to allow.
Opponents of a[] aren't
On 18/08/20 6:00 am, Christopher Barker wrote:
But from a language design perspective, the [] operator is a way to
"index" a container -- get part of the container's contents. And from
this perspective, no index makes no sense.
It can make sense if you have a zero-dimensional array. Or as
On 17/08/20 9:58 pm, Antoine Pitrou wrote:
Probably because exploiting Python abstraction facilities to build DSLs
has/had long been frown upon in this community? That was the leitmotiv
back when people were marvelling over Ruby's flexibility in the area.
As far as I remember, what was
On 17/08/20 8:19 am, Sebastian Berg wrote:
[1] The difference is that `arr[()]` extracts a scalar, while
`arr[...]` returns the array (container) unchanged. This difference
only matters for zero dimensional arrays. There may be reasons to
prefer one over the other, but I can't think of any
On 16/08/20 11:49 am, Guido van Rossum wrote:
SEMANTICS OF NO ARGUMENTS
I can see two basic ways of allowing no arguments. One is for the
interpreter to construct an object that is the argument passed to
__getitem__ and so forth. The other is to not pass an argument at
all. I
On 16/08/20 4:26 am, Ricky Teachey wrote:
There are certainly
instances where I've needed to used matrices to solve a system of
equations in an automated way. But most of time it's simply not needed,
If we're going to have a class that supports matrix multiplication,
I think we should at
On 15/08/20 5:31 am, Stephen J. Turnbull wrote:
It seems to me you could have a Tensor
class whose constructor takes a bool argument 'contravariant' (default
False), and then recommend that users adopt a naming convention to
distinguish covariant Tensors from contravariant Tensors.
You would
On 14/08/20 9:05 pm, Marco Sulla wrote:
Another big problem with tensors is the covariance and contravariance.
Usually in informatic you denote the covariance with the subscript
operator, that on paper is written as subscript. Contravariant index
on the contrary is a superscript. Not sure how a
Another class of folks who might find something like this useful
is those playing around with computer graphics using pygame,
pyglet, etc. where coordinate transformations are used a lot.
Bringing in numpy for that can seem like massive overkill
for a tiny game.
--
Greg
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 seems reasonable to me
that this should be legal.
>>> d[x=1, y=2] = 42
>>> d[x=1,
On 9/08/20 10:43 am, Guido van Rossum wrote:
But integer ranges? I guess they would be useful to catch array indexing
mistakes,
I'm not sure they would. For an index error to be caught at compile
time, the thing being indexed has to have a size known to the
compiler. This was always the case
On 8/08/20 3:24 am, Paul Moore wrote:
def is_valid_specifier(s):
try:
packaging.specifiers.SpecifierSet(s)
return True
except packahing.specifiers.InvalidSpecifier:
return False
This doesn't quite follow the pattern, because it doesn't return
the result of
On 4/08/20 9:12 am, Guido van Rossum wrote:
then presumably calling `c[1, index=2]` would just be an error (since it
would be like attempting to call the method with two values for the
`index` argument),
Hmmm, does this mean that classes providing index notation would
now need to document the
On 8/08/20 4:09 am, Ricky Teachey wrote:
If that incongruity were to be fixed, it seems to me it would become
*obvious* that the semantic meaning of ` m[1, 2, a=3, b=2]` should
definitely be:
m.__get__(1, 2, a=3, b=4)
It would certainly achieve that goal. The question is whether it would
be
On 7/08/20 2:47 am, David Mertz wrote:
The only difference is that in the usual existing style, 'a' doesn't
know that it's called "a". You and Steven have both, basically, said
"Why would you possibly care about that?"
I've only really been thinking about attributes, but I suppose
it might
On 6/08/20 6:42 am, David Mertz wrote:
@unit("meter") a = 3 # a = unit("meter")("a", 3)
@unit("foot") b = 4 # b = unit("foot")("b", 4)
This still doesn't explain why the decorator syntax would be
significantly better than just calling the function directly.
meters = unit("meter")
feet =
On 6/08/20 1:35 am, Marco Sulla wrote:
I suppose that what Greg Ewing suggests is a way to define a sort of
custom simple statement.
you could write
@print
"Hello"
My suggestion was only for decorating assignments to a bare name,
so that wouldn't have been legal.
But that was l
On 5/08/20 9:13 pm, Serhiy Storchaka wrote:
the code can be written as
class Neuron:
activation = linear_activation(activation)
I do not see reasons to introduce special syntax for this very specific
code.
A considerable number of moons ago, I suggested that
@my_property
On 4/08/20 1:16 pm, Steven D'Aprano wrote:
Why would we want to even consider a new approach to handling keyword
arguments which applies only to three dunder methods, `__getitem__`,
`__setitem__` and `__delitem__`, instead of handling keyword arguments
in the same way that every other method
On 4/08/20 6:35 pm, Greg Ewing wrote:
Has anyone suggested attaching the keyword args as attributes
on the slice object?
Realised after sending that this idea is rubbish, because
there can be more than one slice object.
--
Greg
___
Python-ideas
On 4/08/20 9:20 am, Todd wrote:
Another approach could be too simply pass the labelled indices in a dict
as a third/fourth positional argument.
Has anyone suggested attaching the keyword args as attributes
on the slice object?
This would avoid changing the signature of __getitem__, and
On 31/07/20 4:04 am, Christopher Barker wrote:
(Side note: why ARE the views provided by methods, rather than
properties?
Probably because they construct objects, and are therefore
somewhat more expensive than is usually expected for an
attribute access.
--
Greg
How about we just document the whole feature as deprecated
and never speak of it again?
--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
On 26/07/20 1:34 am, Elizabeth Shashkova wrote:
1. We need this lazy `__repr__` calculation inside our debugger, where
we work with different user's objects. Usually it isn't some specific
type, for which you know that it'll be big and its `__repr__`
calculation will be slow
Seems to me it
On 12/07/20 1:01 pm, Edwin Zimmerman wrote:
As I see it, the unsafe callables (eval, exec, os.system, etc) are generally
functions, and safe ones(int, list, dict) are generally classes, though there
certainly would be exceptions.
Where security is concerned, "there certainly would be
On 12/07/20 8:54 am, Wes Turner wrote:
Would it be feasible to just NOP callables when safe=True?
This would break pickle, because calling constructors is
the way many objects are unpickled. And it's not easy to
tell which callables are safe to use as constructors and
which aren't.
--
Greg
On 12/07/20 5:31 am, Wes Turner wrote:
Is there already a way to load data and not code *with pickle*?
As far as I know, pickle has never been able to load code
objects.
The security problems come from the fact that by default a
pickle is able to *call* any module-level callable object
that
On 10/07/20 8:05 am, Christopher Barker wrote:
if not (withrdrawal_amount > balance):
give_cash_to_customer(withdrawal_amount)
Unfortunately, with my luck they will have coded it as
if withdrawal_amount <= balance:
give_cash_to_customer(withdrawal_amount)
But my bigger concern is
On 9/07/20 10:25 pm, Jonathan Fine wrote:
I particularly liked the Tideford Butterscotch Rice Pudding, at NaNp per
100g.
I'd be a bit worried that if I bought one of those, I'd end
up with a balance of NaN in my bank account. I hate to think
what sort of havoc that would cause...
--
Greg
On 6/07/20 3:55 am, Steven D'Aprano wrote:
With that interpretation, a NAN passed as the lower or upper bounds can
be seen as another way of saying "no lower bounds" (i.e. negative
infinity) or "no upper bounds" (i.e. positive infinity), not "some
unknown bounds".
Python already has a value
On 5/07/20 4:39 pm, Steven D'Aprano wrote:
Complex numbers represent points on a plane; it is very common in
graphical toolkits to need to clamp an object to within some window or
other region of the plane,
But graphical toolkits don't treat points as complex numbers.
The question is whether
On 5/07/20 7:33 am, Henk-Jaap Wagenaar wrote:
min(0, float('nan')) == 0 and same for max. I would hence
expect clamp to behave similarly.
But min(float('nan'), 0) == nan.
I don't think you can conclude anything from either of
these about how clamp() *should* behave in the presence
of nans,
On 3/07/20 6:33 pm, Serhiy Storchaka wrote:
it is possible to implement pickling support for property
objects which will fail with your example (and I think third-party
libraries do it). The difference is that full qualified names of getter
and setter differ from the full qualified name of the
On 3/07/20 5:42 am, Matthew Einhorn wrote:
Similarly, if you wanted to overwrite a property by using this
property approach in the sub-class, but also call super for the
parent's class property getter from within the get/set this wouldn't
work!?
Realised after sending that you were talking
On 3/07/20 5:42 am, Matthew Einhorn wrote:
I think what he may have meant is that if you tried accessing a
double-underscore property of the outer class from the get/set methods,
it won't properly de-mangle.
Ah, I see what you mean. I don't think that's a fatal problem;
double-underscore
On 2/07/20 10:49 pm, Stestagg wrote:
Coincidentally, cython has a custom, deprecated syntax for properties
that is actually pretty similar
Not entirely a coincidence -- I invented that syntax for Pyrex,
and Cython inherited it.
I'm a little disappointed to hear it's been deprecated. :-(
--
On 2/07/20 9:00 pm, Steven D'Aprano wrote:
Perhaps Greg meant to say *up to* rather than "no less".
What I said is true for sufficiently small values of 5. :-)
You're right that it depends on how many operations you
want. For reading and writing it's 3; if you want deleting
as well it's 5.
On 2/07/20 9:45 pm, Chris Angelico wrote:
On Thu, Jul 2, 2020 at 7:41 PM Alex Hall wrote:
On Thu, Jul 2, 2020 at 11:33 AM Chris Angelico wrote:
What's the idea being discussed? AIUI there's no need or request to
change the language/stdlib, but maybe I'm misreading.
Ah, now I understand.
On 2/07/20 8:04 pm, Serhiy Storchaka wrote:
It has a problem with pickling (it is solvable).
Can you elaborate? The end result is a property object just the
same as you would get from using @property or calling property
directly. I don't see how it can have any pickling problems
beyond what
The @property.getter and @property.setter decorators are
clever, but they have the disadvantage that you end up
writing the name of the property no less than 5 times,
all of which have to match.
Thinking there must be a better way, I came up with this:
def Property(name, bases, dict):
On 27/06/20 5:30 pm, David Mertz wrote:
My point is that _Elements of Style_ is not a set of rules. It's a nice
book with generally good advice; it's not a style guide in a formal
sense.
Also, does it actually say anything that would forbid or discourage
use of terms such as "chocker" and
On 27/06/20 4:25 pm, Steven D'Aprano wrote:
Seriously, I genuinely thought that the existing behaviour was the
opposite and that `add` unconditionally added the element. "Last seen
wins".
The fact that you haven't noticed until now suggests that
you've never written any code that depends on
On 27/06/20 4:33 pm, Steven D'Aprano wrote:
Take the word out of the sentence, and does the sentence still mean the
same thing? Then the word was needless. That's an objective test.
But in something a fuzzy as natural language, "the same thing"
is not a boolean value. How close in meaning does
On 26/06/20 4:01 am, Steele Farnsworth wrote:
My point was only that, as far as I know, all the methods for built in
container types that serve only to change what is contained return None,
and that this was an intentional design choice, so changing it in one
case would have to evoke a larger
On 26/06/20 2:45 am, Steele Farnsworth wrote:
Personally, I'd want to see mutator methods return `self` so you can do
more than one mutation in a statement, but the convention is that all
the mutator methods return `None`.
I would say the convention is that mutator methods don't return
On 23/06/20 3:23 am, Jonathan Crall wrote:
Indicator variables which take a value of either zero are one are
extremely common.
Yes, but they're explicitly defined as numbers, not truth values.
--
Greg
___
Python-ideas mailing list --
On 22/06/20 12:19 pm, Neil Girdhar wrote:
I'm just curious if there was a reason why Boolean was omitted from the
numeric tower in the numbers library?
Python's bool type is a subclass of int for historical reasons,
not because it's conceptually a numeric type. Doing arithmetic on
it doesn't
On 20/06/20 1:15 pm, Steven D'Aprano wrote:
Here is some evidence that cache misses makes a real difference for
performance. A 70% slow down on calling functions, due to an increase in
L1 cache misses:
https://bugs.python.org/issue28618
There's no doubt that cache misses are a big issue for
On 19/06/20 9:28 am, Steven D'Aprano wrote:
I know very little about how this works except a vague rule of thumb
that in the 21st century memory locality is king. If you want code to be
fast, keep it close together, not spread out.
Python objects are already scattered all over memory, and a
On 18/06/20 3:00 am, Christopher Barker wrote:
3. String representations and parsing for infinity data (positive and
negative).
yup -- let the bike shedding begin!
My bikeshed suggestions:
DISTANT_FUTURE and DISTANT_PAST for datetimes
MUCH_LATER and MUCH_EARLIER for timedeltas
--
On 17/06/20 5:42 pm, David Mertz wrote:
I think the argument 'allow_nan' is poorly spelled. Spelling it 'strict'
would have been much better. Maybe 'conformant'.
It should be called 'json_me_harder'.
--
Greg
___
Python-ideas mailing list --
On 16/06/20 4:16 am, Barry Scott wrote:
even unchanging objects get modified by a ref count inc/dec cycle
and then the page that the object is in is copy-on-write'ed.
End result is that a children share no pages with the parent.
I wonder if it's worth trying to do anything about that? Like
On 15/06/20 5:11 pm, Steve Barnes wrote:
Of course if we had a NaN value for integers, int('NaN'), then we could just
set the initial count to it and since NaN - anything = NaN all would be golden.
Or we could use floating-point reference counts...
--
Greg
On 15/06/20 3:52 am, David Mertz wrote:
I've had occasion to use math.isclose(), np.isclose(), and np.allclose()
quite often.
Can you elaborate a bit on the kinds of things you use them for?
--
Greg
___
Python-ideas mailing list --
On 15/06/20 3:36 am, Paul Moore wrote:
def foo() -> {1, 2, 3}:
return 2
That is, of course, valid syntax right now. I wonder what a type
checker could do with it?
Even if it understood your intent, it probably couldn't do much,
because enforcing that constraint would require a run-time
On 15/06/20 12:39 am, Sebastian M. Ernst wrote:
It's such a common problem when dealing with floating point numbers
Is it really? I've done quite a lot of work with floating
point numbers, and I've very rarely needed to compare two
of them for almost-equality. When I do, I always want to
be in
On 14/06/20 1:42 pm, Chris Angelico wrote:
Hmm, I think I see what you mean. So awaiting it would be "spam(123)"
No, it would still be "await spam(123)". It's just that you wouldn't
be able to separate the await from the call, so this wouldn't be
allowed:
a = spam(123)
await a
On 14/06/20 12:05 pm, Chris Angelico wrote:
On Sun, Jun 14, 2020 at 9:54 AM Greg Ewing wrote:
Likewise, it's legitimate to create an awaitable
object and then await it later.
(Personally I think it *shouldn't* be legitimate to do that in
the case of await, but Guido thinks otherwise, so
Allowing the 'await' keyword to be omitted would also present some
semantic and implementation difficulties. The mechanism behind
'await' is essentially the same as 'yield from', so you're more
or less asking for 'yield from' to be automagically applied to
the result of an expression.
But this
On 13/06/20 8:47 am, J. Pic wrote:
Why not make using await do asyncio.run "behind the scenes" when called
outside async function ?
That would directly tie the await syntax to the asyncio module. This
would not be a good idea. Currently there is nothing special about
asyncio -- it's just one
On 13/06/20 3:02 pm, Steven D'Aprano wrote:
Coroutines are lighter weight than threads because they don't need all
the machinary to pre-emptively run threads in parallel; threads are
lighter weight than processes because they don't need to be in separate
memory spaces enforced by the OS.
Well,
On 13/06/20 9:37 am, Chris Angelico wrote:
If you don't care where the context
switches happen and just want everything to behave sanely by default,
use threads, not coroutines.
There are other reasons for using coroutines, such as the fact that
they're very lightweight compared to threads.
On 11/06/20 2:08 pm, Jonathan Goble wrote:
+1 for the limited idea of bringing back the print statement with
positional arguments only, as syntactic sugar (and not a replacement)
for the print function
Would that apply only to the actual built-in print function, or
would it work for any
I seem to remember reading somewhere that some very early
Lisp systems had a REPL that allowed you to omit the parentheses
around a top-level call. But that feature seems to have sunk
without trace in the swamps of history. I can't see a good
reason for Python to refloat it.
--
Greg
On 10/06/20 1:56 pm, Ricky Teachey wrote:
I have a question. Is there a very good reason that the language allows
spaces between function names and the parentheses?
>>> print (1,2,3)
Python, in common with many other languages, allows whitespace
between any pair of lexical tokens.
Why is this being proposed?
I think we would need a very strong reason to consider this,
and so far I haven't seen any justification other than "because
we can".
--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an
On 31/05/20 1:31 am, Steven D'Aprano wrote:
On Thu, May 28, 2020 at 10:27:47PM +1200, Greg Ewing wrote:
On 28/05/20 7:31 pm, Chris Angelico wrote:
Is it an implementation detail that 4 will be used for eggs if it
isn't passed?
The default value of eggs
being 4 is a static fact, but creating
On 30/05/20 8:03 pm, Steven D'Aprano wrote:
Is this `?=` idea for a general purpose operator we can use anywhere we
like?
I introduced it as part of a two-part idea for allowing optional
parameters without a default. But there would be nothing to stop
you from using it elsewhere.
The syntax
On 30/05/20 7:15 pm, Steven D'Aprano wrote:
Out of curiosity, which languages are you thinking of? I know Lua does
that, I can't think of any others.
You've probably never seen the one I'm thinking of. It's a
proprietary, vaguely VB-like language used for scripting a
particular application. It
On 30/05/20 4:28 pm, Steven D'Aprano wrote:
py> len()
TypeError: len() takes exactly one argument (0 given)
to be replaced with something like this:
UnboundLocalError: local variable referenced before assignment
Not in my version of the idea, because a parameter would only be
On 30/05/20 2:52 am, Dominik Vilsmeier wrote:
Indeed locals are special, but why was it designed this way? Why not
resolve such an unbound local name in the enclosing scopes?
From experience with other languages I can attest that "sometimes
local, sometimes global depending on what gets
On 30/05/20 12:11 am, Steven D'Aprano wrote:
I said that the storage mechanism of *how* local variables are stored,
and hence whether or not writes to `locals()` are reflected in the
local variables, is an implementation detail.
That's true, but just to be clear, my ?= idea doesn't rely on
On 29/05/20 11:49 pm, Steven D'Aprano wrote:
Where else would you put the parameter defaults, if not in the parameter
list?
In some part of the function that's not the parameter list. :-)
There are many ways it could be done. I've suggested one already
(a special assignment statement).
On 29/05/20 8:05 am, tritium-l...@sdamon.com wrote:
People write main entry points that are not exactly this?
If __name__ == '__main__':
sys.exit(main(sys.argv[1:]))
It's not clear that exiting with the return value of main() is
the most Pythonic thing to do -- it's more of a C idiom
On 29/05/20 12:17 am, Richard Damon wrote:
But default values for arguments are really part of the responsibility
for the caller, not the called function. The classic implementation
would be that the caller passes all of the explicitly,
I would say that's really a less-than-ideal
On 28/05/20 8:57 pm, Steven D'Aprano wrote:
The default value used by a parameter is certainly important, and one of
the most common reasons I call `help(func)` is to see what the default
values are. They should be in the signature, and it is an annoyance when
all the signature shows is that it
On 28/05/20 7:31 pm, Chris Angelico wrote:
Is it an implementation detail that 4 will be used for eggs if it
isn't passed?
That feels different to me somehow. I think it has something to do
with declarative vs. procedural stuff. The default value of eggs
being 4 is a static fact, but creating
On 28/05/20 12:38 pm, Rob Cliffe wrote:
why not go
further (as the OP suggested as far as I recall)
and allow the more concise
def order(eggs = 4, spam ?= Spam()):
etc.
That clutters up the header with things that are not part of
the function's signature. All the caller needs
On 27/05/20 7:36 am, Alex Hall wrote:
the only benefit I'm seeing is being able to avoid typing `if obj is
sentinel`. In fact it saves even less typing than other proposals since
you still have to write `obj ?= value`.
"Did the user supply a value for this optional argument?" is
a simple and
Wild idea: Instead of sentinels, have a way of declaring optional
arguments with no default, and a way of conditionally assigning a
value to them if they are not bound.
E.g.
def order(eggs = 4, spam =):
spam ?= Spam()
Here the '?=' means "if spam is not bound, then evaluate the
rhs
On 25/05/20 3:27 am, Ram Rachum wrote:
Speaking of evil, another evil idea would be to write code that modifies
the ast and changes @ between functions to call a compose function instead.
How do you tell just from the ast whether a particular @ is
between functions?
--
Greg
On 24/05/20 10:26 am, Paul Sokolovsky wrote:
On Mon, 18 May 2020 13:25:50 +1200
Greg Ewing wrote:
Or maybe we could leverage the new walrus operator and write
str := (int)
With the idea that someone may confuse ":=" for "<-", so we can swap
result and a
On 18/05/20 1:59 am, Paul Sokolovsky wrote:
But even
{(int): str} is a better type annotation for a function than
Callable[[int], str].
I don't agree -- it looks more like some kind of dict type, and
would be better reserved for that purpose.
And if we e.g. talk about making "->" a special
On 16/05/20 12:26 am, Steven D'Aprano wrote:
Arguments over the precise definition of states of matter are, to some
degree, futile. I've seen amorphous solids described as "liquids that
don't flow" and non-Newtonian liquids described as "solids that flow".
I think this just shows that nature
On 14/05/20 8:55 am, Richard Damon wrote:
On 5/13/20 2:03 PM, Rhodri James wrote:
I'm sorry, but I think the correct response is to give them a spanking
in code review. I certainly wouldn't pass any code that actually
relied on assert doing anything.
My thought was he just needs to add that
On 7/05/20 9:11 pm, Steven D'Aprano wrote:
I'm initially going to use the ancient 1960s
Fortran syntax and spell it `.EQ.`.
I know that syntax will not work in Python
because it will be ambiguous.
I'm sure the new parser will handle it just fine!
--
Greg
On 7/05/20 1:07 pm, David Mertz wrote:
For *most* functions, the substitution
principle is fine in Python. A whole lot of the time, numeric functions
can take either an int or a float that are equal to each other and
produce results that are equal to each other.
It's not much use for
On 6/05/20 7:45 pm, Henk-Jaap Wagenaar wrote:
So... say you are solving a problem in 1d, you do that on a real number
x, right? Now you solve it in 2d, so you do your work on a pair (x, y),
then you might solve it in 3d and do your work on a triplet (x, y, z). A
few days later you generalize
On 6/05/20 6:12 pm, Steven D'Aprano wrote:
https://mathworld.wolfram.com/n-Tuple.html
https://mathworld.wolfram.com/List.html
https://mathworld.wolfram.com/Sequence.html
I get the feeling those definitions are a result of seeing
things through Mathematica-tinted glasses.
--
Greg
On 6/05/20 1:58 pm, Henk-Jaap Wagenaar wrote:
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.
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
On 1/05/20 2:58 am, Christopher Barker wrote:
Imagine someone that uses zip() in code that works for a while, and then
discovers a bug triggered by unequal length inputs.
If it’s a flag, they look at the zip docstring, and find the flag, and
their problem is solved.
Why would they look at
On 30/04/20 3:32 am, Christopher Barker wrote:
I've wondered about Linked Lists for a while, but while there are many
versions on PyPi, I can't find one that seems to be mature and
maintained. Which seems to indicate that there isn't much demand for them.
I think this is probably because a
201 - 300 of 812 matches
Mail list logo
